Created attachment 961094 [details] logs from the host and from the engine Description of problem: While testing the fix of https://bugzilla.redhat.com/show_bug.cgi?id=1157238, which adds Hosted Engine disk to the engine as direct lun in order to allow the engine to know about the LUN used by Hosted engine, I checked if the LUN is allowed to be deleted from the setup and it does. Version-Release number of selected component (if applicable): rhev 3.5 vt11 ovirt-hosted-engine-ha-1.2.4-1.el7.noarch ovirt-hosted-engine-setup-1.2.1-4.el7ev.noarch How reproducible: Always Steps to Reproduce: 1. Deploy hosted engine usind iSCSI storage 2. Once the hosted engine is up, access it and navigate to 'Disks' main tab. There should be the device which is being used by the engine's VM, it should be listed as a direct LUN 3. Try to remove the device Actual results: Removing the device is allowed. 2014-11-25 08:56:49,208 INFO [org.ovirt.engine.core.bll.RemoveDiskCommand] (org.ovirt.thread.pool-7-thread-9) [40cbf672] Running command: RemoveDiskCommand internal: false. Entities affected : ID: e8f0a0e7-3d81-45e4-a347-5ab04a5c7aea Type: DiskAction group DELETE_DISK with role type USER Expected results: Performing operations on this disk should not be allowed since this disk existence supposed to block user from doing operations like: - import the hosted-engine's storage domain - put the iSCSI domain in maintenance while the hosted-engine is installed on it - pick the lun for storage domain creation/extension Additional info: logs from the host and from the engine
Sandro, how is the engine supposed to know which Direct LUN is the HE?
It has image alias 'hosted_engine'
For reference: http://gerrit.ovirt.org/34782
Seems like an easy fix then. Tal, can we bang out a quick-and-dirty patch please?
Done, not as dirty as you'd expect :)
Btw, I considered doing a frontend patch that will grey out the edit/attach/remove on the HE disk but then I figured it might be confusing to the user since no explanation is given there and it's better in the rare case that someone tries to run an disallowed option to have a reason coming back from the engine
(In reply to Tal Nisan from comment #6) > Btw, I considered doing a frontend patch that will grey out the > edit/attach/remove on the HE disk but then I figured it might be confusing > to the user since no explanation is given there and it's better in the rare > case that someone tries to run an disallowed option to have a reason coming > back from the engine Agreed. Einav - can you ack/nack this decision from a UX perspective?
(In reply to Allon Mureinik from comment #7) > (In reply to Tal Nisan from comment #6) > > Btw, I considered doing a frontend patch that will grey out the > > edit/attach/remove on the HE disk but then I figured it might be confusing > > to the user since no explanation is given there and it's better in the rare > > case that someone tries to run an disallowed option to have a reason coming > > back from the engine > Agreed. > Einav - can you ack/nack this decision from a UX perspective? ack - this is consistent with various other parts of the GUI.
The direct LUN, used for identifying the hosted-engine disk, is not allowed to be removed/attached to VM Remove: 2014-12-16 09:26:08,668 WARN [org.ovirt.engine.core.bll.RemoveDiskCommand] (ajp-/127.0.0.1:8702-4) [43487008] CanDoAction of action RemoveDisk failed. Reasons:VAR__ACTION__REMOVE,VAR__TYPE__VM_DISK,ACTION_TYPE_FAILED_HOSTED_ENGINE_DISK Attach to VM 2014-12-16 09:27:39,630 WARN [org.ovirt.engine.core.bll.AttachDiskToVmCommand] (ajp-/127.0.0.1:8702-8) [47a7337b] CanDoAction of action AttachDiskToVm failed. Reasons:VAR__ACTION__ATTACH_ACTION_TO,VAR__TYPE__VM_DISK,ACTION_TYPE_FAILED_HOSTED_ENGINE_DISK Veirified using rhev 3.5 vt13.3 rhevm-3.5.0-0.25.el6ev.noarch ovirt-hosted-engine-setup-1.2.1-7.el6ev.noarch
RHEV-M 3.5.0 has been released, closing this bug.