Probably from historical reasons engine was using SHA1PRNG implementation for random number generation. SHA1PRNG is pseudo-random number generator implemented within JVM (more details at [1]) and it's blocking implementation (it can block the entire process if there is not enough entropy), which could cause issues when engine is running inside a VM. We should switch to NativePRNG, which is blocking only for seed generation. More information about Java implementation is available at [1] and [2]. [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#SecureRandom [2] https://tersesystems.com/blog/2015/12/17/the-right-way-to-use-securerandom/
Running systems out there may benefit by simply setting the JRE to use /dev/urandom in java.security property file: $JAVA_HOME/jre/lib/security/java.security ... securerandom.source=file:/dev/urandom
(In reply to Roy Golan from comment #1) > Running systems out there may benefit by simply setting the JRE to use > /dev/urandom in java.security property file: > > $JAVA_HOME/jre/lib/security/java.security > ... > securerandom.source=file:/dev/urandom I'd personally rather not change the platform default. And also I'm not sure if this will affect us, because AFAIK SHA1PRNG is custom Java implementation and not sure if it uses /dev/(u)random or not. That's why I think it's better to switch from SHA1PRNG to NativePRNG without changing JVM default.
(In reply to Martin Perina from comment #2) > I'd personally rather not change the platform default. I mentioned this is for existing setups that may suffer from it. > And also I'm not sure > if this will affect us, because AFAIK SHA1PRNG is custom Java implementation > and not sure if it uses /dev/(u)random or not. According to the sources you mentioned in the patch and reading the oracle implementation it does look like they are using the device that is mentioned java.security > That's why I think it's > better to switch from SHA1PRNG to NativePRNG without changing JVM default.
adding CodeChange moving to VERIFIED
BZ1421472 is the original bug, I have found this issue when investigating it. So I think you can use the same reproducing steps to verify it.
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.