we want to develope spice for multiple concurrent spice console on
single OS. for example, we want to use windows XP as single VM for
multiple users. we want to develop it as spice feature. is it
possible? any help or idea? shall we work on that experimental
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:
* allocate a drawable.
* for each RedChannelClient push to the pipe (creating a PipeItem, taking a reference on
* 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 Levy <alevy(a)redhat.com> wrote on Thu, 13 Sep 2012 05:47:37 -0400
On 09/12/2012 07:32 PM, Mohsen Saeedi wrote:
I want to know, we are force to install one windows per user? does
can provide a multi remote connection to a single windows XP
I want to install one windows XP as virtual desktop and then share
with more than one users.is it possible in now or in the futures?
Thanks Thanks for the interest. There is no support for multiple
client connections using spice protocol. There is only experimental
known buggy support that still needs more work. There is no concrete
plan when that work will happen.
Users mailing list Users(a)ovirt.org
Spice-devel mailing list Spice-devel(a)lists.freedesktop.org