4 ms·

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 se

by 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

by personZ 12y ago

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