lxc/lxc-ci

Unable to shell to Almalinux Virtual-Machines

h0tw1r3 opened this issue · 5 comments

Looks like it is unable to mount the agent cd to install?

$ incus launch images:almalinux/9 --vm
Launching the instance
Instance name is: select-snapper
$ incus shell select-snapper
Error: VM agent isn't currently running
$ incus console select-snapper
To detach from the console, press: <ctrl>+a q

select-snapper login: root
Password:
[   23.182126] virtio-fs: tag <config> not found
[   23.183464] /dev/disk/by-id/scsi-0QEMU_QEMU_CD-ROM_incus_agent: Can't open blockdev

Last two lines repeat over and over.

Tested Ubuntu 22.04, worked fine.

images:rockylinux/8 doesn't display the Can't open blockdev message on the console, but has the same problem.

For reference:

$ dpkg -l | grep incus
ii  incus                                0.6-202402222335-debian12      amd64        Incus -  Container and virtualization daemon (container-only)
ii  incus-base                           0.6-202402222335-debian12      amd64        Incus -  Container and virtualization daemon (container-only)
ii  incus-client                         0.6-202402222335-debian12      amd64        Incus -  Command line client
ii  incus-ui-canonical                   0.6-202402222335-debian12      amd64        Incus - Web interface (canonical)

Host is Debian 12.

I'm writing lxd / incus support for Bolt, and use Incus with Terraform. This complicates things a bit. Seems like I will either need to keep track of the container images that require the profile versus the ones that don't, and if it's LXD or Incus.

@stgraber Is there any alternative design being considered?

Perhaps baking the incus-agent into all VM images? I realize it will become out of date quickly based on the current development activity, but without the agent all VM's without an appropriate kernel module are unusable - which also seems like a moving target, slow moving, but moving nonetheless. The agent could self-update on startup if it (or a minimal version thereof) was pre-installed.

We've added logic to Incus to automatically detect images that need the agent drive and return a clear startup error when that's the case.

That logic was added right after the 0.6 release.

An embedded agent is a bad idea as the host to agent API is internal and so can change between Incus versions. Shipping the newest agent would therefore mean not being and to run on an older Incus version. This would become a real problem with the upcoming Incus LTS release.

Additionally, that agent still wouldn't work as the other things that are accessed over 9p or the config drive are VM-specific cryptographic keys used for authentication. You can't prebake those in an image.

Now from a scripting standpoint you can look for image.restrictions.cdrom_agent with incus config get and if that's set to true, then you know you need to add the agent drive to have it work.

That relies on the image server setting the flag on affected images but ours does that now.