Understanding Offline Management

Using the offline management functionality, you can connect to and manage virtual machines and Containers with the help of your favorite web browser. If offline management is enabled for a virtual machine or Container, you can access it via offline services configured for this virtual machine or Container. When you turn on an offline service, one of Container ports becomes always open no matter what state it has been in, and you can access the virtual machine or Container even if it is stopped.

The way offline management works slightly differs for

• Containers (both running and stopped) operating in the host-routed mode, running virtual machines operating in the host-routed mode, and stopped virtual machines working in both network modes

  and

• running virtual machines operating in the bridged network mode

Offline Management for Containers and Stopped Virtual Machines

The following figure shows an example offline management configuration for host-routed Containers (both running and stopped), running host-routed virtual machines, and stopped host-routed and bridged virtual machines:

When offline management is enabled, the server keeps ARP and routing entries for host-routed Containers, running host-routed virtual machines, and all stopped virtual machines. In this case, offline management works as follows:

1. From Parallels Power Panel, a user sends a data packet to port 4643 of IP address 1.2.3.4 that belongs to Container #1 (port 4643 is used by the vzpp offline service).

   Note: For the sake of brevity, this description uses Container #1 as an example. The same, however, is true for Virtual Machine #1 as well.

2. The server keeping an ARP entry for Container #1 receives the packet and then sends the packet to the venet0 adapter.
3. The venet0 adapter is configured to forward all packets coming to port 4643 to a special Service Container, so it transmits the packet to the Service Container instead of sending it to Container #1.
4. The init process running in the Service Container and configured to listen to packets to port 4643 receives the packet and forwards it to the Apache web server running on the server. The Service Container saves the information about the processed packet to a log file in the /var/opt/pva/pp/sve/fs/root/var/log/pavm directory on the server
5. The Apache server interacts with the Parallels Agent to process the packet and sends a reply to the Service Container which forwards it to venet0 .
6. venet0 sends the reply via the eth0 physical adapter back to the Parallels Power Panel user.

Offline Management for Running Bridged Virtual Machines

If a bridged virtual machine is running, the server does not keep any ARP and routing entries for it, and all routing is done via the vme interface of the virtual machine.

A data packet for a running virtual machine first arrives at its virtual interface ( vme in the figure above) and only then is forwarded to venet0 . The remaining steps are the same as those described for Containers and stopped virtual machines.

The fact that the packet comes via the vme interface may cause offline management of a running virtual machine to malfunction in some situations. Consider the following situation:

1. A router in your network receives an incoming packet intended for Virtual Machine #1. The packet contains the IP address and MAC address of the destination virtual machine—that is, of Virtual Machine #1.
2. After the packet is processed, it is sent back to the router via venet0 . This outgoing packet still contains the IP address of Virtual Machine #1 but the MAC address of the server.
3. When the router sees that the MAC address is different, it might drop the outgoing packet.

   

To avoid such problems, you can reconfigure the router to accept packets with the same IP address but different MAC addresses. You can also switch virtual machine's network adapter to the host-routed mode or create an additional network adapter and set it to work in the host-routed mode.