Network adapter priority in 2012 R2 Hyper-V Virtual Switches / VMs

Hello all,

I've recently installed our new servers which run Windows Server 2012 R2 using Hyper-V host.
There are 2 VM's both also running Server 2012 R2.

Networking is setup as:
-Public VM Interface (10.25.x.x)
-Internal Only VM Interface (192.168.1.x)
-Management Interface on Hyper-V Host (10.25.x.x)
Note: The Public VM Interface is using NIC Teaming (2 x 1GB NICs) and also Management Interface is in a Team of 2.

The problem i'm having is trying to force the VMs to use the "Internal Only VM Interface" for traffic between the Hyper-V Host and the VM.
(This is due to backup server running on the Hyper-V host trying to transfer data always using the physical switch on external interface).
So far the Hyper-V host refuses to use the Internal interface, always going over the Public VM Interface, unless I manually DISABLE the Public VM NIC inside the virtual machine.
This then forces the Hyper-V host and VM to use the Internal VM interface (massively faster, around 3 x !)

So far i've tried:
-Changing the binding order on the VM and on the Hyper-V host with the Internal Only VM interface at the top)
-Setting "Metric" manually on each adapter in the VM and also Hyper-V host with 5 for the Internal and 10 for the Public
-Rebooted VM
-Ran "nbtstat -R", "ipconfig /flushdns", "netsh interface ip delete arpcache" on both host and VM

When I run "nbtstat -c" on the Hyper-V host, it correctly shows that it is using the Internal Only VM interface (192.168.1.x), but still transfers files over network at the slower speed.

Any ideas would be very welcome!
LVL 8
chrismanncalgavinAsked:
Who is Participating?
 
chrismanncalgavinConnect With a Mentor Author Commented:
In the end the only solution I could find was to set the Windows Firewall settings on each VM to restrict required traffic for certain applications (Yosemite Server Backup) to only use the 192 subnet (VM Only Internal Network).
This is a temporary fix until the backup software company release an update to allow me to bind the software to specific NIC.

Thanks again
0
 
Cliff GaliherCommented:
From a logical standpoint, I understanding wanting to control which MIC traffic goes out from, and MIC binding order SHOULD impact that,

From a practical standpoint though, it should make no difference. Hyper-V creates an extensible switch either way, and the hypervisor will only push traffic out the physical MIC (acting as an uplink port on the virtual switch) if it decides it can't reach the VM (including the "host" OS, which is actually a management VM) another way. In other words, it still uses ARP, etch to make that decision.

So if you are seeing a performance difference AND you are seeing that traffic on your physical NIC, it sounds like you have a subnet setup issue so the hypervisor assumes it must push packets out of the virtual switch.

So with that in mind, I'd even questing if you need the two virtual switches. Like I said, if configured properly , there'd be no performance difference. The only reason to set up multiple v-switches between VMs if is you have some security issue where you need to keep the host VM from seeing that traffic or, in the EXTREMELY rare instance, you are actually saturating all 10GB of the virtual switch and need do some sort of multipath load balancing. Otherwise you could just team the virtual NICs =.
0
 
chrismanncalgavinAuthor Commented:
Hi, thanks for the comments.

What I want to confirm is, should the management interface for Hyper-V ALWAYS be on a different subnet to the VM's to achieve this?
Surely there's other people who put the Hyper-V host in the same subnet as VMs but using different adapters in the same manner I have?
(whether that is best practice or not).
They are currently on the same subnet for ease of management.

I just tested something out and I put the management interface on a seperate subnet, this appeared to work and forced the file transfer to use the Internal Only switch / network for traffic between the host and the guest VMs (resulting in 3 x the speed).

What I would rather find out is if there can we a way to operate the way I have intended with Hyper-V host on same subnet as VMs?
Main reason is the easy of management as mentioned and also the connection to our UPS on the same subnet.
Note: We only have a single subnet at our company plus a small DMZ.
0
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

 
Cliff GaliherCommented:
The separate subnet is purely a security/risk tolerance decision. Some smaller environments will be fine with that. Some won't.

what is a bigger factor though is that the management NIC(s) should NOT have any VMs attached (so no virtual switch) and VM NICs should not be allowed for management (so that box would be unchecked in the virtual network setup.) This makes he topology (both virtual and physical) much easier to understand and packet paths easy to follow. Even if everything is on the same subnet.
0
 
chrismanncalgavinAuthor Commented:
Thanks. Just to confirm that is exactly how I have things configured.

The Management NIC is purely used for this purpose (although on same subnet as VMs), the VM NIC is dedicated to Hyper-V Virtual Switch for VMs.
Also the VM switch DOES NOT have the option "Allow Management Operating System To Share This Adapter" ticked, as per recommendations.

Still no luck yet.
0
 
chrismanncalgavinAuthor Commented:
The solution took at a lot of research and testing on my behalf and in the end was quite different to the suggestions in the comments made.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.