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
