back       next

openvz

Unable to open pty: No such file or directory

Udev is a dependency of xorg and other development packages that breaks OpenVZ containers if installed or upgraded.

Re-create the missing devices after an upgrade via:

vzctl exec {VEID} /sbin/MAKEDEV tty
vzctl exec {VEID} /sbin/MAKEDEV pty

For a permanent fix, edit /etc/rc.sysinit to disable udev and auto-repair the devices:

#/sbin/start_udev
/sbin/MAKEDEV tty
/sbin/MAKEDEV pty

vzdump LVM snapshots kernel errors

On running daily lvm snapshot backups via vzdump on OpenVZ servers, I noticed the below Kernel errors in logwatch reports.


WARNING:  Kernel Errors Present
    Buffer I/O error on device dm-4,  ...:  22 Time(s)
    EXT3-fs error (device dm-4): e ...:  60 Time(s)
    lost page write due to I/O error on dm-4 ...:  22 Time(s)

This would show up on busy servers only, probably caused due to lvm snapshot running out of space.

I edited "/usr/bin/vzdump" and increased the size from 500m to 1000m which seems to have resolved the issue for now.


run_command (\*LOG, "$lvcreate --size 1000m --snapshot --name vzsnap /dev/$lvmvg/$lvmlv");

Loss in network connectivity on OpenVZ host

I was seeing loss in network connectivity when an OpenVZ container is stopped and noticed that the bridge mac address was taking the mac address of an existing containers virtual network interface instead of the physical interface.

The solution was to set the bridge mac address to the physical interface:

/sbin/ifconfig br0 hw ether $(ifconfig eth0 | awk '{print $5; exit}')

Here is what my "/etc/sysconfig/vz-scripts/vps.umount" looks like which is used to remove routes to container with veth-bridge from bridge.

Weekly backups of all OpenVZ container

Here's is a simple shell script to run a weekly lvm snapshot dump of all OpenVZ containers using the vzdump utility:

#!/bin/bash
# ve_dumps.sh
# Dump all VEs

# Todays' date
DATE=$(date +%d)

# Paths
BAK_PATH=/opt/bak/vz_dumps
# Week of month
BAK_DIR=$(cal | awk -v date="${DATE}" '{ for( i=1; i <= NF ; i++ ) if ($i==date) { print FNR-2 } }')

# Function to check and remove previously failed snapshot.
check_vzsnap() {
  OUTPUT=`/usr/sbin/lvdisplay | grep vzsnap`
  [ -n "$OUTPUT" ] && lvremove -f /dev/vg0/vzsnap
}

# Function to perform backup.
backup() {
  # Check and create the required backup directory
  [ -d "${BAK_PATH}/${BAK_DIR}" ] || mkdir -p ${BAK_PATH}/${BAK_DIR}
  # do dumps
  echo "Starting dump at `date`"
  /usr/bin/vzdump --exclude-path '.+/log/.+' --exclude-path '.+/bak/.+' --exclude-path '/tmp/.+' --exclude-path '/var/tmp/.+' --exclude-path '/var/run/.+pid' --snapshot --dumpdir=${BAK_PATH}/${BAK_DIR} --compress --all
  echo "Completed dump at `date`"
}

# Main ############################

# Remove previously failed snapshot
check_vzsnap

# Run backups
backup

exit 0

Bridge Networking On OpenVZ Containers Using VETH Devices

1. Host will be open on LAN and guests on WAN. Additionally, there is a bridged LAN for guests.
2. We will be using bridge networking for protecting the Host Network and saving IP addresses, also giving flexibility with the guest network setup.
3. Configure LAN Eth1 port to 192.168.1.2
4. WAN Eth0 port is not assigned any IP address.
6. Install the required bridge-utils package via:

yum install bridge-utils

* Network:

# cat /etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=<host.domain.tld>
GATEWAY=192.168.1.1
GATEWAYDEV="eth1"

* WAN Bridge device br0:

# cat /etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
BROADCAST=xxx.xxx.xxx.xxx
NETMASK=255.255.255.24
NETWORK=xxx.xxx.xxx.xxx
ONBOOT=yes
GATEWAY=xxx.xxx.xxx.xxx
TYPE=Bridge

* WAN eth0 device:

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
HWADDR=00:30:48:65:12:b4
ONBOOT=yes
TYPE=Ethernet
BRIDGE=br0

* LAN Bridge device br1:

# cat /etc/sysconfig/network-scripts/ifcfg-br1
DEVICE=br1
ONBOOT=yes
TYPE=Bridge
IPADDR=192.168.1.2
NETMASK=255.255.255.0
GATEWAY=192.168.1.1

* LAN eth1 device:

# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
HWADDR=00:30:48:65:12:b5
ONBOOT=yes
TYPE=Ethernet
BRIDGE=br1

Create users in OpenVZ Containers

