[Engine-devel] New tool to upload OVF archives
Keith Robertson
kroberts at redhat.com
Tue Dec 6 13:41:37 UTC 2011
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
More information about the Engine-devel
mailing list