La macchina non si spegne: una richiesta non è un interruttore

Lo spegnimento chiede; l'arresto stacca la spina. Tutto ciò che confonde in una macchina che rifiuta di spegnersi nasce da questa sola distinzione, e dal fatto che una richiesta ha bisogno di qualcuno dentro che la ascolti.

AtlasPVE ·

Questa voce risponde a

  • proxmox vm non si spegne
  • proxmox stop o shutdown
  • proxmox spegnimento pulito
  • proxmox ups spegnimento
  • proxmox vm won't shut down

Premete spegni. L'attività parte, la rotella gira, e tre minuti dopo la macchina è ancora accesa. Alla fine premete arresta e muore all'istante, il che solleva una domanda ovvia: perché la prima non ha funzionato se la seconda evidentemente ci riesce?

Non sono due intensità della stessa azione. Sono due cose completamente diverse.

La distinzione da cui dipende tutto

Lo spegnimento è una richiesta. Lo strato di virtualizzazione chiede all'ospite di spegnersi da solo, come premere il pulsante di accensione di una macchina fisica chiede a un sistema operativo di chiudersi in modo pulito. Cosa farne, lo decide l'ospite.

L'arresto è uno stacco di corrente. Toglie immediatamente alimentazione alla macchina virtuale, senza alcuna conversazione. La documentazione lo avverte in modo netto: arrestare può causare perdita di dati, quindi va usato con cautela.

Una volta tenute separate le due cose, una macchina che non si spegne smette di essere misteriosa. Non sta rifiutando. Dentro nessuno ha sentito la richiesta.

Chi dovrebbe ascoltare

Ci sono due possibili ascoltatori, e una macchina sana ne ha almeno uno.

Il gestore del pulsante di accensione del sistema operativo. Su un ospite Linux di norma c'è. Su un'immagine minimale, su un apparato simile a un contenitore, o su un sistema entrato in una fase di avvio precoce o in una shell di ripristino, può mancare.

L'agente ospite. Quando è attivo e davvero in esecuzione, dà allo strato di virtualizzazione un canale diretto verso l'interno, e la richiesta passa di lì.

Se l'agente è spento e il gestore del pulsante manca o non risponde, la richiesta esce e non arriva da nessuna parte. Allo strato di virtualizzazione non viene detto "no". Non viene detto niente, il che da fuori sembra esattamente la stessa cosa ed è il motivo per cui l'attività appare bloccata anziché fallita.

Se le vostre macchine impiegano regolarmente troppo a spegnersi, verificare che l'agente funzioni davvero è una mossa migliore che accorciare i tempi di attesa.

Poi il timeout, poi la forza

L'attesa ha un limite. Per ospite, il timeout di spegnimento predefinito è di 180 secondi; alla scadenza la macchina viene arrestata in modo forzato.

Un arresto collettivo di tutto un nodo ha il proprio budget: tenta uno spegnimento pulito, aspetta fino a tre minuti per impostazione predefinita, poi arresta duramente ciò che è ancora acceso.

La descrizione onesta di uno spegnimento non presidiato è quindi: chiedere con garbo, aspettare un tempo fisso, poi staccare la spina. Se il vostro database ha bisogno di quattro minuti per scaricare le scritture, le impostazioni predefinite hanno già deciso che ne avrà tre.

Alzate il numero, ma non saltate la domanda

È allettante trattare il timeout come la manopola da regolare. Per una macchina che davvero ha bisogno di più tempo, alzarlo è corretto.

Ma una macchina che non si spegne mai per quanto aspettiate non ha un problema di timeout, e darle dieci minuti significa solo aspettare dieci minuti prima dello stesso arresto forzato. Prima scoprite se qualcuno sta ascoltando.

Quando un'attività di spegnimento è già bloccata

Se un'attività di spegnimento resta appesa e la macchina deve scendere adesso, esiste un modo esplicito di arrestarla scavalcando l'attività di spegnimento in corso invece di mettersi in coda dietro di essa. Esiste proprio perché il caso dell'attività bloccata è abbastanza comune da richiedere una risposta.

Usatelo sapendo cos'è: sempre uno stacco di corrente, con lo stesso avvertimento attaccato.

Il caso che coglie tutti di sorpresa: il blackout

È qui che l'intero testo smette di essere teorico.

Uno script per il blackout che spegne gli ospiti prima che le batterie finiscano eredita ogni proprietà qui sopra. Invia richieste. Gli ospiti che non ascoltano le ignorano. Il timeout scorre. Poi tutto ciò che è ancora acceso viene arrestato duramente, magari con la batteria già bassa e magari tutto insieme.

Due cose vale la pena controllarle prima di affidarsi a un simile impianto, e costano poco entrambe:

Gli ospiti rispondono davvero a una richiesta di spegnimento? Provatene uno, cronometro alla mano, in un pomeriggio qualunque.

Il budget complessivo sta nella batteria? Gli ospiti si spengono in sequenza, e i timeout si sommano. Una fila di macchine che ne impiegano due ciascuna non è uno spegnimento di due minuti.

Un piano per il blackout mai provato è un piano che verrà provato una volta sola: al buio, con il tempo che stringe.

Cosa fa Atlas

Atlas non inventa un terzo tipo di spegnimento. Chiedere e togliere corrente sono le due cose che esistono, e far finta del contrario sarebbe una bugia con conseguenze.

Quello che fa è rifiutarsi di confonderle. Un'azione distruttiva dichiara di essere distruttiva prima che la confermiate, così "arresta" non arriva mai travestito da "spegni" un po' più deciso. Quella distinzione è tutto l'argomento di questo testo, e un pannello che presenta le due come pulsanti vicini di uguale peso l'ha già persa.

Il riepilogo giornaliero porta l'altra metà: un riavvio non pianificato viene riportato come fatto. Una macchina arrestata a forza dopo un mancato spegnimento pulito, il mattino dopo, sembra esattamente una macchina che è andata in crash. Entrambe meritano di essere notate.

Fonti

La documentazione ufficiale di Proxmox. In inglese, e su questo argomento l’ultima parola è la sua.

Voci collegate

Come si presenta questo dentro Atlas?

Vai alla pagina prodotto