Description of problem: when we loose RHEV-M, we need not loose all the VMs that it knows about It shouldn't be that hard to enable a new replacement RHEV-M to learn about pre-existing VMs.... this feature is sorely needed. Hypervisors should be able to cache or otherwise record metadata about their VMs, such that RHEV-M could learn about them should it need to.
Wait... individual VMs *do* have there meta data stored on the hypervisor: DOMAIN=51d5738a-441a-46d8-bab7-1ee5b793e2b8 VOLTYPE=LEAF CTIME=1348180485 FORMAT=RAW IMAGE=df6bc6a4-8cb5-40ad-8560-6b60e5d2ec8b DISKTYPE=1 PUUID=00000000-0000-0000-0000-000000000000 LEGALITY=LEGAL MTIME=1350957837 POOL_UUID= SIZE=83886080 TYPE=PREALLOCATED DESCRIPTION=Exported by virt-v2v EOF Why on earth can't RHEV-M read this if replacing an instance of itself?
vdsm might not be the right component, but they're the agent that runs on ovirt-node hosts. Moving there for more triage.
registering the disks is already in. registering VMs shouldn't too much of a gap. iirc, the main gap is "import existing storage domain" - ayal?
(In reply to Itamar Heim from comment #3) > registering the disks is already in. > registering VMs shouldn't too much of a gap. > iirc, the main gap is "import existing storage domain" - ayal? The above metadata is a single disk metadata not a VMs metadata. The ability to import that already exists as you stated using GetUnregisteredDiskQuery and RegisterDisk. Wrt VMs, currently oVirt stores the VMs metadata on the master storage domain and the gap is just to add the ability to read that and import existing VMs from there. After that to make it more useful what we want is to have the ability to store the VM metadata on *any* domain so that storage domains would be self sufficient and we wouldn't have to rely on the master domain being available.
To be clear, what we need is the ability to import an existing domain, read all the VMs in it and import them as well (similarly to discover unregistered disks since we might already have the same VM in the system and we'd need a way to handle the conflict). This is unfortunately not that simple since currently the VMs data is on the master fs which is only mounted by the SPM so either we'd import this into a new pool (in which case we'd need it to have the same pool uuid as the one stated on the domain or change it on the domain manually which would require some kind of tool or a new verb in vdsm). Alternatively, we could add a new verb to spm to mount a domain's fs and introspect.
Yes, what he said!
should be in 3.5 already *** This bug has been marked as a duplicate of bug 1083307 ***