ubuntuusers.de

Ich stelle ja gerade um von Virtualbox auf QEMU/KVM, und das funktioniert tatsächlich recht gut. "Gefühlt" meine ich auch, dass die VMs dort schneller laufen. Danke für alle Tipps und für den Vorschlag der Umstellung überhaupt! (Zu meiner "Verteidigung": Ich habe vor ein paar Jahren schon einmal versucht, KVM zum Laufen zu bringen, und als das im Gegensatz zu Virtualbox nicht auf Anhieb funktionieren wollte, habe ich es drangegeben.)

Jetzt aber zu meiner Frage:

Auf meinen Hosts ist außer QEMU/KVM und den VMs tatsächlich nichts installiert, und bisher habe ich alle Virtualbox-VMs regelmäßig und automatisiert heruntergefahren, gesichert und dann neu gestartet. Beim Tod einer Host-Platte oder gar des Hosts (immer mal wieder: Netzteil-Tod) konnte ich so "blitzschnell" die VM aus dem Backup des vorherigen Tages wiederherstellen. Bei Virtualbox funktioniert das alles auf dem Dateisystem, alles, was zu einer VM gehört, steht in einem einzigen Verzeichnis.

Bei QEMU/KVM scheint mir das jedoch nicht so einfach zu gehen, denn die Einstellungen der VM finde ich zunächst gar nicht, die XMLs der Snapshots stehen in einem anderen Verzeichnis, und die "Virtual Disks" der Snapshots finde ich ebenfalls nicht, ich finde gar keine weiteren QCOW2-Dateien als die der "Basis-VDs".

1. Kann es sein, dass alle "Versionen"/Snapshots in der selben QCOW2 stecken? Wenn nein, wo liegen die Snapshot-VDs dann?

2. Muss ich jede VM über einen virsh-Aufruf exportieren, bevor ich sie in dieser Form dann sichern kann?

3. Habt Ihr eine "Best Practice" zum Sichern und Wiederherstellen von QEMU/KVM-VMs? Natürlich will ich das per Script und mit Cron machen.

Danke im Voraus für eure Tipps!

Emma2 schrieb:

"Gefühlt" meine ich auch, dass die VMs dort schneller laufen.

Nicht nur gefühlt. Sie sind es wirklich. Ich hab auch eben erst gewechselt. Vbox fühlte sich immer an als wenn man mit angezogener Handbremse fährt. 😀

1. Kann es sein, dass alle "Versionen"/Snapshots in der selben QCOW2 stecken? Wenn nein, wo liegen die Snapshot-VDs dann?

Ja die Snapshots werden intern verwaltet. Keine extra Datei.

schwarzheit schrieb:

Emma2 schrieb:

"Gefühlt" meine ich auch, dass die VMs dort schneller laufen.

Nicht nur gefühlt. Sie sind es wirklich. Ich hab auch eben erst gewechselt. Vbox fühlte sich immer an als wenn man mit angezogener Handbremse fährt. 😀

Ich habe es gestern Abend auch nachzulesen versucht, aber da schrieben einige, Virtualbox "könne mittlerweile auch KVM" (oder so ähnlich). Wenn das so ist, dann hatte ich das wohl bisher nicht aktiviert. Mein Eindruck bei Virtualbox war bisher, dass der insbesondere langsam wurde, wenn mehrere VMs gleichzeitig viel auf ihren VDs gearbeitet haben. Aber auf alle Fälle ist QEMU/KVM "nicht schlechter", und nach den Infos zur Lizenzsituation, die ich im anderen Thread erhalten habe, spricht ja nun wirklich alles für den Umstieg.

schwarzheit schrieb:

Emma2 schrieb:

1. Kann es sein, dass alle "Versionen"/Snapshots in der selben QCOW2 stecken? Wenn nein, wo liegen die Snapshot-VDs dann?

Ja die Snapshots werden intern verwaltet. Keine extra Datei.

Ok, dann gibt es also nur eine QCOW2 pro VM - das ist prima, denn bei Virtualbox war es leider manchmal so, dass die kaskadierten VDIs nicht mehr richtig zusammenpassten, weshalb mancher dort sogar ganz von der Verwendung von Snapshots abrät... (Zur Info: Ich nutze die auch nur vor einem großen Update - und auf meinen Install-Test-VMs, um verschiedene Versionsstände zur Verfügung zu haben.)

Dann bleibt "nur noch" die Frage, wie ich eine VM "exportiere" - oder spezifischer, wie ich sie sichere? (Das ist ja bei Virtualbox extrem einfach: Verzeichnis kopieren - fertig!)

