La máquina no se apaga: una petición no es un interruptor
Apagar pide; detener corta la corriente. Todo lo confuso de una máquina que se niega a apagarse sale de esa única distinción, y del hecho de que una petición necesita a alguien dentro que la escuche.
AtlasPVE ·
Esta entrada responde a
- proxmox vm no se apaga
- proxmox stop o shutdown
- proxmox apagado limpio
- proxmox sai apagado
- proxmox vm won't shut down
Pulsa apagar. La tarea arranca, la rueda gira, y tres minutos después la máquina sigue funcionando. Al final pulsa detener y muere al instante, lo que plantea una pregunta obvia: ¿por qué no funcionó lo primero si lo segundo claramente puede?
No son dos intensidades de la misma acción. Son dos cosas completamente distintas.
La distinción de la que depende todo
Apagar es una petición. La capa de virtualización pide al invitado que se apague solo, igual que pulsar el botón de encendido de una máquina física pide a un sistema operativo que cierre limpiamente. Qué hacer con esa petición lo decide el invitado.
Detener es un corte de corriente. Le quita la alimentación a la máquina virtual de inmediato, sin conversación alguna. La documentación avisa en lenguaje llano: detener puede provocar pérdida de datos, así que úsese con precaución.
En cuanto separa ambas ideas, una máquina que no se apaga deja de ser misteriosa. No se está negando. Nadie dentro oyó la petición.
Quién se supone que escucha
Hay dos posibles oyentes, y una máquina sana tiene al menos uno.
El gestor del botón de encendido del sistema operativo. En un invitado Linux normalmente está. En una imagen mínima, en un aparato de tipo contenedor, o en un sistema que ha entrado en una fase temprana de arranque o en un intérprete de rescate, puede faltar.
El agente invitado. Cuando está activado y realmente en marcha, da a la capa de virtualización un canal directo hacia dentro, y la petición va por ahí.
Si el agente está apagado y el gestor del botón falta o no responde, la petición sale y no llega a ninguna parte. A la capa de virtualización no se le dice "no". No se le dice nada, que desde fuera se ve exactamente igual y es la razón de que la tarea parezca colgarse en vez de fallar.
Si sus máquinas tardan de forma habitual demasiado en apagarse, comprobar si el agente funciona de verdad es mejor primer paso que acortar los tiempos de espera.
Luego el tiempo de espera, luego la fuerza
La espera tiene límite. Por invitado, el tiempo de espera de apagado por defecto es de 180 segundos; al expirar, la máquina se detiene forzosamente.
Una parada en bloque de todo un nodo tiene su propio presupuesto: intenta un apagado limpio, espera hasta tres minutos por defecto, y luego detiene por las bravas lo que siga en marcha.
La descripción honesta de un apagado desatendido es entonces: pedir con educación, esperar un plazo fijo, y luego cortar la corriente. Si su base de datos necesita cuatro minutos para volcar, los valores por defecto ya han decidido que tendrá tres.
Suba el número, pero no se salte la pregunta
Es tentador tratar el tiempo de espera como el mando que hay que ajustar. Para una máquina que de verdad necesita más tiempo, subirlo es correcto.
Pero una máquina que nunca se apaga por mucho que espere no tiene un problema de tiempo de espera, y darle diez minutos solo significa esperar diez minutos antes de la misma parada forzosa. Averigüe primero si hay alguien escuchando.
Cuando una tarea de apagado ya está atascada
Si una tarea de apagado se queda ahí colgada y la máquina tiene que caer ya, existe una manera explícita de detenerla anulando la tarea de apagado en curso en vez de ponerse a la cola detrás. Existe precisamente porque el caso de la tarea atascada es lo bastante común como para merecer respuesta.
Úsela sabiendo lo que es: sigue siendo un corte de corriente, con la misma advertencia pegada.
El caso que pilla a la gente: el corte de luz
Aquí es donde todo este texto deja de ser teórico.
Un guion de corte de luz que apaga los invitados antes de que se acaben las baterías hereda todas las propiedades de arriba. Envía peticiones. Los invitados que no escuchan las ignoran. El tiempo de espera corre. Luego todo lo que siga en marcha se detiene por las bravas, quizá con la batería ya baja y quizá todo a la vez.
Dos cosas merecen comprobarse antes de confiar en un montaje así, y ambas son baratas:
¿Responden los invitados de verdad a una petición de apagado? Pruebe uno, con cronómetro, una tarde cualquiera.
¿Cabe el presupuesto total en la batería? Los invitados se apagan en secuencia, y los tiempos se suman. Una fila de máquinas que tardan dos minutos cada una no es un apagado de dos minutos.
Un plan de corte de luz que nunca se ha ensayado es un plan que se ensayará una sola vez: a oscuras, con prisa.
Qué hace Atlas
Atlas no inventa un tercer tipo de apagado. Pedir y cortar la corriente son las dos cosas que existen, y fingir otra cosa sería una mentira con consecuencias.
Lo que hace es negarse a difuminarlas. Una acción destructiva dice que es destructiva antes de que usted la confirme, así que "detener" nunca llega disfrazado de un "apagar" algo más firme. Esa distinción es todo el asunto de este texto, y un panel que presenta ambas como botones vecinos de igual peso ya la ha perdido.
El resumen diario lleva la otra mitad: un reinicio no planificado se informa como hecho. Una máquina detenida a la fuerza tras fallar un apagado limpio se parece, a la mañana siguiente, exactamente a una máquina que se cayó. Ambas merecen ser notadas.
Fuentes
La documentación oficial de Proxmox. En inglés, y en este asunto es ella la que tiene la última palabra.