http://wiki.openvz.org/Timezone

During the distribution (redhat/centos) installer, you choose the timezone for your HN. The container template has its own preconfigured timezone. So, it is very possible for the zones to differ.

#! /bin/bash
for f in `ls /vz/private`
do
vzctl exec $f rm -f /etc/localtime 2>/dev/null
vzctl exec $f ln -s /usr/share/zoneinfo/Europe/Madrid /etc/localtime
done


Y funcionó

Al ejecutar “yum update” me apareció este error. Era bastante descriptivo pero aún y así busqué algo de información y estaba claro que era un tema de memoria. Como ese mismo día estaba actualizando mis contenedores, a nivel de recursos y demás, me quedó claro que al limitar los recursos de memoria del contenedor a un nivel muy mínimo (128 MB o 256 MB) yum no podía alojar en memoria la cantidad suficiente de datos para iniciar el proceso. Así que, deje dos contenedores de funcionalidades muy bajas a 512 MB de memoria y su respectiva capacidad de proceso. Entonces al ejecutar “yum update” de nuevo todo funcionó bien.


# cat /var/log/messages | grep ’socket’
[...]
Apr 20 20:46:32 hn248 kernel: Orphaned socket dropped (156,624 in CT248)
[...]

Se puede decir que, las causas de la aparición de este aviso, que no problema están claras.

1. El número de sockets huérfanos en una VE es >= 1/4 * (numtcpsock.barrier)
2. El número de sockets huérfanos en una VE es > (sysctl net.ipv4.tcp_max_orphans)

La regla uno dice que, si el número de sockets huérfanos es mayor o igual que la cuarta parte del numtcpsock.barrier asignado a una VE, nos informará de esta situación. La dos, explica que si el total de sockets huérfanos es mayor que el valor configurado en el sysctl, actuará igual.

¿Pero es realmente un “problema”? Según lo que he leído en los foros de OpenVZ, no.Voy a citarlo literalmente:

“Un socket huérfano es algo así como una sesión fantasma. No está cerrada correctamente que, sin embargo, puede contener data o por otras razones, no puede ser liberada inmediatamente y debe “vivir” algún tiempo más después de su cierre. Usualmente, estos sockets aparecen porque el cliente dejó de responder(crashed).

El kernel de OpenVZ limita el número de sockets tcp que pueden acceder por VE, y si todos los sockets de una VE son huérfanos, nadie puede conectarse a esa VE. Eso es por lo que el kernel limita el número máximo de sockets huérfanos a un 1/4 del numtcpsock asignado a una VE. C

Cuando dentro de una VE se alcanza ese límite, el kernel muestra el mensaje “TCP: too many of orphaned sockets” y libera esos sockets. Ese es el comportamiento correcto y los kernel de linux suelen hacer lo mismo en algunos casos extraños.

Es por eso que, esto no es un problema, el kernel sólo informa de que tu VE ha producido sockets que no se han cerrado correctamente. Para prevenir este mensaje  puedes intentar incrementar el numtcpsock para tus VE’s.
Vasily Averin”.

Links

• http://forum.openvz.org/index.php?&t=msg&th=2892
  

# rm -rf /dev/null
# mknod -m 666 /dev/null c 1 3
# /etc/init.d/sshd start

Para sistemas RPM (RedHat, CentOS, Fedora), arreglar el problema temporalmente

# vzctl exec VEID /sbin/MAKEDEV pty
# vzctl exec VEID /sbin/MAKEDEV tty
#vzctl enter VEID

Para solventar el problema permanentemente

1. Editamos el archivo /etc/rc.sysinit del container

2. Comentamos  la linea donde se inicia udev
#/sbin/start_udev

3. Añadimos a continuación los siguientes comandos
/sbin/MAKEDEV tty
/sbin/MAKEDEV pty

4. Reiniciamos nuestro container

# vzctl restart VEID

Para sistemas no basados en RPM. Es algo problemático utilizar Ubutun o Debian con OpenVZ por el simple hecho que, en el mismo foro de OpenVZ, recomiendan no utilizar containers de esas distribuciones. Se crean algunos problemas añadidos, aún así, hay gente que lo utiliza.

La solución descrita más arriba no funciona en Ubuntu:

Ubuntu 9.04
vzctl exec 3333 '/sbin/MAKEDEV /pty'
/sbin/MAKEDEV: warning: can't read /proc/devices
/sbin/MAKEDEV: don't know how to make device "/pty"

Para resolver el error se comentan 2 opciones
# vzctl exec 3333 'dpkg --force-depends --purge udev'

y

# vzctl exec veid update-rc.d -f udev remove
# vzctl restart veid

No puedo comentar nada porque no tengo ningún container con Ubuntu, Debian o Slackware.

Links

• http://forums.openitc.co.uk/index.php?topic=3.0
• http://www.sherin.in/index.php/2008/05/15/unable-to-open-pty-no-such-file-or-directory/
• http://wiki.openvz.org/VPS_enter_failed
• http://forum.openvz.org/index.php?t=tree&th=6986&mid=34077&&rev=&reveal=
• http://david.toribio.eu/2008/10/11/unable-to-open-pty-no-such-file-or-directory/

# joe /etc/yum.repos.d/CentOS-Base.repo

# Name: RPMforge RPM Repository for Red Hat Enterprise 5 - dag
# URL: http://rpmforge.net/
[RHEL5-rpmforge]
name = Red Hat Enterprise 5 - RPMforge.net - dag
#baseurl = http://apt.sw.be/redhat/el5/en/i386/dag
mirrorlist = http://apt.sw.be/redhat/el5/en/mirrors-rpmforge
#mirrorlist = file:///etc/yum.repos.d/mirrors-rpmforge
enabled = 1
protect = 0
#gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck = 0

Otra posible forma, la dejé explicada en estre otro post .

# vzyum VPS_ID check-update

y nos pasa esto


[root@hn10 ~]# vzyum 101 check-update
exec /usr/share/vzyum/bin/yum -c /vz/template/centos/5/i386/config/yum.conf
--installroot /vz/root/101 --vps= 101 check-update
Setting up repositories
centos4-vz-addons 100% |=========================| 951 B 00:00
centos5-updates 100% |=========================| 951 B 00:00
centos5-base 100% |=========================| 1.1 kB 00:00
Cannot find a valid baseurl for repo: RHEL5-rpmforge
Error: Cannot find a valid baseurl for repo: RHEL5-rpmforge


Momentánemente uno de los repositorios no está disponible y no podemos proseguir la instalación de software en los containers. Hemos de editar el fichero siguiente, según el template que utilicemos

# joe /vz/template/centos/5/i386/config/yum.conf

dejando el repositorio que no funciona en enabled = 0

Oomguarpages: cantidad de memoria reservada para el contenedor en situaciones de falta de memoria. Si una aplicación empieza a consumir más memoria que la que tiene la máquina, el sistema entra en condición de “sin-memoria”. En ese caso, el sistema operativo comenzará a matar los procesos de los containers, para liberar algo de espacio y prevenir la muerte total del sistema.

Oomguarpages cuenta el total de memoria y espacio swap utilizado por los procesos de un container en concreto. El “barrier” del parámetro oomguarpages es la cantidad de memoria garantizada(en condiciones de “sin-memoria”).

El total de “sin-memoria” garantizado dentro de un contenedor nunca deberá exceder los recursos físicos de la computadora, en caso contrario, no podrá hacer su función, que es la de eliminar procesos de los contenedores para detener un fallo grave del sistema.

Vmguarpages: asignación de memoria garantizada. La cantidad total de memoria garantizada que un contenedor puede asignar es el barrier de vmguarpages, mientras que la cantidad actual de memoria asignada es contado por el parámetro privvmpages.

Si el total de memoria asignada actual no execede el “barrier” de vmguarpages, las asignaciones del contenedor siempre tendrán éxito. Si el total de memoria asignada actual excede del garantizado pero está por debajo de la barrera de privvmpages, dependerá del total de recursos que tenga el sistema.

Comandos relacionados:

# vzmemcheck -vA
# vzcfgvalidate
# free -m
# vzsplit


Instalarlo es cosa de pocos minutos


# yum install ruby ruby-libs ruby-mode
ruby-rdoc ruby-irb ruby-ri ruby-docs
# wget http://beanmonitor.googlecode.com/files/
beanmonitor-singlesource-0.0.4.tar.bz2
# tar jxf beanmonitor-singlesource-0.0.4.tar.bz2
# rm LICENSE
# cp beanmonitor /usr/bin/


Ya tenemos copiado el comando, ahora sólo tenemos que hacer un par de cosas para empezar a probarlo. Seguidamente, configuramos el path donde beanmonitor, guarda los datos de nuestro beancounters y añadimos una cuenta de mail, que recibirá todos los cambios de beancounters que se produzcan en todas las VPS


# /usr/bin/beanmonitor --savefile /tmp/savefile -w
#/usr/bin/beanmonitor --email-add ruben@unmail.com


Podemos listar los usuarios que hemos añadido

# /usr/bin/beanmonitor --email-list

:all: - ruben@unmail.com


# beanmonitor --email

Lo último es añadir beanmonitor al cron para recibir cada cierto tiempo los cambios detectados

# crontab -e
*/5 * * * */usr/bin/beanmonitor --email

No será la herramienta definitiva de monitorizacion de VPS OpenVZ pero ya es un paso más en el objetivo de controlar algo tan crítico como la gestión de recursos, y más cuando tenemos decenas de VPS.

Saludos.

Links

• http://david.toribio.eu/2008/05/04/recibir-avisos-de-failcount-de-userbeancounters/
• http://code.google.com/p/beanmonitor/wiki/QuickInstall
• http://code.google.com/p/beanmonitor/wiki/HowToGetGoing
• http://code.google.com/p/beanmonitor/downloads/list

Máquina origen = 10.0.0.50
Máquina destino = 10.0.0.100

“You first have to setup SSH to permit the old HN to be able to login to the new HN without a password prompt.” Es decir, hemos de permitir al viejo hardware node ser capaz de loguearse contra el nuevo, sin usar un password.

En la máquina origen, ejecutamos

#ssh-keygen -t rsa

No hemos de teclear nada cuando nos pide una frase, doble Enter y seguimos. Veremos lo siguiente:

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@localhost.localdomain
La llave se ha guardado den el directorio /root/.ssh/


# cd /root/.ssh
# ls - ls /root/.ssh


Veremos el archivo creado

4 -rw------- 1 root root 1743 May 6 10:03 id_rsa
4 -rw-r--r-- 1 root root 408 May 6 10:03 id_rsa.pub

Copiamos la clave a la máquina destino:

# scp id_rsa.pub root@10.0.0.100:./id_rsa.pub

Puede que veamos el siguiente error

ERROR!
[root@localhost .ssh]# scp id_rsa.pub root@10.0.0.100:./id_rsa.pub
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


Editamos known_hosts y quitamos la línea con la ip destino involucrada. Volvemos a repetir el proceso, y deberíamos poder copiar la llave pública sin problemas.

# scp id_rsa.pub root@10.0.0.100:./id_rsa.pub

The authenticity of host '10.0.0.100 (10.0.0.100)' can't be established.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.100' (RSA) to the list of known hosts.
reverse mapping checking getaddrinfo for es failed - POSSIBLE BREAK-IN ATTEMPT!
root@10.0.0.100's password:
id_rsa.pub 100% 408 0.4KB/s 00:00

Nos conectamos ahora al nuevo host, máquina destino. Añadimos la llave pública importada del servidor origen a autorized_keys2 para finalmente borrar el mismo archivo copiado.


# cd .ssh/
# touch authorized_keys2
# chmod 600 authorized_keys2
# cat ../id_rsa.pub >> authorized_keys2
# rm ../id_rsa.pub


Desde el servidor origen:

# ssh -2 -v root@10.0.100

Si nos conectamos bien, sin necesidad de teclear el password es que ya podemos utilizar la herramienta vzmigrate.

# /bin/sh /usr/sbin/vzmigrate -r no -v 10.0.0.100 VED_ID

Prerequisitos de Vzmigrate

Make sure:

• you have at least one good backup of the virtual machine you intend to migrate
• rsync is installed on the target host