D-Bus in virtual desktop infrastructure connecting client services and guest apps

[Fedor Lyakhov]

Hello,

Raising this topic, I want to indicate that I understand the main
purpose of D-Bus is to provide a communication between local services
and clients at the same machine. Remoting D-Bus buses over plain TCP
socket is possible but not recommended, at least for "production".

There is a special use case though, called VDI, when main user desktop
is a virtual machine at remote host, and he uses a thin client to
connect to it. The main open-source solution for this is RHEV, the
virtual display system of it is called Spice (spice-space.org).

For this use case there is a need for exposing client capabilities as
a service to the guest virtual machine - to enhance the user
experience and resource utilization. One of such enhancements is
developed in our project Melange (https://github.com/lyakhov/melange).
We want to totally
off-load all multimedia processing of applications like media players
and VoIP softphones from the virtual machine to the client. Saying
totally I mean no media streams should reach VM at all, i.e. it isn't
some sort of a media pass-through but rather media bypass for
virtualization server. This measure reduces server's CPU and network
load, optimizes media path preserving quality of VoIP calls and video
playback. More details can be found at
http://www.spice-space.org/page/Features/MediaRedirection

Here is an example of how we want to build our system for
GStreamer-based applications:
* GStreamer as the media back-end at the client
* gstd, GStreamer Daemon for D-Bus at the client
* D-Bus transported inside Spice connection
* Guest's application (e.g. media player) linked with GStreamer stubs,
converting function calls into actual D-Bus calls to gstd at the
client.

Want to highlight that we intend to transport D-Bus messages inside a
Spice-provided transport, which has to be designed, BTW - need to make
it secure and reliable... e.g. TLS encryption is already available in
Spice.

Melange is in the very early stage of development, we're working on a
prototype now. The concept has been under public discussion for a
while though - in Spice and GStreamer lists. We want to identify the
best means to achieve our goals... so I have got following
questions/discussion topics:

1. Does using D-Bus make sense in our circumstances? We're considering
an alternative, Apache Thrift - which is a general-purpose remote
procedure call system. It is probably more binary-efficient than D-Bus
(comparable to Google Protocol Buffers), but it isn't widely used in
existing open-source applications and services... And it lacks
features compared to D-Bus - like signals...

2. We need to decide how to provide virtual guest system with a D-Bus
service running at the client. There are many options potentially,
with pro's and contra's:
a) Use peer-to-peer connections and private D-Bus service at the
client, do not use any bus at all. That's how Telepathy D-Tubes are
implemented, for instance. The main drawback here is the need for
private D-Bus servers - while we can make one out of e.g. gstd, in
general we won't be able to re-use existing services - most are
written to work via a bus.

b) Provide client services (gstd) with access to guest's bus. Seems to
be fine for our particular use case. If think more generally, it
should be possible to configure what services to "pass-through" to the
guest. Issues:
- possible name conflict of local and remote services;
- local services being passed to remote machine - so now not available
to the local applications? Or multiple instances of them running?...
- How to actually implement this pass-through? A process at the guest
OS connected with Spice server and acting on behalf of the service?
One process per service, or single process for all?...

c) To address name conflict, I can think of:
- pass services to the new bus at the guest, e.g. "remote" bus
- add namespace to the services, e.g. org.melange would be
remote.org.melange (requires parsing of the D-Bus - bad)

d) What if guest wants to provide services to the client? Not a VDI
use case, but in general this can be thought about...

Of course, there are many more architectural and design questions to
answer. E.g. security concerns...

We're going to visit FOSDEM'14 - I'll be giving a talk in
Virtualisation and IaaS dev room
(https://fosdem.org/2014/schedule/event/virtiaas23/). It would be nice
to meet you there!


-- 
Best regards,
Fedor