Why is correct autorouting so difficult, Garmin?

3 examples from a tour in Austria last weekend:

  1. Route from „Langenlois“ to „Nöhagen“:
    green = autoroute by garmin
    orange = simple direct waygarmin-navinonsene-01
  2. Route from „Melk“ to „Wieselburg“
    green = autoroute directing me on a minor road directly near the highway connection!
    note: no „highway“ or „toll road“ avoidance activated in the settings!!!
    orange: simple direct connection to the highway
    garmin-navinonsene-02
  3. Route from center of „Mariazell“ to „Neuberg an der Mürz“
    green = Garmin directing me on a very narrow, steep street in the city instead of leading me on the main road (orange) to the exit of the village
    garmin-navinonsene-03

navigation device: zumo660 (current firmware)
map: city navigator europe 2017.1

GPS-Routenoptimierung unter Einbeziehung von Ampelpositionen und -wartezeiten

Idee: Viele Navi-Hersteller oder auch Google/Apple verwenden Live-Daten (Feedback vom Navi oder Mobiltelefon, Anzahl der eingebuchten Mobiltelefone bei bestimmten Sendemasten) um den Verkehrsflluß bzw. Staus anzuzeigen.

Bis dato hat aber meines Wissens noch niemand die Anzahl der Ampeln auf einer Strecke sowie die Ampel-Wartezeiten in seine Routenberechnungen mit aufgenommen, obwohl diese in mittleren und großen Städten zur Berechnung der Route eigentlich sehr wichtig wären.

Garmin, TomTom, Apple, Google – anyone listening?
© by me (ca. 2010)

Shutdown eines ESXi-Servers mittels einer APC-USV und einem Windows-Host

Lange habe ich gegrübelt, wie man wohl ohne aufwendiges „Gepfriemel“ einen ESXi-Host (von VMware) bei einem Stromausfall, der länger dauert, korrekt herunterfahren könnte. Im Netz bzw. auf den VMware-Supportseiten findet man dazu alle möglichen Hinweise – von der Installation eines eigenen Plugins in den ESXi-Host (very complicated) bis hin zur Verwendung einer speziellen (und nicht gerade günstigen) Netzwerk-Verwaltungsschnittstellenkarte von APC selbst. Dabei ist die Lösung so einfach:

Man schleift die USB-Schnittstelle des ESXi-Hostservers, an der die USV angeschlossen ist, zu irgendeiner virtuellen Windows-Maschine (die auf ebendiesem ESXi-Host läuft) durch (Hardware konfigurieren, hinzufügen: USB-Controller, OK, Hardware hinufügen: USB-Gerät, die USV auswählen, OK) und installiert auf dieser virtuellen Windows-Maschine die kostenlose Powerchute-Version von APC (die jeder USV beiliegt bzw. von der APC-Homepage heruntergeladen werden kann).
Zur Sicherheit habe ich dem „APC PBE Agent“-Dienst noch ein lokales Administrator-Konto zugewiesen, damit er ungehindert agieren kann.

Danach wird´s ein bisschen komplizierter – allerdings nicht sehr:
Die SSH-Schnittstelle am ESXi-Host freischalten (Konfiguration vom ESXi-Host, Software, Sicherheitsprofil: Eigenschaften, dann den SSH-Dienst auswählen, Optionen, entweder auf „automatisch starten…“ oder „mit Host starten“) und danach natürlich auch starten.

Dann in der Windows-Client-Maschine das Programm „putty“ sowie „plink.exe“ (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) z.B. in den Ordner c:\putty herunterladen und (zumindestens) einmal eine SSH-Verbindung + Login zum ESXi-Host aufbauen (SSH-Key wird automatisch installiert), diese Verbindung in Putty speichern und den dabei vergebenen NAMEN merken.

Jetzt im CMDFILES-Ordner der APC Powerchute-Installation (üblicherweise c:\program files (x86)\APC\Power Chute Business Edition\agent\cmdfiles) eine eigene CMD-Datei anlegen (zB shutserver.cmd), die folgenden Befehl enthält:

@START „“ „c:\putty\plink.exe“ ESXI -l USERNAME -pw PASSWORT „/sbin/shutdown.sh && /sbin/poweroff“

ESXI = der Name der Verbindungssession, die in Putty gespeichert wurde
USERNAME / PASSWORT = Username und Password des Root-Accounts des ESXi-Hosts

Jetzt bleiben nur mehr zwei Tasks bis zum erfolgreichen Shutdown: In der Powerchute-Konfiguration die soeben angelegte „shutserver.cmd“-Datei im Menu „Shutdown“ unter „Shutdown settings“ (no na 😉 anwählen und (falls nicht sowieso bereits geschehen) am ESXi-Host die entsprechenden Aktionen zum Herunterfahren der virtuellen Maschinen konfigurieren (ESXi-Konfiguration, VM starten/herunterfahren, Eigenschaften) – also entweder „Herunterfahren“ oder „Anhalten“.

Ich habe das Script getestet, es hat einwandfrei geklappt – ein vorheriger Wechsel des ESXi-Hosts in den Wartungsmodus war nicht nötig.

Hier der Vollständigkeit halber (mit Dank) noch der Link zu dem Originalartikel, der mich auf die richtige Spur gebracht hat:

https://community.spiceworks.com/how_to/55064-how-to-gracefully-shut-down-vsphere-5-x-esxi-free-using-an-eaton-ups-with-ipm-and-the-command-line

Den zweiten wichtigen Artikel, in dem ich darüber aufgeklärt wurde, dass man die Variablen für das @START-Kommando des APC Powerchute-Scripts (also zB @START „“ „c:\putty\plink.exe“ variable1 variable2 etc.) außerhalb der Anführungszeichen plazieren muß, werde ich nachreichen (wenn ich ihn wiedergefunden habe).

Ein weiterer interessanter Artikel, der sich mit dieser Thematik beschäftigt: https://www.binarus.de/articles/apc-usv-network/apc-usv-network.shtml

Nachtrag 27.3.2019

Nach einigen Stromausfällen und nicht ordnungsgemäß heruntergefahrenen Hosts habe ich mich nochmal auf die Suche nach „dem Fehler“ begeben und bin draufgekommen, dass mit dem oben genannten Kommando ( @START „“ „c:\putty\plink.exe“ ESXI -l USERNAME -pw PASSWORT „/sbin/shutdown.sh && /sbin/poweroff“) KEIN korrektes Herunterfahren oder Anhalten der virtuellen Maschinen erfolgt.

Nach erneutere, längerer Suche habe ich HIER ein korrektes Script gefunden, welches alle aktiven Maschinen korrekt anhält und danach den Host herunterfährt. Das Script hier zur Sicherheit nochmal in Kopie:

! /bin/ash
rm -f listid
touch listid
## Listing the running vms
esxcli vm process list |grep -v "^\s.*"| grep -v "^$" > list
#### cleaning the id.s file by keeping only the id
for name in cat list;do
vim-cmd vmsvc/getallvms | grep $name | grep vmx | grep -v "^$" | awk '{print $1}'>> listid
done
for id in cat listid;do
###### suspending vms##########
echo "Suspending the running machines"
vim-cmd vmsvc/power.suspend $id
done
removing files
#
rm list
rm listid
echo "done."
echo "shutting down the host now.."
/bin/poweroff

Ein paar Kleinigkeiten sind noch zu beachten:

Erstens muss der APC Agent-Dienst auf der Maschine, welche die USV überwacht, unter einem Administrator-Konto bzw Domänen-Admin laufen (nicht unter dem standardmäßigen lokalen Systemkonto), sonst wird das Command-File einfach nicht ausgeführt.

Und zweitens muss die Script-Datei mit den oben angeführten Befehlen auf einem der VMware Datenspeicher-Volumes (egal wo) angelegt werden. Speichert man sie nämlich in einem Systemordner ist sie nach dem nächsten Host-Neustart futsch – VMware lädt alle Betriebssystem-Komponenten beim Systemstart nämlich in´s RAM und speichert neu angelegte oder kopierte Dateien nicht mehr in´s Systemimage zurück.

Eine zusätzliche Hürde hat die neueste Putty- bzw. Plink-Version eingebaut: Eine neue Antispoof-Hürde bedingt ein Drücken der Enter-Taste nach Herstellen der Verbindung, was natürlich während der Ausführung des Command-Files nicht möglich ist, das bleibt dann einfach hängen. Mit der Option
-no-antispoof kann man diese Abfrage deaktivieren.

Bei mir sieht das Command-File nunmehr so aus:

@START "" "c:\putty\plink.exe" HOSTNAME -l USER -pw PASSWORT -no-antispoof "/vmfs/volumes/5a50c0f7-297da616-d8b7-blablablabla/scripts/suspend.sh"