[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Xen und nfs: wie überlasse ich export einer domU?



Hallo Liste,

ich bin dabei meinen Server neu aufzusetzen.
c't Debian Server 2.1 ist bereits drauf und läuft in einer Dom0.
Das, was vorher die Dom0 gemacht hat ist nun auf eine DomU übertragen.
Neben dem Webserver zählt auch die Verteilung der Daten zur Aufgabe der DomU.
Nun hatte ich einen Absturz beim verteilen der Festplatten.

Die Systemfestplatte hängt an hda, DVD an hdc.
Die Datenplatten hängen an sda (interner S-ATA Controller auf dem MBoard, 
nforce2), hde und hdg (PCI-Karte, DMA100-Controller). Auszug aus lspci:
> 01:0c.0 RAID bus controller: Silicon Image, Inc. SiI 3112 
[SATALink/SATARaid] Serial ATA Controller (rev 02)
> 01:06.0 Mass storage controller: Promise Technology, Inc. PDC20268 (Ultra100 
TX2) (rev 02)
Diese hatte ich per Grub (menu.lst) der Dom0 ausgeklammert, und in der 
XEN-Config der DomU gegeben.
Das mounten in der DomU funktionierte auch zunächst ohne murren, die Dom0 hat 
keine Platte mounten können - so soll es ja auch sein.
Nach einer gewissen Zeit (5-10 Minuten?) stürzte alles ab. In der DomU tat 
sich gar nichts mehr, die Dom0 nahm zwar noch Befehle entgegen, machte aber 
nix. Betätigung des Reset-Tasters (selbst nach einstündiger Wartezeit nach 
Affengriff) war leider unumgänglich.
Die letzt Meldung die ich auf der ssh-Konsole noch retten konnte war:
> Message from syslogd@domu at Wed Dec 19 09:54:35 2007 ...
> domu kernel: Disabling IRQ #16
Im Log der Dom0 /var/log/messages steht:
># cat /var/log/messages | grep "Dec 19 09:5"
>Dec 19 09:54:57 server-dom0 kernel: hda: dma_timer_expiry: dma status == 0x64
>Dec 19 09:55:07 server-dom0 kernel: hda: DMA interrupt recovery
>Dec 19 09:55:07 server-dom0 kernel: hda: lost interrupt
>Dec 19 09:55:27 server-dom0 kernel: hda: dma_timer_expiry: dma status == 0x64
>Dec 19 09:55:37 server-dom0 kernel: hda: DMA interrupt recovery
>Dec 19 09:55:37 server-dom0 kernel: hda: lost interrupt
>Dec 19 09:55:57 server-dom0 kernel: hda: dma_timer_expiry: dma status == 0x64
>Dec 19 09:56:07 server-dom0 kernel: hda: DMA interrupt recovery
>Dec 19 09:56:07 server-dom0 kernel: hda: lost interrupt
>Dec 19 09:56:27 server-dom0 kernel: hda: dma_timer_expiry: dma status == 0x64
>Dec 19 09:56:37 server-dom0 kernel: hda: DMA interrupt recovery
>Dec 19 09:56:37 server-dom0 kernel: hda: lost interrupt
>Dec 19 09:56:57 server-dom0 kernel: hda: dma_timer_expiry: dma status == 0x64
>Dec 19 09:57:07 server-dom0 kernel: hda: DMA interrupt recovery
>Dec 19 09:57:07 server-dom0 kernel: hda: lost interrupt
>Dec 19 09:57:27 server-dom0 kernel: hda: dma_timer_expiry: dma status == 0x64
>Dec 19 09:57:37 server-dom0 kernel: hda: DMA interrupt recovery
>Dec 19 09:57:37 server-dom0 kernel: hda: lost interrupt
>Dec 19 09:57:57 server-dom0 kernel: hda: dma_timer_expiry: dma status == 0x64
>Dec 19 09:58:07 server-dom0 kernel: hda: DMA interrupt recovery
>Dec 19 09:58:07 server-dom0 kernel: hda: lost interrupt
>Dec 19 09:58:27 server-dom0 kernel: hda: dma_timer_expiry: dma status == 0x64
>Dec 19 09:58:36 server-dom0 kernel: NETDEV WATCHDOG: eth2: transmit timed out
>Dec 19 09:58:37 server-dom0 kernel: hda: DMA interrupt recovery
>Dec 19 09:58:37 server-dom0 kernel: hda: lost interrupt

An einen Defekt glaube ich nicht. Denn, die Platten sind im Moment in der Dom0 
gemountet und erfreuen sich einer Datensicherung auf eine externe USB-HDD.

Habe ich was falsch gemacht, oder habe ich einen Denkfehler?
Im Bios ist ACPI eingeschaltet, aber alles was dadrunter steht deaktiviert - 
wie auch HDD-spindown.

Falls der Grundgedanke schon suspekt ist: in der c't Zeitschrift zu dem Server 
steht drin, dass man der Dom0 tunlichst so wenig wie möglich auferlegen 
sollte. Also zählte ich nfs auch dazu.
Allerdings fällt mir gerade beim tippen so ein, dass auf diesem Wege eine 
Datensicherung schwierig wird. Erkennt die DomU später überhaupt die am 
USB-Port angeschlossene Platte? Soweit bin ich noch nicht, die Datensicherung 
läuft ja noch.

Genug gequasselt, Eure Meinungen bitte :-)

Danke schonmal und
mfG, Chris......


Reply to: