Stop QEMU from stealing your host entropy and stalling your VMs

Technical Briefing | 8/19/2026

You probably have seen a VM hang during boot or act sluggish when performing cryptographic operations. It is rarely the CPU. Instead, your VM is starving for randomness because the host kernel’s entropy pool is drained. When your virtualized guest tries to pull from /dev/random and the host cannot keep up, QEMU blocks the entire vCPU thread waiting for bits. I have seen production web servers take minutes to generate RSA keys because of this exact bottleneck.

Why virtio-rng is not just a performance tweak

The fix is to offload entropy generation to a hardware source or a jitter-based provider and pass it through to the guest via virtio-rng. This prevents the guest from hammering the host’s entropy pool. If you have an Intel CPU with RDRAND support, you should point QEMU directly to it. This takes the guest out of the host’s entropy starvation loop entirely.

virsh edit my-vm-name
<devices>
<rng model='virtio'>
<backend model='random'>/dev/urandom</backend>
</rng>
</devices>

• Verify your host CPU supports hardware-based random numbers using grep rdrand /proc/cpuinfo
• Avoid mapping /dev/random directly as the backend because it is blocking and will cause the exact lockup you are trying to solve
• Check /sys/class/misc/hw_random/rng_current on the host to see which engine your hardware is actually using

If you are running older kernels on the host, this becomes even more painful because the entropy pool might not be reseeded as aggressively as it is in newer releases. Once you move your guests over to a dedicated virtio-rng device, the unexplained delays during SSH key generation or service startups usually vanish. Keep an eye on your guest dmesg; if you see logs about entropy exhaustion, don’t wait for a site-wide outage to swap the backend.