You don't have to! Think of docker as a unit of software delivery, rather than resource allocation. It's very common to use Docker to either a) deploy only trusted containers on the same machine, or b) deploy only 1 container per machine.
There are also cases where linux cgroups and namespaces are an appropriate security mechanism (usually combined with other best practices, like apparmor/grsec/selinux, network lockdown, active monitoring, running things as non-root etc.) but it's not mandatory.
Here's our latest overview of container security: http://blog.docker.io/2013/08/containers-docker-how-secure-a...
How about built-in failover? On a virtualized environment you can run a cluster and the VM will move to another host in case of failure. Does docker support that? Is that what the docker-cluster project (https://github.com/globocom/docker-cluster) is about?
Kernel upgrades would affect all of the containers running under that kernel (machine or VM) at the same time. Though, if you wanted to be super cautious, you could upgrade kernel on an empty container host (quite easy if virtualized) and migrate containers to it and test them on an individual basis.
For "real" multi-tenant systems, I'd want full VMs, but as noted elsewhere, you can run Docker containers inside a VM, and still benefit from sharing resources by carving up a large VM into many smaller, isolated subsets.
We run OpenVz today, but I'm following Docker closely as we plan to migrate to LXC, and then going for Docker might very well be the best alternative.
Sry but link says it all. No further comment from me: http://marc.info/?l=openbsd-misc&m=119318909016582&w=2
Edit: this is not a os-or-vm problem. You will have local problems and now, in addition, rooting a server may give you access to even more servers that run on your hyp.