Hello,
Thank you for the detailed note. My comments in-line. Appreciate your
time in helping me on this issue.
On 6/20/2025 9:54 PM, Stefano Brivio wrote:
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.
I tried using passt on Ubuntu 24.04 LTS (Noble Numbat) but encountered
permission issues. I spent some time debugging without success. Below
are the steps I took. I would appreciate any suggestions for resolving
this issue.
# passt --version
passt unknown version
Copyright Red Hat
GNU General Public License, version 2 or later
<
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
# dpkg -l | grep passt
ii passt 0.0~git20240220.1e6f92b-1 amd64 user-mode networking
daemons for virtual machines and namespaces
Running virt-customize resulted in a different error:
Error with virt-customize:
libguestfs: command: run: passt
libguestfs: command: run: \ --one-off
libguestfs: command: run: \ --socket /tmp/libguestfsJamIlZ/passt.sock
libguestfs: command: run: \ --pid /tmp/libguestfsJamIlZ/passt1.pid
libguestfs: command: run: \ --address 169.254.2.15
libguestfs: command: run: \ --netmask 16
libguestfs: command: run: \ --mac-addr 52:56:00:00:00:02
libguestfs: command: run: \ --gateway 169.254.2.2
Don't run as root. Changing to nobody...
No routable interface for IPv6: IPv6 is disabled
Template interface: enp97s0 (IPv4)
MAC:
host: 52:56:00:00:00:02
DHCP:
assign: 169.254.2.15
mask: 255.255.0.0
router: 169.254.2.2
DNS:
169.254.2.2
DNS search list:
amd.com
UNIX domain socket bound at /tmp/libguestfsJamIlZ/passt.sock
You can now start qemu (>= 7.2, with commit 13c6be96618c):
kvm ... -device virtio-net-pci,netdev=s -netdev
stream,id=s,server=off,addr.type=unix,addr.path=/tmp/libguestfsJamIlZ/passt.sock
or qrap, for earlier qemu versions:
./qrap 5 kvm ... -net socket,fd=5 -net nic,model=virtio
PID file open: Permission denied
libguestfs: trace: launch = -1 (error)
virt-customize: error: libguestfs error: passt exited with status 1
I tested both versions of passt: the one provided by Ubuntu 24.04 and
the Debian passt package. I have attached error logs for both versions.
I also tried modifying AppArmor rules, but it still fails on Ubuntu 24.04:
# aa-disable /etc/apparmor.d/usr.bin.passt
ERROR: Operation {'runbindable'} cannot have a source. Source = AARE('/')
I attempted to stop the AppArmor service, but the issue with passt persists.