Bug 1095777

Hi Jake,
Please provide steps for reproduction of a bug.

Nikolai,


Sorry just saw this. 

Steps:

1. Set VM to a specific host and "Do not allow migration" and pin the CPUs from the edit menu

2. Start the VM

3. With the VM running, try to change "Do not allow migration" to either of the options allowing migration and allow it to run on any host in the cluster.


In 3.3 (and 3.4) the portal presents an error message of:

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.


In 3.2 the change is allowed and the VM can migrate. The functionality of 3.2 is what is desired here.

For current components at 3.5 engine requires VM to be rebooted for changes to take effect:

"Next Restart Configuration

Some of the changes will be applied only on the vm next start.

Changed fields list
dedicatedVmForVds"

Tested on these components:
sanlock-2.8-1.el6.x86_64
libvirt-client-0.10.2-46.el6_6.2.x86_64
qemu-kvm-rhev-0.12.1.2-2.446.el6.x86_64
mom-0.4.1-4.el6ev.noarch
vdsm-4.16.8.1-6.el6ev.x86_64
rhevm-guest-agent-common-1.0.10-2.el6ev.noarch
rhevm-3.5.0-0.31.el6ev.noarch

Desired functionality of 3.2 had not been met yet.

Created attachment 994362 [details]
PIC1: GUI fields under discussion

Relating to the pic in comment 7.

The relevant field to this bug is "migrationSupport" marked in red rectangle.
The "hostSelection" field marked in green rectangle is not relevant to migration. Because it controls where (on which host) the vm initially starts.

Problem diagnostics:
When  "migrationSupport" field is changed and saved. Its effect is delayed after the vm restarts. This is due to  "migrationSupport" field annotation "@EditableOnVmStatusField".


Solution:
Replace  "migrationSupport" field annotation to normal "@EditableField", allow migration as soon as the vm edit screen is saved to the ovirt engine.

3.5.1 is already full with bugs (over 80), and since none of these bugs were added as urgent for 3.5.1 release in the tracker bug, moving to 3.5.2

(In reply to Dudi Maroshi from comment #8)

> Solution:
> Replace  "migrationSupport" field annotation to normal "@EditableField",
> allow migration as soon as the vm edit screen is saved to the ovirt engine.

Dudi, the issue here is not about changing the code, but on the impact of the behavior change. See bug 1058384 comment 4.

Jake, how is this BZ different than bug 1058384?
If not that we should only keep one and mark this as a duplicate.

(In reply to Doron Fediuck from comment #10)
> (In reply to Dudi Maroshi from comment #8)
> 
> > Solution:
> > Replace  "migrationSupport" field annotation to normal "@EditableField",
> > allow migration as soon as the vm edit screen is saved to the ovirt engine.
> 
> Dudi, the issue here is not about changing the code, but on the impact of
> the behavior change. See bug 1058384 comment 4.
> 
> Jake, how is this BZ different than bug 1058384?
> If not that we should only keep one and mark this as a duplicate.

As I was reading the correspondence about bug 1058384, I understood the following.
1. We the development have no decisive policy about protecting "wise" administrators from doing configuration mistakes (migrating vm with pinned cpu).
2. We need to be cost/effective about how much effort we put on preventive constraints.

I suggest we the development, identify risky/unwise actions. And provide an explanatory warning on the confirmation dialog.

In general power users and administrators (root users) are allowed to destroy their system with power tools. I personally follow Redhat slogan, with great liberty comes great responsibility.

In short, I suggest we provide and log a warning message. If the user unppins a vm with pinned cpus. And allow the user to accept the consequences.

Please comment on my suggestion.

Based on comment 10, this is a duplicate issue.
Let's focus all related discussions in a single issue.

*** This bug has been marked as a duplicate of bug 1058384 ***