utmapp / UTM

Virtual machines for iOS and macOS
https://getutm.app
Apache License 2.0
26.56k stars 1.33k forks source link

Networking issues after upgrade to 4.2.5 #5313

Open lelegard opened 1 year ago

lelegard commented 1 year ago

I used to run UTM 4.1.x with two VM: one Ubuntu 23.04 and one Windows 11. In fact, I started with lower versions of macOS, UTM and Ubuntu. Then all updates succeeded without major problem.

Today, I upgraded UTM to 4.2.5 and I now have weird networking issues.

Each VM has one network interface, configured as "shared network". With UTM 4.1.x, the two VM consistently received the following IP addresses each time:

Now, when I boot the various VM, I get this:

Note the new subnet .66 instead of .64.

I did many restarts of the various VM's and I am positively sure that, at some point, the two VM had two different subnets .65 and .66. At that time, the macOS host had two interfaces 192.168.65.1 and 192.168.66.1. Now, for some unknown reason, only .66 is used. I cannot reproduce the situation with two subnets .65 and .66 at the same time but you can see that the subnet moved from .64 to .66.

EDIT 1: After a couple of hours, my Debian VM now boots as 192.168.67.2, jumping to a new subnet .67.

I see no configuration menu for DHCP in UTM. How does the VM receive its IP address? Is there some embedded DHCP server inside UTM? How do you configure it? How can we get stable IP addresses?

Additionally, there is some new weird behavior in the UTM networking GUI since the upgrade to 4.2.5. I just created a new VM and installed Debian 11. The Debian VM gets address 192.168.66.2.

When I edit the configurations of the various VM ("Modify" menu), I get this on the two older VM which were created by some previous version of UTM (can't remember which one exactly). The GUI is in French.

Capture d’écran 2023-05-17 à 16 30 43

And the network choices are:

Capture d’écran 2023-05-17 à 16 31 27

In the new Debian VM, created by UTM 4.2.5, I see this:

Capture d’écran 2023-05-17 à 16 32 48

You can no longer select the NIC type and the advanced settings.

And the network choices are more limited:

Capture d’écran 2023-05-17 à 16 34 49

The "Emulated VLAN" and "Host only" options are gone. But they are still present in the older VM.

Can't we use "Host only" interfaces with new VM? Can't we specify advanced settings, with a fixed address for instance?

EDIT 2: The "Modify" window for the older pre-4.2.5 VM Ubuntu and the new VM Debian are also different. The old one had "QEMU" and "Input" options. The new one has "Boot" and "Virtualization" instead. We can no longer have access to the full QEMU command with new VM.

Older VM options menu layout: Capture d’écran 2023-05-17 à 18 09 46

New VM options menu layout: Capture d’écran 2023-05-17 à 18 10 13

tbussmann commented 1 year ago

while I cannot comment on the networking (subnet) issues, the differences you showed in your "EDIT 1" and "EDIT 2" seem to indicate that your new VMs were created using the "Virtualize" option whereas the older ones were created using the "Emulate" option. With this UTM is using Apples Virtualization framework instead of QEMU as backend. You can choose between these in the first step of the "Create new Virtual Machine" wizard.

lelegard commented 1 year ago

Thanks @tbussmann

Recreating a new Debian VM with QEMU option gives the same result as the previous Ubuntu VM. I probably clicked on some other option when creating the previous Debian VM. It is a pity we cannot review the creation options after the creation.

However, what does "emulate" mean in that case? Not "emulate" in the sense that QEMU can emulate another CPU architecture I suppose. In the past, I have run an "emulated" arm64 Linux system on a native Intel x64 Linux system and the difference of performance between the host and the emulated arm64 system was huge (and expected). Here, the performance of the VM is similar to the host (tested on large compilations) and there must be some other sort of virtualization, under the control of Qemu.

How does Qemu work in that case?

lelegard commented 1 year ago

Also, does this explain the differences in the DHCP behaviour?

alanfranz commented 1 year ago

I'm experiencing a similar networking issue with DHCP, I'm not sure it's version-related, but for sure I hadn't updated UTM in a few months, I updated it just last week and now I'm getting this weird IP change problem: the IP would always be something like 192.168.64.5, and one day it switched to 192.168.65.2. The MAC address of the VM is unchanged.

Scenario: UTM 4.2.5 Apple Virtualization MacOS Ventura 13.3.1 (a) (22E772610a)

ralgozino commented 2 months ago

FWIW I've noticed the same behaviour using other virtualization tools that use Apple's Virtualization Framework underneath them (like multipass or docker desktop).

My understanding is that the subnet used by Apple's Virtualization Framework is the "Internet Sharing" network defined in the /Library/Preferences/SystemConfiguration/com.apple.vmnet.plist file.

I cannot say what triggers it, but from one moment to the other macos decides that the subnet must be changed and uses the following one. A had it change from 192.168.64.0 to 192.168.65.0 and then to 192.168.66.0 with no apparent reason (even without restarting the os). All the VMs that were already running or created previously with the old subnet obviously get affected and their networking breaks because they can't access anything.

I'd really like to know what is triggering the subnet change, but it seems that I am not putting the right keywords in the search engines. This issue is the only related thing that I found with someone experiencing a similar behaviour.

This other issue could be related: