PD16 on Big Sur: VM not using the configured MAC Address

I can confirm the workaround from TrentR, above.

Edit the virtual network adapter in the Parallels VM config. Under Advanced Settings, switch from "Virtio" to "Realtek RTL8029AS." Make a note somewhere, so you remember to change it back later.

Virtualizing the Realtek NIC will slow down the network and increase the CPU load on the VM, but it will use the correct MAC address on the Mac's bridged NIC.
 
I had the same problem. My VMs got new IP addresses because the router didn't recognize the MAC addresses. Taking a look at the wireshark traces on both the VM (Windows 8.1) and the host (Big Sur, connected with Wi-Fi) I recognized, that the VM correctly uses the assigned MAC address in the DHCP protocol, but it was replaced by another MAC address on the host. It seems that parallels desktop's network driver somehow kicks in and replaces the MAC address. I adapted the settings in my router and everything works again. I didn't dig deeper into this "problem", but could it be that it has something to do with "MAC Address Randomization" (see e.g. https://www.cablelabs.com/mac-addre...-impacts-wi-fi-and-internet-service-providers)?
 
I'm having this issue too.

Two different ubuntu-based linux VMs running on Big Sur 11.1 on a Mac mini (2018) with a Core i5, 16GB RAM. Doesn't appear to make any difference whether it's configured with the Parallels or Apple hypervisor, I get the same result. 'ifconfig' shows the right MAC address, matching that of the VM config, but the router reports something entirely different.
 
I have this problem too. Is there any solution, please? I tried to change a type of virtual adapter (Virtio, etc.) without success. It is a big limitation for me. Any another suggestion? PLEASE, help me.
 
They say they can't reproduce it, and they could only find one related case to link my issue to. Without more people filing technical reports to help them find common factors for users having a problem, I think assigning static IPs within the guest OS or abandoning the efficiency of Virtio virtual NICs will be the new normal.

If you do file a report, mention this thread. It might help convince them combine reports so they know this is a real issue.
 
Apparently, I had a stroke while writing that last line, and I don't have edit rights for my own post. That should have been:

If you do file a report, mention this thread. It might help them combine reports and knowing there are multiple reports may convince them this is a real issue.
 
I sent reports a long time ago already, but yes, it can not hurt if more people send reports and open support tickets to make sure this is taken seriously.
 
Hi guys! Thank you for paying attention to this issue.
Please try the following workaround:
1. Shut down the Big Sur virtual machine.
2. Open its configuration https://kb.parallels.com/117287 > Hardware > Boot Order > Advanced Settings > Boot flags.
3. Paste the following system flags:

devices.net.vmnet.patch_mac=0
devices.net.vmnet.allocate_mac=0

4. Start the virtual machine and check if the issue still remains.
 
Hi Mikhail,

that looks very promising. I applied it to two of my VMs, and they now use the proper MAC address. Would it be possible to apply this globally in some preference, so that
1) I don't need to repeat this for each of my VMs
2) it already applies when I create a VM from the Recovery Partition - in PD 16 we lost the option to change settings before starting such an installation
 
The boot flags fixed my mac address issue, but now I'm noticing other more troubling issues with the bridge network devices in Parallels 16. Connections are being dropped or cut short using the same configurations that previously worked on Catalina + Parallels 15 ...

Don't try to ask for help with this though, the support team is trained to say "not our problem" as soon as the magic words "bridged networking" are spoken. So even though this is a legitimate Parallels issue I was told they won't help me. I tried to offer them a working reproduction case proving the bridged networking device was doing something horribly wrong but they didn't want to hear it. I guess those of us that rely on these network devices to function are stuck just waiting on a fix someday ...
 
Just as a FYI: The behaviour to use configured MAC-address without replacing them to temporary MAC-addresses is now default in Parallels Desktop 16.5.
Flags "devices.net.vmnet.patch_mac=0; devices.net.vmnet.allocate_mac=0" are not needed anymore
 
You must log in or register to reply here.
Back
Top