3 ms·

While people contemplate things like containers, it's worth noting that modern hardware virtualization imposes a performance overhead of low single digital perc

• riquito 12y ago
  You may nave a point, but you're making up numbers and forget other scenarios. How much ram and HD overhead there is to virtualize ping? How much time do I need to spawn the vm? Vms are great, but there are problems better solved by containers. Use both.
  • personZ 12y ago
    Why would anyone ever virtualize or containerize ping? In the real world, we use containers for largely the same things that we use virtualization -- the web server, the database server, the VPN host, and so on. The overhead is negligible to begin with- https://major.io/2014/06/22/performance-benchmarks-kvm-vs-xen/ https://major.io/2014/06/22/performance-benchmarks-kvm-vs-xe... -but with de-duplication of a solution like vmware, approaches 0. Containerization seems like a massive win when you're trying to fit a bunch of stuff in a single Digital Ocean VM, etc. When you're running many machines in a data center, though, it becomes dramatically less valuable.
    • mbreese 12y ago
      Come on... ping was obviously chosen as a ludicrously simple example. You'd never containerize ping. But you could imagine some simple user application that would be easily deployed as a container, but that would be horrible overkill to wrap in a virtual machine. You're right that once you've hit rack levels of virtualization, you've already hit the management overhead requirements to use VMs. In my mind, it isn't about processing or IO overhead. It's about the overhead for management. It's a trade-off. Some applications are better managed as whole systems (VMs), whereas others are more building block-ish and probably better as containers. The two technologies are pretty complimentary.
    • schmichael 12y ago
      Ping is actually an excellent candidate for virtualization/containers/SELinux since it has to run as root. A bug in ping could mean a carefully crafted response could lead to a remote exploit. There are obviously also a number of local exploits that take advantage of setuid binaries like ping: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2851 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2851
      • justincormack 12y ago
        It doesnt have to any more - Linux supports special icmp sockets see https://lwn.net/Articles/420799/ https://lwn.net/Articles/420799/
      • stock_toaster 12y ago
        I think sandboxing (with something like capsicum[1], or maybe seccomp?) would be more appropriate for ping than "containerization". [1]: https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4 https://www.freebsd.org/cgi/man.cgi?query=capsicum&sektion=4
• wmf 12y ago
  modern hardware virtualization imposes a performance overhead of low single digital percentage points For CPU and RAM, but the overhead for I/O is much higher. technologies like deduplication of storage and memory can paradoxically improve performance over bare metal In principle there's no reason why containers can't use those same technologies, although AFAIK currently Linux can't do memory dedupe for containers.
  • personZ 12y ago
    but the overhead for I/O is much higher Hardware virtualized I/O is a thing now as well, and in that case as well the overhead has shrunk to marginal. Add external storage (iSCSI), and things get much more complex. Much of the argument about virtualization is about ten years+ old. It once represented a significant additional overhead, but that simply isn't true at all now.
    • wmf 12y ago
      Looking at it from a public cloud perspective, I doubt we'll ever be able to use SR-IOV. By the time a particular function has been driven into hardware there are new functions we need that aren't in hardware, like sophisticated overlay networking.
• justincormack 12y ago
  Nesting is an issue though, at least for some use cases.