4

I'm running a Hyper-V cluster with three nodes that host a collection of VMs between them. When we need to service a node we can live migrate the roles on that node to one of the others.

What is the correct way to implement the constraint that two specific VMs should be running on the same node, whichever node that is?

pufferfish
  • 2,660
  • 9
  • 37
  • 40
  • 1
    Do you want to add a location constraint (VM1+VM2) on same node or (VM1 on node1) + (VM2 on node1)? – Lenniey Jan 25 '18 at 11:47
  • Anti-affinity is usually the thing that's needed. In your case you need affinity. I'm curious as to why. Can you explain? Thanks. – joeqwerty Jan 25 '18 at 11:57
  • Sure. In my case I want affinity because the two machines communicate via a Virtual Switch of the connection type "Internal network". That channel doesn't seem to work between cluster nodes so until I get that figured out this seemed like a quick fix. – pufferfish Jan 25 '18 at 14:59
  • @Lenniey ((VM1+VM2) on same node) – pufferfish Jan 25 '18 at 15:02
  • I'd like to know that, too. In Hyper-V clustering for Server 2016 there is the new thing called [clustering groups and sets](https://blogs.msdn.microsoft.com/clustering/2016/10/10/failover-clustering-sets-for-start-ordering/). You proably could (ab)use that. Other than that, you could rely on PowerShell and get the location of VM1, check it against VM2, and possibly relocate. I don't have a free testing env. atm, so I can't check it, I'm afraid. – Lenniey Jan 26 '18 at 11:41
  • @pufferfish: OK. Gotcha. An internal virtual switch only proffers connectivity between VM's connected to the internal virtual switch and between those VM's and the parent partition, so no communication between VM's across cluster nodes. – joeqwerty Jan 26 '18 at 16:59

1 Answers1

0

This is just a thought, I will try and test later.

What if you had multiple separate anti-affinity rules from those VMs to other VMs that are on other hosts. (Yes I know this is not how anti-affinity is supposed to work). I don't know if a single VM can be part of multiple anti-affinity rules or not which is what this whole thing hinges on.

VM1, VM2 being the ones you want to keep together, you set up anti-affinity from each VM individually to VM3, and do the same to VM4. Also setup anti-affinity between VM3 and VM4.

If it works it should move around like a nice shell game of VMs moving around smoothly.

Only other way I can think of is setting preferred hosts for the two VMs you want to keep together until you get your external switch issue solved.

EDIT

Looks like it can be part of multiple anti-affinity groups, just do a += when you assign the affinity class name. So you should be good to go if you want to do do this

Harrison Gibbs
  • 369
  • 1
  • 8
  • Wow just realized how old this is... – Harrison Gibbs Oct 01 '18 at 16:07
  • I still haven't resolved it yet so answers still welcome. I think your suggestion would not work. For example, if NODE1 goes down VM3 and VM4 would be migrated to NODE2 and NODE3 respectively. This would leave VM1+VM2 nowehere to go? Then again I haven't actually worked with anti-affinity rules – pufferfish Oct 03 '18 at 12:29
  • Anti-affinity is like preferred hosts, it tries to keep them off the same host but at the end it will still bring up the VM over just leaving it down – Harrison Gibbs Oct 03 '18 at 13:20