Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can you try to make that a little more specific? What does "general-purpose" mean here? "Secure containerized workloads" tends to imply serverside. It's hard to think of things --- other than GPU access --- that Firecracker takes away here.


> It's hard to think of things

No, it isn't. Investigate the K8S world and observe the backflips and somersaults being performed there to deal with networking and storage. Much of that is a consequence of people trying make containers do things that should be run in VMs. A full featured Linux kernel and certain key user space tools can obviate much of that nonsense with ease, deliver better performance, use less resources and be vastly less complex.


If it's not hard to name a thing that Firecracker makes difficult for a serverside workload, could you... name one?

Firecracker runs a full-featured Linux kernel. It's a hypervisor. It's not a kind of kernel.


> If it's not hard to name a thing that Firecracker makes difficult for a serverside workload, could you... name one?

I already did that with live migration. But ok.

Encrypted storage: https://github.com/firecracker-microvm/firecracker/issues/65...: WONTFIX

The answer given is appropriate for firecracker use cases but insufficient otherwise. I'm not anti-firecracker; it's the right choice for many things. Just not all things.

The sort of VM I want orchestrated has encrypted (by contract) multi-pathed network block devices to encrypted storage volumes. 3-10 per tenant. This is trivial for a full-featured kernel; multi-path just works, encryption just works.

VLAN: https://github.com/weaveworks/ignite/issues/810: Open. Maybe one day.

Again, trivial for a full-featured Linux kernel. Has been for ages.

I think you're missing the point. It's not about what hypothetical thing firecracker can or can't do. It's about elevating VM orchestration to some degree of parity with what has been created for container orchestration. These VMs and their complex storage and networking requirements should be modeled as we model containers now; through an orchestration system that makes management easy and as foolproof as possible. The fact that firecracker isn't sufficient to be the Micro-VM of choice for this isn't relevant.


You can encrypt a drive from within Firecracker trivially. It's just Linux, and they're just block devices.

You can do all the standard Linux tap interface networking with Firecracker; it just presents as virtio ethernet to the guest.

This is the second time you've compared Firecracker to a "full-featured Linux kernel". Again: Firecracker is a hypervisor. It's not a kernel. It runs Linux kernels. "Full-featured" Linux kernels. Whatever kernel you compile.


Well now you're arguing with the developers of both firecracker and ignite. Maybe go to the issues I linked and correct them.


No, you're linking to tickets that I don't think you really grok. That's someone asking for an extra encryption feature on the host side for Firecracker images, not someone saying it's impossible to encrypt a drive from within a Firecracker VM, which is obviously possible. You can just, you know, boot one up and try.

The other link you provided is to an Ignite ticket that's talking about integrating Firecracker with Linux namespaces. That has nothing to do with what Firecracker itself is capable of doing. If you want to slag Ignite, that's fine with me; I don't know much about the project, and am just here because weird things are being said about Firecracker, like that it doesn't run "full Linux kernels".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: