Ben Armstrong (aka the Virtual PC Guy) has just finished a presentation at the MVP Summit and presented one little bit of non-NDA info that I can share (and I’m sure Ben will correct me if [there’s an if?] I get it wrong).
Most people (including me up to this morning) assume the following about how VMs connect to a vSwitch in Hyper-V networking:
We assume, thanks to the GUI making things easy for us, is that properties such as VLAN ID and VMQ, which we edit in the vNIC properties, are properties of the vNIC in the VM. We assume then that the vNIC connects directly to the vSwitch. However, it is not actually like that at all in Hyper-V. Under the covers, things work like this:
In reality, the vNIC connects to a switch port. This vSwitch Port is not a VM device at all. And like in the physical world, the vSwitch Port is connected to the switch. In Hyper-V some networking attributes (e.g. VLAN and VMQ) are not attributes of the vNIC but they’re attributes of the vSwitch Port.
What does this mean and why do you care? You might have had a scenario where you’ve had to rescue a non-exported VM and want to import it onto a host. You have some manipulation work to do to be able to do that first. You get that done and import the VM. But some of your network config is gone and you have to recreate it. Why? Well, that’s because those networking attributes were not attributes of the VM while it was running before, as you can see in the second diagram.
When scripting Hyper-V networking like described by John Howard one “sees” and realizes that vSwitchPorts are being used.
http://blogs.technet.com/b/jhoward/archive/2009/07/01/hyper-v-how-to-remove-disabled-virtual-network-adapters-from-the-parent-partition.aspx
or also http://blogs.msdn.com/b/virtual_pc_guy/archive/2009/02/19/script-creating-an-external-only-virtual-network-with-hyper-v.aspx
Nice info. This images (and info) in this (Intel) paper also provide insight:
http://download.intel.com/network/connectivity/virtualization/321968.pdf