Wiederherstellen eines Images aus ceph-RBD-Storage

[frb@artegic]

Hallo community,

folgendes Problem hat mich heute getroffen, bei dem Ihr mir vielleicht helfen könnt. Wenn Informationen fehlen, bitte gerne fragen

Kurz:

Bei der Erweiterung ( Resize ) einer virtuellen Festplatte ( 256GByte -> 512GByte ) über die GUI (ProxMox VE 5.4-10) wurde das Image (KVM raw-Disk) nach einem TImeout-Fehler auf "0 Byte" Größe gesetzt. Das ganze spielte sich auf einem ceph-RBD(PVE)-Storage ab.

Lang:

Wir setzen CentOS7-KVM-VMs ein, mit getrennter root und Daten-Partition. Im vorliegenden Fall wird die VM als mysql-Server genutzt. Die Datenpartition war zum Zeitpunkt des Fehlers 256GByte groß, Partitioniert mit LVM mit einem 50%-LogicalVolume (Platz für Snapshots). Dieses Image wollte ich heute nach einem erprobten Verfahren erweitern. Wir erweitern dabei die Virtuelle Platte via GUI, danach das LVM. So schon hunderte male durchgeführt, ohne Probleme. Heute kam es nun zu einem "timeout"-Fehler, beim Klicken auf OK des "Resize-Dialogs". Im folgenden passierte das dies hier (Auszug Node-Message-Log)

Apr 09 16:12:02 pmve-1901 kernel: Key type ceph registered
Apr 09 16:12:02 pmve-1901 kernel: libceph: loaded (mon/osd proto 15/24)
Apr 09 16:12:02 pmve-1901 kernel: rbd: loaded (major 252)
Apr 09 16:12:02 pmve-1901 kernel: libceph: mon1 10.30.24.12:6789 session established
Apr 09 16:12:02 pmve-1901 kernel: libceph: client198542104 fsid 429ebb4b-db4a-42d2-b3ea-ef1c6894b48f
Apr 09 16:12:02 pmve-1901 kernel:  rbd0: p1
Apr 09 16:12:02 pmve-1901 kernel: rbd: rbd0: capacity 274877906944 features 0x1
Apr 09 16:12:02 pmve-1901 pvedaemon[682925]: <frb@artegic.local> update VM 278: resize --disk scsi1 --size +256G
Apr 09 16:12:02 pmve-1901 kernel: rbd0: detected capacity change from 274877906944 to 549755813888
Apr 09 16:12:05 pmve-1901 pvedaemon[682925]: VM 278 qmp command failed - VM 278 qmp command 'block_resize' failed - got timeout
Apr 09 16:12:47 pmve-1901 kernel: rbd0: detected capacity change from 549755813888 to 0

Gleichzeitig ging das Filesystem der Partition in der VM auf "ReadOnly", der mysqld beendete sich.

In der Hoffnung eines kleinen Problems wurde die VM neu gestartet, dabei wurde schon das Image der Virtuellen Platte nicht mehr der VM bekannt gemacht. Die Fehlermeldung lautete immer

Apr  9 16:12:47 aspdb-nr165 kernel: : [9604909.811582] sd 2:0:0:1: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr  9 16:12:47 aspdb-nr165 kernel: : [9604909.811590] sd 2:0:0:1: [sdb] Sense Key : Not Ready [current]

Ein Blick in den Storage über die GUI zeigt, das auch dort das IMAGE mit 0Byte angezeigt wird.

Gibt es noch Hoffnung an die Daten des Image zu kommen?

Viele Grüße
Frank Bach

 

[CoolTux]

Du kannst eine neue virtuelle Platte anlegen und dann ein Restore durch führen. Damit solltest Du wieder den aktuellen Stand haben.
Das alte Platte so denke ich wird wohl verloren sein. Oder war die separate Platte mit im Backup?

 

[frb@artegic]

Ja die ist im Backup. Den Restore lasse ich gerade laufen. Die Frage ist, ob ich auf das Image, was durch den TimeOut auf "0Bytes" gestetz wurde, nochmal irgendwie zugreifen kann, um den Gap von der Datensicherung bis eben zu überbrücken. Habe einfach gehofft das es "nur" ein Fehler in den MetaDaten oder so ist, aber scheint nicht so zu sein. Trotzdem danke für Deine Antwort.

Wenn sonst noch jemand eine Idee hat.....

 

[Alwin]

Wenn Du eine Wiederherstellung mit der selben VMID gemacht hast, dann wurden die RBD Images bereits gelöscht.

Apr 09 16:12:47 pmve-1901 kernel: rbd0: detected capacity change from 549755813888 to 0

Hm, das sollte eigentlich nicht passieren. Welche pveversion -v läuft auf dem Cluster?

EDIT: Und wie ist die VM konfiguriert, qm config <vmid>?

 

[frb@artegic]

Hallo Alwin,

es hat bisher auch "Hunderte male" ohne Fehler funktioniert, weswegen wir ja so irritiert waren. Wir haben kein Recovery der gesamten VM durchgeführt, sondern die Datenbank-Partition (Virtuelle Disk) neu erstellt und den mysql-Server (bzw. die Datenbanken) darauf aus einem Backup wiederhergestellt.

Hier die von die gewünschten Infos:

# pveversion -v