Hab ich selber noch nicht getestet, aber würd ich hier nicht anders machen.

schwarzheit schrieb:

Hab ich selber noch nicht getestet, aber würd ich hier nicht anders machen.

Nä, das kann ja nicht funktionieren, zumindest nicht so einfach (oder ich bin völlig blind): Bei Virtualbox gibt es Dateien, die die vollständig VM beschreiben, insbesondere die "MyMachine.vbox", und die stehen alle in einem einzigen Verzeichnis.
Bei QEMU/KVM ist das zumindest über mehrere Verzeichnisse verteilt,

• die VMs anscheinend in /etc/libvirt/qemu

• die VDs anscheinend in /etc/libvirt/storage

• die Snapshots anscheinend in /var/lib/libvirt/qemu/snapshot

Aber in der Basis-XML, also der der VM selbst, kommt das Wortfragment "snap" nicht vor. Woher also "weiß" der virt-manager, dass die VM einen Snapshot hat? Macht er das über die Namen der Verzeichnisse (NB: Das Verzeichnis eines Snapshots heißt so wie die VM.) Ich bin also nicht sicher, was ich alles kopieren muss, um die VM zu "sichern".

Wenn Ihr damit allerdings auch keine Erfahrung habt, dann muss ich das wohl einfach mal ausprobieren. Danke bis hier!

Hallo Emma2.

Vielleicht helfen dir dieser Artikel weiter: https://www.computerweekly.com/de/tipp/Die-Snapshot-Grundlagen-von-KVM-verstehen & https://www.linux-magazin.de/ausgaben/2014/01/virt-manager/

Generell sind nur zwei Dateien wichtig. die .xml und die .qcow2. Nur diese beiden Dateien benötigt man um eine VM von Host A zu Host B zu transferieren oder eben aus einen Backup wiederherzustellen, solange sich an den default-Pfaden nichts geändert hat.

Auf meinen Hosts ist außer QEMU/KVM und den VMs tatsächlich nichts installiert, und bisher habe ich alle Virtualbox-VMs regelmäßig und automatisiert heruntergefahren, gesichert und dann neu gestartet

Mit cronjob, shellscript und virsh geht das auch beu KVM/Qemu. VM per cronjob runterfahren, per cronjob und shellscrypt sichern und danach per virsh die VM wieder starten.

Ok, dann gibt es also nur eine QCOW2 pro VM - das ist prima

Das ist default. Kannst auch zwei, drei oder mehr haben. Für meine KVM mit Nextcloud hab ich drei .qcow2.

Emma2 schrieb:

• die VMs anscheinend in /etc/libvirt/qemu

• die VDs anscheinend in /etc/libvirt/storage

• die Snapshots anscheinend in /var/lib/libvirt/qemu/snapshot

um das zu ändern, etwa weil man relevanten Dateien nicht in /etc/ bzw. /var/ haben will ist vor der Installation eine clevere Partitionierung angeraten. Dann kann man die /-Partition relativ klein halten und eine separate Partition oder gar SSD/HDD für qemu, storage und snapshot anlegen. Auf dieser dann die Unterverzeichnisse für qemu, storage und eben snapshot anlegen und in der /etx/fstab/ per Bind-Mounts in die passenden Verzeichnisse unterhalb /etc/ bzw. /var/ einbinden. Die Original Pfade bleiben unverändert, die Dateien liegen so aber physikalisch auf einer anderen Partition oder SSD/HDD, was dann auch die Sicherung vereinfacht. Alternativ wäre auch "ln -s" für die Verzeichnisse möglich, wenn die /etc/fstab/ nicht editiert werden soll.

adelaar schrieb:

um das zu ändern, etwa weil man relevanten Dateien nicht in /etc/ bzw. /var/ haben will <...>

Da war ich wieder ungenau, sorry. Meine QCOW2s liegen natürlich woanders, ich meinte die XML-Dateien für VMs, VDs und Snapshots, und die kann ich natürlich recht einfach per Cron/Bash sichern. Es ging mir hauptsächlich darum, welche Dateien nun wirklich gebraucht werden.

Auf alle Fälle habe ich jetzt verstanden, dass alle "Schnappschüsse der virtuellen Disk" in einer einzigen QCOW2 stehen. Korrekt? Frage aus Neugier: Was passiert denn dann, wenn ich eine solche QCOW2 in eine VM einbinde, ohne die XML der VD oder gar der Snapshots zur Verfügung zu stellen? Muss das nicht irgendwie krachen? (Bei Virtualbox ist es ja so, dass jeder Snapshot seine eigene "differentielle virtuelle Disk" hat und der Zusammenhang zwischen diesen vielen VDIs in einer XML beschrieben ist - was zugegebenermaßen oft zu Problemen mit "nicht mehr erreichbaren" Snapshots führt).

adelaar schrieb:

Hallo Emma2.

Vielleicht helfen dir dieser Artikel weiter: https://www.computerweekly.com/de/tipp/Die-Snapshot-Grundlagen-von-KVM-verstehen & https://www.linux-magazin.de/ausgaben/2014/01/virt-manager/

Ja, die sehe ich mir gern an.

Generell sind nur zwei Dateien wichtig. die .xml und die .qcow2. Nur diese beiden Dateien benötigt man um eine VM von Host A zu Host B zu transferieren oder eben aus einen Backup wiederherzustellen, solange sich an den default-Pfaden nichts geändert hat.

Aber XMLs können es schon mehrere sein, die ich brauche? Zumindest sieht es mir so aus, als gäbe es eine für die VM, eine für jede Virtuelle Disk und eine für jeden Snapshot.

Auf meinen Hosts ist außer QEMU/KVM und den VMs tatsächlich nichts installiert, und bisher habe ich alle Virtualbox-VMs regelmäßig und automatisiert heruntergefahren, gesichert und dann neu gestartet

Mit cronjob, shellscript und virsh geht das auch beu KVM/Qemu. VM per cronjob runterfahren, per cronjob und shellscrypt sichern und danach per virsh die VM wieder starten.

Ja, genau so will ich es (wieder) machen.

Ok, dann gibt es also nur eine QCOW2 pro VM - das ist prima

Das ist default. Kannst auch zwei, drei oder mehr haben. Für meine KVM mit Nextcloud hab ich drei .qcow2.

Aber Du meinst auch "eine pro Virtuelle Disk", oder? Das wäre mir dann klar.

Also nochmal konkret zu den Pfaden. Die hast du anders angegeben als sie (zumindest bei mir) per default sind

• /var/lib/libvirt/images/ sind die *.qcow2

