TauCeti.NET
The lost star colony...

KVM, Qemu: Welche I/O-Scheduler verwenden

Update 20110831: Weitere Informationen zu dem Thema gab es auf dem KVM Forum 2011 in dem PDF Optimizing Your KVM Instances von Mark Wagner. Auch hier zeigt sich, das der Deadline Scheduler aktuell der Optimalste für eine KVM ist.

Update 20100318: Mehr Tuning-Informationen für die KVM gibt es hier: http://www.linux-kvm.org/page/Tuning_KVM .

Update 20090403: Ich denke, das sich das unten stehende, so nicht halten läßt. Die Sache mit dem noop-Scheduler verhält sich teilweise sehr gut, teilweise aber auch ziemlich übel, in dem z.B. der pgflush-Daemon ziemlich viel Systemzeit beansprucht und der I/O-Durchsatz ziemlich in die Knie geht. Das ändert sich schlagartig, sobald man auf den Deadline-Scheduler umschaltet. Auf den getesteten Systemen scheint die Benutzung des Deadline-Schedulers in Host und Guest die beste Kombination zu sein. Man kann das ja selber mal ausprobieren, in dem man den I/O-Scheduler im laufenden Betrieb wechselt z.B.

echo "deadline" > /sys/block/vda/queue/scheduler

Man sollte dann aber schon eine Anwendung oder einen Test fahren, der gut was auf die Platte schreibt und das auch möglichst konstant macht. Oder besser: Man verwendet bonnie++ . Ein eher syntetischer Test für I/O-Durchsatz aber ein guter Ausgangspunkt.

Text vom 20090330: Diese gar nicht so uninteressante Frage kam jetzt schon des Öfteren auf der KVM Mailingliste hoch. Letztendlich ist man sich einig, das das Gastsystem mit elevator=noop gestartet werden sollte. Per Default setzen ja heute die meisten Distributionen den Completely Fair Scheduler-I/O (CFQ) ein. Für den Host selbst ist das vielleicht ok, wenn im Gast elevator=noop als Kernelparameter z.B. im Grub übergibt. Es macht auch nicht wirklich Sinn, wenn sich die I/O-Scheduler im Gast und im Host Gedanken machen müssen, wie denn die Daten am Besten auf die Platte kommen sollen. Wenn ich die Mails der KVM-Entwickler/-User aber richtig interpretiere, dann bevorzugen sie doch eher den deadline Scheduler für den Host. Mit dem habe ich auch sehr gute Erfahrungen gemacht im Serverbereich. Ich finde - aber das ist jetzt meine subjektive Meinung - das der CFQ sich besser für den Desktopbereich eignet als für Serveranwendungen.

Erstellt am 08:00PM Mrz 30, 2009 in Tipps  |  Permalink Kommentare[0]
Tags: linux kvm qemu scheduler

KVM/Qemu: Wie konvertiert man eine VMware VMDK Datei zu einem KVM Image

Die Lösung ist relativ einfach. Entweder verwendet man qemu-img oder kvm-img (je nachdem welches Tool der Distribution beiliegt):

qemu-img convert -f vmdk -O qcow2 vmware-image.vmdk kvm-image.qcow2

Update 20090511: Das funktioniert aber nur solange man nur ein vmdk-File hat. Wenn das VMWare-Image auf mehrere Dateien aufgesplittet ist wie s001.vmdk, s002.vmdk, usw., dann muss man anders vorgehen. Man konvertiert alle diese Dateien ins RAW-Format und kopiert diese dann zusammen in ein File:

for I in *[0-9].vmdk; do kvm-img convert -f vmdk "$I" -O raw "tempdir/$I"; done
cat *.vmdk >> final_image.raw

Das final_image.raw kann man dann mit der KVM starten.

Erstellt am 07:44AM Mrz 11, 2009 in Tipps  |  Permalink Kommentare[0]
Tags: vmware kvm virtualization qemu

KVM, Qemu und XFS Filesystem

