KVM mit LVM auf U16.04: LVM Volumens für VMs gehen "read-only"

[Maxim Webster]

Moin,

ich habe ein anhaltendes Problem mit KVM und LVM, dem ich nicht wirklich auf die Schliche komme:

Ich hab einen HP N54L mit 8GB speicher und 2x2TB im Linux md-raid 1 . Das Host-Linux (Ubuntu 16.04) läuft auf einer dedizierten SSD, auf den HDDs laufen bis zu 4 kleinere VMs (Linux KVM), ebenfalls mit Ubuntu als OS. Jeder VM ist ihr eigenes LVM Logical Volume zugegewiesen.

Die VMs haben echt nix zu tun (persönlicher Minecraft-Server, Zabbix Monitor Host, OpenHAB Heimautomation und Samba/DLNA Datei- und Medienserver). Entsprechend niedrig ist die CPU-Last des Hosts. Aber - ich bekomme von Zabbix immer wieder Meldungen, daß Disk/IO zu hoch sei ("CPU iowait time (host:system.cpu.util[,iowait]): 50.65 %"). Und es kommt sogar vereinzelt vor, daß (darum?) die LVMs einzelner VMs vom Kernel auf read-only geschaltet werden. Bemerkt wird das in der Regel erst abends, wenn die Bude außen dunkel bleibt, weil die OpenHAB VM keine Events mehr ins Protokoll schreiben kann.

Wie kann ich dem Problem auf die Schliche kommen oder es sogar verhindern? Die Log-Files der VMs enden natürlich mit der Schaltung auf read-only und das kern.log des Hosts ist nicht sehr hilfreich. Manchmal gibt es einen zeitlichen Bezug zu einer Aktion (z.B. OS Update in einer VM), manchmal kommen die Meldungen abseits jeder Nutzung.

Gruß

Maxim

[Sven Hartge]

Post by Maxim Webster
Wie kann ich dem Problem auf die Schliche kommen oder es sogar
verhindern? Die Log-Files der VMs enden natürlich mit der Schaltung
auf read-only und das kern.log des Hosts ist nicht sehr hilfreich.

Dann lass den syslog (rsyslog) remote auf den Host loggen, dann hast du
diese Informationen noch da.

Allerdings muss ich sagen, dass ich es in meinem bisherigen Leben noch
nie gesehen habe, dass der Kernel ein LV wg. IO-Rate auf ReadOnly
stellt.

S°

[kay]

Post by Sven Hartge

Post by Maxim Webster
Wie kann ich dem Problem auf die Schliche kommen oder es sogar
verhindern? Die Log-Files der VMs enden natürlich mit der Schaltung
auf read-only und das kern.log des Hosts ist nicht sehr hilfreich.

Allerdings muss ich sagen, dass ich es in meinem bisherigen Leben noch
nie gesehen habe, dass der Kernel ein LV wg. IO-Rate auf ReadOnly
stellt.

Ich benutze Proxmox VE der auch LVM benutzt und da ist mir das; soweit
ich weiß; auch noch nicht passiert. Allerdings sind die LVs dort als
eine Gruppe für alle VMs eingerichtet. Evtl. macht das einen unterschied.

Oder der embedded Raid0/1 Controller des N54L (lt. Specs) funkt
dazwischen....

Ich wusste auch nicht mal das LVM so was (read-only wenn zu viele
IOwaits) kann. Ich dachte so was passierte bestenfalls nach einem crash
bis zum journal-update. Was dann aber eher am filesystem läge und nicht
am LVM selbst. Oder?

Vielleicht dann doch ein Zusammenhang mit "ein LV pro VM"?

Post by Sven Hartge
Dann lass den syslog (rsyslog) remote auf den Host loggen, dann hast >

du diese Informationen noch da.

Interessante Idee, das sollte ich hier evtl. auch mal antesten, den
vm-host als syslog-server zu benutzen.

Kay

[Maxim Webster]

Post by kay
Ich benutze Proxmox VE der auch LVM benutzt und da ist mir das; soweit
ich weiß; auch noch nicht passiert. Allerdings sind die LVs dort als
eine Gruppe für alle VMs eingerichtet. Evtl. macht das einen unterschied.

Was heisst das? Ich hab eine Volume Group auf einem Physical Volume (/dev/md0). Und diese Volume Group ist kvm / libvirt bekannt gegeben. Abseits von KVM kommt kein LVM zum Einsatz, das OS des Hosts ist auf einer dedizierten Platte.

Post by kay
Oder der embedded Raid0/1 Controller des N54L (lt. Specs) funkt
dazwischen....

Vielleicht, aber die RAID Funktion ist im Bios deaktivert. Außerdem: Mindestens eine VM ist niemals von dem Problem betroffen, andere sind häufig oder selten betroffen.

Post by kay

Post by Sven Hartge
Dann lass den syslog (rsyslog) remote auf den Host loggen, dann hast >

du diese Informationen noch da.
Interessante Idee, das sollte ich hier evtl. auch mal antesten, den
vm-host als syslog-server zu benutzen.

"Testen" ist das richtige Work, ich bin froh, daß ich KVM hinbekommen habe.

Gruß

Maxim

[kay]

Post by Maxim Webster

Post by kay
Ich benutze Proxmox VE der auch LVM benutzt und da ist mir das;
soweit ich weiß; auch noch nicht passiert. Allerdings sind die LVs
dort als eine Gruppe für alle VMs eingerichtet. Evtl. macht das
einen unterschied.

