That’s interesting. images:ubuntu/21.04/cloud gives me 5.11.0-22-generic. So I could perhaps try the ubuntu:20.04 image, mounting it with nbd (say), chrooting and changing the kernel to generic, and see if that makes a difference.
If the -kvm kernel is the problem, then I see two possibilities.
- The
-kvmkernel is generally broken. But then I’d expect this issue to be seen in other virtualization frameworks (e.g. libvirt, proxmox, openstack, etc) - There’s something about the way that lxd invokes qemu/kvm which is different to the others and tickles this bug. For example, I notice that lxd starts it with some sandboxing options which I haven’t seen before; and there’s some virtiofsd stuff too.
root 21656 0.0 0.0 79884 3356 ? Ssl 19:10 0:00 /snap/lxd/20987/bin/virtiofsd --socket-path=/var/snap/lxd/common/lxd/logs/test2104/virtio-fs.config.sock -o source=/var/snap/lxd/common/lxd/virtual-machines/test2104/config.mount
lxd 21711 9.3 0.7 2869232 470080 ? Sl 19:10 0:11 /snap/lxd/20987/bin/qemu-system-x86_64 -S -name test2104 -uuid bc185073-c93f-4ef0-a8fa-05832d47f5cc -daemonize -cpu host -nographic -serial chardev:console -nodefaults -no-user-config -sandbox on,obsolete=deny,elevateprivileges=allow,spawn=deny,resourcecontrol=deny -readconfig /var/snap/lxd/common/lxd/logs/test2104/qemu.conf -spice unix=on,disable-ticketing=on,addr=/var/snap/lxd/common/lxd/logs/test2104/qemu.spice -pidfile /var/snap/lxd/common/lxd/logs/test2104/qemu.pid -D /var/snap/lxd/common/lxd/logs/test2104/qemu.log -smbios type=2,manufacturer=Canonical Ltd.,product=LXD -runas lxd
root 21713 0.0 0.0 2376108 13548 ? Sl 19:10 0:00 /snap/lxd/20987/bin/virtiofsd --socket-path=/var/snap/lxd/common/lxd/logs/test2104/virtio-fs.config.sock -o source=/var/snap/lxd/common/lxd/virtual-machines/test2104/config.mount