Ich bin ja gerade beim Upgraden diverser Seitensysteme (von Kunden wie im eigenen Netz) auf Opensuse Leap 42.2. Dabei kam mir auch ein unter KVM/qemu virtualisierter LAMP-Testserver unter Opensuse 12.3 unter die Finger. Beim Upgrade dieses KVM-Gastes waren zunächst die üblichen Hürden zu überwinden:
– Notwendige Abänderungen der Apache2-Konfiguration auf die aktuelle Syntax bzgl. des Zugangs zu Verzeichnissen (Wechsel zu Apache2-Versionen > 2.4)
– Manuelles Nacharbeiten des Upgrades der Mysql DB bzw. Maria DB zur Version 5.6 bzw. 10.0.30 mittels “mysql_upgrade -u root -p”.
Meldung zu lvmetad
Dann aber stolperte ich im Rahmen der Upgrades über eine mir bislang unbekannte Warnung im Zusammenhang mit der grub2-Konfiguration während der Upgrades:
/run/lvm/lvmetad.socket: connect failed: No such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
Das verhinderte zwar keinen Neustart der Zwischenversionen Opensuse 13.1, 13.2 Leap 42.1; aber sauber erschien mir das dann doch nicht. Ein manueller Test unter Leap 42.2 mittels “grub2-mkconfig -o /boot/grub2/grub.cfg” ergab dieselbe Meldung.
Was ist lvmetad?
lvm2-lvmetad ist offenbar ein Caching-Service für Metadaten (“central metadata cache”), die aus physikalischen Volumes [PV] einer LVM-Volume-Group ausgelesen werden. Siehe hierzu:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/metadatadaemon.html
Das Caching führt zu einer Beschleunigung der Ausführung von LVM bzw. LVM-Kommandos.
Dieser Service bzw. ein zugehöriger Socket sollten auf moderneren Opensuse-Systemen offenbar immer aktiviert sein. Ein Statuscheck auf von Scratch installierten Opensuse-Systemen der Versionen 13.1, 42.1, 42.2-Systemen ergab, dass diese Services/Sockets dort laufen – unabhängig davon, ob tatsächlich “Logical Volume Groups” und ” Logical Volumes [LV]” genutzt werden oder nicht.
Auf meinem alten 12.3-System waren die entsprechenden Services aber offenbar nicht aktiviert (“enabled”). (Oder aber der Upgrade hat da was verbockt.)
Dass ein laufender lvmetad-Dienst/Socket vorausgesetzt wird, gilt offenbar selbst dann, wenn das Opensuse-System – wie in meinem Fall – virtualisiert ist und selbst gar kein LV auf den vom Host per virtio-(blk)-Treiber durchgereichten Blockdevices nutzt (also auch kein sog. “nested” LVM für den Fall, dass das Blockdevice selbst auf einem LV des Hostes beruht).
Problemlösung: Aktivieren von lvmetad
Die Lösung war jedenfalls trivial; es half die Durchführung folgender Kommandos
systemctl enable lvm2-lvmetad.socket systemctl enable lvm2-lvmetad.service systemctl start lvm2-lvmetad.socket systemctl start lvm2-lvmetad.service
auf dem von OS 12.3 auf Leap 42.2 upgegradetem System. Ein “grub2-mkconfig -o /boot/grub2/grub.cfg” lief danach ohne jede Warnung oder Fehlermeldung durch.
Fühlbare Performance-Vorteile habe ich auf dem unter KVM virtualisierten System erwartungsgemäß nicht feststellen können; das nutzt zwar ein LV einer LVM Volume Group des KVM-Hostes als Raw-Device über virtio-(blk)-Treiber. In dieser Situation ist es viel wichtiger, dass lvmetad auf dem KVM-Host selbst läuft.