Category Archives: Virtualisierung, KVM, Xen

fsck on KVM raw device disks

Posted on by

If you have a small company resource optimization is a must. Therefore, I use KVM virtualization to provide several (virtual) servers on a KVM host. The hard disks are provided as raw devices under the control of the KVM “virtio” driver. My virtual machines have been running very reliably for two years now.

However, some days ago one of the servers – a LAMP server called “vm1” – could not be booted any more. Not even its virtual console displayed any messages – the boot process stopped at the very beginning. I took this as a sign to check for corruptions of the file system. In the case of “vm1” the raw device is located on a LVM partition “/dev/volgrpk/vm1_hd1” of a LVM volume group on the KVM host. The internal structure of this device consists of a SWAP partition plus a data partition. The latter one gets mounted on “/” on the virtual guest server.

Because it was such a long time ago that I had to use fsck on a virtual device I had forgotten that you cannot deal directly with KVM raw devices from the KVM host. My naive trial to use fsck directly produced warnings as the KVM host cannot handle KVM raw image devices : 

kvm-host:~ # fsck /dev/volgrpk/vm1_hd1 
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/mapper/volgrp1-vm1_hd1

So, I needed a tool which provides access to the partitions of a KVM raw device with some disk image on it.

kpartx to access partitions on KVM raw devices

The easiest way to access a raw device from the KVM host is to use “kpartx”. For Opensuse a relatively up to date RPM is provided in the Update repository “http://download.opensuse.org/update/13.1/“.

For the usage of kpartx see :
KVM-Host – Mounten “virtueller” Gast-Partitionen aus logischen LVM-Volumes
http://linux.die.net/man/8/kpartx
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/sect-Virtualization-Troubleshooting_Xen-Accessing_data_on_guest_disk_image.html

Before you apply kpartx you should have a look at “/proc/partitions/” to be able to distinguish the newly attached virtual partitions later on. In my case I get something like: 

kvm-host:~ # cat /proc/partitions           
major minor  #blocks  name

   8        0 3906228224 sda
   8        1    2088450 sda1
   8        2  104856576 sda2
   8        3  125829112 sda3
   8        4  125837312 sda4
   8        5  104855552 sda5
   8        6  104856576 sda6
   8        7    2096128 sda7
   8        8  629145600 sda8
   8        9  419433472 sda9
   8       10  146809856 sda10
  11        0    1048575 sr0
 253        0  125829120 dm-0
 253        1   62914560 dm-1
 253        2   62914560 dm-2
 253        3   83886080 dm-3
 253        4   41943040 dm-4
 253        5  104857600 dm-5
 253        6  188743680 dm-6
 253        7  104857600 dm-7
  43        0   62914560 nbd0

Now, we first make sure that the KVM guests supposed to use your raw image devices are offline. More precisely: … that any KVM guests using image partitions on the raw device you want to access by kpartx are offline. I avoid sharing or NFS-, SMB-mounting
partitions on raw devices – then it is clear which KVM guests to stop.

To get access to the partitions of a raw device we use kpartx with the option “-a”. In the following example this is shown for for two raw devices used by two different virtual servers: 

kvm-host:~ # kpartx -a /dev/volgrpk/vm1_hd1 
kvm-host:~ # kpartx -a /dev/volgrpk/vm2_hd1 
kvm-host:~ # cat /proc/partitions
major minor  #blocks  name

   8        0 3906228224 sda
   8        1    2088450 sda1
   8        2  104856576 sda2
   8        3  125829112 sda3
   8        4  125837312 sda4
   8        5  104855552 sda5
   8        6  104856576 sda6
   8        7    2096128 sda7
   8        8  629145600 sda8
   8        9  419433472 sda9
   8       10  146809856 sda10
  11        0    1048575 sr0
 253        0  125829120 dm-0
 253        1   62914560 dm-1
 253        2   62914560 dm-2
 253        3   83886080 dm-3
 253        4   41943040 dm-4
 253        5  104857600 dm-5
 253        6  188743680 dm-6
 253        7  104857600 dm-7
  43        0   62914560 nbd0
 253        8    2095104 dm-8
 253        9   60818432 dm-9
 253       10    2095104 dm-10
 253       11   60818432 dm-11
kvm-host:~ # file -s /dev/dm-8
/dev/dm-8: Linux/i386 swap file (new style), version 1 (4K pages), size 523775 pages, no label, UUID=23b50bc8-dbeb-4b2d-be10-75b9f390377e
kvm-host:~ # file -s /dev/dm-9
/dev/dm-9: DOS/MBR boot sector
kvm-host:~ # file -s /dev/dm-10
/dev/dm-10: Linux/i386 swap file (new style), version 1 (4K pages), size 523775 pages, no label, UUID=83220483-e419-42d8-88b6-e6dfe202aebc
kvm-host:~ # file -s /dev/dm-11
/dev/dm-11: DOS/MBR boot sector; GRand Unified Bootloader, stage1 version 0x3, LBA flag 0x1, 1st sector stage2 0x1448200, GRUB version 0.97
kvm-host:~ #

