On Wed, Sep 17, 2025 at 04:02:12PM +0200, Pavel Mores wrote:
On Wed, Sep 17, 2025 at 3:05 PM Martin Kletzander <mkletzan@redhat.com> wrote:
On Wed, Sep 17, 2025 at 02:14:51PM +0200, Pavel Mores via Users wrote:
Hi,
I'm examining a domain that's connected to the 'default' network
# virsh net-dumpxml default <network connections='1'> <name>default</name> <uuid>c757baa7-2b31-4794-9dfb-0df384575602</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:37:b7:92'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254'/> </dhcp> </ip> </network>
This is standard.
using a device as follows:
<interface type='network'> <mac address='52:54:00:ed:06:2e'/> <source network='default' portid='83db8ca9-baed-47f3-ba0d-1a967ee86aa5' bridge='virbr0'/> <target dev='vnet19'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface>
This looks fine.
The domain is running but apparently without an IP address:
# virsh domifaddr podvm-podsandbox-totok-8f10756a Name MAC address Protocol Address
-------------------------------------------------------------------------------
This shows that libvirt does not know about any IP address. Does adding "--source agent", "--source arp" or "--source lease" change anything?
'arp' and 'lease' don't but
# virsh domifaddr --source agent podvm-podsandbox-totok-8f10756a error: Failed to query for interfaces addresses error: argument unsupported: QEMU guest agent is not configured
This is surprising to me since this is a peer pods setup where the domain in question is a podvm running an image which I was told does have the qemu agent running.
However the agent shouldn't be necessary for IP address acquisition I guess, right?
The requisite host-side interfaces look good (to me anyway :-)):
10: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 1000 link/ether 52:54:00:37:b7:92 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever [...] 35: vnet19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
master
virbr0 state UNKNOWN group default qlen 1000 link/ether fe:54:00:ed:06:2e brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:feed:62e/64 scope link proto kernel_ll valid_lft forever preferred_lft forever
I can share more information about the setup if necessary but I'll stop here for now since I feel this must be just a simple stupid oversight on my part. Please let me know if you'd like to have additional info.
When this happens to me sometimes, it's most often a firewall issue and the VM does not get any IP address or cannot communicate outside its network.
I've seen a firewall suggested as a possible culprit, yes, however I don't quite know what it should look like. iptables appear unconfigured:
# iptables -L -v -n Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination
`nft list ruleset` lists only rules that look managed by libvirt itself(*). At any rate the host machine has no specific hand-configured firewall that I know of.
What it can be here is that there are some access issues to the dnsmasq lease file.
What's in your /var/lib/libvirt/dnsmasq/virbr0.status file on the host?
It's empty.
Thanks Martin! pvl
(*) # nft list ruleset table ip libvirt_network { chain forward { type filter hook forward priority filter; policy accept; counter packets 85854914 bytes 398726525237 jump guest_cross counter packets 85854914 bytes 398726525237 jump guest_input counter packets 34777368 bytes 3386943972 jump guest_output }
chain guest_output { ip saddr 192.168.122.0/24 iif "virbr0" counter packets 0 bytes 0 accept
This suggests there were no incoming packets from an IP address in the range on the bridge.
iif "virbr0" counter packets 0 bytes 0 reject
And no packets from outside of that range that would fall through to this above rule. [...]
}
chain guest_input {
[...]
oif "virbr0" ip daddr 192.168.122.0/24 ct state established,related counter packets 0 bytes 0 accept
No packets sent to the address range on the bridge, but
oif "virbr0" counter packets 0 bytes 0 reject
basically no packets sent at all.
}
chain guest_cross { iif "openshift-412" oif "openshift-412" counter packets 0 bytes 0 accept iif "openshift-419" oif "openshift-419" counter packets 0 bytes 0 accept iif "openshift-416" oif "openshift-416" counter packets 0 bytes 0 accept iif "openshift-415" oif "openshift-415" counter packets 0 bytes 0 accept iif "openshift-413" oif "openshift-413" counter packets 0 bytes 0 accept iif "virbr0" oif "virbr0" counter packets 0 bytes 0 accept
No intra-network communication [...]
chain guest_nat { type nat hook postrouting priority srcnat; policy accept;
[...]
ip saddr 192.168.122.0/24 ip daddr 224.0.0.0/24 counter packets 50 bytes 3676 return
There were some IPv4 multicast packets, but these could've originated from the host.
ip saddr 192.168.122.0/24 ip daddr 255.255.255.255 counter packets 0 bytes 0 return
And no broadcast packets from the address space.
meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535 meta l4proto udp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535 ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade
No NAT, anything. [...]
ip saddr 192.168.14.0/24 ip daddr 224.0.0.0/24 counter packets 50 bytes 3675 return
These counters on another range are the same, so I would say all the multicast packets on the range we are interested in are just the same, hence having nothing to do with the guest.
} } table ip6 libvirt_network { chain forward { type filter hook forward priority filter; policy accept; counter packets 0 bytes 0 jump guest_cross counter packets 0 bytes 0 jump guest_input counter packets 0 bytes 0 jump guest_output
And totally nothing with IPv6. My "guess" would be that the guest did not even get an IP address, maybe did not eve try DHCP. Are you sure the guest booted?