So sehr ich ja XFS als Filesystem schätze, muss ich doch ziemlich davon abraten, es in einer KVM (Kernel Virtual Maschine) zu verwenden. Normalerweise richte ich das Root-FS (also /) immer als ext3-Filesystem ein und /boot als ext2. /var, /tmp, /usr, /opt, /home, usw. immer als XFS. Das war all die Jahre auch eine gute und einwandfrei funktionierende Kombination. Falls was ist, kann man mit den Standardtools Root-FS und /boot eventl. reparieren. Solange / und /boot noch tun, hat man ja ohnehin alle Tools drauf, um eventl. die XFS-Partitionen zu reparieren. Den Bedarf hatte ich aber noch nie - bis auf 3 mal in den letzten Monaten in Zusammenhang mit einer KVM.

Da XFS ja ziemlich aggressives Write-Caching betreibt, ist die allgemeine Empfehlung XFS hauptsächlich dann zu verwenden, wenn man eine USV vor dem Rechner hat oder einen Contoller, dessen Cache und Festplatte mit einer Batterie gegen plötzlichen Stromausfall gesichert ist.

So betrachtet, gelten beide Bedingungen nicht für die KVM. Ich kann die KVM ja jeder Zeit mit einem kill vom Host aus abschießen. Oder eine Kernel-Panic des Hosts würde auch die KVM killen. Das ist dann, als ob ich den Stecker für die KVM ziehen würde. Obwohl ich damit auf einem physikalischen Rechner noch nie Probleme hatte, scheint das in einer KVM gravierendere Auswirkungen zu haben. Das Ganze gilt insbesondere dann, wenn man das Virtio Block Device (VIRTIO_BLK) verwendet (das ist der Virtio Plattentreiber, der nicht emuliert werden muss, sondern soz. näher am Host-IO-Treiber sitzt und dadurch schneller arbeiten kann - fällt u.a. dadurch auf, das man ein /dev/vda Device hat).

Ich kann aufgrund meiner Erfahrungen aktuell nur empfehlen, ext3 in einer KVM zu verwenden. Die Probleme mit XFS traten dann und wann auf, wenn die KVM (aus welchen Gründen auch immer), unerwarteter Weise beendet wurde. I.d.R. konnte man das Filesystem wieder herstellen, aber mir hat es auch schon Zwei komplett zerlegt. Mit ext3 ist mir das noch auf keinem KVM-System passiert. Komisch... Normalerweise kenne ich das immer umgekehrt ;-)

Ich vermute mal, das einer der Gründe für die Probleme die fehlende Unterstützung in VIRT_BLK für Barriers ist. Das sieht dann mit dmesg z.B. so aus:

Filesystem "vda7": Disabling barriers, trial barrier write failed
XFS mounting filesystem vda7

Wenn ich die Sache mit den Barriers richtig verstanden habe, dann sind die dafür zuständig, das das Filesystem das darunterliegende Device informieren kann, wenn es Daten flushen, d.h. also wegschreiben soll. Wenn das nicht passiert und die Kiste säuft ab, dann kann das ziemliche Folgen für das Filesystem haben. Oft wird empfohlen, bei XFS die Option nobarrier zu setzen, um die Performance zu steigern. Das sollte man sich aber genau überlegen...

Update 20090206:

Zu dem Thema u.a. qcow2 vs. raw Format für KVM Images siehe auch hier:
Poor Write I/O Performance on KVM-79
Use writeback caching by default with qcow2
Re: Use writeback caching by default with qcow2
XFS FAQ

Interessant finde ich auch die Möglichkeit, LVM direkt als Laufwerk für eine KVM zu nutzen, wie in einem der Postings erwähnt wird (-drive file=/dev/vg/volume). War mir noch gar nicht bekannt...

Update 20090329:

Die XFS FAQ empfiehlt bei Qemu/KVM bei der -drive Option cache=none anzugeben, da hier anscheinend nicht mal auf einen fsync Verlass ist. Ich werde trotzdem bei ext3 als Filesystem in einer KVM bleiben.

Erstellt am 08:41PM Feb 04, 2009 in Tipps  |  Permalink Kommentare[0]
Tags: kvm virtualization xfs qemu corrupt

Qemu, KVM, Anaconda - lvm: Cannot allocate memory

Nachdem ich gerade am Testen von Red Hat Enterprise 5 mit Qemu/KVM bin und mir Anaconda beim Initialisieren der Festplattenpartitionen die Meldung

lvm: Cannot allocate memory

um die Ohren gehauen hat, wollte ich die Welt teilhaben lassen an der Lösung ;-) Ich hatte Qemu gestartet mit

/opt/kvm/current/bin/qemu-system-x86_64 -hda rhel52.img -cdrom /opt/cds/rhel-5-server-x86_64-dvd.iso -boot d -m 256

Der Witz ist, 256 MB Speicher reichen nicht! Es müssen mindestens 512 MB sein. Ich hab's dann probiert mit

/opt/kvm/current/bin/qemu-system-x86_64 -hda rhel52.img -cdrom /opt/cds/rhel-5-server-x86_64-dvd.iso -boot d -m 640

und das funktioniert dann.

Erstellt am 02:59PM Aug 01, 2008 in Tipps  |  Permalink Kommentare[0]
Tags: kvm lvm anaconda redhat virtualization linux qemu

QEMU: Netzwerkanbindung

Nachdem ich kürzlich beschrieben habe, wie man Qemu mit Hardwarevirtualisierung unter Gentoo zum Laufen bringt, geht's dieses Mal um die Netzwerkanbindung von Qemu. Grundsätzlich ist das für eine Qemu-Instanz kein Problem. Man startet die VM einfach mit der Option -net nic -net user (was aber sowieso Default ist). Der Nachteil an der ganzen Sache hier ist allerdings, das nur TCP/IP-Verbindungen funktionieren. Ein ping z.B. funktioniert nicht. Wenn man allerdings eine vollständige Netzanbindung haben möchte, muss man etwas mehr tun. Grundsätzlich gibt es mehrere Möglichkeiten. Ich beschreibe hier die Möglichkeit über TAP und VDE (Virtual Distributed Ethernet). Diese erscheint mir recht sinnvoll und relativ schnell einzurichten. VDE stellt eine Art virtuellen Switch zur Verfügung, an dem mal einfach eine oder mehrere virtuelle Maschinen an

Zunächst brauchen wir TUN/TAP-Unterstützung im Kernel. Ich schätze, das dürfte so ziemlich jeder schon haben. Wenn man's nicht im Kernel einkompiliert hat (dann weiss man sicherlich, das man das gemacht hat ;-) ), kann man einfach mal

modprobe tun

eingeben. Wenn keine Fehlermeldung kommt, ist das Modul geladen (prüfen mit lsmod). Wenn das nicht klappt, muss man in die Kernelsources guggen und das TUN/TAP-Modul aktivieren. Dazu wechselt man nach /usr/src/linux und tippt make menuconfig ein. Unter

Device Drivers -> Network device support

aktiviert man Universal TUN/TAP device driver support als Kernelmodul. Als nächstes installieren wir VDE:

emerge -av vde

Dann erzeugen wir uns ein TAP-Device:

cd /etc/init.d/
ln -s net.lo net.tap0

Unter /etc/conf.d/net fügen wir Folgendes ein (eventl. passt man noch die IP-Adresse an):

config_tap0=( "10.0.2.1 netmask 255.255.255.0 " )

Um das Interface zu starten, gibt man Folgendes ein:

/etc/init.d/vde start
/etc/init.d/net.tap0 start

Damit VDE beim Start des Rechners automatisch startet, aktivieren wir das Start-Skript entsprechend:

rc-update add vde default

Mit ifconfig müsste man jetzt das tap0 Device sehen. Nun können wir die verschiedenen Qemu-Instanzen starten. Wichtig ist, das man jeder Qemu-VM eine eigene MAC-Adresse zuteilt. Qemu vergibt per Default immer die gleiche MAC-Adresse. So können sich die verschiedenen Qemu-Instanzen aber nicht über den virtuellen Switch unterhalten.

Nun kann man eine Qemu-Instanz starten. Ich habe Qemu unter /opt/kvm installiert. Das sieht dann so aus:

