[Proposal] Implement VGA console for container instances

[tarruda]

This is an attempt to implement VGA console type for container instances by using a very simple approach: When lxc console --type=vga is launched for a container instance, it will create a proxy device for a SPICE server listening on the container. That means it is entirely up to the container/image to do most of the heavy lifting, and all this PR does is reuse the existing VM VGA console infrastructure.

To simplify testing this PR, I've created a script which creates a local image for a Debian MATE desktop using Xorg spiceqxl driver: https://gist.github.com/tarruda/b6886fc7be3c21f2f878ea74e0ea7891. After running the script to create the image, use this to test the VGA display:

lxc launch debian-mate-desktop-xspice mate --console=vga

I'm not sure if there's a better way to expose the instance's socket, but creating a proxy device on demand was the easiest path I've found. IMO it ended up being more flexible too, since the user can override the proxy device in the instance config.

[lxc-jenkins]

This pull request didn't trigger Jenkins as its author isn't in the allow list.

An organization member must perform one of the following:

• To have this branch tested by Jenkins, use the "ok to test" command.
• To have a one time test done, use the "test this please" command.

Those commands are simple Github comments of the format: "jenkins: COMMAND"

[tarruda]

In the last commit I changed the approach to adding a proxy device: Instead of calling "Update" passing instance args, I'm calling devicesUpdate directly which seems slightly cleaner since it doesn't change the instance device configuration

[stgraber]

Hey there,

Sorry for the long delay. I've been thinking about this some more trying to see if there's something that we can do which would make sense for all containers and wouldn't feel like a hack.

I've unfortunately come up empty. We definitely will not merge code that will alter an instance's definition by adding devices.

I'm also not all that keen on effectively misrepresenting something to our users. Containers do not have VGA output, they don't have a graphics card, rendering nodes, ... The fact that our --type=vga is using SPICE for VMs is an implementation detail which could change down the line. The guarantee we have for VMs is that we do have a VGA output in the VM which is carried over this to the client by LXD.

Making --type=vga for containers connect to a user-provided SPICE endpoint would completely tie us to SPICE as we have no control over the guest.

Lastly on the misrepresentation part, we have a lot of users that are confused about what a container even is. Having what looks like VGA output but it not working in most cases and when it works, it not showing the early boot or allow for system installation or the like is going to cause a lot of confusion.

The specific case you're covering here is effectively similar to your traditional VNC, NX, RDP, ... use case. It's a remote desktop session and it's probably best treated as such, separately from LXD's internal API.