Getting IPMI controllers to do what you want is anything but trivial :)

Seriously. A person who would advocate using IPMI at scale has either never owned an IPMI card or has never worked at scale or both. The just don't work, and they erase whatever power savings you're trying to achieve.

Although... if you have the engineering resources of Facebook, you can write your own IPMI software and probably get it working pretty well. They're all just embedded ARM systems after all..

I ran out of motivation, but I did manage to fix up some of the SuperMicro IPMI firmware: https://github.com/devicenull/supermicro_ipmi_firmware

Real servers can't be bought without IPMI and AFAIK the BMC cannot be turned off, so it's probably not worth worrying about BMC power if there's nothing you can do about it.

Sure, but as you're aware facebook, google, et al don't buy "real servers", they buy servers that actually meet their requirements. That's why "real vendors" like HP have missed the boat on selling millions of servers into the cloud.

Speaking of Facebook specifically, the evolution is interesting. They replaced BMCs with the reboot-on-LAN hack but then their next motherboard version had BMCs again. It would be interesting to hear the story behind that.

I actually advocated using the vendor specific ones with the BMC being if you use shitty hardware. It works ok, but is absolutely suboptimal.

> Disclaimer: building this type of thing (on bare metal) is a chunk of my day job. I see it as unbelievably trivial.

You do, I'm sure, because you've invested a lot of time learning it and building tooling around it. For anyone who isn't a full-time sysadmin, debugging all of the many and various quirks in management hardware is a major time sink versus scripting a VM server's API.

If you want to power manage your pets, VMware makes sense. But yeah, there's a reason Facebook doesn't use virtualization.

I am curious why Facebook don't use?

If they do use virtualization, the fact, 0 request lead to low power does not correct any more, for example linux container, other container may accept requests, if so they have to dispatch request cross all containers and servers.

The Achilles heel of virtualization is networking. All of the hypervisors out there (VMWare, Xen, KVM) have user-space software switch implementations that dramatically reduce the throughput of TCP session creation. As a consequence you lose a significant amount of hardware potential to serve HTTP connections.

This is wrong as well. VMware standard and distributed virtual switch is in hypervisor kernel.

How's VMWare's TCP new-session-switching-rate compared to Xen's OVS? Any benchmarks showing a significant improvement?

We just did some benchmarks on this topic: https://news.ycombinator.com/item?id=8146536

How about lightweight virtualization like linux container, docker?

That's not virtualization; it's namespace isolation. There's a small performance impact if you're using NAT, but otherwise the kernel networking stack is used, so there's no performance penalty.

Yes, indeed. I mean the optimization of energy saving seems not suitable for the condition of namespace isolation, since you can't control the other containers requests. if we have to, we need to dispatch request from server perspective but not container.

"Virtualization doesn't really add much of anything for that specific problem other than increased context switching and slightly lower performance."

This is BS. What if you have 3 physical servers with 30% utilization? DRS can _seamlessly_ consolidate _arbitrary_ application VMs to one server and shutdown the rest. With bare metal, only certain specifically designed workloads (stateless web farms and some distributed systems etc.) can be moved easily.

It seems that dismissing virtualization out of sheer ignorance is a fad these days. Virtualization provides important hardware abstraction to a much wider variety of workloads.