Maskinen stängs inte av: en förfrågan är ingen strömbrytare

Avstängning frågar; stopp drar ur sladden. Allt förvirrande med en maskin som vägrar stängas av kommer ur den enda skillnaden, och ur att en förfrågan behöver någon därinne som lyssnar.

AtlasPVE ·

Den här artikeln svarar på

  • proxmox vm stängs inte av
  • proxmox stop eller shutdown
  • proxmox ren avstängning
  • proxmox ups stänga av vm
  • proxmox vm won't shut down

Du trycker på stäng av. Uppgiften startar, hjulet snurrar, och tre minuter senare kör maskinen fortfarande. Till slut trycker du på stoppa och den dör omedelbart, vilket väcker en självklar fråga: varför fungerade inte det första när det andra uppenbart kan?

Detta är inte två styrkegrader av samma handling. Det är två helt olika saker.

Skillnaden som allt hänger på

Avstängning är en förfrågan. Virtualiseringsskiktet ber gästen stänga av sig själv, på samma sätt som ett tryck på strömknappen på en fysisk maskin ber ett operativsystem stänga ned snyggt. Vad som händer med förfrågan avgör gästen.

Stopp är ett strömavbrott. Det tar bort strömmen från den virtuella maskinen omedelbart, utan något samtal alls. Dokumentationen varnar för det i klarspråk: att stoppa kan orsaka dataförlust, så använd det försiktigt.

Så snart du håller isär de två slutar en maskin som inte stängs av vara gåtfull. Den vägrar inte. Ingen därinne hörde förfrågan.

Vem som ska lyssna

Det finns två möjliga lyssnare, och en frisk maskin har minst en.

Operativsystemets hantering av strömknappen. På en Linuxgäst finns den normalt. På en minimal avbild, en behållarliknande apparat, eller ett system som hamnat i en tidig startfas eller ett räddningsskal, kan den saknas.

Gästagenten. När den är påslagen och verkligen körs ger den virtualiseringsskiktet en direktkanal inåt, och förfrågan går den vägen.

Är agenten av och knapphanteringen saknas eller inte svarar, går förfrågan ut och kommer ingenstans. Virtualiseringsskiktet får inget "nej". Det får ingenting alls, vilket utifrån ser exakt likadant ut och är skälet till att uppgiften verkar hänga sig i stället för att misslyckas.

Om dina maskiner rutinmässigt tar för lång tid att stänga av är det ett bättre första drag att kontrollera om agenten verkligen fungerar än att korta ned tidsgränser.

Sedan tidsgränsen, sedan våldet

Väntandet har en gräns. Per gäst är standardtiden för avstängning 180 sekunder; när den löper ut stoppas maskinen med våld.

Ett samlat stopp av allt på en nod har sin egen budget: det försöker en ren avstängning, väntar upp till tre minuter som standard, och stoppar sedan hårt det som fortfarande kör.

Den ärliga beskrivningen av en obevakad avstängning är alltså: fråga artigt, vänta en fast tid, dra sedan ur sladden. Om din databas behöver fyra minuter för att skriva klart har standardvärdena redan bestämt att den får tre.

Höj talet, hoppa inte över frågan

Det är lockande att behandla tidsgränsen som ratten att justera. För en maskin som verkligen behöver längre tid är det rätt att höja den.

Men en maskin som aldrig stängs av hur länge du än väntar har inget tidsgränsproblem, och att ge den tio minuter betyder bara att du väntar tio minuter på samma tvingade stopp. Ta först reda på om någon lyssnar.

När en avstängningsuppgift redan har fastnat

Sitter en avstängningsuppgift och hänger och maskinen måste ned nu, finns ett uttryckligt sätt att stoppa den och åsidosätta den pågående avstängningsuppgiften i stället för att ställa sig i kö bakom den. Det finns just för att fallet med den fastnade uppgiften är vanligt nog att behöva ett svar.

Använd det med vetskap om vad det är: fortfarande ett strömavbrott, med samma varning fäst vid sig.

Fallet som överraskar folk: strömavbrott

Här slutar hela texten vara akademisk.

Ett strömavbrottsskript som stänger av gäster innan batterierna tar slut ärver varje egenskap ovan. Det skickar förfrågningar. Gäster som inte lyssnar ignorerar dem. Tidsgränsen löper. Sedan stoppas allt som fortfarande kör hårt, kanske med redan svagt batteri och kanske allt på en gång.

Två saker är värda att kontrollera innan du litar på ett sådant upplägg, och båda är billiga:

Svarar gästerna verkligen på en avstängningsförfrågan? Testa en, med tidtagarur, en vanlig eftermiddag.

Ryms den samlade budgeten i batteriet? Gäster stängs av i följd, och tidsgränserna summeras. En rad maskiner som tar två minuter var är ingen tvåminutersavstängning.

En strömavbrottsplan som aldrig har repeterats är en plan som kommer att repeteras en enda gång: i mörkret, under tidspress.

Vad Atlas gör

Atlas hittar inte på en tredje sorts avstängning. Att fråga och att bryta strömmen är de två saker som finns, och att låtsas annat vore en lögn med följder.

Det Atlas gör är att vägra sudda ut skillnaden. En förstörande handling säger att den är förstörande innan du bekräftar den, så att "stoppa" aldrig kommer förklädd till ett något bestämdare "stäng av". Den skillnaden är hela ämnet för den här texten, och en panel som visar de två som grannknappar med samma tyngd har redan tappat den.

Den dagliga sammanfattningen bär den andra halvan: en oplanerad omstart rapporteras som ett faktum. En maskin som tvångsstoppats efter en misslyckad ren avstängning ser nästa morgon exakt ut som en maskin som kraschade. Båda förtjänar att märkas.

Källor

Proxmox egen dokumentation. På engelska, och den har sista ordet i den här frågan.

Relaterade artiklar

Hur ser det här ut inne i Atlas?

Gå till produktsidan