Hyper-V and networking

For those who have worked with hosted virtualisation (Microsoft Virtual PC and Virtual Server, VMware Workstation and Server, Parallels Desktop, etc.) and haven’t experienced hypervisor-based virtualisation, Microsoft Hyper-V is fundamentally different in a number of ways. Architecturally, it’s not dissimilar to the Xen hypervisor (in fact, there are a lot of similarities between the two) and Xen’s domain 0 is analogous to the parent partition in Hyper-V (effectively, when the Hyper-V role is added to a Windows Server 2008 computer, the hypervisor is “slid” underneath the existing Windows installation and that becomes the parent partition). Subsequent virtual machines running on Hyper-V are known as child partitions.

In this approach, a new virtual switch (vswitch) is created and the physical network adapter (pNIC) is unbound from all clients, services and protocols, except the Microsoft Virtual Network Switch Protocol. The virtual network adapters (vNICs) in the parent and child partitions connect to the vswitch. Further vswitches may be created for internal communications, or bound to additional pNICs; however only one vswitch can be bound to a particular pNIC at any one time. Virtual machines can have multiple vNICs connected to multiple vswitches. Ben Armstrong has a good explanation of Hyper-V networking (with pictures) on his blog.

One exception relates to the connection of virtual machines to wireless network adapters (not a common server scenario, but nevertheless useful when Windows Server 2008 is running on a notebook PC). The workaround is to use Internet connection sharing (ICS) on the wireless pNIC and to connect that to a vswitch configured for internal networking in Hyper-V. Effectively, the ICS connection becomes a DHCP server for the network, presented via the internal vswitch and I’m pleased to find that the same principle can be applied to mobile data cards. Interestingly, Hyper-V seems quite happy to bind directly to a Bluetooth connection.

Hyper-V network connection example

Using this approach, on my system, the various network adapters are as follows:

  • Dial-up adapters, including an HSDPA/HSUPA modem which I have shared to allow a VMs to connect to mobile networks in place of wired Ethernet.
  • Local Area Connection – the pNIC in my notebook PC, bound only to to the Microsoft Virtual Network Switch Protocol.
    Wireless Network Connection – the WiFi adapter in my notebook PC (if there was WiFi connectivity where I am today then this could have been shared instead of the data card.
  • Local Area Connection 3 – the Bluetooth adapter in my notebook PC.
  • Local Area Connection 4 – the external vswitch in my Hyper-V installation, connected to the external network via the pNIC.
  • Local Area Connection 5 – another vswitch in my Hyper-V installation, operating as an internal network, but connected using the method above to the shared HSDPA/HSUPA modem.

This gives me plenty of flexibility for connectivity and has the useful side-effect of allowing me to circumvent the port security which I suspect is the cause of my frequent disconnections at work because the physical switches are configured to block any device presenting multiple MAC addresses for the same port.


I haven’t really come across Fujitsu PCs and servers since I left ICL in 2000; but now I’m back on board at Fujitsu Services (same company – different name), not surprisingly, my new work laptop is a Fujitsu Siemens Lifebook S7010D. It seems like a really good notebook PC (although I find the absence of quick launch function keys in order to make room for a PIN-entry security pad a little strange – I would have preferred an integrated fingerprint reader like those offered on selected IBM ThinkPads).

When I brought the laptop home and the onboard wireless LAN card didn’t detect any of the four wireless networks within range of my home office, I naturally assumed it was broken (based on previous experience with a Dell Latitude D600); but then I had a similar problem with Bluetooth communications so I did the unthinkable (for any self-respecting IT infrastructure consultant) – I called the IT helpdesk.

In what must have qualified for my most embarrassing helpdesk call ever, I found out that there is a switch on the front of the PC to enable/disable the wireless LAN and Bluetooth module. Once enabled, everything sprung into life. Doh!

Maybe next time I’ll RTFM.

Bluetooth Drivers for Dell TrueMobile 300

Following my previous post about the trouble I have had getting the Bluetooth hardware in my Dell Latitude D600 repaired, I then had to reinstall the Dell TrueMobile 300 Bluetooth driver. During the three week wait to get the hardware repaired, I had installed Windows XP SP2 and as Stuart Preston reported on his blog, the Dell drivers do not function correctly under SP2, resulting in a requirement to use the native Microsoft drivers (which are less functional).

A hunt around the Dell Community Forum revealed many unhappy users (bizarrely mostly blaming Microsoft for releasing SP2!), but no real solution until a Google search came up with Dell support document FA1090448 (a search of the Dell website had failed to locate this), pointing to an updated driver that seems to fix the problem.