„Virtualisierung“ ist ein großes Wort und viele schrecken davor zurück. Ich habe aber festgestellt, dass es nicht nur einfach um zu setzen ist, sondern auch vieles vereinfacht.

In diesem wiki Artikel beschreibe ich, wie ich vorgegangen bin um meinen realen Server zu virtualisieren: also von der Installation des Hosts (Virtualisierungsserver) bis zur Migration des echten Servers.

Ich bin der Meinung, dass eine der Hauptfragen bei Virtualisierung die Anbindung des Storage an die VMs ist. Dabei gibt es zwei unterschiedliche Ansätze, die ich hier aufzählen und gängige Meinungen dazu wiedergeben will. Ob diese Meinungen dazu stimmen, habe ich für mich noch nicht überprüft:

• Anbindung als Imagedatei
• Anbindung realer Devices

Die Anbindung als Imagedatei soll Performance kosten, hat aber den Vorteil, dass man snapshots und overlays machen kann. Will man das bei realen Devices, so muss das Dateisystem diese Funktionen mitbringen, was LVM und btrfs können. Ich habe bei diesem Server die Imagedatei genommen, weil ich keine Lust hatte mich mit LVM snapshots auseinander zu setzen.
Gerne wird aber auch LVM genommen, eben wegen der Flexibilität der Containergrößen und der snapshot-Möglichkeit fürs Backup (siehe weiter unten).

Wahrscheinlich ist es sowieso wichtiger, welchen „BUS“ für die Anbindung des Storage man verwendet (IDE,SCSI,USB,virtio). Hier habe ich virtio genommen (siehe unten).

Die größten Probleme machte die Netzwerkeinrichtung. Mit der /etc/network/interfaces die hier eingestellt ist,hat man aber eine Vorlage, die man einfach anpassen kann.

1. Installation von ubuntu-server 12.04
2. Überprüfen der Virtualisierungserweiterungen der CPU und Installation von kvm
3. Einrichten des Netzwerks (erstellen der Bridges)
4. Installation von virt-manager auf dem Adminrechner
5. Erstellen der virtuellen Maschine (vom Adminrechner aus)
6. Überlegungen zum Storage
7. Kopieren des realen Servers in die VM (vom Adminrechner aus)
8. ..

1. Herunterladen des ubuntu-server-1204.iso
2. installation von USB Stick/CD ROM

Schon bei der Installation des Servers muss man wissen, wie man das Storage handhaben will. Will man später LVM Volumes an die VMs durchreichen, dann wählt man am besten jetzt schon bei der Partitionierung:

• geführte Partitionierung - mit LVM
• LVM über die gesammte Platte
• Bei der Meldung „in der LVM zu partitionierender Speicher“ wählt man aber nur 20 GB als Platz für den Host. Der Rest soll ja im LVM frei bleiben für die VMs
• Bei der Installation wählt man in der Softwareauswahl nur „OpenSSH Server“ und „Virtual Machine host“

Der freie LVM Bereich kann sehr bequem im virt-manager den VMs zugewiesen werden. Beim Anlegen einer VM legt der Wizard automatisch LVM Volumes der ausgewählten Größe an.

Diesen Fortgang habe ich komplett hier her: https://help.ubuntu.com/community/KVM/Installation Dort liegt gegebenenfalls eine neuere Version. Derzeit steht dort noch keine Beschreibung für 12.04

1. virtualisierungserweiterungen im Prozessor? UND im BIOS aktiv?

egrep -c '(vmx|svm)' /proc/cpuinfo

Es wird die Anzahl der Kerne ausgegeben, die VT haben (0 also „Keiner“ = Rechner nicht Nutzbar oder VT im BIOS aktiviren).
Anmerkung: vmx steht für Intels VT-Lösung, svm für AMD-V

2. Kann das Betreibsystem kvm?

kvm-ok 

3. Überprüfen, ob 64 Bit Kernel geladen:

uname -m

4. den User, der bei der Installation angegeben wurde in die Gruppen nehmen

$ sudo adduser `id -un` kvm

$ sudo adduser `id -un` libvirtd

'id -un' gibt den momentan eingeloggten user aus. Man kann auch sudo adduser linadmin kvm eintippen, wenn linadmin der angelegte Nutzer ist.

oder direkt mit Namen des Nutzers:

$ sudo adduser linadmin kvm

$ sudo adduser linadmin libvirtd

