virsh shutdown eines kvm E1-VM nicht möglich.

[Hilmar Böhm]

Hallo,

ich benötige eine Möglichkeit, eine Eisfair-VM (Guest) vor einem Backup
(des "Container"-Img.) auf dem KVM-Host sicher herunterzufahren.

Leider funktioniert das Virsh Command "virsh shutdown <E1-Domain Name>
nicht. D.h. dass das Eisfair-VM auf keine der verfügbaren
Shutdown-Methoden reagiert:

___________________
--mode <string> shutdown mode: acpi|agent|initctl|signal|paravirt
___________________

Die 4 hinteren Methoden sind glaub ich ich meiner Umgebung nicht
anwendbar, aber die ersten beiden, acpi und agent.

Auf "--mode acpi" reagiert der Eisfair-Server nicht.

Die Methode "agent" erfordert einen qemu-guest-agent auf dem
Eisfair-Server, mit dem das virsh-shutdown kommuniziert. Diesen Client
gibt es leider nicht im Eisfair-Repo. (Viele andere habe ein
entsprechendes Paket, sogar Alpine Linux, das sich aber auch ohne diesen
Agent via "virsh shutdown" über die "acpi"-Methode beenden lässt.

[Natürlich gibt es auch die Möglichkeit den Server via:
"ssh root@<E1-VM> "halt".
Aber warum eine Sonderbehandlung stricken? Außerdem müsste ich das
Root-PW (lesbar) ins Script schreiben.

Wie habt ihr das gelöst?

Grüße. / Hilmar.

[Helmut Backhaus]

Hallo Hilmar

Am 04.08.2018 um 15:09 schrieb Hilmar Böhm:
>
> [Natürlich gibt es auch die Möglichkeit den Server via:
> "ssh root@<E1-VM> "halt".

Die Lösung nutze ich, aber mit poweroff.
"halt" sollte aber auch gehen.

Oder Du nutzt die dafür vorgesehenen User ...

ssh halt@<E!-VM>
ssh poweroff@<E!-VM>

Aber das habe ich noch nicht Passwortlos probiert, ich wüsste auch so
aus dem Stehgreif nicht wie das gehen könnte. Denn diese User haben ja
kein "home Verzeichnis" in dem sich eine ".ssh" befinden könnte.

> Aber warum eine Sonderbehandlung stricken?

Das kann ich Dir auch nicht sagen ...

> Außerdem müsste ich das Root-PW (lesbar) ins Script schreiben.
>

Nein, musst Du nicht, ich arbeite mit "keys", das hat auch den Vorteil,
dass man sich Passwortlos anmelden kann.

> Wie habt ihr das gelöst?
>

Wie oben beschrieben ... :-)


--
Gruß,
Helmut

[Kay Martinen]

Am 04.08.2018 um 15:09 schrieb Hilmar Böhm:
>

> ich benötige eine Möglichkeit, eine Eisfair-VM (Guest) vor einem Backup
> (des "Container"-Img.) auf dem KVM-Host sicher herunterzufahren.

Warum? Wer macht denn das Backup?

> Leider funktioniert das Virsh Command "virsh shutdown <E1-Domain Name>
> nicht.

Ich kenne virsh nicht. Ich nutze die Backup-Möglichkeiten von ProxMoxVE
über dessen WebUI

> Die Methode "agent" erfordert einen qemu-guest-agent auf dem
> Eisfair-Server, mit dem das virsh-shutdown kommuniziert. Diesen Client
> gibt es leider nicht im Eisfair-Repo.

Ist mir auch schon aufgefallen.

> Aber warum eine Sonderbehandlung stricken?

Ja, eben. Warum. M.E. geht es auch ohne!

> Wie habt ihr das gelöst?

Ich gehe in der Proxmox GUI auf Backup, wähle den Storage aus, lasse
alles andere (Snapshot, lzo) so und sage "Abflug". Läßt sich auch
zentral für mehrere VMs regelmäßig einrichten als Backup-job.

Das läuft so hier schon eine weile. IMHO wird der Host dabei kurz
eingefroren, ein snapshot erstellt, der host wieder aufgetaut und der
Snapshot dann weg gesichert. Da das in der Nacht passiert bin ich noch
nie eingeloggt gewesen und kann nicht sagen ob und wie lang das dauert.
Das Image sichern geht jedenfalls in minutenschnelle.

Nur neulich beim Umzug auf einen anderen Host habe ich alle VMs beendet,
Backup-mode STOP gewählt und auf dem neuen Host diese images zurück
gespielt. Und dort laufen sie nun schon wochenlang ohne Probleme.

Klingt für mich also als ob du es dir unnötig schwer machst - oder ich
etwas falsch. :-/

Kay

--
Sent via SN (Eisfair-1)

[Hilmar Böhm]

Hallo Kay,

ich glaube wir reden da aneinander vorbei. Du fährst mit Deinem
Promox-Server einen Mercedes, ich dagegen mit meinem Debian Server und
KM als Virtualisieren nur einen Feld-, Wald- und Wiesen-Golf. Beide
Systeme sind m.E. nicht vergleichbar (Zumindest nicht vom
Admiralin-Standpunkt aus).

Proxy verwendet als Dateisystem ZOFFS, das hat eine Schnaps-Funktion
bereits eingebaut. (Selbst wenn man Proxy mit MALVE Volumes nutzt, gibt
es eine Schnaps-Funktion.) Durch diese Schnaps-Funktion und durch eine
von Promoter/KVM ermöglichte Spendend-Funktion ist es möglich,
konsistente Hotspots von laufenden KM-Gastsystemen mit nur kurzen
Unterbrechungen zu erzeugen, von dem ein Backup (Web-GUT oder dumpf)
gemacht wird und von dem auch nach einem Restore wieder ein konsistentes
Gastbetriebssystem gestartet werden kann.
Ich habe nur ein einfaches ex4-Filesystem, auf dem in einem Verzeichnis
die KM-Images meiner KM-Gäste wohnen. Also Unix Schnaps!

Damit ich ein konsistentes Backup machen kann (ex4 kennt keine Schnaps),
muss ich das Gastsystem stoppen oder aber noch besser herunterfahren,
dann mit dem Backup-System des Debian-Servers (in meinem Fall
"Screenshot") ein Backup erzeugen und danach die Gäste, die zum
Triggerzeitpunkt liefen, wieder hochfahren.
Du brauchst selbstverständlich mit Deinem Mercedes nur ein paar Klicks.
Bär' auch schlecht, Wendens nicht so wäre. Ich würde an Deiner Stelle
bei Deinen Eis fair-Gästen allerdings etwas misstrauisch sein, ob die
Backups mit dumpf wirklich konsistent durchgeführt werden, denn Eis fair
regiert nicht auf ein Showdown Kommando, das von "außerhalb" abgesetzt wird.

[Ein Crash eines Systems (erzeugt mit "virsh destroy") wirkt wie Stecker
ziehen und hinterlässt ein inkonsistentes System. Virsh kann auch
Snapshots erzeugen, aber m.W. nur innnerhalb der _QCOW2_-Images des
Gastes, was u.U. sehr große Images voraussetzen kann.]

virsh ist die Kommandozeilen-App, mit der man vollständig eine
KVM-Umgebung administrieren kann. Natürlich kann man auch
GUI-Applikationen verwenden (z.B. "virtual-manager"). Aber ich muss das
Starten und Stoppen fürs Backup skripten und das mache ich deshalb mit
"virsh" (VIRtualSHell).
(Btw. Vermutlich verwendet Proxmox intern auch Virsh-Funktionen / Kommandos)

Also sind meine Anforderungen anders als Deine!
Und die Frage wäre: Muss ich denn Proxmox installieren, um ein Backup
meiner VM's zu machen?

Ich sollte daher genauer fragen,
- ob es Nutzer von virtualisierten Eisfair-Servern gibt, die auf einem
KVM-Virtualisierer laufen
- und als Filesystem für die Images nur ext4 nutzen
- und die solche Gast-Images konsistent sichern.

Trotzdem vielen Dank für Deine Antwort. Proxmox ist sicherlich ein Thema
für mich und eines meiner nächsten Projekte. Die HW dafür hätte ich.
(Aber die Zeit... Selbst für kleine Admins im 65+ Status. :-) )

Grüße. / Hilmar.

[Hilmar Böhm]

Am 04.08.2018 um 21:40 schrieb Hilmar Böhm:
> (Zumindest nicht vom Admiralin-Standpunkt aus)
(Zumindest nicht vom Admin-Standpunkt aus)
Sch... Autokorrektur. Sorry

[Hilmar Böhm]

Am 04.08.2018 um 21:40 schrieb Hilmar Böhm:

> Dateisystem ZOFFS
ZFS!

[Hilmar Böhm]

ich werd nicht mehr... Sorry

Am 04.08.2018 um 21:40 schrieb Hilmar Böhm:

> Also Unix Schnaps!
Also nix mit Snapshots

[Kay Martinen]

Am 04.08.2018 um 21:40 schrieb Hilmar Böhm:

> ich glaube wir reden da aneinander vorbei. Du fährst mit Deinem
> Promox-Server einen Mercedes, ich dagegen mit meinem Debian Server und
> KM als Virtualisieren nur einen Feld-, Wald- und Wiesen-Golf. Beide
> Systeme sind m.E. nicht vergleichbar (Zumindest nicht vom

Würde ich nicht sagen. Das Basissystem von Proxmox ist ein
Debian-"Golf". ;-) Das Proxmox-ige steckt in deren Repository das beim
installieren automatisch mit eingebunden wird.

Das einzig "Mercedes-artige" hier mag die Hardware sein. Das ist ein
Proliant DL 360 Gen 5 Mit 12 GB, 8 Kernen und 2 Raids. Alt, aber
Zuverlässig.

> Proxmox verwendet als Dateisystem ZOFFS, das hat eine Snapshot-Funktion

> bereits eingebaut. (Selbst wenn man Proxy mit MALVE Volumes nutzt, gibt

Wenn du statt MALVE hier LVM meinst, richtig. Du KANNST ZFS nutzen. Und
für bestimmte Setups ist es auch ratsam. Es geht aber auch ohne!

> Ich habe nur ein einfaches ex4-Filesystem, auf dem in einem Verzeichnis
> die KM-Images meiner KM-Gäste wohnen. Also Unix Schnaps!

Aber ich benutze doch auch LVM und ext4 darauf.

root@pve:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 33,9G 0 disk
├─sda1 8:1 0 1007K 0 part
├─sda2 8:2 0 127M 0 part
└─sda3 8:3 0 33,8G 0 part
├─pve-swap 253:0 0 4,1G 0 lvm [SWAP]
├─pve-root 253:1 0 8,3G 0 lvm /
├─pve-data_tmeta 253:2 0 20M 0 lvm
│ └─pve-data-tpool 253:4 0 17,3G 0 lvm
│ ├─pve-data 253:5 0 17,3G 0 lvm
│ ├─pve-vm--601--disk--1 253:6 0 1G 0 lvm
│ └─pve-vm--600--disk--1 253:7 0 2G 0 lvm
└─pve-data_tdata 253:3 0 17,3G 0 lvm
└─pve-data-tpool 253:4 0 17,3G 0 lvm
├─pve-data 253:5 0 17,3G 0 lvm
├─pve-vm--601--disk--1 253:6 0 1G 0 lvm
└─pve-vm--600--disk--1 253:7 0 2G 0 lvm
sdb 8:16 0 136,7G 0 disk /storage
sr0 11:0 1 1024M 0 rom

> Du brauchst selbstverständlich mit Deinem Mercedes nur ein paar Klicks.
> Bär' auch schlecht, Wendens nicht so wäre. Ich würde an Deiner Stelle

Du kannst es auch "Drüber" installieren. Siehe:
https://pve.proxmox.com/wiki/Installation

> bei Deinen Eis fair-Gästen allerdings etwas misstrauisch sein, ob die
> Backups mit dumpf wirklich konsistent durchgeführt werden, denn Eis fair
> regiert nicht auf ein Showdown Kommando, das von "außerhalb" abgesetzt
> wird.

Siehe: https://www.thomas-krenn.com/de/wiki/LVM_Snapshots

Ich merke hier generell nichts von Unterbrechungen der VMs. Denn so wie
ich das sehe: Die VM wird vom Hypervisor eingefroren und wieder
aufgetaut. Die läuft danach einfach weiter als wär nix gewesen. Denn "es
passiert ja nix" in der Zwischenzeit. Darum ist es Egal ob Eisfair auf
ein ACPI-Event nicht reagiert oder sonst was.

Den Qemu-agent hab ich bei anderen Gästen (debian u.a.) installiert weil
er da z.B. hilfreich ist für die Bildschirm-darstellung. Und natürlich
reagiert er auf ein Shutdown des Hosts.

BTW: Wenn Proxmox selbst runter fährt, dauert es zwar Minuten. Aber dann
ist es auch Aus. Und nach dem Einschalten ebenso und die VMs sind dann
sofort wieder da. Ich hab den Verdacht die werden; auch ohne qemu-agent;
einfach nur eingefroren. Bisher völlig Problemlos.

>
> [Ein Crash eines Systems (erzeugt mit "virsh destroy") wirkt wie Stecker
> ziehen und hinterlässt ein inkonsistentes System. Virsh kann auch

Es Zieht ja niemand den Stecker dabei. Ich denke es ist mehr wie ein
kurzes pausieren eines daemons oder anderen Prozesses. Nur das hier eine
ganze VM kurz pausiert. Und darum braucht da auch nix runter gefahren zu
werden.

>
> virsh ist die Kommandozeilen-App, mit der man vollständig eine
> KVM-Umgebung administrieren kann. Natürlich kann man auch
> GUI-Applikationen verwenden (z.B. "virtual-manager"). Aber ich muss das
> Starten und Stoppen fürs Backup skripten und das mache ich deshalb mit
> "virsh" (VIRtualSHell).
> (Btw. Vermutlich verwendet Proxmox intern auch Virsh-Funktionen /
> Kommandos)

Es hat in der GUI eingebettet auch eine Kommandokonsole für jede VM. Ich
benutzte die nie weil es nicht nötig ist. Gut möglich das die Befehle
dort die gleichen sind. IMHO ist es aber eher eine qemu-shell o.ä.

>
> Also sind meine Anforderungen anders als Deine!
> Und die Frage wäre: Muss ich denn Proxmox installieren, um ein Backup
> meiner VM's zu machen?

S.O. Du kannst es nachinstallieren. Evtl. mußt du einmal neu booten um
den angepassten kernel zu starten aber danach hast du dann auch eine
WebUI mit der du dir das leben leichter machen kannst.

>
> Ich sollte daher genauer fragen,
> - ob es Nutzer von virtualisierten Eisfair-Servern gibt, die auf einem
> KVM-Virtualisierer laufen
> - und als Filesystem für die Images nur ext4 nutzen
> - und die solche Gast-Images konsistent sichern.

Ja, hier! Proxmox nutzt KVM und Qemu und ich habe ext4 auf lvm laufen
und darin laufen derzeit Drei Virtuelle Eisfair Server.

Das die Sicherungen konsistent sind beweist m.E. die Schilderung meines
Umzugs. Gut, da habe ich alle vorher gestoppt um sicher zu gehen. Aber
auch weil es eh länger dauerte und ich hoffte das die beteiligten IPs so
aus den caches der Switches u.a. raus sind wenn sie auf dem neuen Server
wieder starten. Klappte Perfekt.

Ich sah auch keinen Grund beim umzug einen Snapshot wieder her zu
stellen da ich eh den letzten Stand der VM sichern wollte - durch runter
fahren u.s.w.

> Trotzdem vielen Dank für Deine Antwort. Proxmox ist sicherlich ein Thema
> für mich und eines meiner nächsten Projekte. Die HW dafür hätte ich.
> (Aber die Zeit... Selbst für kleine Admins im 65+ Status. :-) )

-10 hier. Und es ist wirklich einfach. Hätte ich anfangs aber auch nie
gedacht.

[Hilmar Böhm]

Hallo Kay,

deine Ausführungen finde ich interessant, aber wenig hilfreich für mich.

Grüße. / Hilmar.

[Kay Martinen]

Am 05.08.2018 um 00:14 schrieb Hilmar Böhm:

>
> deine Ausführungen finde ich interessant, aber wenig hilfreich für mich.
>

Verstehe ich nicht. Mir scheint du hättest alle Voraussetzungen um dein
KVM aufzubohren. Oder ist deine Sorge das es daneben geht und du es
komplett neu aufsetzen müßtest?

Wenn du dagegen auf virsh, dem shutdown u.s.w. bestehst dann, Okay. Ist
deine Entscheidung.

[Thomas Zweifel]

Hallo Hilmar

Am 04.08.2018 um 15:09 schrieb Hilmar Böhm:

> ich benötige eine Möglichkeit, eine Eisfair-VM (Guest) vor einem Backup
> (des "Container"-Img.) auf dem KVM-Host sicher herunterzufahren.
>
> Leider funktioniert das Virsh Command "virsh shutdown <E1-Domain Name>
> nicht. D.h. dass das Eisfair-VM auf keine der verfügbaren
> Shutdown-Methoden reagiert:
>
> ___________________
> --mode <string> shutdown mode: acpi|agent|initctl|signal|paravirt
> ___________________

Mit ACPI geht das sehr gut, allerdings musst Du das "powerbutton" Paket
installieren und starten.

Dann reicht ein:
virsh shutdown eisfair --mode acpi

und der eis fährt herunter

> [Natürlich gibt es auch die Möglichkeit den Server via:
> "ssh root@<E1-VM> "halt".
> Aber warum eine Sonderbehandlung stricken? Außerdem müsste ich das
> Root-PW (lesbar) ins Script schreiben.

Oder mit einem passwortfreien Schlüssel.... auch nicht schön :-(




Gruss Thomas

[Hilmar Böhm]

Vieeelen Dank, Thomas!!

> Mit ACPI geht das sehr gut, allerdings musst Du das "powerbutton" Paket installieren und starten.

Das ist genau die Info, die ich brauchte. Es funktioniert wie eine 1! :-))

>
> Dann reicht ein:
> virsh shutdown eisfair --mode acpi

man kann auch den --mode Switch weglassen. "acpi" ist wahrscheinlich die
erste Methode, mit der der Shutdown versucht wird...

>> Aber warum eine Sonderbehandlung stricken? Außerdem müsste ich das
>> Root-PW (lesbar) ins Script schreiben.
>
> Oder mit einem passwortfreien Schlüssel.... auch nicht schön :-(

Richtig, das hatte ich mir auch schon überlegt. Lieber ist mir aber die
Sache oben...

Und ich brauch' meine Skripts nicht zu ändern.

> Gruss Thomas
>
Dank und Grüße. / Hilmar.

[Kay Martinen]

Am 05.08.2018 um 13:37 schrieb Thomas Zweifel:
> Hallo Hilmar
>
> Am 04.08.2018 um 15:09 schrieb Hilmar Böhm:

>> ich benötige eine Möglichkeit, eine Eisfair-VM (Guest) ...
>> ... auf dem KVM-Host sicher herunterzufahren.

>
> Mit ACPI geht das sehr gut, allerdings musst Du das "powerbutton" Paket
> installieren und starten.
>

Hey, danke für den Tip auch von mir. Ich hab das auf einer VM getestet
und weiß nun wohl auch warum mein VM-Server so lange braucht(e hoffe
ich). Der versucht die Eisfair-VMs runter zu fahren aber die reagierten
nicht. Ich kann nur vermuten das er sie beim runter fahren schlußendlich
automatisch in Suspend setzte. Dateisystem-Probleme hatte ich da
jedenfalls noch nie, oder es liegt einfach am Journal... Schwierig die
VM-Konsole zu erreichen wenn der Host schon den Shutdown durchführt und
keine lokale konsole da ist!

Eine Eisfair-VM ohne power_button: Reagiert auf nix wenn ich in Proxmox
"runter fahren" wähle.

Eine andere Eisfair-VM mit dem tool: Fängt sofort an runter zu fahren.

Die Dritte kann das tool nicht erreichen, die ist hoffnungslos veraltet.
Muß ich demnächst mal ersetzen.

Will das jetzt nicht aus probieren aber der Server wird wohl nun einige
Minuten Wartezeit sparen beim runter fahren. Gut für die UPS. :)

[Thomas Zweifel]

Hallo Hilmar

Am 05.08.2018 um 14:34 schrieb Hilmar Böhm:
> Vieeelen Dank, Thomas!!
>
>> Mit ACPI geht das sehr gut, allerdings musst Du das "powerbutton"
>> Paket installieren und starten.
>
> Das ist genau die Info, die ich brauchte. Es funktioniert wie eine 1! :-))
>
>> Dann reicht ein:
>> virsh shutdown eisfair --mode acpi
>
> man kann auch den --mode Switch weglassen. "acpi" ist wahrscheinlich die
> erste Methode, mit der der Shutdown versucht wird...

Laut manpage:
By default the hypervisor will try to pick a suitable shutdown method.

Je nachdem, was für eine Distribution Du beim installieren gewählt hast,
kann das gut gehen oder auch nicht.



Gruss Thomas

[Thomas Zweifel]

Hallo Kay

Am 05.08.2018 um 15:50 schrieb Kay Martinen:
> Am 05.08.2018 um 13:37 schrieb Thomas Zweifel:
>> Mit ACPI geht das sehr gut, allerdings musst Du das "powerbutton" Paket
>> installieren und starten.
>
> Hey, danke für den Tip auch von mir. Ich hab das auf einer VM getestet
> und weiß nun wohl auch warum mein VM-Server so lange braucht(e hoffe
> ich). Der versucht die Eisfair-VMs runter zu fahren aber die reagierten
> nicht. Ich kann nur vermuten das er sie beim runter fahren schlußendlich
> automatisch in Suspend setzte. Dateisystem-Probleme hatte ich da
> jedenfalls noch nie, oder es liegt einfach am Journal...

Solange genug Platz auf der Platte frei ist, spricht nichts gegen das
zwischenlagern der VM.

> Eine Eisfair-VM ohne power_button: Reagiert auf nix wenn ich in Proxmox
> "runter fahren" wähle.

Ein HW-Eis reagiert auch nicht auf den Powerschalter ohne acpid. :-)



Gruss Thomas