Hallo Holger,
Am 16.11.2014 um 23:51 schrieb Holger Baumhof:
Hallo Stefan,
sudo du -h /var/lib/libvirt/
4,0K /var/lib/libvirt/qemu/snapshot
4,0K /var/lib/libvirt/qemu/save
4,0K /var/lib/libvirt/qemu/dump
16K /var/lib/libvirt/qemu
4,0K /var/lib/libvirt/boot
20K /var/lib/libvirt/network
20G /var/lib/libvirt/images
4,0K /var/lib/libvirt/dnsmasq
4,0K /var/lib/libvirt/sanlock
20G /var/lib/libvirt/
Mein KVM Host Ubuntu belegt also insgesammt 23GB von denen 20 GB in
/var/lib/libvirt/images/ lieben, also virtuelle Containerfestplatten sind.
Selbst die benötige ich garnicht mehr: 73 GB sind weit mehr als genug.
Benutzt du nun eigentlich .qcow2 Images für deine VM-Clients oder
benutzt du das LVM des Hosts. Ihr habt in der Mail von beidem
gesprochen, das verwirrt mich :)
Ich denke nämlich nach, ob ich besser qcow2 Images oder lieber
LVM-volumes als grundlage für die virtuellen Rechner nehmen soll und
komme zum Schluss, dass LVM für mich und mein Backupsystem (mit rsync)
besser passt.
Grüße, Tobias
P.S.
(hier meine gedanken zum Backup:
Aktuell:
* Backup funktioniert momentan nur mit LVM-Containern, daher
Livebackup durch: LVM-snapshot + kpartx + mount + rsync.
* Nachteile bei LVMsnapshot: eigentlich müsste man die datenbanken
runterfahren (keine downtime, aber auch kein Live-backup) oder host
runterfahren (downtime, kein Live-backup)
* Lösungen:
* ssh-key in den vm-client vom vm-host, runterfahren wichtiger
dienste vor dem snapshot. hochfahren danach. (minimale Downtime)
* virsh shutdown <vm-client>, dann snapshot
Alternative:
* Backup könnte auch über KVM-qcow2 container gehen: kein
Livebackup, dafür snapshots alle in einer Datei, Vorteile: tragbar,
nachteile: große Backup-dateien…, rsync der Datei macht keinen Sinn,
allerdings gibt möglichkeiten qcow2 container-dateien aufzuschließen.
_______________________________________________
linuxmuster-user mailing list
[email protected]
https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