Clearly four additional partitions dm-8 until dm-11 are recognized. Two of them are SWAP partitions. “/dev/dm-9” and “/dev/dm-11” are data partitions each of which is mounted on “/” on my virtual KVM guest servers.

The dm-9 partition is the relevant one for the planned fsck check, which we now can perform in the usual way: 

kvm-host:~ # <strong>fsck -f  /dev/dm-9</strong>
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/volgrpk-vm1_hd1p2: 444945/3808512 files (0.2% non-contiguous), 14281802/15204352 blocks

By the way: A look into “/dev/mapper” shows the available devices and partitions and their device names automatically provided by kpartx: 

kvm-host:~ # ls -l /dev/mapper
total 0
crw------- 1 root root 10, 236 Oct 27 07:46 control
....
....
lrwxrwxrwx 1 root root       7 Oct 27 12:09 volgrpk-vm1_hd1 -> ../dm-1
lrwxrwxrwx 1 root root       7 Oct 27 12:10 volgrpk-vm1_hd1_part1 -> ../dm-8
lrwxrwxrwx 1 root root       7 Oct 27 12:21 volgrpk-vm1_hd1_part2 -> ../dm-9
lrwxrwxrwx 1 root root       7 Oct 27 12:10 volgrpk-vm1_hd1p1 -> ../dm-8
lrwxrwxrwx 1 root root       7 Oct 27 12:21 volgrpk-vm1_hd1p2 -> ../dm-9
lrwxrwxrwx 1 root root       7 Oct 27 08:43 volgrpk-vm2_hd1 -> ../dm-2
lrwxrwxrwx 1 root root       8 Oct 27 12:11 volgrpk-vm2_hd1_part1 -> ../dm-10
lrwxrwxrwx 1 root root       8 Oct 27 12:11 volgrpk-vm2_hd1_part2 -> ../dm-11
lrwxrwxrwx 1 root root       8 Oct 27 12:11 volgrpk-vm2_hd1p1 -> ../dm-10
lrwxrwxrwx 1 root root       8 Oct 27 12:11 volgrpk-vm2_hd1p2 -> ../dm-11
lrwxrwxrwx 1 root root       7 Oct 27 07:46 volgrpk-vm_imap_hd0 -> ../dm-3
lrwxrwxrwx 1 root root       7 Oct 27 07:46 volgrpk-vm_imap_hd1 -> ../dm-4

I omitted some lines and devices in the list
above. The last 2 entries stem from a running virtual IMAP server. Note that one and the same device may be presented with different names. again
Now, we can test our virtual server again by booting it – which in my case worked perfectly …

Before testing the virtual LAMP sever with the repaired file system we should not forget to detach the devices still controlled by kpartx: 

kvm-host:~ # kpartx -d /dev/volgrp1/vm1_hd1 
kvm-host:~ # kpartx -d /dev/volgrp1/vm2_hd1

A look into “/dev/mapper” again shows that the raw image disk devices are still shown. However, the partitions have disappeared. 

kvm-host:~ # ls -l /dev/mapper 
total 0
crw------- 1 root root 10, 236 Oct 27 07:46 control
lrwxrwxrwx 1 root root       7 Oct 27 13:18 volgrpk-vm1_hd1 -> ../dm-1
lrwxrwxrwx 1 root root       7 Oct 27 08:43 volgrpk-vm2_hd1 -> ../dm-2
lrwxrwxrwx 1 root root       7 Oct 27 07:46 volgrpk-vm_imap_hd0 -> ../dm-3
lrwxrwxrwx 1 root root       7 Oct 27 07:46 volgrpk-vm_imap_hd1 -> ../dm-4

Now, we can test our virtual server (here vm1) by booting it – which worked perfectly in my case …

KVM – Problem nach Upgrade Opensuse 12.3 auf 13.1

Posted on by

Habe vor ein paar Tagen einen KVM-Host von Opensuse 12.3 auf Opensuse 13.1 upgegradet. Wie immer habe ich gleich auch noch ein Update aller relevanten System-RPMs auf den aktuellen Stand gemäß Opensuses Standard-Repositories vorgenommen. Danach gingen KVM, virt-manager und Konsorten nicht mehr. Fehler über Fehler …. im besonderen endet der Start von virt-manager mit Fehlern. Auch der testweise Versuch, neue virtuelle Maschinen anzulegen, endet mit Fehlermeldungen. “systemd” zeigt nach dem Start des Service “libvirtd” Fehler der Art

