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

[Arnon Gilboa]

Of course, I meant a link from the site...

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