I meant to say earlier that I could not find the previous discussion.
But still, the gist is that you are providing a common user-interface to using both system containers and VMs (which share many end-user features). It is a common practice in the computer industry. I find it straightforward, but perhaps you have something else in mind?
LXD is now also a manager for virtual machines.
As @simos said it can be useful for users of LXD to also be able to use (mostly) the same commands for VMs and containers.
The deciding point in comparison to other tools are the features and details.
I don’t know what is planned to be done, but for now LXD is not feature complete regarding Virtual machines, so several additions will follow.
Sadly there is no complete feature list yet, but I guess there will be one in the future.
For now you can look at Instances - Documentation (look for VM tag) and the release notes in the forum for (most) available features.
As you can see in [Overview] Features for Virtual Machines for example, many features that you usually want are already implemented.
So VMs are already very usable via LXD.
There will be additional features (especially to achieve feature parity with containers, I assume (as far as that is possible)) I am sure.
But I don’t really understand what you want.
The ambition is to have a good VM manager, which we have now.
If you have good ideas, propose them to the team via a Feature Request, either on Github or in the Forum (at best in a seperate post).
to show you all images that have cloud in their name. The cloud in this case is used as a relative search term, showing all images that support cloud-init. ArchLinux is not in the list.
You can always check https://images.linuxcontainers.org, only cloud variants have cloud-init, if there is no such variant (only default), then no cloud-init.
We usually try to have cloud-init images whenever official up to date packages for it are available in the distro, maybe things changed with Arch but the current state of things suggest it wasn’t last we checked.
Ah that does make sense. It seems cloud-init for arch is actually on 20.2-1 and has been out of date since it was flagged on 2020-09-24. It would also appear Gentoo has the same problem cloud-init-21.1.
Does cloud-init have to be the latest version? I’ll try to find out upstream why Arch Linux is lagging behind, then.
On a side note it’s nice to see cloud-init in Alpine Linux. Currently edge repo, so maybe next stable release 3.13 it will be in main repo.
* Is there any way to add a root account etc without cloud-init? I read somewhere default accounts are not shipped with any images. I suppose the only way is to boot an archiso media, chroot to the environment and add a user.
* I also thought about creating my own image with cloud-init. If the package is slightly out of date is this likely to cause issues? I’ll try to work with upstream to get this up to date. It’s nice to have a rolling release distribution with cloud-init.
I assume something like this can be used to boot an environment from a live-cd in order to add some users. For example the archlinux instance doesn’t have cloud-init, so I expect manually adding users is a way?
The environment will automatically boot from the primary disk. It seems hitting ESC isn’t enough to bring up the boot menu. Did I need to change some of the boot options?
That’s an issue with your Linux distribution, your build of qemu wasn’t built with spice support.
I believe I had the LXD maintainer on Arch mention that to us earlier so there may be an open bug report against qemu in Arch to have this fixed.