Bug 1560208

Summary: Resize disk: IO exception while processing "PUT" request for path /vms/%vm_id%/diskattachments/%disk_id% with a number too large for the size
Product: [oVirt] ovirt-engine Reporter: Elad <ebenahar>
Component: BLL.StorageAssignee: Allon Mureinik <amureini>
Status: CLOSED CURRENTRELEASE QA Contact: Yosi Ben Shimon <ybenshim>
Severity: low Docs Contact:
Priority: unspecified    
Version: 4.2.2CC: bugs, mperina, oliel, omachace, tnisan
Target Milestone: ovirt-4.2.3Keywords: Automation
Target Release: ---Flags: rule-engine: ovirt-4.2+
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-10 06:31:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
engine.log and server.log
none
engine.log and server.log none

Description Elad 2018-03-24 21:49:22 UTC
Description of problem:
A PUT request to /vms/%vm_id%/diskattachments/%disk_id% for resizing a disk to more than the domain capacity raises an ugly IO exception in engine.log


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


How reproducible:
Always

Steps to Reproduce:
1. Create a VM and attach a disk 
2. Try to resize the disk to more than the domain capacity:
(disk attachment update) - PUT to /vms/%vm_id%/diskattachments/%disk_id%


2018-03-25 00:38:23,922 - MainThread - diskattachments - DEBUG - PUT request content is --  url:/ovirt-engine/api/vms/b17f5183-9ab4-4c98-9bb1-623fffd2ac0e/diskattachments/c95d3309-bf12-4e27-b139-cab30585f129 bod
y:<disk_attachment>
    <disk>
        <alias>disk_TestCase5070_2500374230</alias>
        <provisioned_size>171785304187493941248</provisioned_size>
    </disk>
</disk_attachment>


Actual results:

REST API response is ok:


2018-03-25 00:38:24,658 - MainThread - api_utils - WARNING - Failed to update element as expected:
        Status: 400
        Reason: Bad Request
        Detail: For correct usage, see: https://storage-ge-02.scl.lab.tlv.redhat.com/ovirt-engine/apidoc#services/disk-attachment/methods/update

2018-03-25 00:38:24,658 - MainThread - diskattachments - DEBUG - Response code is valid: [400, 409, 500] 
2018-03-25 00:38:24,658 - MainThread - diskattachments - DEBUG - Response body for PUT request is: 
<fault>
    <detail>For correct usage, see: https://storage-ge-02.scl.lab.tlv.redhat.com/ovirt-engine/apidoc#services/disk-attachment/methods/update</detail>
    <reason>Request syntactically incorrect.</reason>
</fault>


But this exception is thrown in engine.log:


2018-03-24 22:24:45,902+03 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-52) [] EVENT_ID: USER_ADD_DISK_FINISHED_SUCCESS(2,021), The
 disk 'disk_TestCase5070_2422242961' was successfully added.
