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

On Mon, May 15, 2017 at 8:05 PM, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote: 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. 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. 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 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.