thanks

Thanks for your comments. Personally, I agree with you–hence my “call to action” to Microsoft. They need to add this functionality to Windows so that Windows will be on par with ESX, Solaris, Linux, etc.

Most readers here are probably familiar with the fact that ESX isn’t based on Linux, but I appreciate you taking the time to clarify that nevertheless.

Thanks for reading!

Thus if you have NIC teaming between e1000 and tg3, and your e1000 driver goes wonky for some reason and none of your e1000 devices work, your traffic still goes out through the tg3 and vice versa. If you were teaming 2 identical devices, you are not protected from driver failures such as this.

Also, as has been stated millions of times. ESX is NOT Linux based. It used to come with a Redhat Linux Service Console, but this was never really a matter of convenience- the ESX kernel is entirely owned by VMware. You can also now buy ESXi which is the core ESX hypervisor and management software without any bundled Linux management OS.

I understand your position. I do not necessarily agree with you on all points, but I can see your point of view. In my opinion, while device manufacturers certainly do bear the responsibility to create device drivers, Microsoft bears the responsibility of making sure that its products meet the needs of the customers. If the device drivers can’t provide NIC teaming or bonding, then Microsoft needs to. And if Microsoft is indeed working on a “MPIO style” NIC teaming framework, then by gosh go public with it so that users will know that Microsoft has recognized the problem and is working on a resolution.

The end state is that customers need a supported way to provide network redundancy to virtual machines hosted on Hyper-V. Whether this means that the code for Hyper-V’s virtual switches needs to be changed to allow multiple uplinks, or Microsoft needs to write its own NIC bonding routines, or something else entirely needs to happen is irrelevant. The customers’ needs have to be addressed. Any way you slice it or dice it, any place you put the blame, the end result is that customers can’t provide network redundancy for VMs, and that’s a problem.

With regards to Quick Migration, those of us that have studied Quick Migration know and understand that this is merely an application of host clustering. Having worked with clusters in the past, I understand what is going on here and why. You’re absolutely correct in that some applications will “ride out” the brief outage. Many will not. Microsoft can’t say to a customer, “Your applications weren’t written well enough to ride out a brief network outage, so that will cause problems when you use Quick Migration”–that won’t fly. Instead, Microsoft has to clearly explain what Quick Migration *is* and what it *isn’t*. That part, in my opinion, has been lost in the marketing war against VMware, Citrix, and Virtual Iron’s live migration functionality. Once customers clearly understand the limitations of Quick Migration, they can apply the technology where it fits to meet their business needs.

Thanks for taking the time to comment, Tim. I appreciate your thoughts and your point of view!

VMware, on the other hand, has access to the code for those devices due to the nature of their Linux-based operating system. They can build that. Now, with that said, I agree that with Microsoft’s synthetic devices in their virtual machines, they might be able to create a NIC teaming capability within the virtual machine, but that doesn’t necessarily map to the NIC teaming on the physical host. We’ll have to wait to see on that one.

As to the clustering or Quick Migration issue, yes, there is an outage of the virtual machine while the machine goes into a save state, the LUN is moved, and the state is restored. This impacts some applications but not all. This is the same that has been happening in Microsoft clusters since they were introduced in NT4. Client applications should be written to be able to ride through a network outage. This generally means that if it attempts to access the server and it is unavailable, it needs to try again for a period of time. Since the state of the virtual machine is saved during a Quick Migration, the client information is saved. It only needs to reconnect. Some applications do this well. Other applications did not code good retry logic into them to be able to ride through a network outage. Other applications are written with tools that don’t handle network outages very well. Again, everything is still in the virtual machine; the client just needs to have the logic to ride through a network outage.

Take VMware ESX for example: it manages the virtual networks, and you can put any two vendors’ network cards in the same virtual switch.

I would be hard pressed to recommend Hyper-V in ANY production environment based on this fact. Network redundancy is a must for any production virtualization environment. The number one question a customer will ask, “Is this solution redundant and does it have any single points of failure?”