proxmox-ve: 5.4-2 (running kernel: 4.15.18-17-pve)
pve-manager: 5.4-10 (running version: 5.4-10/9603c337)
pve-kernel-4.15: 5.4-5
pve-kernel-4.15.18-17-pve: 4.15.18-43
pve-kernel-4.13.4-1-pve: 4.13.4-26
pve-kernel-4.10.17-2-pve: 4.10.17-20
ceph: 12.2.12-pve1
corosync: 2.4.4-pve1
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.1-11
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-53
libpve-guest-common-perl: 2.0-20
libpve-http-server-perl: 2.0-13
libpve-storage-perl: 5.0-44
libqb0: 1.0.3-1~bpo9
lvm2: 2.02.168-pve6
lxc-pve: 3.1.0-3
lxcfs: 3.0.3-pve1
novnc-pve: 1.0.0-3
proxmox-widget-toolkit: 1.0-28
pve-cluster: 5.0-37
pve-container: 2.0-39
pve-docs: 5.4-2
pve-edk2-firmware: 1.20190312-1
pve-firewall: 3.0-22
pve-firmware: 2.0-6
pve-ha-manager: 2.0-9
pve-i18n: 1.1-4
pve-libspice-server1: 0.14.1-2
pve-qemu-kvm: 3.0.1-4
pve-xtermjs: 3.12.0-1
qemu-server: 5.0-54
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.13-pve1~bpo2

# qm config 278

agent: 1
bootdisk: scsi0
cores: 8
cpu: Skylake-Client
hotplug: disk,network,usb,memory,cpu
memory: 40960
name: aspdb-nr165
net0: virtio=DE:AD:0A:1F:02:06,bridge=vmbr0
net1: virtio=2A:29:40:D2:ED:6E,bridge=vmbr1
net2: virtio=DE:AD:0A:1E:02:06,bridge=vmbr2
numa: 1
ostype: l26
scsi0: Prod660:vm-278-disk-1,discard=on,size=16G
scsi1: Prod660:vm-278-disk-0,discard=on,size=512G
scsi9: none,media=cdrom
scsihw: virtio-scsi-pci
smbios1: uuid=6f16aaa8-3fd2-4342-87de-4c54318bf1db
sockets: 2
unused0: Prod660:vm-278-data-aspdb-nr165
vcpus: 16

Viele Grüße
Frank

 

[Alwin]

proxmox-ve: 5.4-2 (running kernel: 4.15.18-17-pve)

Proxmox VE 5.4 geht im Juli 2020 EoL. Bitte auf PVE 6 aktualisieren.

unused0: Prod660:vm-278-data-aspdb-nr165

Es schein noch eine Disk zu geben. Diese kann per editieren wieder eingehängt werden.

 

[frb@artegic]

Hallo,
ja, Upgrade ist schon in Planung. Und ja, die Disk ist noch da, aber eben 0 Byte groß. Genau das war/ist ja das Problem gewesen. Auch nach (wieder-)einhängen kann man nicht auf die Daten zugreifen.
Viele Grüße
Frank

 

[Alwin]

a, Upgrade ist schon in Planung. Und ja, die Disk ist noch da, aber eben 0 Byte groß. Genau das war/ist ja das Problem gewesen. Auch nach (wieder-)einhängen kann man nicht auf die Daten zugreifen.

Wenn das RBD Image (rbd info <pool>/<image>) selbst 0 Byte gross ist, dann gibt's wirklich nix mehr zum zugreifen. :/

 

[frb@artegic]

Ich habe von so einem Problem ( Disk Resize - Timeout - Disk 0 Byte ) nur im Zusammenhang mit KRBD gelesen - das haben wir aber nicht aktiv auf dem Storage ( bzw. nirgendwo überhaupt ).
Ist auch nicht mehr "akut" ein Problem, wir wüssten nur gerne, ob wir etwas dagegen tun können, um zu vermeiden, das es wieder auftritt.

 

[Alwin]

Apr 09 16:12:02 pmve-1901 kernel: rbd0: p1

Aber das war ein KRBD gemountetes Image.

 

[frb@artegic]

Hallo Alwin,
ähm... es ist aber nirgends der Haken gesetzt in den Storages? Gibt es eine Möglichkeit nachzuschauen, ob noch weitere Images "falsch" gemounted sind? Das macht mir gerade etwas Angst...
Danke
Frank

 

[Alwin]

Wenn das KRBD auf dem Storage nicht gesetzt ist, alle VMs von der Node migrieren. Bei der Migration oder beim Shutdown -> Start wird erst eine neue Instanz gestartet.

 

[antondollmaier]

Hallo zusammen,

sorry, dass ich den alten Thread nochmal aufwärme.

Uns hat es jetzt auch erwischt - zwei Mal, auf unterschiedlichen VMs, mit identischem Vorgehen, bei einem "routinemäßigen" Upgrade der VM über das Webinterface.

• Hardware bearbeiten, mehr CPUs hinzufügen (Anzahl Cores ändern)
• Hardware bearbeiten, mehr RAM hinzufügen (MB RAM ändern)
• Disk (ceph rbd image) vergrößern

Beim Vergrößern "hängt" dann das Interface. Anschließend ist das RBD Image 0 Byte groß und die Daten schlichtweg - weg. Keine Rohdaten mehr da, nichts.

Es ist krbd für den Ceph Storage aktiv. Aktuellste Versionen (pve 6.4-8, ceph 15.2.11).

Wir entfernen krbd jetzt (Konfiguration des Storages anpassen und alle VMs, die bei "rbd showmapped" aufgeführt sind, migrieren reicht ja) und hoffen, dass das nicht mehr auftritt.