Re: KVM - virtio und Partitionierung
So, nach etlichen xx Stunden Suchen/ausprobieren habe ich selber eine
Lösung für beide Sachen gefunden. Vielleicht ist das für jemand anderen
noch nützlich, daher schreibe ich mal über beide Dinge.
1)
Den Disk Cache zu deaktivieren macht man in der XML Datei mit:
<driver name='qemu' cache='none'/>
Man muss einen Eintrag also zum beispiel von:
<disk type='block' device='disk'>
<source dev='/dev/vg/kvm-debian'/>
<target dev='vda' bus='virtio'/>
</disk>
auf:
<disk type='block' device='disk'>
<driver name='qemu' cache='none'/>
<source dev='/dev/vg/kvm-debian'/>
<target dev='vda' bus='virtio'/>
</disk>
anpassen. Gefunden habe ich das indirekt hier:
http://rhn.redhat.com/errata/RHBA-2010-0282.html
Dort beschreibt es der vierte Eintrag des Bugfixes (BZ#512072).
Allerdiengs muss man das in Zukunft wohl nicht mehr machen. Den der
Bugfix beschreibt das dies nun in der Zukunft defaultmäßig gemacht wird.
Wenn jemand nicht weiß warum das wichtig ist. Wenn man Block Devices wie
Partitionen oder LVs durchreicht dann hat man ein Cache im Host System
und im Guest System aktiviert. Daher wird alles extrem langsamer, bei
mir um den Faktor 100%. Mit der Option cache=none in der Config wird
somit der Host Cache deaktiviert. Weiterhin muss der Host Cache auch
deaktiviert werden da sonst ein fsync() im Guest System nicht mehr
zuverlässig ist.
Ansonsten muss man beim ändern aufpassen. Während der libvirt Daemon
aktiv ist bringt es nicht die Config Datei anzupassen. Man muss zuerst
libvirt herunterfahren (und somit auch alle VMs) die Datei ändern und
dann wieder libvirt aktivieren.
Ein zweiter sehr viel wichtiger Punkt, die version in Debian Lenny ist
warum auch immer zu alt. Man muss also zusätzlich noch libvirt updaten.
Die aktuelle Version aus den backports.org Archiv funktioniert
einwandfrei. Das ist 0.7.6.
Hat man das gemacht und starten die VMs kann man leicht prüfen ob der
cache deaktiviert wurde, einfach in der Prozess Tabelle schauen, beim
"kvm" befehl muss dann bei der "-drive" Option zusätzlich noch ein
"cache=off" erscheinen.
Ansonsten hatte ich einmal ein paar Benchmarks gemacht, die ich dann
nicht vorenthalten möchte. Wobei ich dazu wohl noch viel erzählen muss:
http://global.phoronix-test-suite.com/index.php?k=profile&u=root-11820-30374-27022
Im großen und ganzen sind die tests mit dem lesen mehr oder weniger
unbrauchbar, hier steht für Host sowie Guest System zahlen von 2900mb/s
oder 900mb/s etc. die dateien werden wohl vom OS gecached, daher auch so
hohe zahlen.
Die schreibwerte sind ganz Interessant, im ganzen läuft das hinaus das
die Benchmarks sagen das die KVM VM schneller als mein Host ist. Zuerst
konnte ich noch nichtmal verstehen warum und bin dann heute morgen auch
im bett gegangen, als ich mich dann wieder daran gesetzt habe, habe ich
den Grund gefunden.
Als erstes zum Host System. Ich nutze XFS, das Host System nutzt LVM
aber logischerweise auf einer echten Harddisk.
Für das Guest System habe ich eine LV erstellt. Das Guest System sieht
also eine Harddisk die auf LVM läuft und dort nutze ich wieder wiederrum
XFS.
Beim Booten des Guest ist dann folgende Meldung interessant:
> Filesystem "vda1": Disabling barriers, not supported by the underlying
device
Jetzt war die Frage was barriers überhaupt ist. Kurz gesagt mit barriers
wird sichergestellt das fsync() Operationen auch wirklich synchron sind
wenn der Harddisk cache aktiviert wurde. Das ganze kann natürlich nur
aktiv sein wenn das laufwerk das auch unterstützt.
Meine echte Harddisk tut das, das Guest System hat aber eine Harddisk
die ja auf LVM läuft, und LVM unterstützt das nicht.
"barriers" zu aktivieren reist aber einen relativ großes Loch in der
Performance, stellt aber sicher das Schreiboperationen auch wirklich
geschrieben wurden.
Ich habe also noch weiter gesucht. Und bin noch zu folgenden Sachen
gekommen. Barriers wird derzeit default nur von XFS und ext4 aktiviert
wenn es unterstützt wird. Bei ext3 ist es z.B. default aus. Es zu
deaktivieren bedeutet aber auch das wenn Datenbanken zum Beispiel
Transaktionen nutzen am ende einer Transaktion nicht sichergestellt ist
ob Daten wirklich zur HDD geschrieben wurde. Ansonsten hatte ich
irgendwo gelesen das barriers support in LVM wohl ab Linux 2.6.29
verfügbar ist.
Ansonsten ist das Thema mit barriers schon so als wenn man die Böxe der
Pandora öffnet: Wer mehr drüber lesen möchte:
http://blog.nirkabel.org/2008/12/07/ext3-write-barriers-and-write-caching/
http://lwn.net/Articles/283161/
http://xfs.org/index.php/XFS_FAQ#Q:_How_can_I_address_the_problem_with_the_disk_write_cache.3F
Und unzählige weitere Tests/Benchmarks beschreibungen bei Google.
2)
Für die Partitonierung hatte ich mir noch ein drittes Schema überlegt.
Für jede Partition im Guest System wird eine LV im Host System genutzt.
Die LV kann problemlos erweitert werden. Im Gastsystem wird dann zuerst
die Partition auf die maximale größe der festplatte gezogen, danach dann
das Dateisystem vergrößert.
Problem bei der Umsetzung:
Vergrößern der LV kann man zwar allerdiengs bekommt das Guest System
davon nichts mit. Man muss mindest einmal rebooten. Zumindest weiß ich
nicht wie man den Guest System mitteilt das sich die Harddisk vergrößert
hat.
Danach kann man die Partition größer machen. Zum Beispiel mit "parted".
Da ich XFS nutze geht das aber leider nicht mit parted. parted
vergrößert auch das Dateisystem, XFS ist aber nur vergrößerbar wenn es
auch gemountet ist. Vergößern der partition ist aber trotzdem kein
Problem. Allerdiengs weigern sich die ganzen Partitionier Tools dies zu
machen wenn die Partition gemountet ist, daher habe ich eine Knoppix
gebootet und es von dort aus gemacht. Von Knoppix dann einfach cfdisk
/dev/vda die aktuelle partition löschen und eine neue mit maximaler disk
größe erstellen. Bei anderen Dateisystemen kann man auch parted nutzen.
System wieder normal booten und dann xfs_growfs auf die Partition
anwenden die XFS nutzt.
Wenn man es noch hinbekommen würde das die neue Diskgröße dem Guest
System ohne Reboot bekannt gemacht werden kann, und die Partition auch
vergrößert werden kann im gemounteten zustand dann wäre das wohl ein
sehr guter weg. Ich werde wohl nochmal den LVM-in-LVM ansatz weiter
ausprobieren auser jemand weiß wie letzteres erreichbar ist.
Reply to: