Managing Virtual Networks

A Virtual Network is a Virtuozzo notion denoting the grouping of a number of Containers with bridged network interfaces into a single subnet. Using Virtual Networks is also necessary if you want to single out groups of Containers on a Hardware Node into separate subnets to be invisible to each other. General information on the two network modes in which Containers can operate - namely, host-routed and bridged modes - is provided in Parallels Virtuozzo Containers User's Guide. Only those Containers that operate in the bridged mode can be united into Virtual Networks. The picture below illustrates different scenarios of how Virtual Networks can be used and what are the effects of this or that toponomy.

The scheme above illustrates three Virtuozzo Hardware Nodes 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 Node, a VLAN can be set up by standard means of the OS, and Parallels Infrastructure Manager provides an interface for creating VLANs on any network adapter. On Windows Nodes, any suitable third-party tools can be used for creating VLANs. Parallels Infrastructure Manager 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:

1. A Virtual Network is created either on the general Parallels Infrastructure Manager screen for the whole Virtuozzo Group of Hardware Nodes or on the screen related to a particular Hardware Node. Whatever the screen, the created Virtual Network will be available for all the registered Hardware Nodes. If you use a particular Hardware Node for the Virtual Network creation, you can also specify to what network interface card (NIC) of the current Node the Virtual Network will be assigned, if at all.
2. Containers from one or more Hardware Nodes 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.
3. For each Hardware Node that hosts the Containers included in the Virtual Network, the Virtual Network should either be assigned to one of the Node's physical/VLAN adapters or defined locally for the Node (the latter variant is possible if the Containers of only one Node 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 Hardware Nodes - 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 Node or bridged to some adapter - the latter case is illustrated with double-headed arrows connecting the Virtual Network border with the Nodes' 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 Hardware Node 1.
• Containers 102, 103, and 201 are united into Virtual Network A. They can communicate with each other and other hosts because on each Node, Virtual Network A is assigned to the eth0 adapter.
• 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 Node, 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 Node 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 Node, 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 Hardware Node.
• Containers 205 and 301 are united into Virtual Network D through the respective adapters of their Hardware Nodes much like the Containers of Virtual Network A. However, Virtual Network D is bridged not to the physical interface on both of the Nodes, 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 Node's interfaces, so it remains local for the Node. 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 Node'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 Node'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 Hardware Node, 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 Infrastructure Manager provides easier ways of setting up your network, as was illustrated above.

Note: Any interface on the Node can be assigned to only one Virtual Network. If you need to create more Virtual Networks on one Node, either use more physical adapters or create VLANs.

Please send us your feedback on this help page