Tóm tắt Networking trong qemu - QuânSysAd's Blog

07 tháng 7 2022

Tóm tắt Networking trong qemu

 Có 2 loại:

  • the virtual network device that is provided to the guest (e.g. a PCI network card).
  • the network backend that interacts with the emulated NIC (e.g. puts packets onto the host's network).
By default QEMU will create a SLiRP user network backend and an appropriate virtual network device for the guest. as if you had typed -net nic -net user on your command line


Note - if you are using the (default) SLiRP user networking, then ping (ICMP) will not work, though TCP and UDP will. Don't try to use ping to test your QEMU network configuration!

Chọn loại network nào ? 

In most cases, if you don't have any specific networking requirements other than to be able to access to a web page from your guest, user networking (slirp) is a good choice.

However, if you are looking to run any kind of network service or have your guest participate in a network in any meaningful way, tap is usually the best choice.


User Networking (SLIRP)

This is the default networking backend and generally is the easiest to use. It does not require root / Administrator privileges. It has the following limitations:

  • there is a lot of overhead so the performance is poor
  • in general, ICMP traffic does not work (so you cannot use ping within a guest)
    • on Linux hosts, ping does work from within the guest, but it needs initial setup by root (once per host) -- see the steps below
    • the guest is not directly accessible from the host or the external network

    User Networking is implemented using "slirp", which provides a full TCP/IP stack within QEMU and uses that stack to implement a virtual NAT'd network.

    A typical (default) network is shown below.



    Note that from inside the guest, connecting to a port on the "gateway" IP address will connect to that port on the host; so for instance "ssh 10.0.2.2" will ssh from the guest to the host.


    Trong ảnh trên nếu ssh 10.0.2.2 : tức là kết nối từ guest (vm) tới host (máy vật lý)

    Adding the following to the qemu command line will change the network configuration to use 192.168.76.0/24 instead of the default (10.0.2.0/24) and will start guest DHCP allocation from 9 (instead of 15):


    Nếu dùng các tham số lệnh sau sẽ thay đổi cấu hình network là dùng dải mạng 192.168.76.0/24 và sẽ khởi động DHCP cấp IP động từ 9 (thay vì 15)

    -netdev user,id=mynet0,net=192.168.76.0/24,dhcpstart=192.168.76.9
    

    You can isolate the guest from the host (and broader network) using the restrict option. For example -netdev user,id=mynet0,restrict=y or -netdev type=user,id=mynet0,restrict=yes will restrict networking to just the guest and any virtual devices. This can be used to prevent software running inside the guest from phoning home while still providing a network inside the guest. You can selectively override this using hostfwd and guestfwd options.


    Có thể cô lập mạng giữa guest và host (và broader network sử dụng tùy chọn `restrict`). Ví dụ
    `-netdev user,id=mynet0,restrict=y` hoặc `-netdev type=user,id=mynet0,restrict=yes`

    sẽ giới hạn network chỉ gồm guest và host. Có thể ngăn chặn phần mềm trong guest kết nối tới host trong khi vẫn cung cấp network bên trong guest. Bạn có thể chọn lọc ghi đè bằng tùy chọn  `hostfwd` and `guestfwd`

    Bật lệnh ping trong guest, Linux hosts

    • Determine the main group ID (or one supplementary group ID) of the user that will run QEMU with slirp.
    • In /etc/sysctl.conf (or whatever is appropriate for your host distro), make sure that the whitespace-separated, inclusive group ID range in the net.ipv4.ping_group_range sysctl includes the above group ID.
    • For example, as root,
    • add a new group called unpriv_ping:
    • groupadd unpriv_ping
    • set this group for a number of users as another supplementary group (note, they will have to re-login):
    • for U in user1 user2 ... user_n; do
        usermod --append --groups unpriv_ping $U
      done

    • then set both sides of the inclusive range in the above sysctl to the numeric ID of the new group:
    • (
        GROUP_ID=$(getent group unpriv_ping | cut -f 3 -d :)
        printf 'net.ipv4.ping_group_range = %u %u\n' $GROUP_ID $GROUP_ID \
          >> /etc/sysctl.conf
      )
      sysctl -p
    • Advanced user networking options

      The -netdev user parameter has some more useful options:

      • The DHCP address and name for the guest can be set with -netdev user,id=n0,host=addr,hostname=name

      • You can specify the guest-visible virtual DNS server address with -netdev user,id=n0,dns=addr
      • QEMU can simulate a TFTP server with -netdev user,id=n0,tftp=xxx,bootfile=yyy
      • To share files between your guest and host, you can use -netdev user,id=n0,smb=dir,smbserver=addr
      • To forward host ports to your guest, use -netdev user,id=n0,hostfwd=hostip:hostport-guestip:guestport


    • Tap

    • The tap networking backend makes use of a tap networking device in the host. It offers very good performance and can be configured to create virtually any type of network topology. Unfortunately, it requires configuration of that network topology in the host which tends to be different depending on the operating system you are using. Generally speaking, it also requires that you have root privileges.

    • Cung cấp hiệu năng cao và yêu cầu quyền root ở máy host.

    • -netdev tap,id=mynet0
    • VDE

      The VDE networking backend uses the Virtual Distributed Ethernet infrastructure to network guests. Unless you specifically know that you want to use VDE, it is probably not the right backend to use.

    Socket

    The socket networking backend allows you to create a network of guests that can see each other. It's primarily useful in extending the network created by the SLIRP backend to multiple virtual machines. In general, if you want to have multiple guests communicate, the tap backend is a better choice unless you do not have root access to the host environment.


    Nếu muốn nhiều máy ảo có thể giao tiếp với nhau thì tap backend sẽ tốt hơn trừ khi bạn không có quyền root ở máy host.


    -netdev socket,id=mynet0,listen=:1234
    -netdev socket,id=mynet0,connect=:1234

    Virtual Network Devices

    How to create a virtual network device?

    The virtual network device that you choose depends on your needs and the guest environment (i.e. the hardware that you are emulating). For example, if you are emulating a particular embedded board, then you should use the virtual network device that comes with embedded board's configuration. Such on-board NICs can be configured with the -nic option of QEMU. See the corresponding section below for details.

    On machines that have a PCI bus (or any other pluggable bus system), there are a wider range of options. For example, the e1000 is the default network adapter on some machines in QEMU. Other older guests might require the rtl8139 network adapter. For modern guests, the virtio-net (para-virtualised) network adapter should be used instead since it has the best performance, but it requires special guest driver support which might not be available on very old operating systems.

    Use the -device option to add a particular virtual network device to your virtual machine:

    -device TYPE,netdev=NAME
    

    The netdev is the name of a previously defined -netdev. The virtual network device will be associated with this network backend.

    Note that there are other device options to select alternative devices, or to change some aspect of the device. For example, you want something like: -device DEVNAME,netdev=NET-ID,mac=MACADDR,DEV-OPTS, where DEVNAME is the device (e.g. i82559c for an Intel i82559C Ethernet device), NET_ID is the network identifier to attach the device to (see discussion of -netdev below), MACADDR is the MAC address for the device, and DEV-OPTS are any additional device options that you may wish to pass (e.g. bus=PCI-BUS,addr=DEVFN to control the PCI device address), if supported by the device.


    Use -device help to get a list of the devices (including network devices) you can add using the -device option for a particular guest.

    The -nic option

    In case you don't care about configuring every detail of a NIC, you can also create a NIC together with a host backend by using the -nic parameter. For example, you can replace

    -netdev user,id=n1 -device virtio-net-pci,netdev=n1
    
    with:

    -nic user,model=virtio-net-pci

    Use -nic model=help to get a list of the supported NIC models.

    If you don't care about the NIC model, you can also omit that option. So the shortest way to get a tap device is for example simply:

    -nic tap
    

    The NIC option should also be use to configure NICs on embedded systems (which can not be used via -device). For example, to connect such an on-board NIC to the tap backend and change its MAC-address, you can use the -nic option like this:

    -nic tap,mac=02:ca:fe:f0:0d:01
    

    Network Monitoring

    How to get SSH access to a guest

    A simplest way is to forward a specific host port to guest port 22. It can be done via:

    -device e1000,netdev=net0
    -netdev user,id=net0,hostfwd=tcp::5555-:22

    The first line creates a virtual e1000 network device, while the second line created one user typed backend, forwarding local port 5555 to guest port 22. Then we can do:

     ssh localhost -p 5555

    to have SSH access to guest after its network setup (don't forget to turn off firewalls if there is any in the guest or host).



    How to use tap with a wireless adapter on the host
    https://wiki.qemu.org/Documentation/Networking/NAT





    How to disable network completely

    If you don't specify any network configuration options, then QEMU will create a SLiRP user network backend and an appropriate virtual network device for the guest (eg an E1000 PCI card for most x86 PC guests). If you don't want any networking at all you can suppress this default with:

    -nic none
    

    The more general option -nodefaults also suppresses the default networking configuration, as well as the creation of several other default devices.


    Setting up taps on Linux

    For Linux with iproute2 and tap/tun support, this can be configured as below, and assumes the reader has experience using iproute2 (at least ip-addr and ip-link). Take note of the host's physical devices' configuration, as the bridge created will become the new endpoint for the physical device. Note that this WILL cause the host's networking on that physical device to go out, possibly requiring a reboot for remote systems!

     # modprobe tun tap                  # unnecessary if tun/tap is built-in
     # ip link add br0 type bridge
     # ip tuntap add dev tap0 mode tap
     # ip link set dev tap0 master br0   # set br0 as the target bridge for tap0
     # ip link set dev eth0 master br0   # set br0 as the target bridge for eth0
     # ip link set dev br0 up

    At this point, the bridge works, but is not usable as it does not have an IP address. For reassigning the physical device's addresses for the bridge to be usable:

     # ip address delete $PREFIX dev eth0
     # ip address add $PREFIX dev br0
     # ip route add default via $ROUTE dev br0

    This can be automated with a shell script to setup tap networking on remote hosts; as mentioned above, connection will be lost upon setting the physical device's master to a bridge.

    Please note that the newly-created tap device's link may need to be set to UP via ip-link after a virtual machine has been started. Furthermore, as a bridge device basically acts as the new endpoint for a physical device, most normal networking commands, such as a DHCP client or packet sniffer, must be ran on the bridge instead of the physical device. Creating multiple bridges per interface is known (anecdotally) to be problematic; instead, create a tap for each virtual machine using a single bridge for each physical device to be used.


    Tap device link tạo mới phải được set về up thông qua ip-link sau khi máy ảo khởi động. Hơn nữa, bridge device về cơ bản hoạt động như một điểm endpoint mới cho thiết bị vật lý, hầu hết các lệnh networking  như DHCP client hoặc packet sniffer phải được chạy trong bridge thay vì thiết bị vật lý. Tạo nhiều b



    Không có nhận xét nào: