Bug 1292509 - It is possible to edit a disk using the api during LSM except the snapshot operation phase
Summary: It is possible to edit a disk using the api during LSM except the snapshot op...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 3.6.1.3
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-3.6.2
: 3.6.2.5
Assignee: Tal Nisan
QA Contact: Raz Tamir
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-17 15:58 UTC by Raz Tamir
Modified: 2016-02-18 11:15 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-18 11:15:24 UTC
oVirt Team: Storage
Embargoed:
rule-engine: ovirt-3.6.z+
ylavi: planning_ack+
tnisan: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)
engine and vdsm logs (375.20 KB, application/x-gzip)
2015-12-17 15:58 UTC, Raz Tamir
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 50803 0 master MERGED core: Disallow disk edit when it's in locked status 2015-12-27 13:04:13 UTC
oVirt gerrit 51088 0 ovirt-engine-3.6 MERGED core: Disallow disk edit when it's in locked status 2015-12-27 14:50:07 UTC
oVirt gerrit 51093 0 ovirt-engine-3.6.2 MERGED core: Disallow disk edit when it's in locked status 2015-12-27 14:55:51 UTC

Description Raz Tamir 2015-12-17 15:58:14 UTC
Created attachment 1106763 [details]
engine and vdsm logs

Description of problem:
I'm trying to edit a disk during a live storage migration and I noticed that I can do that if the snapshot operation (that is part of live storage migration) didn't started yet or already finished but the disk is still locked.

