[Engine-devel] New tool to upload OVF archives

Livnat Peer lpeer at redhat.com
Tue Dec 6 08:05:48 UTC 2011


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 at redhat.com>
>>>>> To: engine-devel at 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 at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 




More information about the Devel mailing list