Proxmox VirtIO RNG: /dev/urandom vs /dev/hwrng? Use /dev/urandom. The hardware RNG is slower, can hang your VMs, and adds zero practical security. Here’s the evidence.
What VirtIO RNG actually does
VirtIO RNG passes entropy from the Proxmox host into the guest. The guest’s kernel uses it to seed its own CSPRNG. Without it, a fresh VM can boot with predictable randomness until it gathers enough entropy — bad for SSH keys, TLS, and anything crypto.
Proxmox lets you pick the host-side entropy source in the VM’s hardware settings. The two options are /dev/urandom and /dev/hwrng. The docs don’t explain the difference, so people assume hardware is better. It isn’t.
The problem with /dev/hwrng
/dev/hwrng reads from a hardware random number generator — like Intel RDRAND or a TPM. Sounds great, but on a homelab it’s usually slower than /dev/urandom. Worse, if the hardware RNG is busy or buggy, the read blocks. A blocked read on the host means the guest’s VirtIO RNG request stalls. That can freeze the guest during boot or when it asks for entropy.
I’ve seen a VM hang for 30 seconds on boot because the host’s /dev/hwrng was tied up by another VM. Switching to /dev/urandom fixed it instantly. There’s no reason to put up with that.
Why /dev/urandom is the right choice
/dev/urandom on the host is already a cryptographically secure PRNG. It’s seeded from multiple sources, including the hardware RNG if available. It never blocks. Passing it to the guest via VirtIO RNG is fast and safe.
The guest doesn’t need raw hardware entropy. It needs a good seed to initialize its own CSPRNG. /dev/urandom gives it that. Your VMs won’t be any less secure.
How to set it in Proxmox
In the VM’s hardware tab, add a VirtIO RNG device. For the entropy source, type /dev/urandom. That’s it. No need to pass through a physical device or mess with permissions.
If you’re editing the config directly, it looks like this:
rng0: source=/dev/urandom,max_bytes=1024,period=1000The max_bytes and period control how much entropy is fed per interval. Defaults are fine for most VMs.
My take
This is a classic case of overthinking. Hardware RNG sounds impressive, but /dev/urandom is already good enough. Don’t add a potential hang for zero benefit. Keep it simple.
If you’re worried about entropy on the host itself, check out this post on clocksource issues — sometimes the real problem is elsewhere.