From engine.log:
2015-12-16 23:25:51,647 INFO  [org.ovirt.engine.core.bll.MoveDisksCommand] (ajp-/127.0.0.1:8702-1) [disks_syncAction_31fcbdca-8271-487f] Running command: MoveDisksCommand internal: false. Entities affected :  ID: 4fcb3acc-6b7a-4a34-a0d2-11ab30bb3cee Type: DiskAction group CONFIGURE_DISK_STORAGE with role type USER
2015-12-16 23:25:51,671 INFO  [org.ovirt.engine.core.bll.lsm.LiveMigrateVmDisksCommand] (ajp-/127.0.0.1:8702-1) [disks_syncAction_31fcbdca-8271-487f] Lock Acquired to object 'EngineLock:{exclusiveLocks='[4fcb3acc-6b7a-4a34-a0d2-11ab30bb3cee=<DISK, ACTION_TYPE_FAILED_DISK_IS_BEING_MIGRATED$DiskName disk_11864>]', sharedLocks='[b9d619e8-cff1-47b8-8181-771a7c707f9d=<VM, ACTION_TYPE_FAILED_OBJECT_LOCKED>]'}'
2015-12-16 23:25:51,808 INFO  [org.ovirt.engine.core.bll.lsm.LiveMigrateVmDisksCommand] (org.ovirt.thread.pool-7-thread-40) [disks_syncAction_31fcbdca-8271-487f] Running command: LiveMigrateVmDisksCommand Task handler: LiveSnapshotTaskHandler internal: false. Entities affected :  ID: 4fcb3acc-6b7a-4a34-a0d2-11ab30bb3cee Type: DiskAction group DISK_LIVE_STORAGE_MIGRATION with role type USER
2015-12-16 23:25:51,872 INFO  [org.ovirt.engine.core.bll.CreateAllSnapshotsFromVmCommand] (org.ovirt.thread.pool-7-thread-40) [303da457] Running command: CreateAllSnapshotsFromVmCommand internal: true. Entities affected :  ID: b9d619e8-cff1-47b8-8181-771a7c707f9d Type: VMAction group MANIPULATE_VM_SNAPSHOTS with role type USER
2015-12-16 23:25:51,879 INFO  [org.ovirt.engine.core.bll.CreateSnapshotCommand] (org.ovirt.thread.pool-7-thread-40) [4e780d2c] Running command: CreateSnapshotCommand internal: true. Entities affected :  ID: 00000000-0000-0000-0000-000000000000 Type: Storage
2015-12-16 23:25:51,936 INFO  [org.ovirt.engine.core.vdsbroker.irsbroker.CreateSnapshotVDSCommand] (org.ovirt.thread.pool-7-thread-40) [4e780d2c] START, CreateSnapshotVDSCommand( CreateSnapshotVDSCommandParameters:{runAsync='true', storagePoolId='b798a3c9-c3dd-43f3-b277-765783234b08', ignoreFailoverLimit='false', storageDomainId='97cc2b73-d176-40a0-b3b7-1994dcd9e0ac', imageGroupId='4fcb3acc-6b7a-4a34-a0d2-11ab30bb3cee', imageSizeInBytes='5368709120', volumeFormat='COW', newImageId='188d3c36-0ddc-4b2d-8d8f-5deb4106dad7', newImageDescription='', imageInitialSizeInBytes='0', imageId='c9e80756-98d8-4427-82ea-f7d703971e04', sourceImageGroupId='4fcb3acc-6b7a-4a34-a0d2-11ab30bb3cee'}), log id: 6e7a0aa5
2015-12-16 23:25:51,938 INFO  [org.ovirt.engine.core.vdsbroker.irsbroker.CreateSnapshotVDSCommand] (org.ovirt.thread.pool-7-thread-40) [4e780d2c] -- executeIrsBrokerCommand: calling 'createVolume' with two new parameters: description and UUID
2015-12-16 23:25:52,632 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] (ajp-/127.0.0.1:8702-9) [disks_update_d77450d0-a889-49b7] Lock Acquired to object 'EngineLock:{exclusiveLocks='null', sharedLocks='[b9d619e8-cff1-47b8-8181-771a7c707f9d=<VM, ACTION_TYPE_FAILED_VM_IS_LOCKED>]'}'
2015-12-16 23:25:52,640 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] (ajp-/127.0.0.1:8702-9) [disks_update_d77450d0-a889-49b7] Running command: UpdateVmDiskCommand internal: false. Entities affected :  ID: 4fcb3acc-6b7a-4a34-a0d2-11ab30bb3cee Type: DiskAction group EDIT_DISK_PROPERTIES with role type USER
2015-12-16 23:25:52,671 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] (ajp-/127.0.0.1:8702-9) [disks_update_d77450d0-a889-49b7] Lock freed to object 'EngineLock:{exclusiveLocks='null', sharedLocks='[b9d619e8-cff1-47b8-8181-771a7c707f9d=<VM, ACTION_TYPE_FAILED_VM_IS_LOCKED>]'}'
2015-12-16 23:25:52,680 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-9) [disks_update_d77450d0-a889-49b7] Correlation ID: disks_update_d77450d0-a889-49b7, Call Stack: null, Custom Event ID: -1, Message: VM wipe_after_delete_vm_iscsi disk_11864 disk was updated by admin@internal.
2015-12-16 23:25:53,057 INFO  [org.ovirt.engine.core.vdsbroker.irsbroker.CreateSnapshotVDSCommand] (org.ovirt.thread.pool-7-thread-40) [4e780d2c] FINISH, CreateSnapshotVDSCommand, return: 188d3c36-0ddc-4b2d-8d8f-5deb4106dad7, log id: 6e7a0aa5
2015-12-16 23:25:53,060 INFO  [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (org.ovirt.thread.pool-7-thread-40) [4e780d2c] CommandAsyncTask::Adding CommandMultiAsyncTasks object for command 'fab60fa7-12a3-4c8e-b137-d68a16e8a54c'
2015-12-16 23:25:53,060 INFO  [org.ovirt.engine.core.bll.CommandMultiAsyncTasks] (org.ovirt.thread.pool-7-thread-40) [4e780d2c] CommandMultiAsyncTasks::AttachTask: Attaching task 'bfe019ce-b770-42b7-801e-f4ecb0c2c75e' to command 'fab60fa7-12a3-4c8e-b137-d68a16e8a54c'.
2015-12-16 23:25:53,068 INFO  [org.ovirt.engine.core.bll.tasks.AsyncTaskManager] (org.ovirt.thread.pool-7-thread-40) [4e780d2c] Adding task 'bfe019ce-b770-42b7-801e-f4ecb0c2c75e' (Parent Command 'LiveMigrateVmDisks', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters'), polling hasn't started yet..
2015-12-16 23:25:53,123 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-7-thread-40) [4e780d2c] Correlation ID: 303da457, Job ID: 2fa48cea-e65c-472a-9be3-402d650c55fc, Call Stack: null, Custom Event ID: -1, Message: Snapshot 'Auto-generated for Live Storage Migration' creation for VM 'wipe_after_delete_vm_iscsi' was initiated by admin@internal.
2015-12-16 23:25:53,138 INFO  [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (org.ovirt.thread.pool-7-thread-40) [4e780d2c] BaseAsyncTask::startPollingTask: Starting to poll task 'bfe019ce-b770-42b7-801e-f4ecb0c2c75e'.

Version-Release number of selected component (if applicable):
rhevm-3.6.1.3-0.1.el6.noarch
vdsm-4.17.13-1.el7ev.noarch

How reproducible:
100%

Steps to Reproduce:
1. Live  migrate vm's disk
2. using rest command try to edit the disk (example in 'Additional info')
3.

Actual results:
The operation succeeds


Expected results:


Additional info:
PUT command on api/vms/35e4a02a-86c7-4f01-9725-86e0b33512f7/disks/ccc15eaf-dac8-4062-8168-897747591031

with body:
<disk>
    <wipe_after_delete>true</wipe_after_delete>
</disk>

Comment 1 Allon Mureinik 2015-12-21 07:43:40 UTC
For some obscure reason, I can't see anything about the disk's status in the canDoAction method.
Weird.

Tal, as this week's QA contact, please take a look/.

Comment 2 Red Hat Bugzilla Rules Engine 2015-12-21 07:53:45 UTC
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.

Comment 3 Tal Nisan 2015-12-21 12:33:58 UTC
Very strange indeed, the only validation on the disk status was done in the user/admin portals, no such validation exist in the command itself

Comment 4 Raz Tamir 2016-01-17 15:15:27 UTC
Verified on rhevm-3.6.2.5-0.1.el6.noarch

Comment 5 Raz Tamir 2016-01-17 15:16:18 UTC
Verified on rhevm-3.6.2.5-0.1.el6.noarch


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