[pve-devel] Qemu / virtio-rng-pci
Alexandre DERUMIER
aderumier at odiso.com
Mon Jun 1 20:20:50 CEST 2015
seem that qemu added support for RDRAND in qemu 2.2
http://git.qemu.org/?p=qemu.git;a=commit;h=78a611f1936b3eac8ed78a2be2146a742a85212c
(so, it's seem to be enough to have hardware entropy for intel >= ivybridge without virtiorng
----- Mail original -----
De: "Stefan Priebe" <s.priebe at profihost.ag>
À: "aderumier" <aderumier at odiso.com>
Cc: "dietmar" <dietmar at proxmox.com>, "pve-devel" <pve-devel at pve.proxmox.com>, "Marco Schinkel" <m.schinkel at profihost.ag>
Envoyé: Lundi 1 Juin 2015 19:03:50
Objet: Re: [pve-devel] Qemu / virtio-rng-pci
Marco, can you please join the discussion? Below some findings from Alexandre.
Thank!'s!
Greets,
Stefan
Excuse my typo s ent from my mobile phone.
Am 01.06.2015 um 18:52 schrieb Alexandre DERUMIER < aderumier at odiso.com >:
I had look for some more informations about virtio-rng
https://lists.fedoraproject.org/pipermail/devel/2013-February/177909.html
"BTW, virtio-rng really only works well if you have a hardware RNG in the
host. Otherwise, the host kernel will take too much time (a few
minutes) before producing enough entropy to feed the FIPS tests in the
guest, and during this time the host will be entropy-starved."
So I don't known if it's a good idea to enable it by default. (performance ?)
It need to be tested.
With ivy-bridge processor,
It's possible to pass RDRAND to guest (I don't have checked if qemu is filtering it or not), without virtio-ring.
or possible to map it on host to /dev/random but it's require an additionnal daemon
"RDRAND only hands out random numbers. We plan to add QEMU support for
using RDRAND directly (with whitening, similar to rngd), but it is not
in yet. Right now what you do is use rngd in the host to feed
/dev/random with random numbers from RDRAND, connect /dev/random to
virtio-rng."
With new Broadwell processor, it's directly feeding /dev/random, so in this case we can use virtio-ring by default.
But the article here:
http://rhelblog.redhat.com/2015/03/09/red-hat-enterprise-linux-virtual-machines-access-to-random-numbers-made-easy/
say that changed has been done rhel7.1 (no patch reference), to don't have need of daemon for ivy-bridge.
I'll try to dig a little bit more tomorrow
----- Mail original -----
De: "dietmar" < dietmar at proxmox.com >
À: "Stefan Priebe" < s.priebe at profihost.ag >, "aderumier" < aderumier at odiso.com >
Cc: "pve-devel" < pve-devel at pve.proxmox.com >
Envoyé: Lundi 1 Juin 2015 17:39:25
Objet: Re: [pve-devel] Qemu / virtio-rng-pci
BQ_BEGIN
BQ_BEGIN
BQ_BEGIN
Sure. I'm just thinking about the check regarding Qemu 2.3. I would also
BQ_END
BQ_END
BQ_BEGIN
BQ_BEGIN
BQ_BEGIN
like to use it for older qemu versions / installations.
BQ_END
BQ_END
BQ_END
BQ_BEGIN
BQ_BEGIN
BQ_END
BQ_END
BQ_BEGIN
BQ_BEGIN
BQ_BEGIN
Is there no other way to support it and not to break live migration?
BQ_END
BQ_END
BQ_END
BQ_BEGIN
BQ_END
BQ_BEGIN
I don't see how to do it, adding a new pci device by default will break live
BQ_END
BQ_BEGIN
migration.
BQ_END
BQ_BEGIN
Or we need to add a new option in vmid.conf
BQ_END
BQ_BEGIN
BQ_END
BQ_BEGIN
@Dietmar : any opinion ?
BQ_END
I don't really want a new option for that...
BQ_END
More information about the pve-devel
mailing list