Bug 1288366 - NPE when moving a LUN disk in REST API
NPE when moving a LUN disk in REST API
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-sdk-python (Show other bugs)
3.3.0
x86_64 Linux
low Severity medium
: ovirt-3.6.0-rc
: 3.6.0
Assigned To: Vered Volansky
Aharon Canan
:
Depends On: 1126425
Blocks: 1147860
  Show dependency treegraph
 
Reported: 2015-12-04 00:43 EST by JINKOO HAN
Modified: 2016-03-10 07:04 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1126425
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pm-rhel: requirements_defined+
pm-rhel: testing_beta_priority+
pm-rhel: testing_plan_complete+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 45361 None None None Never
oVirt gerrit 45776 None None None Never
oVirt gerrit 45805 None None None Never

  None (edit)
Description JINKOO HAN 2015-12-04 00:43:30 EST
Is it possible to back-port to REHV 3.3?


+++ This bug was initially created as a clone of Bug #1126425 +++

Description of problem:
When moving a LUN disk attached to a VM using REST API - getting NPE.
The same scenario with a floating disk should also result in an NPE, as well as copy disk.


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


How reproducible:
100%

Steps to Reproduce:
1. Move a LUN disk, example:
http://localhost:8080/api/vms/5b1ee280-4251-489a-899c-8e9dac73c327/disks/bdca3776-6597-4323-84f1-4ea75f7d269d/move
POST

Body:
<action>
    <storage_domain id="7158eae9-4886-4af7-af0b-d668ecee9e4f"/>
</action>
2. NPE

Actual results:
NPE

Expected results:
CDA message

Additional info:
There was always an NPE in this unreasonable scenario.
BackendVmDiskResource.move()
BackendDiskResource.move()
BackendDiskResource.copy()

Both try to extract guid from imageId, which is null:
Guid imageId = asGuid(getDisk().getImageId()); //(BackendVmDiskResource)
Guid imageId = asGuid(get().getImageId()); //(BackendDiskResource X 2)

--- Additional comment from Allon Mureinik on 2014-08-27 13:00:53 EDT ---

The operation should fail in any event, just with a better error than NPE. Pushing out to 3.5.1

--- Additional comment from Allon Mureinik on 2014-09-18 06:21:22 EDT ---

This requires moving around a LOT of code, for a small benefit.
Pushing out to 3.6.0.

Idan - please create a tracker and open bugs for the similar issues we have in other Disks actions.
Thanks.

--- Additional comment from Idan Shaby on 2014-09-30 04:59:31 EDT ---

Tracking - Bug 1147860.

VM LUN disks:
Export - Bug 1147861.
Move - Bug 1147863.

LUN disks:
Export - Bug 1147870
Move - Bug 1147873
Copy - Bug 1147874

--- Additional comment from Carlos Mestre González on 2015-09-22 06:59:28 EDT ---

<fault>
<reason>Operation Failed</reason>
<detail>
[Cannot move Virtual Machine Disk. Action is unsupported for the specified disk type (LUN).]
</detail>

version: 3.6.0-13

--- Additional comment from Sandro Bonazzola on 2015-11-04 06:29:25 EST ---

oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.
Comment 2 Allon Mureinik 2015-12-04 02:45:46 EST
Setting this bug as VERIFIED, based on Carlos' work described in https://bugzilla.redhat.com/show_bug.cgi?id=1126425#c4.

When RHEV (as opposed to oVirt) 3.6 is released, this bug should be set to CLOSED CURRENTRELEASE.
Comment 4 Allon Mureinik 2016-03-10 05:44:27 EST
RHEV 3.6.0 has been released, setting status to CLOSED CURRENTRELEASE
Comment 5 Allon Mureinik 2016-03-10 05:48:21 EST
RHEV 3.6.0 has been released, setting status to CLOSED CURRENTRELEASE
Comment 6 Allon Mureinik 2016-03-10 07:04:52 EST
RHEV 3.6.0 has been released, setting status to CLOSED CURRENTRELEASE

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