The X86 answer is make sure your VM doesn't trap RdRand or RdSeed. You trust your VM for many things, this is one of them.
A sufficiently recent RNGd on a post Snady Bridge CPU, will (or can be told to) use RdRand or RdSeed, and an untrapped RdRand or RdSeed gets entropy into the VM. /dev/random then works with a real (not a virtual) source of entropy.
This isn't by accident. It's right there in the Intel architecture docs.
For a device based hardware entropy source (I.E. uses a kernel driver to share it) you need the VM to correctly virtualize the physical source. I have no clue if they do this and if so, for which devices.
If your RNGd doesn't have the drng option below, update it.
If your hardware doesn't have a fast hardware RNG, you're doomed and you should consider using different hardware for security purposes.
# rngd --help
Usage: rngd [OPTION...]
Check and feed random data from hardware device to kernel entropy pool.
-b, --background Become a daemon (default)
**-d, --no-drng=1|0 Do not use drng as a source of random number input**
-f, --foreground Do not fork and become a daemon
-n, --no-tpm=1|0 Do not use tpm as a source of random number input
-o, --random-device=file Kernel device used for random number output
-p, --pid-file=file File used for recording daemon PID, and multiple
exclusion (default: /var/run/rngd.pid)
-q, --quiet Suppress error messages
-r, --rng-device=file Kernel device used for random number input
-s, --random-step=nnn Number of bytes written to random-device at a time
-v, --verbose Report available entropy sources
-W, --fill-watermark=n Do not stop feeding entropy to random-device until
at least n bits of entropy are available in the
pool (default: 2048), 0 <= n <= 4096
-?, --help Give this help list
--usage Give a short usage message
-V, --version Print program version
Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.
Report bugs to Jeff Garzik <email@example.com>.