From 7bc1e85270166625dd71fe0d17145ba8b8db193e Mon Sep 17 00:00:00 2001 From: Johannes Stoelp Date: Fri, 10 Dec 2021 20:25:00 +0100 Subject: virtio: enhanced qemu user network description --- content/2021-12-02-toying-with-virtio.md | 52 +++++++++++++++++++++++++++++--- 1 file changed, 48 insertions(+), 4 deletions(-) (limited to 'content') diff --git a/content/2021-12-02-toying-with-virtio.md b/content/2021-12-02-toying-with-virtio.md index 9de9a94..a46fb2a 100644 --- a/content/2021-12-02-toying-with-virtio.md +++ b/content/2021-12-02-toying-with-virtio.md @@ -191,10 +191,48 @@ The full build script is available under [build_kernel.sh][build-kernel]. For the qemu device emulation we already decided on the front-end device, which will be our virtio net device. \ -On the back-end we will choose the [`user`][qemu-user-net] network stack. This -runs a dhcp server in qemu which implements a virtually NAT'ed sub-network with -the address range `10.0.2.0/24`. By default, the dhcp server assigns the -following IP addresses interesting to us: +On the back-end we will choose the [`user`][qemu-user-net] option. This enables +a network stack implemented in userspace based on [libslirp][libslirp], which +has the benefit that we do not need to setup additional network interfaces and +therefore require any privileges. Fundamentally, [libslirp][libslirp] works by +replaying [Layer 2][osi-2] packets received from the guest NIC via the socket +API on the host ([Layer 4][osi-4]) and vice versa. User networking comes with a +set of limitations, for example +- Can not use `ping` inside the guest as `ICMP` is not supported. +- The guest is not accessible from the host. + +With the guest, qemu and the host in the picture this looks something like the +following. +```text ++--------------------------------------------+ +| host | +| +-------------------------+ | +| | guest | | +| | | | +| | user | | +| +------+------+-----------+ | +| | | eth0 | kernel | | +| | +--+---+ | | +| | | | | +| | +-----v--------+ | | +| | | nic (virtio) | | | +| +--+---+-----+--------+------+--+ | +| | | Layer 2 qemu | | +| | | (eth frames) | | +| | +----v-----+ | | +| | | libslirp | | | +| | +----+-----+ | | +| | | Layer 4 | | +| | | (socket API) | user | ++--+---------+--v---+--------------+---------+ +| | eth0 | kernel | +| +------+ | ++--------------------------------------------+ +``` + +The user networking implements a virtually NAT'ed sub-network with the address +range `10.0.2.0/24` running an internal dhcp server. By default, the dhcp +server assigns the following IP addresses which are interesting to us: - `10.0.2.2` host running the qemu emulation - `10.0.2.3` virtual DNS server > The netdev options `net=addr/mask`, `host=addr`, `dns=addr` can be used to @@ -225,6 +263,9 @@ qemu-system-x86_64 \ -nic user,model=virtio-net-pci ``` +The `-nic` option is a shortcut for a `-device (front-end) / -netdev +(back-end)` pair. + After booting the guest we are dropped into a shell and can verify a few things. First we check if the virtio net device is detected. Then we check if the interface got configured and brought up correctly. @@ -330,3 +371,6 @@ respectively. [virtio]: http://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.pdf [qemu-nic-opts]: https://www.qemu.org/docs/master/system/invocation.html#hxtool-5 [qemu-user-net]: https://www.qemu.org/docs/master/system/devices/net.html#using-the-user-mode-network-stack +[libslirp]: https://gitlab.com/qemu-project/libslirp +[osi-2]: https://osi-model.com/data-link-layer +[osi-4]: https://osi-model.com/transport-layer -- cgit v1.2.3