Hardreset Test -> VM = initramfs

X

Xyvran

Member
Oct 25, 2017
16
0
6
46
Hallo,

ich teste gerade die hard Reset Geschichte unter Proxmox, da bei uns es doch mal passiert das ein Server aus geht und falle auf die Nase:

Ich lasse eine VM laufen und starte von dort ein einfachen lese dd:
Code: 
dd if=/dev/vda1 of=/dev/null
So bald die VM am arbeiten ist, ziehe ich dem Proxmox den Stecker:
Code: 
echo b > /proc/sysrq-trigger

Danach kommt der Proxmox Server wunderbar wieder hoch und alles ist gut - bis auf, das die VM nicht mehr will. Ich komme maximal noch in den Grub rein und bekomme danach die Meldung:
Code: 
Fehler: Schreiben des Sektor 0xcd2890 nach >hd0< ist fehlgeschlagen.
Beliebige Taste...
Darauf folgenden nur noch:
Code: 
Buffer I/O error on dev vda1, logical block 524320, lost async page write
blk_update_request: I/O error, dev vda, sector 4196736
...

und lande dann natürlich bei:
Code: 
BusyBox v.21.1
...
(initramfs)

Getestet habe ich folgende Cache Optionen die alle das gleiche Problem brachten und bin auch der Meinung irgendwo gelesen zu haben, das no cache die richtige Variante wäre:
No Cache
Default (No cache)
Direct sync

VM Harddisk Controller habe ich folgende Varianten probiert: virtio + scsi

Das einzige was hilft an der Stelle ist nur noch ein Restore aus dem Backup mit einer neuen raw Disk.


Mein Aufbau:
Eigenständiges Ceph Cluster (losgelöst von Proxmox):
Auf einem Ceph Knoten:
Code: 
ceph status -v
ceph version 12.2.1 (3e7492b9ada8bdc9a5cd0feafd42fbca27f9c38e) luminous (stable)
Auf dem Proxmox Server:
Code: 
ceph status -v
ceph version 12.2.1 (1a629971a9bcaaae99e5539a3a43f800a297f267) luminous (stable)

Proxmox Host:
Code: 
proxmox-ve: 5.1-25 (running kernel: 4.13.4-1-pve)
pve-manager: 5.1-36 (running version: 5.1-36/131401db)
pve-kernel-4.13.4-1-pve: 4.13.4-25
pve-kernel-4.4.35-1-pve: 4.4.35-76
pve-kernel-4.10.17-3-pve: 4.10.17-23
libpve-http-server-perl: 2.0-6
lvm2: 2.02.168-pve6
corosync: 2.4.2-pve3
libqb0: 1.0.1-1
pve-cluster: 5.0-15
qemu-server: 5.0-17
pve-firmware: 2.0-3
libpve-common-perl: 5.0-20
libpve-guest-common-perl: 2.0-13
libpve-access-control: 5.0-7
libpve-storage-perl: 5.0-16
pve-libspice-server1: 0.12.8-3
vncterm: 1.5-2
pve-docs: 5.1-12
pve-qemu-kvm: 2.9.1-2
pve-container: 2.0-17
pve-firewall: 3.0-3
pve-ha-manager: 2.0-3
ksm-control-daemon: 1.2-2
glusterfs-client: 3.8.8-1
lxc-pve: 2.1.0-2
lxcfs: 2.0.7-pve4
criu: 2.11.1-1~bpo90
novnc-pve: 0.6-4
smartmontools: 6.5+svn4324-1
zfsutils-linux: 0.7.2-pve1~bpo90

RBD Device auf dem Proxmox:
KRBD: off

Ceph.conf
Code: 
[global]
fsid = xxx
mon_initial_members = cn1, cn2, cn3
mon_host = 10.2.2.21,10.2.2.22,10.2.2.23
auth_cluster_required = cephx
auth_service_required = cephx
auth_client_required = cephx
filestore_xattr_use_omap = true
public_network = 10.2.2.0/24
cluster_network = 192.168.104.0/24
debug asok = 0/0
debug auth = 0/0
debug buffer = 0/0
debug client = 0/0
debug context = 0/0
debug crush = 0/0
debug filer = 0/0
debug filestore = 0/0
debug finisher = 0/0
debug heartbeatmap = 0/0
debug journal = 0/0
debug journaler = 0/0
debug lockdep = 0/0
debug mds = 0/0
debug mds balancer = 0/0
debug mds locker = 0/0
debug mds log = 0/0
debug mds log expire = 0/0
debug mds migrator = 0/0
debug mon = 0/0
debug monc = 0/0
debug ms = 0/0
debug objclass = 0/0
debug objectcacher = 0/0
debug objecter = 0/0
debug optracker = 0/0
debug osd = 0/0
debug paxos = 0/0
debug perfcounter = 0/0
debug rados = 0/0
debug rbd = 0/0
debug rgw = 0/0
debug throttle = 0/0
debug timer = 0/0
debug tp = 0/0

[mon]
osd_pool_default_size = 3
mon_allow_pool_delete = false

[client]
rbd_cache = false

Hat jemand eine Idee, da eigentlich Blöcke unter ceph ja so nicht kaputt sein können oder!?
 
So wie der Zufall es will... ich habe eine anscheinend defekte VM auf einen NFS Datenspeicher gezogen und die VM konnte wieder starten. Beim online migrieren hatte mich folgende Meldung stutzig gemacht:
Code: 
create full clone of drive virtio0 (ceph-images:vm-159-disk-1)
Formatting '/mnt/pve/nfs-fshh7-proxmoxmigrate/images/159/vm-159-disk-1.raw', fmt=raw size=16106127360
drive mirror is starting for drive-virtio0
drive-virtio0: transferred: 0 bytes remaining: 16106127360 bytes total: 16106127360 bytes progression: 0.00 % busy: 1 ready: 0
...
drive-virtio0: transferred: 16106127360 bytes remaining: 0 bytes total: 16106127360 bytes progression: 100.00 % busy: 0 ready: 1
all mirroring jobs are ready
drive-virtio0: Completing block job...
drive-virtio0: Completed successfully.
drive-virtio0 : finished

2017-11-22 13:34:57.186291 7faf867fc700 -1 librbd::managed_lock::BreakRequest: 0x7faf74056f80 handle_blacklist: failed to blacklist lock owner: (13) Permission denied
2017-11-22 13:34:57.186308 7faf867fc700 -1 librbd::managed_lock::AcquireRequest: 0x7faf70000f30 handle_break_lock: failed to break lock : (13) Permission denied
2017-11-22 13:34:57.186333 7faf867fc700 -1 librbd::ManagedLock: 0x7faf74056200 handle_acquire_lock: failed to acquire exclusive lock:(13) Permission denied
2017-11-22 13:34:57.186346 7faf867fc700 -1 librbd::image::RemoveRequest: 0x564cf4844380 handle_exclusive_lock: cannot obtain exclusive lock - not removing
Removing image: 0% complete...failed.
rbd: error: image still has watchers
rbd rm 'vm-159-disk-1' error: rbd: error: image still has watchers
TASK OK

Sofort auf einem anderen Node folgendes eingegeben:
Code: 
rbd status proxmox-images/vm-159-disk-1
Watchers: none

Per Hand konnte ich das auch von einem anderen Node löschen:
Code: 
rbd rm proxmox-images/vm-159-disk-1
Removing image: 100% complete...done.

Gibt der rbd das Image nicht richtig frei (exclusive lock), wenn Proxmox hart ausgeschaltet wird? Theoretisch hätte doch ein Timeout genügen müssen, aber auch das hab ich ausgesessen! ;)

Hat da noch jemand eine Idee?
 
So etwas lässt einen ja nicht in Ruhe... vor allem nicht ruhig schlafen.

Aber ich führe das jetzt mal zum Ende:

Nach rumprobieren & co habe ich nun festgestellt, das doch ein Lock vorhanden war:
Code: 
rbd lock ls proxmox-images/vm-159-disk-1
There is 1 exclusive lock on this image.
Locker           ID                   Address
client.165132933 auto 140180086621696 10.1.100.102:0/922534539

Kurzerhand entfernt:
Code: 
rbd lock rm proxmox-images/vm-159-disk-1 auto\ 140180086621696 client.165132933

Und die VM fuhr wieder wie gewohnt hoch. So einfach kann es manchmal sein.

Jetzt stellt sich eigentlich nur noch eine Frage:
Warum löscht Proxmox sein eigenen Lock nicht mehr, wenn das Virt abgestürzt war? Im dem Fall bekomme ich die VM nicht mal im Cluster auf einen anderen Proxmox Node gezogen und kann die dort auch nicht anwerfen bevor der Lock weg ist (hab ich auch gerade getestet).
 
Xyvran said:
So etwas lässt einen ja nicht in Ruhe... vor allem nicht ruhig schlafen.

Aber ich führe das jetzt mal zum Ende:

Nach rumprobieren & co habe ich nun festgestellt, das doch ein Lock vorhanden war:
Code: 
rbd lock ls proxmox-images/vm-159-disk-1
There is 1 exclusive lock on this image.
Locker           ID                   Address
client.165132933 auto 140180086621696 10.1.100.102:0/922534539

Kurzerhand entfernt:
Code: 
rbd lock rm proxmox-images/vm-159-disk-1 auto\ 140180086621696 client.165132933

Und die VM fuhr wieder wie gewohnt hoch. So einfach kann es manchmal sein.

Jetzt stellt sich eigentlich nur noch eine Frage:
Warum löscht Proxmox sein eigenen Lock nicht mehr, wenn das Virt abgestürzt war? Im dem Fall bekomme ich die VM nicht mal im Cluster auf einen anderen Proxmox Node gezogen und kann die dort auch nicht anwerfen bevor der Lock weg ist (hab ich auch gerade getestet).
Click to expand...

das lock wird nicht von Proxmox angelegt, sondern von Ceph/librbd. sh. http://docs.ceph.com/docs/master/release-notes/#upgrade-from-jewel-or-kraken , eventuell sind die caps am key nicht richtig gesetzt?
 
You must log in or register to reply here.
Top Bottom