usbipd-win: sharing local USB devices with Hyper-V guests and WSL 2

What usbipd-win actually solves on a Windows host

A USB device is physically bound to one machine. If you are running a Linux workload in a Hyper-V guest or in WSL 2, the guest cannot see that device, and no amount of configuration inside the guest changes that. usbipd-win addresses the host side of this problem: it turns the Windows machine into a USB/IP server, so a remote client can enumerate and attach a device as if it were plugged into the client.

The audience is narrow and specific. You need Windows 10 x64 or ARM64, or Windows Server 2019 version 1809 or newer, and you need a Linux side that speaks USB/IP. The README states the software does not depend on any other software, which matters because it means the installer is the whole story on the host. Typical users are developers who flash or debug hardware from a Linux toolchain while their laptop runs Windows, and administrators who keep a USB dongle on a physical host and hand it to a virtual machine.

The project is written in C#. The repository layout shows a Usbipd directory for the service and CLI, a Usbipd.PowerShell directory, a Drivers directory, an Installer directory, and a UnitTests directory, so the service, the driver component and the packaging are separate build units. The licence is GPL-3.0, which is worth noting before you consider embedding any of it.

The bind and attach split, and why it is the whole design

usbipd-win separates two operations that are easy to conflate. Binding happens on the Windows host and is persistent. Attaching happens from the client side and is not persistent.

On the host, the README gives this sequence with administrator privileges: usbipd --help, then usbipd list to enumerate devices with their busids, then usbipd bind --busid=<BUSID> to export one. The README states that sharing a device is persistent and survives reboots. That is a real design decision, not an incidental detail: once bound, the device stays claimed by the USB/IP server across restarts until you unbind it.

On the client side, the README states that attaching is non-persistent, and that you have to re-attach after a reboot, or when the device resets or is physically unplugged and replugged. For WSL 2, the attach command runs from Windows and does not require administrator privileges. For other Linux machines, the standard usbip client tools are used against the host.

The consequence is a state machine you have to internalise. Bind once, attach often. If a device behaves oddly after a reset, the first thing to check is whether the attach is still in place, not whether the bind survived. The README is explicit that the bind survives reboots; it says nothing about the attach doing so, because it does not.

Installing usbipd-win on Windows 10 or Windows 11

There are two documented installation paths. The first is running the .msi from the latest release on the machine where the USB device is physically connected. The second is the Windows Package Manager, which is the one most people will want.

winget install usbipd

After that command, three things should exist on the machine. A service named usbipd with the display name USBIP Device Host, which you can check in the Services app. A command line tool also called usbipd, whose location is added to the PATH environment variable. And a firewall rule named usbipd that allows all local subnets to connect to the service. The README notes that you can modify this firewall rule to fine tune access control, which is the intended knob if the default scope is wider than you want.

One caveat the README raises directly: if you run a third-party firewall, you may have to reconfigure it to allow incoming connections on TCP port 3240. The built-in rule does not help you there.

To inspect the tool before committing to anything, the help output is the documented starting point:

usbipd --help
usbipd list

The list command is what you run to find the busid you will need for every later operation. The README also points to a wiki page on enabling tab completion for PowerShell, which is a quality of life improvement rather than a requirement.

Sharing a device and attaching it inside WSL 2

The end-to-end flow for WSL 2 has three commands, and the privilege requirements differ between them. Listing and binding need administrator privileges on Windows. Attaching to WSL 2 does not.

usbipd list
usbipd bind --busid=<BUSID>
usbipd attach --wsl --busid=<BUSID>

After the bind, the device is exported and stays exported across reboots. After the attach, the device should appear inside the WSL 2 instance as a USB device. If it does not, the README points at the kernel: update WSL 2 with wsl --update to get the latest kernel, which the README says supports most USB devices. For devices the default kernel does not cover, the README directs you to a wiki page on WSL support that explains how to add drivers.

For a non-WSL 2 Linux client, the flow moves to the client machine and uses the standard USB/IP tooling:

usbip list --remote=<HOST>
sudo usbip attach --remote=<HOST> --busid=<BUSID>

