9: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
5:22 a.m.
Can we update the ID feature to autogenerate an ID instead of specifying it.
Also the ID generation needs to flow through to the template/VM's disk ID
----- Original Message -----
From: "Keith Robertson" <kroberts(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Sunday, December 4, 2011 12:10:38 PM
Subject: [Engine-devel] New tool to upload OVF archives
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
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5: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
----- Original Message -----
> From: "Keith Robertson"<kroberts(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Sunday, December 4, 2011 12:10:38 PM
> Subject: [Engine-devel] New tool to upload OVF archives
>
> 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
>
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
7:34 a.m.
On 12/05/2011 03:58 PM, Keith Robertson wrote:
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
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
[1]: .../engine-image-uploader/src/ovf/sample-ovf.xml
>
> ----- Original Message -----
>> From: "Keith Robertson"<kroberts(a)redhat.com>
>> To: engine-devel(a)ovirt.org
>> Sent: Sunday, December 4, 2011 12:10:38 PM
>> Subject: [Engine-devel] New tool to upload OVF archives
>>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
8:27 a.m.
On 12/05/2011 10:34 AM, Livnat Peer wrote:
On 12/05/2011 03:58 PM, Keith Robertson wrote:
> 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
>
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,
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
Livnat
> [1]: .../engine-image-uploader/src/ovf/sample-ovf.xml
>> ----- Original Message -----
>>> From: "Keith Robertson"<kroberts(a)redhat.com>
>>> To: engine-devel(a)ovirt.org
>>> Sent: Sunday, December 4, 2011 12:10:38 PM
>>> Subject: [Engine-devel] New tool to upload OVF archives
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
12:05 a.m.
On 12/05/2011 06:27 PM, Keith Robertson wrote:
On 12/05/2011 10:34 AM, Livnat Peer wrote:
> On 12/05/2011 03:58 PM, Keith Robertson wrote:
>> 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
>>
> 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,
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. Then you have 2 different templates pointing to the same
disks?
Livnat
Cheers,
Keith
> Livnat
>
>> [1]: .../engine-image-uploader/src/ovf/sample-ovf.xml
>>> ----- Original Message -----
>>>> From: "Keith Robertson"<kroberts(a)redhat.com>
>>>> To: engine-devel(a)ovirt.org
>>>> Sent: Sunday, December 4, 2011 12:10:38 PM
>>>> Subject: [Engine-devel] New tool to upload OVF archives
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
5:41 a.m.
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
6: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:
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
7:24 a.m.
Can we post that on the upstream wiki?
----- Original Message -----
From: "Shahar Havivi" <shaharh(a)redhat.com>
To: "Keith Robertson" <kroberts(a)redhat.com>
Cc: engine-devel(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
7:24 a.m.
On 06.12.11 10:24, Andrew Cathrow wrote:
Can we post that on the upstream wiki?
I dont see y not,
and I did saw the Keith is inside redhat...
----- Original Message -----
> From: "Shahar Havivi" <shaharh(a)redhat.com>
> To: "Keith Robertson" <kroberts(a)redhat.com>
> Cc: engine-devel(a)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(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:14 a.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:
Can we post that on the upstream wiki?
----- Original Message -----
> From: "Shahar Havivi"<shaharh(a)redhat.com>
> To: "Keith Robertson"<kroberts(a)redhat.com>
> Cc: engine-devel(a)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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)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/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--
11:40 p.m.
On 06.12.11 14:14, Keith Robertson wrote:
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
Hi Keith,
ovrit must have image gropu id and the format must be: [Image Group Id]/[Image Id]
if you don't have the image group id you can generate a guid and set it for
the VM image group id.
On 12/06/2011 10:24 AM, Andrew Cathrow wrote:
>Can we post that on the upstream wiki?
>
>----- Original Message -----
>>From: "Shahar Havivi"<shaharh(a)redhat.com>
>>To: "Keith Robertson"<kroberts(a)redhat.com>
>>Cc: engine-devel(a)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(a)ovirt.org
>>>http://lists.ovirt.org/mailman/listinfo/engine-devel
>>_______________________________________________
>>Engine-devel mailing list
>>Engine-devel(a)ovirt.org
>>http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
12:01 a.m.
----- Original Message -----
From: "Shahar Havivi" <shaharh(a)redhat.com>
To: "Keith Robertson" <kroberts(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Wednesday, December 7, 2011 9:40:50 AM
Subject: Re: [Engine-devel] New tool to upload OVF archives
On 06.12.11 14:14, Keith Robertson wrote:
> 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
Hi Keith,
ovrit must have image gropu id and the format must be: [Image Group
Id]/[Image Id]
if you don't have the image group id you can generate a guid and set
it for
the VM image group id.
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.
>
>
>
>
> On 12/06/2011 10:24 AM, Andrew Cathrow wrote:
> >Can we post that on the upstream wiki?
> >
> >----- Original Message -----
> >>From: "Shahar Havivi"<shaharh(a)redhat.com>
> >>To: "Keith Robertson"<kroberts(a)redhat.com>
> >>Cc: engine-devel(a)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(a)ovirt.org
> >>>http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>_______________________________________________
> >>Engine-devel mailing list
> >>Engine-devel(a)ovirt.org
> >>http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:35 a.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.
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=)
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?
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.
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?
12:01 p.m.
----- Original Message -----
From: "Keith Robertson" <kroberts(a)redhat.com>
To: "Omer Frenkel" <ofrenkel(a)redhat.com>, "Andrew Cathrow"
<acathrow(a)redhat.com>
Cc: "Shahar Havivi" <shaharh(a)redhat.com>, engine-devel(a)ovirt.org
Sent: Wednesday, December 7, 2011 2:35:06 PM
Subject: Re: [Engine-devel] New tool to upload OVF archives
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.
> 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=)
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?
> 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.
>
>
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?
So is it valid to have an ovf and image in the root of the zip or do we require a
subdirectory
12:13 p.m.
----- Original Message -----
> From: "Keith Robertson"<kroberts(a)redhat.com>
> To: "Omer Frenkel"<ofrenkel(a)redhat.com>, "Andrew
Cathrow"<acathrow(a)redhat.com>
> Cc: "Shahar Havivi"<shaharh(a)redhat.com>, engine-devel(a)ovirt.org
> Sent: Wednesday, December 7, 2011 2:35:06 PM
> Subject: Re: [Engine-devel] New tool to upload OVF archives
>
> 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.
>> 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=)
> 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?
>> 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.
>>
>>
> 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?
So is it valid to have an ovf and image in the root of the zip or do we require a
subdirectory
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"
7: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:
On 06.12.11 14:14, Keith Robertson wrote:
> 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
Hi Keith,
ovrit must have image gropu id and the format must be: [Image Group Id]/[Image Id]
if you don't have the image group id you can generate a guid and set it for
the VM image group id.
>
>
>
>
> On 12/06/2011 10:24 AM, Andrew Cathrow wrote:
> >Can we post that on the upstream wiki?
> >
> >----- Original Message -----
> >>From: "Shahar Havivi"<shaharh(a)redhat.com>
> >>To: "Keith Robertson"<kroberts(a)redhat.com>
> >>Cc: engine-devel(a)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(a)ovirt.org
> >>>http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>_______________________________________________
> >>Engine-devel mailing list
> >>Engine-devel(a)ovirt.org
> >>http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
>
4524
days inactive
4527
days old
16 comments
5 participants
participants (5)
-
Andrew Cathrow -
Keith Robertson -
Livnat Peer -
Omer Frenkel -
Shahar Havivi