Preamble
since i can't comment, ill leave an answer. people really need to do their research about openVZ (among other technologies..) before posting...
i realize that this was a question from a few years ago, but I intend to disambiguate the lies about OpenVZ/Virtuozzo and disinformation about operating system virtualization still propagated today
OpenVZ
openVZ is a great piece of technology, that can be used for a plethora of uses. there is many uses for operating system level virtualization, and many people fall into the category of needing this level of simulation...
its like a Chroot on Steroids, but with the ability to restrict processes tables and separate hardware utilization, in turn allowing for fluent operating systems inside of operating systems: but with a heightened layer of additional security and privacy or isolation while still allowing root access.
unfortunately, the same lies are spread around about the Chroot function... every one will tell you to use virtualization, and that its not a security feature. most times, this is entirely not true, the insecurity accusations are entirely false, as Chroot is directly integrated into a variety of popular software, usually as a potent security and isolation feature (when used correctly)
an important note is that not every admin has the level of knowledge needed to secure all the necessary kernel parameters on a dedicated server or under full system virtualization.
this means that deploying OpenVZ means that your customers will have much less attack surface to try and cover and secure before deploying their applications. a good host will do a good job securing these parameters, and it in turn, this is better for not only everybody on the Node, or in the data-center, but for the internet as a whole...
Why not Change?
"considering changing", as Michael Hampton suggests, to full system virtualization, because of "little unknown issues" is not not only overkill be entirely unnecessary. this is the sign of one not fully understanding the intended purpose. full system simulation includes everything, such as the bios and hardware interrupts,
this means you have less over-head when using OpenVZ, and therefore, in direct correlation to what the evidence concludes (i.e benchmarks), that this will typically result in a faster virtual machine, especially for someone with a lesser level of understanding about *nix, and not to mention higher levels of security.. (to assume that every user with a virtual machine understands kernel security and custom patching is incredulous)
converting to a new technology is always going to be complicated, and emerging technologies in the open source world are ALWAYS going to take time to be perfected.
I'm now wondering about the more fundamental aspect of this problem. Why is it that you can't remount tmp with different options in a virtual environment?
So whats the Issue?
with that said, and to answer your question , on most modern OpenVZ Kernels these days, the issue is that the kernels pluggable modules appear to be "missing", especially to commands which directly depend on them. but they are still there.
the explanation is simple, in that openVZ simulated the operating system, and not the kernel. giving guest access to hardware related settings would be insecure. you do not get direct access to hardware, devices, or file systems.
this may sound cumbersome, but is not (once your get the hang of it), and the trade off between security for new users and experienced users having to understand how to work-around (which an experienced user should know how to do anyways), is sincerely a modest one. on a truly secure dedicated machine or KVM, you would want to implement many of the kernel layer securities existing in a container anyways
finally, simfs is a simulated file system device for use with openVZ, and is not recognized by the mount file-system command (AFAIK).
And how do I Fix this?
not sure if this is the case for you, but it should be resolvable in most newer kernel versions simply be issuing
mount --bind -o defaults,exec /tmp /tmp
and in the kernel version one of my host nodes use, i simply dropped the /dev/simfs inside fstab, and mount -a
works as expected...
example:
none /tmp simfs defaults,exec 0 0
I hope this helps somebody.