<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Shahar and Andrew,<br>
<br>
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.<br>
<br>
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 "
<style type="text/css">p { margin-bottom: 0.08in; }</style>[Image
Group Id]/[Image Id]". <br>
<br>
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]?<br>
<br>
[1] <nfs export path here>/images/<image here><br>
[2] <nfs export path here>/images/<Image Group UUID
here>/<image here><br>
<br>
Cheers,<br>
Keith<br>
<br>
<br>
<br>
<br>
On 12/06/2011 10:24 AM, Andrew Cathrow wrote:
<blockquote
cite="mid:616503c4-fb89-4dbb-b8c7-3cc88394cbb0@zmail07.collab.prod.int.phx2.redhat.com"
type="cite">
<pre wrap="">Can we post that on the upstream wiki?
----- Original Message -----
</pre>
<blockquote type="cite">
<pre wrap="">From: "Shahar Havivi" <a class="moz-txt-link-rfc2396E" href="mailto:shaharh@redhat.com"><shaharh@redhat.com></a>
To: "Keith Robertson" <a class="moz-txt-link-rfc2396E" href="mailto:kroberts@redhat.com"><kroberts@redhat.com></a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:engine-devel@ovirt.org">engine-devel@ovirt.org</a>
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
<a class="moz-txt-link-freetext" href="http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat">http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat</a>
On 06.12.11 08:41, Keith Robertson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 12/06/2011 03:05 AM, Livnat Peer wrote:
</pre>
<blockquote type="cite">
<pre wrap=""><snip>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Is it covered by the tool?
</pre>
</blockquote>
<pre wrap="">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...
</pre>
</blockquote>
<pre wrap="">I think Shahar can help with this.
Shahar - can you publish the ovf docs on the oVirt wiki?
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">yes
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Correct, this is the current behavior.
</pre>
<blockquote type="cite">
<pre wrap="">Then you have 2 different templates pointing to the same
disks?
</pre>
</blockquote>
<pre wrap="">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=<a class="moz-txt-link-rfc2396E" href="http://www.gnome.org/~markmc/qcow-image-format.html">"http://www.gnome.org/~markmc/qcow-image-format.html"</a>
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>
</pre>
<blockquote type="cite">
<pre wrap="">Livnat
</pre>
</blockquote>
<pre wrap="">The point is that the TemplatID [1] can have multiple child disks
and each ch
_______________________________________________
Engine-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/engine-devel">http://lists.ovirt.org/mailman/listinfo/engine-devel</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Engine-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/engine-devel">http://lists.ovirt.org/mailman/listinfo/engine-devel</a>
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>