[Guide] ESXi / APC-USV / Automatischer Shutdown mit CentOS-VM

Ich war es leid, das Shutdown-Script immer wieder anpassen zu müssen, wenn ich neue VMs zum Leben erweckte. Nach einiger Recherche habe ich jetzt folgendes Script am laufen. Das Script macht folgendes:

1) Shutdown aller laufenden VMs, Ausnahme: Storage VM, denn diese muss als letztes herunter gefahren werden.
2) Pause, um sicher zu stellen, dass alle VMs genug Zeit haben, herunter zu fahren
3) Shutdown der Storage VM
4) Pause, um sicher zu stellen, dass Storage VM sauber herunter gefahren werden kann
5) Shutdown des ESXI Hosts

Damit werden immer alle VMs automatisch herunter gefahren. Das einzige, was ich im Script jetzt noch anpassen muss, sind Name und VM-ID der Storage VM. Bleibt dies konstant, sichert das Script immer, wie oben beschrieben, das saubere Herunterfahren des gesamten Systems.

Ich habs getestet und für gut befunden :)

Code: 
###### Shutdown aller laufenden VMs mit Ausnahme der StorageVM

## hier den Namen der StorageVM eingeben
StorageVM='[B][COLOR="#B22222"]NAME_DEINER_STORAGE_VM[/COLOR][/B]'

## Schleife, um alle laufenden VMs mit Ausnahme der StorageVM herunter zu fahren 

VMS=`vim-cmd /vmsvc/getallvms | tail -n+2 | awk '{print $1","$2}'`

for vm in ${VMS}
do
        vmID=`echo $vm | cut -d',' -f1`
        vmName=`echo $vm | cut -d',' -f2`

        if [ $vmName != $StorageVM ]
        then
                powerState=`vim-cmd vmsvc/power.getstate $vmID | tail -n+2`

                if [ "$powerState" == "Powered on" ]
                then
                       vim-cmd vmsvc/power.shutdown $vmID
                fi
        fi
done

## Pause, um alle laufenden VMs mit Ausnahme der Storage VM sauber herunter fahren zu lassen
sleep 180s


###### Shutdown StorageVM
vim-cmd vmsvc/power.shutdown [B][COLOR="#B22222"]tbd[/COLOR][/B] # Storage VM-ID kann mittels [I]vim-cmd /vmsvc/getallvms[/I] ermittelt werden

#Pause, um die StorageVM sauber herunter fahren zu lassen
sleep 180s


###### Shutdown ESXI-Host
poweroff

Quelle: Shutdown all VMs on ESXi host except one : vmware
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also bei mir läuft das seit einem Jahr komplett problemlos mit ESXI Boardmitteln, d.h. "Autostart order".

Ein

Code: 
ssh root@esxi /sbin/poweroff

fährt alle VMs ordnungsgemäß in umgekehrter "Autostart order" runter und schaltet danach den Host aus.

Dazu ist es lediglich notwendig einmal die public key Authentifizierung für SSH einzurichten und die Autostart Reihenfolge der VMs festzulegen.
Napp-It als meine Storage-VM mit der NFS Freigabe als ESXi Datastore für meine weiteren VMs wird dabei natürlich als letztes runtergefahren und beim Einschalten wieder als Erstes gestartet.
 
Yepp. Das geht auch. Wenn allerdings eine neue VM noch nicht für den Autostart vorgesehen ist, wird diese auch nicht runter gefahren (oder?). Und dann gibt es für das System/die VM einen undefinierten Zustand. Mit dem Script ist auf jeden Fall sichergestellt, dass ALLE auf dem System laufenden VMs runter gefahren werden.

Ich finde das Script deswegen charmant, weil es, nach dem Motto: "Set and forget", mit dem einmaligen Einrichten getan ist. Natürlich unter der Annahme, die StorageVM bleibt unverändert.
 
Nungut, das Poweroff geht auch nur, wenn VMTools (oder open-vm-tools usw.) auf der VM installiert sind. Ansonsten zieht er der VM technisch gesehen einfach den Stecker.
Beides hat seine Vor/Nachteile. Ich bin aber auch eher bei den ESXi Bordmitteln - VMs, die ich nicht irgendwie in den Autostart reinpacke sind bei mir auch nicht wichtig und von daher egal, da diese bei einem erneuten Hochfahren sowieso nicht starten.
 
