3 ms·

Firecracker is pretty great, good to see it can be used in a CI environment like this, definitely peaking my interest. I know its the backbone of what runs fly

Firecracker is pretty great, good to see it can be used in a CI environment like this, definitely peaking my interest. I know its the backbone of what runs fly.io[0] as well [0]: https://fly.io/docs/reference/architecture/#microvms https://fly.io/docs/reference/architecture/#microvms

emmelaich 4y ago
*piquing
waz0wski 4y ago
Firecracker has been running AWS Lambda & Fargate for a few years now https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir... There's also similar microVM project with a bit more container-focused support called Kata https://katacontainers.io/ https://katacontainers.io/
- digianarchist 4y ago
  Not a hypervisor expert by any means but what's stopping projects backporting the super fast startup time of Firecracker into regular VM hypervisors? I'm assuming that Firecracker is somewhat constrained in some way.
  - antonvs 4y ago
    It’s written specifically to host the Linux kernel, and doesn’t use a bios or a boot loader. If you backported that into another hypervisor, it would probably have to be something like “are we loading a compatible Linux? If so switch to Firecracker mode”. But of course you can do that yourself, with a small shell script that either starts the traditional VM or Firecracker. Or they could do what QEMU has done and put out a separate product/mode: https://github.com/qemu/qemu/blob/a082fab9d25/docs/system/i386/microvm.rst https://github.com/qemu/qemu/blob/a082fab9d25/docs/system/i3...
    - solarkraft 4y ago
      I'm used to QEMU VMs being slow and annoying to work with due to them being full VMs, so I was quite surprised to see that this is really just as fast as Firecracker!
    - skissane 4y ago
      That QEMU doc says: > The recommended way to trigger a guest-initiated shut down is by generating a triple-fault, which will cause the VM to initiate a reboot Doesn’t that mean it can’t distinguish an intentional triple fault to trigger reboot from an accidental triple fault caused by a guest kernel bug which corrupts the IDT? I think it would be better if there was some kind of call the guest could make to the hypervisor to reboot-one is less likely to invoke that service by accident than to triple fault by accident.
intelVISA 4y ago
Does Fly.io have an in-house engineering team? Seems like it's mostly AWS lite.

emmelaich 4y ago

*piquing

waz0wski 4y ago

Firecracker has been running AWS Lambda & Fargate for a few years now https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/ https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir... There's also similar microVM project with a bit more container-focused support called Kata https://katacontainers.io/ https://katacontainers.io/

digianarchist 4y ago
Not a hypervisor expert by any means but what's stopping projects backporting the super fast startup time of Firecracker into regular VM hypervisors? I'm assuming that Firecracker is somewhat constrained in some way.
- antonvs 4y ago
  It’s written specifically to host the Linux kernel, and doesn’t use a bios or a boot loader. If you backported that into another hypervisor, it would probably have to be something like “are we loading a compatible Linux? If so switch to Firecracker mode”. But of course you can do that yourself, with a small shell script that either starts the traditional VM or Firecracker. Or they could do what QEMU has done and put out a separate product/mode: https://github.com/qemu/qemu/blob/a082fab9d25/docs/system/i386/microvm.rst https://github.com/qemu/qemu/blob/a082fab9d25/docs/system/i3...
  - solarkraft 4y ago
    I'm used to QEMU VMs being slow and annoying to work with due to them being full VMs, so I was quite surprised to see that this is really just as fast as Firecracker!
  - skissane 4y ago
    That QEMU doc says: > The recommended way to trigger a guest-initiated shut down is by generating a triple-fault, which will cause the VM to initiate a reboot Doesn’t that mean it can’t distinguish an intentional triple fault to trigger reboot from an accidental triple fault caused by a guest kernel bug which corrupts the IDT? I think it would be better if there was some kind of call the guest could make to the hypervisor to reboot-one is less likely to invoke that service by accident than to triple fault by accident.

intelVISA 4y ago

Does Fly.io have an in-house engineering team? Seems like it's mostly AWS lite.