You can tell people to just do something else, there's probably a separate natural solution, etc. but sometimes you're willing to sacrifice some peak performance just have that uniformity of operations and control.
GCP has had nested virtualization for a while.
Nested virtualization can mean a lot of things. Not just full VMs.
The technical details are a lot more complex than most realize.
Single level VMX virtualization is relatively straightforward even if there are a lot of details to juggle with VMCS setup and handing exits.
Nested virtualization is a whole another animal as one now also has to handle not just the levels but many things the hardware normally does, plus juggling internal state during transitions between levels.
The LKML is filled with discussions and debates where very sharp contributors are trying to make sense of how it would work.
Amazon turning the feature on is one thing. It working 100% perfectly is quite another…
This is really big news for micro-VM sandbox solutions like E2B, which I work on.
If EC2 were like your home server, you might be right. And an EC2 bare metal instance is the closest approximation to that. On bare metal, you've always been free to run your own VMs, and we had some customers who rolled their own nested VM implementations on it.
But EC2 is not like your home server. There are some nontrivial considerations and requirements to offer nested virtualization at cloud scale:
1. Ensuring virtualized networking (VPC) works with nested VMs as well as with the primary VM
2. Making sure the environment (VMM etc) is sufficiently hardened to meet AWS's incredibly stringent security standards so that nesting doesn't pose unintended threats or weaken EC2's isolation properties. EC2 doesn't use libvirt or an off-the-shelf KVM. See https://youtu.be/cD1mNQ9YbeA?si=hcaZaV2W_hcEIn9L&t=1095 and https://youtu.be/hqqKi3E-oG8?si=liAfollyupYicc_L&t=501
3. Ensuring performance and reliability meets customer standards
4. Building a rock-solid control plane around it all
It's not a trivial matter of flipping a bit.
Thanks for the well-reasoned response.
It's provided many a chuckle.
Thanks!
I remember playing with nested virty some years ago and deciding it is a backwards step except for PoC and the like. Given I haven't personally run out of virty gear, I never needed to do a PoC.
The place I've probably wanted it the most though is in CI/CD systems: it's always been annoying to build and test system images in EC2 in a generic way.
It also allows for running other third party appliances unmodified in EC2.
But also, almost every other execution environment offers this: GCP, VMWare, KVM, etc, so it's frustrating that EC2 has only offered it on their bare metal instance types. When ec2 was using xen 10+ years ago, it made sense, but they've been on kvm since the inception of nitro.
pure CPU should be essentially unaffected, if they're not emulating the MMU/page tables in software
the difference in IO ranges from barely measurable to absolutely horrible, depending on their implementation
traps/vmexits have another layer to pass through (and back)
I don't know if this applies to the specific nested virtualisation AWS are providing though.