Aber da müssten sich beide Optionen nicht unterscheiden, oder? Wenn die VM-Tools in der VM nicht installiert sind, dann wird die VM einfach ausgeschaltet?
 
Beide Varianten haben m.E. ihre Daseinsberechtigung. Ich habe zum Beispiel bei mir aus verschiedenen Gründen nur eine einzige VM (und nicht die Storage-VM) für den Autostart konfiguriert, alle anderen starte ich immer manuell.

Die APCUPSD-VM an sich ist ja der eigentliche Clou, was man dann damit macht, kann man ja zum Glück nach Gutdünken selbst entscheiden... schon mehr als einen Rechner nur mit einer USB-USV steuern zu können, hilft ja zum Teil schon. ;)
 
Danke erstmal für den Guide, hat fast einwandfrei unter Ubuntu funktioniert. SELinux habe ich jetzt nicht benutzt, wofür eigentlich? Und ich nutze halt auch /sbin/poweroff. Allerdings hat es mir danach irgendwie die USV aus der VM gehauen und ich musste das USB Kabel neu stecken damit die USV wieder richtig erkannt wurde(es wurde nur irgendein Vendor Code statt der UPS Name gezeigt). Hat da jemand eine Idee?
 
SELinux = Security Enhanced Linux: SELinux – Wikipedia

Ist halt auf einigen Server-orientierten Distributionen von Haus aus dabei und aktiv. Das Schutzniveau ist damit schon höher, der Konfigurationsaufwand aber ggf. auch. ;)

Woran das „Verschwinden“ der USV liegen könnte, weiß ich jetzt auch nicht. Wie ist denn Dein Hardware-Setup?
 
Das ist ja einen super Anleitung, genau was ich greade suche Danke dafür :)
 
Zuletzt bearbeitet:
Das freut mich. :)
 
Eieiei ich mag linux nicht oder es mag mich nicht. Mein ESXi basiert auf AMD Ryzen und so wie es scheint kann centOS die R CPUs nicht ab? Ich bekomme nach dem boot n Kernelpanic

Das ganze sollte aber auch unter UBUNTU funktionieren oder?
 
Aktuelles BIOS auf dem Mainboard? Gab da doch‘n Bug. Ggf. mal Secure Boot in den VM-Einstellungen unter ESXi für diese VM deaktivieren.

Stochere aber im Nebel, hab keinen AM4-Ryzen.
 
Also ich hab das soweit unter UBUNTU zum laufen gebracht. Ist mr auch lieber da ich schon mit 1 Distro genug zu tuen habe (<---NOOB)

apcaccess sagt mir die USV ist online und es kann darauf zugreifen.

hatte sogar noch ein erweitertes TUT gefunden das einen apache installiert und die USV Daten in einer Website darstellt - neat :)

Jetzt muss ich nur noch den Rest verstehen und umsetzten.

SELinux braucht man zuhause glaub ich nicht oder?
 
Habe das mal ungesetzt und die Einrichtung war sehr gut beschrieben :) (vi ist horror aber anedes Thema ...)

Wenn ich den Strom an der USV abschalte passiert einfach nichts. Irgendwo hab ich einen Fehler gemacht aber wo?

Die USV VM meldet das der Strom weg ist und nach einiger zeit kommt die Shutdown "Meldung" aber es fährt die VMs nicht herrunter.

Hat jemand Tipps ?

Danke
 
Funktioniert denn sudo ./apccontrol doshutdown" (davon wird aber ausdrücklich abgeraten! - nur mal zum Testen)?

Welche VM versuchst Du denn herunterzufahren? Die, die die USV steuert oder eine andere? Klappt SSH auf den ESXi-Host ohne Passworteingabe?
 
