Version 1.6 route-venet0

[everclear]

I upgraded to 1.6 and found that one of the OpenVZ instances couldn't connect to the network. The system was BlueOnyx on a CentOS5 template (migrated from a physical machine in the past).

In version 1.6, /etc/vz/dists/scripts/redhat-add_ip.sh now removes /etc/sysconfig/network-scripts/route-venet0.

That means that /etc/sysconfig/network can't contain GATEWAY="192.0.2.1", but must instead contain GATEWAYDEV="venet0".

BlueOnyx assumes if it's an setup that it should set GATEWAY="192.0.2.1" on boot.

Just noting this issue in case anyone else has the problem. Would be good if Proxmox didn't remove the file. I don't know if there is a reason why it would be best to remove it.

 

[tom]

it looks that this change happens in newer vzctl version so I do not think that we can fix this. did you get feedback from blueonyx?

 

[lp86]

I have the same problem, why has this file been deleted? This has caused some serious headaches!

This has affected all of my centos based containers, so its nothing special to blueonyx.

 

[dietmar]

This has affected all of my centos based containers, so its nothing special to blueonyx.

Yes, but what exactly is the problem? GATEWAYDEV="venet0" is perfectly valid?

 

[lp86]

After upgrading to 1.6 none of my centos containers networking works until I recreate the "route-venet0" then they work again.

 

[KenMarcus]

I installed proxmox 1.6 a few days a ago on a new server and have it running locally at 192.168.1.101
I am able to access the "master node" with no problem.

I then created a new openvz container from a blueonyx template and put it at 192.168.1.111. It's set as venet

If I change the /etc/sysconfig/network (in the container) to add the GATEWAYDEV="venet0" as below, and then restart the network, then I am able to access it and ping out from it.

FORWARD_IPV4=false
#GATEWAY=192.0.2.1
GATEWAYDEV="venet0"
HOSTNAME=localhost
NETWORKING=yes


My problem is that after each restart of the container, then /etc/sysconfig/network reverts back to
FORWARD_IPV4=false
GATEWAY=192.0.2.1
HOSTNAME=localhost
NETWORKING=yes

Should I just set up a cron to check and fix it, or is there a more elegant solution?


Ken Marcus

 

[dietmar]

Should I just set up a cron to check and fix it, or is there a more elegant solution?

You use an old version of vzctl? What is the output of

# pveversion -v

 

[KenMarcus]

Dietmar

Thanks for your reply.


The output of the pveversion -v is:

pve-manager: 1.6-2 (pve-manager/1.6/5087)
running kernel: 2.6.32-3-pve
proxmox-ve-2.6.32: 1.6-14
pve-kernel-2.6.32-3-pve: 2.6.32-14
qemu-server: 1.1-18
pve-firmware: 1.0-7
libpve-storage-perl: 1.0-13
vncterm: 0.9-2
vzctl: 3.0.24-1pve4
vzdump: 1.2-7
vzprocps: 2.0.11-1dso2
vzquota: 3.0.11-1
pve-qemu-kvm: 0.12.5-1
ksm-control-daemon: 1.0-4



Ken Marcus

 

[KenMarcus]

Possibly the BlueOnyx system is rewriting it.

I went ahead and just set up a cron to run the script below to check and fix it.

#!/usr/bin/perl
#checks the network config file

$tempfile = "/root/tempfile.txt";
if (-e "$tempfile") { system ("rm $tempfile"); }


$conffile = "/etc/sysconfig/network";

$cat = `cat $conffile`;

if ($cat !~ /#GATEWAY=192.0.2.1/) {
open (FIL,"$conffile") or die "Can't Open $conffile\n";
open (FIL2,">$tempfile") or die "Can't Open $tempfile\n";
while (<FIL>) {
$thisline = $_;

if ( ($thisline =~ /^GATEWAY=192.0.2.1/ ) ) {
print FIL2 "#"."$thisline";
print FIL2 "GATEWAYDEV=\"venet0\"\n";
} else {
print FIL2 "$thisline";
}
}
close (FIL);
close (FIL2);
system ("cp $tempfile $conffile ");
system ("/etc/rc.d/init.d/network restart");

} else
{
#print "The cat is $cat";
}



Ken M

 

[carl.byington]

I have the same problem after 'apt-get -u dist-upgrade' to 1.6, the route-venet0 files disappeared, so I need to manually

route add -net 192.0.2.0 netmask 255.255.255.0 dev venet0
route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.0.2.1

to get networking to work in the vz containers.


pveversion -v
pve-manager: 1.6-5 (pve-manager/1.6/5261)
running kernel: 2.6.18-4-pve
proxmox-ve-2.6.18: 1.6-8
pve-kernel-2.6.18-2-pve: 2.6.18-5
pve-kernel-2.6.18-4-pve: 2.6.18-8
qemu-server: 1.1-22
pve-firmware: 1.0-9
libpve-storage-perl: 1.0-14
vncterm: 0.9-2
vzctl: 3.0.24-1pve4
vzdump: 1.2-8
vzprocps: 2.0.11-1dso2
vzquota: 3.0.11-1
pve-qemu-kvm-2.6.18: 0.9.1-8

I presume that any reboot of these containers will now require manual intervention to recover network access.

Any fix for this? I could always just add those route commands in a cron task.

 

[lp86]

I just chattr +i the file, that stops it from being deleted.