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. */ _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs