Bug 983749

Summary:	[RFE] Allow to import existing data storage domains and register vms from them
Product:	[Retired] oVirt	Reporter:	joshua
Component:	vdsm	Assignee:	Maor <mlipchuk>
Status:	CLOSED DUPLICATE	QA Contact:	yeylon <yeylon>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acathrow, amureini, bazulay, bugs, iheim, jboggs, mgoldboi, ovirt-bugs, ovirt-maint, srevivo
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	3.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	storage
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-08-04 12:02:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description joshua 2013-07-11 21:02:35 UTC

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 23:50:33 UTC

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 12:11:12 UTC

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 09:54:44 UTC

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 13:49:21 UTC

(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 05:44:55 UTC

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 23:54:01 UTC

Yes, what he said!

Comment 8 Itamar Heim 2014-08-04 12:02:08 UTC

should be in 3.5 already

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