Parallels Desktop 27.0.2 – VMs fail to start after macOS reboot on Apple Silicon

[DiegoB5]

Hi,

I'm experiencing a recurring issue with Parallels Desktop 27.0.2 (build 58673) on an Apple Silicon Mac running macOS 27.0.1.

The problem is that virtual machines stop starting after rebooting macOS. This affects both existing VMs and newly created VMs.

Environment:
- macOS 27.0.1 (26A434)
- Parallels Desktop 27.0.2 (build 58673)
- Apple Silicon
- Parallels installation is the official notarized version
- SIP is enabled

VMs affected:
- Existing Windows 11 ARM VM
- Newly created Debian GNU/Linux 13 ARM64 VM

The important point is that the Debian VM is a completely new VM, so this does not appear to be related to corruption of an existing virtual disk.

What I have observed:

1. Immediately after reinstalling Parallels, the Debian VM was able to boot successfully.
2. After rebooting macOS, the VMs stopped starting again.
3. Creating a new macOS user account and trying to start the VM from that account produces exactly the same result.
4. Therefore the problem does not appear to be related to my macOS user profile.
5. Recreating Parallels network configuration did not resolve the issue.
6. Disconnecting the VM network adapter also did not resolve the issue.

When the VM fails to start, `prl_disp_service` is running normally, but `prl_vm_app` is not started.

For example:

ps aux | grep -E '[p]rl_(disp_service|naptd|vm_app)'

shows `prl_disp_service` and `prl_naptd`, but no `prl_vm_app`.

I also captured a sample of `prl_disp_service`. One thread repeatedly gets stuck around macOS group/user resolution:

initgroups
getgrouplist_internal
search_grouplist
ds_grouplist
_od_rpc_call
XPC
mach_msg

The Parallels log also repeatedly reports:

Resolve user group list

Interestingly, macOS itself can resolve the user and groups immediately. These commands all return normally:

id
groups
id -Gn
dscl . -read /Users/$(whoami) RecordName PrimaryGroupID
dscacheutil -q user -a name "$(whoami)"
dscacheutil -q group -a name admin

I also tested with a completely new local macOS user, with the same result.

There are no obvious virtual disk errors in the logs, and the problem affects a brand-new Debian VM as well as the existing Windows VM.

At this point it looks like `prl_disp_service` is getting stuck before `prl_vm_app` is launched, possibly while preparing the VM configuration or resolving user/group information.

Has anyone seen this behavior with Parallels Desktop 27.0.2 on macOS 27.x?

I can provide the relevant `prl_disp_service` sample, Parallels logs, and any other diagnostics that would be useful.

Thanks.

 

[DiegoB5]

Update / Possible root cause found

I finally managed to identify what appears to be the root cause of the problem.

After reproducing the issue several times, I noticed that when Parallels failed to start the VM, the following conditions were always present:

• [tt]com.apple.pfd[/tt] was not running and repeatedly exited with exit code 3.
• [tt]com.apple.NetworkSharing[/tt] was not running.
• No [tt]vmenet0[/tt], [tt]vmenet1[/tt], etc. interfaces existed.
• [tt]pfctl -s info[/tt] reported:

Status: Disabled

The important part is that this was happening before starting the VM, so Parallels was not causing [tt]pfd[/tt] to fail.

I also found that [tt]pfd[/tt] was repeatedly launched by [tt]launchd[/tt] and immediately terminated with exit code 3. The logs showed errors such as:

XPC_ERROR_CONNECTION_INTERRUPTED
[com.apple.pf:framework] connection error: Connection interrupted
AuthorizationCreate() failed -60008
error obtaining authorization rights
SCDynamicStoreCreateWithOptions() failed: Configuration daemon (not (no longer) available
settings: Cannot allocate memory

The decisive test

The decisive test was manually enabling PF:

sudo pfctl -E

Immediately after doing this, PF became enabled and [tt]pfd[/tt] was able to stay running. [tt]NetworkSharing[/tt] also started successfully, and Parallels was then able to create:

vmenet0
vmenet1
vmenet2

The VM booted normally.

I then rebooted the Mac and confirmed that PF was disabled again by default, reproducing the original problem.

Workaround

I created a LaunchDaemon to automatically enable PF at boot:

/Library/LaunchDaemons/com.dborrajo.enable-pf.plist

with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.dborrajo.enable-pf</string>

    <key>ProgramArguments</key>
    <array>
        <string>/sbin/pfctl</string>
        <string>-E</string>
    </array>

    <key>RunAtLoad</key>
    <true/>

    <key>LaunchOnlyOnce</key>
    <false/>

    <key>StandardOutPath</key>
    <string>/var/log/com.dborrajo.enable-pf.log</string>

    <key>StandardErrorPath</key>
    <string>/var/log/com.dborrajo.enable-pf.err</string>
</dict>
</plist>

I installed it with:

sudo chown root:wheel /Library/LaunchDaemons/com.dborrajo.enable-pf.plist
sudo chmod 644 /Library/LaunchDaemons/com.dborrajo.enable-pf.plist
sudo launchctl bootstrap system /Library/LaunchDaemons/com.dborrajo.enable-pf.plist

After rebooting, PF remained enabled automatically.

Then I launched Parallels without manually running [tt]pfctl -E[/tt], and the VM booted successfully.

At that point the system showed:

PF:
Status: Enabled

PFD:
state = running

NetworkSharing:
state = running

VMNET:
vmenet0
vmenet1
vmenet2

What I believe is happening

At this point I have a reproducible workaround.

This makes me think that the original Parallels VM startup problem is actually related to a macOS 27 PF/pfd initialization issue, which prevents Apple's [tt]vmnet[/tt]/[tt]NetworkSharing[/tt] infrastructure from being initialized correctly.

Parallels then gets stuck waiting for [tt]vmnet[/tt]/NetworkSharing, which is consistent with the threads I previously captured waiting in:

__vmnet_start_interface_block_invoke
_NETRBClientCreateInternal
NETRBXPCSetupAndSend
xpc_connection_send_message_with_reply_sync
mach_msg

and:

vmnet_interface_set_event_callback
_dispatch_sync_f_slow
__DISPATCH_WAIT_FOR_QUEUE__

The important point is that I reproduced the problem with a brand-new Debian ARM64 VM, so this is not specific to my Windows VM or its virtual disk.

I also tested the Windows VM backup and a new Debian VM, and both showed the same startup problem before the PF workaround.

Current status

The workaround is currently working reliably for me, including after a complete macOS reboot.

I have not modified or recreated the virtual disks as part of this workaround.

Parallels Desktop is the official/notarized version:

Parallels Desktop 27.0.2 (build 58673)

and SIP is enabled.

Question

Has anyone else seen [tt]com.apple.pfd[/tt] repeatedly exiting with code 3 when PF is disabled on macOS 27, followed by Parallels being unable to create the [tt]vmenet[/tt] interfaces?

If this is a known macOS 27 issue, it would be useful to know whether there is a proper fix planned, rather than having to force-enable PF with a LaunchDaemon.

I would also appreciate confirmation from Parallels as to whether this PF/pfd/vmnet interaction is a known compatibility issue with macOS 27.