vdeq /opt/kvm/bin/qemu-system-x86_64 -net vde,vlan=0,sock=/var/run/vde.ctl -net nic,vlan=0,macaddr 52:54:00:00:AA:02 -hda disk.img -m 128 -localtime

vdeq ist ein Wrapper der Qemu startet und das Qemu-Gastsystem mit dem VDE Switch verbindet. Wenn man keine grafische Ausgabe möchte, weil das System z.B. auf einem Server läuft, gibt man einfach noch zusätzlich z.B. noch -vnc :2 an. Dann kann man sich mit dem vncclient mit dem Qemu-Gast verbinden. Was man nicht tun sollte, so logisch es klingen mag, -nographic anzugeben. Da geht bei mir die CPU Last ganz mächtig nach oben. Wieso ist mir allerdings etwas schleierhaft und das ist vielleicht auch nicht überall so.

Noch ein Tipp: Wenn ihr meint, ihr habt alles richtig gemacht, startet Qemu und setzt dann einen einfachen ping ab und es kommt die Meldung bad file descriptor, dann stoppt die VM, beendet VDE, stoppt das TAP-Device, löscht alles was irgendwie nach vde klinkt unter /var/run raus, startet das TAP-Device wieder, konfiguriert es (IP, Netmask, usw.), startet VDE wieder und  anschließend Qemu. Bei mir hat's geholfen ;-) Hat mich auch blos 10 Jahre meines Lebens gekostet...

Ein paar Links:
Qemu - How to use Network
VDE Basic Networking
Using VDE with QEMU HOWTO
Gentoo HowTo: Qemu
Qemu / KVM - Ein grosses HowTo
Gentoo Wiki - KVM
OS on QEMU
Ubuntu - The Kernel Virtual Machine
QEMU Notes
QEMU - Debian - Linux - TUN/TAP - network bridge
QEMU, VDE and Dnsmasq
VDE, Dnsmasq SystemV Init-Skript
QEMU host <-> guest network bridging

Technorati Tags: gentoo, network, qemu, tap, tun, vde, dnsmasq, howto, debian, bridge

Erstellt am 11:59PM Jul 29, 2007 in Tipps  |  Permalink Kommentare[0]
Tags: debian tap dnsmasq gentoo tun network bridge qemu howto vde

KVM - Kernel based Virtual Machine - unter Gentoo installieren

Nachdem ich mich gegen XEN und für die Kombination KVM/Qemu entschieden habe, habe ich in letzter Zeit damit etwas beschäftigt. Aufgrund meiner aktueller Hardware musste auch ein relativ aktueller Kernel her, der mindestens 2.6.20 sein musste. Das hatten vor ein paar Wochen noch nicht viele Distributionen. Ausserdem war es für mich wichtig, das ich jederzeit meinen eigenen Kernel kompilieren kann. Und damit sieht's dann mit XEN ganz schlecht aus. Man braucht eigentlich immer einen Kernel, der bei der Distribution dabei ist. Wenn man auf die Sourcen von der xensource.com Seite angewiesen ist, ist man eh verloren. Mich würd das einfach aufregen, immer darauf angewiesen zu sein, wann eine Distribution mal wieder einen Kernel mit XEN rausbringt oder XEN selbst mal wieder eine Anpassung an irgendeinen Kernel macht. Also was liegt näher, gleich die KVM zu verwenden, die seit 2.6.20 sowieso in jedem Kernel ist? Soweit ich das bis jetzt beurteilen kann, läuft das wirklich gut. Nur einen Nachteil gegenüber XEN habe ich bisher gefunden (ok man braucht noch einen Prozessor, der Hardwarevirtualisierung unterstützt, den XEN auch nicht braucht...), der schon etwas schade ist: Man kann keine PCI Geräte in die KVM einblenden. Bei XEN kann man z.B. eine TV-Karte aus der Dom0 ausblenden und in eine DomU einblenden. Bei der KVM ist man auf die Geräte beschränkt, die der Emulator mitliefert. Auf jeden Fall bin ich mit der Geschwindigkeit der KVM bisher sehr zufrieden.