Um mich später von einem Administrationsrecher anmelden zu können musste ich (uwe_wickie) mit

 $ sudo passwd 

ein root-Passwort erstellen.

Installation der benötigten Packete zum Erstellen einer Bridge

sudo apt-get install bridge-utils

Das Netzwerk „komplex“.
Siehe auch → KVM virtuelle Netzwerke
Ich stelle mal die /etc/network/interfaces hier ein und erläutere danach den Hintergrund:

  # This file describes the network interfaces available on your system
  # and how to activate them. For more information, see interfaces(5).
  # The loopback network interface
   auto lo
  iface lo inet loopback
#  auto eth0
  iface eth0 inet manual


  # Roter Switch
  auto br0
  iface br0 inet static
  address 10.0.0.122
  network 10.0.0.0
  netmask 255.0.0.0
  broadcast 10.0.0.255
  gateway 10.0.0.254
  dns-nameservers 10.0.0.254
  bridge_ports eth0
    bridge_fd 0
    bridge_maxwait 0

  # Gruener Switch
  auto br1
  iface br1 inet static
  address 10.16.1.2
  netmask 255.240.0.0
   bridge_ports eth1
   bridge_fd 0
   bridge_maxwait 0


   
  # Blauer Switch
  auto br2
  iface br2 inet manual
   bridge_ports eth2
   bridge_fd 0
   bridge_maxwait 0
   

Ich habe also drei „Bridges“ angelegt: br0 br1 und br2 Diese „Bridges“ stellen wir uns als virtuelle Switches vor: ich kann virtuelle Netzwerkkarten diesen Switches zuweisen und damit ein virtuelles Kabel ziehen.

Wichtig sind die: bridge ports ethx Einträge: diese binden eine reale Schnittstelle an den virtuellen Switch brx. Ich muss also vorher wissen, welche reale Netzwerkkarte an welchem Netz hängt um in der interfaces Datei richtig zu zuordnen.

Nach Einfügen der neuen Interfaces sollte der Server neu gebootet werden.

Anmerkung: es fällt auf, dass die realen eth Devices keine IP mehr haben, wenn man ifconfig aufruft. Das liegt daran, dass diese IP der zugeordnete Switch brx bekommt. Das muss so sein .. sonst funktioniert es halt nicht ..

Ein Aufruf von

 ifconfig 

liefert also nur eine IP für den grünen brx.

Nun installiert man auf seinem AdminPC den virt-manager aus den ubuntu Repos. Bei mir mußte ich danach noch das Paket libvirt-bin nachinstallieren. Es ist egal, wo der admin PC steht: meiner ist meist Zuhause .. oder wie jetzt gerade, mit mir unterwegs.

Bemerkung: Installiert man den virt-manager unter Ubuntu 10.04 erhält man eine ältere Version, die nicht zu den Screenshots passt und am Ende lässt sich der Brücken-Name nicht editieren.

Nun kann man im virt-manager erstmal die Verbindung zum kvmhost einrichten: → Datei → Verbindung hinzufügen
Hypervisor: QEMU/KVM, Häkchen bei „Mit entferntem Rechner verbinden“, Methode: ssh, Benutzername: root, Hostname: Name oder IP.
Verwendet man ausschließlich key-authentification am Server-Host, muss der Key beim aktuellen Benutzer im Verzeichnis .ssh liegen und die Serververbindung in ~/.ssh/config z.B. mit

Host server-host
     HostName server-host
     IdentityFile ~/.ssh/host_id
     User root

angegeben sein.
Damit erstellt man ein „Bookmark“ im virt-manager zum kvmhost

Klickt man dieses Bookmark doppelt, so wird zum Server verbunden und man kann Maschinen anlegen/starten/umbauen/ .. Evtl. ein Häkchen bei „Automatische Verbindung“, ansonsten muss man eben jedes Mal den Bookmark doppelclicken.

Für die Festplattenkonfiguration sollte man sich zunächst den nächsten Abschnitt 6. Überlegungen zum Storage zu Gemüte führen.
Will man in ein LVM auf dem Host installieren, muss man erst noch den Speicherort „LVM“ hinzufügen:
Rechtsclick auf die Verbindung → Einzelheiten → Speicher.
Standardmäßig ist nur /var/lib/libvirt/images eingerichtet, hier kann man schon mal die .iso's hinkopieren.
Dann: das grüne Plus links unten anclicken, Name: LVM, Typ: logical: LVM Volume Group → Weiter.
der Zielpfad (/dev/<vg-name>) steht shcon da. Kein Häkchen bei Pool erzeugen, weil er ja schon vorhanden ist → Abschließen.
Verwendet man LVM, funktioniert bei mir (zumindest bei SATA) nur raw, nicht qcow2.
Wählt man nun links LVM an, so kann man eventuelle Logical Volumes in der Volume-Group sehen (bei mir z.B. das des Host-Systems etc.)
Verbindungsinformationen schließen.

