3

I have a pretty simple configuration: Windows Server 2012 Hyper V Host, with two VMs (both Server 2012), one for IIS, one for SQL Server. They're all connecting through the physical NIC

Last night I tried adding a virtual switch, and setting up virtual NICs on the two VMs (in addition to the physical NIC).

I hadn't switched over the servers to actually use the virtual NICs yet, but for some reason, this destroyed the connection speed between the two VMs -- even though the virtual NICs weren't being used. We're talking from 200-500 milliseconds to 30-90 seconds per request!

So this morning, after seeing the terrible impact it had on my site, I disabled the two virtual NICs, since that's all that I changed, and sure enough, speeds came back.

Ultimately I need to get them switched over to using the v-NICs, but I need to get past this issue first.

What could be causing this? And what can I do to troubleshoot it?

Additional details:

The setup is actually very simple (which may be part of my problem, I may be oversimplifying what is needed to get this set up).

I have a single server with a single (physical) NIC. Currently, this NIC is used for communication between the v-host and the internet, as well as between the two VMs and the internet. It is also used for intra-communication between the two VMs.

However, I'm trying to switch the intra-communication to go through the virtual swtich via vNICs, freeing up the physical NIC to be used only for external communication.

So I added an internal virtual switch to the v-host, then added a virtual NIC to each VM.

After doing this, that's when my connection speeds -- over the physical NIC -- dropped drastically. Disabling the vNICs (through the VMs' network configuration) restored the speed back to normal.

Below are screens of the VM configuration for the external physical NIC and internal vNICs (on just one VM, as they're both identically configured).

Another round of details

In digging a bit more on the issue, it appears that Broadcom NICs are notorious for performance issues. This server has dual Broadcom BCM5716C NICs. Here are some links to discussion of known issues:

Slow Network Access Within Virtual Machines - Broadcom and Hyper-V

Hyper-V Virtual Machine Very Slow Network – VMQ – Broadcom

So I started playing with settings, disabling various settings, one at a time. None of the changes seemed to have any impact on the issue -- if I enable the guest vNIC, the load speeds drop to 25+ seconds. Disable it again, they return to 250ms -- a factor of 100!

I also tried installing the latest drivers from Broadcom, no difference.

At this point, I feel it's an issue of compatibility between the Broadcom NIC and Hyper-V. But I don't want to order new NICs and go through the trouble of shutting the site down, installing and configuring them, only for the problem to persist.

So it would be nice if I could definitively rule in or out the NIC.

Physical NIC configuration on the switch manager Physical NIC configuration on the switch manager

Virtual switch configuration on the switch manager Virtual switch configuration on the switch manager

Physical NIC configuration on the DB VM Physical NIC configuration on the DB VM

Virtual NIC configuration on the DB VM Virtual NIC configuration on the DB VM

| improve this question | | | | |
  • So, you've configured NIC pass-through to guests using SR-IOV and now on the same NICS, you're configuring vSwitches? Is that correct? – MDMarra Sep 15 '13 at 13:25
  • @MDMarra Sorry, this is a new setup for me, so I don't have much experience with virtualization (which is why I'm seeking help -- I've very likely configured it wrong). I'm not sure I'm explaining it accurately. I'll update the comments w/ some screens and more info. – Jerad Rose Sep 15 '13 at 17:18
  • @MDMarra Additional details added. – Jerad Rose Sep 15 '13 at 18:57
  • AFAIK there's no such thing as physical NIC passthrough on Hyper-V. You've created a vswitch named "Physical NIC", which is mapped to a physical adapter and enabled management OS use. On each VM, there is a vNic using this switch. Why do you want to switch from one vswitch to another? Apart from the "new" one not being connected to anything I really don't see the point. As for why one connection is slower than the other I have no idea. – Trondh Sep 17 '13 at 6:38
2

I have a very similar setup. I found the answer here (Extremely slow file transfers to Hyper-V VM on local machine)

With the Broadcom chipset I disabled the virtual queues and all latency disappeared. Make this change on the physical NIC, not the virtual NIC.

| improve this answer | | | | |
0

AFAIK there's no such thing as physical NIC passthrough on Hyper-V. You've created a vSwitch named "Physical NIC", which is mapped to a physical adapter and enabled management OS use. On each VM, there is a vNic using this switch. Why do you want to switch from one vswitch to another? Apart from the "new" one not being connected to anything I really don't see the point.

Hyper-V is smart enough to only send traffic from the vswitch onto the physical nic when traffic is routed out of the host, which means you're already doing what you're trying to achieve.

| improve this answer | | | | |
  • That's very possible, but I keep getting random "Named Pipe" and other connection-related issues, which makes zero sense on a virtual NIC. Why would there be any collisions or any other physical-NIC-like symptoms on a vNIC? I know that's another question entirely, but I still don't understand why setting up an internal NIC has such an impact on the external NIC. I also can't find a site/blog/diagram that walks through setting up a simple configuration like this -- seems like this setup would be very common (maybe no one thinks a guide is necessary). – Jerad Rose Sep 17 '13 at 12:28
  • You mean like this? virtualizationadmin.com/articles-tutorials/… Named pipe issues? – Trondh Sep 17 '13 at 13:27
  • Yeah, that's a good article, thanks. I think that second diagram (Figure B) is what I'm trying to set up. I'll spend some time reading that tonight. Named pipe issue = Named Pipes Provider: Could not open a connection to SQL Server {53}.. But again, I need to post a separate question for this (not sure if that belongs on SO or serverfault). – Jerad Rose Sep 17 '13 at 13:56
  • Try dba.stackexchange.com. – Trondh Sep 17 '13 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.