On Fri, Sep 02, 2011 at 03:44:58PM -0500, Adam Litke wrote:
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?
RHEV-M uses this directory to hold a backup of its VM metadata. That's done via the updateVM verb. The metadata is stored there in OVF format.
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.
The deep reason why #2 cannot be resolved, is that VM metadata is essentially data-center-wide. Vdsm, however, is a single node manager, that may not have visibility to the complete network or storage domains.
This is also why I am reluctant to add VM database into Vdsm - I think it belongs to a higher level. Handling the removal of a defined VM on migration success seems very hard to do right - imagine destination crash just in the worst time. We need a distributed database for that.
Single node use case is very important, though. I would love to see a Vdsm sub-package that maintains a database of VM domains, as well of all other inter-node information.
That sub-package could implement the define/undefine API that you suggest; maybe something more elaborated such as rhevm-api.
Regards,
Dan.
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?