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

[Laszlo Ersek]

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