[ovirt-devel] [ovirt-users] Feature: enhanced OVA support

Tue May 16 08:07:30 UTC 2017

On Mon, May 15, 2017 at 10:52 PM, Arik Hadas <ahadas at redhat.com> wrote:

>
>
> On Mon, May 15, 2017 at 8:05 PM, Richard W.M. Jones <rjones at redhat.com>
> wrote:
>
>> On Sun, May 14, 2017 at 04:56:56PM +0300, Arik Hadas wrote:
>> > Hi everyone,
>> >
>> > We would like to share our plan for extending the currently provided
>> > support for OVA files with:
>> > 1. Support for uploading OVA.
>> > 2. Support for exporting a VM/template as OVA.
>> > 3. Support for importing OVA that was generated by oVirt (today, we only
>> > support those that are VMware-compatible).
>> > 4. Support for downloading OVA.
>> >
>> > This can be found on the feature page
>> > <http://www.ovirt.org/develop/release-management/features/vi
>> rt/enhance-import-export-with-ova/>
>> > .
>> >
>> > Your feedback and cooperation will be highly appreciated.
>>
>> The plan as stated seems fine, but I have some reservations which I
>> don't think are answered by the page:
>>
>> (1) How will oVirt know the difference between an OVA generated
>> by oVirt and one generated by VMware (or indeed other sources)?
>> A VMware OVF has an XML comment:
>>
>> <!--Generated by VMware ESX Server, [...] -->
>>
>> but not any official metadata that I could see.
>
>
> So that's something that we have not decided on yet.
> Indeed, we need some indication of the system that generated the OVA and
> it makes sense to have it inside the OVF. I thought about a field that is
> part of the VM configuration, like the "origin" field of VMs in
> ovirt-engine. Having a comment like you mentioned is also an option.
>
>
>>
>> (By the way, I don't think importing via virt-v2v vs directly will be
>> any quicker.  The v2v conversion / device installation takes only a
>> fraction of the time.  Most of the time is consumed doing the format
>> conversion from VMDK to qcow2.  However you are correct that when you
>> know that the source is oVirt/KVM, you should not run virt-v2v.)
>>
>
> Note that the disks within the OVA will be of type qcow2. So not only that
> no v2v conversion / device installation is needed, but also no format
> conversion will be needed on the import and upload flows.
>
>
>>
>> (2) I think you're going to have a lot of fun generating OVAs which
>> work on VMware.  As Yaniv says, the devices aren't the same so you'd
>> be having to do some virt-v2v -like driver installation / registry
>> modification.  Plus the OVF file is essentially a VMware data dump
>> encoded as XML.  OVF isn't a real standard.  I bet there are a million
>> strange corner cases.  Even writing VMDK files is full of pitfalls.
>>
>> VMware has a reasonable V2V import tool (actually their P2V tooling is
>> very decent).  Of course it's proprietary, but then so is their
>> hypervisor.  Maybe oVirt can drive their tools?
>>
>
> No no, that fun is not part of the plan :)
> The OVAs we'll generate are supposed to contain:
> 1. OVF - it should be similar to the one virt-v2v generates for oVirt
> (that is similar to the one we use internally in oVirt for snapshots and
> for backup within storage domains, i.e., OVF-stores). We will definitely
> need some extensions, like an indication that the OVA was generated by
> oVirt. We may make some tweaks here and there, like removing network
> interfaces from the list of resources. But we already are generally aligned
> with what the specification says about OVFs.
>
> 2. qcow2 disks - thus, no conversion (device installation) and no format
> conversion will be needed (we may consider to convert them to raw later on,
> since they are expected to be the base volumes of the disks, not sure it
> worth the effort though).
>

I wonder if it's worth looking into several options when exporting:
1. Run virt-sysprep with 'harmless' operations such as
'abrt-data,backup-files,crash-data,tmp-files'

> 2. Run virt-sparsify on the disks.
3. Convert to compressed qcow2. In most cases it certainly can have a
significant saving (1:2 should be reasonable, but some can get 1:6 even) of
disk space (and later, file transfer times, etc).
If we are already converting, we can also convert from qcow2 to qcow2v3
(compat 0.1 to compat 1.1).

Y.

> I will add this to the feature page.
>
> We are aware to the fact that with this design, the OVAs could not be
> directly consumed by others, like VMware. But this could make it easier for
> them to make the needed conversion - they won't need to query the VM
> configuration from oVirt and won't need to lookup the disks inside oVirt's
> storage domains. Anyway, we assume that this conversion is done by other
> tools.
>
>
>> Rich.
>>
>> --
>> Richard Jones, Virtualization Group, Red Hat
>> http://people.redhat.com/~rjones
>> Read my programming and virtualization blog: http://rwmj.wordpress.com
>> Fedora Windows cross-compiler. Compile Windows programs, test, and
>> build Windows installers. Over 100 libraries supported.
>> http://fedoraproject.org/wiki/MinGW
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170516/ea93921b/attachment-0001.html>