Als root funktioniert der Login via SSH passwortlos. Als normaler user nicht (Da kommt dan n dioe PW Abfrage
 
Dann ist gut. Hast Du denn auch schon die apccontrol editiert und mal ausprobiert?
 
Hab ich editiert und da steht jetzt der Befehl zum runterfahren.

./apccontrol doshutdown

funktioniert nicht.... da kommt immer eine Meldung das das Komando nicht gefunden wird ?

Ich hab eine SmartUPS 750. Meine VM gibt an das ich insgesammt 109 MInuten Runntime habe.

Mein ESXi mit allem an zieht ca. 150W peak.

Ich denke die UPS läuft noch auf Batterie bis der TIMER abgelaufen ist. Also es passiert nichts weil ja noch genug saft in der UPS ist.

Was muss ich denn in der config einstellen damit die sofort herrunterfährt?

Imo sieht das so aus:

Code: 
ONBATTERYDELAY 6

#
# Note: BATTERYLEVEL, MINUTES, and TIMEOUT work in conjunction, so
# the first that occurs will cause the initation of a shutdown.
#

# If during a power failure, the remaining battery percentage
# (as reported by the UPS) is below or equal to BATTERYLEVEL,
# apcupsd will initiate a system shutdown.
BATTERYLEVEL 30

# If during a power failure, the remaining runtime in minutes
# (as calculated internally by the UPS) is below or equal to MINUTES,
# apcupsd, will initiate a system shutdown.
MINUTES 10

# If during a power failure, the UPS has run on batteries for TIMEOUT
# many seconds or longer, apcupsd will initiate a system shutdown.
# A value of 0 disables this timer.
#
#  Note, if you have a Smart UPS, you will most likely want to disable
#    this timer by setting it to zero. That way, you UPS will continue
#    on batteries until either the % charge remaing drops to or below BATTERYLEVEL,
#    or the remaining battery runtime drops to or below MINUTES.  Of course,
#    if you are testing, setting this to 60 causes a quick system shutdown
#    if you pull the power plug.
#  If you have an older dumb UPS, you will want to set this to less than
#    the time you know you can run on batteries.
TIMEOUT 30
 
So sieht meine aus:

Code: 
#
# These variables are needed for set up the autoconf other variables.
#
prefix=/usr
exec_prefix=/usr

APCPID=/var/run/apcupsd.pid
APCUPSD=/sbin/apcupsd
SHUTDOWN=/usr/sbin/shutdown
SCRIPTSHELL=/usr/bin/sh
SCRIPTDIR=/etc/apcupsd
WALL=wall

export SYSADMIN=root
export APCUPSD_MAIL="/bin/mail"
if [ -f $SCRIPTDIR/config ]; then . $SCRIPTDIR/config ; fi

#
# Concatenate all output from this script to the events file
#  Note, the following kills the script in a power fail situation
#   where the disks are mounted read-only.
# exec >>/var/log/apcupsd.events 2>&1

#
# This piece is to substitute the default behaviour with your own script,
# perl, or C program.
# You can customize every single command creating an executable file (may be a
# script or a compiled program) and calling it the same as the $1 parameter
# passed by apcupsd to this script.
#
# After executing your script, apccontrol continues with the default action.
# If you do not want apccontrol to continue, exit your script with exit
# code 99. E.g. "exit 99".
#
# WARNING: the apccontrol file will be overwritten every time you update your
# apcupsd, doing `make install'. Your own customized scripts will _not_ be
# overwritten. If you wish to make changes to this file (discouraged), you
# should change apccontrol.sh.in and then rerun the configure process.
#
if [ -f ${SCRIPTDIR}/${1} -a -x ${SCRIPTDIR}/${1} ]
then
    ${SCRIPTDIR}/${1} ${2} ${3} ${4}
    # exit code 99 means he does not want us to do default action
    if [ $? = 99 ] ; then
        exit 0
    fi
fi

case "$1" in
    killpower)
        echo "Apccontrol doing: ${APCUPSD} --killpower on UPS ${2}" | ${WALL}
        sleep 10
        ${APCUPSD} --killpower
        echo "Apccontrol has done: ${APCUPSD} --killpower on UPS ${2}" | ${WALL}
    ;;
    commfailure)
        echo "Warning communications lost with UPS ${2}" | ${WALL}
    ;;
    commok)
        echo "Communications restored with UPS ${2}" | ${WALL}
    ;;
