Am Fr., 23. Apr. 2021 um 11:52 Uhr schrieb Ilya Dryomov <idryomov@xxxxxxxxx >: > > This snippet confirms my suspicion. Unfortunately without a verbose > log from that VM from three days ago (i.e. when it got into this state) > it's hard to tell what exactly went wrong. > > The problem is that the VM doesn't consider itself to be the rightful > owner of the lock and so when "rbd snap create" requests the lock from > it in order to make a snapshot, the VM just ignores the request because > even though it owns the lock, its record appears to be of sync. > > I'd suggest to kick it by restarting osd36. If the VM is active, it > should reacquire the lock and hopefully update its internal record as > expected. If "rbd snap create" still hangs after that, it would mean > that we have a reproducer and can gather logs on the VM side. > > What version of qemu/librbd and ceph is in use (both on the VM side and > on the side you are running "rbd snap create"? > > I just stopped the OSD, waited some seconds and started it again. I still can't create snapshots. Ceph version is 14.2.18 accross the board qemu is 4.1.0-1 as we use krbd, the kernel version is 5.2.9-arch1-1-ARCH How can I gather more logs to debug it? -- Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im groüen Saal. _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |