[Engine-devel] New tool to upload OVF archives

Shahar Havivi shaharh at redhat.com
Wed Dec 7 07:40:50 UTC 2011 

On 06.12.11 14:14, Keith Robertson wrote:
> 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
the VM image group id.
> 
> 
> 
> 
> On 12/06/2011 10:24 AM, Andrew Cathrow wrote:
> >Can we post that on the upstream wiki?
> >
> >----- Original Message -----
> >>From: "Shahar Havivi"<shaharh at redhat.com>
> >>To: "Keith Robertson"<kroberts at redhat.com>
> >>Cc: engine-devel at 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 at ovirt.org
> >>>http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>_______________________________________________
> >>Engine-devel mailing list
> >>Engine-devel at ovirt.org
> >>http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
>

More information about the Devel mailing list