UTM icon indicating copy to clipboard operation
UTM copied to clipboard

Bridged Network - connection between macOS host and macOS guest is lost after 1-2 mins

Open ChristophM2000 opened this issue 9 months ago • 3 comments

Configuration

  • UTM Version: 4.6.4
  • macOS Version: Sequioa 15.4
  • Mac Chip: M3

I have an Apple Mac M3 host with macOS Sequioa 15.4 and UTM running with a guest also with macOS Sequioa 15.4. When I restart the VM, everything is fine. I can access the guest from the host and vice versa. I can also access the guest from an external Mac in the network.

But after a random time, suddenly no connection is possible between host and guest and vice versa. The strange thing is that the external Mac can always access the guest.

If I press ‘Renew DHCP lease’ in macOS guest or deactivate and activate Ethernet, the connection between host and guest works again for a short time of maybe 1-2 minutes before it drops again. Sometimes the connection remains active a little longer after restarting the VM. I have no idea what the problem is and it is very annoying that I have to restart my guest network dozens of times a day. Does anyone here have a solution?

ChristophM2000 avatar Apr 10 '25 14:04 ChristophM2000

I have more or less the same issue:

Host: Apple M3 Pro, MacOS 15.4 UTM: 4.6.4 (107) Guest: Gentoo linux

After a random time the guest fails to renew the DHCP lease. It seems like the UTM's internal DHCP server does not provide the required information anymore. This leads to a discard of the guest's IP address and is therefore not accessible anymore. Only a hard reset of the VM solves the issue for a short time for me.

This issue came up either since the last UTM update or with the last MacOS Update (15.4).

Normal/expected behavior (according to the guest's logs):

Apr 22 11:32:49 virtualdev /etc/init.d/net.enp0s1[1905]: config_enp0s1 not specified; defaulting to DHCP Apr 22 11:32:49 virtualdev dhcpcd[1916]: dhcpcd-10.2.2 starting Apr 22 11:32:49 virtualdev dhcpcd[1918]: DUID 00:01:00:01:2d:91:e4:d1:72:8b:0e:38:5b:8a Apr 22 11:32:49 virtualdev dhcpcd[1918]: enp0s1: IAID 0e:38:5b:8a Apr 22 11:32:49 virtualdev dhcpcd[1918]: enp0s1: soliciting a DHCP lease Apr 22 11:32:49 virtualdev dhcpcd[1918]: enp0s1: offered 192.168.64.4 from 192.168.64.1 hostname.domain.tld Apr 22 11:32:50 virtualdev dhcpcd[1918]: enp0s1: probing address 192.168.64.4/24 Apr 22 11:32:54 virtualdev dhcpcd[1918]: enp0s1: leased 192.168.64.4 for 3600 seconds Apr 22 11:32:54 virtualdev dhcpcd[1918]: enp0s1: adding route to 192.168.64.0/24 Apr 22 11:32:54 virtualdev dhcpcd[1918]: enp0s1: adding default route via 192.168.64.1

Problematic behavior:

Apr 22 09:27:27 virtualdev dhcpcd[1920]: enp0s1: failed to renew DHCP, rebinding Apr 22 09:34:57 virtualdev dhcpcd[1920]: enp0s1: DHCP lease expired Apr 22 09:34:57 virtualdev dhcpcd[1920]: enp0s1: deleting route to 192.168.64.0/24 Apr 22 09:34:57 virtualdev dhcpcd[1920]: enp0s1: deleting default route via 192.168.64.1 Apr 22 09:34:57 virtualdev dhcpcd[1920]: enp0s1: soliciting a DHCP lease Apr 22 09:35:02 virtualdev dhcpcd[1920]: enp0s1: probing for an IPv4LL address Apr 22 09:35:05 virtualdev dhcpcd[1920]: enp0s1: changing route to fdfa:7c31:3dca:eca9::/64 Apr 22 09:35:05 virtualdev dhcpcd[1920]: enp0s1: changing default route via fe80::80a9:97ff:fea1:5664 Apr 22 09:35:07 virtualdev dhcpcd[1920]: enp0s1: using IPv4LL address 169.254.237.247 Apr 22 09:35:07 virtualdev dhcpcd[1920]: enp0s1: adding route to 169.254.0.0/16

c-krause avatar Apr 24 '25 07:04 c-krause

same issue:

  • UTM Version: 4.6.5(108)
  • macOS Version: Sequioa 15.4.1
  • Mac Chip: M4

i-tengfei avatar May 15 '25 09:05 i-tengfei

After updating MacOS to 15.5 and UTM to 4.6.5 i still have the same issue.

It seems like only M3 and M4 chips are affected as several colleagues of mine that have the same setup but an M2 chip never saw this issue.

c-krause avatar May 21 '25 11:05 c-krause