GNOME Boxes Guest OS ip doesn't respect Host Configuration

Ask Fedora
, , , ,
1

I’m facing a bit of a strange issue while using GNOME Boxes on Fedora 39, where one network ip address of the guest OS doesn’t seem to respect the host network configuration.

Host A

  • Fedora 39(upgraded from Fedora 38)
  • Kernel: 6.6.7
  • QEMU: 8.1.3
  • GNOME Boxes: 45.0
$ sudo virsh net-edit default
<network>
  <name>default</name>
  <uuid>37d24d9f-7d52-4415-9beb-f60e59494261</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:73:76:71'/>
  <ip address='192.168.125.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.125.2' end='192.168.125.254'/>
    </dhcp>
  </ip>
</network>

As defined here, the guest machine should take the ip address via DHCP within the range of 192.168.125.2/24.

Guest A

  • CentOS Stream 9(fresh installed)
  • Kernel: 5.14
$ ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> 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 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:f3:c9:6b brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute enp1s0
       valid_lft 86184sec preferred_lft 86184sec
    inet6 fec0::5054:ff:fef3:c96b/64 scope site dynamic noprefixroute 
       valid_lft 86185sec preferred_lft 14185sec
    inet6 fe80::5054:ff:fef3:c96b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

However, the ip address of the guest doesn’t respect the configuration and assigned an ip of 10.0.2.15/24 range. I tried installed other OS(CentOS 7, Debian 12.5 etc) as new guest machines, it all took ip from this range, regardless of the virsh net-edit configuration files.

I even tried specifying a mac binding by adding lines inside <dhcp> like mentioned in this highly voted answer. It appears to do nothing.

Interestingly, during the troubleshooting I tried to replicate the issue on another machine, it behaves just as what was expected.

Host B

  • Fedora 39(upgraded from Fedora 36)
  • Kernel: 6.6.7
  • QEMU: 8.1.3
  • GNOME Boxes: 45.0
$ sudo virsh net-edit default
<network>
  <name>default</name>
  <uuid>89dce599-2651-45be-80f4-c1f1e795de23</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:1e:85:a4'/>
  <ip address='192.168.125.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.125.2' end='192.168.125.254'/>
    </dhcp>
  </ip>
</network>

Despite the almost identical configuration like Host A, this time the configuration take effect for the guest machine, as shown below:

Guest B

  • CentOS Stream 9(fresh installed)
  • Kernel: 5.14
$ ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> 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 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:b2:f9:81 brd ff:ff:ff:ff:ff:ff
    inet 192.168.125.184/24 brd 192.168.125.255 scope global dynamic noprefixroute enp1s0
       valid_lft 3487sec preferred_lft 3487sec
    inet6 fe80::5054:ff:feb2:f981/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

On a side note, I noticed while running Guest B on Host B, I can configure the guest IP in Boxes Preference GUI window while no such thing in Host A with Guest A.

Considering the drastically different behaviors from two identically configured machines, my theory is that some environmental variable or configurations related to guest machine ip assignment was changed in later releases. The existing configuration from Host B that upgraded from earlier Fedora releases was persevered and respected, while the more recent Host A lack this configuration to regulate its behavior. However, I was just not knowledgeable enough on this domain to tell which.

Any suggestions on where else I should look for?

PS: I’ve also tried the solution provided in similar post but not successful.

EDIT: Add tried and failed attempts from existing posts.

2

Check the output:

virsh dumpxml ${VM} --xpath //interface
3

On Host A, it is listed as:

$ virsh dumpxml centos-strea --xpath //interface
<interface type="user">
  <mac address="52:54:00:f3:c9:6b"/>
  <model type="virtio"/>
  <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
4 
VM="centos-strea"
virsh shutdown ${VM}
virsh detach-interface ${VM} user --persistent
virsh attach-interface ${VM} bridge virbr0 --model virtio --persistent
virsh start ${VM}
5

If I read correctly, you are suggesting to turn the current nat into bridge network setup. I’m not sure if that’s what I want…

Thanks,

6

You are confusing user mode networking with virtual bridging.
NAT is still necessary in both cases due to separate subnets.

7

Thanks for correcting me. Like I said, I don’t have much knowledge on this field.

The detach-interface and attach-interface commends were successfully executed, and the virsh dumpxml gives me below on Host A:

$ virsh dumpxml centos-strea --xpath //interface
<interface type="bridge">
  <mac address="52:54:00:6c:35:9e"/>
  <source bridge="virbr0"/>
  <model type="virtio"/>
  <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>

I crossed check the section on Host B, which shows very similar:

$ virsh dumpxml centos-strea --xpath //interface
<interface type="bridge">
  <mac address="52:54:00:b2:f9:81"/>
  <source bridge="virbr0"/>
  <model type="virtio"/>
  <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>

The result is positive. Now the Guest A respect the setup in Host A.

Now I’m curious the reason how this came into. Both VMs were created entirely using gnome-boxes, albeit Guest A was created later than Guest B. Is it a default interface type change that was introduced sometimes?

Many thanks!

1 Like
8

This happens when GNOME Boxes cannot contact the virtual networking service while creating a new VM and then the problem persists in the VM configuration.
The most reasonable explanation is a race condition due to delayed socket activation, therefore explicitly enabling the service should prevent future problems:
Virsh not detecting devices properly - #2 by vgaetera

1 Like