I have a netbsd-4 xen2 domU (on xen2 dom0), and /dev/random is usually
nearly emtpy:

$ rndctl -s
           860227 bits mixed into pool
               64 bits currently stored in pool (max 4096)
           781210 bits of entropy discarded due to full pool
            78953 hard-random bits generated
          9344583 pseudo-random bits generated

All of the bits (except for 9 mysterious ones) have come from xbd0:

$ rndctl -l
Source                 Bits Type      Flags
xbd0                 860218 disk estimate, collect
xennet0                   0 net  

I noticed this because on login I run coda's clog, and it apparently
wants 16 bytes from /dev/random.  (Coda uses a variant of
Needham-Shroeder for authentication.)

In roughly the same uptime (4+ days), a real machine that's used more
has:

rndctl -s
          9968879 bits mixed into pool
                0 bits currently stored in pool (max 4096)
          6538249 bits of entropy discarded due to full pool
          3430630 hard-random bits generated
        403079498 pseudo-random bits generated

Source                 Bits Type      Flags
ums1                 151156 tty  estimate, collect
ums0                     64 tty  estimate, collect
ukbd0                146554 tty  estimate, collect
wd0                 8089071 disk estimate, collect
st0                 1579712 tape estimate, collect
pckbd0                 2304 tty  estimate, collect

So, fairly clearly domU is an entropy-poor environment.  But servers
need random bits.  Does anyone have thoughts about how to deal with
this?  Should there be a xen random source pseudodevice providing bits
from dom0?

Also, I wanted to understand how entropy was used; it seems it's
always used up and I know of know way to know what the consumers
were.  I suspect it's a combination of sshd and racoon (I use
transport-mode IPsec on coda traffic).

Is there any reason not to bump up the pool size?  I'm not sure it
would help that much; I suspect lots of bits are generated during
backups and the 'discarded' counter only goes up then.