Ubuntu Desktop 2023 VMs slow

LXD
1

Hello.

I see an odd behavior with Ubuntu Desktop VMs: version 23.10 and 23.04 start well after creation, but quickly they become unusable, like frozen. With release 22.04, all is ok: once started, the VM container displays the initial setup window (connect with an account, localization, etc) and can be used. With 23.04 and 23.10 I cannot used them.

I start all these VMs the same way:

lxc launch images:$IMG ubuntu --vm -c security.secureboot=false -c limits.cpu=4 -c limits.memory=4GiB --console=vga

$IMG being resp. ubuntu/22.04/desktop, ubuntu/23.04/desktop and ubuntu/23.10/desktop

My lxd version is 5.19, client and server. Images ids are the following, refreshed yesterday:

| u-2204 | e54f4ad921ee | no | Ubuntu jammy amd64 (20231025_07:42) | x86_64 | VIRTUAL-MACHINE | 961.54MiB | Oct 25, 2023 at 5:19pm (UTC) |
| u-2304 | ce11fb469512 | no | Ubuntu lunar amd64 (20231025_07:42) | x86_64 | VIRTUAL-MACHINE | 1111.53MiB | Oct 25, 2023 at 1:44pm (UTC) |
| u-2310 | 8dac65b1dec1 | no | Ubuntu mantic amd64 (20231025_07:42) | x86_64 | VIRTUAL-MACHINE | 1076.33MiB | Oct 25, 2023 at 1:57pm (UTC) |

Anyone observing the same issue or having a suggestion on what to do?

Guy

2

I am seeing the same issue, opted to install debian 12 base and trying to install a desktop now. I think I saw another thread mention this but on a much older ubuntu version

3

I ended having to reinstall my os and redo partitions on several drives. The reason for the issue is I had been using a btrfs pool is just as good as a zfs.

From the manual

Note
This issue is seen most often when using VMs on Btrfs, due to the random I/O nature of using raw disk image files on top of a Btrfs subvolume.

Therefore, you should never use VMs with Btrfs storage pools.

If you really need to use VMs with Btrfs storage pools, set the instance root disk’s size.state property to twice the size of the root disk’s size. This configuration allows all blocks in the disk image file to be rewritten without reaching the qgroup quota. The btrfs.mount_options=compress-force storage pool option can also avoid this scenario, because a side effect of enabling compression is to reduce the maximum extent size such that block rewrites don’t cause as much storage to be double-tracked. However, this is a storage pool option, and it therefore affects all volumes on the pool.