Real server, Multiple IP Addresses, HyperV Virtual Server, How to partition IPs across real and Virtual NICs

hyper-viprouting

This is a slightly difficult problem to explain without same basic background information – I'll try and refine the question later as necessary


Originally, I have a single hosted server (Win 2008R2) with the following range of 8 IP addresses.

- Single NIC ( IP: x.x.128.72 -> x.x.128.79 // Subnet: x.x.255.192 // GW: x.x.128.65 )

After installing Hyper-V and setting up a single virtual server on the same box, I then wanted to assign one of the IP addresses to the virtual server, leaving everything else running normally.

Firstly, I tried using the "External" network, but (even after setting IPs on the "Virtual Adapter" similar to Here but struggled to get networking running at all).

I needed to keep the server running (otherwise I would have spent more time pursuing this approach)

Q1 … Was this a sensible thing to do ? Should I have carried on down this route ?

I then decided to try different approach – Set the HyperV network to "Internal" (visible to Management OS)

- Physical NIC ( IP: x.x.128.72 to .75 // Subnet: x.x.255.192 // GW: x.x.128.65 )
- Virtual NIC ( IP: x.x.128.78 // Subnet: x.x.255.252 // GW: x.x.128.72 ) 
     - Gateway was the same as the IP of the physical NIC )
- Virtual OS-NIC ( IP: x.x.128.77 // Subnet: x.x.255.252 //  GW: x.x.128.78 ) 
     - Gateway was the same as the IP of the host virtual-NIC )

Surprisingly enough, this approach actually worked, and I was able to connect from all the following:
– Internet to/from physical NIC (x.x.128.72)
– physical NIC (x.x.128.72) to virtual-OS-NIC (x.x.128.77) e.g. testing via ping + FTP
– Internet to/from virtual-OS-NIC (x.x.128.72)

The problem I have is that this approach seems to only last for a short while (a few hours).

After this time, it seems that I lose the ability to connect from Virtual-OS-NIC to/from the internet (but I can still connect from the host-OS to the virtual-OS and from the host-OS to the internet)

I have re-tested this a couple of times with the same results … I leave the server on for a few hours (e.g. overnight), and when I come back in the morning, the Virtual-OS loses the ability to route to the internet

I'm not quite sure what to look at next (or whether I'm going about this completely the wrong way )

One "possible relevant item" is that the host-OS is also running RRAS (Routing and Remote Access), but this is only to run a simple VPN

Q2 – Wheat should I be looking at next ? (Any good references / recommendations of what to try)

Would appreciate any thoughts or comments (even if you tell me I'm going about this the wrong way)

*EDIT – Second attempt at using "External" *

Having re-tried with the "External" approach, I again got NO network access…

I then unchecked the "Enable Virtual LAN Identification for Management operating System" … Hey presto, everything sprung into life.

The criticual wording was hidden in the "more about managing virtual networks" link that states

Specifies an identification number that can be used to isolate network traffic from the management operating system

Eventual result … SUCCESS (but without reslution of why it PARTLY worked for limited time)

I later found the following MSDN Blog-Post interesting … Understanding Hyper-V VLANs

Best Answer

Hyper-V is not actually an add-on to Windows at all, it's actually a full hypervisor that takes over. The originally installed OS then becomes a root partition, subordinate to Hyper-V. So what was the base OS is technically a special VM now. To that extent the "special" VM can have hardware passed through (to give the appearance of being a normal OS still). This is the default configuration for almost all hardware after Hyper-V is enabled. When you create a virtual network for Hyper-V that's connected to a physical NIC however, Hyper-V takes ownership of the NIC and it is no longer passed through.

Your NIC configuration should be as follows:

Physical NIC should have the "Microsoft Virtual Network Switch" protocol enabled only (the one exception is when this isn't an actual physical NIC, like a software configured team, you'll usually have some sort of other protocol that can't be disabled).

In Hyper-V Manager's Virtual Network Manager; create a "Network", this will create a Virtual Network Switch in Hyper-V. Make it an External One, attached to the Physical NIC, also check the box to allow the Management OS access. This will create a new vNIC for the Base OS (remember it's actually a special VM, so you're adding a vNIC to this VM...). The new NIC may have to be configured for the IPs taken off the old Physical NIC (depends on the version of Hyper-V that you're using, if it will do this automatically or not).

Create VMs as desired, add vNICs to them and attach those vNICs to the appropriate virtual Network.

External Virtual Networks are attached to a Physical NIC. They allow VMs to connect to the Physical NICs. Internal Virtual Networks always create a new vNIC for the Management OS (there's no checkbox, it's just always done). This allows VMs to communicate with the base OS, but not with any Physical NICs. Private Virtual Networks are for VMs only and does not attach to the Management OS in any way.

You also mentioned problems keeping things running. If you are not using Server grade NIC chips (particularly Intel, Broadcom, QLogic, Emulex, NexGen, Mellanox, etc) expect problems. Similarly be sure you have the latest firmware. If you're running Via or Realtek chips you can save your time and dump the idea of reliable Level 1 Hypervisors (Hyper-V, ESXi, KVM, etc).