[Spice-devel] An overview of Network redirection in Spice
Hi, Ive 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
Re: [Spice-devel] An overview of Network redirection in Spice
On 2010-03-02 16:29, 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. - Is there really such a requirement? Is there such a real-life use-case? From my experience, if the printer is on the network, it can be reached from wherever is needed - or is specifically redirected. - What else besides printing is a good candidate for network redirection? I doubt FTP (as the example below) is one of them. - Aren't you bypassing all network access controls en-route (firewalls, ACLs, content-filtering, etc.) ? You are also in the way of WAN acceleration devices, which may have helped with the traffic, as well as QOS. 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). What about IPv6? Why go above layer 2? 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. Take from OpenVPN (or VPNc?) their virtual NIC. Makes more sense to me and works. And the driver is already signed, works on all Windows OSes, etc. 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. Nobody but Apple uses Bonjour. How about UPNP and SSDP? SLP On Linux (donno if anyone's using it). Solution Advantages --- - Transparent user experience for network
Re: [Spice-devel] An overview of Network redirection in Spice
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
