Search Engine: Elastic

Article ID: 114171, created on Jun 20, 2012, last review on May 10, 2014

  • Applies to:
  • Operations Automation


Linux Shared VPS is not accessible from POA Management Node using CORBA ports range #8352 - #8500, as a result the shared hosting server is marked as unmanageable in POA and all tasks related to services on the server fail.

There is no firewall at all between Shared VPS and POA Management Node (MN) or it is configured correctly to allow connections between POA MN and the Shared VPS using mentioned above CORBA ports range.

An attempt to connect from Shared VPS to POA Management Node fails (assuming that the command below is being run on Shared VPS and is the backnet IP address of POA MN):
vps# telnet 8354
telnet: connect to address Connection timed out

Routing table in the VPS looks like this:
# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface   *        U     0      0        0 venet0     *          U     0      0        0 venet0
default         UG    0      0        0 venet0


The reason of problem in this case is that default route for backnet is lost in the Shared VPS, more details are provided below.

When Shared VPS is created from POA, it usually gets assigned two IP addresses – one from external network (frontnet), and another one from shared VPSs backnet IP pool. Both IP addresses are added to the same host-routed network interface venet0 on the VPS. In order for the backnet IP to work properly a static route should be configured inside of such VPS.

POA task with name Configure Agent in VPS created during new host registration in POA creates such route in the file /etc/sysconfig/network-scripts/route-venet0 inside of the VPS. For example, if backnet IP address of the VPS is, POA adds the following route to the file:  dev venet0  scope link  src

In earlier POA versions (prior to POA 2.9) route was being added to the /etc/rc.local file instead of /etc/sysconfig/network-scripts/route-venet0 file, it had the following syntax:
ip route add dev venet0 src

POA creates the task Configure Agent in VPS only once when shared VPS is being created and registered in POA. So, if POA was upgraded to the latest version, routes in the /etc/rc.local file may still exist for old Shared VPSs registered in the past (before POA 2.9). This also means that default route for backnet is absent in the correct file /etc/sysconfig/network-scripts/route-venet0.

So, if default route for backnet is present only in the /etc/rc.local file and is absent in the file /etc/sysconfig/network-scripts/route-venet0 then the following problem may occur: if network service is restarted inside the Shared VPS then default route for backnet will be lost and connectivity to such VPS from POA will be also lost (as shared VPSs use backnet IP address to communicate with POA Management Node).

Also default backnet route can get lost when some IP address is removed from Shared VPS, either manually on VPS Hardware Node by running the command vzctl set CTID –ipdel IP_ADDRESS or by POA task Unconfigure IP address from host, because during IP address removal venet0 interface can be restarted (by ifdown & ifup commands).


To solve the issue manually add route configured in the /etc/rc.local file to the /etc/sysconfig/network-scripts/route-venet0  file using the following format:
NETWORK/MASK dev venet0  scope link  src VPS_IP_ADDRESS

where NETWORK and MASK - IP network and its mask, VPS_IP_ADDRESS - IP address of the Shared VPS. E.g., the routing rule may look like this:  dev venet0  scope link  src

Restart network service inside VPS after you modified the /etc/sysconfig/network-scripts/route-venet0  file:
# service network restart

caea8340e2d186a540518d08602aa065 5356b422f65bdad1c3e9edca5d74a1ae e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF