Two Keyboards, One Mac: Giving a Parallels VM Its Own Input Devices

I keep a Windows VM open all day on my MacBook, and I got tired of alt-tabbing into it. What I wanted was not complicated: one keyboard and mouse for macOS, a second set that drives only the VM, both working at the same time.

macOS does not want you to have this.

Plug in a second keyboard and you do not get a second cursor. You get the same cursor, moved by two hands. The HID layer merges every attached device into one event stream before any application sees it, and whichever window has focus receives all of it. X11 on Linux has multi-pointer support. macOS has nothing equivalent, and no utility you install on the Mac fixes it, because the merge happens below the level anything in userspace can reach.

Almost every answer I found while searching says this is impossible and suggests buying a second machine. That is wrong, and I can prove it in one command.

Tested on: MacBook Pro (M4 Pro), macOS 26.4.1, Parallels Desktop 27.0.0 with a Windows 11 ARM guest, and UTM 4.7.5 on its QEMU backend.

The idea: stop trying to share

The usual advice (run the VM in a window, click into it, type) is not a second workstation. It's the same workstation with an extra window, and every keystroke still has to be aimed by moving focus around.

The move that works is the opposite of sharing. Take the device away from macOS entirely and give it to the guest at the USB level. Once the host does not own the hardware, there is nothing to share and nothing to fight over.

Passed through, the dongle never enters the host's event stream at all. Its input goes to the guest's own driver stack, which is why window focus no longer matters. That last part is the whole feature.

What you need

• A USB second set. A 2.4 GHz keyboard-and-mouse combo on a single receiver is ideal, because one dongle is one passthrough and it covers both devices.

• A separate primary set for the Mac. Bluetooth is perfect, since Bluetooth peripherals belong to the host's Bluetooth stack and are never candidates for USB passthrough. The two mechanisms cannot collide.

• A second display. Not required. It's what turns this from a trick into a desk.

Order matters. Do not pass through the only input device you have. While a device is assigned to the guest, macOS cannot see it at all, including at the login screen. VMware takes this seriously enough to block HID passthrough by default in Fusion, in their words because of the risk of removing all human interface from the Mac. Make sure the Mac has its own set first.

Step 1: Find the device

Parallels ships a CLI that lists every USB device it can see and who currently owns it:

prlsrvctl usb list

Device: 'Wireless Device'  :
  Name: 'Wireless Device'
  System name: '2120000|3151|3022|full|--|b120300001'
  Present-On-Host: YES
  Connected-To-Vm: NO

That long system name is the handle you'll use everywhere else: bus address, vendor ID, product ID, speed and instance, pipe-separated. Yours will differ. Copy your own.

Mine is a no-name combo whose receiver reports itself as YICHIP, vendor 0x3151. Before committing, it's worth checking what the receiver actually presents:

ioreg -c IOHIDDevice -r -d 1 | grep -A4 YICHIP

"Product"          = "Wireless Device"
"Transport"        = "USB"
"PrimaryUsagePage" = 1
"PrimaryUsage"     = 6      <- keyboard
"PrimaryUsage"     = 2      <- mouse

Usage page 1 with usage 6 is a keyboard, usage 2 is a mouse. One dongle, both devices. That is exactly why a combo set is the right hardware for this.

Step 2: Hand it to the VM

With the VM running, connect the device. Either the system name or the friendly name works:

prlctl set "Windows 11" --device-connect 'Wireless Device'

Connect device: Wireless Device
The device successfully connected
The VM has been successfully configured.

The keyboard and mouse stop working on the Mac at this moment. That's the desired outcome, not a failure.

Step 3: Prove the host really let go

This is the step most write-ups skip, and it's the only one that separates a real passthrough from a VM that is merely receiving forwarded events.

Ask macOS whether the device still exists in its HID registry. The answer you want is zero:

ioreg -c IOHIDDevice -r -d 1 | grep -c YICHIP
# 0

prlsrvctl usb list | grep -A6 'Wireless Device'
#   Present-On-Host: YES
#   Connected-To-Vm: YES

Zero HID entries on the host, Connected-To-Vm: YES on the Parallels side. The device is gone from macOS's input system. Nothing you type on it can reach a Mac application, because as far as macOS is concerned the hardware is not attached.

Then move the second mouse. The Windows cursor should move while a macOS app is focused and the VM window is not. That's the whole feature, and it's faster to confirm by hand than by any amount of tooling.

Step 4: Make it survive a replug

A live connection is not a setting. Record a permanent rule so the dongle goes straight to the guest whenever it appears, whether after a reboot, a sleep cycle, or an actual unplug:

prlsrvctl usb set '2120000|3151|3022|full|--|b120300001' "Windows 11"

Confirm it stuck by looking for Autoconnect-Action: guest in prlsrvctl usb list.

Here's where I lost an hour. My receiver already had an autoconnect rule pointing at the VM, listed exactly as it should be, and the device was still not attached. I assumed the rule meant it was working. It wasn't.

usb set writes the rule, and the rule only fires when a device is plugged in. On a receiver that is already plugged in, it does nothing at all until you run --device-connect once by hand. The Parallels documentation does not mention this anywhere I could find, and it is the single most likely reason this looks broken for you.

Step 5: Stop the two sets fighting

Passthrough solves ownership. It does not solve the layout problem: Windows still has exactly one cursor, and Parallels' integrated pointer drives that same cursor whenever the macOS pointer is over the VM window.

Turn off mouse capture. "Optimize mouse for games" locks the host pointer inside the VM window on click, and you need a key combination to escape. With a dedicated guest mouse you never want that:

prlctl set "Windows 11" --smart-mouse-optimize off

Put the guest on its own display. Run the VM full-screen on the second monitor and leave it there. The rule that keeps the two sets independent then becomes a physical one, easy to obey without thinking:

Keep the macOS pointer off the VM's display. Set 1 drives the Mac, set 2 drives Windows, and they never touch. Move the Mac pointer onto the VM and it will start moving the Windows cursor too. Not broken, just both sets aimed at the same guest.

When it doesn't work

Three things went wrong for me here, and none of them appear in any documentation.

The rule looks right but nothing happens. Covered above. usb set needs a plug-in event. Run --device-connect once by hand.

A USB hub with an autoconnect rule takes everything with it. I have a 7-in-1 hub that had picked up a guest autoconnect rule at some point. While that rule is active, every device plugged into the hub goes to Windows rather than macOS. If devices are vanishing from the Mac unexpectedly, run prlsrvctl usb list and look at what else has Autoconnect-Action: guest. Clear it with:

prlsrvctl usb del '<system name of the hub>'

You cannot script the check from inside the guest. I tried to verify from Windows with prlctl exec and got "Unable to open new session in this virtual machine" despite Parallels Tools being installed and current. Verify from the host with ioreg instead. It is a better check anyway, because it tests the thing that actually matters.

Other hypervisors

The underlying requirement is the same everywhere: the host has to release the HID rather than share it. I tested Parallels and UTM myself. The VMware and VirtualBox notes below come from their own documentation, and I have flagged them as such.

VMware Fusion (documented, not tested by me). There is an official KB for this exact use case, Connecting a second mouse or keyboard directly to a Fusion virtual machine. Fusion refuses HID passthrough by default, deliberately, because you can lock yourself out of your own Mac. You enable it with:

usb.generic.allowHID = "TRUE"
usb.generic.allowLastHID = "TRUE"

The second line permits taking the last remaining HID, which is the one that leaves you with no input at all. On Fusion 13 these belong in the global config at /Library/Preferences/VMware Fusion/config rather than in the VM's .vmx.

UTM. I did test this one, because it's free. It works, and it behaves exactly like Parallels, but the setting is off by default, and it is hidden in a place you would not expect.

Create the VM, then open its settings and go to Input. Under USB Sharing there's a checkbox, Share USB devices from host, unchecked, with a Maximum Shared USB Devices count beside it. Until you tick that, utmctl usb list answers "No devices found. Make sure a USB sharing enabled VM is running", which is true, but it does not tell you where the setting is.

With it enabled and the VM running:

utmctl usb list
# Name                    VID :PID   Location
# Wireless Device (2:2)   3151:3022  131074

utmctl usb connect "Virtual Machine" 3151:3022

Then the same check as before, on the host:

ioreg -c IOHIDDevice -r -d 1 | grep -c YICHIP
# 0

Two entries before the connect, zero after. That is the whole point of showing it: this is not a Parallels feature. It's what exclusive USB ownership does, whoever implements it.

One thing to watch. UTM has two backends and picks between them from your answers in the creation wizard. The Summary screen names it under Engine. If yours says anything other than QEMU you are on Apple Virtualization, which cannot do USB passthrough at all, and there will be no USB Sharing section to find.

VirtualBox (documented, not tested by me). USB 2.0 and 3.0 filters require the Extension Pack, whose licence is not free for commercial use. Worth knowing before you plan around it.

What this does and doesn't give you

Behaviour	Works	Why
Type into Windows while a Mac app is focused	Yes	Input reaches the guest's driver stack, not the host's window server
Two people working at once	Yes	Two displays, two sets, two independent focus states
Copy-paste between the two sets	Yes	Parallels' shared clipboard is unaffected by passthrough
Second set also works on the Mac	No	Exclusive by design, so macOS cannot see the device at all
Pass a Bluetooth keyboard to the guest	No	Not a USB device. Bluetooth peripherals belong to the host stack
Two independent cursors inside Windows	No	Windows has one pointer; the guest mouse and the integrated pointer share it

Questions I had along the way

Can two people use one Mac at the same time? Sort of. Not two macOS sessions, but one person on macOS and one in the VM, which is what this setup is. macOS has no multi-seat mode.

Can I use a second keyboard only for the VM? That is exactly what passthrough does. While the device is attached to the guest, macOS cannot see it at all.

Why do both my keyboards control the same cursor? Because macOS merges every HID into a single event stream before any app sees it. Nothing installed on the Mac side changes that.

Does this work with a Bluetooth keyboard? Not this way. Bluetooth peripherals belong to the host's Bluetooth stack and are not USB devices, so there is nothing to pass through.

Will the second set still work on the Mac? No, and that is the point. Ownership is exclusive.

Do I need Parallels Pro? No. prlctl and prlsrvctl ship with the standard edition.

Undoing it

Both halves are reversible, and you need both, because releasing the device does not delete the rule that will re-grab it:

prlctl set "Windows 11" --device-disconnect 'Wireless Device'
prlsrvctl usb del '2120000|3151|3022|full|--|b120300001'
prlctl set "Windows 11" --smart-mouse-optimize auto

The part worth remembering

The instinct with a problem like this is to look for software that splits input: a driver, a remapper, something clever sitting in the event stream. Nothing in that category works on macOS, because the merge happens below where any of it can reach.

What works is giving the hardware away. Ownership is the only knob macOS actually exposes, and a hypervisor is the one thing that can take a device off it cleanly.

So the check that matters is not "does the guest respond" but "has the host forgotten". ioreg returning zero is the whole proof.