11:10 a.m.
All,
I have created a new tool that makes it easier to upload an OVF archive
file to an oVirt export domain. I've attached the patch to this email
so that you can try it out and see what it does.
I am looking for feedback on the tool so please let me know what you think.
Cheers,
Keith
//---- Begin description
The new tool provided in this patch makes it easier to upload an
OVF archive to an export domain. An OVF archive is simply a
zipped archive that can contain an image and must contain
an XML document describing the image to be uploaded.
The tool has the following behavior:
1. Before unpacking the archive it will check for requisite space
on the local system.
2. Before uploading the requisite parts in the archive it will
check for space in the target NFS export domain.
3. At this time only NFS as a transport mechanism is supported.
This is slightly different behavior than the iso uploader which
supports both NFS and SSH/SFTP.
4. The tool will allow you to rename the image.
5. The tool will allow you to change the UUID of the image.
6. The tool will only upload those files explicitly listed in the
archive's XML .ovf file. This prevents spurious cruft which it included
in some OVF archives from being moved to the export domain.
Example usage:
1. > python ovirt-image-uploader.py -n 127.0.0.1:/virt/exports
--template-name=new-name-here --template-id=new-uuid-here upload
keith.ovf --force
2. > python ovirt-image-uploader.py --conf-file=./imageuploader.conf list
Please provide the REST API password for RHEV-M (CTRL+D to abort):
Export Storage Domain Name | Datacenter | Export
Domain Status
ExportDomain | LegacyDC | active
3. > python ovirt-image-uploader.py -e ExportDomain
--template-name=new-name-here --template-id=new-uuid-here upload
keith.ovf --force
7:58 a.m.
On 12/05/2011 08:22 AM, Andrew Cathrow wrote:
Can we update the ID feature to autogenerate an ID instead of specifying it.
Yes.
Also the ID generation needs to flow through to the template/VM's
disk ID
Are you sure about that? In the sample OVF XML in the patch [1], the
XML Element, "TemplateId", has a UUID that ends in 9402. The only other
place that this 9402 UUID appears is in the "ovf:id" attribute a
"Section" element. This UUID does not appear in any disk ID elements.
Hence, it was my assumption that the UUIDs for the TemplateID and the
"ovf:diskId" elements are distinctly separate.
Cheers,
Keith
[1]: .../engine-image-uploader/src/ovf/sample-ovf.xml
9:34 a.m.
On 12/05/2011 03:58 PM, Keith Robertson wrote:
Hi Keith,
As far as i know the template id appears only once which is fine but the
disk id should be updated in several places.
I think Andrew's question was referencing to the disk-id.
Changing the disk id also requires taking care of all the references to
this id, for example:
- in the ovf file the References element, Disk element and devices under
"VirtualHardwareSection".
- The image files names (image and meta-data file)
- The data inside the meta-data file
Is it covered by the tool?
Livnat
10:27 a.m.
On 12/05/2011 10:34 AM, Livnat Peer wrote:
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...
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.
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.
Cheers,
Keith
2:05 a.m.
On 12/05/2011 06:27 PM, Keith Robertson wrote:
I think Shahar can help with this.
Shahar - can you publish the ovf docs on the oVirt wiki?
yes
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. Then you have 2 different templates pointing to the same
disks?
Livnat
7:41 a.m.
On 12/06/2011 03:05 AM, Livnat Peer wrote:
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
8:48 a.m.
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:
1:14 p.m.
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:
--------------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/OvfF...
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">&...
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">...
</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">...
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>
--------------040900030609090501000801--
2:01 a.m.
----- Original Message -----
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.
1:35 p.m.
On 12/07/2011 03:01 AM, Omer Frenkel wrote:
<snip
first some clarifications so we could talk in the same language:
Agreed. It's
actually pretty hard to describe all of this.
I have noticed that when I tell oVirt to import an image that it will
import it even if there isn't a .meta file. As such, I would like to
know if a .meta file required or will oVirt automatically generate one?
Here is a use case that illustrates some of the issues that I am facing:
1. Assume the following OVF archive.
|
|- 5272b689-cd9f-4532-9b5d-2413eb7b9402.ovf <-- The OVF XML
|- c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad <-- The COW image
2. In the exmple above, there is no directory hiearchy defined in the
archive (i.e. all files are in the root).
3. Also, in the example above the file
"5272b689-cd9f-4532-9b5d-2413eb7b9402.ovf" appropriately refers to the
image in it's XML without an "Image Group UUID" in the prefix.
I can have the tool massage the XML and the directory layout so that it
will upload to the export domain such that it looks like this...
<NFS EXPORT DOMAIN HERE>/virt/exports/
|----- images
| |----- 2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f <-- Generated UUID
| |----- 5272b689-cd9f-4532-9b5d-2413eb7b9402
|---- master
|---- vms
|---- 5272b689-cd9f-4532-9b5d-2413eb7b9402
|---- 5272b689-cd9f-4532-9b5d-2413eb7b9402.ovf
Is this desireable?
2:13 p.m.
Yes, it is valid in the XML. The question is does oVirt support it.
Here are 2 odd-ball scenarios:
1. The image is deeply nested in the archive.
dir1/dir2/dir3/.../dirN/cow-image-here
Inside the XML you would have...
<File ovf:href="dir1/dir2/.../dirN/cow-image-here"
2. The image is in the root of the archive...
cow-image-here
Inside the XML you whould have...
<File ovf:href="cow-image-here"
9:04 a.m.
The ovirt link to the ovf document:
http://www.ovirt.org/wiki/Ovf
On 07.12.11 09:40, Shahar Havivi wrote:
4869
days inactive
4872
days old
16 comments
5 participants
participants (5)
-
Andrew Cathrow -
Keith Robertson -
Livnat Peer -
Omer Frenkel -
Shahar Havivi