Falls man noch nicht mit dem kvmhost verbunden ist: Verbindung herstellen (Bookmark clicken).
Nach der Verbindung mit dem kvmhost kann man auf den Bildschirm mit dem gelben Stern oben drücken, um eine neue VM zu erstellen.
Zuerst muss man den IPCop / IPFire installieren, dann erst die linuxmuster.net.

Nun einige Screenshots:

Hier wählt man das iso aus. Leider findet man hier nur Dateien, die im voreingestellten „Pool“ liegen.
Nun kann man einen neuen Pool erstellen (s.o., wie LVM), der auf ein Verzeichnis auf dem Server zeigt, oder man gewöhnt sich an Dateien / CD-Images etc. für kvm immer in /var/lib/libvirt/images/ zu legen und die Rechte aus libvirt-qemu:kvm zu setzen.

Ich habe als Betriebssystem „Linux“ und als Version „Debian Lenny“ ausgewählt.

RAM und CPU-Anzahl eingeben → Weiter siehe Screenshot.
IPFire soll laut Handbuch mindestens 4GB haben → Abschließen und dann das angelegte Volume auswählen.

Installiert man den IPCop/IP-Fire, setzt man das Häkchen „Konfiguration bearbeiten vor der Installation“ und fügt nach dem Erstellen der VM in der dann auftauchenden Konfiguration noch zwei Netzwerkkarten für grün (br0) und die Verbindung zum blauen Netz (z.B. CoovaChilli) hinzu. Für letztere empfiehlt sich ein virtuelles Netzwerk, da man die physikalische Brücke br2 zur Verbindung zu den Access-Points braucht.

Es ist sinnvoll, zwei verschiedene Gerätemodelle auszuwählen, damit man sie im IPCop leicht auseinanderhalten kann.
Achtung: Der IPCop beherrscht NICHT die virtio-Geräte, IPFire jedoch schon.

Hard-Disk → Erweiterte Optionen → z.B. IDE und Raw.

Hat man die Installation abgebrochen, muss man hier noch die CD „einlegen“:
IDE-CDRom wählen und das Iso angeben.

Zu aller erst: Partitionierung des Servers.
Hier gibt es verschieden Varianten: Das Host-System kommt:
1) auf das Raid (alle HDDs bilden ein Raid-5), es benötigt aber eine Boot-Partition, die nicht im LVM ist. (Abb 1)
2) auf eine Partition, die nicht im Raid ist (nur Teile der Platten kommen ins Raid, Abb. 2)
3) Man erstellt 2 Raids aus den Platten, eins für den Host (Raid 1, Ubuntu), eins für den Rest s. Abb 3, (grau)
4) Man gönnt sich eine weitere (kleine, evtl. SSD) Platte fürs Ubunu (vgl. Abb.1 nur boot-Partiton ist gespart und Ubuntu-Server-Partition ist auf extra SSD).

Zu den Imagedateien: Wie oben steht, ist nicht nur das Dateiformat wichtig, sondern auch die Anbindung. Als Dateiformat der Imagedatei wählt man qcow2, da dieses zwar x GB groß angelegt wird, aber trotzdem erstmal nur so groß ist, wie die Dateien drin benötigen. Das ist ein Vorteil, aber auch ein Nachteil, weil das „wachsen“ Performance kostet.
Für den Server sind entweder vier separate Image-Dateien (root, swap, home, var) oder eine Image-Datei mit 4 Partitionen sinnvoll (man sollte nicht den linuxmuster.net-Server nochmals ein LVM im Image anlegen lassen), dann ist später das Backup mit lvm-snapshot einfacher.
Als BUS nimmt man virtio beim Server und IDE beim IPCop, weil der IPCop die virtio devices noch nicht kennt. IPFire kann virtio.
Vorsicht: Verwendet man virtio, so melden sich die Platten als vda, vdb,… (anstatt sda, sdb,…). Wenn man dann einen virtuellen Client installieren will, muss man die start.conf und /etc/fstab dementsprechend anpassen, sonst findet linbo die Festplatte natürlich nicht. Hier ist aus Kompatibilitätsgründen SATA sinnvoller.

