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-gnome --vm --console=vga
  • lxc launch images:debian/buster/desktop-gnome --vm --console=vga
  • lxc launch images:fedora/34/desktop-gnome --vm --console=vga
  • lxc launch images:opensuse/tumbleweed/desktop-kde --vm --console=vga
  • lxc launch images:ubuntu/20.04/desktop-gnome --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!
https://www.youtube.com/watch?v=pEUsTMiq4B4

5 Likes

@Stephane

I just read about the Release a month ago of Ubuntu Web v20.04.3 and it’s description sound really interesting!

Any chance an LXD VM image will become available?

That’s unlikely, we’ve so far also stayed away from doing all the Ubuntu flavors as the daily consumption of build resources and bandwidth to distribute those desktop images is already pretty significant.

After “lxc start desk”, when I do “lxc console desk -t vga” I get dropped into a session with user “ubuntu”. Is there some way to specify which user will be “logged in” when the desktop container starts rather than “ubuntu”?

You could build your own custom images through distrobuilder.

Is the section that creates the user and sets up the autologin.

Late reply. This is what I needed. Thanks.

it looks like the ubuntu-desktop vm locks the screen after a while of inactivity & you can not get back in without providing a password. The only was back in seems to be lxc restart ubuntu-desk.

Is that intended behaviour?

Not exactly intended, @monstermunchkin may be able to find a way around that (effectively turning it off).

You can go set a password with lxc exec ubuntu-desk -- passwd ubuntu which should let you get out of that.

1 Like

@vrms

1 Like

Not for me I only use headless-linux sessions. Though for some GUI based software I have configured LXD instances to use Xvnc so I can connect to the the Windowmanager on the device. Works fine…

I never got the LXD based console access working on macOS. Where as VNC is the default remote desktop protocol on Macs.

As some people might use this post as a reference, I kindly suggest to modify
images:archlinux/desktop → into → images:archlinux/desktop-gnome

Hello @all,

I invested some time to get a kde (kubuntu) running as a container an access to them by xrdp. At the moment everything is based on Ansible with a few configuration changes where I found config errors e.g. in systemd. Installing the kubuntu desktop on the cloud image currently takes the longest time.
If there is interest, I’m happy to write a tutorial, or pass the changes to @stgraber?

Greeting Frank