libvirtError: unknown OS type hvm

an.

Ich habe dann die kvm-Pakete, libvirt-Pakete etc. deinstalliert und die erneute Installation über die YaST2-Module “Install Hypervisor and Tools” vornehmen lassen. Erneut ergab sich ein negatives Resultat. Offenbar testet z.Z. bei SuSE niemand die KVM-Funktionsfähigkeit unter OS 13.1!

Als nächstes habe ich dann versucht, die von YaST2 installierten Pakete über das Repository
http://download.opensuse.org/repositories/Virtualization/openSUSE_13.1/
upzudaten. Erneut ein Fehlschlag!

Bevor man nun in Verzweiflung gerät:

Nach einigem Probieren habe ich eine Variante gefunden, die aktuell funktioniert. Der Clue ist, dass man statt des Paketes “kvm” besser “qemu-kvm” installieren sollte. Dann läuft alles wieder wie geschmiert. Man kann sich dann auch mit dem aktuellen Layout von “virt-manager” anfreunden. Die Liste der von mir installierte Pakete aus dem oben genannten Repository sieht aktuell wie folgt aus:

kvm

Man beachte, wie gesagt, dass das Paket “kvm”, das Opensuse standardmäßig vorsieht, durch “qemeu-kvm” ersetzt ist.

KVM-Host – Mounten “virtueller” Gast-Partitionen aus logischen LVM-Volumes

Posted on by

Beim Aufsetzen eines neuen Servers schlage ich zur Zeit einen Weg ein, bei dem bestimmte Serveraspekte in virtuellen KVM-basierten Maschinen gekapselt werden sollen. Nun nutze ich auf dem KVM-Host als Basis einer flexiblen Partitionierung LVM. Die virtuellen KVM-Systeme erhalten ihre virtuellen Platten und zugehörige Partitionen in Form der Zuweisung von logischen LVM-Volumes, die auf dem KVM-Host vorliegen. Der Zugriff des Gastes auf dieses Raw-Device erfolgt in meinem Fall über “virtio”. Im Zuge der Installation des Gast-Systemes werden innerhalb der virtuellen Harddisk dann “virtuelle” Partitionen des Gastsystems angelegt. Die nachfolgende Darstellung illustriert dies:

KVM_Host_mit_LVM_V01

Aufgabenstellung: Mounten virtueller Partitionen eines KVM-Gastes auf dem KVM-Host

Der Inhalt der Aufgabenstellung hört sich nur scheinbar widersprüchlich an. Es kann tatsächlich mal vorkommen, dass man aus bestimmten Gründen gerne vom Host aus auf eine der “virtuellen” Partitionen des KVM-Gastes zugreifen möchte. Natürlich nur, wenn das KVM-Gastsystem nicht aktiv läuft und die virtuelle Harddisk nicht vom Gastsystem genutzt wird.

Bei ein wenig Nachdenken wird sofort klar: Ein solcher Zugriff des KVM-Hostes erfordert ein zwischengeschaltetes Tool – in den Partitionsverzeichnissen des Hosts wird die virtuelle Partition eines Gastes, die sich innerhalb eines logischen LVM-Volumes befindet, nicht direkt als mountbares Device bereitstehen. Die Situation ist hier vergleichbar mit der internen Struktur von Files, die als Loopback-Devices genutzt und gemountet werden. Der YaST2-“Partitioner” des Opensuse 12.3-Systems etwa lässt die interne Partitionierungs-Struktur logischer LVM-Volumes nicht erkennen. Schließlich wird ja das gesamte logische LVM-Volume von KVM als Raw-Device behandelt und enthält keine unmittelbaren Filesystem-Informationen wie eine normale formatierte (LVM-) Partition des Hosts.

Gründe für einen Zugriff auf virtuelle Partitionen der KVM-Gastsysteme vom Host aus können vielfältig sein – u.a. sind zu nennen:

  • Erstellung von Sicherungen bestimmter Inhalte des Gast-Filesystems.
  • Bearbeitung bestimmter Files des Filesystems des KVM-Gastes auch bei nicht laufendem KVM-Gast.

In meinem Fall hatte ich eine Konfigurationsdatei das Gastes verpfuscht, die ein normales Starten dieses KVM-Gastes verhinderte. Diese Datei hätte ich nun gerne vom Host aus bearbeitet, um das Gastsystem ohen Rückgriff auf Sicherungen wieder zum Laufen zu bringen.

Lösung: kpartx

Gibt es nun ein Linux-Tool mit dem man die Struktur des Raw-Devices auslesen und die Partitionen erkennen kann ? Ja, das gibt es – es heißt “kpartx”. Ich zitiere aus der zugehörigen “man-page”:

Name : kpartx – Create device maps from partition tables
Synopsis : kpartx [-a | -d | -l] [-v] wholedisk
Description : This tool, derived from util-linux’ partx, reads partition tables on specified device and create device maps over partitions segments detected. It is called from hotplug upon device maps creation and deletion.

“kpartx” kann man für verschiedene Devices oder Platten-Images einsetzen. Neben der Bereitstellung interner Partitionen von Raw-Device-Harddisks für virtuelle KVM-Systeme eignet es sich z.B. auch für den Zugriff auf Loopback-Device-Files.

Die verschiedenen Optionen von “kpartx” sehe man sich selber an. Mittels der Option “-a” erzeugt man eine vollständige Liste der Partitionen eines Raw-, LVM- oder Loopback-
Devices im Verzeichnis:

/dev/mapper

Die dortigen Einträge entsprechen unter Opensuse Links übrigens Devices der Form “/dev/dm-xx”. Diese Devices kann man dann im KVM-Host benutzen und u.a. mounten.

Ein Beispiel

Nachfolgend zur Illustration ein paar typische Kommandos für ein Testsetup:

Das Harddisk-Array der Testmaschine ist ein Raid 10-Array aus vier 2 TB-Platten. Das Array wurde mit GPT partitioniert. Die bislang aufgesetzten logischen Volumes befinden sich unter “/dev/volgrp1”. Einem virtuellen KVM-Gast wurde u.a. das logische Volume “/dev/volgrp1/vm_imap_hd0” als virtuelle Harddisk per virtio-Treiber zur Verfügung gestellt und beim Installieren des Betriebssystems OS 12.3 mit 2 “virtuellen” Partitionen – einem Swap-Bereich und einer ext4-Partition – ausgestattet.

Folgender Screenshot liefert einen Überblick:

kvm_partitions_1

Man erkennt, dass “fdisk” und “parted” den internen Aufbau z.B. des logischen LVM-Volumes “/dev/volgrp1/vm_imap_hd0” durchaus erkennen. Allerdings finden sich unter “/dev/mapper” noch keine entsprechenden Devices, die im Host direkt brauchbar und mountbar wären.

Hierfür benötigen wir nun den Befehl “kpartx” in der Form

kpartx -a /dev/volgrp1/vm_imap_hd0

kvm_partitions_2

Es wird klar, dass “kpartx -a /dev/volgrp1/vm_imap_hd0” denn internen Aufbau des logischen Volumes analysiert und entsprechende Devices unter “/dev/mapper” bzw. in unserem Fall als “/dev/dm-5” und “/dev/dm-6” bereitstellt. “/dev/dm-6” entspricht der Partition, die im virtuellen Gast als root-Filesystem gemountet wird.

Abschluss der Arbeiten mit Gast-Partitionen durch “kpartx -d”

Bitte nicht vergessen, nach dem Abschluss der Arbeiten mit den “virtuellen” Partitionen im KVM Host die Partitionen vor dem Neustart der virtuellen Maschinen wieder zu “umounten” und zur Sicherheit auch aus dem Device-Mapper zu entfernen. Letzteres ermöglicht “kpartx -d” – in unserem Beispiel:

kpartx -d /dev/volgrp1/vm_imap_hd0

Links

Natürlich ist die dargestellte Vorgehensweise nicht auf meinem Mist gewachsen. Deshalb stellvertretend für viele andere Links ein paar Hinweise auf Artikel, die für mich nützlich waren:

http://backdrift.org/mounting-a-file-system-on-a-partition-inside-of-an-lvm-volume
http://blog.normation.com/2011/04/07/mounting-partitions-stored-in-a-logical-volume-or-a-disk-image/
http://serverfault.com/questions/376421/how-to-access-partitions-inside-a-logical-volume-from-the-host-machine

Einige meiner Leser werden sich fragen, wie man die virtuellen Partitionen innerhalb eines logischen Volumes nun bei Bedarf in ihrer Größe abändern kann. Ein direktes Resizing mit LVM im Host ist hier natürlich nicht ohne größere Umwege möglich. Die Entwickler bei Red Hat haben aber den Befehl “virt-resize” bereitgestellt, der
im Zusammenspiel mit dem LVM-System des KVM-Hostes die erforderlichen Schritte sehr erleichtert. Hierzu seien dem interessierten Leser folgende Links ans Herz gelegt:

