Desktop images for LXD VM

Hello,

I just wanted to gauge interest for us building desktop images through distrobuilder and making them available as variants on images.linuxcontainers.org.

Looking at our current selection, I expect we’d do:

  • archlinux
  • debian
  • fedora
  • opensuse
  • ubuntu

Those images are likely to be significantly larger than our current ones, I wouldn’t be surprised if they were to get around 1GiB in size.

As for how I’d expect them to behave. I’d have distrobuilder build them with cloud-init included and a built-in config to have the default user (typically named after the distribution) to be setup with password-less sudo and auto-login onto the desktop.

The result would be things like:

  • lxc launch images:archlinux/desktop --vm --console=vga
  • lxc launch images:debian/buster/desktop --vm --console=vga
  • lxc launch images:fedora/34/desktop --vm --console=vga
  • lxc launch images:opensuse/tumbleweed/desktop --vm --console=vga
  • lxc launch images:ubuntu/20.04/desktop --vm --console=vga

Which would download the image, create the VM and then start it with a SPICE console attached so you can get straight onto the desktop.

We’d probably also bake in the spice agent tools so things like copy/paste work out of the box (and of course the lxd agent as usual).

Before we spend time on this though, I’d like to make sure it’d be useful to people.
Also note that we’re likely to pick whatever desktop environment is preferred/recommended by the given distro and just go with that.

Those images are going to be expensive to build and to distribute because of their size, so we’re pretty unlikely to accommodate multiple desktop environments, package selection, …

And there is a quick poll to get some opinions :slight_smile:

  • Yes, I would use that
  • Interesting but not sure I’d have a use for it
  • Not interested in desktop VMs

0 voters

2 Likes

If possible it would also be cool to have images based on the Ubuntu official flavours that offer different Desktop Environments.

Possibly, though we’d be back to what I mentioned above about offering every desktop environment on every distro being extremely costly (CPU time to build, bandwidth to build, disk space usage and then distribution bandwidth), so while it’d be fun for folks to try different desktop environments, we’ll definitely be pretty conservative on what we offer.

We may be able to do something like kubuntu down the line and watch it for a few months. If it just gets a few dozen users, then we’d drop it as it wouldn’t be worth the cost.

1 Like
  1. I guess these images could also be used for containers?
    Which would need further adjustments by the users of course, such as my Guide for Wayland Sockets.

  2. Another idea would be to provide multiple cloud-init configs for different desktop environments, that would install the required packages.
    This way you would have less size and bandwidth on your side and could deliver some more variants.
    Though the support for different variants would increase the effort.

Its all about the spice scoket these days - Wayland is dead, LXD prevails!

The complexity of this has been explained so many times - cloud-init can be anything from text too a zip file its just so “hard” to implement this. Ive been “begging” for years!

@stgraber im working on something desktop images may have good implications on - HEAD API would be ideal (although WEBDAV really wouldn’t - proxying it in PHP is hard work. A isDir key would do everything I need. But imagine a “right click” → “properties” would be needed - an API just for this would be :100: )

Edit: spelling

I don’t think we’d do that. Container and VM images are two completely separate artifacts on our side. So producing both would double the disk usage.

It would also be very confusing to those using containers as running a desktop image in a container will not get you a working desktop environment. You’d need to then give a bunch of extra instructions on how to integrate with your system’s desktop environment, setup GPU drivers, setup pulseaudio, …

There are definitely use cases for this, but in pretty much all cases, those few wanting to do that will be far better served by starting from a normal image and installing the software they want.

We could do that indeed but I think it’d offer a very poor user experience.
It would significantly drag the initial startup time with no particularly good user feedback on what’s going on at the time and creating multiple instances from one image would cause each instance to individually re-download the exact same bits.

The initial desktop images are now available!

2 Likes