Helper script to create users on all OpenVZ VEs simultaneously:

#!/bin/bash
# create_ve_users.sh
# Usage: ./create_ve_users.sh <username> <password> <uid> <group1,group2>

USERNAME=$1
PASSWORD=$2
USERID=$3
GROUP=$4
EXPECTED_ARGS=4

OUT_FILE=.create_users_$$

if [ $# -ne $EXPECTED_ARGS ]
then
  echo "Usage: `basename $0` <username> <password> <uid> <group1,group2>"
  exit 65
fi

VE_LIST=$(/usr/sbin/vzlist -H -o veid)

for VE in ${VE_LIST}
do
        vzctl exec $VE \
                "echo useradd -u $USERID -G $GROUP -p \''`openssl passwd -1 $PASSWORD`'\' $USERNAME > /tmp/${OUT_FILE} ; \
                sh /tmp/${OUT_FILE} ; \
                rm -f /tmp/${OUT_FILE}"
done

exit 0

Update OpenVZ containers

If you manage several OpenVZ containers, here is a simple bash script to keep the OpenVZ containers upto date.

#!/bin/bash
# vzyum_updates.sh
# updates VEs

VE_LIST=$(/usr/sbin/vzlist -H -o veid | grep -v Warning)

for VE in ${VE_LIST}
do
  /usr/bin/vzyum $VE update
done

exit 0

OpenVZ CentOS template cache creation with vzpkgcache

Following the instruction over at OpenVZ Wiki, I've had no problems with the installation and creation of templates prior to CentOS-5.2 on x86_64 systems. However, with the latest set of updates to CentOS-5.2, the vzpkgcache seems to have been broken as sysklogd is no longer being installed by default. Below is how I got it to work:

Note: edit /vz/template/centos/5/x86_64/config/minimal.list and append .x86_64 to all except for the addons packages. Then run:

# vzpkgcache -f centos-5-x86_64-minimal

which gives the below error at the end:

sed: can't read /etc/init.d/syslog: No such file or directory
ERROR: Script install-post failed

The solution was to edit "/vz/template/centos/5/x86_64/config/install-post" and set syslog and syslog.conf sed replacements with exit status of "0".

# Disable klogd
$VZCTL exec2 $VEID \
        "sed -i -e 's/daemon\\ klogd/passed\\ klogd\\ skipped/' \
                -e 's/killproc\\ klogd/passed\\ klogd\\ skipped/' \
                        /etc/init.d/syslog; exit 0"
...
# Disable fsync() in syslog
$VZCTL exec2 $VEID \
        "sed -i -e 's@\\\([[:space:]]\\\)\\\(/var/log/\\\)@\\\1-\\\2@' \
                /etc/syslog.conf; exit 0"

APF on CentOS-5 OpenVZ Containers

  1. Increase the NUMIPTENT values in VE conf file to 1000 on the host:
    NUMIPTENT="1000:1000"

  2. Edit "/etc/sysconfig/vz" on the host:
    IPTABLES="ipt_REJECT ipt_tos ipt_TOS ipt_LOG ip_conntrack ip_conntrack_ftp ip_conntrack_irc ipt_owner ipt_length ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state iptable_nat ip_nat_ftp ipt_recent"

  3. Make sure the above modules are loaded on the host, so it would help if you have APF on the host as well.
  4. Restart the VE
    # vzctl restart <VEID>

  5. It is normal to get ipt_recent error as below:
    Warning: Unknown iptable module: ipt_recent, skipped

    You can verify the modules loaded via:

    # vzctl exec <VEID> grep ipt_recent /proc/net/ip_tables_matches

    Note: ipt_recent is required for passive ftp to work, else... will need to specify passive ftp ports in ftp conf file and open those ports via apf as well.

  6. Here is a typical apf config on a VE with CentOS-5 running ISPConfig.

    DEVEL_MODE="0"
    IFACE_IN="venet0"
    IFACE_OUT="venet0"
    IFACE_TRUSTED=""
    SET_MONOKERN="1"
    IG_TCP_CPORTS="21,22,25,53,80,81,110,143,443"
    IG_UDP_CPORTS="53"
    EGF="1"
    EG_TCP_CPORTS="21,25,80,443,43"
    EG_UDP_CPORTS="20,21,53"

openvz user and quota issues

Recently, I've had a client who's had issues with uploading files and general functioning of the ISPConfig hosting control panel.

So the first thing I checked out was "/proc/user_beancounters", and everything seemed normal there.

Quick check with `vzquota` turned out that the inodes were maxed out.

Blocks and Inodes can also be checked/displayed within the container via `df -h` and `df -i`.

Additionally, since he had a lot of users, he was maxed out on the users limits too. Noticed that with `repquota -a` which pulled up a huge number of users.

Increasing the appropriate limits with vzctl on diskspace, diskinodes and quotaugidlimit resolved all issues.

Syndicate content