TASK ERROR: rbd error: rbd: listing images failed: (2) No such file or directory

[Greg.Davis]

First time poster so apologies if I miss critical info for ya!

I am receiving the error in the subject in a production environment. The error ONLY affects destruction of machines and doesn't appear to be hindering migration like many of the other forum posts have stated. I've tried resolutions from other posts and haven't had any success thus far. Additionally, my knowledge regarding keyrings isn't perfect and it sounds like the issue may revolve around that.

Quick background on the environment and what triggered this change:

Two weeks I upgraded our production environment from pve5.4 to pve6 following the documentation as well as ironing out potential issues before they arrived.
The upgrade went fine. Last week into this morning I stood up two new nodes and added them to the cluster, again, no complaints from CEPH or Proxmox. I received a request to take a handful of VMs offline as they're no longer needed and when I went to destroy only the first would succeed with the others throwing the error below:

trying to acquire cfs lock 'storage-ceph-vm' ...
Could not remove disk 'ceph-vm:vm-126-disk-0', check manually: error with cfs lock 'storage-ceph-vm': got lock request timeout
TASK ERROR: rbd error: rbd: listing images failed: (2) No such file or directory

Am I mistaken that I should be able to use the GUI to Destroy VMs down a line without waiting for the previous one to finish or can Proxmox only Destroy one at a time? In the past I thought I was able to Destroy multiple.

Thank you!

 

[t.lamprecht]

Am I mistaken that I should be able to use the GUI to Destroy VMs down a line without waiting for the previous one to finish or can Proxmox only Destroy one at a time? In the past I thought I was able to Destroy multiple.

That's a limitation I wanted to fix since quite a bit, but came not yet around to. :/ Currently we lock the whole storage, but it would be enough if we reduce the lock to a "VMID" granularity. This enhancement request is tracked under:
https://bugzilla.proxmox.com/show_bug.cgi?id=1962

 

[Greg.Davis]

That's a limitation I wanted to fix since quite a bit, but came not yet around to. :/ Currently we lock the whole storage, but it would be enough if we reduce the lock to a "VMID" granularity. This enhancement request is tracked under:
https://bugzilla.proxmox.com/show_bug.cgi?id=1962

This is good to know! I thought I was going crazy. At least a bulk Destroy option that queues up VMs for destruction would be nice!

Otherwise I guess

qm destroy {id} && qm destroy {id+}...

Will do the trick

 

[t.lamprecht]

Yes, that will do it, can also use a loop:

for vmid in 101 103 104 10212 <other IDs...>; do echo "destroying $vmid"; qm destroy "$vmid"; done

Just ensure that the VMIDs are really those you want to destroy!

 

[dawei]

That's a limitation I wanted to fix since quite a bit, but came not yet around to. :/ Currently we lock the whole storage, but it would be enough if we reduce the lock to a "VMID" granularity. This enhancement request is tracked under:
https://bugzilla.proxmox.com/show_bug.cgi?id=1962

Hello, I have the same problem now. Can you tell me whether this problem is fixed in the latest version?

 

[t.lamprecht]

Hello, I have the same problem now. Can you tell me whether this problem is fixed in the latest version?

No, else the linked bugzilla entry would reflect that.

 

[dawei]

不，否则链接的 bugzilla 条目会反映这一点。

OK, thank you very much for your reply. Next, I will continue to wait。