Bug 735260

Summary:	[Text] Make clear that Pinning a VM to a host only takes effect on the next power up
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Stephen Gordon <sgordon>
Component:	ovirt-engine-webadmin-portal	Assignee:	Gilad Chaplik <gchaplik>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Pavel Novotny <pnovotny>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	3.0.0	CC:	acathrow, dfediuck, ecohen, iheim, jkt, lvernia, michal.skrivanek, pstehlik, Rhev-m-bugs, sgordon
Target Milestone:	---	Keywords:	Reopened
Target Release:	3.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	sla
Fixed In Version:	is23	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-07-15 13:59:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	SLA	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1032811

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