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

[Arnon Gilboa]

Great overview!
I finally understood what my neighbor was working on...
Please wikify it & add link@ http://cleo/qumrawiki/Spice
Arnon

Yonit Halperin wrote:
> 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.
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>