• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • Unexplored Territory Podcast
  • HA Deepdive
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

BC-DR

Host placement for the secondary FT VM with Fault Domains?

Duncan Epping · Sep 23, 2026 · Leave a Comment

On Reddit there was a question about how to specify on which group of hosts the secondary VM of an FT-enabled VM would land on. Now this is a problem that has been around for a while, and for the longest time we actually did not have a solution for it, but now we do. I did a quick search, and somehow I couldn’t find an article where I describe how this works, so I figured I would write one. Having said that, I would not be surprised if there’s already and article out there, but somehow didn’t pop up.

When it comes to vSphere Fault Tolerance, when you enable it on a VM, what you will see happening is that the VM you enabled it on will get “(primary)” behind the name. This VM is, as you would expect, the primary and is paired with a “secondary”. This “secondary” VM runs in lockstep with the primary, so that it can take over instantly if the primary would fail for any reason. Now, that secondary VM is kind of a strange VM. Although you can find the VM in your inventory on a host level, you cannot find it on a cluster level or in the VM view. It is like a shadow copy, it is there, but yet it isn’t really.

As a result, making VM-Host rules for it is rather difficult. Although you can do it, this shadow / secondary VM can also be reinstantiated and as a result that VM-Host rule would unfortunately break. Why? Well, the newly instantiated VM is literally that… a newly instantiated VM, so the old rules do not apply. So although the VM-Host rules with tags can work through the Compute Policy option, it not ideal. Probably should also mention, traditional VM-Host groups and rules do not even work with the secondary VM, as you simply cannot select the secondary VM to begin with.

So what does work? Well, there’s a new option called Enable Metro Cluster Fault Tolerance. What this does is that when you select a Host Group for the primary, the secondary VM automatically ends up on a host outside of the selected group. The Host Group can simply be defined via the VM-Host group option under your cluster’s Configure tab as shown in the screenshots below.

Hopefully this helps those who are planning on leveraging FT and want to ensure the primary and secondary are placed on different fault domains.

Host placement for the secondary FT VM with Fault Domains?

 

VCF 9.1 Protection and Recovery demo showing how to recover from a ransomware attack

Duncan Epping · Jun 1, 2026 · Leave a Comment

Just recorded a new demo for VCF 9.1 Protection and Recovery, or VMware Live Recovery as it was called previously. In this demo I show the recovery process after a ransomware attack! I just love how easy it is with this platform, and how it includes integration with either Carbon Black or CrowdStrike.

vSphere HA setting Performance degradation VMs tolerate

Duncan Epping · Apr 8, 2026 · Leave a Comment

There was a question this week internally and I really had to start digging, as I have not looked at this in a loooong time. What does “Performance degradation VMs tolerate” do? And does this feature require admission control to be enabled or not?

vSphere HA setting Performance degradation VMs tolerate

I had to test this, as I barely ever play around with the HA settings these days. But, let’s first describe what this feature is for. I think the UI explains it fairly decently, but here’s my explanation from the vSphere Clustering Deep Dive:

This feature allows you to specify the performance degradation you are willing to incur if a failure happens. It is set to 100% by default, but it is our recommendation to consider changed the value. You can for instance change this to 25% or 50.

Now, the requirement for this feature to work is to have DRS enables, but Admission Control does not need to be enabled! A lot of people are under the impression that it requires Admission Control in order to take “an X number of failures” into account, but it does not. It actually does not use what is specified for Admission Control. It takes a single failure into account when it comes to this feature, and then uses DRS to do the calculations if powered on VMs will get the same amount of resources allocated after a failure. If the answer is no, or performance degradation is higher than the percentage specified, a warning is triggered. You will still be able to power on new VMs, but the warning will not go away unless the resource usage changes, or you add more resources to the cluster.

vSAN to vSAN Replication and Recovery Plan creation demo!

Duncan Epping · Dec 9, 2025 · 1 Comment

As I was going through the various recordings I had of demos I created for Explore, I realized I hadn’t published the demos I created for vSAN to vSAN Replication, and on creating a Recovery Plan based on a vSAN Protection Group in VMware Live Recovery. So here it is. It is a pretty lengthy video as I go through all the various steps involved. So what you will see in this demo is the following:

  • vCenter Server Pairing between my 2 sites
  • Cluster pairing
  • Creation of a vSAN Protection Group, including vSAN to vSAN Replication
  • Creation of a Recovery Plan based on the previously created Protection Group
  • Test of the Recovery Plan

What happens after a Site Takeover when my failed sites come back online again?

Duncan Epping · Dec 4, 2025 · Leave a Comment

I got a question after the previous demo: what would happen if, after a Site Takeover, the two failed sites came back online again? I completely ignored this part of the scenario so far, I am not even sure why. I knew what would happen, but I wanted to test it anyway to confirm that what engineering had described actually happened. For those who cannot be bothered to watch a demo, what happens when the two failed sites come back online again is pretty straightforward. The “old” components of the impacted VMs are discarded, vSAN will recreate the RAID configuration as specified within the associated vSAN Storage Policy, and then a full resync will occur so that the VM is compliant again with the policy. Let me repeat one part: a full resync will occur! So if you do a Site Takeover, I hope you do understand what the impact will be. A full resync will take time, of course, depending on the connection between the data locations.

  • Page 1
  • Page 2
  • Page 3
  • Interim pages omitted …
  • Page 64
  • Go to Next Page »

Primary Sidebar

About the Author

Duncan Epping is a Chief Technologist and Distinguished Engineering Architect at Broadcom. Besides writing on Yellow-Bricks, Duncan is the co-author of the vSAN Deep Dive and the vSphere Clustering Deep Dive book series. Duncan is also the host of the Unexplored Territory Podcast.

Follow Us

  • X
  • Spotify
  • RSS Feed
  • LinkedIn

Recommended Book(s)

Also visit!

For the Dutch-speaking audience, make sure to visit RunNerd.nl to follow my running adventure, read shoe/gear/race reviews, and more!

Do you like Hardcore-Punk music? Follow my Spotify Playlist!

Do you like 80s music? I got you covered!

Copyright Yellow-Bricks.com © 2026 · Log in