From: "Toby Corkindale" <toby@dryft.net>
On 5 November 2014 12:42, Peter Ross <Petros.Listig@fdrive.com.au> wrote:
I have to admit not really to understand the "support this or that virtualisation"
A virtualisation presents a "virtual computer" and this may slightly differ depending on the virtualisation solution.
But the same goes for physical machines.
And I have not read: "Product XY only works on Dell T610 and HP ML 150". I can install it on a "no name box" as well. Why not on any VM?
The ERP solution [not Oracle, btw] I am dealing with in-house runs on Tomcat. Tomcat and Java are designed to live "everywhere".
Of course the software is certified on Linux X and Windows Y only..
So, in theory virtualisation should be roughly the same everywhere. And something like the JVM is designed to work almost everywhere. And usually it all works OK.
However sometimes you get bizarre incompatibilities -- the one I'm thinking of is OpenVZ and the JVM. I don't know why, but the jvm just doesn't work right under OpenVZ -- it's a well-known issue. (And one which I believe points out that openvz has been flawed all along; I wouldn't trust *anything* under it as a result)
Oracle does not support containers, Avi pointed out. In short, containers and Jails are not full virtualisation. As an example, FreeBSD jails are having a problem with shared System V memory: jail(8) man page: https://www.freebsd.org/cgi/man.cgi?query=jail&sektion=8 allow.sysvipc A process within the jail has access to System V IPC primitives. In the current jail implementation, System V primitives share a single namespace across the host and jail environments, meaning that processes within a jail would be able to communicate with (and potentially interfere with) processes outside of the jail, and in other jails. Not that the default is 0(disabled): "Some restrictions of the jail environment may be set on a per- jail basis. With the exception of allow.set_hostname, these boolean parameters are off by default." If you really need to run multiple postgresql (e.g.) in various jails on the same box you can run them with different UIDs (and enabling SysV memory) but it makes security a "cooperative issue" - only recommended if you control host and jail environment yourself (e.g. not a good idea for web hosting) The handbook writes about jails: "Important: Jails are a powerful tool, but they are not a security panacea. While it is not possible for a jailed process to break out on its own, there are several ways in which an unprivileged user outside the jail can cooperate with a privileged user inside the jail to obtain elevated privileges in the host environment. Most of these attacks can be mitigated by ensuring that the jail root is not accessible to unprivileged users in the host environment. As a general rule, untrusted users with privileged access to a jail should not be given access to the host environment." I do not know this about OpenVZ (and in general Linux containers). The documentation about Linux containers is a bit vague in this regard (or I have not found the "ultimate answer" yet). One reason not to trust it that much. Here is one example about container issues mentioned (but not explained): http://unix.stackexchange.com/questions/127001/linux-lxc-vs-freebsd-jail "There are some known security issues with LXC that can be mitigated using selinux, for example." I actually would like to know what the "known security issues" are.. Cheers Peter