Live data from Hacker News

We replaced Firecracker with QEMU

hocus.dev

151–156 of 156 posts

Re: We replaced Firecracker with QEMU

#151

Earlier quoted context omitted.

After reading the README of virtualization tools (and looking at the author) I discovered the benefits of using them. I recommend also giving that a try.

I do have to use it since someone early on in the company I work at decided to do everything with AWS and Kubernetes. The fact of the matter is that it's just inefficient, slow and expensive. Bare metal is simple, fast, and keeps you in control.

bare metal has high capex and low opex

cloud vms have low capex and high opex

which one is more expensive is a function of many variables

Re: We replaced Firecracker with QEMU

#152

Earlier quoted context omitted.

I do have to use it since someone early on in the company I work at decided to do everything with AWS and Kubernetes. The fact of the matter is that it's just inefficient, slow and expensive. Bare metal is simple, fast, and keeps you in control.

bare metal has high capex and low opex cloud vms have low capex and high opex which one is more expensive is a function of many variables

to get decent prices for cloud you need to commit to 3 years of usage upfront, and if you do that then it's about the same price as buying the hardware outright.

Otherwise it's three times more expensive.

Re: We replaced Firecracker with QEMU

#153
post #22

Earlier quoted context omitted.

kvm does the same with KSM.

Not precisely, in that KSM does it after the fact while OpenVZ has it occur as a consequence of its design, on the loading of the program. See (OpenVZ) "Containers share dynamic libraries, which greatly saves memory." It's just 1 Linux kernel when you are running OpenVZ containers. https://docs.openvz.org/openvz_users_guide.webhelp/_openvz_c... See (KVM/KSM): "KSM enables the kernel to examine two or more already run…

KSM is a Linux kernel feature, not directly related to KVM.

Re: We replaced Firecracker with QEMU

#154
post #26

Earlier quoted context omitted.

I'd love to get a clear explanation of what libvirt actually does. As far as I can tell it's a qemu argument assembler and launcher. For my own use-case, I just launch qemu from systemd unit files: https://wiki.archlinux.org/title/QEMU#With_systemd_service

> As far as I can tell it's a qemu argument assembler Raises a few questions to me: Can you use KVM/do KVM stuff without QEMU? Can you do libvirt stuff without QEMU? Hoping the answers to both aren't useless/"technically, but why would you want to?"

> Can you use KVM/do KVM stuff without QEMU?

Here's a post of someone using KVM from Python (raw, without needing a kvm library or anything): https://www.devever.net/~hl/kvm

Re: We replaced Firecracker with QEMU

#155
post #108

Earlier quoted context omitted.

Shit like this is how you burn customers and then they find out you aren't changing the sheets, they change hotels. Just because you can doesn't mean you should.

I don't see the problem. Is this not the value proposition of the cloud? At scale things like block level de-duplication and over-provisioning of compute are more efficient to say nothing of power and cooling. This efficiency drives down cost. As long as your data isn't leaking and you get the hardware you pay for when you need it what's the problem?

Value to whom? Sell a thing and not deliver it. This this our current millieu to scam people and make the difference.

The entire vibe of this thread is

1) everyone is doing it

2) efficiency drives cost down (to the vendor) but those savings are not passed to the consumer

3) "hardware you pay for when you need it", all predicated on the at IF and it doesn't happen.

Oversubscription should always be opt-in, otherwise it is an underhanded scam.

Re: We replaced Firecracker with QEMU

#156

Earlier quoted context omitted.

Memory (DDR4) is like 1.50€ per GB nowadays. There is no need to skimp on it. The most expensive component is still the CPU if you actually want to do work and not just idle your webserver 99% of the time.

this ignores just how competitive these services have become and how much competition there is in this marketplace. Anything that allows a company to balance user experience with cost of hardware will be evaluated. The fact is this is super common because even though RAM is super cheap, at scale, these things add up. If you as a provider don't have to spend 120K on RAM and can use that on more CPUs or something else,…

If they were competitive, they would be within an order of magnitude of on-prem, but they are not, they are 5x or more. "Super Common" is a weasel word.
Post reply on HN