Bug 1489795 - Importing a VM from 3.6 fails due to NPE @ org.ovirt.engine.core.bll.network.VmInterfaceManager.removeAll
Summary: Importing a VM from 3.6 fails due to NPE @ org.ovirt.engine.core.bll.network....
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: 4.1.4.2
Hardware: Unspecified
OS: Unspecified
unspecified
high vote
Target Milestone: ovirt-4.1.7
: 4.1.7.1
Assignee: Arik
QA Contact: Nisim Simsolo
URL:
Whiteboard:
: 1525216 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-08 11:56 UTC by Petr Matyáš
Modified: 2017-12-14 09:33 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-13 12:28:52 UTC
oVirt Team: Virt
tjelinek: ovirt-4.1?
rule-engine: blocker?
tjelinek: planning_ack?
tjelinek: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)
engine log (453.72 KB, text/plain)
2017-09-08 11:56 UTC, Petr Matyáš
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 81600 0 ovirt-engine-4.1 POST core: prevent NPE when import VM fails 2017-09-10 16:29:01 UTC
oVirt gerrit 81601 0 master POST core: prevent NPE when import VM fails 2017-09-10 16:34:59 UTC

Description Petr Matyáš 2017-09-08 11:56:42 UTC
Created attachment 1323707 [details]
engine log

Description of problem:
Having a VM from 3.6 without any snapshots, I'm unable to import the VM in 4.1 setup. Copy disk action of VM import task fails, however the import task keeps running, apparently forever.

Version-Release number of selected component (if applicable):
ovirt-engine-4.1.4.2-0.1.el7.noarch

How reproducible:
always

Steps to Reproduce:
1. setup a VM in 3.6 engine
2. export the VM
3. import the VM in 4.1 engine

Actual results:
VM import task keeps running forever although copy disk failed

Expected results:
VM is imported

Additional info:
there is NPE at the end of engine log

Comment 1 Michal Skrivanek 2017-09-09 15:58:05 UTC
please check any recent changes and reassign to network if needed. Thanks!

Comment 2 Yaniv Kaul 2017-09-10 09:13:17 UTC
Petr, did you notice the exception?
328ccdecbb07, Job ID: 85f52fb7-1565-4ba3-a801-54dd86293db2, Call Stack: null, Custom Event ID: -1, Message: Failed to import Vm pmatyas-engine40-1 to Data Center dc01, Cluster cl01
2017-09-08 13:40:24,026+02 ERROR [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (org.ovirt.thread.pool-6-thread-38) [] [within thread]: endAction for action type ImportVm threw an exception.: java.lang.NullPointerException
	at org.ovirt.engine.core.bll.network.VmInterfaceManager.removeAll(VmInterfaceManager.java:135) [bll.jar:]
	at org.ovirt.engine.core.bll.exportimport.ImportVmCommand.removeVmNetworkInterfaces(ImportVmCommand.java:1153) [bll.jar:]
	at org.ovirt.engine.core.bll.exportimport.ImportVmCommand.endWithFailure(ImportVmCommand.java:1121) [bll.jar:]
	at org.ovirt.engine.core.bll.CommandBase.internalEndWithFailure(CommandBase.java:768) [bll.jar:]
	at org.ovirt.engine.core.bll.CommandBase.endActionInTransactionScope(CommandBase.java:697) [bll.jar:]
	at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:2057) [bll.jar:]
	at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:202) [utils.jar:]
	at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInRequired(TransactionSupport.java:137) [utils.jar:]
	at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:105) [utils.jar:]
	at org.ovirt.engine.core.bll.CommandBase.endAction(CommandBase.java:559) [bll.jar:]
	at org.ovirt.engine.core.bll.tasks.DecoratedCommand.endAction(DecoratedCommand.java:17) [bll.jar:]
	at org.ovirt.engine.core.bll.tasks.CoCoAsyncTaskHelper.endAction(CoCoAsyncTaskHelper.java:337) [bll.jar:]
	at org.ovirt.engine.core.bll.tasks.CommandCoordinatorImpl.endAction(CommandCoordinatorImpl.java:340) [bll.jar:]
	at org.ovirt.engine.core.bll.tasks.CommandAsyncTask.endCommandAction(CommandAsyncTask.java:154) [bll.jar:]
	at org.ovirt.engine.core.bll.tasks.CommandAsyncTask.lambda$endActionIfNecessary$0(CommandAsyncTask.java:106) [bll.jar:]
	at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalWrapperRunnable.run(ThreadPoolUtil.java:84) [utils.jar:]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
	at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]

Comment 3 Petr Matyáš 2017-09-11 08:17:12 UTC
Yes, I did, but what is it exactly that you are asking?

Comment 4 Petr Matyáš 2017-09-11 08:19:13 UTC
Putting needinfo back

Comment 5 Yaniv Kaul 2017-09-11 09:13:33 UTC
(In reply to Petr Matyáš from comment #4)
> Putting needinfo back

1. I've fixed the title for you.
2. If you see a stack trace, please add it to the bug. For two reasons:
- It allows to faster pinpoint where the issue may be.
- It allows to search for duplicates.

Comment 6 Michal Skrivanek 2017-09-11 13:55:14 UTC
Arik, the bug is filed on 4.1, is there really no need for that fix in 4.1 as your abandoned patch indicates?

Comment 7 Arik 2017-09-12 08:15:59 UTC
(In reply to Michal Skrivanek from comment #6)
> Arik, the bug is filed on 4.1, is there really no need for that fix in 4.1
> as your abandoned patch indicates?

The fix is needed in 4.1 as well.

Comment 8 Tomas Jelinek 2017-09-12 09:59:43 UTC
targeting accordingly

Comment 9 Red Hat Bugzilla Rules Engine 2017-09-12 09:59:49 UTC
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

Comment 10 Nisim Simsolo 2017-09-25 13:16:40 UTC
Verification builds:
rhevm-4.1.7.1-0.1.el7
vdsm-4.17.43-1.el7ev.noarch
qemu-kvm-rhev-2.6.0-28.el7_3.9.x86_64
sanlock-3.5.0-1.el7.x86_64
libvirt-client-3.2.0-14.el7.x86_64

Verification scenario:
1. Create VM in 3.6 engine (rhv-3.6.12-4).
2. Export VM to export domain.
3. Detach export domain from 3.6 setup and attach it to 4.1 setup.
4. Import VM (normally and as clone).
5. In both cases verify VM imported successfully and VM is running properly.

Comment 11 Tomas Jelinek 2017-12-14 09:33:56 UTC
*** Bug 1525216 has been marked as a duplicate of this bug. ***


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