¿Cómo salgo de esta situación de manera segura?
Los detalles son los siguientes:
Un servidor xen tiene dispositivos de bloque asignados a máquinas virtuales. Pero estos dispositivos también se han montado dentro de Xen.
De hecho, 44 de estos dispositivos de bloque se han montado de esta manera. Para empeorar las cosas, cada dispositivo físico se ve en 4 rutas y cada una de ellas está montada en un punto de montaje separado. En otras palabras, los dispositivos se montan 5 veces cada uno.
El sistema operativo invitado VM ve la ruta a través de un pseudo dispositivo PowerPath (asignado como un dispositivo phy: block a domU)
Algunos de los dispositivos están formateados como ext2 y reiserfs.
No es necesario que me explique los riesgos de corrupción del sistema de archivos involucrados aquí.
Me temo que incluso solo desmontar los sistemas de archivos puede causar corrupción, y creo que en este momento extraer la alimentación del host es la opción más segura .
Tenga en cuenta que las aplicaciones, bases de datos Oracle en su mayor parte, en todas las máquinas virtuales todavía se están ejecutando y en uso.
Descubrí esto al investigar el uso elevado de la CPU en dom0. Hay un proceso de "búsqueda" que no se puede matar, con cwd -> / media / disk-12 que se monta desde / dev / sdf1, que pertenece a / dev / emcpowerr
Antes de que alguien pregunte, la única vez que he visto que los procesos no se pueden eliminar y continúo usando CPU y RAM (a diferencia de un proceso difunto / zombie), es cuando hay E / S comprometidas pendientes, por ejemplo, la sincronización devuelta pero aún no físicamente en el disco . Más comúnmente esto ocurre en la E / S de cinta.
Sugerencias?
PD: ¿Esperaba que los dispositivos estuvieran "reservados" una vez montados, para evitar este tipo de cosas? ¿O eso no es posible en Linux?
EDITAR: en primer lugar, estoy convencido de que KDE dentro del hipervisor) es el culpable. Parece que KDE está montando los dispositivos que puede al iniciar sesión para crear iconos de escritorio. Sin embargo, no ocurre lo mismo en otros servidores Xen, pero todos los demás servidores están ejecutando una versión mucho más antigua de SLES y KDE ... V4 parece ser el infractor, con 3.4 comportándose mejor).
Además, dos máquinas virtuales no críticas se han bloqueado. Después de apagarlos, no se iniciarían nuevamente debido a la corrupción del sistema de archivos. La máquina virtual principal / de producción todavía se está ejecutando y la base de datos en ella todavía funciona, pero claramente esta es una bomba de tiempo. El cliente está intentando reconstruir el entorno en otra máquina virtual en otro servidor, pero tiene problemas para configurar algunos de los componentes, por lo que estamos esperando ...
En cualquier caso, siento que ninguna de las respuestas ha sido más que "las mejores prácticas siempre se cierran con gracia". Y espero obtener algo más concreto ... En cualquier caso, creo que esta situación puede justificar un poco más de cuidado. pensando. ¿El cierre provocará una sincronización de E / S sobresaliente, en particular las actualizaciones de metadatos del sistema de archivos desde el hipervisor, y provocará una posible corrupción importante del sistema de archivos?
fuente
Respuestas:
Si los discos se escriben desde un único punto de montaje, no se está haciendo daño. Realice un apagado limpio (si lo desea, haga una copia de seguridad del estado suspendido) repare las monturas. No ejecute nada excepto las aplicaciones necesarias en el Dom0. Si, OTOH, las particiones se escriben desde múltiples rutas, eso es MALO y empeora cada segundo. Tirar del enchufe.
fuente
No tengo ninguna razón concreta, pero mi instinto me dice que lo siguiente puede ser el mejor enfoque:
Alternativa a 11: inicie la VM y monte los sistemas de archivos sin un fsck completo.
El razonamiento es que no quiero que el hipervisor Xen tenga más posibilidades que las absolutamente necesarias para causar corrupción en los sistemas de archivos domU.
fuente
No soy un experto en Xen y todavía no tengo experiencia con él. Pero mi enfoque si estuviera en su lugar sería: primero sé que podría perder datos (tal vez incluso todos); segundo, trataría de crear instantáneas y luego suspender las máquinas virtuales, restableciéndolas en un entorno seguro diferente.
No quiero darte falsas esperanzas, pero creo que tendrás suerte si puedes recuperar algo.
Advertencia : seguir estos consejos puede hacer que pierda todos los datos. Esto depende de usted para ver si vale la pena el riesgo o no.
Con mucha suerte, sus aplicaciones siguen funcionando porque los datos que están utilizando están en memoria volátil. Debería intentar aprovechar esta situación (intente evaluar si ese podría ser el caso por aplicaciones) y exportar los datos en vivo a un recurso compartido de red si las aplicaciones ofrecen dicha función. Si hay datos en el disco, esta función de exportación podría "bloquearse" de forma muy similar a su
finddeclaración o bloquearse (y bloquear la aplicación o el sistema operativo) debido a los datos del disco modificados / dañados.Entonces podría intentar hacer una instantánea en vivo, las instrucciones en el siguiente artículo: Crear instantáneas en Xen . Iría por la instantánea byte por byte, aunque podría atascarse como tu
findcomando ... Sin embargo, no daría tanta esperanza.Antes de ejecutar el comando anterior, debe leer este documento de Citrix, que ayuda a comprender las instantáneas en Xen (PDF) .
Les deseo buena suerte.
fuente