[Engine-devel] New tool to upload OVF archives

Tue Dec 6 19:14:33 UTC 2011

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

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
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20111206/6e99de40/attachment-0002.html>