11: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