Multiple access problem about docker-gui

[yanbx]

Sorry, this question should not be asked. I think I have figured out where to modify it.It is possible that SPICE has a protocol number due to the image initialization Settings.I'll try again for myself.This problem can be turned off. We'll keep in touch

[fadams]

I'm not totally clear what you are actually trying to achieve.

I have a strong suspicion that you are probably thinking that doing some of this is easier than it actually is.

What I mean by that is that there are actually many, many different concepts going on in the context of logging in to a Linux Graphical Desktop and even more concepts when considering remote access.

You have previously asked about first disabling the SPICE password then gone on to ask about disabling password access to the Desktop. I've previously sent some links that might enable such a thing, but it seems obvious that if you have something directly entering a desktop pretty much by definition it is single user.

Then you talk about multiple monitors. Supporting multiple monitors (multi headed) is a totally orthogonal concept to multiple users.

Another complication and something you need to consider is the differences between multiple users, sessions and seats.

Linux is fundamentally multi user and if you create a system with multiple users via adduser logging in as any of those users or su to those users is perfectly possible. However that is not the same thing at all as being able to support multiple different graphical sessions.

There is also a difference too between having multiple different desktop sessions and multiple connections to the same desktop session.

For the case of SPICE if you actually read the documentation you will see on this page https://www.spice-space.org/spice-user-manual.html "Spice does not support multiple connections to the same QEMU instance by default. So anybody who will connect to the same host and port can simply take over your session. You can solve this problem by using ticketing."

What this actually means is that when one SPICE client has successfully connected to a running SPICE server then subsequent connections are blocked. Which is what you are observing as is an artefact of SPICE.

There is also this page https://www.spice-space.org/multiple-clients.html to be honest I've not tried any of this but what it is explicitly talking about is supporting multiple concurrent connections to a single spice server. Which implies multiple connections to the same desktop session. This may be what you want, but as I say I've not tried it and I've not looked into how to configure Xspice to do this (or even if it's possible).

On the broader topic of whether SPICE supports multiple simultaneous user sessions - that is to say a use case where you have a server that has multiple users and you want to support simultaneous different desktop sessions for each user. Well that is not even on the SPICE roadmap. The main use case for SPICE is actually connecting to VMs with the aim of making them "feel" like physical desktop seats.

I found this page https://spice-devel.freedesktop.narkive.com/q6pfMH8S/multiple-concurrent-spice-consoles-was-users-ovirt-spice-vdi with a response "multiple sessions to the single VM are not on the roadmap. There is experimental multi-client support but it is to make more users see the same session."

Supporting multiple (different) concurrent Desktop sessions is actually a rather complex subject. In a previous response I have tried to explain the purpose of the Display Manager in these virtual desktops. The DM basically manages the login process but also handles setting up per user services like PulseAudio, polkit and a few other things.

All of those things are important to give a properly functioning desktop session. It would actually be possible to run several different Xspice servers and to run Gnome on them, but they wouldn't be "quite right".

SPICE was never actually designed for that particular use case.

If you look at things like RDP now that is actually a full Remote Desktop Protocol. The subtle difference with RDP over say SPICE and VNC is that on the server side RDP actually has something that behaves very like a Display Manager so when you do an RDP login it correctly launches a full user session. It's a subtle but important difference.

It would almost certainly be possible to write your own Display Manager that behaves like xrdp's session manager, but instead launches SPICE. Indeed I'd be pretty certain that it'd be possible to hack xrdp's session manager to launch SPICE sessions instead of RDP sessions but it's beyond the scope of anything I am trying to illustrate in this repo

Another thing I'd say is that if your use case is multiple different user sessions as opposed to multiple connections to the same user session then you can maybe think about it in a different way.

The reason for things like RDP enabling multiple user sessions is because physical machines are fixed resources. When you start virtualising things there is less benefit e.g. do you need multiple sessions onto a physical server or do you actually want multiple VMs each with a single graphical seat.

For what we are doing in this repo you should bear in mind that each desktop is a container and uses even fewer resources than a VM so there's not actually a strong argument to have multiple graphical sessions supported on each containerised environment (though as I say above it's technically possible with a bit of work) rather I'd say that you would be much better off running a separate containerised desktop instance for each user. Doing this actually uses no more resources than running multiple graphical sessions on the same virtual server.

As I say at the start though you really need to be clear what exactly it is that you are wanting to achieve. But really the graphical desktops and remote graphical desktops in this repo are behaving exactly as intended and in many cases it's constrained by the things I mention here and in previous responses about how Linux deals with graphical logins, sessions, seats and the like.