Re: [Engine-devel] New tool to upload OVF archives

From: "Keith Robertson" <kroberts(a)redhat.com&gt; To: "Omer Frenkel" <ofrenkel(a)redhat.com&gt;, "Andrew Cathrow" <acathrow(a)redhat.com&gt; Cc: "Shahar Havivi" <shaharh(a)redhat.com&gt;, engine-devel(a)ovirt.org Sent: Wednesday, December 7, 2011 2:35:06 PM Subject: Re: [Engine-devel] New tool to upload OVF archives On 12/07/2011 03:01 AM, Omer Frenkel wrote: > <snip > first some clarifications so we could talk in the same language: Agreed. It's actually pretty hard to describe all of this. > image in vdsm called image-group in rhevm (and stands for a whole > disk) > it can have one or more volume(s) which is called image in rhevm > (and stand for snapshots of the disk) > > so now, every volume file has a .meta file, and the image id is > written there (under IMAGE=) I have noticed that when I tell oVirt to import an image that it will import it even if there isn't a .meta file. As such, I would like to know if a .meta file required or will oVirt automatically generate one? > so without it i don't think its a valid image entirely, > if for some reason the image id is missing, it should be taken from > the volume meta file. > > Here is a use case that illustrates some of the issues that I am facing: 1. Assume the following OVF archive. | |- 5272b689-cd9f-4532-9b5d-2413eb7b9402.ovf <-- The OVF XML |- c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad <-- The COW image 2. In the exmple above, there is no directory hiearchy defined in the archive (i.e. all files are in the root). 3. Also, in the example above the file "5272b689-cd9f-4532-9b5d-2413eb7b9402.ovf" appropriately refers to the image in it's XML without an "Image Group UUID" in the prefix. I can have the tool massage the XML and the directory layout so that it will upload to the export domain such that it looks like this... <NFS EXPORT DOMAIN HERE>/virt/exports/ |----- images | |----- 2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f <-- Generated UUID | |----- 5272b689-cd9f-4532-9b5d-2413eb7b9402 |---- master |---- vms |---- 5272b689-cd9f-4532-9b5d-2413eb7b9402 |---- 5272b689-cd9f-4532-9b5d-2413eb7b9402.ovf Is this desireable?