Was heisst das? Ich hab eine Volume Group auf einem Physical Volume
(/dev/md0). Und diese Volume Group ist kvm / libvirt bekannt gegeben.
Abseits von KVM kommt kein LVM zum Einsatz, das OS des Hosts ist auf
einer dedizierten Platte.

Ich weiß nicht was du damit meinst eine VG dem KVM "bekannt" gegeben zu
haben. Aber vielleicht hilft dir dies hier weiter. So sieht das bei mir aus.

***@pve:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
fd0 2:0 1 4K 0 disk
sr0 11:0 1 1024M 0 rom
cciss!c0d0 104:0 0 33,9G 0 disk
├─cciss!c0d0p1 104:1 0 1007K 0 part
├─cciss!c0d0p2 104:2 0 127M 0 part
└─cciss!c0d0p3 104:3 0 33,8G 0 part
├─pve-root 251:0 0 8,3G 0 lvm /
├─pve-swap 251:1 0 4,1G 0 lvm [SWAP]
├─pve-data_tmeta 251:2 0 20M 0 lvm
│ └─pve-data-tpool 251:4 0 17,3G 0 lvm
│ ├─pve-data 251:5 0 17,3G 0 lvm
│ ├─pve-vm--100--disk--2 251:6 0 1G 0 lvm
│ ├─pve-vm--210--disk--1 251:7 0 2G 0 lvm
│ ├─pve-vm--101--disk--1 251:8 0 2G 0 lvm
│ └─pve-vm--211--disk--1 251:9 0 2G 0 lvm
└─pve-data_tdata 251:3 0 17,3G 0 lvm
└─pve-data-tpool 251:4 0 17,3G 0 lvm
├─pve-data 251:5 0 17,3G 0 lvm
├─pve-vm--100--disk--2 251:6 0 1G 0 lvm
├─pve-vm--210--disk--1 251:7 0 2G 0 lvm
├─pve-vm--101--disk--1 251:8 0 2G 0 lvm
└─pve-vm--211--disk--1 251:9 0 2G 0 lvm
cciss!c0d1 104:16 0 136,7G 0 disk /storage

Die pve-vm--xxx-disk-y sind die derzeit laufenden VMs.
Das wird alles von ProxMox gemanaged über die webUI und ich habe daran
nichts verändert, es läuft einfach und stabil.

Allerdings auf einem Proliant DL360G5 mit HW-Raid (2*2Disks)

Post by Maxim Webster
Mindestens eine VM ist niemals von dem Problem betroffen, andere sind
häufig oder selten betroffen.

Du meinst, wenn das Problem auftritt, dann ist immer eine VM dabei bei
der das NICHT auftritt? Könnte es möglich sein das genau DIE das Problem
bei den anderen Produziert - selbst aber nicht betroffen ist?

Post by Maxim Webster

Post by kay
Interessante Idee, das sollte ich hier evtl. auch mal antesten,
den vm-host als syslog-server zu benutzen.

"Testen" ist das richtige Work, ich bin froh, daß ich KVM hinbekommen habe.

Ich habe bei disesm Server auch kurz überlegt ob ich das händisch machen
will, aber das kann ich immer noch. Ich hab dann von Proxmox gehört, es
testweise installiert und es läuft bis jetzt völlig problemlos. Darum
bleibe ich erst mal dabei. Auch weil ich keine Lust auf das Gebastel
hatte. ProxMox war out-of-the-box schnell installiert, lässt sich; dank
debian-unterbau; leicht erweitern und die WebUI ist praktisch, zeigt
sogar die konsolen der VMs. Nur im Grafikmodus zickt der cursor oft mal
daneben und ist doppelt und verschoben. Geht aber auch so.

Kay

[Maxim Webster]

Post by Sven Hartge
Allerdings muss ich sagen, dass ich es in meinem bisherigen Leben noch
nie gesehen habe, dass der Kernel ein LV wg. IO-Rate auf ReadOnly
stellt.

Fallen Dir denn andere Gründe ein, warum das LV auf read-only gehen könnte? Filesystem und Raid sind beide nicht betroffen, es ist das Logical Volume.

Gruß

Maxim

[Sven Hartge]

Post by Maxim Webster

Post by Sven Hartge
Allerdings muss ich sagen, dass ich es in meinem bisherigen Leben
noch nie gesehen habe, dass der Kernel ein LV wg. IO-Rate auf
ReadOnly stellt.

Fallen Dir denn andere Gründe ein, warum das LV auf read-only gehen
könnte? Filesystem und Raid sind beide nicht betroffen, es ist das
Logical Volume.

*Was* _genau_ ist denn *wo* read-only?

Setzt der Gast-Kernel sein Dateisystem auf dem virtuellen Datenträger
Read-Only? Oder was passiert?

Zeig mal Logs, mach mal mehr Angaben.

S°

[Maxim Webster]

Seit meinem initialen Post ist es natürlich nicht wieder aufgetreten. Die VM welche am häufigsten mit dem Problem zu kämpfen hatte wurde inzwischen auf einen Raspberry verlegt, andere, seltener betroffene arbeiten im Moment einwandfrei.

Sollte das Problem wieder auftreten, wühle ich mich erstmal durch die Logs.