Schlagwort: kvm

Hetzner EQ-Server + KVM && bridge

prego 26 Kommentare

Vorneweg: Es ist ein Krampf bis ich es rausgefunden hatte…

Eine Bridge einrichten, dafuer:

aptitude install bridge-utils

und anschliessend die /etc/network/interfaces entsprechend anpassen:

### Hetzner Online AG - installimage
# Loopback device:
auto lo
iface lo inet loopback
 
# device: eth0
auto  eth0
iface eth0 inet manual
 
# bridge: br0
auto br0
iface br0 inet static
	address		188.XX.XX.142
	broadcast	188.XX.XX.191
	netmask		255.255.255.192
	gateway		188.XX.XX.129
 
	bridge_ports	eth0
	bridge_stp	on
	bridge_maxwait	5
 
	up		route add -host 188.XX.XX.160 gw 188.XX.XX.160
	up		route add -host 188.XX.XX.161 gw 188.XX.XX.161
	up		route add -host 188.XX.XX.162 gw 188.XX.XX.162

Dabei darauf auf die klassischen Fehler achten:

  1. echo 1 >> /proc/sys/net/ipv4/ip_forward
  2. iptables -P FORWARD ACCEPT

Wichtig war bei mir unter Ubuntu Linux auch noch in der /etc/sysctl.conf den folgenden Wert einzukommentieren:

 net.ipv4.ip_forward=1

Bei der Konfiguration der virtuellen Maschinen dann das Netzwerk ueber die bridge (br0) konfigurieren. Nachtraeglich kann man das sonst auch noch in der entsprechenden /etc/libvirt/quemu/MASCHINENNAME.xml anpassen:

    <interface type='bridge'>
      <mac address='54:52:00:3f:35:9d'/>
      <source bridge='br0'/>
    </interface>

In der Maschine selber ist es dann nur noch wichtig, die IP des Hauptsystems als Gateway einzutragen, ein Beispiel fuer die /etc/network/interfaces eines Gastes waere:

auto lo
iface lo inet loopback
 
# The primary network interface
auto eth0
iface eth0 inet static
	address		188.XX.XX.162
	broadcast	188.XX.XX.191
	netmask		255.255.255.192
	gateway		188.XX.XX.142

Die Informationen hier habe ich aus dem Blogeintrag: „Hetzner: EQ-Serie mit zusaetzlichen IP-Adressen (HowTo)“ und den bridge-krams aus meinem Kopf…

[Update]

  • 2010-10-18: stp=on und sysctl Absatz hinzugefuegt

Skript: Netzwerkinterface neustarten

prego Ein Kommentar

Ich hatte eine Debian etch Maschine, virtualisiert mit KVM, bei der brach unter Last immer die Netzwerkverbindung zusammen. Reproduzierbar. Das Update auf Lenny brachte nix. Ich habe die Maschine gestern mit Lenny neu aufgesetzt und die Probleme existieren nicht mehr. Hier nun das Skript was ueberprueft ob eine Verbindung nach aussen moeglich ist und ggfs. das Interface neustartet, ich brauche es nicht mehr, aber bevor ich es loesche hier noch einmal dokumentiert:

#!/bin/bash
##
#  check if network is available and if not restart
#  the network interface
##
 
if ping -c 1 -w 1 -q www.google.de &>/dev/null; then
#  echo "Network is up, no further action required"
  echo ""&>/dev/null
else
  echo "Network is down, restarting the interface..."
  ifdown eth0 && ifup eth0
 fi

Zum festhalten: parted, LVM, virsh

prego 4 Kommentare

Um Partitionen groesser als 2TB zu erstellen muss man GPT labels benutzen. fdisk und Konsorten koennen damit nicht umgehen, deswegen nimmt man dafuer parted. Mit den folgenden Befehlen stellt man den Partitionstabellentyp auf gpt um, und erstellt eine Partition ueber die komplette Platte und formatiert diese mit xfs:

  • parted /dev/sdX -> mklabel gpt -> quit
  • parted -s — /dev/sdX mkpart primary 0 -1
  • mkfs.xfs /dev/sdX

Noch kurz die grundlegenden wichtigsten Befehle zum erstellen eines LVM:

  • /dev/sdX als physikalisches Volume initialisieren: pvcreate /dev/sdX
  • erstellen eine Volume Group mit dem Namen VG-NAME: vgcreate VG-NAME /dev/sdX
  • Ansehen kann man sich das dann mit vgscan oder vgs
  • Erstellen eines neuen Volumes mit dem Namen VOLNAME: lvcreate -n VOLNAME –size 10GB VG-NAME
  • Formatieren, mounten, angucken:
    mkfs.ext3 /dev/VG-NAME/VOLNAME
    mkdir /mnt/VOLNAME
    mount /dev/VG-NAME/VOLNAME /mnt/VOLNAME
  • Anzeigen von Logischen Volumes: lvdisplay
  • Vergroessern/Verkleinern eines Volumes:
    lvextend -L+10G /dev/VG-NAME/VOLNAME
    lvreduce -L-10GB /dev/VG-NAME/VOLNAME
    e2fsck -f /dev/VG-NAME/VOLNAME
    resize2fs /dev/VG-NAME/VOLNAME
  • Loeschen von Volumes: lvremove /dev/VG-NAME/VOLNAME

Abschliessend sei noch gesagt, dass virsh echt cool ist. Dabei ist eben festzuhalten, dass das Speichern u Wiederherstellen aller vms (z.B. vor oder nach einem reboot) einfach geht z.B. mit:

  • for i in `virsh list | grep running | awk {‚print $2‘}` ; do virsh save $i /vms/$i ; done
  • for i in `ls /vms` ; do virsh restore /vms/$i ; done

Wenn man mit virsh console VM auf eine Maschine moechte, duerfen dafuer auf dem Gast in der /etc/inittab die Zeilen mit T0 und T1 nicht auskommentiert sein.

Die Infos hier sind von da und da und dem.

Migration virtueller Maschinen von XEN zu KVM

prego Ein Kommentar

Die Migration virtueller Maschinen von XEN zu KVM ist einfacher als ich es zuerst befuerchtet hatte. Das Hauptarbeit liegt darin die *.img Dateien umzuwandeln. Waehrend XEN fuer jede Partition eine Imagedatei anlegt (z.B. disk.img, swap.img etc.) speichert KVM die komplette Maschine in einem Image.  Weiter hat jede Maschine in KVM seinen eigenen kompletten Kernel. Die Aufgaben sind kurz zusammengefasst:

  • Installation von grub und Kernel in der XEN-Maschine
  • Erstellen einer neuen KVM Imagedatei
  • Partitionierung der KVM Imagedatei, kopieren der XEN Imagedatei(en)  in die neue KVM Imagedatei
  • Installation von grub in der KVM Imagedatei
  • Anlegen einer neuen Maschine in KVM und einbinden der frisch erstellten KVM Imagedatei in die neue Maschine

Diese Schritte sind alle beschrieben in dem Blogpost XEN to KVM Migration auf SirPing’s blog. Ich habe die Migration von 4 Maschinen erfolgreich nach der Anleitung durchgefuehrt. Da der Blog zur Zeit nur aus einem einzigen Post besteht, und dieser auch inzwischen ein knappes Jahr alt ist ist, habe ich zur Sicherheit den Beitrag hier nochmal als PDF angehaengt.