Bug 983749 - [RFE] Allow to import existing data storage domains and register vms from them
[RFE] Allow to import existing data storage domains and register vms from them
Status: CLOSED DUPLICATE of bug 1083307
Product: oVirt
Classification: Community
Component: vdsm (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.5.0
Assigned To: Maor
yeylon@redhat.com
storage
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-11 17:02 EDT by joshua
Modified: 2016-04-18 02:57 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-08-04 08:02:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description joshua 2013-07-11 17:02:35 EDT
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.
Comment 1 joshua 2013-07-11 19:50:33 EDT
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?
Comment 2 Mike Burns 2013-07-12 08:11:12 EDT
vdsm might not be the right component, but they're the agent that runs on ovirt-node hosts.  Moving there for more triage.
Comment 3 Itamar Heim 2013-07-13 05:54:44 EDT
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?
Comment 4 Ayal Baron 2013-07-14 09:49:21 EDT
(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.
Comment 5 Ayal Baron 2013-07-15 01:44:55 EDT
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.
Comment 6 joshua 2013-07-17 19:54:01 EDT
Yes, what he said!
Comment 8 Itamar Heim 2014-08-04 08:02:08 EDT
should be in 3.5 already

*** This bug has been marked as a duplicate of bug 1083307 ***

Note You need to log in before you can comment on or make changes to this bug.