Description of problem:
Pinning a VM to host other than the one it is currently running on doesn't seem to be very intuitive.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Select VM started on Host A.
2. Edit, select Specific Host B, tick Run VM on the selected host (no migration allowed) box.
VM remains on Host A, no migration event triggered (no errors either), on attempting to migrate to Host B results in error that VM is pinned to host.
VM migrated to Host B automatically.
What is actually the expected behaviour here?
Changes in some of the VM's properties take effect only after the VM is stopped and then started again.
The expected behavior is: After the VM (that is currently running on Host A) will shutdown, running it again will be done on Host B (or fail if Host B is not available for running VMs for some reason).
This is not a bug; however, a GUI improvement can be done here in order to clarify when changes will actually take effect -> marking as a Future-Feature and flagging for rhevm_future.
just to explain the use case:
if a VM is /pinned/ it /cannot/ live migrate.
(assumption is it is using a local resource on the host (say, pci passthrough).
workaround may be to set the other host, remove pinning, live migrate, set pinning.
not sure we if allow changing all of these when a VM is up.
(In reply to comment #2)
The confusion from my point of view is that the UI allows you to pin the VM, while running, to a host other than the one it is running on but no notification is given as to what manual action needs to be undertaken to get it running on that host (either restarting it or removing the pinning and live migrating it first as you suggest).
(In reply to comment #3)
Anything you change in VM properties via the edit menu while it is running will only take effect on next power up.
Pin to host is a VM property - so this is the expected behavior.
Documentation should clarify it and the dialogue should make that clear.
> the dialogue should make that clear.
Do you mean to make that clear for this field or some general solution in this dialog which if changes any VM property will make that clear? And what exactly do you mean by "make that clear"? Have a warning message in the bottom part of the dialog would be enough?
we can block in the engine such an update, so if a user tries to edit a VM pinning topology he will get a proper error message. This will also help REST api users...
Tool-tip is something users may miss, so I think blocking the editing for a running VM is better in this case.
Please re-open if you wish to provide the missing information.
(In reply to Doron Fediuck from comment #7)
> we can block in the engine such an update, so if a user tries to edit a VM
> pinning topology he will get a proper error message. This will also help
> REST api users...
> Tool-tip is something users may miss, so I think blocking the editing for a
> running VM is better in this case.
It was unclear to me that this question was directed at me (given Tomas was addressed in the message) but the answer is yes. Edit of properties on a running VM should be blocked IMO or better yet the user should be allowed to make changes but notified they wont take effect until restart.
block in the engine such an update, and added a info icon next to the fields.
Verified in rhevm-3.3.0-0.33.beta1.el6ev.noarch (is23).
1. Create new VM, set to run on a specific host and run it.
2. Edit the running VM:
- change the specific host to be ran on or select "Any Host in Cluster"
- or/and change the migration option to some other value
1. There is new info icon '(?)' before "Start Running On:" label with tooltip:
"The fields under 'Start Running On' and 'Migration Options' aren't editable
while the VM isn't down".
2. After submitting the dialog you get error:
Error while executing action:
* There was an attempt to change VM values while the VM is not down. Please shut down the VM in order to modify these properties.
Closing - RHEV 3.3 Released