On Fri, Jul 14, 2023 at 12:41:52PM +0200, Laszlo Ersek wrote: > 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.
We should concentrate on making virt-customize work. The rsync case (and API) is weird and not worth worrying about at this point. If it breaks that might in a way be better -- we can then justify removing it after a few releases. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
