Bug 1803473

Summary: [RESTAPI] Failed to create a new disk with isVirtIoScsiValid ValidateFailure NPE in the engine log
Product: [oVirt] ovirt-engine Reporter: Yosi Ben Shimon <ybenshim>
Component: BLL.StorageAssignee: Tal Nisan <tnisan>
Status: CLOSED DUPLICATE QA Contact: Avihai <aefrat>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 4.4.0CC: bugs, mavital, michal.skrivanek, rbarry
Target Milestone: ---Keywords: AutomationBlocker, Regression, TestBlocker
Target Release: ---Flags: mavital: blocker?
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: 2020-02-17 16:32:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
logs none

Description Yosi Ben Shimon 2020-02-16 10:19:04 UTC
Created attachment 1663318 [details]
logs

Description of problem:
A lot of automation tests failed to create a disk with VirtIO-SCSI validation errors.

From ART log:
	Status: 500
	Reason: Internal Server Error
	Detail: [General command validation failure.]

From engine log (flooded by these errors/warnings):


2020-02-13 06:11:25,811+02 WARN  [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-44) [] Trying to release exclusive lock which does not exist, lock key: '34a6621a-a53f-4f6b-8044-79fa70905c5fVDS_INIT'

2020-02-13 06:11:26,031+02 ERROR [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default task-56) [disks_create_05fb0c13-c765-44ed] Error during ValidateFailure.: java.lang.NullPointerException
	at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.validator.storage.DiskVmElementValidator.isVirtIoScsiValid(DiskVmElementValidator.java:54)
	at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.storage.disk.AddDiskCommand.checkIfImageDiskCanBeAdded(AddDiskCommand.java:299)
	at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.storage.disk.AddDiskCommand.validate(AddDiskCommand.java:195)
	at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.internalValidate(CommandBase.java:804)
	at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:413)
	at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13)
	at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.Backend.runAction(Backend.java:451)


..... long trace .....

2020-02-13 06:11:26,036+02 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-56) [] Operation Failed: [General command validation failure.]


No errors/exceptions found in the VDSM logs.

Version-Release number of selected component (if applicable):
ovirt-engine-4.4.0-0.20.master.el7.noarch
vdsm-4.40.2-1.el8ev.x86_64
libvirt-6.0.0-4.module+el8.2.0+5642+838f3513.x86_64


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
All tests that tried to create a new disk failed.

Expected results:
The disks should be created successfully.

Additional info:
Attached logs from a sample test.
Might be related to the recent but regarding the VirtIO-SCSI interface disk attachment failure.

Comment 1 Avihai 2020-02-16 16:21:17 UTC
I see the same issue also with interface=virtio/virtio_scsi/sata/ide which make this issue more blocker as it happens on ALL interface types.

Also tried with format=cow/raw and sparse=true/false but still same error occurs.


Rest request I used which worked fine in prior build rhv-4.4.0.18/ovirt-engine-4.4.0-0.19 and now fails:

Method: POST

URL : https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/disks

Body:
<disk>
    <alias>disk_virtiocow_1212300070</alias>
    <bootable>false</bootable>
    <interface>virtio</interface>
    <format>cow</format>
    <provisioned_size>1073741824</provisioned_size>
    <shareable>false</shareable>
    <sparse>true</sparse>
    <wipe_after_delete>true</wipe_after_delete>
  <storage_domains>
    <storage_domain id="2bf0736f-65d1-412a-b1c4-664a1e74eab7"/>
  </storage_domains>
</disk>

Comment 2 Tal Nisan 2020-02-17 15:34:09 UTC
Michal, was this already fixed by the last fix in the area?

Comment 3 Ryan Barry 2020-02-17 16:32:21 UTC

*** This bug has been marked as a duplicate of bug 1798139 ***

Comment 4 Michal Skrivanek 2020-02-17 16:47:54 UTC
(In reply to Tal Nisan from comment #2)
> Michal, was this already fixed by the last fix in the area?

that one is waiting on your feedback - https://gerrit.ovirt.org/#/c/106794/