Bug 863101 - [RestAPI][direct lun] NPE when starting VM with direct lun (at org.ovirt.engine.core.bll.RunVmCommandBase.connectLunDisks(RunVmCommandBase.java:354) [engine-bll.jar:])
[RestAPI][direct lun] NPE when starting VM with direct lun (at org.ovirt.engi...
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
x86_64 Linux
urgent Severity urgent
: ---
: 3.1.0
Assigned To: Liron Aravot
: TestBlocker
Depends On:
  Show dependency treegraph
Reported: 2012-10-04 08:44 EDT by Jakub Libosvar
Modified: 2016-02-10 15:26 EST (History)
11 users (show)

See Also:
Fixed In Version: SI21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
engine log (12.73 KB, text/x-log)
2012-10-04 08:44 EDT, Jakub Libosvar
no flags Details
luns table (1.16 KB, application/octet-stream)
2012-10-04 08:59 EDT, Jakub Libosvar
no flags Details
screenshot-vm with lun (179.82 KB, image/png)
2012-10-07 06:08 EDT, Liron Aravot
no flags Details

  None (edit)
Description Jakub Libosvar 2012-10-04 08:44:27 EDT
Created attachment 621630 [details]
engine log

Description of problem:
When attempting to start VM that has attached direct lun, NPE occurs

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Attach direct lun to VM
2. Start VM
Actual results:

Expected results:

Additional info:
Backend log is attached, no relevant actions in vdsm
Blocks direct lun tests
Comment 1 Jakub Libosvar 2012-10-04 08:48:44 EDT
First two lines are storage domains, last one is direct lun

[root@jl-rhevm31 ~]# psql engine -U postgres -c "select * from luns;"
           physical_volume_id           |              lun_id               |            volume_group_id             |                             serial                             | 
lun_mapping | vendor_id | product_id | device_size 
 7ZfIzV-iXHb-6giT-oFgU-OnkF-XSMZ-fH6T5K | 36006048c14e9eb8f668dfc53ea5995ca | vLdoVE-kEX8-u92X-v7eL-7H2t-W411-9HHSuV | SEMC_Celerra_EMC-Celerra-iSCSI-VLU-fs62_T5_LUN7_CKM00120100230 |           7 | EMC       | Celerra    |         250
 9JQfWW-mHP0-geFO-OIlF-QxTy-joIJ-UFieQm | 36006048c0714062ba4b91f6a904bc07f | XjccnK-49dn-33V8-GAPT-kW1C-7ByJ-74X9mn | SEMC_Celerra_EMC-Celerra-iSCSI-VLU-fs75_T5_LUN4_CKM00120100230 |           4 | EMC       | Celerra    |          21
                                        | 36006048c12952607a6254682d950135a |                                        |                                                                |             |           |            |           0
Comment 2 Jakub Libosvar 2012-10-04 08:59:03 EDT
Created attachment 621632 [details]
luns table

Attaching psql output as a file so it's more readable
Comment 3 Itamar Heim 2012-10-04 09:01:23 EDT
please copy start of stack trace for easier bugzilla searches:
2012-10-04 14:12:31,353 ERROR [org.ovirt.engine.core.bll.RunVmOnceCommand] (ajp-/ [3e6868cf] Command org.ovirt.engine.core.bll.RunVmOnceCommand throw exception: java.lang.NullPointerException
	at org.ovirt.engine.core.bll.RunVmCommandBase.connectLunDisks(RunVmCommandBase.java:354) [engine-bll.jar:]
	at org.ovirt.engine.core.bll.RunVmCommand.RunVm(RunVmCommand.java:221) [engine-bll.jar:]
	at org.ovirt.engine.core.bll.RunVmCommand.ExecuteVmCommand(RunVmCommand.java:276) [engine-bll.jar:]
	at org.ovirt.engine.core.bll.VmCommand.executeCommand(VmCommand.java:83) [engine-bll.jar:]
Comment 6 Liron Aravot 2012-10-07 06:08:36 EDT
Created attachment 622951 [details]
screenshot-vm with lun
Comment 7 Liron Aravot 2012-10-07 06:09:41 EDT
doesn't reproduce on latest DS, tested with latest commit : 103b565425ceb516b52e8a10838497f6d539cf4f

Jakub, apperantly there is something wrong with your tests to lun disks regarding the lun connections, there was a similar bug that wan't reproducable by you as well through GUI last week or so, dunno what's going with the jenkins test but it seems to work just fine. please confirm.
i've attached in the previous comment a screenshot.
Comment 8 Jakub Libosvar 2012-10-08 03:33:26 EDT
It doesn't reproduce using GUI. 
First item is LUN created by API, second by GUI:

           physical_volume_id           |              lun_id               |            volume_group_id             |                             serial                              | lun_mapping | vendor_id | product_id | device_size 

                                        | 36006048c12952607a6254682d950135a |                                        |                                                                 |             |           |            |           0
 aPJ9z2-Q7dz-KW6D-OrcG-69Us-omfE-lSKxRV | 36006048ce7ff8320bd02378f18cf9712 |                                        | SEMC_Celerra_EMC-Celerra-iSCSI-VLU-fs78_T5_LUN18_CKM00120100230 |          18 | EMC       | Celerra    |          21

Disk was created using following body:
        <logical_unit id="36006048c12952607a6254682d950135a">

Now I'm not sure whether it's api's bug (don't pass parameters) or backend (allows creating LUN with insufficient parameters). CC'ing Michael.
Comment 9 Liron Aravot 2012-10-09 10:27:26 EDT
note that the issue was that the sent xml lacked the <type> tag in which the lun type needs to by specified.
a patch to return appropiate error in that case was sent:
Comment 10 Michael Pasternak 2012-10-09 10:30:54 EDT

Please make sure <type> marked as mandatory in RSDL for disks.add()
Comment 11 Jakub Libosvar 2012-10-10 02:58:29 EDT
Verified that VM can be started when <type> tag is in <lunStorage> element.
Comment 12 Allon Mureinik 2012-10-16 10:08:56 EDT
Merged I302b399fd93419fb1f621fd315b50d5971ae9c11
Comment 13 vvyazmin@redhat.com 2012-10-23 06:26:42 EDT
Verified on RHEVM 3.1 - SI21.1

RHEVM: rhevm-3.1.0-21.el6ev.noarch
VDSM: vdsm-4.9.6-38.0.el6_3.x86_64
LIBVIRT: libvirt-0.9.10-21.el6_3.5.x86_64
QEMU & KVM: qemu-kvm-rhev-
SANLOCK: sanlock-2.3-4.el6_3.x86_64

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