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.
Posted at 09:41nachm. Feb. 04, 2009 by cetixx in Tipps | Kommentare [0]