Re: What belongs in the Debian cloud kernel?
On Sat, Apr 04, 2020 at 10:17:20AM +0200, Thomas Goirand wrote:
> > The first two bugs are about nested virtualization. I like the idea of
> > deciding to support that or not. I don't know much about nested virt,
> > so I don't have a strong opinion. It seems pretty widely supported on
> > our platforms. I don't know if it raises performance or security
> > concerns. So these seem okay to me, as long as we decide to support
> > nested virt, and there aren't major cons that I'm unaware of.
>
> There's a big problem when activating nested virt. I have read that Live
> migration of VMs can become impossible (ie: for all VMs that are also
> host OS for virtualization). As much as I understand, this is because of
> the difficulty to support nested MMU. I'm not sure if the situation has
> changed or not, but last time I checked this was the case. Ben, do you
> know if this has evolved?
Remember, nested virtualization works today; nothing we have done would
have prevented that. The question is about whether or not we care about
enabling features to support use cases that only arise when nested
virtualization is in use.
The reason nested virtualization breaks live migration is that it shares
state between the VM and the underlying hypervisor. The VM is, in a
sense, no longer self contained. The nested VMs state is tracked by the
parent VM in a VMCS structure, as shown in the nested-vmx.rst doc I
linked previously, and the values in that struct need to be mapped to a
corresponding list in the hypervisor. Migration would entail some
coordination between the hypervisor and the outer VM, as the shared
state would need to be kept in sync throughout the process.
The sharing of state between the VM and the hypervisor hints at some of
the potential security concerns around nested virtualization in
mixed-trust environments.
> So, when I'm being asked about it, my answer from an OpenStack operator
> point of view, is always a big "NO !". I want to be able to service my
> compute nodes. This means being able to live-migrate the workload away,
> otherwise, customers may notice.
Whether or not you support nested virt on your infrastructure is a
deployment choice, not a choice Debian needs to make.
noah
Reply to: