Comments on: More on Hyper-V and NIC Teaming http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/ The weblog of an IT pro specializing in virtualization, storage, and servers Wed, 08 Feb 2012 17:13:47 +0000 hourly 1 http://wordpress.org/?v= By: Dude http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/comment-page-1/#comment-49460 Dude Tue, 02 Nov 2010 01:29:57 +0000 http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/#comment-49460 The current microsoft system sucks. i agree that it shoud be handled in the same way as their mpio framework. we invested alot of money into a large failover cluster only to find that domain controller is our new single point of failure. and of course it did. without teaming we can only connect to our dc through a single switch at one time. loose that switch and there's your single point of failure. kind of makes the whole process of failover clustering pointless doesn't it. we always try micrsoft first and usually don't need to try anything else. now i think we'll be trying vmware. which i was hoping i wouldn't have to. if anyone know's a way around this i'd love to know. just post it here. cheers. The current microsoft system sucks. i agree that it shoud be handled in the same way as their mpio framework. we invested alot of money into a large failover cluster only to find that domain controller is our new single point of failure. and of course it did. without teaming we can only connect to our dc through a single switch at one time. loose that switch and there’s your single point of failure. kind of makes the whole process of failover clustering pointless doesn’t it. we always try micrsoft first and usually don’t need to try anything else. now i think we’ll be trying vmware. which i was hoping i wouldn’t have to.

if anyone know’s a way around this i’d love to know. just post it here.

cheers.

]]> By: Amr Nassar http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/comment-page-1/#comment-47255 Amr Nassar Thu, 07 Jan 2010 01:00:34 +0000 http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/#comment-47255 Installation order should be as follows: 1. Add the Hyper-V role 2. Install the NIC Teaming software 3. Configure the team 4. Configure virtual networking within Hyper-V Installation order should be as follows:
1. Add the Hyper-V role
2. Install the NIC Teaming software
3. Configure the team
4. Configure virtual networking within Hyper-V

]]> By: Dan http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/comment-page-1/#comment-44533 Dan Wed, 20 May 2009 09:06:42 +0000 http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/#comment-44533 Further to Ian's message, does anyone have hands on experience they can share with a BladeCentre H, HS21's or HS22's and load balancing. I'll be implementing a similar system in the coming months and are unsure of any potential issues. Specifically, I'll have the two blade NICs and two NICs on the expansion card (NIC types the same). There will be a number of Hyper-V blades clustered. If anyone can share first hand experience it would be much appreciated. Cheers Dan Further to Ian’s message, does anyone have hands on experience they can share with a BladeCentre H, HS21′s or HS22′s and load balancing. I’ll be implementing a similar system in the coming months and are unsure of any potential issues. Specifically, I’ll have the two blade NICs and two NICs on the expansion card (NIC types the same). There will be a number of Hyper-V blades clustered.

If anyone can share first hand experience it would be much appreciated. Cheers

Dan

]]> By: Ian http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/comment-page-1/#comment-44369 Ian Sun, 03 May 2009 23:44:01 +0000 http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/#comment-44369 Sean, We are ewxperiencing the same issue only we are using IBM HS21 blades in a BladeCentre H. We have SLB setup on our Broadcom NIC's however are somewhat tied to the SLB technology because our NIC's are across different physical switches in the back of the BladCentre-H Chassis. I don't believe we can use 802.3ad across multiple switches??? Did you have any luck? Ian Sean,

We are ewxperiencing the same issue only we are using IBM HS21 blades in a BladeCentre H. We have SLB setup on our Broadcom NIC’s however are somewhat tied to the SLB technology because our NIC’s are across different physical switches in the back of the BladCentre-H Chassis. I don’t believe we can use 802.3ad across multiple switches???

Did you have any luck?

Ian

]]> By: Sean McPartlin http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/comment-page-1/#comment-44272 Sean McPartlin Mon, 20 Apr 2009 16:27:40 +0000 http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/#comment-44272 Nat: So you got Teaming to work with the IBM x series and Hyper-V? Would love some more info on that. I'm trying to get HS12 in a BladeCenter S to work with hyper-v in a clustered 2008 2 node system. My VM's can only ping the IP of the Hyper V. Can't route past it. I'm going to try messing with the 802.3ad setup and see if that helps. Sean~ Nat: So you got Teaming to work with the IBM x series and Hyper-V? Would love some more info on that.

I’m trying to get HS12 in a BladeCenter S to work with hyper-v in a clustered 2008 2 node system.

My VM’s can only ping the IP of the Hyper V. Can’t route past it.

I’m going to try messing with the 802.3ad setup and see if that helps.

Sean~

]]> By: slowe http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/comment-page-1/#comment-43135 slowe Wed, 31 Dec 2008 16:04:02 +0000 http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/#comment-43135 I suppose we just have different perspectives on the matter. I can see your point, but to me this level of redundancy should have been built into the hypervisor/parent partition. Thanks for commenting! I suppose we just have different perspectives on the matter. I can see your point, but to me this level of redundancy should have been built into the hypervisor/parent partition.

Thanks for commenting!

]]> By: Nate http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/comment-page-1/#comment-43131 Nate Wed, 31 Dec 2008 13:55:41 +0000 http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/#comment-43131 I suppose my thought is that if we are talking about 'enterprise-grade' virtualization customers they are also likely 'enterprise-grade' networking customers. I'm not sure if other netorking vendors already offer solutions to etherchannel with multiple switches, but if they don't I'd assume they'll follo suit soon. I know Juniper has something they call "virtual chassis" for stacking that I'd assume could lead to the same end goal. To me an etherchannel solution is more 'enterprise' than a mac-out solution. My guess is Microsoft will probably implement something within hyper-v at some point to do NIC bonding for SMB folks using budget switches, but my point is that there is a solution now. Additionally even if Microsoft implements something similar to what vmware has done it may still be beneficial to opt for etherchannel in an enterprise scenario if you can for better load balancing. Again my beef is with saying 'unsupported' in the first place. It's an incorrect statement. The NIC vendor supports thier software, therefore it is supported. Microsoft states the use of third party NIC teaming is 'accepted' just that the support of that third party software falls to the NIC vendor. It's not like Microsoft is saying "don't do it". Yes Microsoft says that if you are having an issue they may ask you to disable the team as part of the troubleshooting process. That's not a big surprise. Even if the teaming software was provided by Microsoft I'm sure there are scenarios where they would ask you to disable it in troubleshooting to verify if it is the issue. Heck, I'm sure that vmware does the same with their teaming solution. To me the 'unsupported' thing is FUD. I suppose my thought is that if we are talking about ‘enterprise-grade’ virtualization customers they are also likely ‘enterprise-grade’ networking customers. I’m not sure if other netorking vendors already offer solutions to etherchannel with multiple switches, but if they don’t I’d assume they’ll follo suit soon. I know Juniper has something they call “virtual chassis” for stacking that I’d assume could lead to the same end goal. To me an etherchannel solution is more ‘enterprise’ than a mac-out solution. My guess is Microsoft will probably implement something within hyper-v at some point to do NIC bonding for SMB folks using budget switches, but my point is that there is a solution now. Additionally even if Microsoft implements something similar to what vmware has done it may still be beneficial to opt for etherchannel in an enterprise scenario if you can for better load balancing.

Again my beef is with saying ‘unsupported’ in the first place. It’s an incorrect statement. The NIC vendor supports thier software, therefore it is supported. Microsoft states the use of third party NIC teaming is ‘accepted’ just that the support of that third party software falls to the NIC vendor. It’s not like Microsoft is saying “don’t do it”. Yes Microsoft says that if you are having an issue they may ask you to disable the team as part of the troubleshooting process. That’s not a big surprise. Even if the teaming software was provided by Microsoft I’m sure there are scenarios where they would ask you to disable it in troubleshooting to verify if it is the issue. Heck, I’m sure that vmware does the same with their teaming solution. To me the ‘unsupported’ thing is FUD.

]]> By: slowe http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/comment-page-1/#comment-43113 slowe Wed, 31 Dec 2008 00:55:40 +0000 http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/#comment-43113 Nate, I don't know about your experience, but my experience has been that having cross-stack capable switches (like stacked Catalyst 3750s or VSS-enabled Catalyst 6500s) is generally less common than perhaps one might think. With that in mind, the ability to use a third-party NIC tool to create 802.3ad/LACP-capable bonds is less compelling than the ability to team dissimilar NICs in an active/active mode without any switch configuration required. Finally, with regards to "unsupported"...customers who are deploying enterprise-grade virtualization solutions generally want support from the vendor. "Unsupported" means "not in my data center" for these types of customers. Nate, I don’t know about your experience, but my experience has been that having cross-stack capable switches (like stacked Catalyst 3750s or VSS-enabled Catalyst 6500s) is generally less common than perhaps one might think. With that in mind, the ability to use a third-party NIC tool to create 802.3ad/LACP-capable bonds is less compelling than the ability to team dissimilar NICs in an active/active mode without any switch configuration required.

Finally, with regards to “unsupported”…customers who are deploying enterprise-grade virtualization solutions generally want support from the vendor. “Unsupported” means “not in my data center” for these types of customers.

]]> By: Nate http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/comment-page-1/#comment-43108 Nate Tue, 30 Dec 2008 21:56:11 +0000 http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/#comment-43108 This is a late comment to this post, but I just got around to playing with NIC teaming on one of my IBM x series servers. The server has broadcom NICs, and what I found was using the BACS software I could use the smart load balancing for making a failover team that would work just fine with hyper-v. When I flipped it to being an active-active team things hit the wall. Smart load balancing wasn't the only option though, you can also do an 802.3ad team (etherchannel). After some searching I found a Microsoft presentation that actually suggests using 802.3ad to load balance NICs for hyper-v. Going the etherchannel route means you are using a standards based well supported framework to run your team on. Now that Cisco had released VSS which lets you build an etherchannel across multiple 6500s (you could do it before on stacked 3750s) I don't see why you wouldn't use it. Its a more stable method than mac-out methods, and should result in better load balancing. Also, just because Microsoft isn't the one who supports something doesn't mean it is "unsupported." That's just a marketing scare tactic from vmware. This is a late comment to this post, but I just got around to playing with NIC teaming on one of my IBM x series servers. The server has broadcom NICs, and what I found was using the BACS software I could use the smart load balancing for making a failover team that would work just fine with hyper-v. When I flipped it to being an active-active team things hit the wall. Smart load balancing wasn’t the only option though, you can also do an 802.3ad team (etherchannel). After some searching I found a Microsoft presentation that actually suggests using 802.3ad to load balance NICs for hyper-v. Going the etherchannel route means you are using a standards based well supported framework to run your team on. Now that Cisco had released VSS which lets you build an etherchannel across multiple 6500s (you could do it before on stacked 3750s) I don’t see why you wouldn’t use it. Its a more stable method than mac-out methods, and should result in better load balancing.

Also, just because Microsoft isn’t the one who supports something doesn’t mean it is “unsupported.” That’s just a marketing scare tactic from vmware.

]]> By: VMware’s Virtual Datacenter OS | Planet Virtualization http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/comment-page-1/#comment-41700 VMware’s Virtual Datacenter OS | Planet Virtualization Tue, 23 Sep 2008 16:46:45 +0000 http://blog.scottlowe.org/2008/06/23/more-on-hyper-v-and-nic-teaming/#comment-41700 [...] More on Hyper-V and NIC Teaming [...] [...] More on Hyper-V and NIC Teaming [...]

]]>