!!!!
http://unix-heaven.org/resizing-kvm-disk-image-lvm-the-easy-way
!!!!
http://www.pither.com/articles/2009/10/09/resize-ext3-in-lvm-in-partition-in-kvm-qemu-virtual-image-file
http://libguestfs.org/virt-resize.1.html

Viel Spass nun mit KVM, LVM, logischen Volumes und “virtuellen” Partitionen !

Opensuse 11.4, XEN, Nvidia, uvesafb

Posted on by

Wie bekommt man auf einem System mit einer Nvidia-Karte

  • Opensuse 11.4,
  • den zugehörigen XEN-Kernel
  • und einen graphischen Desktop mit 3D-Beschleunigung in der Dom0 des XEN-Systems

zum Laufen ?

Dieses Thema mag auf den ersten Blick fast esoterisch erscheien. Aber es gibt tatsächlich Entwickler für graphische Applikationen, die auf einem System virtualisierte Gäste laufen lassen und gleichzeitig in der Dom0 3D-Grafik betreiben wollen.

Siehe auch:
http://www.nvnews.net/vbulletin/showthread.php?t=60125

Ferner ist es so, dass man bei einem laufenden 3D-beschleunigten X-Server (z.B. in der Dom0) auch 3D-Output der virtuellen Maschinen beschleunigt darstellen kann: Das X-System beherrscht ja schon seit langem beschleunigten 3D-Ouput auch über ein Netzwerk.
Also kann man den graphischen Output der virtuellen Maschine über das (virtuelle gebridgte) Netzwerk des Hosts auch auf dem X-Server des Hosts beschleunigt darstellen. Bei einem leistungsstarken System geht das besser als man meinen möchte. Dazu mehr in einem künftigen Beitrag.

Ich habe selbst schon vor 3 Jhren bei meinen ersten Versuchen mit XEN Anläufe unternommen, um eine 3D-Beschleunigung mit Nvidia-Karten in der Dom0 irgendwie und halbwegs stabil hinzubekommen. Aber ich bin regelmäßig gescheitert. Nun hat sich inzwischen aber einiges getan (s. das oben angegebene Forum) und jetzt hat es endlich auch auf meinen XEN-Systemen unter Opensuse 11.4 so funktioniert wie ich mir das vorstelle. Meinen Lösungsansatz findet ihr im Original unter

http://www.nvnews.net/vbulletin/showthread.php?t=60125&page=10

als Beitrag des Users “moenchmeyer”.

Hier stelle ich als Ergänzung eine deutsche Variante der von mir angegebenen Schritte ins Netz.

Das Testsystem von mir hat einen Q9550 Quad Core Prozessor einen Raid10 Plattenverbund und eine Nvidia 9800 GTX+ Grafikkarte sowie 8 GByte RAM. Es wird als 64-Bit-System mit den entsprechenden x86_64-Kernelvarianten und Kernelmodulen betrieben.

Es sind zwei Hürden zu überwinden :

  1. Die Installation (inkl. Kompilation) des Nvidia-Treibers für den XEN-Kernel von Opensuse 11.4
  2. Der Einsatz von “uvesafb” statt des normalen Vesa Framebuffer-Verfahrens für die TTYs tty1 bis tty6 des XEN hosts.

Ohne Punkt 2 erhält man beim Umschalten von der graphischen Desktop-Umgebung, die typischerweise auf tty7 läuft, zu einem der textorientierten Terminals (tty1 bis tty6, tty10) nämlich nur schwarze Schirme. Und das mag zumindest ich nicht. Wie also kann man das vermeiden?

Schritt 1: Installation von Opensuse 11.4 mit den Xen und Virtualisierungspaketen (libvirt etc.)

Man installiere auf dem künftigen XEN-System Opensuse 11.4 zunächst ganz regulär. Vor dem eigentlichen Installationsvorgang wählt man bei der SW-PaketKonfiguration am besten gleich die Option “hostserver für Xen Virtual Machine” aus. Dann spart man sich die spätere Nach-Installation. Zusätzlich installiert man die notwendigen Compiler und Zutaten einer elementaren Entwicklungsumgebung sowie die Kernelquellen, um später Kernelmodule kompilieren zu können.

Schritt 2: Installationsversuch bzgl. des Nvidia-Kernel-Moduls nach dem Booten des Default-Kernels (nicht des Xen-Kernels)

Auf dem frisch installierten System werkelt der Nouveau-Treiber für Nvidia-Karten und erlaubt den Zugang zu einer graphischen Desktop-Umgebung. Im Gegensatz zum proprietären Nvidia-Treiber erlaubt dieser offene Treiber aber keine 3D-Beschleunigung. Daher holen wir uns nun den aktuellen Nvidia-Treiber (270.41.06) vom Nvidia-Portal.

