Description of problem: How 'Shutdown' works? If there is not Guest Agent (GA) inside OS, then ACPI call is sent. If guest OS has hooks to run specific application when kernel catches ACPI call, it would show popup (RHEL, SuSE). This shutdown warning popup tells user that OS is _going_ to be shutdown in 60 seconds. _But_ user can cancel this shutdown. When he cancels the shutdown, rhevm does not know about it but still keeps the VM in 'Powering off' state. But the VM is not in fact powering off, ok? During 'Powering Off' state of the VM, the user cannot attach any CD. Summary: rhevm supposes that powering off of a VM means it is really powering off. This could be no reality. If rhevm cannot be sure the VM would shutdown 100%, it should not restrict actions on such VM (like 'change cd'). Version-Release number of selected component (if applicable): is19 How reproducible: 100% Steps to Reproduce: 1. have RHEL with GUI as VM (not guest agent) 2. shutdown from admin portal 3. cancel shutdown popup inside guest VM 4. immediately try to change cd Actual results: not possible to change cd during 'powering off' state Expected results: should be possible (as 'powering off' state is belief, not reality) Additional info: yes, after timeout is reached, the state is again up, but it is super annoying to wait just to attach a cd.
this should have a roll forward if the VM does indeed power off (qemu process down), and should then only change cd in the vm config?
note the default 60s delay is removed in 3.4 comment #1 may make sense and should be part of bug 922377
(In reply to Michal Skrivanek from comment #4) > note the default 60s delay is removed in 3.4 > comment #1 may make sense and should be part of bug 922377 this is addressed now, as aprt of VM configuration
"edit running vm" feature