Giving a graphics card to a virtual machine: the real obstacle is not the driver, it is the group

Handing a physical graphics card, a disk controller or a capture card directly to a virtual machine is possible. The promise is real: the machine uses that hardware as if it were its own.

But where people get stuck is not the driver. It is the group.

Devices are not handed over one by one

Your motherboard decides which devices can be isolated from each other and sorts them into groups. You cannot hand over a single device from a group; you hand over the whole group.

The consequence: if your graphics card is in the same group as the disk controller, giving the graphics card means giving the disk controller too. That is usually not something you can do, because the server's own disk is there.

So the question to ask when buying hardware is not "will this graphics card work" but "is it in its own group on this motherboard". Grouping is a property of the motherboard, not the card. The same card passes cleanly on one board and not at all on another.

The device disappears from the server

The second surprise: once you hand a device to a virtual machine, the server can no longer use it. It is not a loan, it is a transfer.

The most common version: on a machine with a single graphics card you hand the card to a virtual machine and the server's own screen goes with it. If you can connect remotely that is fine, but when something goes wrong you no longer have the option of plugging in a keyboard and monitor to look.

Passed hardware also takes the freedom to move

For anyone who has built a cluster, this is the most important point: a machine with hardware passthrough usually cannot move to another node.

The reason is simple: the card you handed over is inside this physical machine. Even if the other node has the identical model, it is not the same device.

So the safety net your cluster gives you does not cover that machine. It cannot be moved on maintenance nights and cannot come up on another node during a failure. When you set up passthrough, what you are really choosing is this: mobility, in exchange for performance and direct hardware access.

Memory is no longer flexible either

The fourth and least known constraint: passed-through hardware writes directly into the virtual machine's memory. For that to work, the memory has to stay put.

But the mechanism that stretches memory and takes it back is precisely the one that moves memory around. When both are enabled on the same machine, the driver side runs into trouble.

In practice the rule is: on a machine with hardware passthrough, do not stretch the memory, give it a fixed amount. This means that machine cannot join the "promise more than you have" game described in the previous article. The memory you promised it is genuinely set aside.

The decision sentence

Passthrough is not a gain, it is a trade. What you gain: real hardware speed and access to all of that hardware's abilities. What you lose: portability, the server's use of that device, and memory flexibility.

If you are making that trade knowingly, it is the right tool. If you made it without noticing, you find out on the first maintenance night or at the first failure.

What Atlas does

When Atlas reads the PCI devices on the server, it also reads which isolation group each one is in. So before deciding, you can see the grouping: is the device you want to hand over alone, or is there something next to it that you do not want to give away.

There is also a rule that lands exactly on the last part of this article. If a virtual machine has hardware passthrough defined and memory stretching enabled, Atlas marks it as a warning: together they cause trouble on the driver side. The warning does not just say "there is a problem", it says what to do and takes you straight to the memory setting.

This is a small example of the product's general stance: the configuration itself is valid, nothing errors, but two valid settings make no sense together. Things like that need to be said while you are setting up, not during a failure.