On Fri, 20 Jun 2025 14:26:11 +0100
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
On Fri, Jun 20, 2025 at 05:12:27PM +0530, Aithal, Srikanth wrote:
> Hello all,
>
> I am encountering an issue with virt-customize when the host kernel, on which
> virt-customize runs, has CONFIG_IPV6_SIT built-in. Below is the error output
> from the command:
>
> virt-customize -a noble-server-cloudimg-amd64.qcow2 --install isc-dhcp-client [
...
> Using the -v verbose option, I discovered that the IP address assigned in the
> QEMU command line was not reflected inside the guest. Here is the relevant ip a
> output from the log:
You would not expect the IP inside the appliance to be the same as
outside. We're using two tools called libslirp & passt to create a
user-level network.
By the way, just to avoid confusion: passt's default behaviour
(stand-alone, not started by libguestfs) is to advertise to the guest
(DHCP / NDP / DHCPv6) addresses and routes copied from the host
interface with the (first) default route.
But with libguestfs, for compatibility with libslirp, passt is also
configured with a fixed address, which won't be the same as the host.
You would see that in passt's own command-line (it's a separate tool,
so you won't see that in QEMU's command line).
> + ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd
> 127.255.255.255 scope host lo valid_lft forever preferred_lft forever inet6 ::1
> /128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc
> pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:12:34:56 brd
> ff:ff:ff:ff:ff:ff inet6 fe80::5054:ff:fe12:3456/64 scope link tentative
> valid_lft forever preferred_lft forever 3: sit0@NONE: mtu 1480 qdisc noqueue
> state UNKNOWN group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 inet6
> ::127.0.0.1/96 scope host valid_lft forever preferred_lft forever
>
> Further debugging revealed that when the host kernel has SIT-related
> configurations enabled (i.e., CONFIG_IPV6_SIT), the supermin appliance, which
> libguestfs uses, inherits the same kernel and initrd. Consequently, the guest
> environment booted by virt-customize includes the sit0 device.
>
> When the sit0 device is present, the primary NIC (eth0) does not receive the
> static IP address assigned by libguestfs in the QEMU command line:
>
> /usr/bin/qemu-system-x86_64 \ -global virtio-blk-pci.scsi=off \ ... -netdev
> user,id=usernet,net=169.254.2.15/16 \ -device virtio-net-pci,netdev=usernet \
In this case it would use libslirp. I'm pretty sure slirp doesn't
support IPv6 at all which is the problem here. But also ...
It kind of does, but it's not enabled by default, and it doesn't
support SLAAC plus a number of mandatory functionalities, at least not
ouf of the box, so, yes, see below...
> I verified this issue on another machine where the host kernel
had no
> SIT-related configurations enabled. On that machine, the same virt-customize
> command with the same Noble image worked correctly. I have attached verbose
> logs for both working and non-working configurations. A diff of these logs
> shows that the sit0 device causes the IP assignment issue with the eth0
> interface.
>
> I have the following queries and would appreciate any responses:
>
> 1. Why does the user network IP not get applied when the sit0 device is
> present in the appliance?
I think the DHCP client tries to configure sit0 as it's the first
interface reported by the kernel and can't do it with the information
provided by libslirp's DHCP server.
No idea about 2. and 3.
> 2. Is there a way to append parameters to the libguestfs QEMU
command line to
> blacklist the sit module in such cases?
> 3. Can we override the kernel and initrd used by libguestfs via the
> virt-customize command line?
> libguestfs: command: run: passt --help
> sh: 1: passt: not found
If you use passt (which supports IPv6) it might work better, or at
least differently ...
...that would be my suggestion as well (apt install passt). It's not
exactly up to date on Ubuntu 24.04, and doesn't look very maintained
(see e.g.
https://bugs.launchpad.net/ubuntu/+source/passt/+bug/2077158,
I maintain the Debian package only), but it should work better than
libslirp anyway, as the appliance can use SLAAC as well.
--
Stefano