Bug 1193643
Summary: | If Quotas are enabled, even in Audit mode, active VMs' disks cannot be edited | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Gordon Watson <gwatson> | |
Component: | ovirt-engine | Assignee: | Dudi Maroshi <dmaroshi> | |
Status: | CLOSED ERRATA | QA Contact: | Artyom <alukiano> | |
Severity: | high | Docs Contact: | ||
Priority: | medium | |||
Version: | 3.5.0 | CC: | amureini, dfediuck, dmaroshi, iheim, istein, juwu, lpeer, lsurette, mgoldboi, rbalakri, rgolan, Rhev-m-bugs, sherold, tnisan, yeylon, ykaul | |
Target Milestone: | ovirt-3.6.0-rc | Keywords: | Triaged, ZStream | |
Target Release: | 3.6.0 | Flags: | mgoldboi:
Triaged+
|
|
Hardware: | Unspecified | |||
OS: | Linux | |||
Whiteboard: | ||||
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.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1253142 (view as bug list) | Environment: | ||
Last Closed: | 2016-03-09 20:57:57 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | SLA | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1253142 |
Description
Gordon Watson
2015-02-17 19:40:03 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. 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 (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? 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. As commented elsewhere, default quota is not a viable option we will have. pending an u/s and 3.6.0 fix to move this to modify 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). Verified on rhevm-backend-3.6.0-0.12.master.el6.noarch 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 |