2018-03-24 22:24:46,890+03 INFO  [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default task-22) [diskattachments_create_0f43f252-bcbb] Lock Acquired to object 'EngineLock:{exclusiveLocks='[5323
b165-677c-417e-bae2-f5b5e900be1b=DISK]', sharedLocks=''}'
2018-03-24 22:24:46,980+03 INFO  [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default task-22) [diskattachments_create_0f43f252-bcbb] Running command: AttachDiskToVmCommand internal: false. En
tities affected :  ID: 78855750-2127-4ebe-b929-16aa2815cc9a Type: VMAction group CONFIGURE_VM_STORAGE with role type USER,  ID: 5323b165-677c-417e-bae2-f5b5e900be1b Type: DiskAction group ATTACH_DISK with role t
ype USER
2018-03-24 22:24:46,988+03 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand] (default task-22) [diskattachments_create_0f43f252-bcbb] START, HotPlugDiskVDSCommand(HostName = host_mixed_3, H
otPlugDiskVDSParameters:{hostId='8923c614-9ab0-4ec6-a154-7d0e111cc9f5', vmId='78855750-2127-4ebe-b929-16aa2815cc9a', diskId='5323b165-677c-417e-bae2-f5b5e900be1b', addressMap='null'}), log id: 6d1885d4
2018-03-24 22:24:50,719+03 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.HotPlugDiskVDSCommand] (default task-22) [diskattachments_create_0f43f252-bcbb] FINISH, HotPlugDiskVDSCommand, log id: 6d1885d4
2018-03-24 22:24:50,748+03 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-22) [diskattachments_create_0f43f252-bcbb] EVENT_ID: USER_ATTACH_DISK_TO_VM(2,016), Disk disk_TestCase5070_2422242961 was successfully attached to VM vm_TestCase5070_2422225393 by admin@internal-authz.
2018-03-24 22:24:50,749+03 INFO  [org.ovirt.engine.core.bll.storage.disk.AttachDiskToVmCommand] (default task-22) [diskattachments_create_0f43f252-bcbb] Lock freed to object 'EngineLock:{exclusiveLocks='[5323b165-677c-417e-bae2-f5b5e900be1b=DISK]', sharedLocks=''}'
2018-03-24 22:24:51,931+03 ERROR [org.ovirt.engine.api.restapi.resource.validation.IOExceptionMapper] (default task-30) [] IO exception while processing "PUT" request for path "/vms/78855750-2127-4ebe-b929-16aa2815cc9a/diskattachments/5323b165-677c-417e-bae2-f5b5e900be1b"
2018-03-24 22:24:51,931+03 ERROR [org.ovirt.engine.api.restapi.resource.validation.IOExceptionMapper] (default task-30) [] Exception: java.io.IOException: java.lang.NumberFormatException: For input string: "171785304187493941248"
        at org.ovirt.engine.api.restapi.xml.JAXBProvider.readFrom(JAXBProvider.java:200) [restapi-jaxrs.jar:]
        at org.ovirt.engine.api.restapi.xml.JAXBProvider.readFrom(JAXBProvider.java:162) [restapi-jaxrs.jar:]
        at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.readFrom(AbstractReaderInterceptorContext.java:66) [resteasy-jaxrs.jar:3.0.25.Final-redhat-1]
        at org.jboss.resteasy.core.interception.ServerReaderInterceptorContext.readFrom(ServerReaderInterceptorContext.java:61) [resteasy-jaxrs.jar:3.0.25.Final-redhat-1]
        at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:56) [resteasy-jaxrs.jar:3.0.25.Final-redhat-1]
        at org.jboss.resteasy.security.doseta.DigitalVerificationInterceptor.aroundReadFrom(DigitalVerificationInterceptor.java:36) [resteasy-crypto.jar:3.0.25.Final-redhat-1]
        at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:59) [resteasy-jaxrs.jar:3.0.25.Final-redhat-1]
        at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:151) [resteasy-jaxrs.jar:3.0.25.Final-redhat-1]
        at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:92) [resteasy-jaxrs.jar:3.0.25.Final-redhat-1]
        at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:115) [resteasy-jaxrs.jar:3.0.25.Final-redhat-1]
        at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs.jar:3.0.25.Final-redhat-1]
        at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs.jar:3.0.25.Final-redhat-1]


Expected results:
No exception

Additional info:
engine.log and server.log attached


For reproduction - Execute automation job - TC5070 over iSCSI

Comment 1 Elad 2018-03-24 22:09:35 UTC
Created attachment 1412609 [details]
engine.log and server.log

Comment 2 Tal Nisan 2018-03-25 06:24:26 UTC
Seems like it's a general scenario while inputting big numbers and their validation via the REST infrastructure, moving to infra for inspection

Comment 3 Allon Mureinik 2018-03-25 09:13:34 UTC
(In reply to Tal Nisan from comment #2)
> Seems like it's a general scenario while inputting big numbers and their
> validation via the REST infrastructure, moving to infra for inspection

Indeed.
The same behavior is observed when trying to update a VM's memory, e.g.:

PUT http://mureinik.localdomain:8080/ovirt-engine/api/vms/145d1e47-7a4c-4668-b70a-796378a7b947

BODY:
<vm>  
  <memory>171785304187493941248</memory>
</vm>

Comment 4 Martin Perina 2018-03-26 12:57:02 UTC
It seems to me that both VM memory and Disk size are defined as integers and not longs, that's why those errors are raise. Parsing HTPP content and storing those into model classes is performed in the RestEasy, Ondro/Ori is there any way how to return more descriptive error there

Comment 5 Yosi Ben Shimon 2018-04-25 14:38:45 UTC
Tested using:
ovirt-engine-4.2.3.2-0.1.el7.noarch

Two requests via REST-API:
1)
- url:
https://storage-ge-17.scl.lab.tlv.redhat.com/ovirt-engine/api/vms/3cb0d402-e5aa-4cb8-b9c9-b9cc8262fffb
- body:
<vm>  
  <memory>171785304187493941248</memory>
</vm>
- response:
<fault>
    <detail>Value 171785304187493941248 is greater than maximum long 9223372036854775807</detail>
    <reason>Invalid value</reason>
</fault>

2)
- url:
https://storage-ge-17.scl.lab.tlv.redhat.com/ovirt-engine/api/vms/3cb0d402-e5aa-4cb8-b9c9-b9cc8262fffb/diskattachments/536ea3d0-45f3-4679-8c9f-584bfbee186d
- body:
<disk_attachment>
    <disk>
        <alias>test_VM_Disk1</alias>
        <provisioned_size>171785304187493941248</provisioned_size>
    </disk>
</disk_attachment>
- response:
<fault>
    <detail>Value 171785304187493941248 is greater than maximum long 9223372036854775807</detail>
    <reason>Invalid value</reason>
</fault>

==========
No exceptions from engine side.

Moving to VERIFIED

Comment 6 Sandro Bonazzola 2018-05-10 06:31:16 UTC
This bugzilla is included in oVirt 4.2.3 release, published on May 4th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.3 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.