zu LVM: will man LVM verwenden, so installiert man den Server und erstellt ebenfalls eine VolumeGroup. Das geht bei der Installation, oder danach mittels: <blockquote>mit fdisk der gewünschten Partition die ID 8e (LVM) geben </blockquote> <blockquote>pvcreate /dev/<Partition> /dev/<Partition2> # <Partition> und <Partition2> als Physical Volume initialisieren </blockquote> <blockquote>vgcreate <group> /dev/<Partition> /dev/<Partition2> # Erstellt Volume Group <group>, bestehend aus /dev/<Partition> und /dev/<Partition2></blockquote> <blockquote>lvcreate -L 2G -n <vol> <group> # Erzeugt ein 2 GB großes Logical Volume mit dem Namen <vol> in der Volume Group <group> </blockquote>

Dummerweise taucht /dev/<group> erst auf, wenn man eine lv in der Group angelegt hat: deswegen lege ich immer gleich mit die LV für meinen Gast an. Man muss das LVM dann noch dem kvm als Storagepool zuweisen. Das geht über „Einstellungen“ auf die IP (also den Host) im virt-manager.

Das ganze ist etwas verwirrend, da ein LV, das man einer VM zuweist, für diese keine Partition, sondern eine Festplatte ist: das VM System erstellt also Partitionen auf diesem LV. Deswegen kann man das LV nicht ohne weiteres vom Host aus mounten (für backups). Will man es mounten, da müsste man die VM anhalten und dann mittels <blockquote>kpartx -av /dev/vg_lml/<lv-der-vm></blockquote> das LV vorbereiten. kpartx vorher mittels <blockquote>aptitude install kpartx</blockquote> installieren. Dann kann man die Devices, die dann unter /dev/mapper/ neu erschienen sind (die Partitionen des LVs) normal mounten. Aushängen (nach umounten der Partitionen) geht mittels: <blockquote>kpartx -dv /dev/vg_lml/<lv-der-vm></blockquote>

zuerst legt man das LVM an, das den Platz für die paedML bereitstellen soll. Das geht mit lvcreate. Das PhysicalVolume hat man ja bei der Installation schon angelegt. Die VolumeGroup sollte auch schon angelegt sein. Ob das der Fall ist bekommt man heraus mittels: pvscan vgscan lvscan

Eine nicht gestartete vg kann man mittels vgchange -ay <vg_name> starten. lvdisplay kann auch Informationen liefern.

Ist alles angelegt, lädt man das LV mittels <blockquote>kpartx -av /dev/vg_lml/<lv-der-vm></blockquote>

Dann kann man das LV als normale Festplatte verwenden und Partitionieren/Formatieren: <blockquote>fdisk /dev/mapper/<name-der-lv></blockquote> und Formatieren. (Das gleiche Dateisystem wie beim Quellserver, andernfalls gibt es später Probleme bei Grub): <blockquote>mkfs.ext3 /dev/mapper/<name-der-lv>1</blockquote> (Man beachte die „1“!)