Anschließend wechseln wir in den “runlevel 3”. Dort starten wir
im Verzeichnis mit dem Treiber die Installation:

sh NVIDIA-Linux-x86_64-270.41.06.run

Diese schlägt fehl – die Installationsroutine beklagt sich über den bereits laufenden Nouveau-Treiber. Die Frage, ob ein File zur Deaktivierung des Nouveau-Treibers installiert werden soll, beantworten wir positiv.

Schritt 3: Deaktivierung von KMS und Installation des Nvidia-Kernel-Moduls für den Default-Kernel (nicht Xen-Kernel)

Wir deaktivieren nun KMS – z.B. mit Hilfe von YAST und des dortigen Editors für die Files in “/etc/sysconfig”. Wir setzen die Option “NO_KMS_INITRD” unter “system > kernel” auf “yes”. (Alternativ kann man den Eintrag auch direkt im File “/etc/sysconfig/kernel” editieren.)

Anschließend führen wir einen Reboot in den Runlevel 3 durch. Dabei setzen wir im Menü des Grub Bootloaders neben “linux 3” noch den Parameter “nomodeset” – dann sind wir hinsichtlich der Deaktivierung von KMS auf der sicheren Seite.

Jetzt steht einer erfolgreichen Installation des NvidiaTreibers nichts mehr im Wege. Wir führen sie durch, wechseln danach in den Runlevel 5 und testen das korrekte Arbeiten der 3D-Beschleunigung in unserer grafischen Desktop-Umgebung über “glxinfo” oder die Einstellungen in der Applikation “nvidia-settings”. Natürlich können wir auch mal “glxgears” staren oder einen 3D-Effekt des KDE-Desktops anschalten.

Damit haben wir uns von der Funktionstüchtigkeit des Nvidia-Treibers für den normalen Kernel des Opensuse 11.4-Systems überzeugt. Jetzt kann man auch die Pakete für den Nouveau-Treiber deinstallieren – wenn man will.

Schritt 4: Booten des XEN-Kernels und Installation des Nvidiatreibers in der Dom0
Wir rebooten das System. Im Grub-Menü wählen wir nun aber die Option für den XEN-Kernel und geben erneut “linux 3” als Option an, um in den Runlevel 3 zu gelangen. Ein Booten in den Runlevel 5 würde scheitern, da der Nvidia-Treiber bislang nicht für den XEN-Kernel kompliert wurde.

Im Runlevel 3 führen wir daher die Installation des Nvidia-Treibers erneut durch – diesmal aber mit einer speziellen Art der Kompilation:

cd Your_Directory_With_THE_Nvidia_Driver
export IGNORE_XEN_PRESENCE=1 SYSSRC=/usr/src/linux-2.6.37.6-0.5 SYSOUT=/usr/src/linux-2.6.37.6-0.5-obj/x86_64/xen

sh ./NVIDIA-Linux-x86_64-270.41.06.run

Die Environment-Variablen IGNORE_XEN_PRESENCE, SYSSRC und SYSOUT werden von der Installationsroutine ausgewertet: Die Präsenz des XEN-Kernels wird ignoriert, die Kompilation erfolgt gegen die Sourcen und Einstellungen des Standard-Kernels – der resultierend Output (das Modul) wird aber gem. der Vorgaben für den XEN-Kernel gelinkt und installiert.

Die Versionsangaben in den obigen Statements müssen ggf. an die tatsächlichen Verhältnissen auf dem System angepasst werden. Sie gelten wie angegeben nur für eine Opensuse 11.4 Installation ohne Kernel-Updates.

Nun haben wir ein geeignetes und bereits geladenes Nvidia-Kernelmodul in der Dom0.

Schritt 5: Starten des X-Servers durch Wechsel in den Runlevel 5
Wir wechseln nun in den Runlevel 5 (init 5). Der XServer sollte anstandslos auf dem tty7 starten. Wir können uns dort einloggen und uns von der Funktionstüchtigkeit der 3D-Beschleunigung überzeugen. Damit ist die erste Hürde für den XEN-Kernel genommen.

Unglücklicherweise hat die Sache einen gravierenden Makel:

Ein Wechsel von der graphischen Oberfläche zu einem der textorientierten Terminals tty1 bis tty6 führt zu schwarzen Bildschirmen. Hier lernen wir gerade die 2te Hürde kennen: Die Ausgabe des angesprungenen Terminals wird nicht auf dem Schirm dargestellt und ist somit nicht sichtbar – obwohl die Terminals als Prozesse faktisch aktiv sind und sogar auf Tastatureingaben reagieren. So ist ein Wechsel zum grafischen tty7 jederzeit durch CTRL ALT F7 oder durch ein Einloggen im Blindflug und anschließendes Tippen von “chvt 7” möglich.

