[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
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@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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
Hi, the ovf documentation can be found in this link http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat On 06.12.11 08:41, Keith Robertson wrote:
On 12/06/2011 03:05 AM, Livnat Peer wrote:
<snip>
Is it covered by the tool? Livnat, Currently, the tool will only update the TemplateID and the 2 places where it appears. It does not update the "ovf:diskID" attribute or the 5 places where the "diskID" UUID can appear.
The OVF XML schema is a bit vague on these issues so I had to make some assumptions. Please correct my assumptions... I think Shahar can help with this. Shahar - can you publish the ovf docs on the oVirt wiki?
1. The UUID in the TemplateID element appears to be different than the UUID for the "ovf:diskId" attribute. I am assuming that this is a requirement. yes
2. The UUID for the TemplateID uniquely identifies the "image" to be imported *not* the disk ID(s). An image can have multiple disks and each disk would have it's own UUID.
I am not sure i follow you with this question. IIUC the tool supports the ability to change template ID but not change it's disks ids. Correct, this is the current behavior. Then you have 2 different templates pointing to the same disks? No, I don't think you would have two templates pointing to the same disk(s) unless the tool that generated the OVF archive and it's associated XML did it incorrectly.
To summarize, the OVF XML schema appears to create a parent-child relationship between the TemplateID and the disks. See the abbreviated XML below from an actual OVF XML file below and notice the following points:
1. The "Content" element appears to be the "parent" element. It has a "Name" and a "TemplateID" which I think uniquely identify the "image" or "template". 2. The "Content" element has "Item"(s) as indirect children. These "Item"s can be disks and are uniquely identified by their own UUID (i.e. InstanceID). 3. The "InstanceID" of a disk can be resolved to a physical disk by looking at the "id" and "href" combination in the "References" element.
In short, the relationship appears to be...
TemplateID (UUID-1) |- Disk (UUID-2) |- Disk (UUID-3)
Do you agree?
//---------- Begin XML <?xml version='1.0' encoding='UTF-8'?> <ovf:Envelope ovf:version="3.0.0.0"> <References> <File ovf:href="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:id="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8589934592"/> </References> <Section xsi:type="ovf:DiskSection_Type"> <Info>List of Virtual Disks</Info> <Disk ovf:diskId="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8" ovf:actual_size="1" ovf:vm_snapshot_id="c1398a3c-ca59-460a-ac0c-0ea91d7218be" ovf:fileRef="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:format="http://www.gnome.org/~markmc/qcow-image-format.html" ovf:volume-format="COW" ovf:volume-type="Sparse" ovf:disk-interface="VirtIO" ovf:disk-type="System" ovf:boot="true" ovf:wipe-after-delete="false" /> </Section> <Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type"> <Name>tmcowrhel6</Name> <TemplateId>5272b689-cd9f-4532-9b5d-2413eb7b9402</TemplateId> <Section ovf:id="5272b689-cd9f-4532-9b5d-2413eb7b9402" ovf:required="false" xsi:type="ovf:OperatingSystemSection_Type"> <Info>Guest Operating System</Info> <Description>RHEL6x64</Description> </Section> <Section xsi:type="ovf:VirtualHardwareSection_Type"> <Info>1 CPU, 1024 Memeory</Info> <System> <vssd:VirtualSystemType>RHEVM 3.0.0.0</vssd:VirtualSystemType> </System> <Item> <rasd:Caption>Drive 1</rasd:Caption> <rasd:InstanceId>c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:InstanceId> <rasd:ResourceType>17</rasd:ResourceType> <rasd:HostResource>2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:HostResource> </Item> </Section> </Content> </ovf:Envelope>
Livnat
The point is that the TemplatID [1] can have multiple child disks and each ch
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Can we post that on the upstream wiki? ----- Original Message -----
From: "Shahar Havivi" <shaharh@redhat.com> To: "Keith Robertson" <kroberts@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, December 6, 2011 9:48:47 AM Subject: Re: [Engine-devel] New tool to upload OVF archives
Hi, the ovf documentation can be found in this link http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat
On 06.12.11 08:41, Keith Robertson wrote:
On 12/06/2011 03:05 AM, Livnat Peer wrote:
<snip>
Is it covered by the tool? Livnat, Currently, the tool will only update the TemplateID and the 2 places where it appears. It does not update the "ovf:diskID" attribute or the 5 places where the "diskID" UUID can appear.
The OVF XML schema is a bit vague on these issues so I had to make some assumptions. Please correct my assumptions... I think Shahar can help with this. Shahar - can you publish the ovf docs on the oVirt wiki?
1. The UUID in the TemplateID element appears to be different than the UUID for the "ovf:diskId" attribute. I am assuming that this is a requirement. yes
2. The UUID for the TemplateID uniquely identifies the "image" to be imported *not* the disk ID(s). An image can have multiple disks and each disk would have it's own UUID.
I am not sure i follow you with this question. IIUC the tool supports the ability to change template ID but not change it's disks ids. Correct, this is the current behavior. Then you have 2 different templates pointing to the same disks? No, I don't think you would have two templates pointing to the same disk(s) unless the tool that generated the OVF archive and it's associated XML did it incorrectly.
To summarize, the OVF XML schema appears to create a parent-child relationship between the TemplateID and the disks. See the abbreviated XML below from an actual OVF XML file below and notice the following points:
1. The "Content" element appears to be the "parent" element. It has a "Name" and a "TemplateID" which I think uniquely identify the "image" or "template". 2. The "Content" element has "Item"(s) as indirect children. These "Item"s can be disks and are uniquely identified by their own UUID (i.e. InstanceID). 3. The "InstanceID" of a disk can be resolved to a physical disk by looking at the "id" and "href" combination in the "References" element.
In short, the relationship appears to be...
TemplateID (UUID-1) |- Disk (UUID-2) |- Disk (UUID-3)
Do you agree?
//---------- Begin XML <?xml version='1.0' encoding='UTF-8'?> <ovf:Envelope ovf:version="3.0.0.0"> <References> <File ovf:href="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:id="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8589934592"/> </References> <Section xsi:type="ovf:DiskSection_Type"> <Info>List of Virtual Disks</Info> <Disk ovf:diskId="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8" ovf:actual_size="1" ovf:vm_snapshot_id="c1398a3c-ca59-460a-ac0c-0ea91d7218be" ovf:fileRef="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:format="http://www.gnome.org/~markmc/qcow-image-format.html" ovf:volume-format="COW" ovf:volume-type="Sparse" ovf:disk-interface="VirtIO" ovf:disk-type="System" ovf:boot="true" ovf:wipe-after-delete="false" /> </Section> <Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type"> <Name>tmcowrhel6</Name> <TemplateId>5272b689-cd9f-4532-9b5d-2413eb7b9402</TemplateId> <Section ovf:id="5272b689-cd9f-4532-9b5d-2413eb7b9402" ovf:required="false" xsi:type="ovf:OperatingSystemSection_Type"> <Info>Guest Operating System</Info> <Description>RHEL6x64</Description> </Section> <Section xsi:type="ovf:VirtualHardwareSection_Type"> <Info>1 CPU, 1024 Memeory</Info> <System> <vssd:VirtualSystemType>RHEVM 3.0.0.0</vssd:VirtualSystemType> </System> <Item> <rasd:Caption>Drive 1</rasd:Caption> <rasd:InstanceId>c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:InstanceId> <rasd:ResourceType>17</rasd:ResourceType> <rasd:HostResource>2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:HostResource> </Item> </Section> </Content> </ovf:Envelope>
Livnat
The point is that the TemplatID [1] can have multiple child disks and each ch
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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@redhat.com> To: "Keith Robertson" <kroberts@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, December 6, 2011 9:48:47 AM Subject: Re: [Engine-devel] New tool to upload OVF archives
Hi, the ovf documentation can be found in this link http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat
On 06.12.11 08:41, Keith Robertson wrote:
On 12/06/2011 03:05 AM, Livnat Peer wrote:
<snip>
Is it covered by the tool? Livnat, Currently, the tool will only update the TemplateID and the 2 places where it appears. It does not update the "ovf:diskID" attribute or the 5 places where the "diskID" UUID can appear.
The OVF XML schema is a bit vague on these issues so I had to make some assumptions. Please correct my assumptions... I think Shahar can help with this. Shahar - can you publish the ovf docs on the oVirt wiki?
1. The UUID in the TemplateID element appears to be different than the UUID for the "ovf:diskId" attribute. I am assuming that this is a requirement. yes
2. The UUID for the TemplateID uniquely identifies the "image" to be imported *not* the disk ID(s). An image can have multiple disks and each disk would have it's own UUID.
I am not sure i follow you with this question. IIUC the tool supports the ability to change template ID but not change it's disks ids. Correct, this is the current behavior. Then you have 2 different templates pointing to the same disks? No, I don't think you would have two templates pointing to the same disk(s) unless the tool that generated the OVF archive and it's associated XML did it incorrectly.
To summarize, the OVF XML schema appears to create a parent-child relationship between the TemplateID and the disks. See the abbreviated XML below from an actual OVF XML file below and notice the following points:
1. The "Content" element appears to be the "parent" element. It has a "Name" and a "TemplateID" which I think uniquely identify the "image" or "template". 2. The "Content" element has "Item"(s) as indirect children. These "Item"s can be disks and are uniquely identified by their own UUID (i.e. InstanceID). 3. The "InstanceID" of a disk can be resolved to a physical disk by looking at the "id" and "href" combination in the "References" element.
In short, the relationship appears to be...
TemplateID (UUID-1) |- Disk (UUID-2) |- Disk (UUID-3)
Do you agree?
//---------- Begin XML <?xml version='1.0' encoding='UTF-8'?> <ovf:Envelope ovf:version="3.0.0.0"> <References> <File ovf:href="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:id="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8589934592"/> </References> <Section xsi:type="ovf:DiskSection_Type"> <Info>List of Virtual Disks</Info> <Disk ovf:diskId="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8" ovf:actual_size="1" ovf:vm_snapshot_id="c1398a3c-ca59-460a-ac0c-0ea91d7218be" ovf:fileRef="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:format="http://www.gnome.org/~markmc/qcow-image-format.html" ovf:volume-format="COW" ovf:volume-type="Sparse" ovf:disk-interface="VirtIO" ovf:disk-type="System" ovf:boot="true" ovf:wipe-after-delete="false" /> </Section> <Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type"> <Name>tmcowrhel6</Name> <TemplateId>5272b689-cd9f-4532-9b5d-2413eb7b9402</TemplateId> <Section ovf:id="5272b689-cd9f-4532-9b5d-2413eb7b9402" ovf:required="false" xsi:type="ovf:OperatingSystemSection_Type"> <Info>Guest Operating System</Info> <Description>RHEL6x64</Description> </Section> <Section xsi:type="ovf:VirtualHardwareSection_Type"> <Info>1 CPU, 1024 Memeory</Info> <System> <vssd:VirtualSystemType>RHEVM 3.0.0.0</vssd:VirtualSystemType> </System> <Item> <rasd:Caption>Drive 1</rasd:Caption> <rasd:InstanceId>c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:InstanceId> <rasd:ResourceType>17</rasd:ResourceType> <rasd:HostResource>2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:HostResource> </Item> </Section> </Content> </ovf:Envelope>
Livnat
The point is that the TemplatID [1] can have multiple child disks and each ch
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
This is a multi-part message in MIME format. --------------040900030609090501000801 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Shahar and Andrew, There is some ambiguity between the OVF XML schema and the document (i.e. RHEVM-OVF-1.odt). The XSD defines an XML element called Content. This content element roughly correlates to a VM. It has such things as "Name", "TemplateID", and can have "Item" element(s) that describe such things as CPUs, Memory, and Disks. Currently, my tool will allow the user to change the "TemplateID" in the "Content" element. I can easily modify the tool to also change the UUID of each disk that it finds within the "Content" element (i.e. diskID); however, oVirt places an additional stipulation on Disk elements. It states that disks should be laid out like " [Image Group Id]/[Image Id]". What should the tool do if it opens an archive and discovers that disks to not have "Image Group ID"s? Will oVirt be able to appropriately load them if the tool simply copies the image into a path resembling [1] or is it requiring a path like [2]? [1] <nfs export path here>/images/<image here> [2] <nfs export path here>/images/<Image Group UUID here>/<image here> Cheers, Keith On 12/06/2011 10:24 AM, Andrew Cathrow wrote:
Can we post that on the upstream wiki?
----- Original Message -----
From: "Shahar Havivi"<shaharh@redhat.com> To: "Keith Robertson"<kroberts@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, December 6, 2011 9:48:47 AM Subject: Re: [Engine-devel] New tool to upload OVF archives
Hi, the ovf documentation can be found in this link http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat
On 06.12.11 08:41, Keith Robertson wrote:
On 12/06/2011 03:05 AM, Livnat Peer wrote:
<snip>
Is it covered by the tool? Livnat, Currently, the tool will only update the TemplateID and the 2 places where it appears. It does not update the "ovf:diskID" attribute or the 5 places where the "diskID" UUID can appear.
The OVF XML schema is a bit vague on these issues so I had to make some assumptions. Please correct my assumptions... I think Shahar can help with this. Shahar - can you publish the ovf docs on the oVirt wiki?
1. The UUID in the TemplateID element appears to be different than the UUID for the "ovf:diskId" attribute. I am assuming that this is a requirement. yes
2. The UUID for the TemplateID uniquely identifies the "image" to be imported *not* the disk ID(s). An image can have multiple disks and each disk would have it's own UUID.
I am not sure i follow you with this question. IIUC the tool supports the ability to change template ID but not change it's disks ids. Correct, this is the current behavior. Then you have 2 different templates pointing to the same disks? No, I don't think you would have two templates pointing to the same disk(s) unless the tool that generated the OVF archive and it's associated XML did it incorrectly.
To summarize, the OVF XML schema appears to create a parent-child relationship between the TemplateID and the disks. See the abbreviated XML below from an actual OVF XML file below and notice the following points:
1. The "Content" element appears to be the "parent" element. It has a "Name" and a "TemplateID" which I think uniquely identify the "image" or "template". 2. The "Content" element has "Item"(s) as indirect children. These "Item"s can be disks and are uniquely identified by their own UUID (i.e. InstanceID). 3. The "InstanceID" of a disk can be resolved to a physical disk by looking at the "id" and "href" combination in the "References" element.
In short, the relationship appears to be...
TemplateID (UUID-1) |- Disk (UUID-2) |- Disk (UUID-3)
Do you agree?
//---------- Begin XML <?xml version='1.0' encoding='UTF-8'?> <ovf:Envelope ovf:version="3.0.0.0"> <References> <File ovf:href="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:id="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8589934592"/> </References> <Section xsi:type="ovf:DiskSection_Type"> <Info>List of Virtual Disks</Info> <Disk ovf:diskId="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8" ovf:actual_size="1" ovf:vm_snapshot_id="c1398a3c-ca59-460a-ac0c-0ea91d7218be" ovf:fileRef="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:format="http://www.gnome.org/~markmc/qcow-image-format.html" ovf:volume-format="COW" ovf:volume-type="Sparse" ovf:disk-interface="VirtIO" ovf:disk-type="System" ovf:boot="true" ovf:wipe-after-delete="false" /> </Section> <Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type"> <Name>tmcowrhel6</Name> <TemplateId>5272b689-cd9f-4532-9b5d-2413eb7b9402</TemplateId> <Section ovf:id="5272b689-cd9f-4532-9b5d-2413eb7b9402" ovf:required="false" xsi:type="ovf:OperatingSystemSection_Type"> <Info>Guest Operating System</Info> <Description>RHEL6x64</Description> </Section> <Section xsi:type="ovf:VirtualHardwareSection_Type"> <Info>1 CPU, 1024 Memeory</Info> <System> <vssd:VirtualSystemType>RHEVM 3.0.0.0</vssd:VirtualSystemType> </System> <Item> <rasd:Caption>Drive 1</rasd:Caption> <rasd:InstanceId>c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:InstanceId> <rasd:ResourceType>17</rasd:ResourceType> <rasd:HostResource>2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:HostResource> </Item> </Section> </Content> </ovf:Envelope>
Livnat
The point is that the TemplatID [1] can have multiple child disks and each ch
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
--------------040900030609090501000801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Shahar and Andrew,<br> <br> There is some ambiguity between the OVF XML schema and the document (i.e. RHEVM-OVF-1.odt). The XSD defines an XML element called Content. This content element roughly correlates to a VM. It has such things as "Name", "TemplateID", and can have "Item" element(s) that describe such things as CPUs, Memory, and Disks.<br> <br> Currently, my tool will allow the user to change the "TemplateID" in the "Content" element. I can easily modify the tool to also change the UUID of each disk that it finds within the "Content" element (i.e. diskID); however, oVirt places an additional stipulation on Disk elements. It states that disks should be laid out like " <style type="text/css">p { margin-bottom: 0.08in; }</style>[Image Group Id]/[Image Id]". <br> <br> What should the tool do if it opens an archive and discovers that disks to not have "Image Group ID"s? Will oVirt be able to appropriately load them if the tool simply copies the image into a path resembling [1] or is it requiring a path like [2]?<br> <br> [1] <nfs export path here>/images/<image here><br> [2] <nfs export path here>/images/<Image Group UUID here>/<image here><br> <br> Cheers,<br> Keith<br> <br> <br> <br> <br> On 12/06/2011 10:24 AM, Andrew Cathrow wrote: <blockquote cite="mid:616503c4-fb89-4dbb-b8c7-3cc88394cbb0@zmail07.collab.prod.int.phx2.redhat.com" type="cite"> <pre wrap="">Can we post that on the upstream wiki? ----- Original Message ----- </pre> <blockquote type="cite"> <pre wrap="">From: "Shahar Havivi" <a class="moz-txt-link-rfc2396E" href="mailto:shaharh@redhat.com"><shaharh@redhat.com></a> To: "Keith Robertson" <a class="moz-txt-link-rfc2396E" href="mailto:kroberts@redhat.com"><kroberts@redhat.com></a> Cc: <a class="moz-txt-link-abbreviated" href="mailto:engine-devel@ovirt.org">engine-devel@ovirt.org</a> Sent: Tuesday, December 6, 2011 9:48:47 AM Subject: Re: [Engine-devel] New tool to upload OVF archives Hi, the ovf documentation can be found in this link <a class="moz-txt-link-freetext" href="http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat">http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat</a> On 06.12.11 08:41, Keith Robertson wrote: </pre> <blockquote type="cite"> <pre wrap="">On 12/06/2011 03:05 AM, Livnat Peer wrote: </pre> <blockquote type="cite"> <pre wrap=""><snip> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Is it covered by the tool? </pre> </blockquote> <pre wrap="">Livnat, Currently, the tool will only update the TemplateID and the 2 places where it appears. It does not update the "ovf:diskID" attribute or the 5 places where the "diskID" UUID can appear. The OVF XML schema is a bit vague on these issues so I had to make some assumptions. Please correct my assumptions... </pre> </blockquote> <pre wrap="">I think Shahar can help with this. Shahar - can you publish the ovf docs on the oVirt wiki? </pre> <blockquote type="cite"> <pre wrap="">1. The UUID in the TemplateID element appears to be different than the UUID for the "ovf:diskId" attribute. I am assuming that this is a requirement. </pre> </blockquote> <pre wrap="">yes </pre> <blockquote type="cite"> <pre wrap="">2. The UUID for the TemplateID uniquely identifies the "image" to be imported *not* the disk ID(s). An image can have multiple disks and each disk would have it's own UUID. </pre> </blockquote> <pre wrap="">I am not sure i follow you with this question. IIUC the tool supports the ability to change template ID but not change it's disks ids. </pre> </blockquote> <pre wrap="">Correct, this is the current behavior. </pre> <blockquote type="cite"> <pre wrap="">Then you have 2 different templates pointing to the same disks? </pre> </blockquote> <pre wrap="">No, I don't think you would have two templates pointing to the same disk(s) unless the tool that generated the OVF archive and it's associated XML did it incorrectly. To summarize, the OVF XML schema appears to create a parent-child relationship between the TemplateID and the disks. See the abbreviated XML below from an actual OVF XML file below and notice the following points: 1. The "Content" element appears to be the "parent" element. It has a "Name" and a "TemplateID" which I think uniquely identify the "image" or "template". 2. The "Content" element has "Item"(s) as indirect children. These "Item"s can be disks and are uniquely identified by their own UUID (i.e. InstanceID). 3. The "InstanceID" of a disk can be resolved to a physical disk by looking at the "id" and "href" combination in the "References" element. In short, the relationship appears to be... TemplateID (UUID-1) |- Disk (UUID-2) |- Disk (UUID-3) Do you agree? //---------- Begin XML <?xml version='1.0' encoding='UTF-8'?> <ovf:Envelope ovf:version="3.0.0.0"> <References> <File ovf:href="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:id="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8589934592"/> </References> <Section xsi:type="ovf:DiskSection_Type"> <Info>List of Virtual Disks</Info> <Disk ovf:diskId="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8" ovf:actual_size="1" ovf:vm_snapshot_id="c1398a3c-ca59-460a-ac0c-0ea91d7218be" ovf:fileRef="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:format=<a class="moz-txt-link-rfc2396E" href="http://www.gnome.org/~markmc/qcow-image-format.html">"http://www.gnome.org/~markmc/qcow-image-format.html"</a> ovf:volume-format="COW" ovf:volume-type="Sparse" ovf:disk-interface="VirtIO" ovf:disk-type="System" ovf:boot="true" ovf:wipe-after-delete="false" /> </Section> <Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type"> <Name>tmcowrhel6</Name> <TemplateId>5272b689-cd9f-4532-9b5d-2413eb7b9402</TemplateId> <Section ovf:id="5272b689-cd9f-4532-9b5d-2413eb7b9402" ovf:required="false" xsi:type="ovf:OperatingSystemSection_Type"> <Info>Guest Operating System</Info> <Description>RHEL6x64</Description> </Section> <Section xsi:type="ovf:VirtualHardwareSection_Type"> <Info>1 CPU, 1024 Memeory</Info> <System> <vssd:VirtualSystemType>RHEVM 3.0.0.0</vssd:VirtualSystemType> </System> <Item> <rasd:Caption>Drive 1</rasd:Caption> <rasd:InstanceId>c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:InstanceId> <rasd:ResourceType>17</rasd:ResourceType> <rasd:HostResource>2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:HostResource> </Item> </Section> </Content> </ovf:Envelope> </pre> <blockquote type="cite"> <pre wrap="">Livnat </pre> </blockquote> <pre wrap="">The point is that the TemplatID [1] can have multiple child disks and each ch _______________________________________________ Engine-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/engine-devel">http://lists.ovirt.org/mailman/listinfo/engine-devel</a> </pre> </blockquote> <pre wrap="">_______________________________________________ Engine-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/engine-devel">http://lists.ovirt.org/mailman/listinfo/engine-devel</a> </pre> </blockquote> </blockquote> <br> </body> </html> --------------040900030609090501000801--
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
On 06.12.11 14:14, Keith Robertson wrote: 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@redhat.com> To: "Keith Robertson"<kroberts@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, December 6, 2011 9:48:47 AM Subject: Re: [Engine-devel] New tool to upload OVF archives
Hi, the ovf documentation can be found in this link http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat
On 06.12.11 08:41, Keith Robertson wrote:
On 12/06/2011 03:05 AM, Livnat Peer wrote:
<snip>
>Is it covered by the tool? Livnat, Currently, the tool will only update the TemplateID and the 2 places where it appears. It does not update the "ovf:diskID" attribute or the 5 places where the "diskID" UUID can appear.
The OVF XML schema is a bit vague on these issues so I had to make some assumptions. Please correct my assumptions... I think Shahar can help with this. Shahar - can you publish the ovf docs on the oVirt wiki?
1. The UUID in the TemplateID element appears to be different than the UUID for the "ovf:diskId" attribute. I am assuming that this is a requirement. yes
2. The UUID for the TemplateID uniquely identifies the "image" to be imported *not* the disk ID(s). An image can have multiple disks and each disk would have it's own UUID.
I am not sure i follow you with this question. IIUC the tool supports the ability to change template ID but not change it's disks ids. Correct, this is the current behavior. Then you have 2 different templates pointing to the same disks? No, I don't think you would have two templates pointing to the same disk(s) unless the tool that generated the OVF archive and it's associated XML did it incorrectly.
To summarize, the OVF XML schema appears to create a parent-child relationship between the TemplateID and the disks. See the abbreviated XML below from an actual OVF XML file below and notice the following points:
1. The "Content" element appears to be the "parent" element. It has a "Name" and a "TemplateID" which I think uniquely identify the "image" or "template". 2. The "Content" element has "Item"(s) as indirect children. These "Item"s can be disks and are uniquely identified by their own UUID (i.e. InstanceID). 3. The "InstanceID" of a disk can be resolved to a physical disk by looking at the "id" and "href" combination in the "References" element.
In short, the relationship appears to be...
TemplateID (UUID-1) |- Disk (UUID-2) |- Disk (UUID-3)
Do you agree?
//---------- Begin XML <?xml version='1.0' encoding='UTF-8'?> <ovf:Envelope ovf:version="3.0.0.0"> <References> <File ovf:href="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:id="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8589934592"/> </References> <Section xsi:type="ovf:DiskSection_Type"> <Info>List of Virtual Disks</Info> <Disk ovf:diskId="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8" ovf:actual_size="1" ovf:vm_snapshot_id="c1398a3c-ca59-460a-ac0c-0ea91d7218be" ovf:fileRef="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:format="http://www.gnome.org/~markmc/qcow-image-format.html" ovf:volume-format="COW" ovf:volume-type="Sparse" ovf:disk-interface="VirtIO" ovf:disk-type="System" ovf:boot="true" ovf:wipe-after-delete="false" /> </Section> <Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type"> <Name>tmcowrhel6</Name> <TemplateId>5272b689-cd9f-4532-9b5d-2413eb7b9402</TemplateId> <Section ovf:id="5272b689-cd9f-4532-9b5d-2413eb7b9402" ovf:required="false" xsi:type="ovf:OperatingSystemSection_Type"> <Info>Guest Operating System</Info> <Description>RHEL6x64</Description> </Section> <Section xsi:type="ovf:VirtualHardwareSection_Type"> <Info>1 CPU, 1024 Memeory</Info> <System> <vssd:VirtualSystemType>RHEVM 3.0.0.0</vssd:VirtualSystemType> </System> <Item> <rasd:Caption>Drive 1</rasd:Caption> <rasd:InstanceId>c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:InstanceId> <rasd:ResourceType>17</rasd:ResourceType> <rasd:HostResource>2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:HostResource> </Item> </Section> </Content> </ovf:Envelope>
Livnat
The point is that the TemplatID [1] can have multiple child disks and each ch
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Shahar Havivi" <shaharh@redhat.com> To: "Keith Robertson" <kroberts@redhat.com> Cc: engine-devel@ovirt.org Sent: Wednesday, December 7, 2011 9:40:50 AM Subject: Re: [Engine-devel] New tool to upload OVF archives
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
On 06.12.11 14:14, Keith Robertson wrote: 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@redhat.com> To: "Keith Robertson"<kroberts@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, December 6, 2011 9:48:47 AM Subject: Re: [Engine-devel] New tool to upload OVF archives
Hi, the ovf documentation can be found in this link http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat
On 06.12.11 08:41, Keith Robertson wrote:
On 12/06/2011 03:05 AM, Livnat Peer wrote:
<snip> >>Is it covered by the tool? >Livnat, >Currently, the tool will only update the TemplateID and the 2 >places >where it appears. It does not update the "ovf:diskID" >attribute >or the >5 places where the "diskID" UUID can appear. > >The OVF XML schema is a bit vague on these issues so I had to >make some >assumptions. Please correct my assumptions... I think Shahar can help with this. Shahar - can you publish the ovf docs on the oVirt wiki?
>1. The UUID in the TemplateID element appears to be different >than the >UUID for the "ovf:diskId" attribute. I am assuming that this >is >a >requirement. yes
>2. The UUID for the TemplateID uniquely identifies the "image" >to >be >imported *not* the disk ID(s). An image can have multiple >disks >and >each disk would have it's own UUID. > I am not sure i follow you with this question. IIUC the tool supports the ability to change template ID but not change it's disks ids. Correct, this is the current behavior. Then you have 2 different templates pointing to the same disks? No, I don't think you would have two templates pointing to the same disk(s) unless the tool that generated the OVF archive and it's associated XML did it incorrectly.
To summarize, the OVF XML schema appears to create a parent-child relationship between the TemplateID and the disks. See the abbreviated XML below from an actual OVF XML file below and notice the following points:
1. The "Content" element appears to be the "parent" element. It has a "Name" and a "TemplateID" which I think uniquely identify the "image" or "template". 2. The "Content" element has "Item"(s) as indirect children. These "Item"s can be disks and are uniquely identified by their own UUID (i.e. InstanceID). 3. The "InstanceID" of a disk can be resolved to a physical disk by looking at the "id" and "href" combination in the "References" element.
In short, the relationship appears to be...
TemplateID (UUID-1) |- Disk (UUID-2) |- Disk (UUID-3)
Do you agree?
//---------- Begin XML <?xml version='1.0' encoding='UTF-8'?> <ovf:Envelope ovf:version="3.0.0.0"> <References> <File ovf:href="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:id="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8589934592"/> </References> <Section xsi:type="ovf:DiskSection_Type"> <Info>List of Virtual Disks</Info> <Disk ovf:diskId="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8" ovf:actual_size="1" ovf:vm_snapshot_id="c1398a3c-ca59-460a-ac0c-0ea91d7218be" ovf:fileRef="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:format="http://www.gnome.org/~markmc/qcow-image-format.html" ovf:volume-format="COW" ovf:volume-type="Sparse" ovf:disk-interface="VirtIO" ovf:disk-type="System" ovf:boot="true" ovf:wipe-after-delete="false" /> </Section> <Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type"> <Name>tmcowrhel6</Name> <TemplateId>5272b689-cd9f-4532-9b5d-2413eb7b9402</TemplateId> <Section ovf:id="5272b689-cd9f-4532-9b5d-2413eb7b9402" ovf:required="false" xsi:type="ovf:OperatingSystemSection_Type"> <Info>Guest Operating System</Info> <Description>RHEL6x64</Description> </Section> <Section xsi:type="ovf:VirtualHardwareSection_Type"> <Info>1 CPU, 1024 Memeory</Info> <System> <vssd:VirtualSystemType>RHEVM 3.0.0.0</vssd:VirtualSystemType> </System> <Item> <rasd:Caption>Drive 1</rasd:Caption> <rasd:InstanceId>c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:InstanceId> <rasd:ResourceType>17</rasd:ResourceType> <rasd:HostResource>2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:HostResource> </Item> </Section> </Content> </ovf:Envelope>
Livnat
The point is that the TemplatID [1] can have multiple child disks and each ch
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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?
----- Original Message -----
From: "Keith Robertson" <kroberts@redhat.com> To: "Omer Frenkel" <ofrenkel@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com> Cc: "Shahar Havivi" <shaharh@redhat.com>, engine-devel@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
----- Original Message -----
From: "Keith Robertson"<kroberts@redhat.com> To: "Omer Frenkel"<ofrenkel@redhat.com>, "Andrew Cathrow"<acathrow@redhat.com> Cc: "Shahar Havivi"<shaharh@redhat.com>, engine-devel@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"
The ovirt link to the ovf document: http://www.ovirt.org/wiki/Ovf On 07.12.11 09:40, Shahar Havivi 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
On 06.12.11 14:14, Keith Robertson wrote: 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@redhat.com> To: "Keith Robertson"<kroberts@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, December 6, 2011 9:48:47 AM Subject: Re: [Engine-devel] New tool to upload OVF archives
Hi, the ovf documentation can be found in this link http://cleo.tlv.redhat.com/qumrawiki/CategoryRhevmBackend/OvfFileFormat
On 06.12.11 08:41, Keith Robertson wrote:
On 12/06/2011 03:05 AM, Livnat Peer wrote:
<snip> >>Is it covered by the tool? >Livnat, >Currently, the tool will only update the TemplateID and the 2 >places >where it appears. It does not update the "ovf:diskID" attribute >or the >5 places where the "diskID" UUID can appear. > >The OVF XML schema is a bit vague on these issues so I had to >make some >assumptions. Please correct my assumptions... I think Shahar can help with this. Shahar - can you publish the ovf docs on the oVirt wiki?
>1. The UUID in the TemplateID element appears to be different >than the >UUID for the "ovf:diskId" attribute. I am assuming that this is >a >requirement. yes
>2. The UUID for the TemplateID uniquely identifies the "image" to >be >imported *not* the disk ID(s). An image can have multiple disks >and >each disk would have it's own UUID. > I am not sure i follow you with this question. IIUC the tool supports the ability to change template ID but not change it's disks ids. Correct, this is the current behavior. Then you have 2 different templates pointing to the same disks? No, I don't think you would have two templates pointing to the same disk(s) unless the tool that generated the OVF archive and it's associated XML did it incorrectly.
To summarize, the OVF XML schema appears to create a parent-child relationship between the TemplateID and the disks. See the abbreviated XML below from an actual OVF XML file below and notice the following points:
1. The "Content" element appears to be the "parent" element. It has a "Name" and a "TemplateID" which I think uniquely identify the "image" or "template". 2. The "Content" element has "Item"(s) as indirect children. These "Item"s can be disks and are uniquely identified by their own UUID (i.e. InstanceID). 3. The "InstanceID" of a disk can be resolved to a physical disk by looking at the "id" and "href" combination in the "References" element.
In short, the relationship appears to be...
TemplateID (UUID-1) |- Disk (UUID-2) |- Disk (UUID-3)
Do you agree?
//---------- Begin XML <?xml version='1.0' encoding='UTF-8'?> <ovf:Envelope ovf:version="3.0.0.0"> <References> <File ovf:href="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:id="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8589934592"/> </References> <Section xsi:type="ovf:DiskSection_Type"> <Info>List of Virtual Disks</Info> <Disk ovf:diskId="c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:size="8" ovf:actual_size="1" ovf:vm_snapshot_id="c1398a3c-ca59-460a-ac0c-0ea91d7218be" ovf:fileRef="2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad" ovf:format="http://www.gnome.org/~markmc/qcow-image-format.html" ovf:volume-format="COW" ovf:volume-type="Sparse" ovf:disk-interface="VirtIO" ovf:disk-type="System" ovf:boot="true" ovf:wipe-after-delete="false" /> </Section> <Content ovf:id="out" xsi:type="ovf:VirtualSystem_Type"> <Name>tmcowrhel6</Name> <TemplateId>5272b689-cd9f-4532-9b5d-2413eb7b9402</TemplateId> <Section ovf:id="5272b689-cd9f-4532-9b5d-2413eb7b9402" ovf:required="false" xsi:type="ovf:OperatingSystemSection_Type"> <Info>Guest Operating System</Info> <Description>RHEL6x64</Description> </Section> <Section xsi:type="ovf:VirtualHardwareSection_Type"> <Info>1 CPU, 1024 Memeory</Info> <System> <vssd:VirtualSystemType>RHEVM 3.0.0.0</vssd:VirtualSystemType> </System> <Item> <rasd:Caption>Drive 1</rasd:Caption> <rasd:InstanceId>c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:InstanceId> <rasd:ResourceType>17</rasd:ResourceType> <rasd:HostResource>2b30e705-c1d6-4bd8-a6cd-a1fe8a70614f/c0e51e1b-004e-4d10-abc0-8b9f5e21f3ad </rasd:HostResource> </Item> </Section> </Content> </ovf:Envelope>
Livnat
The point is that the TemplatID [1] can have multiple child disks and each ch
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (5)
-
Andrew Cathrow -
Keith Robertson -
Livnat Peer -
Omer Frenkel -
Shahar Havivi