On Mon, Sep 05, 2011 at 07:38:30AM -0400, Ayal Baron wrote:
----- Original Message -----
On Mon, Sep 05, 2011 at 05:59:28AM -0400, Ayal Baron wrote:
----- Original Message -----
On Sun, Sep 04, 2011 at 03:16:08PM -0400, Ayal Baron wrote:
----- Original Message -----
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.
Once we get rid of "master domain" and "SPM", each domain can have its own are for storing small files (e.g. VM definition file).
A VM definition should be stored on only one domain (true for both RHEVM use case and any other use case) and if the VM has disks spanning multiple domains then management/user needs to decide which domain will hold this info (e.g. where the system disk is, or first domain which had a disk in it or whatever).
wrt Dan's comment, vdsm should have visibility to all the resources needed to run a VM. This means that if vdsm is to run VM-X which has disks on storage domain A and SD B then vdsm should be connected to both domains (same applies to networks). vdsm could locally cache storage and networking info so that when the VM references a storage or a network, we could automatically connect/configure whatever we need.
The "data-center-wide" bit is totally irrelevant as the storage is shared so as long as vdsm can access the domain, it's fine.
It is relevant. For example, we do not want two Vdsms creating different VMs with the same name or vmId. Your suggested scheme, where each Vdsm persists VM metadata on a storage domain that it sees, may lead to that.
We would still have an "SDM" which would prevent such a scenario from occuring. Management would have to choose the SDM. I don't see the problem.
I do not see how SDM helps us here, unless we give one of our SDMs control on our single VM DB. One Vdsm is asked to create VM-A. Another Vdsm is asked to create another VM, which happens to have the same name, but a totally different definition. Who decides which one is created?
As I noted above, you would have a VM "DB" per domain, not one global DB. And of course only one vdsm would control a domain (the SDM)
The point that I try to convey is that having more than one VM DB in a migration domain, is wrong.
One SDM may be asked to define VM-A, with disks on its domain. Another SDM may be asked to define another VM named VM-A. We end up defining both, and cannot run them both on the same host.
And to our jewish readers: there's one God in heaven; there should be one DB on earth.
Dan.