-
Bug
-
Resolution: Done-Errata
-
Normal
-
rhel-10.0.beta
-
libvirt-10.10.0-7.el10
-
None
-
Low
-
rhel-virt-core-libvirt-2
-
ssg_virtualization
-
29
-
3
-
False
-
False
-
-
None
-
None
-
Pass
-
RegressionOnly
-
-
All
-
None
This specific issue was reported as point 1. in the description of https://issues.redhat.com/browse/RHEL-7306, and it becomes rather relevant now because of https://issues.redhat.com/browse/RHEL-45241: libvirt documentation states that the "address" attribute from an "ip" element inside a "user" (network) interface is used by QEMU (via libslirp) as address in the guest.
However, that's not the case: if the user use a network identifier (say, 169.254.0.0, with the subnet mask being 255.255.0.0) in the "address" attribute, libslirp uses this "address" (not a usable IP address) as prefix, rather, and replaces it with 169.254.2.15.
passt, however, doesn't: the address will be configured as 169.254.0.0. So, if a user takes the (wrong) libslirp example and changes the back-end to passt, the address will actually change, and unexpectedly so.
This should be fixed by changing the example in the documentation, or clarifying this aspect.
- blocks
-
RHEL-45518 Use passt as the default userspace networking solution (libvirt)
-
- Closed
-
- is cloned by
-
RHEL-46602 libvirt doesn't configure default gateway for passt network back-end
-
- New
-
- links to
-
RHSA-2024:140012 libvirt bug fix and enhancement update