Richard W.M. Jones
2023-Jul-14 09:29 UTC
[Libguestfs] [libguestfs PATCH 0/7] lib: support networking with passt
On Thu, Jul 13, 2023 at 07:10:45PM +0200, Laszlo Ersek wrote:> 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.2Another good test (and the one that really matters) would be something like this on Terminal #1 ...><rescue> chroot /sysroot bash ><rescue> dnf install emacs(or some other package). If dnf can see the Fedora repositories despite the network setup being slightly wonky, that will mean that virt-customize should work.> 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.It's good that this work has found a bunch of libvirt bugs! Rich.> 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 > _______________________________________________ > Libguestfs mailing list > Libguestfs at redhat.com > https://listman.redhat.com/mailman/listinfo/libguestfs-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
Laszlo Ersek
2023-Jul-14 10:41 UTC
[Libguestfs] [libguestfs PATCH 0/7] lib: support networking with passt
On 7/14/23 11:29, Richard W.M. Jones wrote:> On Thu, Jul 13, 2023 at 07:10:45PM +0200, Laszlo Ersek wrote: >> 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 > > Another good test (and the one that really matters) would be something > like this on Terminal #1 ... > >> <rescue> chroot /sysroot bash >> <rescue> dnf install emacs > > (or some other package). If dnf can see the Fedora repositories > despite the network setup being slightly wonky, that will mean that > virt-customize should work.I've been actually thinking about another Clevis+Tang test, but my original test environment for that is gone (gone with my RHEL7 laptop...) :/ But, given that I build all v2v projects from source, I can run my "virt-builder" binary from guestfs-tools such that it pick up my just-build libguestfs. And so I've now run: $ rm -f fedora-37.img $ LIBGUESTFS_BACKEND=libvirt virt-builder --update fedora-37 $ rm -f fedora-37.img $ LIBGUESTFS_BACKEND=direct virt-builder --update fedora-37 I've verified that "passt" gets launched in both cases. And, the updates do complete: [ 4.4] Downloading: http://builder.libguestfs.org/fedora-37.xz [ 5.2] Planning how to build this image [ 5.2] Uncompressing [ 10.8] Opening the new disk [ 17.3] Setting a random seed [ 17.3] Updating packages [ 166.5] Setting passwords virt-builder: Setting random password of root to VbTWjwUIVAVAXFLV [ 167.3] SELinux relabelling [ 176.7] Finishing off Output file: fedora-37.img Output size: 6.0G Output format: raw Total usable space: 5.9G Free space: 4.0G (67%) [ 3.4] Downloading: http://builder.libguestfs.org/fedora-37.xz [ 4.2] Planning how to build this image [ 4.2] Uncompressing [ 9.9] Opening the new disk [ 14.2] Setting a random seed [ 14.2] Updating packages [ 224.8] Setting passwords virt-builder: Setting random password of root to tT0YGZ9adqTMXzYR [ 225.6] SELinux relabelling [ 234.6] Finishing off Output file: fedora-37.img Output size: 6.0G Output format: raw Total usable space: 5.9G Free space: 4.0G (67%)> It's good that this work has found a bunch of libvirt bugs!Passt is meant to replace slirp, so its different mission statement ("make the guest networking env resemble the host one as much as possible") is justified and welcome; but for the libguestfs appliance, I figured we'd want to hide any slirp/passt differences, preferably with both the direct and libvirt backends. (For example, the rsync test case, which is already restricted to the direct backend, would break due to those differences.) So that requires digging into a bunch of corner cases. It's difficult to know where to draw the line: if a different host IP address (as seen by the guest) breaks our rsync test case, then maybe a different host MAC address, or different guest IP address, might break something else, for someone else. They might have some custom shell script they run in the appliance. So who can say how pedantically we should imitate the slirp environment?... Close imitation was never the intent in the libvirt enablement (and justifiedly so, again, I think), but using just the defaults definitely broke our rsync test case at least. Laszlo