Re: [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.