Es gibt in der Zwischenzeit praktisch keine Linux Distribution mehr, bei der Hardware Virtualisierung nicht mitgeliefert wird. Über das Setup haben wir auch schon hier im Blog berichtet.
Allerdings hat sich in den letzten drei Monaten herausgestellt, daß die Dinge nicht immer so einfach sind, wie man auf den ersten Blick erwarten würde. Obwohl das System auch über längere Zeiträume stabil lief, kam es immer wieder zu unerklärlichen Abstürzen. Das fatale daran: der Gast in der domU brachte dadurch immer auch das Wirtssystem mit zum Absturz.
CPU: 0
EIP: 0061:[<e1202e82>] Not tainted VLI
EFLAGS: 00210286 (2.6.22-14-xen #1)
EIP is at xfs_count_page_state+0x42/0x80 [xfs]
eax: c199b9e0 ebx: c199b9e0 ecx: c16c84d4 edx: 00100100
esi: d94d9b64 edi: d94d9b68 ebp: d94d9b60 esp: d94d9b14
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0069
Process sftp-server (pid: 32164, ti=d94d8000 task=df2a6f90 task.ti=d94d8000)
Stack: c199b9e0 d94d9b34 d94d9b60 000200d2 e1203fd6 […]
Call Trace:
[<e13fd6>] xfs_vm_releasepage+0x76/0xd0 [xfs]
[<e13f60>] xfs_vm_releasepage+0x0/0xd0 [xfs]
[<c0154c>] try_to_release_page+0x2c/0x40
[<c015c3>] shrink_inactive_list+0x7b3/0x910
[<c01161>] __activate_task+0x21/0x40
[<c0114f>] try_to_wake_up+0x3f/0x400
[<e12010>] xfs_bmap+0x0/0x10 [xfs]
[<e12004>] __xfs_get_blocks+0x74/0x2b0 [xfs]
Die Probleme scheinen immer durch das Zugriffe auf das XFS Dateisystem ausgelöst zu werden. Das ist umso verwunderlicher, da auf der Testmaschine keine Probleme dieser Art zu beobachten waren. Generell war XFS bisher immer das Dateisystem der Wahl. Es hat sich bei Systemabstürzen und auch bei defekten Platten immer hervorragend bewährt: Normalerweise kann man jahrelang Daten über Daten auf XFS Dateisystemen verwalten, ohne daß es jemals aus dem Tritt kommt.
Im Gegensatz zum Testsystem liegt das XFS Dateisystem auf einem Software RAID, das über dm-crypt eingebunden wird. Außerdem handelt es sich beim Produktivsystem um eine Mehrprozessormaschine. Ich habe jetzt jedenfalls das virtuelle System komplett auf ext3 umgestellt und hoffe, daß die Probleme nun endgültig behoben sind.
Aber auch mit 3ware Controllern scheint XEN so seine liebe Mühe zu haben. Verwendet man einen XEN Kernel auf einem System, das mit älteren PATA Controllern (z.B. 7850) ausgestattet ist, ist innerhalb kürzester Zeit kein schreibender Zugriff auf das Dateisystem mehr möglich.
sd 0:0:0:0: [sda] Result: hostbyte=DID_ERROR
driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sda, sector 32189487
lost page write due to I/O error on sda5
lost page write due to I/O error on sda5
3w-xxxx: tw_map_scsi_sg_data(): pci_map_sg() failed.
Scheint also noch nicht so ganz ausgereift zu sein… Leider gibt es bei diesem Artikel weder eine Pointe noch eine Lösung.
Bis auf weiteres kann man diese Sachen halt nicht in dieser Kombination verwenden.
Ein Gedanke zu „XEN ist doch nicht so unproblematisch“