Managing Virtual Networks
A Virtual Network is a grouped number of virtual environments with bridged network interfaces into a single subnet. Using virtual networks you can make groups of virtual environments on a physical server which belong to different subnets invisible to each other. General information on the two network modes in which virtual environments can operate (host-routed and bridged) is provided in Parallels Virtuozzo Containers User's Guide and Parallels Cloud Server documentation. Only virtual environments operating in the bridged mode can be organized into virtual networks. The chart below illustrates different scenarios of virtual network usage and their respective results.
The scheme above illustrates three Virtuozzo physical servers each having a single Ethernet adapter (
eth0). The Ethernet adapters are physically united into a single network. On the Ethernet adapters of Nodes 2 and 3, a VLAN is set up.
Note: On a Linux physical server, a VLAN can be set up by standard means of the OS, and Parallels Virtual Automation provides an interface for creating VLANs on any network adapter. On Windows physical servers, any suitable third-party tools can be used for creating VLANs. Parallels Virtual Automation does not provide an interface to these tools, though it naturally displays the VLAN adapters created in this way.
The steps needed to set up each of the five Virtual Networks shown on the scheme (A-E) are the following:
- A Virtual Network is created either on the general Parallels Virtual Automation screen for the whole Server Group of physical servers or on the screen related to a particular physical server. Whatever the screen, the created Virtual Network will be available for all the registered physical servers. If you use a particular physical server for the Virtual Network creation, you can also specify to what network interface card (NIC) of the current physical server the Virtual Network will be assigned, if at all.
- Containers from one or more physical servers are added to the Virtual Network, thus creating a separate subnet. Only the bridged interfaces of the Containers are involved in this process; host-routed interfaces cannot be added to Virtual Networks. You should make sure that these Containers can also communicate with each other on the IP level, i.e. their IP addresses/net masks are compatible with each other.
- For each physical server that hosts the Containers included in the Virtual Network, the Virtual Network should either be assigned to one of the physical server's physical/VLAN adapters or defined locally for the physical server (the latter variant is possible if the Containers of only one physical server are included in the Virtual Network).
Using the method above, the configuration shown on the scheme can be created. Each of the five Virtual Networks serves to group two or three Containers of one or two physical servers - this is shown with double-headed arrows connecting the Virtual Network border with the Container bridged interfaces. Each of the Virtual Networks is either local for the physical server or bridged to some adapter - the latter case is illustrated with double-headed arrows connecting the Virtual Network border with the physical servers' Ethernet or VLAN interfaces.
Let us see the effects of each of the combinations shown:
- Container 101 has only a host-routed interface and thus is not included in any Virtual Network. It is visible by any Containers and other hosts that can access the
eth0 adapter of physical server 1.
- Containers 102, 103, and 201 are united into Virtual Network A. They can communicate with each other and other hosts because on each physical server, Virtual Network A is assigned to the
- Container 201 has two bridged adapters, with the second one included in Virtual Network B together with Container 202. Virtual Network B is not assigned to any interface on the physical server, and still Container 202 is able to communicate with the outer world thanks to the fact that Container 201 is bridged to
eth0 on the physical server through Virtual Network A. Of course, for this to be possible, all the bridged adapters of Containers 201 and 202 should belong to one and the same IP subnet.
- Virtual Network C with Containers 203 and 204 is another example of a Virtual Network defined locally on the physical server, but unlike Virtual Network B, its Containers can only see one another and no other hosts, because there is no bridging to any of the adapters of the physical server.
- Containers 205 and 301 are united into Virtual Network D through the respective adapters of their physical servers much like the Containers of Virtual Network A. However, Virtual Network D is bridged not to the physical interface on both of the physical servers, but to the VLAN interfaces created on the physical ones. This results in the isolation of Containers 205 and 301 within this VLAN so that they are visible to each other but not to any other external hosts.
- Virtual Network E is the most complex example on this scheme. The Virtual Network is not assigned to any of the physical server's interfaces, so it remains local for the physical server. In addition to its inclusion in Virtual Network E, Container 302 enjoys a host-routed interface, so it can effectively communicate with the outer world. But what about Container 303? Unlike Container 202 in Virtual Network B, it cannot be simply included in a single IP subnet with the bridged interface of its fellow Container that would be bridged, in its turn, to the physical server's interface. For Container 303 to be able to go outside the limits of the Virtual Network, network fine-tuning should take place. In particular, the Ethernet frame that is sent by Container 303 to an external host should come to Container 302, lose its framing, thus becoming a pure IP packet, be routed through the host-routed interface of Container 302 to the physical server's adapter eth0, put on a new framing to become again an Ethernet frame (different from the original one because the source MAC address becomes that of the physical server, and not that of Container 303), and go further. Paving the way for a response to get successfully to Container 303 is also a challenge. Thus, if you are not a network guru, chances are Container 303 will remain isolated in the scope of Virtual Network E. Luckily, Parallels Virtual Automation provides easier ways of setting up your network, as was illustrated above.
Note: Any interface on the physical server can be assigned to only one Virtual Network. If you need to create more Virtual Networks on one physical server, either use more physical adapters or create VLANs.