El Pan de cada día: Linux monta los volúmenes en read only.

Panadero: Los chicos de LMS

Descripción: Mi grupo de gurús preferidos pusieron cerco a mi mesa el otro día reportando errores de disco en sus VM basadas en RHEL. Sin motivo aparente, RHEL 4.x reporta un error de disco y monta los volúmenes en Read Only. Imagináos la gracia.

Acciones diagnósticas: Lo de siempre. Revisar ESX, la conexión al almacenamiento, la carga de las VM, etc, etc. La consola del Linux reporta lo siguiente:

SCSI Error : <0> return code = 0x20008
end_request: I/O error, dev sda, sector 4928181
Aborting journal on device dm-0 ext3_abort called.
EXT3-fs error (device dm-0): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only.

(este es uno de los errores que pueden aparecer)

Después, chapuzón en San Google bendito y la consecuente llamada a mis infiltrados de VMware, apareció la solución.

Solución: Parece ser que es un "issue" con el driver LSI incorporado en RHEL4 U3, RHEL4 U4, SLES9 SP3 y SLES10. Esta versión del driver cambia el mecanismo de notificación de timeouts en acceso, limitando a 5 el número reintentos que el driver hace ante un timeout. VMware ha publicado un driver modificado al efecto. Este "issue" no es exclusivo de las máquinas virtuales. Si navegáis en Google, os lo encontraréis en físicas, eso sí, es más difícil. Está asociado a situaciones de carga de disco en el almacenamiento, situaciones que, en entornos ESX, son más fácilmente reproducibles.

Links de referencia:
RHEL4 U3, RHEL4 U4, SLES9 SP3, and SLES10 File Systems Might Become Read-Only ,
ESX 3.0.1 - Linux Guests go ReadOnly

Conclusiones: Pa habernos matao....

Nota Técnica: Linux en VM sobre portátiles.

Nuestro amigo Pablo nos pregunta:

"Buenas tardes JL, lo primero un saludo y mis felicitaciones por la web, se aprende bastante del tema de la virtualizacion con tus post.
Tengo una dudilla que me gustaría que me aclarases (si es que el fondo de la cuestión esta relacionado con VMW) y es que yo uso el VM Player o el workstation en el portátil del trabajo (para virtualizar maquinas linux y correr aplicaciones) y por mas que lo he intentado, no consigo terminar de afinar el tema de la frecuencia de la CPU (centrino en este caso)...
Si arranco linux desde el HD, el tema funciona a la perfección, pero desde la maquina virtual el micro esta siempre al 100% de su velocidad nominal, con el consiguiente gasto de batería y constante ruido del ventilador.
¿sabes si el VMware permite este ajuste? Mas que nada por desistir de buscar la solución si es que en el fondo no la tiene.
Nada mas, un saludo"

Buena pregunta. El "battery drain" (vaciado de batería) no es un problema exclusivo de la virtualización con linux, sino de la utilización de Linux en dispositivos portátiles. Sin ir más lejos, conozco el caso de un esforzado usuario de un Samsung Q1 que tras conseguir que su "tamagochi" arrancase en Linux, observó importente como la batería desaparecía en menos de una hora. Si a esto le añadimos la capa de abstracción que añade la virtualización, es de suponer que la VM linux corra a sus anchas sin preocuparse por detalles como son la eficiencia del consumo, y también es posible que VMware workstation o VMplayer tampoco tengan demasiado en cuenta a la plataforma portátil.

En cualquier caso, no he probado lo que nuestro amigo Pablo nos comenta. Si alguno de los lectores de este blog tiene alguna experiencia similar, os animo a compartirla.

Un cordial saludo.

Noticias: Linux incluirá VMI

Parece ser la la comunidad linux plantea incorporar la esspecificación VMI diseñada por VMware en próximas revisiones del kernel. VMI ya ha sido adoptada en los desarrollos que en el campo de virtualización están siendo realizados por IBM, VMware, RedHat, y XenSource. VMI (Virtual Machine Interface) es una especificación publicada por VMware que propone una interfáce única y normalizada entre una máquina virtual y cualquier hypervisor. Esta interface permitirá la paravirtualización transparente, de forma que una única versión de los binarios de un sistema operativo pueda ejecutarse en modo nativo (el hardware físico) o bajo cualquier hypervisor que soporte el modo paravirtualizado.

Hay quien en la comunidad plantea sus dudas sobre la idoneidad de incorporar o no una especificación propietaria dentro del kernel de Linux (evidentemente tiene sus riesgos), pero también SUN es propietaria de Java y no por ello ha usado el poder que le dá la propiedad intelectual para otra cosa que no sea evitar la dispersión de Java en múltiples versiones incompatibles, fenómemo que he de reconocer con algo de dolor, bastante habitual en la comunidad.

La idea de un interface standard entre hypervisores y VM es genial: Permitirá la compatibilidad entre hypervisores, permitiendo que el ecosistema de la virtualización mantenga la diversidad necesaria para que los usuarios podamos escoger alternativas. Unificar esta interface será un hito tan importante como la aparición de las BIOS o de la interface NETBIOS lo fué en su momento. Un ecosistema variado es garantía de contínua innovación y mejora, y si no, obsérvese al resto de los ecosistemas existentes: Bases de datos, donde SQL Server se mide constantemente contra Oracle, y en menor medida, contra DB2; Servidores de Aplicaciones, donde las constantes innovaciones de IIS obligan a mejorar constantemente a Apache, y en menor medida, a Websphere o a BEA... Incluso Linux obliga a Microsoft a mantener a Windows en constante evolución... y viceversa.

La competencia es sana, y cualquier iniciativa (en este caso de mano de la Comunidad Linux y de un fabricante), que permita la creación de un ecosistema común, donde distintas concepciones compitan, debe ser aplaudida.

¿Qué opináis vosotros?

Nota técnica: Problemas con el reloj bajo VMware

Uno de los incidentes más habituales y que trae de cabeza a más de uno viene dado por el reloj de las máquinas virtuales. Alguno de vosotros ya habréis observado que el reloj de cualquier sistema operativo que virtualicéis bajo VMware Server y/o ESX (a mí en Workstation no me ha pasado aún) es que el reloj de la VM parece ir más lento ( o más rápido). Este problema es especialmente acuciante en VM's bajo Linux.

En el entorno Windows, incluso en VM's dentro de un dominio (donde el DC hace de servidor de tiempo), podemos sorprendernos encontrando un desfase de horas entre nuestras VM y las máquinas físicas. El Knowlegde Base de VMware (accesible desde la página principal de VMware) ofrece distintas soluciones, aunque he de reconocer que la presentación es bastante confusa.

Como norma general, vengan las siguientes recomendaciones:

1. Utilizar una sola fuente de reloj: Es decir, si usáis ntp, desactivar el "Time sync" en las VMware Tools y viceversa.
2. No uséis al host VMware como time server: El COS (Console Operating System) no está pensado para esto, y la ejecución del algún proceso en él puede afectar al reloj.
3. En el caso de Linux, Los escenarios varían:

• Si vuestro reloj se ralentiza bajo VI3, mirad este Link
• Para el resto de los casos (reloj acelerado, otras plataformas), usad este otro

¿Quién dijo que sólo Microsoft tiene "particularidades" tontas?

Un saludo.