Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1511522 - ImportVmFromConfiguration fails with NullPointerException after domain import between 4.1 and 4.2 env
Summary: ImportVmFromConfiguration fails with NullPointerException after domain import...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.1.7.6
Hardware: x86_64
OS: Unspecified
medium
medium vote
Target Milestone: ovirt-4.3.0
: 4.3.0
Assignee: Arik
QA Contact: Liran Rotenberg
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-09 13:59 UTC by Elad
Modified: 2019-02-13 07:46 UTC (History)
4 users (show)

Fixed In Version: ovirt-engine-4.3.0_alpha
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-13 07:46:50 UTC
oVirt Team: Virt
rule-engine: ovirt-4.3+


Attachments (Terms of Use)
logs from engine and hypervisors (deleted)
2017-11-09 13:59 UTC, Elad
no flags Details
ovf (deleted)
2018-03-05 10:59 UTC, Elad
no flags Details


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 88534 master MERGED core: fix an NPE on import vms with future custom compatibility version 2018-03-06 22:40:52 UTC

Description Elad 2017-11-09 13:59:20 UTC
Created attachment 1349929 [details]
logs from engine and hypervisors

Description of problem:
Following https://bugzilla.redhat.com/show_bug.cgi?id=1511037#c2

Import VM (from data domain in my case, we think it could be reproduced with export domain) fails with the following:

2017-11-08 17:50:19,208+02 ERROR [org.ovirt.engine.core.bll.exportimport.ImportVmFromConfigurationCommand] (default task-16) [] Error during ValidateFailure.: java.lang.NullPointerException
        at org.ovirt.engine.core.bll.validator.VmValidationUtils.isGraphicsAndDisplaySupported(VmValidationUtils.java:75) [bll.jar:]
        at org.ovirt.engine.core.bll.VmHandler.isGraphicsAndDisplaySupported(VmHandler.java:632) [bll.jar:]
        at org.ovirt.engine.core.bll.VmHandler$Proxy$_$$_WeldClientProxy.isGraphicsAndDisplaySupported(Unknown Source) [bll.jar:]
        at org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.validateGraphicsAndDisplay(ImportVmCommandBase.java:212) [bll.jar:]
        at org.ovirt.engine.core.bll.exportimport.ImportVmCommand.validateAfterCloneVm(ImportVmCommand.java:469) [bll.jar:]
        at org.ovirt.engine.core.bll.exportimport.ImportVmCommand.validate(ImportVmCommand.java:190) [bll.jar:]
        at org.ovirt.engine.core.bll.exportimport.ImportVmFromConfigurationCommand.validate(ImportVmFromConfigurationCommand.java:87) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.internalValidate(CommandBase.java:836) [bll.jar:]
        at org.ovirt.engine.core.bll.CommandBase.validateOnly(CommandBase.java:365) [bll.jar:]


Version-Release number of selected component (if applicable):
rhevm-4.1.7.6-0.1.el7.noarch

How reproducible:
Not always

Steps to Reproduce:
1. Had more than 50 VMs backup up to iSCSI domain's OVF_STORE and destroyed the domain.
2. Imported the domain to 4.2 DC (4.2 setup) and registered all the VMs
3. Destroyed the domain and imported it to a 4.1 DC in 4.1.7 setup
4. Registered all the VMs 

Actual results:
Import for some of the VMs failed with the mentioned exception

Expected results:
Import should succeed.

Additional info:
logs from engine and hypervisors

Comment 1 Michal Skrivanek 2017-11-10 08:30:27 UTC
I do not see a reason for separate bug yet. Please continue in https://bugzilla.redhat.com/show_bug.cgi?id=1511037#c3

*** This bug has been marked as a duplicate of bug 1511037 ***

Comment 2 Elad 2017-12-03 14:58:19 UTC
We can re-open this bug based on https://bugzilla.redhat.com/show_bug.cgi?id=1511037#c12

Comment 3 Maor 2017-12-18 12:53:31 UTC
I think that this bug should re-opened, since this bug should be related to the cluster compatibility, and probably should be fixed, as Michal suggested, by validating the compatibility level of the VM's cluster before importing it.
the other bug BZ1511037 should be focused on the exception got from prepare image, which is not be related to this issue.
Michal, do you have any objection about this?

Comment 4 Yaniv Lavi 2017-12-27 14:11:53 UTC
Reopening to consider.

Comment 5 Michal Skrivanek 2017-12-27 15:11:13 UTC
this bug tracks blocking imports from newer CL to older engines
It will likely work only from the version that the fix is merged into

Comment 6 Arik 2018-03-05 09:54:25 UTC
(In reply to Elad from comment #0)
> Actual results:
> Import for some of the VMs failed with the mentioned exception

Elad, can you tell whether or not these VMs that we failed to import to 4.1 are set with a custom compatibility version? (does this domain still available?)

Comment 7 Elad 2018-03-05 10:59:05 UTC
Created attachment 1404287 [details]
ovf

<CustomCompatibilityVersion>4.2</CustomCompatibilityVersion><ClusterCompatibilityVersi
on>4.1</ClusterCompatibilityVersion>

Comment 8 Arik 2018-03-06 08:56:25 UTC
Elad, thanks.

Reducing severity as this would happen only to VMs whose effective compatibility version is higher than the compatibility version of the target cluster + this issue exists since 3.6, so apparently, that flow is not that common.

Comment 9 Michal Skrivanek 2018-03-06 10:33:59 UTC
to elaborate on comment #5 we should allow only thee 2 flows:
1) export according to cluster level of the VM (so it's importable in corresponding engine version) 
2) import according to cluster level in OVF as that particular version - either into the same cluster version or into a newer cluster version with cluster level override set to the old one

Comment 10 Arik 2018-03-13 22:07:19 UTC
(In reply to Michal Skrivanek from comment #9)
> 2) import according to cluster level in OVF as that particular version -
> either into the same cluster version or into a newer cluster version with
> cluster level override set to the old one

What if the cluster version that the VM was exported from is not supported? for instance, the VM was exported in oVirt 3.3 and imported to engine 4.2

Comment 11 Michal Skrivanek 2018-03-14 14:13:37 UTC
for 3.3 you do not have the clusterVersion in OVF, but in general I guess we can do a best effort and treat it as the lowest version currently supported. Ideally with a big fat warning

Comment 12 Arik 2018-03-14 14:17:47 UTC
(In reply to Michal Skrivanek from comment #11)
> for 3.3 you do not have the clusterVersion in OVF, but in general I guess we
> can do a best effort and treat it as the lowest version currently supported.
> Ideally with a big fat warning

Ack, that's what I thought - taking the lowest supported version.

Comment 13 Yaniv Kaul 2018-03-15 14:06:37 UTC
Is this on track to 4.2.2? If not, please defer to 4.2.3.

Comment 14 Arik 2018-03-15 15:15:46 UTC
well, a fix for the NPE can make it to 4.2.2 but a proper fix should probably be postponed to 4.2.3

Comment 15 Yaniv Kaul 2018-04-11 10:19:51 UTC
(In reply to Arik from comment #14)
> well, a fix for the NPE can make it to 4.2.2 but a proper fix should
> probably be postponed to 4.2.3

Any updates?

Comment 16 Michal Skrivanek 2018-04-12 12:33:56 UTC
needs a bit more time, not that critical for 4.2.3

Comment 17 Yaniv Kaul 2018-05-31 12:34:18 UTC
(In reply to Michal Skrivanek from comment #16)
> needs a bit more time, not that critical for 4.2.3

Any updates?

Comment 18 Michal Skrivanek 2018-07-16 14:23:06 UTC
it doesn't seem important enough for 4.2.z. It's not a very common flow to import future versions into legacy environemnt

Comment 19 Liran Rotenberg 2018-12-25 07:23:09 UTC
Verified on:
ovirt-engine-4.2.8.1-0.1.el7ev.noarch
with ovirt-engine-4.3.0-0.6.alpha2.el7.noarch


Steps:
1. Had more than 50 VMs backup up to iSCSI domain's OVF_STORE and destroyed the domain.
2. Imported the domain to 4.3 DC (4.3 setup) and registered all the VMs
3. Destroyed the domain and imported it to a 4.2 DC in 4.2.8 setup
4. Registered all the VMs 

Results:
Import for the VMs succeed.
No exception in the engine log.

Comment 20 Sandro Bonazzola 2019-02-13 07:46:50 UTC
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.0 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.


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