Here the busid is the one reported by the remote listing, and the attach needs root on the client. The README notes that client-side tooling exists for other operating systems such as Microsoft Windows, but not as part of this project. That sentence is doing real work: it tells you the project's boundary is the Windows host side, and that anything you find for a Windows client comes from somewhere else and carries its own support story.

Where usbipd-win is the wrong tool

The most common wrong expectation is simultaneous access. The README describes binding as sharing a device with USB/IP clients, and the practical reading is that the device is handed over. If your workflow needs the device enumerated in Windows and in the guest at the same time, this is not the project for you, and the README offers no mechanism for that.

The second limitation is the attach lifecycle. Because attaching is non-persistent and must be redone after a reboot, a device reset, or a physical unplug and replug, any unattended workflow has to cope with the device disappearing. The README states this plainly rather than hiding it, but it is easy to miss when you are evaluating the tool from a single successful test.

Driver coverage inside the guest is the third boundary. The README's own advice is to run wsl --update for the latest kernel and to consult a wiki page for devices the default kernel does not support. That means a device class the kernel has no driver for will not work no matter how correctly you bind and attach it. The failure looks like a successful attach with nothing usable on the other side.

Finally, the README points to a wiki page listing tested devices. That page is the honest answer to whether a specific piece of hardware is known to work, and its existence implies that not all hardware is.

How usbipd-win compares with running Linux on the hardware

The obvious alternative is to stop sharing altogether: run the Linux workload on a machine that has the USB device attached, or dual boot. That removes the USB/IP layer, the bind and attach lifecycle, and the kernel driver question, at the cost of giving up the Windows host you presumably need for something else.

A second alternative, for WSL 2 users specifically, is to accept that WSL 2 is not the right place for the device and to use a full Hyper-V guest instead. The README treats both as supported targets, and the difference in approach is visible in the commands: WSL 2 attaches from Windows with usbipd attach --wsl and no administrator rights, while a non-WSL 2 Linux guest attaches from inside the guest using the usbip client tools with sudo. The WSL 2 path is shorter, but it inherits the WSL 2 kernel's driver coverage, which is exactly the constraint the README tells you to address with wsl --update and the wiki.

A third comparison is with the GUI and IDE integration tools the README links from its wiki. Those are not alternatives to usbipd-win; they are front ends over the same service. If you prefer a graphical interface over the CLI, the README's position is that you find one from that list rather than expecting one in the box. The core product is the service and the usbipd command.

Maintenance, licence and the upgrade path

The repository is not archived, and the last push was on 2026-09-22. Releases are tagged with both a version and a product name, for example v5.3.0 (usbipd-win 5.3.0) on 2025-10-11, v5.2.0 on 2025-08-14 and v5.1.0 on 2025-05-24. That cadence suggests the project is still moving, though the README does not document a rollback procedure, so an upgrade that misbehaves has no documented way back other than reinstalling an earlier .msi from the releases page.

Upgrade cost is low on the surface because winget handles both directions:

winget install usbipd
winget uninstall usbipd

The README also documents removal through Add/Remove Programs or Settings/Apps. The thing to think about before upgrading is the persistent bind state. The README says sharing survives reboots but says nothing about what an upgrade does to existing bound devices, so if you have devices bound in a lab, re-check usbipd list after the upgrade rather than assuming.

The licence is GPL-3.0, and the repository carries a COPYING.md, a LICENSES directory and REUSE status tooling, which indicates the project takes licence hygiene seriously. GPL-3.0 is a copyleft licence, so if you are considering shipping any part of this inside a product, that is a question for your own legal review, not something this article can settle. For ordinary use as an installed Windows service, the licence is not a practical obstacle.

Editorial conclusion

Adopt usbipd-win when your USB device lives on a Windows host and a Linux VM or WSL 2 instance needs direct access to it, and when you can keep the bind step in your provisioning notes. Do not adopt it if you need the device visible to Windows and the guest at the same time, or if you need a supported client implementation on macOS or Windows, since the README states client-side tooling for those systems is not part of this project. Before rolling it out, verify three things: that the device appears in usbipd list with a busid, that your third-party firewall allows incoming TCP 3240, and that the default WSL 2 kernel supports the device class or that you have added the driver the wiki describes.

Frequently asked questions

Official sources

1. dorssel/usbipd-win on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases