Re: Status of Nested Virt in 4.4 (Was: Re: Xen 4.4 development update)

[George Dunlap <george.dunlap@eu.citrix.com>]

On 01/24/2014 03:02 PM, Ian Campbell wrote:
> On Fri, 2014-01-24 at 15:56 +0100, Tim Deegan wrote:
>> B11;rgb:0000/0000/0000At 14:47 +0000 on 24 Jan (1390571231), George Dunlap wrote:
>>> On 01/17/2014 09:40 AM, Ian Campbell wrote:
>>>> On Fri, 2014-01-17 at 02:16 +0000, Zhang, Yang Z wrote:
>>>>> As Andrew said, nested still in experimental stage, because there are
>>>>> still lots of scenarios I am not covered in my testing. So it may not
>>>>> accurate to say it is good supported. But I hope people know that the
>>>>> nested is ready to use now. And encourage them to try it and report
>>>>> bug to us to push nested move forward.
>>>> Perhaps we could say it is "tech preview" rather than "experimental"?
>>> If { {xp,win7,win8,rhel6}x{x86,x64} } x { Xen, KVM, VMWare } and Win7 XP
>>> compatibility mode are tested regularly, and only HyperV, L2 shadow, and
>>> paging / PoD don't work, I think we should be able to call this a "1.0"
>>> release for nested virt.  Then we can add in "now works with HyperV",
>>> "Now works with shadow", "Now works with paging" as those become mature.
>> That depends on what the failure modes are for the other cases --
>> esp. given that the L1 guest's choice of hypervisor, shadow vs HAP &c,
>> are not under the control of the L0 admin.  I thikn that has to be
>> clearly understood before we encourage people to turn this on.
> Especially in the light of the previous two bugs here which let the
> guest admin crash the host, in at least one of the two cases even if the
> host admin had disabled nested virt for that guest (and I think it was
> actually in both cases...)

Right -- well I think then we need to help try to define some criteria 
that VMX nested virt would need to meet for portions of it to stop being 
considered "experimental" or "tech preview".  Just a couple of angles:

* L1 / L2 guests tested.  What do people think of the mix of L1 / L2 
guests there?  They look like a pretty good combination to me.

* L2 workloads tested

Other than booting, what kinds of workloads are run in the L2 guests?  
Do the L2 guests ever get into heavy swapping scenarios, for instance?

* Minimum subset of functionality

I think it makes sense to explicitly say that we support only certain 
hypervisors, and to not support some advanced features in L2 guests.  
Saying only L1 HAP L2 HAP is reasonable, I think.  No HyperV, no L2 
shadow, no PoD are reasonable restrictions; it should be fine for us to 
say that the L1 admin enables that, and badness ensues, he has only 
himself to blame.

* Security

That said, I think we must assume that some of our users will have L0 
admin != L1 admin.  This means that L1 admin must not be able to do 
anything to crash L0.  In the PoD case above, for example, if L1 enables 
PoD or paging, it might cause locking issue in L0; that's not acceptable.

Anything else?

  -George