On Thu, Jul 13, 2023 at 07:10:46PM +0200, Laszlo Ersek wrote: > Currently we #define NETWORK_ADDRESS as "169.254.0.0". That's a bug in > libguestfs, but it's been invisible -- thus far it's been canceled out by > *independent* bugs in *both* QEMU and libvirt. > > (1) With the direct backend, the current definition of NETWORK_ADDRESS > results in the following QEMU command line option: > > -netdev user,id=usernet,net=169.254.0.0/16 > > According to the QEMU documentation, the "net" property here is supposed > to specify the *exact* IP address that the guest will receive. The guest > however receives 169.254.2.15 (I've checked that with virt-rescue). > > In other words, libguestfs doesn't do what the QEMU documentation says, > and QEMU doesn't do what the QEMU documentation says either. The end > result has been good enough -- but only until now. > > (2) With the libvirt backend, the current definition of NETWORK_ADDRESS > results in the following domain XML snippet: > > <interface type="user"> > <model type="virtio"/> > <ip family="ipv4" address="169.254.0.0" prefix="16"/> > </interface> > > which libvirt translates, in turn, to > > -netdev {"type":"user","net":"169.254.0.0/16","id":"hostnet0"} > > According to the domain XML documentation, the @address attribute here is > again supposed to specify the *exact* IP address that the guest will > receive. However, the guest receives 169.254.2.15 (I've checked that with > virt-rescue). > > In other words, libguestfs doesn't do what the libvirt documentation says, > and libvirt doesn't do what the libvirt documentation says either. The end > result has been good enough -- but only until now. > > Where things break down though is the subsequent passt enablement, in the > rest of this series. For example, when using the libvirt backend together > with passt, libvirt translates the @address attribute to passt's > "--address" option, but passt takes the address *verbatim*, and not as a > subnet base address. That difference is visible in the appliance; for > example, when running virt-rescue on a Fedora 38 image, and issuing "ip > addr". Namely, after enabling passt for the libvirt backend, the > guest-visible IP address changes from 169.254.2.15 to 169.254.0.0, which > is an IP address that makes no sense for an endpoint. > > Fix the latent bug by specifying the actual guest IP address we want, in > NETWORK_ADDRESS. > > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184967 > Signed-off-by: Laszlo Ersek <ler...@redhat.com> > --- > lib/guestfs-internal.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h > index c7ef32277e93..4be351e3d3cc 100644 > --- a/lib/guestfs-internal.h > +++ b/lib/guestfs-internal.h > @@ -155,7 +155,7 @@ cleanup_mutex_unlock (pthread_mutex_t **ptr) > /* Network address and network mask (expressed as address prefix) that the > * appliance will see (if networking is enabled). > */ > -#define NETWORK_ADDRESS "169.254.0.0" > +#define NETWORK_ADDRESS "169.254.2.15" > #define NETWORK_PREFIX "16" > > /* Guestfs handle and associated structures. */
Reviewed-by: Richard W.M. Jones <rjo...@redhat.com> -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs