I Replaced My CAD Workstation With a VM and It Didn't Fall Apart

The idea that sounds wrong at first

Running high-end CAD software inside a virtual machine feels like one of those ideas you immediately dismiss. It's supposed to be slow and glitchy, a compromise at best, especially when the software in question is something like Siemens NX, a tool people usually pair with expensive, dedicated workstations.

Someone actually did it, though. There was no dedicated Windows machine, just a MacBook, a home server, and a stubborn idea that maybe this could work. Against expectations, it booted and ran well. "More than usable," as they put it.

That's when curiosity kicks in, because if this works even decently, it challenges a lot of assumptions about how heavy workloads are supposed to run.

When GPU passthrough stops being optional

The experiment didn't start smoothly. Integrated graphics were the first attempt, and that failed fast, with errors, incompatibility, and all the usual signs that the software wasn't even willing to try.

That's when things got serious. A dedicated GPU, an Intel Arc Pro B50, was passed directly into the VM with full passthrough, nothing shared or half virtualized. At that point the project stops being a casual setup and starts looking like a real workstation.

Even then, it wasn't plug-and-play. One wrong configuration made the entire VM unbootable. Another required ripping out drivers and reinstalling them from scratch, twice.

The pattern is clear: this works, but only if you're willing to fight for it.

The weird fragility of "it works now"

The fact that it runs is only half the story; the other half is how fragile the process feels. The GPU showed up as unrecognized. Drivers froze mid-install. Updates appeared immediately after installing the latest version. It's the kind of behavior that makes you wonder whether the system is stable or just temporarily cooperative.

One moment captures it perfectly: reinstalling the exact same driver sequence suddenly fixed everything, even though nothing had changed.

That's trial-and-error survival, with very little engineering clarity. And yet, once it clicks, it stays working. The setup is chaotic and the outcome is stable, which is a strange balance.

Remote access is the real experience layer

This is where the project moves from "hacky experiment" to something genuinely usable, and the connection method matters more than expected.

At first, it's just standard remote access. Then someone suggests tools like Moonlight or Parsec for proper hardware-accelerated streaming, and the experience changes completely. "Really, really smooth," the builder said after switching.

People underestimate this part. The VM runs on the server and you interact with it remotely, so if that layer is bad, the whole setup feels broken. If it's good, you forget you're not on a native machine.

GPU passthrough gets the attention, but how you see and control the result matters just as much.

Not everyone's ready to abandon bare metal

For all the excitement, there's hesitation. Some users already run similar setups and say it works "fine," but still keep a dual-boot Windows system around.

The reason is that certain applications, especially ones like SolidWorks, still feel better on bare metal, whether for GPU acceleration, edge-case performance, or reliability under heavy load. Virtualization hasn't fully earned that trust yet.

So the divide is clear. One side sees this as the future: flexible, centralized, and hardware agnostic. The other finds it impressive but not quite ready to replace a dedicated machine.

Both are right, depending on how much risk you're willing to tolerate.

The bigger shift hiding underneath

Siemens NX running in a VM is interesting in itself, and it also points to something bigger: your "workstation" doesn't have to be a physical device anymore. It can live on a server, in a rack, accessible from anything.

That's a subtle but powerful shift. Your MacBook becomes the window while the server does the work. Your hardware becomes modular, replaceable, and upgradable without touching your daily device.

It also introduces a new dependency on the setup itself: the configuration and the fragile chain of drivers, passthrough settings, and remote protocols that make it all work. You gain flexibility, and you inherit complexity.

Still, the fact that this works at all, smoothly enough to be "more than usable," is what sticks. Once people see that, they stop asking whether it can work and start asking why they're still doing it the old way.