Add virtio-rng support

[fabiand]

As a user I want to be able to provide my guest with good random numbers. One way to achieve this is by using a virtio RNG device.

Design: https://docs.google.com/document/d/1G75lPm0dCf3ZcFnG6NJpUDZgTaQnFKKM7_glpXzH9uc/edit#

This issue is about adding a virtio rng device type including it's knbos, and two configuration profiles which reflect the oVirt and OpenStack configuration.

The device can be added by a user on demand (thus is not automatically added to each VM).

The device should expose all the detailed settings you can configure on the the virtio-rng device.
And in addition it must expose a profile field which will set the knobs (i.e. backend, rate period and byets) according to profiles derived from oVirt and OpenStack.
A user can eitehr set the knbos himself, or choose from these two options.

The backend should be /dev/random if available or dev/urandom as a fallback.

API

kind: VMI
spec:
  domain:
    devices:
      rng:
        profile: ovirt  # DEFAULT
        # OR
        profile: openstack
        # OR
        rate: 
          period: 2000
          bytes: 1234
      …

libvirt reference. https://libvirt.org/formatdomain.html#elementsRng

Open Questions

• Is hardware RNG slower? Wouldn’t it be better to use /dev/urandom?
• If we know explicitly that a hardware RNG is present, we should request it (device plugins?), otherwise don’t request it and use /dev/random
  • This can be a follow up a) expose hwrng via DP, add virt controller awareness for hwrng devies
• How can we schedule nodes?
• How do we accommodate device plugins (unlimited devices?)
• A daemonset might need to prepare something?

[michalskrivanek]

@fabiand
why openstack/ovirt flavor? this should use virtuned, worst case presets until we have virtuned.
For low level kubevirt API why do we need anything else than libvirt-level attributes?

[michalskrivanek]

@fabiand
why openstack/ovirt flavor? this should use virtuned, worst case presets until we have virtuned.
For low level kubevirt API why do we need anything else than libvirt-level attributes?

[fabiand]

@michalskrivanek the "flavors" can be implemented by virtuned - we just do not have it right now, nothing is stopping us on using it on the longer run.

My point is that we do not want to expose all of the low-level knobs. But expose "flavors" which will set the internal (libvirt) knobs to the values.

I.e. openstack has values for ( backend, rate period and bytes), and ovirt as well. Selecting "flavor: ovirt" will set the libvirt knobs to the values which ovirt currently has.

[fabiand]

@michalskrivanek the "flavors" can be implemented by virtuned - we just do not have it right now, nothing is stopping us on using it on the longer run.

My point is that we do not want to expose all of the low-level knobs. But expose "flavors" which will set the internal (libvirt) knobs to the values.

I.e. openstack has values for ( backend, rate period and bytes), and ovirt as well. Selecting "flavor: ovirt" will set the libvirt knobs to the values which ovirt currently has.

[petrkotas]

Lets split this issue into three separate ones.

1. Implement the API support, which is done in #1385,
2. Implement new presents with default for the virtio RNG,
3. Tackle the challenge with hardware RNG device.

[petrkotas]

Lets split this issue into three separate ones.

1. Implement the API support, which is done in #1385,
2. Implement new presents with default for the virtio RNG,
3. Tackle the challenge with hardware RNG device.