Schritt 6: Prüfe die
Existenz des Moduls “uvesafb”
Wieder in unserer grafischen Umgebung angelangt, überzeugen wir uns davon, dass das Modul “uvesafb.ko” im Verzeichnis “/lib/modules/2.6.37.6-0.5-xen/kernel/drivers/video” vorhanden ist.

Opensuse’s XEN-Kernel ist zusammen mit diesem Modul kompiliert und installiert worden. Das Modul sollte also an seinem Platz zu finden sein. Wenn nicht, bleibt leider nichts anderes übrig, als selbst den Kernel zusammen mit diesem Modul neu zu konfigurieren, zu kompilieren und zu implementieren.

Schritt 7: Installation von “v86d”
“uvesafb” benötigt für seinen Einsatz zwingend den sogenannten Helper Daemon “v86d”. Dieser Daemon ermittelt Daten zum Framebuffer System der Grafikkarte und den Fähigkeiten des Schirms. Ohne “v86d” läuft “uvesafb” nicht !

Leider gibt es zu “v86d” kein geeignetes RPM-Paket, das sich unter Opensuse 11.4 installieren ließe. Zumindest habe ich keines gefunden.

Also müssen wir uns die Sourcecodes besorgen – und zwar von folgender Adresse:

http://dev.gentoo.org/~spock/projects/uvesafb/

Wir laden uns das Archiv “v86d0.1.10.tar.bz2” herunter und expandieren es in einem Verzeichnis unserer Wahl. Wir wechseln dorthin und führen dann die Stadardschritte “./configure” und “make” durch. “./configure” ergänzen wir dabei um die Option “–with-x86emu”.

Die Kompilation und das Linken sollten problemfrei vor sich gehen. Das resultierende Executable “v86d” kopieren wir dann als root in das Verzeichnis “/sbin/”.

Schritt 8: Identifizieren möglicher “uvesafb”-Modes”
Wir informieren uns über mögliche “uvesafb”-Modes durch Absetzen des Befehls

cat /sys/bus/platform/drivers/uvesafb/uvesafb.0/vbe_modes

an irgendeinem Pseudo-Terminal der grafischen Oberfläche.

Schritt 9: Konfigurationsdatei für das “uvesafb”-Modul
Als root erzeugen wir nun ein File “uvesafb.conf” im Verzeichnis “/etc/modprobe.d/”. Wir legen dann den künftig von uns gewünschten “uvesafb”-Modus für die TTYs – z.B. den Modus 1280×800-32 – fest, indem wir folgende Zeile in die Datei einfügen:

options uvesafb mode_option=1280×800-32 scroll=ywrap

Schritt 10: Eliminieren aller Vesa “vga”-Parameter aus der Bootloader-Konfiguration
Als nächstes ändern wir unsere Grub Bootloader-Konfiguration. Dazu könen wir Yast benutze oder aber die Konfigurationsdateien unter “/boot/grub” auch direkt editieren:

Wir eliminieren aus den Zeilen, die den Grub-Eintrag für das Booten des XEN-Kerels beschreiben, alle “vga”-Parameter – etwa “vga=mode-0xnnn” oder “vga=0xnnn”. “nnn” steht hier für den bei der Installation des SUSE-Systems festgelegten Standard VESA Framebuffer Modus für die TTYs.

Diese Entfernung der vga-Paramter ist ein sehr wichtiger Schritt: Die Vesa-Modes sind mit den “uvesafb”-Modes nicht kompatibel. Ein Starten der Standard-Vesa-Modes würde später ein erfolgreiches Laden des “uvesafb”-Moduls und ein Setzen des gewünschten “uvesafb”-Modus verhindern! Das Standard Vesa Setup ist nicht mit “uvesafb” verträglich !

Schritt 11: Erneutes Booten des XEN-Kernels und Laden des “uvesafb”-Moduls
Wir booten den XEN-Kernel erneut in den Runlevel 3. Da wir die vga-Optionen eliminiert haben, erschienen die Boot-Meldungen nun natürlich in der wenig ansehnlichen Terminal-Auflösung von 80×25 Spalten/Zeilen. Davon lassen wir uns aber nicht abschrecken, denn gleich werden wir unseren “uvesafb”-Modus anschalten.

Im Runlevel 3 loggen wir uns als root ein und versuchen dann, das “uvesafb”-Modul zu laden:

modprobe uvesafb

