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 !