[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What belongs in the Debian cloud kernel?



On 4/2/20 7:55 PM, Ross Vandegrift wrote:
> On Wed, Apr 01, 2020 at 03:15:37PM -0400, Noah Meyerhans wrote:
>> Should we simply say "yes" to any request to add functionality to the
>> cloud kernel?  None of the drivers will add *that* much to the size of
>> the image, and if people are asking for them, then they've obviously got
>> a use case for them.  Or is this a slipperly slope that diminishes the
>> value of the cloud kernel?  I can see both sides of the argument, so I'd
>> like to hear what others have to say.
> 
> I don't think just saying "yes" automatically is the best approach.  But
> I'm not sure we can come up with a clear set of rules.  Evaluating the
> use cases will involve judgment calls about size vs functionality.  I
> guess I think that's okay.
> 
> 
> 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?

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.

Cheers,

Thomas Goirand (zigo)


Reply to: