Here are two different ways i can think of to potentially solve this
(i'm not qemu hacker, feel free to correct me or propose a better
solution):
- the spicevmc chardev's "name" parameter could be used to identify the
agent numerically (e.g. "vdagent:1" instead of "vdagent")
- the -device
Public bug reported:
docs/multiseat.txt says:
> Note on spice: Spice handles multihead just fine. But it can't do
> multiseat. For tablet events the event source is sent to the spice
> agent. But qemu can't figure it, so it can't do input routing.
> Fixing this needs a new or extended input
any word on this? If this is not considered for adoption, i would like
to know the reason, so that we can have better predictions about what to
do for entropy in a QEMU system.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Public bug reported:
According to https://wiki.qemu.org/Features/VirtIORNG the default
backend for `virtio-rng-pci` is `/dev/random`. Alternately, the user
can point it to a different backend file, like `/dev/urandom`.
However, both of these files have suboptimal behavior in one way or
another,
To be clear, the problem with using /dev/urandom as a backend is that
it's possible to feed data from an uninitialized pool into the guest.
and the problem with using /dev/random as a backend is that it's
possible for a guest to starve the other host (and other guests) of
entropy, since it pulls
