XEN - Time handling in Linux VMs (Problemas con NTP y XEN)

Problemas con la hora de las maquinas virtuales? Una forma de solucionarlo es hacer que el DomU sea independiente de la hora de su Dom0 de la siguiente manera.

Para probarlo
echo 1 > /proc/sys/xen/independent_wallclock

Para que sea definitivo
en /etc/sysctl.conf

# Set independent wall clock time
xen.independent_wallclock=1

Manera alternativa.
The independent_wallclock=1 may also be passed as a boot parameter to the VM.

http://docs.vmd.citrix.com/XenServer/4.0.1/guest/ch04s06.html

By default, the clocks in a Linux VM are synchronized to the clock running on the control domain, and cannot be independently changed. This mode is a convenient default, since only the control domain needs to be running the NTP service to keep accurate time across all VMs. Upon installation of a new Linux VM, make sure you change the time-zone from the default UTC to your local value (see Section 4.8, “Release Notes” for specific distribution instructions).

Solaris - Terminal too wide

Abres felizmente un httpd.conf con vi y te aparece el decepcionante mensaje de error:

Terminal too wide

En Solaris es bastante común este error. Para solucionarlo:

stty columns 120

OCFS2 self-fencing during cluster failover on SUSE Linux Enterprise

During a clustered failover or network disruption, all paths to the storage system can become unavailable. As a result, the nodes might fence by panicking. Set the O2CB_HEARTBEAT_THRESHOLD value in /etc/sysconfig/o2cb to a value large enough to ensure that the nodes do not self-fence.

Oracle Cluster File System (OCFS2) has a fencing mechanism that relies on each node being able to write a heartbeat value to a specific area on each OCFS2 volume. Every two seconds, each node writes a new heartbeat value, and reads the value of the other node. If a node is unable to write or read the heartbeat value, it retries the operation a specific number of times, and then self-fences by panicking the Linux kernel as it fails to obtain quorum.

During a clustered failover or network disruption, all paths to the storage system can become unavailable. None of the nodes in the OCFS2 cluster is able to write or read the heartbeat values. As a result, the nodes might fence by panicking.

With a dedicated TCP/IP network for the iSCSI link between Linux hosts and the storage system, a reasonable value usually is 181. This value corresponds to a total of 360 seconds before a node self-fences.

Depending on the load in the iSCSI network, you should raise the value. It is best to use a value in the range of 91 to 201 for a configuration with OCFS2 on multipath, and iSCSI devices.

Cluster XEN - bloqueo Filesystem compartido

Después de configurar un cluster de Xen con openais, ocfs2, con los recursos dlm, o2cb y filesystem en el cluster, probando el failover en la caída de uno de los nodos (reboot desde ILO) me he encontrado que el punto de montaje compartido se quedaba totalmente bloqueado hasta que no se volvía a levantar el nodo que había "tirado".

En el log veía algo como: do_sysfs: write "0" to "/sys/kernel/dlm/4E0AD0290F4A43BCAC24CF8314B01A7A/control"

La solución es tan simple como complicada de encontrar por internet, simplemente es necesario crear los recursos de STONITH y tenerlo activado.

Una vez STONITH está activo, he hecho la prueba (varias veces) de tirar un nodo desde la ILO y el bloqueo es solo de unos segundos e inmediatamente una vez recuperado, se levantan las máquinas virtuales en el otro nodo.

Apache2 - Ocultar ficheros

Para denegar el acceso a diferentes ficheros en el Document Root o cualquier directorio tenemos el siguiente ejemplo

<Location ~ "(.Xauthority|.bash_history|.profile|.rhosts|.sh_history|.ssh|.subversion|.sunw|.bashrc|.svn)">
Order allow,deny
Deny from all
</Location>


Este denegaria el acceso a los ficheros (.bash_history |.profile| .rhosts| .sh_history| .ssh|.subversion| .sunw|.bashrc|.svn) del directorio Document Root.

XEN - tap:aio y SLES11

La versión que se incluye en el dvd me ha dado problemas al crear maquinas virtuales con discos configurados con tap:aio como por ejemplo este:

disk = ['tap:aio:/vmachines/10.disk.xm,xvda,w']

El error que da es:

VmError: Device 51952 (tap) could not be connected. Setting up the backend failed. See the log files in /var/log/xen/ for details.

Para ello la solución es actualizar a la versión más nueva posible. Con suscripción a Novell no hay problema, ya en sus repos hay versiones más nuevas. Si no hay el repositorio http://download.opensuse.org/repositories/Virtualization/SLE_11/ que funciona bien.

RMS - Acceso por consola serie - minicom

Para configurar el acceso por minicom a estos dispositivos, es necesaria la siguiente config en el profile, por defecto /etc/minicom/minirc.dfl

pu port /dev/ttyS0
pu baudrate 9600
pu bits 8
pu parity N
pu stopbits 1
pu rtscts No
pu xonxoff Yes

OpenBox - Ligero y rapido

OPENBOX

Este entorno es de los más rápidos que he probado y bastante sencillo de configurar. Para los que lo quieran usar este howto es muy completo:

http://urukrama.wordpress.com/openbox-guide/#Configuring

Unos screenshots http://openbox.org/wiki/Openbox:Screenshots

Pacemaker - Recurso ClusterMon el monitor del cluster

Este recurso ocf (ocf::pacemaker:ClusterMon) crea una pagina html estática donde escribe el estado de los recursos del cluster. Con este aspecto:

Cluster summary

Last updated: Tue May 4 15:58:13 2010
Current DC: nodo1 (nodo1)
2 Nodes configured.
5 Resources configured.

Config Options

Default resource stickiness	:	0
STONITH of failed nodes	:	enabled
Cluster is	:	symmetric
No Quorum Policy	:	Ignore

Node List

• Node: nodo1 (nodo1): online
• Node: nodo2 (nodo2): online

Resource List

STONITH_iLO_RSA_nodo1 (stonith:external/ibmrsa-telnet): Started nodo2
STONITH_iLO_RSA_nodo2 (stonith:external/ibmrsa-telnet): Started nodo1
Resource Group: cluster_services

• cluster_ip (ocf::heartbeat:IPaddr): Started nodo1
  
• cluster_moon (ocf::pacemaker:ClusterMon): Started nodo1
  
• cluster_apache2 (lsb:apache2): Started nodo1
  

vm_mail01 (ocf::heartbeat:Xen): Started nodo2
vm_mail02 (ocf::heartbeat:Xen): Started nodo1

Un recurso curioso :)