Bug 1401848
| Summary: | [z-stream clone - 4.0.7] Improve OVA import compatibility | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | rhev-integ |
| Component: | ovirt-engine | Assignee: | Shahar Havivi <shavivi> |
| Status: | CLOSED ERRATA | QA Contact: | Nisim Simsolo <nsimsolo> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.0.5 | CC: | ahadas, bgraveno, bugs, dornelas, fabrice.bacchella, fromani, gklein, juzhou, lsurette, mavital, michal.skrivanek, mxie, mzhan, nsimsolo, rbalakri, Rhev-m-bugs, rjones, shavivi, srevivo, tgolembi, tzheng, xiaodwan, ykaul |
| Target Milestone: | ovirt-4.0.7 | Keywords: | ZStream |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Previously, some OVF files that did not contain the VM Name tag caused a runtime error when importing. This update ensures that a default name is provided to the virtual machine by its OVA name.
|
Story Points: | --- |
| Clone Of: | 1401077 | Environment: | |
| Last Closed: | 2017-03-16 15:30:16 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1401077 | ||
| Bug Blocks: | |||
|
Description
rhev-integ
2016-12-06 09:06:32 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. (Originally by Arik Hadas) (Originally by rhev-integ) 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. (Originally by fabrice.bacchella) (Originally by rhev-integ) (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. (Originally by Yaniv Kaul) (Originally by rhev-integ) 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. (Originally by fabrice.bacchella) (Originally by rhev-integ) 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). (Originally by Arik Hadas) (Originally by rhev-integ) I made your requested modification to the OVF and it works. Thanks. (Originally by fabrice.bacchella) (Originally by rhev-integ) We may need to patch vdsm and virt-v2v as well (Originally by Shahar Havivi) (Originally by rhev-integ) 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 (Originally by Tomas Golembiovsky) (Originally by rhev-integ) Patch send to virt-v2v: https://www.redhat.com/archives/libguestfs/2016-September/msg00030.html (Originally by Shahar Havivi) (Originally by rhev-integ) (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". (Originally by Richard Jones) (Originally by rhev-integ) > 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.
(Originally by Shahar Havivi)
(Originally by rhev-integ)
(In reply to rhev-integ from comment #0) > +++ This bug is an upstream to downstream clone. The original bug is: +++ > +++ bug 1371843 +++ > ====================================================================== Whoever did this, next time please don't. It just messed up both original and this bug. Open a regular bug (Originally by michal.skrivanek) it is a trivial backport, let's do that in 4.0.7 (Originally by michal.skrivanek) unfortunately we add to revert until 4.0.6 is out. Will merge clone patch afterwards which other patch is required? (In reply to Michal Skrivanek from comment #20) > which other patch is required? We just need 4.0.6 to be released. After that is done, this patch will be merged, and will be in 4.0.7. Verification build: rhevm-4.0.7-0.1.el7ev qemu-kvm-rhev-2.6.0-28.el7_3.3.x86_64 vdsm-4.18.22-1.el7ev.x86_64 libvirt-client-2.0.0-10.el7_3.4.x86_64 sanlock-3.4.0-1.el7.x86_64 virt-v2v-1.32.7-3.el7_3.2.x86_64 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0542.html |