Containers aren't emulating anything or translating anything. They let your partition out system and network resources as you see fit (or to protect users from abusing each other) without running kernels within kernels and other performance killing hokum.
[1] dotCloud don't actually yet recommend running Docker in production, but if you did...
[2] This was part of what Mailgun (part of Rackspace) said in their presentation at the Docker workshop in SF today.
Standardization for the sake of standardization is not defensible.
Is there an explanation why 'in production' is actively discouraged? Is that a limitation of the underlying lxc stuff?
I ask, because the interesting parts of docker _for me_ seem to be focused on the setup, deployment - and not the runtime. So if I create a working image and want to use that in production, wouldn't docker become passive as soon as I run that thing?
What's the danger here?
As long as we're not comfortable operating Docker at large scale ourselves (we run quite a lot of containers in production at dotCloud), we won't recommend that others do it.
They belong to a category of virtualization known as 'container-based virtualization' which implements virtualized perspectives of the system within the host kernel, effectively dividing the system in to multiple systems (from the perspective of the affected processes). That is unquestionably virtualization.
I believe a statement closer to what you were looking to express was containers are not running under a hypervisor.
LXC still creates a performance impact, depending upon which options are selected, with particular note for the various memory accounting options. However, that impact is far lower than a hypervisor. In addition, startup times are vastly reduced since the kernel bootstrap and hardware detection concerns are rendered unnecessary.