Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
    
@ChrisS - The server in question is my own hosted server (and currently connected to an IPKVM to allow me to recover from mistakes if necessary) ... Therefore I am well aware of any risks... I have had experience in the past with IP-routing / monitoring and setting up subnets and routing tables. I know what I want to achieve (but I think it is the Hyper-V that is throwing me slightly) - I understand your concern, but can assure you that I am certainly not a novice at routing, just hitting problems when a solution works fine for 6 hours and then spontaneously stops. –  Steven_W Nov 26 '11 at 1:19

1 Answer 1

up vote 3 down vote accepted

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).

share|improve this answer
    
Thanks @ChrisS, this confirms that the original (and simpler) method that I was TRYING to achieve (External) is the method that should have worked. Since it is a weekend, I think I'll have another go at trying to get this approach working. –  Steven_W Nov 26 '11 at 15:52
    
For reference, the physical NIC is a "Intel(R) 82578DM Gigabit Network Connection", though I'm not sure how the firmware on this would interfere with IP routing (I could still access the host-OS normally (and host-to-virtual), just not virtual-to-internet) .... Will let you know how I get on. –  Steven_W Nov 26 '11 at 15:54
    
Final result (shown in question-edit above) was a success .. "External" is clearly the "ideal" approach, though it seems that the "Internal" method could be made to work, but would be a horrible kludge with strange side-effects. –  Steven_W Nov 26 '11 at 16:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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