----- Original Message -----
From: "Shahar Havivi" <shaharh@redhat.com> To: "Keith Robertson" <kroberts@redhat.com> Cc: engine-devel@ovirt.org Sent: Wednesday, December 7, 2011 9:40:50 AM Subject: Re: [Engine-devel] New tool to upload OVF archives
Shahar and Andrew,
There is some ambiguity between the OVF XML schema and the document (i.e. RHEVM-OVF-1.odt). The XSD defines an XML element called Content. This content element roughly correlates to a VM. It has such things as "Name", "TemplateID", and can have "Item" element(s) that describe such things as CPUs, Memory, and Disks.
Currently, my tool will allow the user to change the "TemplateID" in the "Content" element. I can easily modify the tool to also change the UUID of each disk that it finds within the "Content" element (i.e. diskID); however, oVirt places an additional stipulation on Disk elements. It states that disks should be laid out like " [Image Group Id]/[Image Id]".
What should the tool do if it opens an archive and discovers that disks to not have "Image Group ID"s? Will oVirt be able to appropriately load them if the tool simply copies the image into a path resembling [1] or is it requiring a path like [2]?
[1] <nfs export path here>/images/<image here> [2] <nfs export path here>/images/<Image Group UUID here>/<image here>
Cheers, Keith Hi Keith, ovrit must have image gropu id and the format must be: [Image Group Id]/[Image Id] if you don't have the image group id you can generate a guid and set it for
On 06.12.11 14:14, Keith Robertson wrote: the VM image group id.
first some clarifications so we could talk in the same language: 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=) 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.
On 12/06/2011 10:24 AM, Andrew Cathrow wrote:
Can we post that on the upstream wiki?
----- Original Message -----
From: "Shahar Havivi"<shaharh@redhat.com> To: "Keith Robertson"<kroberts@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, December 6, 2011 9:48:47 AM Subject: Re: [Engine-devel] New tool to upload OVF archives
Hi, the ovf documentation can be found in this link http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat
On 06.12.11 08:41, Keith Robertson wrote:
On 12/06/2011 03:05 AM, Livnat Peer wrote:
<snip> >>Is it covered by the tool? >Livnat, >Currently, the tool will only update the TemplateID and the 2 >places >where it appears. It does not update the "ovf:diskID" >attribute >or the >5 places where the "diskID" UUID can appear. > >The OVF XML schema is a bit vague on these issues so I had to >make some >assumptions. Please correct my assumptions... I think Shahar can help with this. Shahar - can you publish the ovf docs on the oVirt wiki?
>1. The UUID in the TemplateID element appears to be different >than the >UUID for the "ovf:diskId" attribute. I am assuming that this >is >a >requirement. yes
>2. The UUID for the TemplateID uniquely identifies the "image" >to >be >imported *not* the disk ID(s). An image can have multiple >disks >and >each disk would have it's own UUID. > I am not sure i follow you with this question. IIUC the tool supports the ability to change template ID but not change it's disks ids. Correct, this is the current behavior. Then you have 2 different templates pointing to the same disks? No, I don't think you would have two templates pointing to the same disk(s) unless the tool that generated the OVF archive and it's associated XML did it incorrectly.
To summarize, the OVF XML schema appears to create a parent-child relationship between the TemplateID and the disks. See the abbreviated XML below from an actual OVF XML file below and notice the following points:
1. The "Content" element appears to be the "parent" element. It has a "Name" and a "TemplateID" which I think uniquely identify the "image" or "template". 2. The "Content" element has "Item"(s) as indirect children. These "Item"s can be disks and are uniquely identified by their own UUID (i.e. InstanceID). 3. The "InstanceID" of a disk can be resolved to a physical disk by looking at the "id" and "href" combination in the "References" element.
In short, the relationship appears to be...
TemplateID (UUID-1) |- Disk (UUID-2) |- Disk (UUID-3)
Do you agree?
//---------- Begin XML <?xml version='1.0' encoding='UTF-8'?> <ovf:Envelope ovf:version="3.0.0.0"> <References> <File ovf:href="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:id="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8589934592"/> </References> <Section xsi:type="ovf:DiskSection_Type"> <Info>List of Virtual Disks</Info> <Disk ovf:diskId="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8" ovf:actual_size="1" ovf:vm_snapshot_id="c1398a3c-ca59-460a-ac0c-0ea91d7218be" ovf:fileRef="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:format="http://www.gnome.org/~markmc/qcow-image-format.html" ovf:volume-format="COW" ovf:volume-type="Sparse" ovf:disk-interface="VirtIO" ovf:disk-type="System" ovf:boot="true" ovf:wipe-after-delete="false" /> </Section> <Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type"> <Name>tmcowrhel6</Name> <TemplateId>5272b689-cd9f-4532-9b5d-2413eb7b9402</TemplateId> <Section ovf:id="5272b689-cd9f-4532-9b5d-2413eb7b9402" ovf:required="false" xsi:type="ovf:OperatingSystemSection_Type"> <Info>Guest Operating System</Info> <Description>RHEL6x64</Description> </Section> <Section xsi:type="ovf:VirtualHardwareSection_Type"> <Info>1 CPU, 1024 Memeory</Info> <System> <vssd:VirtualSystemType>RHEVM 3.0.0.0</vssd:VirtualSystemType> </System> <Item> <rasd:Caption>Drive 1</rasd:Caption> <rasd:InstanceId>c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:InstanceId> <rasd:ResourceType>17</rasd:ResourceType> <rasd:HostResource>2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:HostResource> </Item> </Section> </Content> </ovf:Envelope>
Livnat
The point is that the TemplatID [1] can have multiple child disks and each ch
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel