I have been very busy over the last couple of months upgrading Hyper-V hosts to R2. For the most part, these upgrades have been uneventful, without any issues at all, which is always a good thing. However, I said "for the most part", so lets talk about what happened?
Early in the upgrades, I was seeing some random issues with Virtual Switches losing their bindings with the physical NIC. This caught my attention, but after poking around and with no issues being evident, I just recreated the virtual switch and moved on. However, as I started working more and more larger scale upgrades I started to see a concerning trend. I noticed any Virtual Switch that was bound to a Broadcom NetXtreme II 5708 was losing its bindings. I decided to see if I could reproduce this in a lab and found that I could reproduce this easily.
I am sure there are those of you out there wondering why I would even be using Broadcom NIC's for my virtual networks instead of the good old dependable Intel that we all know and love. The answer is simple. I run all Dell in my data center and all Dell PowerEdge servers come with Broadcom NIC's on-board. I am running some pretty dense Hyper-V configurations with one cluster running over 12 virtual networks, so I need all the NIC's I can get, so not using the four on-board Broadcom's in this configuration wasn't an option. Well, at least it wasn't before, but that has changed.
I decided to reach out to my friends over at the Microsoft Product group and see if they had heard of this problem internally or from feedback for other customers. Apparently, this is a recent issue that has been discovered and is now officially documented as a known issue. Currently, Microsoft doesn't have a work around for this issue and nor is there an ETA for resolution. After all, it may not be Microsoft, but could very well be Broadcom.
So, what do we do? Well, in my configurations I can't afford these little gotchas and I will be working only with my trusted Intel NIC's for my virtual networks. And for my Broadcom NIC's? Well, they can still be used, but in my opinion are well suited for your management and iSCSI connections only.
Early in the upgrades, I was seeing some random issues with Virtual Switches losing their bindings with the physical NIC. This caught my attention, but after poking around and with no issues being evident, I just recreated the virtual switch and moved on. However, as I started working more and more larger scale upgrades I started to see a concerning trend. I noticed any Virtual Switch that was bound to a Broadcom NetXtreme II 5708 was losing its bindings. I decided to see if I could reproduce this in a lab and found that I could reproduce this easily.
I am sure there are those of you out there wondering why I would even be using Broadcom NIC's for my virtual networks instead of the good old dependable Intel that we all know and love. The answer is simple. I run all Dell in my data center and all Dell PowerEdge servers come with Broadcom NIC's on-board. I am running some pretty dense Hyper-V configurations with one cluster running over 12 virtual networks, so I need all the NIC's I can get, so not using the four on-board Broadcom's in this configuration wasn't an option. Well, at least it wasn't before, but that has changed.
I decided to reach out to my friends over at the Microsoft Product group and see if they had heard of this problem internally or from feedback for other customers. Apparently, this is a recent issue that has been discovered and is now officially documented as a known issue. Currently, Microsoft doesn't have a work around for this issue and nor is there an ETA for resolution. After all, it may not be Microsoft, but could very well be Broadcom.
So, what do we do? Well, in my configurations I can't afford these little gotchas and I will be working only with my trusted Intel NIC's for my virtual networks. And for my Broadcom NIC's? Well, they can still be used, but in my opinion are well suited for your management and iSCSI connections only.
7 comments: