Unless you want to PCI pass-through an SRIOV VF into a guest? If you're paying out the ass for Cisco cloud gear you probably want the guest to have direct access to a card...
Again, I don't remember the specifics, but depending on the underlying networking (on the host etc), there may be some issues with IPSec (but I could be wrong). From some random searching: https://linux-ipsec.org/wp-content/uploads/slides/2018/quest...
> SANs work fine from within VMs. The point of a SAN is that the disk isn't attached. Firecracker talks to host block devices the same way other virtualizers do.
But you may want to talk to an attached HBA? Firecracker's docs (https://github.com/firecracker-microvm/firecracker/blob/main...) say: "Firecracker emulated block devices are backed by files on the host. To be able to mount block devices in the guest, the backing files need to be pre-formatted with a filesystem that the guest kernel supports."
Based on everything else in the Firecracker docs, I don't see any vHBA support provided, so the guest cannot access an HBA on the host. And a virtual device backed by a file is going to have crap performance.
Yep, PCI pass-through is 100% something you can't do with Firecracker. To me, that's a perfect example of a feature that's not really there to support cloud-style serverside workloads, but that might just be my bias.
I think the other way to look at it is there's just different workloads that need different solutions. Firecracker is perfect for Lamba-style workloads.
But some companies (who don't want to manage datacenter resources, but do want the large scale and flexibility of cloud computing) want a whiz-bang multi-tenant enterprise containerized solution (say, using K8s as orchestrator). And maybe one of their critical applications has certain requirements that necessitate an HBA, deep packet inspection, an HSM, a high-precision clock, etc. They need strong isolation guarantees, so they want a VM, but they want K8s to manage it.
Kata Containers seems to fit the latter, as it can change hypervisors, supports more architectures, advanced networking features, device assignment, etc. Seems to align most with on-prem cloud as it's maintained by the OpenStack people.
I'll bet you it's more like 85%. AWS has a good amount of hardware designed to pass through into the VM, various custom guest drivers, some advanced high-performance networking stuff, and the GPU support like you mentioned. Customers probably pay a hefty premium, so we shouldn't discount it from either a business or technical perspective.
Unless you want to PCI pass-through an SRIOV VF into a guest? If you're paying out the ass for Cisco cloud gear you probably want the guest to have direct access to a card...
Again, I don't remember the specifics, but depending on the underlying networking (on the host etc), there may be some issues with IPSec (but I could be wrong). From some random searching: https://linux-ipsec.org/wp-content/uploads/slides/2018/quest...
> SANs work fine from within VMs. The point of a SAN is that the disk isn't attached. Firecracker talks to host block devices the same way other virtualizers do.
But you may want to talk to an attached HBA? Firecracker's docs (https://github.com/firecracker-microvm/firecracker/blob/main...) say: "Firecracker emulated block devices are backed by files on the host. To be able to mount block devices in the guest, the backing files need to be pre-formatted with a filesystem that the guest kernel supports."
Based on everything else in the Firecracker docs, I don't see any vHBA support provided, so the guest cannot access an HBA on the host. And a virtual device backed by a file is going to have crap performance.