Bug 1193643 - If Quotas are enabled, even in Audit mode, active VMs' disks cannot be edited
Summary: If Quotas are enabled, even in Audit mode, active VMs' disks cannot be edited
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: Unspecified
OS: Linux
medium
high
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Dudi Maroshi
QA Contact: Artyom
URL:
Whiteboard:
Depends On:
Blocks: 1253142
TreeView+ depends on / blocked
 
Reported: 2015-02-17 19:40 UTC by Gordon Watson
Modified: 2019-07-16 11:33 UTC (History)
16 users (show)

Fixed In Version: 3.6.0-10
Doc Type: Bug Fix
Doc Text:
Previously, if a quota mode was enabled on a data center, editing an existing disk of a running virtual machine always failed. With this update, the default quota value for an existing disk is no longer set to null but set to the current value. A wrong quota change is no longer detected for an existing disk, and editing disks on a running virtual machine works as expected.
Clone Of:
: 1253142 (view as bug list)
Environment:
Last Closed: 2016-03-09 20:57:57 UTC
oVirt Team: SLA
mgoldboi: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
oVirt gerrit 44768 master MERGED core: Allow VM disks editing after enabling quota on data center Never
oVirt gerrit 44769 ovirt-engine-3.6 MERGED core: Allow VM disks editing after enabling quota on data center Never
Red Hat Knowledge Base (Solution) 1351393 None None None Never

Description Gordon Watson 2015-02-17 19:40:03 UTC
Description of problem:

If Quotas are enabled, whether in Audit or Enforced mode, and a quota is created, then a virtual disk cannot be edited while the VM is running unless it has already been edited after the quota was created while the VM was down.

It will fail with "Cannot edit Virtual Machine Disk. At least one of the VMs is not down.". 

The engine log will show "ACTION_TYPE_FAILED_VM_IS_NOT_DOWN".



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

RHEV 3.5


How reproducible:

Every time.


Steps to Reproduce:

1. Create a VM that has one disk and start it.
2. Enable Quotas in that DC.
3. Create a quota.
4. Highlight the VM, select 'Disks' tab and 'Edit'.
5. Modify the 'Extend size by' value or 'Alias' name.
6. Hit 'OK'.
7. "Cannot edit Virtual Machine Disk. At least one of the VMs is not down." will be reported.

Then just to prove the point;

8. Create a second disk.
9. Try to edit this disk. It will be successful.


Actual results:

VM cannot be edited after Quotas have been enabled and a quota created if the VM is up and the disks have not been edited since the quota was created.


Expected results:

The disk should be able to be edited.

Additional info:

Comment 3 Eyal Edri 2015-04-28 11:23:30 UTC
moving to 3.5.4 due to capacity planning for 3.5.3.
if you believe this should remain in 3.5.3, please sync with pm/dev/qe and a full triple ack for it. also - ensure priority is set accordingly to the bug status.

Comment 4 Dudi Maroshi 2015-07-22 13:12:48 UTC
Reconstructed the bug in RHEV 3.5
Failed reconstructing the bug in RHEV 3.6

Please advise if we want to solve the bug in RHEV 3.5

Comment 5 Doron Fediuck 2015-07-22 14:47:52 UTC
(In reply to Dudi Maroshi from comment #4)
> Reconstructed the bug in RHEV 3.5
> Failed reconstructing the bug in RHEV 3.6
> 
> Please advise if we want to solve the bug in RHEV 3.5

How big / invasive / risky is the fix?

Comment 6 Dudi Maroshi 2015-07-23 16:10:28 UTC
Investigated the bug:

Diagnostics:
------------
1. UpdateVmDiskCommand is testing in the canDoAction method that:
   If the disk is connected to a running VM then
      If disk is of type IMAGE and the quota changed
          fail command. Report ACTION_TYPE_FAILED_VM_IS_NOT_DOWN
      End if
   End if

2. quota change is tested by comparing recent quota ID (from database) with current ID

If quota enabled on data center. For all existing disks. The recent quota is always null. But the current quota is arbitrary the first in the list box.

Therefore when enabling quota on existing disks. They are no longer editable.

Suggested solution:
-------------------
Long term, solving bug 1245931 will solve this correctly.

Short term, assume if recent quota is null, there is no quota change. Will allow block disk update after quota applied.



As for RHEV 3.6 a broken fix for bug 1185826. Fails the test for disk is of type IMAGE or CINDER. Therefore quota change is never tested.


Posted temporary fix for RHEV 3.5
What to do about RHEV 3.6:
1. Fix bug 1185826, masking the problem found in RHEV 3.5
2. Fix problem cause, bug 1245931 in both RHEV versions.

Comment 7 Doron Fediuck 2015-08-03 11:03:54 UTC
As commented elsewhere, default quota is not a viable option we will have.

Comment 8 Roy Golan 2015-08-11 07:29:47 UTC
pending an u/s and 3.6.0 fix to move this to modify

Comment 9 Dudi Maroshi 2015-08-11 16:48:54 UTC
In reply to comment 5, the tech answer is in comment 6.
Was fixed for ovirt 3.5.z. 
Pending decision if we want to address the root cause in master and 3.6.

Currently in ovirt 3.6. The problem is not present due to wrong fix to bug 1185826.
The easiest and fastest is to fix bug 1185826, and apply the fix done for 3.5.z. Very simple fix. The problem cause will remain just bypassed.

The long term solution is to have a defined policy for for dealing with (new vm-disk and existing vm-disk) after (enabling/disabling quota).

Comment 11 Artyom 2015-09-01 12:03:16 UTC
Verified on rhevm-backend-3.6.0-0.12.master.el6.noarch

Comment 15 errata-xmlrpc 2016-03-09 20:57:57 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0376.html


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