@node pcsys_network @section Network emulation QEMU can simulate several network cards (e.g. PCI or ISA cards on the PC target) and can connect them to a network backend on the host or an emulated hub. The various host network backends can either be used to connect the NIC of the guest to a real network (e.g. by using a TAP devices or the non-privileged user mode network stack), or to other guest instances running in another QEMU process (e.g. by using the socket host network backend). @subsection Using TAP network interfaces This is the standard way to connect QEMU to a real network. QEMU adds a virtual network device on your host (called @code{tapN}), and you can then configure it as if it was a real ethernet card. @subsubsection Linux host As an example, you can download the @file{linux-test-xxx.tar.gz} archive and copy the script @file{qemu-ifup} in @file{/etc} and configure properly @code{sudo} so that the command @code{ifconfig} contained in @file{qemu-ifup} can be executed as root. You must verify that your host kernel supports the TAP network interfaces: the device @file{/dev/net/tun} must be present. See @ref{sec_invocation} to have examples of command lines using the TAP network interfaces. @subsubsection Windows host There is a virtual ethernet driver for Windows 2000/XP systems, called TAP-Win32. But it is not included in standard QEMU for Windows, so you will need to get it separately. It is part of OpenVPN package, so download OpenVPN from : @url{https://openvpn.net/}. @subsection Using the user mode network stack By using the option @option{-net user} (default configuration if no @option{-net} option is specified), QEMU uses a completely user mode network stack (you don't need root privilege to use the virtual network). The virtual network configuration is the following: @example guest (10.0.2.15) <------> Firewall/DHCP server <-----> Internet | (10.0.2.2) | ----> DNS server (10.0.2.3) | ----> SMB server (10.0.2.4) @end example The QEMU VM behaves as if it was behind a firewall which blocks all incoming connections. You can use a DHCP client to automatically configure the network in the QEMU VM. The DHCP server assign addresses to the hosts starting from 10.0.2.15. In order to check that the user mode network is working, you can ping the address 10.0.2.2 and verify that you got an address in the range 10.0.2.x from the QEMU virtual DHCP server. Note that ICMP traffic in general does not work with user mode networking. @code{ping}, aka. ICMP echo, to the local router (10.0.2.2) shall work, however. If you're using QEMU on Linux >= 3.0, it can use unprivileged ICMP ping sockets to allow @code{ping} to the Internet. The host admin has to set the ping_group_range in order to grant access to those sockets. To allow ping for GID 100 (usually users group): @example echo 100 100 > /proc/sys/net/ipv4/ping_group_range @end example When using the built-in TFTP server, the router is also the TFTP server. When using the @option{'-netdev user,hostfwd=...'} option, TCP or UDP connections can be redirected from the host to the guest. It allows for example to redirect X11, telnet or SSH connections. @subsection Hubs QEMU can simulate several hubs. A hub can be thought of as a virtual connection between several network devices. These devices can be for example QEMU virtual ethernet cards or virtual Host ethernet devices (TAP devices). You can connect guest NICs or host network backends to such a hub using the @option{-netdev hubport} or @option{-nic hubport} options. The legacy @option{-net} option also connects the given device to the emulated hub with ID 0 (i.e. the default hub) unless you specify a netdev with @option{-net nic,netdev=xxx} here. @subsection Connecting emulated networks between QEMU instances Using the @option{-netdev socket} (or @option{-nic socket} or @option{-net socket}) option, it is possible to create emulated networks that span several QEMU instances. See the description of the @option{-netdev socket} option in the @ref{sec_invocation,,Invocation chapter} to have a basic example.