Zunächst guggt man, ob man einen Prozessor mit Hardwarevirtualisierung (HVM) hat:

egrep '^flags.*(vmx|svm)' /proc/cpuinfo

Bei mir sieht das dann so aus: 

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm

Kommt keine Ausgabe, dann kann man die KVM nicht nutzen. vmx erscheint bei Intelprozessoren und svm bei AMD. Inzwischen ist der Kernel 2.6.20 für die AMD64/EMT64 Plattform nicht mehr masked, so das bei der Installation des Kernels mit

emerge -av gentoo-sources

bei mir momentan 2.6.20-r8 installiert ist. Als nächstes sollte man im Kernelsource guggen, ob das KVM Kernelmodul auch einkompiliert ist. Dazu verwendet man entweder genkernel oder man wechselt nach /usr/src/linux und gibt make menuconfig ein. Ob das KVM Modul aktiviert ist, sieht man unter

Device Drivers
 -> Virtualization
 -> Kernel-based Virtual Machine (KVM) support

Hier schaltet man dann die KVM für Intel oder eben AMD ein, falls nicht schon passiert. Wenn man den Kernel neu erzeugen muss, dann sollte man das aber mit genkernel machen mit

genkernel --menuconfig

Wenn man dann einen fertigen Kernel hat und der Rechner eventl. restartet wurde, kann man das Kernelmodul laden für Intel

modprobe kvm-intel

und für AMD

modprobe kvm-amd

Nun ist es so, das das KVM Modul höchstwahrscheinlich mit dem GCC 4 kompiliert worden ist. Bei gcc -v kommt bei mir z.B. die Version 4.1.1 zu Tage. Der Emulator Qemu läßt sich aber momentan aber nur mit GCC 3 übersetzen. Also müssen wir den nachinstallieren:

emerge =sys-devel/gcc-3.4.6

Nun brauchen wir die Programme für den Userspace und damit u.a. den Emulator Qemu, der hier in einer angepassten Version für die KVM vorliegt. Die KVM Userspace-Programme kann man bei Sourceforge downloaden:

Kernel virtual machine

Für den Kernel 2.6.20 brauchen wir die Version 12 und für Kernel 2.6.22 KVM-36. Die Installation sieht dann z.B. wie folgt aus:

tar xvfz kvm-12.tar.gz
cd kvm-12
./configure --prefix=/opt/kvm --qemu-cc="/usr/bin/gcc32"
make
make install

U.U. muss man noch die Alsa-Sources nachinstallieren (die musste ich unter Debian Etch nachinstallieren). Bei mir waren alle nötigen Sourcen schon vorhanden. Wenn das dann durchgelaufen ist, findet man in /opt/kvm/bin qemu-img zum Erzeugen der VM-Images und qemu-system-x86_64 mit dem man die VM dann startet.

So... Dann sind also mal die Grundvoraussetzungen für die KVM geschaffen. Wie man Images erzeugt und wie man mehrere VMs mit Hilfe des VDE (Virtual Distributed Ethernet) ans Netz bringt, zeig ich dann später. Mehr zu dem Thema auch im KVM Gentoo Wiki.

Erstellt am 03:00AM Jul 07, 2007 in General  |  Permalink Kommentare[0]
Tags: gentoo qemu kvm

X: X Error of failed request

Wenn man z.B. eine Linux-Distribution unter qemu remote auf einen anderen Rechner installieren möchte, muss man i.d.R. dafür sorgen, das die X-Ausgabe auf den lokalen Client ladet. Das läßt sich z.B. über ssh realisieren:

ssh -X rechnername 

Wenn man nun versucht, z.B. Debian unter qemu zu installieren, kam bei mir folgende Meldung: 

X Error of failed request

Die Lösung des Problem ist, das man anstatt -X den Switch -Y verwendet:

ssh -Y rechnername

Das schaltet das trusted X11 forwarding ein.

Technorati Tags: x11, ssh, qemu

Erstellt am 08:00PM Jul 01, 2007 in General  |  Permalink Kommentare[0]
Tags: x11 ssh qemu