Re: [Engine-devel] New tool to upload OVF archives

6 Dec 2011

      This is a multi-part message in MIME format.
--------------040900030609090501000801
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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@redhat.com>
To: "Keith Robertson"<kroberts@redhat.com>
Cc: engine-devel@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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--------------040900030609090501000801
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

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

--------------040900030609090501000801--