Description of problem: In 3.3, changing a VM's migration policy (e.g. "allow" to "do not migrate" or "allow manual migration") requires the VM to be shutdown, in 3.2 this was possible while the VM was running. Version-Release number of selected component (if applicable): 3.3.0 How reproducible: 100% Steps to Reproduce: 1. Select 'edit' for running VM 2. Attempt to change from one migration option under the Host tab to another 3. Actual results: Error message that this requires the VM to be down Expected results: Migration policy should be changeable while VM is running.
changed by gchaplik in 5460e6ba7306028704cfae2e3a604a3b101f8f15, moving to sla to resolve
Hi, this is indeed a behavior change, as requested in bug 735260 and added in version 3.3. Closing as this is not a bug and works as designed. I you wish to change the behavior again, I suggest we discuss it first and then reopen if needed.
Doron, Per the customer: " I just successfully performed the following on a RHEV3.2 host: - create a new VM, select pinned to hostA with no migration allowed - start VM - edit VM: disable no migration allowed, set to "any host in the cluster" - migrate VM from hostA to hostB This is the desired functionality." According to BZ#735260 this should not be the case, as if I read the comments correctly this should have only been possible after a reboot of the VM, yes? Either way, the above functionality is what is desired, and I can definitely see the use case for this. So yes, would like to change the behavior again (back?). Is this acceptable?
(In reply to Jake Hunsaker from comment #3) > Doron, > > Per the customer: > > " I just successfully performed the following on a RHEV3.2 host: > - create a new VM, select pinned to hostA with no migration allowed > - start VM > - edit VM: disable no migration allowed, set to "any host in the cluster" > - migrate VM from hostA to hostB > > This is the desired functionality." > > > According to BZ#735260 this should not be the case, as if I read the > comments correctly this should have only been possible after a reboot of the > VM, yes? The above flow is really the direct opposite of what was reported in BZ#735260. The flow observed in BZ#735260 was: - Create a VM. - Start the VM. - Edit the VM and pin it to a host other than the one it is running on. - Save the changes. At this point: a) No automatic migration of the virtual machine to the desired host occurs. b) Manually initiating migration of the VM is not permitted (explicitly denied with an error indicating the VM is pinned to a host). As a result the user was left with a VM that they've "pinned" to a host, but is not running on that host and can not be moved to it without shutting the VM down and starting it again. It's not surprising that the flow you described above doesn't run into this as the VM is being *unpinned* from the host. The rules around the migration action that prevent it being used when the VM is pinned don't apply, because it's no longer pinned. > Either way, the above functionality is what is desired, and I can definitely > see the use case for this. So yes, would like to change the behavior again > (back?). > > Is this acceptable? Allowing moving of a VM from pinned to unpinned while it's up (your customers use case, which again is the opposite to that described in the other bug) seems reasonable. I do not however think moving of a VM from unpinned to pinned while it's up should be permitted unless additional work is also done to ensure that the pinning is actually applied (read: the VM migrated) before the VM is locked down to prevent the migration action. Either that or when marking an online VM as pinned the only host option should be the host it's on.
*** Bug 1093281 has been marked as a duplicate of this bug. ***
*** Bug 1095001 has been marked as a duplicate of this bug. ***
this bug is propose to clone to 3.4.z, but missed the 3.4.4 builds. moving to 3.4.5 - please clone once ready.
Updating target release as this is too risky for 3.4.5 and may introduce regressions.
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
*** Bug 1095777 has been marked as a duplicate of this bug. ***
Revert the patch. Postpone solution till we have detailed design.
Suggest the following design: 1. On pinned running VM, change migration policy to allow migration on pinned VM. Allow only after VM reboot. Give an warning message, and mark VM icon with pending change. The rational: prevent migrating host specific information. 2. On migrateable running VM, change migration policy: pin the VM to one or more hosts. If not running on pinned host: Update all other changes, if any. Start a background job transaction: a) Migrate running VM to any of the pinned hosts. b) Update the VM pinning to on or more requested hosts. c) Complete transaction and provide success info event message. On transaction failure. Provide error event message. Leave VM unchanged. If running of pinned host Update VM normally 3. On pinned running VM, add/change pinning to OTHER hosts. While including the current host in the list. Update VM normally. 4. On pinned running VM, modify pinning hosts. Removing the current host from the list. Same treatment as case 1.
(In reply to Dudi Maroshi from comment #20) > Suggest the following design: ... > 2. On migrateable running VM, change migration policy: pin the VM to one or > more hosts. > If not running on pinned host: > Update all other changes, if any. > Start a background job transaction: > a) Migrate running VM to any of the pinned hosts. > b) Update the VM pinning to on or more requested hosts. > c) Complete transaction and provide success info event message. > Step B should come before A. Otherwise it looks ok.
(In reply to Doron Fediuck from comment #21) > (In reply to Dudi Maroshi from comment #20) > > Suggest the following design: > ... > > 2. On migrateable running VM, change migration policy: pin the VM to one or > > more hosts. > > If not running on pinned host: > > Update all other changes, if any. > > Start a background job transaction: > > a) Migrate running VM to any of the pinned hosts. > > b) Update the VM pinning to on or more requested hosts. > > c) Complete transaction and provide success info event message. > > > > Step B should come before A. I expect the Admin to make sure the VM is already running on the desireable host and *then* update it to be pinned. That will prevent us from doing an implicit migration (which may fail) and the user wouldn't know the VM is mis-placed. I suggest a canDo if the VM isn't running out of the pin-to-hosts set. > Otherwise it looks ok.
(In reply to Roy Golan from comment #22) > I suggest a canDo if the VM isn't running out of the pin-to-hosts set. s/isn't/is
Guys I want to conclude this, the patch should in already - My only problem is to require a restart for the migrateable to become available. I think we can make it a config value and a customer can determine the behaviour
it decided to supply a 'Force action" kinda checkbox for the operation when we want to move the VM from non-migratable to something else.
When running VM change from pinned to non-pinned. Agreed to use checkboxed confirmation dialog-box. With same functionally as in host -> "Host 'confirm host has been rebooted'" -> confirm dialog-box.
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high
*** Bug 1146069 has been marked as a duplicate of this bug. ***
Verified on rhevm-backend-3.6.5-0.1.el6.noarch 1) change migration options when VM up 2) change migration options of VM with CPU pinning 3) change migration options of VM with CPU passthrough 4) change migration options of VM with NUMA pinning
This issue is fixed in RHEVM 3.6.5 Z-Stream https://rhn.redhat.com/errata/RHBA-2016-0661.html