¿Cómo salgo de esta situación de forma 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 así. 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 de la máquina virtual ve la ruta a través de un pseudodispositivo PowerPath (asignado como un dispositivo phy:block al 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 desmontar los sistemas de archivos puede causar corrupción, y creo que en este punto, desconectar la energía del host es la opción más segura .
Tenga en cuenta que las aplicaciones, las bases de datos de Oracle en su mayor parte, en todas las máquinas virtuales aún se están ejecutando y en uso.
Descubrí esto cuando investigaba el alto uso de CPU en dom0. Hay un proceso de "búsqueda" indestructible, 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úan usando la CPU y la RAM (a diferencia de un proceso difunto/zombi), es cuando hay E/S confirmadas pendientes, por ejemplo, se devolvió la sincronización pero aún no está físicamente en el disco. . Más comúnmente, esto ocurre en la E/S de cinta.
¿¡Sugerencias!?
PD ¿Hubiera esperado 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 iniciar sesión para crear iconos de escritorio. Sin embargo, no sucede lo mismo en otros servidores Xen, pero todos los demás servidores ejecutan 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 volvían a arrancar debido a la corrupción del sistema de archivos. La VM principal/de producción aún se está ejecutando y la base de datos aún funciona, pero claramente esto 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 hasta ahora ninguna de las respuestas ha sido más que "la mejor práctica siempre se cierra con gracia" Y espero obtener algo más concreto... En cualquier caso, siento que esta situación puede justificar una reflexión más cuidadosa. ¿El cierre provocará que las E/S pendientes, en particular las actualizaciones de metadatos del sistema de archivos del hipervisor, se sincronicen y provoquen daños importantes en el sistema de archivos?
Relacionado:¿Obtener varias columnas de una subconsulta seleccionada?Respuesta aceptada:
Si los discos se escriben desde un único punto de montaje, no se produce ningún daño. Haga un apagado limpio (haga una copia de seguridad desde el estado suspendido si lo desea) arregle los soportes. No ejecute nada más que las aplicaciones necesarias en el Dom0. Si, OTOH, las particiones se escriben desde múltiples rutas, eso es MALO y empeora por segundos. Tira del enchufe.