After:
lxc image delete 98e43d
then rbd -p rbd-lxc-aa0.a1f mv image_98e43d99d83ef1e4d0b28a31fc98e01dd98a2dbace3870e51c5cb03ce908144b_ext4 bad_image_98e43d99d83ef1e4d0b28a31fc98e01dd98a2dbace3870e51c5cb03ce908144b_ext4
all is sorted again.
This is weird, so you’re effectively still getting some images without the filesystem in the name… this shouldn’t be possible so I’m really wondering what’s triggering that.
If you happen onto some kind of reproducer for this, let me know and we’ll get this sorted.
Will definitely let you know if we can end up narrowing down a way to reproduce.
Also - lxc list takes a lot longer to reply than it used to - any ideas what could’ve changed?
Hmm, I can’t think of anything obvious that we’d have changed.
Is lxc list --fast similarly slow?
That is appropriately fast.
Oh, we’ve recently filled one gap in the Ceph support, the container state now includes the disk usage. For running containers, that’s pulled directly from the filesystem so should be near instant, but for stopped containers, this involves rbd du which isn’t always the fastest. I wonder if that’s the source of the issue here.