کد:
http://blogs.technet.com/b/mrsnrub/archive/2009/12/06/hyper-v-virtual-networks.aspx

The most common questions that I get on Hyper-V setups relates to the networking configuration, and it seems to be common thing to get wrong, so I’ll try to go through the 3 types of virtual network we have, and how they differ.

A private network can only be used by the child partitions, so consider this a “switch for a purely virtual environment”.
An internal network is the same as a private network, except that the parent partition (physical host) acquires a virtual network adapter which is automatically connected to this virtual switch.
Neither of these 2 types of virtual network require a physical network adapter – so if you are working with a lab or test environment then it’s perfectly fine to have no NICs whatsoever.

The third type of virtual network is the external network – this requires a physical NIC which Hyper-V will now take ownership of and unbind every protocol except the “Microsoft Virtual Network Switch Protocol”.
This network type allow communication between any partition connected to it and physical machines on the network connected to the physical NIC.
The physical NIC has now effectively been converted into a switch, which is why there should be nothing other than the “Microsoft Virtual Network Switch Protocol” bound to it – a common mistake here is to think “ah, the host doesn’t have any IPv4 settings, I’ll manually re-enable this…” – do not do this.
Similar to the internal network, when you create an external network the parent is given a new virtual network adapter which is connected to this virtual switch.
The automatically-created virtual network adapters for external networks will be given the original protocol configuration of the physical NIC, so this respect the network adapter as seen by the parent partition OS has been “virtualized”.
If the external network is dedicated for child partitions (recommended configuration – the host should have its own management interface which is not associated with Hyper-V at all) then it is perfectly safe to disable the virtual network adapter associated with the external network (note, do not disable the adapter which is the external network).

Take a look at the following diagram, with some explanatory text below:

The 1 physical server here, Doc, is the Hyper-V host/parent partition which has 2 physical NICs present: NIC1 and NIC2.
NIC1 has IP settings bound on it and it is not used with any external network – this would be the management interface so we can communicate with the parent partition even if we are reconfiguring Hyper-V or have the hypervisor not running.
NIC2 has the icon of a switch because it has been taken over by Hyper-V and now (just like a regular switch) does not have any IP protocol bound to it – the parent partition has had a virtual NIC created which is connected to this network (this is the one safe to disable if the interface should be for the child partitions only).
Virtual machines Sneezy and Happy are able to communicate with the real world through the external network.

In addition to the external network, the blue switch represents an internal network – this creates a new virtual network adapter in the parent partition which is used to allow communication between Sleepy, Bashful, Doc and Dopey (as I decided to multi-home Dopey on an internal and private network in this example).

The red switch is for a private network – Doc does not get to connect to this switch so direct communication with Grumpy is not possible except from Dopey.
If Dopey doesn’t have any kind of routing or proxy service present, nothing other than Dopey can talk to Grumpy, and vice versa.
This means the parent partition OS sees a total of 4 network adapters – the 2 representing the physical NICs, 1 for the external network and 1 for the internal network.

Now for some screenshots from my home (W2K8R2) setup, where the host has 2 NICs: 1 for management of the host and 1 dedicated for the child partitions:

Note that I gave the network adapters in the host OS meaningful names BEFORE I created any virtual networks – this is personal taste but makes administration so much easier than dealing with “Local Area Connection #4” and trying to figure out what that is and if it’s safe to disable it.
You can see I disabled the virtual NIC which Hyper-V created for the parent when I made the external network, as it’s dedicated for child partition use.

When I created the external network, I named it based on the NIC which is associated with the network (luckily the machine has 2 different brand NICs onboard to make this easier).

Here you can see the physical NIC owned by Hyper-V for the external network should have nothing other than the “Microsoft Virtual Network Switch Protocol” bound to it – this is “just a switch” now.

Here are the properties of the other physical NIC which is used for management of the host.

Do not toggle the binding for the “Microsoft Virtual Network Switch Protocol” on any interface manually – the Hyper-V Virtual Network Manager UI uses this flag to see if a physical NIC is already associated with an external network before attempting to create one – this has tripped up several people in the past, and what you get is something like the following error:
Error applying new virtual network changes
Setup switch failed
The switch could not bind to {interface name} because it is already bound to another switch.
If you get the option to create an external network on an interface but get this error, this is the only time you should remove that binding manually and retry.

This is all just about the creation of virtual networks – you still have to go into the settings of each of the virtual machines and give them a network adapter (legacy or synthetic) for each of the virtual networks it should connect with simultaneously, selected through a drop-down list.
Neither Hyper-V or Virtual Server before it allow “host drive connection”, “USB device redirection” or “drag & drop of files”, even with Integration Services (or VM Additions) installed – this is a potential security hole, so you need to configure a common network between the parent and child partitions if you want to transfer files in & out.

Possible workarounds if you really don’t want to set up a network to transfer files between the parent and child partitions:
- create an ISO on the parent with the files to copy into the child, and mount it as a virtual DVD
- with the VM shut down, mount the VHD file from the child partition on Windows 7 /Server 2008 R2 directly through Disk Management (this is useful for getting MEMORY.DMP files out of VMs that are bugchecking during boot too)

A final note on Hyper-V networking – there is no virtual DHCP server, so you need to either set up your own, use an existing one (if using an external network) or assign IPv4 addresses manually.
I tend to use the 3 different private subnets to easily identify which type of network the machine is meant to connect with, and also avoid potential disasters if I accidentally connect to the wrong one:
- 172.16.0.1 thru 172.31.255.254 for PRIVATE networks
- 192.168.0.1 thru 192.168.255.254 for INTERNAL networks
- 10.0.0.1 thru 10.255.255.254 for EXTERNAL networks

A final note: just as with physical machines, if you multi-home a VM then check your protocol bindings, network adapter order and gateway/route settings to make sure you avoid performance or security issues



موضوعات مشابه: