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

[Laszlo Ersek]

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:

><rescue> ping -c 3 8.8.8.8
><rescue> ip neighbor
><rescue> ip addr
><rescue> ip route

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