On Tue, May 01, 2018 at 01:18:36PM +0000, Jonathan Lebon wrote:

I'd like to bring attention to an issue we just discovered in the
latest Fedora 27 Cloud pungi compose[1]. I've just verified that the
latest F27 Atomic pungi compose suffers the same issue. FAH 28 RC 1.1
ships with kernel 4.16.3 and so doesn't have that issue yet. The
latest two-week F28 compose does suffer from this issue.

Essentially, services at startup that require entropy will block the
boot process until enough entropy is gathered. This can result in a
greater startup time before SSH comes up in cloud environments which
may have limited entropy for VMs. (In my quick test here on version
28.20180429.1, it blocked for almost 4m). This makes for a
deteriorated UX for AH.

Do we have a suggested approach? External entropy pools? Haveged?

--
Matthew Miller mattdm@mattdm.org http://mattdm.org/
Fedora Project Leader mattdm@fedoraproject.org http://fedoraproject.org/

Thanks @jlebon - this is definitely something that we're going to need to monitor for the next two week release!

My prediction is this gets reverted upstream. The thing everyone running VMs needs to do now is verify that they're passing through virtio-rng or equivalent. Probably we should make a push to have libvirt for example just do it by default, particularly if the host has rdrand.

There's going to be a long tail of this type of thing. Particularly in not-top-tier public clouds.

If it doesn't get reverted in the upstream kernel directly, maybe we carry a revert for a bit.

we reverted this for now so it's no longer a problem: https://bugzilla.redhat.com/show_bug.cgi?id=1572944