Bug 735260 - [Text] Make clear that Pinning a VM to a host only takes effect on the next power up
Summary: [Text] Make clear that Pinning a VM to a host only takes effect on the next p...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.0.0
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
: 3.3.0
Assignee: Gilad Chaplik
QA Contact: Pavel Novotny
URL:
Whiteboard: sla
Depends On:
Blocks: 3.3snap2
TreeView+ depends on / blocked
 
Reported: 2011-09-02 03:12 UTC by Stephen Gordon
Modified: 2019-07-11 07:36 UTC (History)
10 users (show)

Fixed In Version: is23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-15 13:59:36 UTC
oVirt Team: SLA


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 19937 None None None Never
oVirt gerrit 20444 None None None Never

Description Stephen Gordon 2011-09-02 03:12:45 UTC
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):

ic139

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.
3. Save.

  
Actual results:

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.

Expected results:

VM migrated to Host B automatically.

====================================

What is actually the expected behaviour here?

Comment 1 Einav Cohen 2011-09-02 13:15:51 UTC
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.

Comment 2 Itamar Heim 2011-09-03 05:17:12 UTC
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.

Comment 3 Stephen Gordon 2011-09-04 23:03:33 UTC
(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).

Comment 4 Simon Grinberg 2013-02-13 16:23:18 UTC
(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.

Comment 6 Tomas Jelinek 2013-06-10 11:06:05 UTC
> 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?

Comment 7 Doron Fediuck 2013-07-01 14:15:46 UTC
Tomas,
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.

Thoughts?

Comment 8 Doron Fediuck 2013-07-15 13:59:36 UTC
Please re-open if you wish to provide the missing information.

Comment 9 Stephen Gordon 2013-07-15 14:34:12 UTC
(In reply to Doron Fediuck from comment #7)
> Tomas,
> 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.
> 
> Thoughts?

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.

Comment 10 Gilad Chaplik 2013-10-07 14:05:29 UTC
block in the engine such an update, and added a info icon next to the fields.

Comment 11 Pavel Novotny 2013-11-18 16:50:00 UTC
Verified in rhevm-3.3.0-0.33.beta1.el6ev.noarch (is23).

Verification steps:
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

Results:
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:

pinned-vm:
    * 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.
-~-

Comment 12 Itamar Heim 2014-01-21 22:32:06 UTC
Closing - RHEV 3.3 Released

Comment 13 Itamar Heim 2014-01-21 22:32:11 UTC
Closing - RHEV 3.3 Released


Note You need to log in before you can comment on or make changes to this bug.