[Engine-devel] New tool to upload OVF archives

Omer Frenkel ofrenkel at redhat.com
Wed Dec 7 08:01:40 UTC 2011 


----- Original Message -----
> From: "Shahar Havivi" <shaharh at redhat.com>
> To: "Keith Robertson" <kroberts at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, December 7, 2011 9:40:50 AM
> Subject: Re: [Engine-devel] New tool to upload OVF archives
> 
> 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.

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 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
> > >>
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

More information about the Engine-devel mailing list