Re: [Users] [Spice-devel] multiple concurrent spice consoles (was Ovirt + Spice + VDI)

Great to hear. So the situation is as follows: * there has been extensive refactoring of spice-server to support multiple concurrent connections, or as they are called in the commit messages: multiclients, or multi client, or multiple client support. * It isn't set on by default, you need to enable a special environment variable, it says in the README, I think SPICE_DEBUG_MC_ENABLED=1 (check first in README). * The reason it isn't enabled is that spice will abort if you use two clients which have different network conditions. This is not usable in production. The problem requires me to explain a bit more about how spice is architected, but since you are suggesting you will work on fixing this, I am glad to do so: Some nomenclature: (camel case denotes a struct defined in spice-server) Drawable - spice internal item linking to on device RedDrawable. We limit these to NUM_DRAWABLES to avoid ballooning server memory usage. RedClient - a single client. It can have multiple channels connected. We are only interested in the display channel right now, but the problem is mirrored for the cursor channel, although it is simpler to fix there. RedChannel - a single channel. It can have multiple clients. RedChannelClient - a single instance of a channel for a particular client. Contains the socket to the client for this channel (spice has a separate socket per channel per client). It contains a queue of outgoing messages to the client, messages are dequeued when the socket becomes ready for writing (see red_worker.c poll loop) pipe - the message queue just mentioned is called a pipe, or a message pipe. This is the penultimate cause of the abort mentioned: one of the RCCs (RedChannelClient) socket because blocked for write for a long time. As a result the pipe size increases. Each pipe item references a Drawable. When the pipe size reaches NUM_DRAWABLES we get an abort (this is a bit simplified since not all pipe items have to reference a Drawable). Every rendering operation coming from the guest goes through the following sequence: * read by spice-server from device: QXLInterface::get_command (qemu: hw/qxl.c:interface_get_command) * allocate a drawable. * for each RedChannelClient push to the pipe (creating a PipeItem, taking a reference on the drawable) * try to send data to each RCC socket There are a few things we can do: (a) dynamically increase NUM_DRAWABLES - this goes against the requirement to constrain the amount of memory the server uses (for allowing multiple servers on one vm) * we can make this configurable for a short term solution. * but even with this it is possible that a (b) (this is what I want to do) Replace too long a queue with a single rendered image. This will free all the drawable references, using a single new drawable or possibly another queue (Drawables reference RedDrawables that are the device allocated memory, and this new rendered image will be completely in non guest ram). The building blocks for (b) already exist in the server. See for instance update_area. But I've taken a long time to write this and I need to stop now, so if this sounds like something you want to do then please ask me further questions, I'm also on irc. Alon