[Libguestfs] [libguestfs PATCH 0/7] lib: support networking with passt

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184967 This series makes both backends prefer passt over slirp for appliance networking, if QEMU or libvirt (respectively) is recent enough, and passt is installed. My test setup is: $ virt-builder fedora-38 Then, each test run looks like this: Terminal#1: $ ./run rescue/virt-rescue --network --ro -a fedora-38.img Terminal#2: - check if "passt" is running (ps -ef, pgrep, ...), provided it *should* be running Terminal#1: Expected results (in the above order), always on the "eth0" lines: - all three pings succeed (get replies) - 52:56:00:00:00:02 - 169.254.2.15/16 - default via 169.254.2.2 Actual results: (1) At current master (13c7052ff96d): (1.1) With "LIBGUESTFS_BACKEND=direct": Pass, this is the baseline. (1.2) With "LIBGUESTFS_BACKEND=libvirt": Pass, this is the baseline. (2) With this series applied: (2.1) With passt not installed: (2.1.1) With "LIBGUESTFS_BACKEND=direct": Pass, this is a regression test concerning the absence of "passt". (2.1.2) With "LIBGUESTFS_BACKEND=libvirt": Pass, this is a regression test concerning the absence of "passt". (2.2) With passt installed: (2.2.1) With "LIBGUESTFS_BACKEND=direct": Pass, this verifies the new feature. (2.2.2) With "LIBGUESTFS_BACKEND=libvirt": Basic connectivity works fine (i.e., the pings). The "ip neighbor" and "ip route" checks fail. In addition, the "ip addr" check *partially* fails. All that is due to libvirt bugs: (a) Libvirt specifies the *guest MAC* (virtio-net MAC) as the *host MAC* for passt, with a wrong "--mac-addr" option (from libvirt commit a56f0168d576, "qemu: hook up passt config to qemu domains", 2023-01-10). This breaks "ip neighbor". (b) Libvirt doesn't pass the "--gateway" option to passt. This breaks "ip route". Namely, passt (following its default behavior) sets the guest's gateway to 192.168.0.1, which is the gateway for my *host*. (c) "ip addr" also reports "169.254.2.15/1". The IP address is fine, but the netmask is wrong; it's not /16. This is most likely a consequence of (b) -- normally the gateway is supposed to be on the same Ethernet segment (subnet) as the endpoint! 192 decimal is 11000000 binary, while 169 decimal is 10101001 binary, and their longest common initial bit sequence is just 1 bit -- hence the /1, most likely. I've filed <https://bugzilla.redhat.com/show_bug.cgi?id=2222766> about these. The upshot is that "appliance networking with passt" works with either backend, but with the libvirt backend, there are some appliance-visible differences from the SLIRP environment. Whether that's a problem in practice, I can't tell (probably not a problem) -- dependent on future decisions about RHBZ#2222766, we might want to update the libvirt backend code introduced here. Laszlo Laszlo Ersek (7): lib: fix NETWORK_ADDRESS: make it an actual IP address, not a subnet base lib/launch-libvirt: support networking with passt docs: fix broken link in the guestfs manual docs: clarify sockdir's separation lib: move guestfs_int_create_socketname() from "launch.c" to "tmpdirs.c" lib: introduce guestfs_int_make_pid_path() lib/launch-direct: support networking with passt fish/guestfish.pod | 4 +- generator/actions_properties.ml | 8 +- lib/guestfs-internal.h | 32 ++++- lib/guestfs.pod | 6 +- lib/launch-direct.c | 147 +++++++++++++++++++- lib/launch-libvirt.c | 11 ++ lib/launch.c | 54 +++---- lib/tmpdirs.c | 41 ++++++ 8 files changed, 263 insertions(+), 40 deletions(-) base-commit: 13c7052ff96d5ee99ec1b1252f1a3b4d7aed44d2