[Spice-devel] An overview of Network redirection in Spice

[Yonit Halperin]

Hi,
I’ve previously worked on the network redirection feature, which part of
it is already in the upstream. Here, I present an overview of this feature
and its status.

Motivation
----------
In many scenarios, the network that the Spice client resides in is not
accessible from the virtual machine. Thus, the user cannot access
resources that are located in the client's network (e.g., network
printers). The suggested solution provides an almost transparent access to
this network.

Solution overview
-----------------
1.	An additional virtual network card (nic) is installed on the VM.
This network card is dedicated for communication with the client-side
network
2.	The nic's subnet is unique (henceforth, the virtual subnet).
3.	Resources in the client-side that need to be accessed via the VM
receive virtual ip addresses in the range of the virtual subnet. The user
accesses these resources using the virtual ips. Therefore, all the packets
that are designated to these resources pass through the special nic.
4.	All the network packets that pass through the special nic are
delivered to the Spice Server, via QEMU. Eventually, the actual connection
and data transfer to/from the physical resource are performed by the Spice
Client.
The server a) Performs the network stack analysis of the packets (e.g.,
handles the TCP protocol); b)  Sends to the client connection-control
instructions, e.g., open/close connection to a specific resource; c)
Tunnels to the client the buffers that need to be delivered to a specific
resource.
5.	After a connection to a resource was established, it is
bidirectional, i.e., the client can tunnel to the server data that was
originated from the resource and that is designated to the VM. The client
can also send to the server control messages about the connection (e.g.,
the connection was closed). The server translates the information to
network packets and pushes them to the VM through the special nic.

Design details
--------------
1.	Adding a nic: a special network device we added to Qemu, that
pushes all the packets to spice and can receive packets from spice.
2.	Network stack analysis:  we use a modified version of Slirp.
Slirp was created by Danny Gasparovski. It emulates a PPP or SLIP
connection over a normal terminal. Qemu use its code mainly for their
“user” network (the –net user option). The Slirp code in Qemu transfers
the application layer of the packets to its destination by using BSD
sockets. However, we need to pass the application layer to/from the Spice
server. We took the Slirp code from Qemu,
and changed it to use a general interface for network connections that can
be set by the user of slirp. We fill it with callbacks to the
corresponding routines in the server.
Our intention was to ship Slirp as a library that hopefully will be useful
for other projects, and that Qemu will be able to use as well.
3.	Spice: added a designated channel for network redirection. It is
called “tunnel channel”. Control data and “redirected” data is passed to
and from the client. The client pushes the redirected data to the
corresponding network resources and also can receive data from them and
sends it back to the server (and from there it is sent to the VM).
4.	Generating virtual ips: In order to keep the virtual IPs
consistent with the resources they represent (in a specific network), we
generate them by hashing identifiers that are unique to the resource and
to the network it is located in. Thus, in different executions of Spice
client on the same network, each client-side resource will obtain the same
virtual IP it obtained in the previous executions. In this manner, we
preserve the validity of configurations in the VM that employ the virtual
IPs.
5.	Printer discovery: We implemented printer discovery via SNMP and
DNS-SD.
Snmp++ library was used for SNMP. For DNS-SD we used Apple Bonjour API,
while employing avahi-daemon in Linux and Apple Bonjour in Windows.

Solution Advantages
-------------------
-	Transparent user experience for network services (mainly
printers). The user just need to know the virtual ip of the printer. We
can use Gui for that and configuration file.
-	General solution for network resources (e.g., ftp serves). Not
only printers.
-	It can be generalized to local resources as well.
-	In the tunnel channel there is an option to process the
application layer - it can function as a firewall.
-	Other solutions use a special guest-driver and/or a
guest-application. As far as I know most of them also depends on the
printer drivers installed on the client machine.
This solution is cross-platform (client and guest wise) and
client-independent.

Disadvantages
-------------
- Bandwidth: The rendered job (which can be much larger than the original
file) is sent from the host to the client. This is problematic on WAN.
(Other solutions send the file as it is to the client, and as mentioned
before, depend on the drivers on the client machine).
The tunnel channel traffic should be compressed in order to minimize this
issue.
- Installation of drivers on the guest: only by administrator user.
- Some protocols (e.g., IPP) include the destination and/or src in the
data. This is problematic when using a virtual ip. In order to fully
support it we need to process the data itself and serve as proxy. If the
protocol is also encrypted (an option in IPP), it is even more
complicated.

Status
------
- Qemu side was implemented but is not yet in upstream, so the whole
feature is still inactive.
- Slirp and Spice: TCP support is in upstream (including live migration).
Bug fixes, Udp support, stable virtual ip generation, printer discovery
and more – were implemented but haven’t been taken to upstream yet.
- Slirp – I made some cosmetic changes to the slirp code, fixed some bugs,
minimized it to work only for network redirection, and modified it to work
with general interface for sockets. But there is still a lot of work that
needs to be done in order to make it a real library (e.g., currently there
is only one instance of it) that not only Spice will want to use. It
probably should be aligned with upstream Qemu Slirp.
- Printer-Discovery – (1) need Gui to display printers and their virtual
ips.
(2) Apple Bonjour for windows – at the first phase we can require that
apple bonjour will be installed on the client computer (it is free, and if
it is not installed only the DNS-SD discovery won't work). Legally, we
cannot ship Apple binaries with spice. However, at a second phase, we can
compile them by ourselves and ship them.
- Printing protocol: After all the changes I made will be applied, raw tcp
printing (also know as HP JetDirect) is fully supported. IPP also worked
for me, also through cups (but without any special security
configuration). Probably there are other protocols that are (or can be
easily) supported.

Optional features
-----------------
- Resolving DNS queries in slirp – the user will be able to use the
client-side printer names in the virtual network, as they will be resolved
as virtual ips.
- Optional general compression layer for all spice channels.


Any questions and ideas are welcomed,
Yonit.