7:51 a.m.
Hi,
from time to time we get a request [1] to import appliance with crafted
OVF (from Cisco or Gigamon) into oVirt. The common denominator is that
some disks are missing and are supposed to be created during import of
the appliance.
Doing the import properly would require not only solving of the problem
with missing disks, but also implementing multiple concepts -- notably
concept of configurations [2] (for Cisco appliance) or concept of
properties [3] (for Gigamon appliance). This would be quite complex
change to oVirt as well as to virt-v2v and at the moment we don't feel
that such effort is justifiable. But by solving the problem with disks
we can at least provide a helping hand to those requiring the crafted
appliances.
The idea here is that virt-v2v would ignore the non-existing disks and
user would be required to add those manually after conversion. As for
OVFs using the configurations virt-v2v would pick some settings from OVF
(random from users perspective) and user would be responsible for
editing the VM's configuration after conversion (CPUs, memory, etc.) to
size the VM properly based on the expected use. We could further
constrain this to only work with -o vdsm, but this may not be needed
unless we hit some issues with implementing the feature. It is also
possible that ignoring the disks may not work for some reasons that
we have not yet discovered and we'll se once we try.
There is one more problem with the Cisco OVA that it contains .cert file
which is not specified in manifest. But the file is not needed during
conversion. So this could be possibly handled by enforcing virt-v2v to
use only files listed in manifest instead of complaining.
Before I invest any time into this I wanted to make sure that such
approach would be acceptable to the upstream. So would this be good
enough?
***
The topics for discussions are above. What follows are the technical
details for those interested in gain deeper understanding of the
problem. You may be wondering why would we want to ignore the empty
disks if we can create them for most of the output backends. The problem
is, that we cannot. Either we don't know which disks are of the interest
because not all should be used (configurations) or we have no idea how
big the disk should be (properties).
### Configurations
The OVF can define several configurations in DeploymentOptionSection.
A short (simplified) example may look like this:
<DeploymentOptionSection>
<Configuration ovf:default="true" ovf:id="Standard" />
<Configuration ovf:id="Express" />
...
</DeploymentOptionSection>
Then in the VirtualHardwareSection there can be duplicate settings
distinguished only by the ovf:configuration attribute. For example 2 different
vCPU configurations:
<Item ovf:configuration="Express">
...
<rasd:Description>Number of Virtual CPUs</rasd:Description>
<rasd:ResourceType>3</rasd:ResourceType>
<rasd:VirtualQuantity>4</rasd:VirtualQuantity>
</Item>
<Item ovf:configuration="Standard">
...
<rasd:Description>Number of Virtual CPUs</rasd:Description>
<rasd:ResourceType>3</rasd:ResourceType>
<rasd:VirtualQuantity>16</rasd:VirtualQuantity>
</Item>
In terms of disks this means that only some of the disks get used. Specifically
the Cisco Appliance has 4 disks listed in the DiskSection -- 1 system disk A
and 3 empty disks B,C,D. But the created VM never has all four. It has either
only A or it has A+B or A+C or A+D. Without understanding configurations we
cannot tell whether to use B, C, D or none.
### Properties
The OVF can define various properties in ProductSection element. Like this:
<ProductSection>
...
<Property ovf:key="datadisksize"
ovf:qualifiers="MinValue(20),MaxValue(1000)" ovf:type="int"
ovf:userConfigurable="true">
<Label>02. Size of Data Disk</Label>
<Description>The size of the Data Disk in
gigabytes.</Description>
<Value ovf:value="40"/>
</Property>
...
</ProductSection
Then, the ovf:key value of the property can be used as a variable on
other places in the OVF. For example like this:
<DiskSection>
...
<Disk ovf:capacity="${datadisksize}" ovf:fileRef="" ...
/>
...
</DiskSection>
And as before, without understanding the concept virt-v2v has no idea
how to size the disk. The Value element is optional (if the property is
userConfigurable) so relying on the default in OVF may not work. I can
imagine some OVFs may even use a property to specify vCPU count or
memory which could bring up a question how to handle those. Possibly
default to 0 or 1 (where 1 may be better default in my opinion).
Tomas
[1] https://bugzilla.redhat.com/1705600
[2] Open Virtualization Format Specification (DSP0243) Version 2.1.1,
Chapter 9.8 -- DeploymentOptionSection
[3] Open Virtualization Format Specification (DSP0243) Version 2.1.1,
Chapter 9.5.1 -- Property elements
--
Tomáš Golembiovský <tgolembi(a)redhat.com>