When running cryptographic operations like Kerberos realm setup inside KVM virtual machines, many administrators encounter the frustrating /dev/random starvation issue. Unlike physical hardware, VMs lack direct access to hardware entropy sources like interrupt timings or thermal noise.

# Typical symptom when checking entropy pool
cat /proc/sys/kernel/random/entropy_avail
# Output might show critically low values (<100)

Services like krb5_newrealm depend on sufficient entropy for generating cryptographic keys. In my case, the process hung for hours at "Loading random data" because:

• VM isolation prevents access to host's hardware RNG
• Default Linux entropy harvesting isn't optimized for virtualization
• Cryptographic operations require high-quality randomness

Here are three battle-tested approaches I've implemented:

# Solution 1: Install haveged (works for most cases)
sudo apt-get install haveged
sudo systemctl enable --now haveged

# Solution 2: Pass host's entropy via virtio-rng (KVM-specific)
<devices>
  <rng model='virtio'>
    <backend model='random'>/dev/random</backend>
  </rng>
</devices>

# Solution 3: Use urandom as fallback (less secure)
echo "HRNGDEVICE=/dev/urandom" | sudo tee /etc/default/rng-tools

For KVM environments, passing host entropy via virtio-rng offers the best balance of security and performance:

1. Edit VM configuration:

   
   virsh edit your_vm_name
   

2. Add the RNG device section as shown above
3. Verify inside guest:

   
   ls -l /dev/hwrng  # Should show virtio device
   cat /sys/devices/virtual/misc/hw_random/rng_available
   

Testing entropy collection rates before/after solutions:

Remember that security-sensitive operations should always favor quality over speed. The virtio-rng solution provides the best combination of both.

When running cryptographic operations in virtual machines, you might notice commands like krb5_newrealm hanging at "Loading random data" for hours. This occurs because:

• Virtual machines lack physical hardware interrupts that feed entropy to /dev/random
• The default Linux entropy pool fills very slowly in VMs (often just a few bits per second)
• Cryptographic operations require high-quality randomness for security

First check your current entropy availability:

cat /proc/sys/kernel/random/entropy_avail

In healthy physical systems this typically shows >1000. In VMs you'll often see <100, sometimes single digits.

The best solution is to pass host entropy to the VM using virtio-rng:

<devices>
  <rng model='virtio'>
    <backend model='random'>/dev/random</backend>
  </rng>
</devices>

Add this to your VM's XML configuration via virsh edit, then:

sudo apt install rng-tools
sudo systemctl start rng-tools
sudo systemctl enable rng-tools

If virtio-rng isn't available, install haveged which uses CPU timing jitter:

sudo apt install haveged
sudo systemctl start haveged
sudo systemctl enable haveged

For immediate needs, you can mix /dev/urandom (faster but cryptographically weaker):

sudo rngd -r /dev/urandom -o /dev/random -f

Note this is less secure for production environments.

After implementing any solution, monitor entropy levels:

watch -n 1 cat /proc/sys/kernel/random/entropy_avail

You should see values consistently above 1000 for cryptographic operations.

With proper entropy sources:

• Kerberos realm creation completes in seconds instead of hours
• SSL/TLS operations initialize immediately
• No more hangs during cryptographic operations