We have now landed enough of @monstermunchkin’s VM work into distrobuilder to allow for building an initial set of images.
Currently that’s just Ubuntu x86_64 images for xenial, bionic, eoan and focal in both normal and cloud variants.
Those images are slightly smaller than the existing ones from the ubuntu: remote and do have the LXD agent loading units pre-baked, so no need for cloud-init, ssh, … You can just launch them and use them with lxc exec (after letting it boot for a few seconds).
We will be following this work with aarch64 images shortly and have initial work done to add both Debian and Fedora images to the mix. We will then follow with the rest of the distributions.
For the normal variant, you’ll notice that the hostname isn’t quite right and needs manual fixing. This will be resolved by us adding proper support for file templating in virtual machines at the LXD layer. We’re expecting LXD 3.22 to support that properly.
Actually, in the context of LXD, the lxc tool stands for LXD client (yes, confusing but I didn’t pick those names).
lxv has been suggested before but it would likely cause more confusion than clear any. Everything with VMs behaves the same as with containers and can usually be shared between the two.
So if we had lxc and lxv, it may feel quite odd that every command, except for init and launch behave and produce the exact same output. Creating a profile with one would be visible in the other for example, despite the two different commands giving the impression that you’re dealing with a completely different set of objects.
You’ll notice that secureboot is getting disabled here. That’s because proper signing of arm64 UEFI images is still pretty new and apparently buggy. Some Ubuntu releases have it enabled but we’ve been seeing issues with grub trying to boot the signed kernel.
All the images on the images: remote will have the LXD agent loader units baked in.
The images you can get from ubuntu: and ubuntu-daily: are somewhat outside of our control and currently do not have the agent loader units integrated. I submitted a package for lxd-agent-loader to Ubuntu and should that be included and approved by the security team, we’ll eventually get all Ubuntu images on those two remotes to behave too.
Note that the following require secureboot be disabled (security.secureboot=false):
archlinux
debian/8 and debian/8/cloud
debian/9 and debian/9/cloud
Additionally, opensuse has an annoying prompt on first boot on the console for secureboot.
So you either need to handle that prompt or also disable secureboot for those.
what are the difference between the standard image and the cloud image… on the standard image I had to manually edit /etc/hostname on the cloud-image I didn’t. what is the purpose of having the non cloud image?
Any tutorial/ hints on how to use th cloud image and specify a bigger/custom HDD size for the root partition?
Now… I know this is out of the scope for LXC/LXD team… but MAAS has made some changes from what the called “PODS” into now they are called “KVM HOSTS” and you can create a KVM VM within MAAS.
Any ideas if their roadmap is aligned with LXD/LXC for the ability of creating containers from MAAS ? it seems they are pushing a lot these PODS/KVM but for containers there is only a container tab. but they treat them as “DEVICES” so when I click on a container that is registered on the DNS under any domain, it fails (already sumbitted the bug in MAAS<
It seems there is no one interested in seen CONTAINERS properly integrated with MAAS). only for juju integration…
If you are pushing towards managing KVMs under LXD, should other Ubuntu teams try to align with a similar goal? (I know it is not directly in your hands, but maybe you can push more than a nobody like me asking for feature requests that no one is interested in)
Thanks and sorry for the wining… I love command line… but I have been having trouble evangelizing LXC/LXD to people used to Citrix/VMWare and even virt-manager users…
The hostname thing will be fixed when using LXD 3.22.
The cloud images have cloud-init pre-installed which runs a wide variety of things on boot, including generating the hostname file which is why you didn’t see the issue with that image.
As for MAAS, I don’t believe there is any plan on creating containers through it at this time. The current focus is on getting MAAS to use LXD for VMs, replacing libvirt in that regard.
Similarly Multipass on Linux will also be using LXD to run VMs.
That’s correct. For those you need to use cloud-init to provision a user, once you have a user in there, you can install the LXD agent with:
mount -t 9p config /mnt
cd /mnt
./install.sh
reboot
I did push our agent integration package to Ubuntu but it’s been sitting in a review queue for well over a month now… Hopefully it eventually gets accepted and included in the official images.