If VDSM is to be functional in a stand-alone configuration, one of the first features that must be added is support for persistent domains. Since there will not be a management server around to "remember" domain configurations, there should be an option to have VDSM store it. Here is my idea for how it could be implemented. Your comments and advice are greatly appreciated.
Selecting a location to store VM metadata: ------------------------------------------ The first design decision that needs to be made is where the VM metadata should be stored. Based on my investigation, there are two potential locations: 1) In a new directory under '/rhev/data-center', or 2) Inside the Master Storage Domain ('/rhev/data-center/<spUUID>/mastersd/master/vms/').
Option #2 seems the most promising at first but I have a few concerns. The '/rhev/data-center/<spUUID>/mastersd/master/vms/' directory already exists today. What is it currently being used for? Even though I have some VMs created I do not see any information here. Also, if the concept of Master Storage Domain is going away, in the future how will we select a SD in which to store VM definitions?
Option #1 may be an acceptable fallback if issues with #2 cannot be resolved. However, I would prefer that VM metadata be stored on managed storage so that it can be recovered if the host OS needs to be reinstalled.
New VDSM APIs required: ----------------------- Once we have a place to store persistent VM configurations, we will need APIs to define and undefine VMs. I propose the following:
define(vm_params): Create a persistent VM. This API will create a persistent VM that will start in the 'Down' state. The initial user parameters will be saved along with any VDSM derived parameters to a metadata file.
undefine(vmUUID): Delete a persistent VM. This API will un-persist a VM that has been previously created with 'define'. This operation is valid only for Down VMs. The VM will be destroyed and its persistent config removed.
Future APIs: In the future, a new class of APIs for modifying the state of an existing VM will be required. For example: add/remove disks, change memory, change cpus/topology, etc. It would not be very user friendly to force redefinition of a VM just to change some simple hardware details.
Other implications: ------------------- Adding this feature will have implications on a number of other APIs. I am sure I am missing many here so please feel free to add information if you know it.
create(): - If passed in a vmId corresponding to a persistent VM, parameters are loaded from stored metadata.
list(), listNames(), getAllVmStats(), getVmsList(): - These functions must also list persistent VMs
migrate(): - After successful migration, remove local VM metadata
Comments? What have I missed?