Oh, they do? That seems surprising given that the Canonical LXD image servers were just mirrors of https;//images.linuxcontainers.org
They do run their own image servers for Ubuntu images (https://cloud-images.ubuntu.com) but I never heard of them publishing other distro images.
Actually scratch that, I didn’t look properly 
We do still build VM images for Gentoo and those are definitely visible on the image server.
What we had to do is stop building them on arm64 because there were issues there.
stgraber@dakara:~$ incus image list images: os=Gentoo arch=amd64 type=virtual-machine
+-------------------------+--------------+--------+---------------------------------------+--------------+-----------------+------------+------------------------------+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCHITECTURE | TYPE | SIZE | UPLOAD DATE |
+-------------------------+--------------+--------+---------------------------------------+--------------+-----------------+------------+------------------------------+
| gentoo/openrc (3 more) | b8a1a8954046 | yes | Gentoo current amd64 (20231204_16:07) | x86_64 | VIRTUAL-MACHINE | 1051.33MiB | Dec 4, 2023 at 12:00am (UTC) |
+-------------------------+--------------+--------+---------------------------------------+--------------+-----------------+------------+------------------------------+
| gentoo/systemd (3 more) | de892682bbad | yes | Gentoo current amd64 (20231204_16:07) | x86_64 | VIRTUAL-MACHINE | 1031.74MiB | Dec 4, 2023 at 12:00am (UTC) |
+-------------------------+--------------+--------+---------------------------------------+--------------+-----------------+------------+------------------------------+
| | 3ec3dcc9cc80 | yes | Gentoo current amd64 (20231202_16:07) | x86_64 | VIRTUAL-MACHINE | 1031.84MiB | Dec 2, 2023 at 12:00am (UTC) |
+-------------------------+--------------+--------+---------------------------------------+--------------+-----------------+------------+------------------------------+
| | 377d2ba3b8a8 | yes | Gentoo current amd64 (20231203_16:07) | x86_64 | VIRTUAL-MACHINE | 994.74MiB | Dec 3, 2023 at 12:00am (UTC) |
+-------------------------+--------------+--------+---------------------------------------+--------------+-----------------+------------+------------------------------+
| | 3149cb6ee217 | yes | Gentoo current amd64 (20231203_16:07) | x86_64 | VIRTUAL-MACHINE | 1031.84MiB | Dec 3, 2023 at 12:00am (UTC) |
+-------------------------+--------------+--------+---------------------------------------+--------------+-----------------+------------+------------------------------+
| | e7d327ff0c04 | yes | Gentoo current amd64 (20231202_16:07) | x86_64 | VIRTUAL-MACHINE | 994.07MiB | Dec 2, 2023 at 12:00am (UTC) |
+-------------------------+--------------+--------+---------------------------------------+--------------+-----------------+------------+------------------------------+
So incus launch images:gentoo/openrc --vm or incus launch images:gentoo/systemd --vm should work just fine (may need -c security.secureboot=false though, I don’t recall if Gentoo has a signed bootloader).
I’ve tried
images:gentoo/current/amd64
images:gentoo/current/openrc
Drop the /current. Your previous syntax looks correct.
Indeed the vm images are also available on incus:
§ incus image list images:gentoo | grep VIRTUAL-MACHINE
| gentoo/openrc (3 more) | b8a1a8954046 | yes | Gentoo current amd64 (20231204_16:07) | x86_64 | VIRTUAL-MACHINE | 1051.33MiB | Dec 4, 2023 at 12:00am (UTC) |
| gentoo/systemd (3 more) | de892682bbad | yes | Gentoo current amd64 (20231204_16:07) | x86_64 | VIRTUAL-MACHINE | 1031.74MiB | Dec 4, 2023 at 12:00am (UTC) |
Explains why they are ALSO available on lxd servers then 
(may need
-c security.secureboot=falsethough, I don’t recall if Gentoo has a signed bootloader).
IIRC yes, you need this.
Added the vhost_vsock kernel module and now with the help of the correct image and the following command …
incus launch --profile p-test images:gentoo/openrc node-1 -c security.secureboot=false --vm
I am now receiving the following message.
Error: Failed to run: forklimits limit=memlock:unlimited:unlimited fd=3 fd=4 fd=5 -- /usr/bin/qemu-system-x86_64 -S -name node-1 -uuid 9427b300-cd6a-497f-ae10-2b690458e72b -daemonize -cpu host,hv_passthrough -nographic -serial chardev:console -nodefaults -no-user-config -sandbox on,obsolete=deny,elevateprivileges=allow,spawn=allow,resourcecontrol=deny -readconfig /var/log/incus/node-1/qemu.conf -spice unix=on,disable-ticketing=on,addr=/var/log/incus/node-1/qemu.spice -pidfile /var/log/incus/node-1/qemu.pid -D /var/log/incus/node-1/qemu.log -smbios type=2,manufacturer=LinuxContainers,product=Incus -runas nobody: qemu-system-x86_64: -spice: invalid option
: exit status 1
Additional thoughts? Is this saying it doesn’t like -spice?
Update:
$ qemu-system-x86_64 --version
QEMU emulator version 8.0.4
Yeah, looks like your local QEMU wasn’t built with spice support.
Very cool! After a handful of other USE flags, it appears I have a working installation. Thank you for your help.
Excellent!
Hey,
was there anything new outside the recommended use flags?
optfeature "virtual machine support" app-emulation/qemu[spice,usbredir,virtfs]
Also remember that for a graphical “console” (GUI apps) to work you’ll need either app-emulation/virt-viewer or net-misc/spice-gtk installed.
Here’s my package.use/qemu file.
app-emulation/qemu spice ncurses usb usbredir virtfs vhost-net
Probably not new, but if you want updates on the CLI, then ncurses is a good one to add. I added usb and vhost-net just in case.
This was just for qemu. There were a good number of kernel modules that I needed to add as well since I manually configure those.
Ah, the GVP. Planning on creating an Incus page in the Wiki?
Planning on creating an Incus page in the Wiki?
Of course, but since it’s a wiki, anyone can participate!
If an image here …
https://images.linuxcontainers.org/
… does not have cloud in the variant column, does that mean it does not have cloud-init support? I can’t seem to execute cloud-init status within a VM instance.
That’s correct, only the cloud variant has cloud-init installed.
I am trying to create a new image from an existing Gentoo image and just add cloud support to it.
https://linuxcontainers.org/incus/docs/main/howto/images_create/
My understanding is I should be able to create an instance using the image I want, start it, install cloud-init, stop it, publish it … and I should then be able to use the published image with cloud support for new instances that use would then consume my cloud-init sections.
Problem is, I keep running out of disk-space when compiling cloud-init and I think because this section in my profile is not working.
root:
path: /
pool: default
size: 30GB
type: disk
30GB really ought to be enough for a Gentoo image that just needs cloud support but I do see it’s needing rust which I know is big, but not sure how big, so I added 100GB.
tar: rust-1.71.1-x86_64-unknown-linux-gnu/rust-docs/share/doc/rust/html/core/arch/x86_64/fn._mm256_testn_epi16_mask.html: Cannot write: No space left on device
But again, I must be doing something wrong to allocate the required space. What am I missing?
With virtual machines, growing the root disk on the Incus side just grows the virtual disk, it doesn’t update the partition table or grow the individual partitions.
So you’re going to have to use growpart and resize2fs inside of the VM to actually grow the partition to match the larger disk (See df -h / for current sizing).