Removed limits.cpu in that gitlab instance, but it didn’t help.
Workaround is to never stop the virtual machine I guess 
Does this only occur with opensuse images?
Just tried lxc init images:ubuntu/22.04 ubuntuvm --vm and exactly the same behaviour with Ubuntu.
1 Like
So in a nutshell you can start and get into an instance vm once but after first stop it never starts again?
What storage pool type are you using? Can you try on a Dir pool?
Alpine Linux behaves in the same way as Ubuntu and SUSE.
Storage pool:
+---------+--------+------------------------------------+-------------+---------+---------+
| NAME | DRIVER | SOURCE | DESCRIPTION | USED BY | STATE |
+---------+--------+------------------------------------+-------------+---------+---------+
| default | btrfs | /var/lib/lxd/storage-pools/default | | 31 | CREATED |
+---------+--------+------------------------------------+-------------+---------+---------+
Gonna create dir pool and try with it
So in a nutshell you can start and get into an instance vm once but after first stop it never starts again?
Yes that’s what’s happening
OK, so I have created a dirpool
+---------+--------+------------------------------------+-------------+---------+---------+
| default | btrfs | /var/lib/lxd/storage-pools/default | | 30 | CREATED |
+---------+--------+------------------------------------+-------------+---------+---------+
| dirpool | dir | /var/lib/lxd/storage-pools/dirpool | | 0 | CREATED |
+---------+--------+------------------------------------+-------------+---------+---------+
Then I have created a virtual machine with lxc init images:opensuse/15.4 vmtest --vm --storage dirpool command.
lxc config show vmtest
architecture: x86_64
config:
image.architecture: amd64
image.description: Opensuse 15.4 amd64 (20221201_04:20)
image.os: Opensuse
image.release: "15.4"
image.serial: "20221201_04:20"
image.type: disk-kvm.img
image.variant: default
volatile.base_image: 10fdd5d67c4d6e3399a0cc3384d8213d77a9fbaf19addfc3e050f5a193a0427e
volatile.cloud-init.instance-id: 37b17f8d-0e30-4043-822f-06ec43aa0a9a
volatile.eth0.host_name: tapa93207a5
volatile.eth0.hwaddr: 00:16:3e:2b:3c:91
volatile.last_state.power: RUNNING
volatile.uuid: d73d8af8-e9d4-4dc2-a4db-62b2a63bbb7c
volatile.vsock_id: "116"
devices:
root:
path: /
pool: dirpool
type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""
Then as “usual” I have started (lxc start vmtest), verified that I can use shell (lxc shell vmtest), then (lxc stop vmtest) - it stops cleanly without a force. But when I tried lxc start vmtest --console then it won’t start just like with default pool with btrfs driver.
(I tried using another vm with new name vmtest2 to ensure it does not interfere with the remains of older vmtest, but it’s the same)
Update:
I’ve read logs and noticed that qemu packages were upgraded (7.1.0-5.1 → 7.1.0-6.1) the night before VMs became broken. I have booted to the snapshot before the upgrade and virtual machine instances work (the old gitlab one too!). So, I think it’s something with SUSE Tumbleweed qemu packages. It happens that I have another machine with SUSE Tumbleweed (but regular desktop - not a transactional server - this one I have to upgrade manually) I haven’t upgraded it yet, so I ensured everything works before the upgrade. Then I’ve upgraded packages. I made similar tests and yep the same thing started to happen after the upgrades!
Once again thank you Thomas for looking at this and please share any thoughts, especially if you think it’s something different. But probably I have to move with the issue to OpenSUSE forums…
WereCatf also thank you.
1 Like