Bug 1371843 - Improve OVA import compatibility
Summary: Improve OVA import compatibility
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.0.3
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ovirt-4.1.0-alpha
: 4.1.0.2
Assignee: Shahar Havivi
QA Contact: Nisim Simsolo
URL:
Whiteboard:
Depends On: 1406304
Blocks: 1401077 1402301
TreeView+ depends on / blocked
 
Reported: 2016-08-31 08:58 UTC by Fabrice Bacchella
Modified: 2017-02-01 14:33 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1401077 1402301 (view as bug list)
Environment:
Last Closed: 2017-02-01 14:33:48 UTC
oVirt Team: Virt
Embargoed:
rule-engine: ovirt-4.1+
rule-engine: planning_ack+
michal.skrivanek: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 63517 0 master MERGED v2v: Support for ova exported from AWS 2020-03-11 05:43:03 UTC

Description Fabrice Bacchella 2016-08-31 08:58:24 UTC
For it's AWS Storage Gateway, Amazon provides it's VM gateway as an OVA. But ovirt can't import it using the "import virtual machines wizard", it fails with:

File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 544, in _handle_request
    res = method(**params)
  File "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line 195, in _dynamicMethod
    result = fn(*methodArgs)
  File "/usr/share/vdsm/API.py", line 1427, in getExternalVmFromOva
    return v2v.get_ova_info(ova_path)
  File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 197, in get_ova_info
    _add_general_ovf_info(vm, root, ns)
  File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 1060, in _add_general_ovf_info
    raise V2VError('Error parsing ovf information: no ovf:Name')
V2VError: Error parsing ovf information: no ovf:Name

You can test it, the VM is easy to get from:
https://eu-central-1.console.aws.amazon.com/storagegateway/create

Comment 1 Arik 2016-08-31 09:37:21 UTC
(In reply to Fabrice Bacchella from comment #0)
The current implementation of import OVAs is targeted for (and therefore tested with) OVAs that represent VMs exported from VMWare. This needs to be enhanced in order to support OVAs from other sources, like Amazon.

Comment 2 Fabrice Bacchella 2016-08-31 09:46:29 UTC
OVA and OVF are open standard specified by the DMTF. Ever you support it whatever the source is coming from, or you have a very poor and incomplete implementation that happens to support random instances.

Don't try to nitpick about where it's coming from.

Comment 3 Yaniv Kaul 2016-09-01 07:02:20 UTC
(In reply to Fabrice Bacchella from comment #2)
> OVA and OVF are open standard specified by the DMTF. Ever you support it
> whatever the source is coming from, or you have a very poor and incomplete
> implementation that happens to support random instances.

This is the thing about it being an 'open' standard - everyone can write anything there (specifically, in the XML). And in fact, everyone does.
For example, VMware does not support our OVF - and no wonder - they have no idea what virtio is.

Same goes for Amazon.

> 
> Don't try to nitpick about where it's coming from.

Hope the above explains why it's not a nitpick.

Comment 4 Fabrice Bacchella 2016-09-01 07:23:06 UTC
I'm not talking about hardware compatibility problem, like a vmdk versus other format, or a strange network card. The problem occurs when parsing the ovf xml.

The VM I tried to import is made specifically to run in vmware. So it's a "vmware compatible" ova. That make it's failure in ovirt even more strange.

Comment 6 Arik 2016-09-04 14:20:25 UTC
The OVF in the given OVA differs from OVFs that are generated by vSphere in:
1. There is no <Name> tag under <VirtualSystem>
2. The content of <rasd:HostResource> does not have the "ovf:" prefix
By adding these things, I managed to convert the given OVA.

Shahar,
1. this should be added to the code you have added in virt-v2v, right?
2. I guess we should not count on having the name of the VM inside the OVA. IMO the whole import dialog should behave differently for OVA files: when choosing OVA as a source, the user needs to specify the host and the path as today and if they are valid to go directly to the second dialog (and there we already verify that the VM name is not empty).

Fabrice, in the meantime, I suggest to extract the file (it is just a tar file), do the changes mentioned above manually and pack it again. Then you'll be able to import this VM (I also started the VM and got to the login screen).

Comment 7 Fabrice Bacchella 2016-09-05 09:20:13 UTC
I made your requested modification to the OVF and it works. Thanks.

Comment 8 Shahar Havivi 2016-09-05 09:39:26 UTC
We may need to patch vdsm and virt-v2v as well

Comment 11 Tomáš Golembiovský 2016-09-06 11:39:35 UTC
I've also looked at the specification referenced by Shahar[1] to make sure whether we're just fixing our mess or somebody else's mess.

(In reply to Arik from comment #6)
> The OVF in the given OVA differs from OVFs that are generated by vSphere in:
> 1. There is no <Name> tag under <VirtualSystem>

The <Name> element is not mentioned anywhere (except examples), but looking at the schema file[2] it says it's optional.

> 2. The content of <rasd:HostResource> does not have the "ovf:" prefix

This is however a different story. Specification clearly states the value is either "ovf:/file/<id>" or "ovf:/disk/<id>". So it has to include the "ovf:" prefix. See Table 3 on page 21.


[1] http://www.dmtf.org/sites/default/files/standards/documents/DSP0243_2.1.0.pdf
[2] http://schemas.dmtf.org/ovf/envelope/2/dsp8023.xsd

Comment 12 Shahar Havivi 2016-09-08 08:41:33 UTC
Patch send to virt-v2v:
https://www.redhat.com/archives/libguestfs/2016-September/msg00030.html

Comment 13 Richard W.M. Jones 2016-09-08 09:32:26 UTC
(In reply to Arik from comment #6)
> 2. I guess we should not count on having the name of the VM inside the OVA.
> IMO the whole import dialog should behave differently for OVA files: when
> choosing OVA as a source, the user needs to specify the host and the path as
> today and if they are valid to go directly to the second dialog (and there
> we already verify that the VM name is not empty).

You might want an optional name field, which would translate to
passing '-on name' to virt-v2v (or not).  With Shahar's patch,
every Amazon VM will be mapped to the same name "default".

Comment 14 Shahar Havivi 2016-09-08 10:50:40 UTC
> You might want an optional name field, which would translate to
> passing '-on name' to virt-v2v (or not).  With Shahar's patch,
> every Amazon VM will be mapped to the same name "default".
it is true only for conversion that will run directly virt-v2v.
vdsm is naming each vm with 'default' if the Name is not exists (current patch), and in oVirt engine you are able to name the VM regardless the ovf:name tag.

Comment 17 Richard W.M. Jones 2016-12-07 08:16:00 UTC
Upstream patches:

1ae4252c93c685cb8561b55c1231502b37212b5a
312379c8a61cd4a16aa7c80c1adda3081e601d43 (possibly)
98619f9c26076d034574b8822dfcc6799741ed96

Comment 19 Richard W.M. Jones 2016-12-07 08:21:56 UTC
(In reply to Richard W.M. Jones from comment #17)
> Upstream patches:
> 
> 1ae4252c93c685cb8561b55c1231502b37212b5a
> 312379c8a61cd4a16aa7c80c1adda3081e601d43 (possibly)
> 98619f9c26076d034574b8822dfcc6799741ed96

Sorry, those are the libguestfs commits.  Tingting will
create a new bug to track inclusion of those fixes in
RHEL 7.3-z.

Comment 20 tingting zheng 2016-12-07 08:42:13 UTC
(In reply to Richard W.M. Jones from comment #19)
> (In reply to Richard W.M. Jones from comment #17)
> > Upstream patches:
> > 
> > 1ae4252c93c685cb8561b55c1231502b37212b5a
> > 312379c8a61cd4a16aa7c80c1adda3081e601d43 (possibly)
> > 98619f9c26076d034574b8822dfcc6799741ed96
> 
> Sorry, those are the libguestfs commits.  Tingting will
> create a new bug to track inclusion of those fixes in
> RHEL 7.3-z.

I just cloned this bug against libguestfs on rhel7.4 to track from virt-v2v side:bug 1402301.For 7.3.z,I think the request should be raised and approved by pm.

Comment 21 Sandro Bonazzola 2016-12-12 13:53:37 UTC
The fix for this issue should be included in oVirt 4.1.0 beta 1 released on December 1st. If not included please move back to modified.

Comment 22 Nisim Simsolo 2017-01-02 13:54:16 UTC
bug https://bugzilla.redhat.com/show_bug.cgi?id=1406304 is blocking import testing, When trying to import OVA or VM from any external provider, the next error message (popup) appears:
Error while executing action: 

rhel7_VM:
must be greater than or equal to 1
Attribute: vm.vmStatic.maxMemorySizeMb

Comment 23 Nisim Simsolo 2017-01-30 12:41:23 UTC
Verification builds:
ovirt-engine-4.1.0.2-0.2.el7
libvirt-client-2.0.0-10.el7_3.4.x86_64
vdsm-4.19.2-2.el7ev.x86_64
qemu-kvm-rhev-2.6.0-28.el7_3.3.x86_64
sanlock-3.4.0-1.el7.x86_64
virt-v2v-1.32.7-3.el7_3.2.x86_64


Note You need to log in before you can comment on or make changes to this bug.