FT: Decide where FT Enabled VM Secondary VM Is

[danielbrookes]

Hi,

I have a vSphere Cluster which has 10 hosts, each being a Blade within a Blade Chassis. Odd numbered hosts are on Chassis A and even numbered hosts are on Chassis B.

I have created DRS Groups for each Blade Chassis and created rules on the Cluster to seperate certain machines out so they run on seperate Chassis, i.e we have 4 Citrix Provisioning Servers and I ensure that 2 of these are running on one Cluster Group, two on the other and they are kept on seperate hosts. That way if an entire chassis fails we still have 2 PVS servers up.

My question is this - when I enable a VM for FT is there anyway to configure rules which stipulate where the secondary VM is created, and tell DRS\FT to stick to those rules. So as an example, I have Server1 running on a host in Chassis A, I would like to enable FT for that VM and ensure that the Secondary VM is always running on a host in Chassis B?

I've tried Searching but cant really find much, hopefully someone has done this before.

Thanks for any help.l

[Gleed]

Unfortunately, there is no way to dictate which host will run the FT secondary. The best you can do is after FT is enabled use vmotion to move the secondary to where you want it.

Regards,

-Kyle

[FranckRookie]

Hi Daniel,

I never tested it but you can try playing with VM-Host affinity rules. Once FT is enabled, try to set up a rule for Server1 to stay on hosts in Chassis A and another rule for its clone to stay on hosts in Chassis B.

Let us know if you have any success with this configuration.

Good luck.

Regards

Franck

[danielbrookes]

Thanks for the replys guys. Franck - I've tried looking at affinity rules but you can only set rules up for the live machine, the secondary machine is not listed. Unless I am missing a trick?

Its a bit of a pain really and I think it would be really neat if this feature did exist, we have lots of resilliance built into our design, as I guess most people do, but if a Blade Chassis were to fail then we could potentially have downtime.

HA will obviously sort that out if a chassis were to fail, I have been wanting to look at Fault Tollerance for a while but in our setup its not quite there yet, its like 99.9% (and is really amazing - I mean 2ms downtime for complete hardware failure!) but I cant quite report back to my Management that we can protect our VM's incase the secondary machine is in the same chassis as the primary.

[FranckRookie]

Hope someone else has a solution for you. Maybe a silly idea but depending on your needs, you can also build two nodes clusters for FT VMs with one host in each blade...

[danielbrookes]

Hello,

Sorry to resurect one of my old posts but I was wondering if this has changed at all in vSphere 5?  I've tried to find out but cant.

We actually had a power issue the other day which resulted in us losing all of our vSphere blades in a chassis.  Everything worked as expected and we sat feeling pleased that all our planning paid off, commenting at how good HA is and the decisions we took to keep certain VMs seperate using DRS rules and groups.

It would have been really neat if we HAD enabled FT and everything stayed up.  If I could use a DRS rule to keep the secondary copy of a FT enabled VM seperate from the other (that is on a seperate group of hosts) that would be the icing on the cake.  If it hasnt changed, any ideas of when it will or how do I put a feature request in?

Thanks,

Daniel

[kfarkas]

Daniel,

About the placement of a secondary VM, unfortunately we have not changed the DRS rule support for FT VMs in vSphere 5. I will let the product manager for FT know about your request.

So, the best way today to control the placement of a secondary VM is to move the powered on secondary VM to a host in a different blade chassis. If you have EVC enabled, you should also configure the FT VM to have a DRS automation level of manual or disabled. While DRS won't be able to move the FT VMs around for load balancing, it will attempt to move the other VMs around if the load becomes unbalanced.

Keith