• /etc/libvirt/qemu/ sind die *.xml (für die VM's)

Hat man eine VM mit dem Namen DebianServer konfiguriert, dann gibt es eine DebianServer.qcow2 und eine DebianServer.xml in den o.g Verzeichnissen.

Weitere *.xml gibt es noch in anderen Unterverzeichnissen. Etwa die /etc/libvirt/qemu/networks/default.xml für NAT-Network.

Warum schrieb ich, dass nur die DebianServer.qcow2 und eine DebianServer.xml wichtig sind für die eine zuvor konfigurierte VM mit dem Namen DebianServer? Alles was mit der VM zu tun hat ist da drin (abgesehen von Snapschots). Die lasse ich jetzt mal außen vor.

Mit diesen beiden Dateien kann man eine VM jederzeit auf einen anderen Host transferieren. Habe das grade erst vor ca. zwei Wochen im Zuge der Neuinstallation von zwei Notebooks mit vorher Xubuntu 22.04, nun 24.04 gemacht. War kein "do-release-upgrade" sondern tatsächlich eine komplette Neuinstallation bei der jeweils nur die /home-Partitionen unverändert erhalten geblieben sind. Alles andere, also auch /var und /etc kam neu.

Dann habe ich aus dem Backup von Notebook A (nennen wir sie im Beispiel mal) DebianServer.qcow2 und DebianServer.xml genommen und auf Notebook B in die Verzeichnisse /var/lib/libvirt/images/ und /etc/libvirt/qemu/ kopiert. Nach einem Neustart des Virt-Manager konnte ich die DebianServer-VM dann starten. Es waren keinerlei Änderungen oder Anpassungen nötig. Das habe ich aus der Zeit mit VirtualBox anders, eben deutlich komplizierter in Erinnerung.

adelaar schrieb:

Also nochmal konkret zu den Pfaden. Die hast du anders angegeben als sie (zumindest bei mir) per default sind

• /var/lib/libvirt/images/ sind die *.qcow2

• /etc/libvirt/qemu/ sind die *.xml (für die VM's)

Nee, unsere Pfade sind schon gleich (ich habe auch nichts daran geändert):

• in /etc/libvirt/qemu sind die XMLs für die VMs

• in /etc/libvirt/storage sind die XMLs für die Speicherpools

Alles was mit der VM zu tun hat ist da drin (abgesehen von Snapschots). Die lasse ich jetzt mal außen vor.

Das ist doch eine Aussage. Danke! Allerdings brauche ich Snapshots auch, aber ich weiß ja, wo deren XMLs stehen, nämlich

• in /var/lib/libvirt/qemu/snapshot

Jetzt ist mir nur immer noch unklar (allerdings nur aus Neugier wichtig)

• was passiert mit der QCOW2, wenn ich die XML des Snapshots versehentlich nicht sichere? (wird dann nur die Basis-Disk "gesehen"?)

• wie weiß der virt-manager überhaupt, welche Snapshots existieren? (vielleicht auf Basis des Verzeichnisnamens?)

Ob man das irgendwo nachlesen kann?

Nach einem Neustart des Virt-Manager konnte ich die DebianServer-VM dann starten. Es waren keinerlei Änderungen oder Anpassungen nötig.

Das setzt aber voraus, dass Du die virtuellen NICs auch gleich benannt hast?

Das habe ich aus der Zeit mit VirtualBox anders, eben deutlich komplizierter in Erinnerung.

Ich arbeite seit vier oder fünf Jahren mit Virtualbox und habe das bisher als recht einfach empfunden: Ich musste zum Restore lediglich das ganze Verzeichnis kopieren, dann mit vboxmanage registervm <name> die VM registrieren, dann allerdings noch die Namen der NICs anpassen, das war dann aber schon alles. Letzteres ist bei KVM wohl einfacher, weil ich ja frei bin in der Benennung der NICs (ich nutze Bridgeinterfaces). Dafür ist es bei Virtualbox egal, wie die Pfade aussehen, weil eben alles zu einer VM Gehörende in einem Verzeichnis ist.

Das setzt aber voraus, dass Du die virtuellen NICs auch gleich benannt hast?

Der für die VM relevante Teil steht in der .xml und sieht z.B. so aus:

    <interface type='network'>
      <mac address='52:54:00:f1:77:23'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

Wird also mit der .xml auf den neuen Host transferiert. Bezieht die VM die die ip-Adresse per DHCP ist damit alles geregelt.

Wie gesagt, ich nutze Bridge-NICs, und meine Server haben feste IPs. Aber auch das ist bei KVM besser: Bei VBox heißen die Bridgeadapter so wie die NIC im Netplan. Bei KVM kann ich die benennen, z.B. brlan und brdmz. Das funktioniert ganz prima.

Emma2 schrieb:

Wie gesagt, ich nutze Bridge-NICs, und meine Server haben feste IPs.

Ist bei einer Bridge auch nicht anders. Aber die musst du ja eh vorher auf dem Host konfigurieren. Auf meinem dedizierten Server für KVM hab ich auch Bridges.

Feste IP's hat bei mir nur die pfsense in der VM auf dem Host und der Host selbst. Alle anderen Server (egal ob VM oder physikalisch) haben zwar auch feste IP's bekommt diese aber per DHCP von der pfsense zugewiesen. Eben anhand der MAC-Adresse (IPv4) bzw. Interface-ID (IPv6). Solange sich also die MAC-Adresse nicht ändert bleibt alles gleich, auch nach einem Umzug auf einen neuen Host, denn auch die Interface-ID basiert ja auf der MAC-Adresse.

Aus meiner Sicht vereinfacht das den Konfigurationsaufwand erheblich.

adelaar schrieb:

Emma2 schrieb:

Wie gesagt, ich nutze Bridge-NICs, und meine Server haben feste IPs.

Ist bei einer Bridge auch nicht anders. Aber die musst du ja eh vorher auf dem Host konfigurieren. Auf meinem dedizierten Server für KVM hab ich auch Bridges.

Ja, das stimmt, und bei KVM ist es eben einfacher als bei VBox: Bei LVM kann ich meinen Bridges Namen geben, die dann über alle Hosts hinweg gleich sind. Bei VBox heißt die Bridge immer so wie der physische Adapter, und das variiert von Host zu Host...

Feste IP's hat bei mir nur die pfsense in der VM auf dem Host und der Host selbst.

Ich habe übrigens gerade umgestellt von OPNsense als VM auf eine kleine Appliance - das macht mich frei von eventuell auftretenden Problemen auf dem Host.

Alle anderen Server (egal ob VM oder physikalisch) haben zwar auch feste IP's bekommt diese aber per DHCP von der pfsense zugewiesen.

Ja, das klingt sinnvoll, und ich habe das auch noch auf der Liste. Aber wie woanders gesagt, ist mein Netz nicht meine Haupttätigkeit...

Danke nochmal für alle Tipps!