Anschließend noch mounten (mit der zuvor schon beachteten „1“) <blockquote>mount /dev/mapper/<name-der-lv>1 /media/<mountpoint des lv></blockquote> Danach kopiert man die alte Platte in die LV <blockquote>cp -a /media/<alte-platte>/* /media/<mountpoint des lv>/</blockquote>

Alternativ lässt sich der alte Server auch im laufenden Betrieb kopieren. Dazu muss der neue Server als Testumgebung (siehe unter 3: /etc/network/interfaces) ins grüne Netz. zuerst wechselt man in das Zielverzeichnis um anschließend mit ssh und einer Pipe zu kopieren. Das Ganze dauert natürlich ein bisschen.

<blockquote>cd /media/<mountpoint des lv>

ssh root@<alter Server> 'cd /; tar czvf - *' | tar xzf - </blockquote>

Am Ende noch folgende Dateien anpassen: <blockquote>/media/<mountpoint der LV>/etc/fstab</blockquote> <blockquote>/media/<mountpoint der LV>/boot/grub/menu.lst</blockquote> <blockquote>/media/<mountpoint der LV>/boot/grub/device.map</blockquote>

Jeweils aus sdax vdax machen. Falls beim ursprünglichen Server ein LVM eingerichtet war müssen zusätzlich die Zeilen mit /dev/mapper in der fstab gelöscht werden.

Am Ende wird mit einem ubuntu12.04 iso die VM gebootet und der grub installiert nach dieser Anleitung: http://wiki.ubuntuusers.de/grub

<blockquote>sudo mount /dev/vda1 /mnt</blockquote> <blockquote>sudo mount -o bind /dev /mnt/dev</blockquote> <blockquote>sudo mount -o bind /sys /mnt/sys</blockquote> <blockquote>sudo mount -t proc /proc /mnt/proc</blockquote> <blockquote>sudo chroot /mnt</blockquote> <blockquote>grub-install /dev/vda</blockquote> <blockquote>update-grub</blockquote>

Danach bootet die paedML wieder. Kommt eine Fehlermeldung bei grub-install, dass stage1 nicht gefunden wurde, dann hat man vielleicht ext4 und nicht ext3 beim Formatieren verwendet.

Da man ja die VM für das Backup eben nicht anhalten will, erstellt man einen LVM Snapshot (im laufenden Betrieb). Das Dateisystem in der VM muß das aber unterstützen. LVM snapshot sagt dem Dateisystem: bringe dich in einen konsistenten Zustand. Das macht das Dateisystem. Dann wird der snapshot erstellt in ein neues LV. Die Größe des backupLVs ist wählbar und hat nur sekundär mit der Größe des zu backupenden LVs zu tun. Der Grund: die Hardlinks sind sehr klein und verbrauchen so gut wie keinen Platz. Wird im original LV eine Datei geändert während das Snapshot existiert, so wandert die alte Version auf die snapshot LV und die neue bleibt im Original. Wenn ich also nach 3 Tagen das backupLV lösche, so verliere ich nur alte Versionen von Dateien, keine neuen. Außerdem ist die LV, die ich zerstöre, nur so groß, wie die Summe der Größen aller Dateien, die sich seit Erstellung des Snapshots geändert haben. Deswegen reichen für ein Backup meines 500 GB Servers ein Snapshot mit 20GB locker aus.

Im Einzeiler geht das so:

1. Snapshot Erstellen

   lvcreate -s /dev/vg_lml/vg_lml-server -L 20G -n backup-lv-server

Diese Zeile erstellt eine LV mit Namen backup-lv-server. Die Größe ist 20GB Erklärung: Im backup-lv-server ist der snapshot: er belegt erstmal keinerlei Platz, da er nur Hardlinks auf die Originaldateien im original LV hat. Wird, nach Erstellung, eine Datei im Original verändert, so wird die alte Datei ins backup-lv geschoben, und ersetzt den Hardlink. So wächst das LV-backup.

Sinn der Sache ist, dass man nun vom erstellten BackupLV eine Sicherung per rsnapshot oder rsync auf eine andere Festplatte macht. Beim erstenmal werden alle Dateien rüberkopiert. Das muss man beachten! Hier wird die Anbindung wirklich relevant. Eine 100MBit/s Leitung kopiert normalerweise um die 10MByte/s (eigentlich 12,5, aber dieser theoretische Wert wird nicht erreicht). Für meine 460GB benötige ich also erstmal ca. 14 Stunden! Ist nicht so schlimm, weil die VMs ja weiter laufen, als wäre nichts, man sollte es aber bedenken.

Wie geht es im einzelnen:

• BackupLV Snapshot erstellen:

  lvcreate -s /dev/vg_lml/vg_lml-server -L 20G -n backup-lv-server

• BackupLV mit kpartx aufschließen:

  kpartx -av /dev/vg_lml/backup-lv-server

• BackupLV mounten:

  mount /dev/mapper/backup-lv-server1 /media/backup

• BackupLVmount mit rsync auf NAS syncen (durch SSH Tunnel):

  rsync -aP /media/backup admin@nasIP:/share/HDA_DATA/Backup

• BackupLVmount mit rsync auf NAS syncen (direkt auf den rsyncserver des NAS):

  rsync -aP --password-file=<Datei mit Passwort> /media/backup admin@nasIP::Backup 

Anmerkung zum NAS: Die Informationen dazu habe ich hier her: wiki-nas-portal.org. Es gibt zwei Möglichkeiten: durch SSH (verschlüsselt und deswegen langsamer) oder direkt auf den rsync Server des NAS (haben meine QNAPs). Auf dem rsync Server muss das Ziel-Verzeichnis angelegt werden.

# mkdir /share/HDA_DATA/Backup
# chmod 755 /share/HDA_DATA/Backup

Danach muss das virtuelle Verzeichnis „Backup“ in der Datei /etc/rsync.conf definiert werden.

uid = admin
gid = administrators
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
read only = false
hosts allow = *
port = 873

[Qmultimedia]
path = /share/HDA_DATA/Qmultimedia
.......

[Backup]
path = /share/HDA_DATA/Backup

Nach getaner Arbeit muss das BackupLV ungemountet, eingepackt und gelöscht werden:

umount /media/backup
kpartx -dv /dev/vg_lml/backup-lv-server
lvremove /dev/vg_lml/backup-lv-server

Bei mir sieht ein mögliches Script so aus. ++++ Zum Aufklappen des Skripts bitte hier klicken | Achtung:

• Ich habe EIN logical Volume an die linuxmuster.net vergeben und darin 4 Partitionen erstellt (root, swap, home, var). Man hätte auch 4 LVMs weiterreichen können, dann sieht das Script anders aus.
• Ich sichere auf eine an den Host angestöpselte USB-HDD in einem praktischen Wechselständer.
• Pfade zur Backup-Platte und den „aufgeschlossenen“ LVMs müssen angepasst werden

#Auf linuxmuster-Server: (Platz sparen)
#find /home/teachers -type d -iname "FirefoxProfil" -exec rm -r "{}" ";"
#find /home/students -type d -iname "FirefoxProfil" -exec rm -r "{}" ";"
#find /home/teachers -type d -iname "LibreOffice" -exec rm -r "{}" ";"
#find /home/students -type d -iname "LibreOffice" -exec rm -r "{}" ";"
#find /home -type d -iname ".Trash-*" -exec rm -r "{}" ";" 2>&1 >> /media/sdg/backup/backup.log
 
#Auf Host dieses Script starten (mit SCREEN, s.u.): 
mount /dev/sdg1 /media/sdg
#Eventuell vorhandenes Backup umbenennen
mkdir /media/sdg/backup
 
####################################
#mit screen -R backup arbeiten !!! #
####################################
 
echo "===== Backup der linuxmuster.net =====" >> /media/sdg/backup/backup.log
date >> /media/sdg/backup/backup.log
 
echo "== lvmcreate, kpartx ==" >> /media/sdg/backup/backup.log
lvcreate  --size 20G --snapshot --name backupsnap /dev/SVR-host/linuxmuster.net 2>&1 >> /media/sdg/backup/backup.log
kpartx -av /dev/SVR-host/backupsnap 2>&1 >> /media/sdg/backup/backup.log
 
echo "== mount backupsnap1 ==" >> /media/sdg/backup/backup.log
mount /dev/mapper/SVR--host-backupsnap1 /media/backupsnap/ 2>&1 >> /media/sdg/backup/backup.log
echo "== rsync der Root-Partition ==" >> /media/sdg/backup/backup.log
rsync -aPq /media/backupsnap/ /media/sdg/backup/root/ 2>&1 >> /media/sdg/backup/backup.log
umount /media/backupsnap/ 2>&1 >> /media/sdg/backup/backup.log
 
#backupsnap 2 ist bei mir swap !!!
 
echo "== mount backupsnap3 ==" >> /media/sdg/backup/backup.log
mount /dev/mapper/SVR--host-backupsnap3 /media/backupsnap/ 2>&1 >> /media/sdg/backup/backup.log
rsync -aPq /media/backupsnap/ /media/sdg/backup/var/ 2>&1 >> /media/sdg/backup/backup.log
umount /media/backupsnap 2>&1 >> /media/sdg/backup/backup.log
 
echo "== mount backupsnap4 ==" >> /media/sdg/backup/backup.log
mount /dev/mapper/SVR--host-backupsnap4 /media/backupsnap/ 2>&1 >> /media/sdg/backup/backup.log
rsync -aPq /media/backupsnap/ /media/sdg/backup/home/ 2>&1 >> /media/sdg/backup/backup.log
umount /media/backupsnap 2>&1 >> /media/sdg/backup/backup.log
 
echo "== kpartx weg, lvremove ==" >> /media/sdg/backup/backup.log
kpartx -dv /dev/SVR-host/backupsnap 2>&1 >> /media/sdg/backup/backup.log
lvremove -f /dev/SVR-host/backupsnap 2>&1 >> /media/sdg/backup/backup.log
 
echo "##### Backup End ##### " >> /media/sdg/backup/backup.log

++++

++++ Zum Aufklappen eines weiteren Skript-Beispiels, bitte hier klicken |

• Annahme: Die zu sichernden KVM-Clients heißen „server“, „ipfire“ und „chapman“
• Weitere Annahme: Alle LVMs haben nur eine Partition „/dev/sda1“ auf der alles „/“ sitzt, andernfalls muss man eben „so tun“ als ob man weitere Server hätte.
• Die entsprechenden Verzeichnisse /srv/ipfire müssen erstellt werden.
• Man installiert rsnapshot auf dem Host und konfiguriert es so: (Achtung, TABs als Zwischenräume, Verzeichnisse immer mit / enden lassen)

# Ziel auf dem NAS/NFS/USB-Festplatte:
snapshot_root     /srv/backup/rsnapshot/
no_create_root    1
retain    daily   61
retain    monthly 12
link_dest 1
 
backup    /srv/ipfire  ipfire/
backup    /srv/chapman chapman/
backup    /srv/server  server/

• Ein Skript, dass jetzt alles nach /srv/backup/rsnapshot/ sichert, falls es keine leeren Verzeichnisse gibt, wäre:

backup_only_kvmclients.sh

#!/bin/bash
 
function prep {
kvmclient=$1
partition=$2
lvcreate -s /dev/vgserver/${kvmclient} -L 200M  -n ${kvmclient}-backup
kpartx -a /dev/vgserver/${kvmclient}-backup
mount /dev/mapper/vgserver-${kvmclient}--backup${partition} /srv/${kvmclient}
}
 
function pop {
kvmclient=$1
umount /srv/${kvmclient}
kpartx -d /dev/vgserver/${kvmclient}-backup 
lvremove -f /dev/vgserver/${kvmclient}-backup
}
 
function check {
c=0
for i in "$@" ; do
    if [ -z "$(ls -A /srv/$i 2>/dev/null)" ]; then
        c=1
        echo WARNING: Abbruch, weil /srv/$i leer erscheint
    fi 
done
[ $c -eq 1 ] && return 1 || return 0
}
 
 
prep ipfire 1
prep chapman 1
prep server 1
 
# check for empty dirs
check ipfire chapman server
# backup using rsnapshot
if [ $? -eq 0 ]; then
    rsnapshot daily
fi
 
# normalzustand herstellen
pop server
pop chapman
pop ipfire

++++

• Wer auf dem KVM-Host eine Partition /pfad1 übrig hat, die für ein Vollbackup reicht, der kann

1. Eine extra Partition pfad1 dem Client durchreichen.
2. Vom Host aus via ssh (mit ssh-key) auf dem Client, d.h. dem linuxmuster.net-Server den Befehl linuxmuster-migration-backup -d /extrapartition absetzen.
3. Oder linuxmuster-migration-backup zeitlich früher ausführen..
4. Von der extra Partition pfad1 einen LVM-snapshot machen und wie im vorhergehenden Skript mit rsnapshot wegsichern.

Manchmal ist es nötig oder praktisch, die VMs „von außen“ herunter zu fahren. Das kann man tun, indem man den VMs vom Host aus ACPI Befehle schickt: in unserem Fall der APCI Event: „Powerbutton pressed“

Zuerst läßt man sich die VMs anzeigen:

<blockquote>virsh list</blockquote>

Sollte zu etwas wie folgendem führen: <blockquote> Id Name State

1 centos.nixcraft.in   running
2 freebsd              running 

</blockquote>

nun kann man mittels: <blockquote> virsh shutdown 2 </blockquote> Die zweite Maschine herunterfahren.

Quelle: http://www.cyberciti.biz/faq/linux-kvm-stop-start-guest-virtual-machine/

sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

sudo adduser $linadmin libvirtd sudo usermod -G libvirtd -a linadmin sudo apt-get install libcap2-bin sudo setcap cap_net_admin=ei /usr/bin/qemu-system-x86_64

storage: ich nehme virtio angebundene qcow2 Container. IDE angebundene qcow2 Container sind sehr lahm. Außerdem weise ich beim erschaffen des Containers die größe auch gleich voll zu. Deswegen belegen die auch nicht mehr auf der Platte.

www.linux-kvm.org/page/Networking

http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Netzwerkoptionen/_Virtuelle_Netzwerke_konfigurieren