Das Terminal-Layout sollte sich nun deutlich zum Besseren ändern. Zur Sicherheit (oder im Fehlerfall zur Analyse) sehen wir uns nun die letzten Meldungen in “/var/log/messages” zum Laden des Moduls an. “uvesafb” sollte nicht nur geladen worden sein – der ”
v86d”-Daemon sollte relevante Information zur Vesa-Implementierung der Graka und zu Schirm verraten haben. Ferner sollte der Speicherpunkt für den Modus gesetzt worden sein.

May 20 17:24:50 xen kernel: [ 27.172094] uvesafb: NVIDIA Corporation, G92 Board – 03910050, Chip Rev , OEM: NVIDIA, VBE v3.0
May 20 17:24:50 xen kernel: [ 27.288417] uvesafb: VBIOS/hardware supports DDC2 transfers
May 20 17:24:50 xen kernel: [ 27.445892] uvesafb: monitor limits: vf = 75 Hz, hf = 94 kHz, clk = 210 MHz
May 20 17:24:50 xen kernel: [ 27.446342] uvesafb: scrolling: redraw
May 20 17:24:50 xen kernel: [ 27.838652] Console: switching to colour frame buffer device 160×64
May 20 17:24:50 xen kernel: [ 27.870389] uvesafb: framebuffer at 0xf7000000, mapped to 0xffffc90005980000, using 14336k, total 14336k
May 20 17:24:50 xen kernel: [ 27.870390] fb0: VESA VGA frame buffer device

Durch “CTRL ALT Fx” probieren wir nun, ob wir zwischen den TTYs tty1 bis tty6 hn und her wechseln können und das alle Terminals sich im gleichen “uvesafb”-Modus präsentieren.

Schritt 12: Wechsel zwischen der 3D-beschleunigten grafischen Oberfläche der Dom0 und den TTYs im Framebuffer-Modus
Abschließend starten wir nun den Runlevel 5, loggen uns in die grafische Desktop-Umgebung ein, die ja wegen des Nvidia-Treibers 3D-beschleunigt ist. Dort probieren jetzt einen Wechsel zu den anderen TTYs – z.B. zum Konsolen-Terminal tty1. Das sollte nun anstandslos klappen – der Output des Terminals tty1 muss sichtbar sein (im gewählten “uvesafb”-Modus). Auch eine Wechsel zurück zum tty7 sollte nun problemfrei funktionieren.

Damit haben wir unser Ziel erreicht. In der XEN Dom0 von Opensuse 11.4 läuft nun der prorietäre Nvidia-Treiber und verhilft uns zum Genuß einer grafischen Oberfläche mit 3D-Beschleunigung. Zudem können wir den uvesafb-Framebuffer-Modus unserer anderen TTYs über eine Konfigurationsdatei kontrollieren und wie gewohnt zwischen allen Terminals hin und her wechseln.

Bleibt nur noch, den Bootvorgang in den Runlevel 5 durch Manipulation entsprechender Startup-Skripts zu automatisieren. Wir müssen eigentlich nur dafür sorgen, dass das “uvesafb”-Modul vor dem Starten des X-Servers geladen wird. Das führen wir hier aber nicht weiter aus, sondern überlassen es dem Leser, das durch ein entsprechendes Skript unter /etc/init.d/rc5d hinzubekommen.

Nützliche Links:
https://wiki.archlinux.org/index.php/Uvesafb
http://dev.gentoo.org/~spock/projects/uvesafb/

Viel Spaß nun mit XEN und einer grafischen Desktopumgebung der Dom0, bei der auch 3D-Effekte und 3D-Programme hardware-beschleunigt laufen.

Opensuse 11.4 und KVM – Shutdown Problem

Posted on by

Habe mir neulich auf einem System (mit 3ware Raid 10 und LVM) KVM und die libvirt_Komponenten installiert, um verschiedene Dinge auf einem virtuellen System zu testen. Die Installation des KVM-Gastes (ein SLES-System) hat auch wunderbar geklappt.

Leider traten dann gehäuft Probleme nach dem Runterfahren des Opensuse 11.4 KVM-Hostes auf. Nicht immer, aber doch relativ häufig wurden nach einem Reboot Inkonsistenzen im Root-Filesystem gemeldet, die mit einem manuellen fsck-Lauf behoben werden konnten. Nach ersten Analysen scheint es unter Opensuse 11.4 beim shutdown ein Timing Problem mit dem Stoppen der libvirt-Prozesse zu geben – irgendwie laufen die bis zum bitteren Ende und verursachen Fehler.

Fakt ist jedenfalls, dass das Problem mit KVM und libvirt zusammenhängt. Nach einer Deinstallation von KVM und libvirt verschwinden die Probleme sofort und dauerhaft. Auf einem anderen System mit Opensuse 11.3 und demselben Raid-Controller treten die Probleme erst gar nicht auf …..

Habe bislang keine Lösung 🙁