|Summary:||[RFE] VM-Affinity should allow to create a policy to run the VMs between two hosts only.|
|Product:||Red Hat Enterprise Virtualization Manager||Reporter:||Udayendu Sekhar Kar <ukar>|
|Component:||ovirt-engine||Assignee:||Dudi Maroshi <dmaroshi>|
|Status:||CLOSED ERRATA||QA Contact:||Artyom <alukiano>|
|Version:||3.4.0||CC:||awels, bhaubeck, colin.coe, dfediuck, dmaroshi, iheim, istein, lpeer, mkalinin, mtessun, pablo.iranzo, pvilayat, rbalakri, Rhev-m-bugs, rpai, sherold, yeylon, ykaul|
|Target Milestone:||ovirt-3.6.0-rc||Keywords:||FutureFeature, Reopened, Triaged|
|Fixed In Version:||3.6.0-4 alpha3||Doc Type:||Enhancement|
With this release, virtual machines can be pinned to more than one host. A virtual machine that is pinned to multiple hosts cannot be live migrated, but can be made highly available between the specified hosts. The virtual machine cannot run on any other hosts in the cluster, even if all of the specified hosts are unavailable.
|Last Closed:||2017-11-01 09:05:44 UTC||Type:||Bug|
|oVirt Team:||SLA||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1256730|
Description Udayendu Sekhar Kar 2014-06-10 06:15:04 UTC
Description of problem: There is a requirement to run 2-3 VMs only between two hosts with HA mode so that if one host will be down VM should move to other but if both hosts will be down, VM should not move to other hosts in teh cluster. Customer want to achieve the plan like the below: - There are 5 hosts in a cluster. - They want to create a VM affinity group for 2-3 VMs and want those VMs to run specifically on host3 and host4. - If host 3 and host 4 will be down, its OK to have the down time for the VM but it should not start on other hosts except host3 or host4. Version-Release number of selected component (if applicable): RHEVM 3.4 Actual results: Currently no options available in the VM-Affinity group to make such a policy. Expected results: Need some option via VM-Affinity to allow restrict a group of VMs to run only betweeb some specific hosts with HA features.
Comment 1 Doron Fediuck 2014-06-11 08:00:46 UTC
Hey, it sounds like a better resolution will be to pin the VMs to specific hosts. We should have an RFE for it already. Do you think it'll resolve this RFE?
Comment 2 Udayendu Sekhar Kar 2014-06-11 08:19:33 UTC
hi, Pinning the VM to a host will be a good point but it will not allow VM migration to other(specific host). I guess the pinning concept is pertially same but the requirement is little more. The pinning is needed between 2 or 3 hosts only out of many hosts from the same cluster. And when all the mentioned hosts will down, its OK to keep the VM down. Am I clear enough regarding the requirement ? Please let me know, I will be happy to explain you what customer is actually looking for. Regards, Uday
Comment 3 Doron Fediuck 2014-06-14 07:57:35 UTC
Uday, I'm suggesting a different RFE which others already asked for and may resolve this issue as well; pin to hosts (not host). Basically it means that a VM can only run on a sub-set of hosts in the cluster. The idea is to extend the existing pin to host for multiple hosts and this should resolve your request if I'm not mistaken. Thoughts?
Comment 4 Udayendu Sekhar Kar 2014-06-14 14:46:36 UTC
Hi Doron, I got yout point. This is a good idea indeed and this will help to fulfil the requirement of the cutsomer. Thanks, Uday
Comment 5 Colin Coe 2014-06-19 00:04:59 UTC
Scenario: 2 RHEV-H in Rack A, 2 RHEV-H in Rack B Guests A, B and C should only run on any RHEV-H in Rack A Guests D, E and F should only run on any RHEV-H in Rack B Should the RHEV-H in Rack A become unavailable, these guests should run on any host in Rack B but automatically migrate back when the RHEV-H in Rack A become stable. I see only limited use in the current affinity capabilities. Really hoping Red Hat addresses this in 3.4.1.
Comment 9 Doron Fediuck 2015-04-28 11:39:31 UTC
For 3.6.0, this will be implemented as 'pin to hosts', which extends the existing functionality of pin to host.
Comment 11 Dudi Maroshi 2015-06-08 17:32:20 UTC
Please find in here the RFE feature design. http://www.ovirt.org/Feature/VmPinningToMultipleHosts
Comment 12 Colin Coe 2015-06-08 22:41:18 UTC
What would happen if both hosts a VM is pinned to go down? Would the VM go down as well? How is the scenario in comment 5 handled? Thanks
Comment 13 Doron Fediuck 2015-06-09 09:04:33 UTC
(In reply to Colin Coe from comment #12) > What would happen if both hosts a VM is pinned to go down? > > Would the VM go down as well? > > How is the scenario in comment 5 handled? > > Thanks Coline, you're asking for something different than this BZ. This BZ is resolving the following case (taken from description): " ... if one host will be down VM should move to other but if both hosts will be down, VM should not move to other hosts in teh cluster. " For your scenario you can write your own scheduling filter in Python.
Comment 16 Alexander Wels 2015-07-24 14:07:35 UTC
Multiple select host UI changes have been merged.
Comment 19 Colin Coe 2015-10-18 06:54:36 UTC
(In reply to Doron Fediuck from comment #13) > (In reply to Colin Coe from comment #12) > > What would happen if both hosts a VM is pinned to go down? > > > > Would the VM go down as well? > > > > How is the scenario in comment 5 handled? > > > > Thanks > > Coline, > you're asking for something different than this BZ. > This BZ is resolving the following case (taken from description): > > " > ... if one host will be down VM should move to other but if both hosts will > be down, VM should not move to other hosts in teh cluster. > " > > For your scenario you can write your own scheduling filter in Python. Could you point me at am example of this? Please note that it needs to run in RHEV 3.5 Thanks
Comment 24 errata-xmlrpc 2016-03-09 20:46:44 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0376.html