Bug 969641
| Summary: | PRD34 - [RFE] Able to detach the ISO domain from the DataCenter though iso is attached and mounted in the VM | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Udayendu Sekhar Kar <ukar> |
| Component: | ovirt-engine | Assignee: | Maor <mlipchuk> |
| Status: | CLOSED ERRATA | QA Contact: | Aharon Canan <acanan> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.1.0 | CC: | acanan, acathrow, amureini, ebenahar, iheim, jkt, lpeer, mlipchuk, Rhev-m-bugs, rpai, scohen, sputhenp, tpoitras, ukar, yeylon |
| Target Milestone: | --- | Keywords: | FutureFeature, Improvement |
| Target Release: | 3.4.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | storage | ||
| Fixed In Version: | av2 | Doc Type: | Enhancement |
| Doc Text: |
Previously, you could put an ISO domain into maintenance even if there was an ISO image attached to a virtual machine.
Now, attempting to put an ISO domain to maintenance while a virtual machine has an attached ISO image (not from Run-once) is blocked by an error message, and the operation is canceled.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-09 14:59:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1014039 | ||
| Bug Blocks: | 1078909, 1142926 | ||
|
Description
Udayendu Sekhar Kar
2013-06-01 09:17:51 UTC
can we get engine + VDS logs (SOS)? We should add a warning message when deactivating the ISO storage domain We should check if all the vms in the Data Center has empty path in the cdrom vm_device. SELECT type,device,spec_params FROM vm_device where device='cdrom' and type='disk'; If the path is empty then we can detach the ISO domain, if not we should present a warning. Take in notice that there is a bug that when user ejects the CD of the running VM, VDSM still reports the device is attached. Even when the ISO will be moved to maintenance the VM should still see the ISO path, since it is already mounted in the host. The fix prints an audit log when deactivating ISO domain, only if the VM uses this ISO file. The indication whether the VM uses this is file is if in the DB the vm deivce of the disk of the floppy has a non-empty path. Maor, update on this? patch is stale upstream. Yes, I have talked with Omer yesterday about it, and this bug is actually blocked on another bug I'm looking at right now. The other bug, is that VDSM reports the engine that the VM has still attached ISO file although the user has already removed the CD from the VM. If we will block detaching ISO domain with a CDA, that will just make the user angry since from his perspective he already removed the ISO cd from the VM and still can't detach the ISO. So this could be handled in two ways: 1) We can use an audit log warning for now (as implemented in posted patch), so we won't block the user, until that bug will be fixed. 2) Find/Open the VDSM bug and just block it on this one. (ether way, there should be a bug on it) (In reply to Maor from comment #10) > Yes, I have talked with Omer yesterday about it, and this bug is actually > blocked on another bug I'm looking at right now. > The other bug, is that VDSM reports the engine that the VM has still > attached ISO file although the user has already removed the CD from the VM. I have managed to check it with vdsm-4.12.0-131 and this bug did not reproduced, So I'm changing the patch to use CDA validation instead or warnning. > > If we will block detaching ISO domain with a CDA, that will just make the > user angry since from his perspective he already removed the ISO cd from the > VM and still can't detach the ISO. > > So this could be handled in two ways: > 1) We can use an audit log warning for now (as implemented in posted patch), > so we won't block the user, until that bug will be fixed. > 2) Find/Open the VDSM bug and just block it on this one. (ether way, there > should be a bug on it) Fix for BZ1014039 has been merged upstream, the bug is not longer blocked Keep in mind, there is still an issue when starting a VM with run once. Since there is no persistence in the DB of the iso file. The current_cd in vm_dynamic should be changed when the VM is starting up. (In reply to Maor from comment #15) > Keep in mind, there is still an issue when starting a VM with run once. > Since there is no persistence in the DB of the iso file. The current_cd in > vm_dynamic should be changed when the VM is starting up. opened a bug https://bugzilla.redhat.com/1065719 This bug is referenced in ovirt-engine-3.4.0-beta3 logs. Moving to ON_QA Putting ISO domain to maintenance while there is an ISO attached to VM (not from Run-once) is blocked with the following error message on UI: Operation Canceled Error while executing action: Cannot deactivate Storage. The ISO Storage Domain is being used by the following VMs: dc1-1. CDA failure in engine.log: 2014-03-30 17:59:42,273 WARN [org.ovirt.engine.core.bll.storage.DeactivateStorageDomainCommand] (ajp-/127.0.0.1:8702-9) [254b18e2] CanDoAction of action DeactivateStorageDomain failed. Reasons:VAR__TYPE__STORAGE__DOMAIN,VAR__ACTION__DEACTIVATE,ERROR_CANNOT_DEACTIVATE_STORAGE_DOMAIN_WITH_ISO_ATTACHED,$VmNames dc1-1 ============ Steps to reproduce: On a shared DC with ISO domain attached and active: 1) Run a VM 2) 'Change CD' to the VM - attach an ISO to it 3) Put the ISO domain to maintenance ============ Still, due to: https://bugzilla.redhat.com/show_bug.cgi?id=1065719, putting ISO domain to maintenance while an ISO is attached to a VM from Run-once isn't blocked. =========== Link to TCMS run: https://tcms.engineering.redhat.com/run/123142/ 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. http://rhn.redhat.com/errata/RHSA-2014-0506.html |