Shuttleworth said, "LXD crushes traditional virtualisation for common enterprise environments, where density and raw performance are the primary concerns. Canonical is taking containers to the level of a full hypervisor, with guarantees of CPU, RAM, I/O and latency backed by silicon and the latest Ubuntu kernels."
So what is crushing? According to Shuttleworth, LXD runs guest machines 14.5 times more densely and with 57 percent less latency than KVM. So, for example, you can run 47 KVM Ubuntu VMs on a 16GB Intel server, or an amazing 536 LXD Ubuntu containers on the same hardware.
Shuttleworth also stated that LXD was far faster than KVM. For example, all 536 guests started with LXD in far less time than it took KVM to launch its 37 guests. "On average" he claimed," LXD guests started in 1.5 seconds, while KVM guests took 25 seconds to start."
As for latency, Shuttleworth boasted that, "Without the overhead emulation of a VM, LXD avoids the scheduling latencies and other performance hazards. Using a sample 0MQ [a popular Linux high-performance asynchronous messaging library] workload, LXD guests had 57 percent less latency for KVM guests.
Thus, LXD should cut more than half of the latency for such latency-sensitive workloads as voice or video transcode. This makes LXD an important potential tool in the move to network function virtualisation (NFV) in telecommunications and media, and the convergence of cloud and high performance computing.
Indeed, Shuttleworth claimed that with LXD the Ubuntu containers ran at speeds so close to bare-metal that they couldn't see any performance difference. Now, that's impressive!
LXD, however, as Shuttleworth pointed out, is not a replacement for KVM or other hypervisor technologies such as Xen. Indeed, it can't replace them. In addition, LXD is not trying to displace Docker as a container technology.
Instead, LXD works in tandem with both. LXD works best for hosting very lightweight containers. When you want the maximum number of instances of a small application, such as a telecomm app, on a given hardware platform, LXD is an excellent choice.
In addition, early LXD adopters are running common code such as Tomcat applications under low load. LXD's density comes from the fact that the same kernel is managing all the workload processes, as does its improved latency and quality of service.
If, however, your VMs are running many different software programs, KVM would be a better choice.
As Mark Baker, Canonical's OpenStack product manager, said, "We will, of course, continue to improve KVM in Ubuntu, but we are extremely excited to enable LXD alongside it for guests where raw performance, density or latency are of particular importance."
As for Docker, or other container technologies, such as CoreOS's Rocket, you run those on LXD. They are complementary, not rival, technologies.
Canonical revealed that the benchmarking was done on an Intel server with 16 GBs of RAM running Ubuntu 14.04 LTS. The testing involved launching as many guest instances as possible with competing hypervisor technologies, LXD and KVM.
In the density test, an automated framework continually launched instances while checking hypervisor resources and stopped when resources were depleted. The same test was used for LXD and KVM; only the command line tool used to launch the images was different.
The server was able to launch 37 KVM guests, and 536 identical LXD guests. Each guest was a full Ubuntu 14.04 system that was able to respond on the network. While LXD cannot magically create additional CPU resources, it can use memory much more efficiently. For low load workloads, this gave a density improvement of 1,450 percent.
The key phrase there is "low load." Heavy workloads will still require more RAM. Therefore, some programs, say most database server stacks, would not be suitable for LXD.
While Canonical only benchmarked LXD on Intel's x86 architecture, Shuttleworth also claimed similar results on the other platforms LXD supports: ARM-64 and IBM Power.
Still, there's no question, that for lightweight server apps, LXD will be a serious contender.