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
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 ***
We can re-open this bug based on https://bugzilla.redhat.com/show_bug.cgi?id=1511037#c12
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?
Reopening to consider.
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
(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?)
Created attachment 1404287 [details] ovf <CustomCompatibilityVersion>4.2</CustomCompatibilityVersion><ClusterCompatibilityVersi on>4.1</ClusterCompatibilityVersion>
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.
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
(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
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
(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.
Is this on track to 4.2.2? If not, please defer to 4.2.3.
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
(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?
needs a bit more time, not that critical for 4.2.3
(In reply to Michal Skrivanek from comment #16) > needs a bit more time, not that critical for 4.2.3 Any updates?
it doesn't seem important enough for 4.2.z. It's not a very common flow to import future versions into legacy environemnt
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.
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.