The risks of using Hyper-V pass through disks

  • No portability. VHDX files can be copied anywhere that they’re needed. This makes migrations a snap, even in old Hyper-V versions that don’t support Shared Nothing Live Migration. There are a lot of other benefits to this portability too, such as manual backups or sharing virtual disks with other people for development or debugging purposes.
  • Host backups are a problem. The host computer only brokers the attachment between the virtual machine and the disk. It can’t see the contents. So, if you use a hypervisor-based backup application like Altaro, your pass-through disks aren’t going to be backed up. You’ll be required to use an agent-based system inside the guest.
  • Guest backups are a problem. The nice thing about host-based backups is how coordinated everything is. The VM backups run sequentially without interruption, so you don’t have to do a lot of fancy scheduling to try to balance the detrimental effects of too many VMs backing up at once or spacing them out so far that there is a lot of dead-air time when it would be more efficient to be performing a backup. When you’ve got a system that performs smart backup scheduling, like Altaro does, it’s even better. On top of the scheduling benefits of host-level backup, any hardware acceleration provided by the storage manufacturer can be put into play, which means that you can get some very fast backups. Unless you decide to use an in-guest backup agent just so your pass-through disks are covered. Then you get none of these things. It’s safe to say that if you have a hardware accelerator available to assist with host-level backups and you forfeit it, that will cost you more performance in a night than the pass-through disk will add to daytime operations throughout its lifetime.
  • Forget Hyper-V Replica. HVR can’t see pass-through disks. ’nuff said.
  • Snapshots/checkpoints don’t work with pass-through disks. Just like backup and Replica, the snapshot/checkpoint mechanism can’t see the contents of pass-through disks. I’ve heard a few people using this as an excuse to use pass-through disks because they’re terrified of what will happen if someone takes a snapshot. Frankly, I’d be more terrified that this is the length someone is willing to go to in order to prevent snapshots from being taken. It’s just plain poor stewardship. Besides, I’m fairly certain that the system can still snapshot the guest, it just doesn’t get the contents of pass-through disks. If someone inadvertently takes a snapshot, that could make a merge a tricky situation.
  • Live Migration can be problematic. For starters, you can forget about Shared Nothing Live Migration. Intra-cluster Live Migration usually works, but sometimes it hiccups because the source host has to take the pass-through disk offline and the destination host has to bring it immediately online. There’s a sort of “limbo” period in-between where neither one of them has it. I don’t know that I’ve ever heard of a destination system not getting the hand-off, but I have heard of some taking so long to pick it up that the guest blue screened. In any other Live Migration scenario, if the destination host has any problems with the hand-off, the migration fails and the guest continues running at the source without interruption. With pass-through disks, there’s no such luck.
  • Lack of support. Microsoft will support your pass-through configuration, but that’s about it. Community forum posts are likely to go unanswered, except for suggestions that you convert to VHDX. Some software vendors may not support their applications on pass-through disks, especially if they know about the potential disconnect issue. For access to the widest support base, VHDX is the way to go.
  • Lack of tools. We have all kinds of nifty things we can do with VHDX files using PowerShell and other tools. You can even directly mount them in Windows Explorer. There’s really nothing out there for pass-through disks. It seems like a small issue, until there’s a problem with a VM and you need to perform a task on the disk and discover that there’s really no good way to do it.

NLB Unicast cluster node unable to route

Environment was Hyper-V 2012 R2 and members of an NLB cluster can communicate with each other but have no external access.  Problem seems to be related to the ARP requests for the gateway and how it is formed.

MAC Address Spoofing was already enabled on the VM advanced network properties.

The trick is to add a static ARP entry for the default gateway similar as follows,

netsh interface ipv4 add neighbors “Local Area Connection” 00-aa-01-d2-3a-cc