June 22, 2010 at 11:56Hyper-V and Networks
This will probably be the final article in a series on Hyper-V architecture. At one forum, I was advised to write a sequel - “Hyper-V and the invisible virtual machine”, “Hyper-V and the Order of Linux”, I will think about it, and maybe even write about it.
So, this article will talk about how virtual machines in a Hyper-V environment work with network interfaces. As I said in previous articles, network interfaces are the only way that virtual machines interact with each other and with the "outside world". Therefore, it is necessary to understand the features of network communication in a Hyper-V environment.
As you can see in Hyper-V Manager, there are two types of virtual network adapters: Network Adapter and Legacy Network Adapter. They differ among themselves in that the first of them is a synthetic device, and the second is emulated. How synthetic devices differ from emulated ones can be read in the first article, “Hyper-V Architecture”. If anyone is interested, the Legacy Network Adapter emulates a DEC 21140 10 / 100TX 100 MB multiport network card (and therefore only supports 10 / 100Mbps) and is not supported on Windows XP and Windows Server 2003 in the 64-bit version.
It seems that it is not worth explaining that the use of synthetic devices is always preferable, and that is why when creating a new virtual machine, the Network Adapter is added by default. Using the Legacy Network Adapter is recommended only in two cases:
To do this, when creating a virtual machine, you need to uncheck the "Start virtual machine automatically" checkbox, and then, having entered the virtual machine configuration, manually remove the Network Adapter and add the Legacy Network Adapter.
It is also worth mentioning the assignment of MAC addresses to virtual adapters. It can be assigned either automatically when creating a virtual machine (and the range of issuing MAC addresses can be changed in the settings of the Hyper-V server), or manually through the configuration of the virtual machine.
Of course, if there are network adapters, they must connect somewhere. And for this, in Hyper-V there are virtual networks (Virtual Networks), which in essence are the most common virtual switches. Each virtual switch can be connected to both the network interfaces of virtual machines and the physical network interfaces of the server. Virtual networks are of three types, and to make it easier to understand them - take a look at the diagram.
Our server has two network interfaces. When the host OS has just been installed and the interfaces have been configured - TCP / IP is attached to each of them, some other protocols and accordingly - network settings are assigned (IP address, subnet mask, gateway addresses and DNS) - statically or dynamically, in in this case - it doesn’t matter.
Virtual networks (i.e. virtual switches) are of three types: External, Internal and Private. External- A virtual network with access to the “outside world”. When creating a network of type External, you must specify the network interface through which the output to the outside will be carried out (Physical adapter 2). In this case, the physical interface loses all network settings, and a virtual adapter is created in the host OS (Virtual Adapter 1), to which all the necessary protocols and settings are attached. The physical interface remains with only one protocol: Virtual Network Switching Protocol. In addition, Windows Server 2008 R2 introduced the ability to create networks of type External, but still isolate them from the host OS. This is done by unchecking "Allow management operating system to share this network adapter":
ATTENTION:When creating a virtual network of type External, a short-term disconnection of the network connection occurs, and all settings are transferred to a new, virtual adapter. This must be remembered firstly, if the configuration is carried out remotely - the connection may be interrupted, and secondly - you may have to reconfigure Windows Firewall to bind the rules to the new virtual interface.
Internal - an internal virtual network to which only virtual interfaces can connect - virtual machines and host OS. A network of type Internal is not tied to a physical interface, and, accordingly, has no way out.
Private- The same as Internal, except that only virtual machines can connect to such a network. A private network does not have access to the "outside world" or to the host OS.
For a better understanding, I will draw a table in which it will be indicated which interfaces will be connected to the virtual switch and which ones will not with different settings:
Hyper-V supports VLAN (IEEE 802.1Q). To do this, in the properties of the virtual network interfaces there is a checkbox “Enable VLAN Identification”, after activation of which you can enter the VLAN ID. First, of course, you need to configure the switches so that the traffic is tagged with the appropriate IDs, and, of course, install the network adapter drivers in the host OS that support the necessary functions.
You can read more about setting up virtual machines to work with VLAN in Dmitry Makarov’s article .
I can’t finish the article without mentioning the new feature introduced in Windows Server 2008 R2 - support for virtual queues, VMQ.
VMQ support allows you to transfer most of the cost of processing network packets addressed to virtual machines from the host OS onto the shoulders of the network adapter processor. Of course, provided that the network adapter supports this, and integration components are installed in the guest OS.
If VMQ is not used, then the processing of network packets occurs as follows:
At the same time, a virtual switch operating in the space of the parent OS is involved in the distribution of traffic by virtual machines and filtering by VLAN tags. With a large number of virtual machines and with large volumes of traffic, this can lead to some performance degradation, since the server processor has other tasks besides processing network packets. Using VMQ allows you to shift the processing of packets onto the shoulders of the network adapter processor:
A network adapter that supports VMQ is able to independently perform the necessary processing of network packets, and then write data directly to the memory area of the corresponding virtual machine.
The data transfer, both with VMQ, and without it, goes as usual: Virtual network adapter - VMBus - Virtual switch - Physical network adapter.
On this I would like to end the article, and at the same time - a story about the architecture of Hyper-V. In conclusion - I would like to ask: I have a desire to write an article about Live Migration. Will it be interesting to the audience, or has everyone heard about it and everyone knows about it?
So, this article will talk about how virtual machines in a Hyper-V environment work with network interfaces. As I said in previous articles, network interfaces are the only way that virtual machines interact with each other and with the "outside world". Therefore, it is necessary to understand the features of network communication in a Hyper-V environment.
Network adapters
As you can see in Hyper-V Manager, there are two types of virtual network adapters: Network Adapter and Legacy Network Adapter. They differ among themselves in that the first of them is a synthetic device, and the second is emulated. How synthetic devices differ from emulated ones can be read in the first article, “Hyper-V Architecture”. If anyone is interested, the Legacy Network Adapter emulates a DEC 21140 10 / 100TX 100 MB multiport network card (and therefore only supports 10 / 100Mbps) and is not supported on Windows XP and Windows Server 2003 in the 64-bit version.
It seems that it is not worth explaining that the use of synthetic devices is always preferable, and that is why when creating a new virtual machine, the Network Adapter is added by default. Using the Legacy Network Adapter is recommended only in two cases:
- When the guest OS does not support the installation of the integration component;
- When you need access to the network before loading the OS, for example, downloading via PXE to install the OS from the WDS server.
To do this, when creating a virtual machine, you need to uncheck the "Start virtual machine automatically" checkbox, and then, having entered the virtual machine configuration, manually remove the Network Adapter and add the Legacy Network Adapter.
It is also worth mentioning the assignment of MAC addresses to virtual adapters. It can be assigned either automatically when creating a virtual machine (and the range of issuing MAC addresses can be changed in the settings of the Hyper-V server), or manually through the configuration of the virtual machine.
Virtual networks
Of course, if there are network adapters, they must connect somewhere. And for this, in Hyper-V there are virtual networks (Virtual Networks), which in essence are the most common virtual switches. Each virtual switch can be connected to both the network interfaces of virtual machines and the physical network interfaces of the server. Virtual networks are of three types, and to make it easier to understand them - take a look at the diagram.
Our server has two network interfaces. When the host OS has just been installed and the interfaces have been configured - TCP / IP is attached to each of them, some other protocols and accordingly - network settings are assigned (IP address, subnet mask, gateway addresses and DNS) - statically or dynamically, in in this case - it doesn’t matter.
Virtual networks (i.e. virtual switches) are of three types: External, Internal and Private. External- A virtual network with access to the “outside world”. When creating a network of type External, you must specify the network interface through which the output to the outside will be carried out (Physical adapter 2). In this case, the physical interface loses all network settings, and a virtual adapter is created in the host OS (Virtual Adapter 1), to which all the necessary protocols and settings are attached. The physical interface remains with only one protocol: Virtual Network Switching Protocol. In addition, Windows Server 2008 R2 introduced the ability to create networks of type External, but still isolate them from the host OS. This is done by unchecking "Allow management operating system to share this network adapter":
ATTENTION:When creating a virtual network of type External, a short-term disconnection of the network connection occurs, and all settings are transferred to a new, virtual adapter. This must be remembered firstly, if the configuration is carried out remotely - the connection may be interrupted, and secondly - you may have to reconfigure Windows Firewall to bind the rules to the new virtual interface.
Internal - an internal virtual network to which only virtual interfaces can connect - virtual machines and host OS. A network of type Internal is not tied to a physical interface, and, accordingly, has no way out.
Private- The same as Internal, except that only virtual machines can connect to such a network. A private network does not have access to the "outside world" or to the host OS.
For a better understanding, I will draw a table in which it will be indicated which interfaces will be connected to the virtual switch and which ones will not with different settings:
Work with VLAN
Hyper-V supports VLAN (IEEE 802.1Q). To do this, in the properties of the virtual network interfaces there is a checkbox “Enable VLAN Identification”, after activation of which you can enter the VLAN ID. First, of course, you need to configure the switches so that the traffic is tagged with the appropriate IDs, and, of course, install the network adapter drivers in the host OS that support the necessary functions.
You can read more about setting up virtual machines to work with VLAN in Dmitry Makarov’s article .
VMQ
I can’t finish the article without mentioning the new feature introduced in Windows Server 2008 R2 - support for virtual queues, VMQ.
VMQ support allows you to transfer most of the cost of processing network packets addressed to virtual machines from the host OS onto the shoulders of the network adapter processor. Of course, provided that the network adapter supports this, and integration components are installed in the guest OS.
If VMQ is not used, then the processing of network packets occurs as follows:
At the same time, a virtual switch operating in the space of the parent OS is involved in the distribution of traffic by virtual machines and filtering by VLAN tags. With a large number of virtual machines and with large volumes of traffic, this can lead to some performance degradation, since the server processor has other tasks besides processing network packets. Using VMQ allows you to shift the processing of packets onto the shoulders of the network adapter processor:
A network adapter that supports VMQ is able to independently perform the necessary processing of network packets, and then write data directly to the memory area of the corresponding virtual machine.
The data transfer, both with VMQ, and without it, goes as usual: Virtual network adapter - VMBus - Virtual switch - Physical network adapter.
Instead of a conclusion
On this I would like to end the article, and at the same time - a story about the architecture of Hyper-V. In conclusion - I would like to ask: I have a desire to write an article about Live Migration. Will it be interesting to the audience, or has everyone heard about it and everyone knows about it?