Eric's Technical Outlet

Learning the hard way so you don't have to

Network Pathing of P->V

Unfortunately, most of the infrastructure here is still on 100Base-TX, including our core routing equipment. The only gigabit fabric I have available to me are the SLM2024’s purchased explicitly for iSCSI in our Hyper-V environment and a 2960G purchased by a previous administrator to connect the NetApp and enable inter-server communications to the backup system.

The network is scheduled for its long overdue upgrade, but in the meantime, this is what I have to work with. It doesn’t really pose a problem for the Hyper-V deployment, but it can seriously impact P->V performance. Documentation on the exact path traffic takes from the physical machine to its new virtual host is completely non-existent. Its default configuration is to use HTTPS, so Microsoft probably doesn’t consider it a security risk, and they probably also assume that you’re not going to be saddled with a 100Base-TX router.

If networking isn’t your thing, then you need to know that even if both endpoints in communication are plugged into gigabit connectors, if they have to go through a 100Mbps router to communicate, then the entire conversation will be downgraded to 100bps. It makes sense when spelled out, even more so when diagrammed, but it’s not always as obvious when both wires are plugged into the same gigabit layer-2 switch.

The short answer to ensuring gigabit P->V is that the physical server must be able to communicate on the management subnet of the Hyper-V host you are deploying to. To eliminate confusion, the management adapter should be the answering IP when you ping the name of the Hyper-V host. If you haven’t spent any time getting that configured correctly, then you might want to take a spin through the Hyper-V Cluster Installation Master Document and pay special attention to the networking sections.

All the servers I’ve virtualized have contained at least two network adapters, so I configure one on the local subnet of the Hyper-V host with no DNS or gateway entries. Running a TRACERT to the Hyper-V host by name should result in no hops through a router. If the scheduling of the P->V allows for multiple interrupts, I will run “IPCONFIG /ALL > \\netshare\%computername%_IPCONFIG.txt” so that I can recreate the IP scheme once the server is virtualized, and then I reconfigure the primary adapter to be in the proper subnet. Doing this requires a gateway and DNS on that adapter, but in this usage scenario, that is not a detriment. The SCVMM server is the biggest wildcard. In our environment, it behaves unpredictably when placed in the same subnet as the hosts. However, if it is not participating in the local subnet, gigabit transfers won’t work. For that server, I have added a secondary adapter in the relevant subnet with no gateway or DNS entries. In that configuration, it periodically will lose connection to one or both of the hosts, so I only enable that NIC during P->V. If a hiccup occurs during a P->V, the worst case is that it will throttle down to 100Base.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: