Virsh auf QNAP nutzen - Virtuelle Maschinen via SSH starten / stoppen

[PROLOG] _{^{Ein Prolog ist übrigens das Vorwort, ein Epilog das Schlusswort. Das habe ich bei meinen anderen Artikeln durcheinandergebracht, lässt sich aber nicht mehr ändern...}}

Freitagabend, Partytime... ist dank COVID-19 momentan nicht drin. Deshalb habe ich spontan einfach Freitagabend, NAS-Migrationstime draus gemacht.

Unspektakulär, denn das verlief bei mir seit jeher problemlos. Diesmal ist aber eine Kleinigkeit anders:

Die SSD welche meine VM beherbergt wird nämlich nicht mit umziehen und weicht einer M.2 SSD. Nach der Migration also einfach einen RTRR Restore der VM Images auf die M.2 gemacht und diese für die VM in der Virtualization Station neu eingebunden. Läuft.

Zumindest bis zu dem Punkt, an dem ich die VM wie gewohnt via SSH starten möchte, das funktioniert nicht mehr.

Der Grund weshalb ich die VM gerne auf diese Weise starten und stoppen möchte ist einfach:

Meist arbeite ich mit VM temporär vom z.B. Sofa aus auf meinem Smartphone und die VM soll nicht ständig laufen, ich nutze sie nur für Testzwecke.

Nicht nur, dass es mich nervt mich dazu ständig in der GUI mit ultralangem Passwort und 2FA anmelden zu müssen, der Browser auf dem Smartphone wird von der Virtualization Station gar nicht erst unterstützt, sodass es offensichtlich einem PC bedarf um eine VM aus der GUI von QTS heraus zu starten.

Da ich mich jetzt sowieso wieder bewusst damit beschäftigen muss:

Warum sollte ich diese Information hier nicht teilen, denn ich glaube der ein oder andere User könnte ebenfalls Interesse haben seine VM auf diese einfache Art zu kontrollieren.

[WAS IST VIRSH?]

Virsh ist ein Tool mit dem man über Kommandozeilen virtuelle Maschinen verwalten kann. Neben dem einfachen Starten, Stoppen und Rebooten kann man auch neue VM anlegen und bearbeiten. Ein zugegeben für meine Erfahrung mit Linux und VM zu komplexes Programm, aber für das reine Starten und Stoppen reichen meine Erfahrungen.

[WO BEKOMMT MAN VIRSH FÜR QNAP?]

Wer jetzt im App Center oder diversen Repos gesucht hat wird enttäuscht sein, denn von virsh fehlt dort jede Spur. Virsh ist, zumindest trifft dies auf meine Geräte zu, bereits auf dem QNAP in den shared libaries enthalten, es muss (ab QTS 4.1.x ? ) allerdings erst verlinkt werden, damit die Anwendung gefunden und gestartet werden kann.

[VIRSH (AUF QNAP) VERWENDEN]

Wir befinden uns ab sofort in einer SSH Session auf dem QNAP.

Wie schon angedeutet muss virsh in den shared libaries erstmal verlinkt werden. Ich mache das jedes Mal aufs Neue wenn ich virsh verwende, möglicherweise weiß jemand mit mehr Linux Erfahrung, wie dies einmalig auf Dauer zu bewerkstelligen ist.

Dazu dient der Befehl export LD_LIBRARY_PATH=/QVS/usr/lib:/QVS/usr/lib64/ export PATH=$PATH:/QVS/usr/bin/:/QVS/usr/sbin/ welcher im Nachfolgenden vor jeder Verwendung von virsh eingegeben wird, nachdem virsh mit exit (oder quit) oder die SSH Session beendet wurde.

Zunächst gilt es herauszufinden wie die VM "intern benannt" sind, virsh spricht hier von "domain name" und bei einer VM im Allgemeinen übrigens von "guest". Dieser Step ist einmalig, wir müssen uns die Ergebnisse nur für die spätere Verwendung notieren. Außerdem wollen wir erstmal herausfinden, welche VM überhaupt durch virsh kontrolliert werden können. Ob und welche Restriktionen es da gibt ist mir jedoch nicht bekannt.

Vorbereitung

1. Shared libaries verlinken:

export LD_LIBRARY_PATH=/QVS/usr/lib:/QVS/usr/lib64/ export PATH=$PATH:/QVS/usr/bin/:/QVS/usr/sbin/

2. Virsh starten:

virsh

3. Alle verfügbaren (und kontrollierbaren) VM anzeigen:

list --all

Bei mir sieht die Ausgabe wie folgt aus:

virsh list --all.JPG

Selbsterklärend: unter "state" wird angegeben in welchem Zustand sich die VM mit dem entsprechenden domain name befindet.

Die Zuordnung der VM zu den domain names ist einfach:

In der Virtualization Station wird in den Einstellungen der jeweiligen VM unter Information/ Allgemein die UUID angezeigt, die dem domain name entspricht:

VS_UUID.JPG

Den domain name bzw. UUID benötigen wir um die VM später zu kontrollieren. Ich habe mir die UUID dazu mit einer kurzen Beschreibung welche VM das ist in einer Textdatei gespeichert, aus der ich mir später die Befehle für die Verwendung von virsh einfach herauskopiere.

Eine VM mit Virsh starten

1. Shared libaries verlinken:

export LD_LIBRARY_PATH=/QVS/usr/lib:/QVS/usr/lib64/ export PATH=$PATH:/QVS/usr/bin/:/QVS/usr/sbin/

2. Virsh starten:

virsh

5. VM starten

start [domain name / UUID der VM] #ohne [ ]

6. Virsh beenden (optional)

exit

7. SSH Session beenden (optional)

exit

Eine VM mit Virsh herunterfahren

Voraussetzung ist dass ACPI funktionsfähig ist, wie ich gelesen habe. Da ich mich nicht sehr mit VM beschäftige weiß ich nicht ob und wo man das ändern kann.

1. Shared libaries verlinken:

export LD_LIBRARY_PATH=/QVS/usr/lib:/QVS/usr/lib64/ export PATH=$PATH:/QVS/usr/bin/:/QVS/usr/sbin/

2. Virsh starten:

virsh

3. VM herunterfahren

shutdown [domain name / UUID der VM] #ohne [ ]

4. Virsh beenden (optional)

exit

5. SSH Session beenden (optional)

exit

Das Herunterfahren überprüfe ich persönlich immer wieder mit list --all, da die VM sporadisch aus mir nicht erfindlichen Gründen nicht herunterfahren und es einen zweiten Anlauf benötigt. Was mir aufgefallen ist, ist dass dies scheinbar nur dann der Fall ist, wenn ich eine Windows VM mit RDP fernsteuere. Weiter habe ich das aber noch nicht verfolgt.

Als Alternative (im Notfall) für shutdown ("graceful") der übrigens ein ordentliches Herunterfahren initiiert, gäbe es den Befehl destroy ("ungraceful") der einem harten Abschalten der VM entspricht. Für destroy gibt es die Option --graceful, mit der versucht werden soll das Dateisystem nicht zu beschädigen, ich habe es aber noch nie getestet und so weit soll es hier auch nicht gehen, nur ein Wissenswertes noch: list zeigt alle laufenden, list --all auch die abgeschalteten VM an.

In der Praxis sieht es bei mir so aus, dass ich mir die entsprechenden Befehle am PC in eine Textdatei geschrieben habe und per Copy and Paste schnell agieren kann. Auf Android nutze ich die Pro Version von JuiceSSH bei der ich Snippets erstellt habe, die die Befehle hintereinander abarbeiten und die SSH Session anschließend beenden.

Die Funktionen von virsh sind damit gerade einmal angekratzt, da geht noch vieles mehr, wer die Hilfe aufruft wird von der Fülle der möglichen Befehle nahezu erschlagen.

Mehr als start, shutdown und gelegentlich destroy nutze ich im Alltag aber auch nicht und für den hier behandelten Einsatzzweck ist es ausreichend.

Für jeden der mehr will bietet sich google an, hier findet man einiges an Hilfen zu virsh und seinen Befehlen. reboot, suspend und resume ist ebenfalls möglich und wahrscheinlich selbsterklärend, aber genug an dieser Stelle.

Achja: der Grund warum ich nach der Migration keine Kontrolle mehr mit virsh hatte war lediglich, dass sich die UUID der VM geändert hatte und in meinem Snippet noch die alte stand.

Ich hoffe dass diese Möglichkeit für den ein oder anderen ein nützliches und scheinbar verborgenes Feature darstellt, ich mag die Funktion jedenfalls nicht mehr missen.

Cheers