#
# powerout, onbattery, offbattery, mainsback events occur
#   in that order.
#
    powerout)
    ;;
    onbattery)
        echo "Power failure on UPS ${2}. Running on batteries." | ${WALL}
    ;;
    offbattery)
        echo "Power has returned on UPS ${2}..." | ${WALL}
    ;;
    mainsback)
        if [ -f /etc/apcupsd/powerfail ] ; then
           printf "Continuing with shutdown."  | ${WALL}
        fi
    ;;
    failing)
        echo "Battery power exhausted on UPS ${2}. Doing shutdown." | ${WALL}
    ;;
    timeout)
        echo "Battery time limit exceeded on UPS ${2}. Doing shutdown." | ${WALL}
    ;;
    loadlimit)
        echo "Remaining battery charge below limit on UPS ${2}. Doing shutdown." | ${WALL}
    ;;
    runlimit)
        echo "Remaining battery runtime below limit on UPS ${2}. Doing shutdown." | ${WALL}
    ;;
    doreboot)
        echo "UPS ${2} initiating Reboot Sequence" | ${WALL}
        ${SHUTDOWN} -r now "apcupsd UPS ${2} initiated reboot"
    ;;
    doshutdown)
        echo "UPS ${2} initiated Shutdown Sequence" | ${WALL}
        /usr/bin/ssh root@_IP_ "sh /vmfs/volumes/SSDSandsk_Local/Scripts/shutdown-all-vms.sh"
    ;;
    annoyme)
        echo "Power problems with UPS ${2}. Please logoff." | ${WALL}
    ;;
    emergency)
        echo "Emergency Shutdown. Possible battery failure on UPS ${2}." | ${WALL}
    ;;
    changeme)
        echo "Emergency! Batteries have failed on UPS ${2}. Change them NOW" | ${WALL}
    ;;
    remotedown)
        echo "Remote Shutdown. Beginning Shutdown Sequence." | ${WALL}
    ;;
    startselftest)
    ;;
    endselftest)
    ;;
    battdetach)
    ;;
    battattach)
    ;;
    *)  echo "Usage: ${0##*/} command"
        echo "       warning: this script is intended to be launched by"
        echo "       apcupsd and should never be launched by users."
        exit 1
    ;;
esac

Wichtig ist dieser Abschnitt:
(...)
doshutdown)
echo "UPS ${2} initiated Shutdown Sequence" | ${WALL}
/usr/bin/ssh root@_IP_ "sh /vmfs/volumes/SSDSandsk_Local/Scripts/shutdown-all-vms.sh"
(...)

Anstatt _IP_ muss da die IP von Deinem ESXi-Host stehen und anstatt "SSDSandsk_Local/Scripts/shutdown-all-vms.sh" eben der Teil des Pfades und der Name des Scripts auf dem ESXi-Host bei Dir.

Mit dem Befehl "./apccontrol doshutdown" kannst Du halt manuell das Event auslösen, unabhängig wie viel Saft / Zeit noch in der USV ist - also gut zu Testzwecken. Um den Befehl auszuführen, musst Du Dich im Verzeichnis /etc/apcupsd/ befinden.
 
Code: 
sh: can't open '/vmfs/DS_4_FC_2TB/scripts/shutdown-all-vms.sh': No such file or directory

Geht als nicht weil es nicht auf den Datastore kommt. Ich hatte da eigentlich diese lange ID eingetragen. Damit ging es auch nicht?

So nach n bisschen fummeln fährt jetzt alles runter wenn ich den Befehl eingebe. Schon mal gut :P
 
Zuletzt bearbeitet:
:)
 
Wenn man einen 2 ESXi damit herunterfahren möchte kann man einfach die Schritte kopieren oder?

Also Key erstellen, in ESXi ablegen, neues Script im Datastore hinterlegen und so weiter ?
 
Grds. ja. Musst halt im Prinzip nur zwei befehle in der apccontrol hinterlegen.
 
Anmelden, um zu antworten.

Ähnliche Themen

E
ESXi (free) zusätzlicher Benutzer mit SSH Zugriff
Antworten
1
Aufrufe
262
Liesel Weppen
L
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh