aliguori

Hi, I work at AWS and before that on KVM since it was a thing.

Restricting /dev/kvm these days doesn't make much sense. The interface is designed to be safe for any user. The fact that we started as a character device and not syscalls is just a historical decision.

Kata Containers is a lot of infrastructure for running containers and it uses QEMU to run the actual VMs. Firecracker just replaces the QEMU part and we're eager to work with folks like the Kata community.

I love QEMU, it's an amazing project, but it does a ton and it's very oriented towards running disk images and full operating systems. We wanted to explore something really focused on serverless. So far, I'm really happy with the results and I hope others find it interesting too.

Yes, the root volume on i3.metal is exposed as NVMe and is EBS-backed.

Sorry for that. The timeout behavior on earlier kernels is a bit of a pain.

There's a lot to love about NVMe and timeouts are not actually part of the NVMe specification itself but rather a Linux driver construct. Unfortunately, early versions of the driver used an unsigned char for the timeout value and also have a pretty short timeout for network-based storage.

As mentioned elsewhere in the thread, recent AMIs are configured to avoid this problem out of the box.

Yes, all customer PV instances in EC2 are running in an HVM container and are protected against the guest-to-guest Meltdown vulnerability.

As with all virtual and physical machines, patches are necessary to protect against process-to-process Meltdown within the OS itself. Those are starting to roll out from the respective vendors although it will take time for those to work inside a PV instance.

We're still working the details out upstream but the TL;DR is that the way to address Meltdown with Xen PV is to use nested virtualization so that the outer guest is an HVM or PVH guest.

C5 does not support nested virtualization but i3.metal allows using virtualization technology without nested virtualization.

Both i3.metal and c5 use the same underlying Nitro technology.

I tried to cover this in my re:Invent session and walked through how we have been evolving the Nitro System over the last 5 years. Videos and slides will be posted eventually.

Thanks! Would love to hear more about the counters that your interested in. We've exposed more in C5 than in previous instance types and we are trying to make more available over time in a safe way.

It's exactly the same as with the i3.16xlarge instance type. There are eight 1900 GB drives. In an i3.16xlarge, those eight drives are passed through to the instance with PCIe passthrough but for the i3.metal instance, you avoid going through a hypervisor and IOMMU and have direct access.

There is more coming at re:Invent. We have more talks queued up tomorrow on this too.

You can provision these servers just like any other instance. They work just like any other Amazon EC2 instance (same Nitro System platform as C5).

Disclaimer: I work at AWS on the team responsible for the Nitro System including EC2 Bare Metal Instances.

> Hopefully Amazon will disclose more details.

We will have some more details on how this all works at re:Invent in a couple weeks.

You claim it's objectively bad then only cite subjective things like function, structure, and variable names.

That word doesn't mean what you think it means :-)