Linux VMs For Everyone
Over at Newsforge, Grant Gross has written an interesting overview of the options available for hosting multiple Linux installations on virtual machines; interestingly, it's not just for those with the big bucks for high-end IBM hardware, though that's surely nice.
The theoretical customer downtime doesn't change.
First, the non-VM scenario: let's say in a given period, there's a 1:3 chance that a box will go down, and you have 1 customer upset. If you have three customers, the odds are 1:1 that one of the machines will go down. Over three periods, three customers will experience downtime.
Okay, VM now: There's still a 1:3 chance that a box will go down, but if you have 3 customers, three customers will be upset if it happens. Over three periods, the odds of the machine going down are 1:1, so over three periods, three customers will experience downtime.
It reduces the odds and raises the stakes in equal proportion. Of course, dealing with three upset customers may be more than 3x as difficult as dealing with 1 upset customer 3 times.
This achitecture has huge advantages when it comes to making backups, since the host OS can access and back up all the partitions in one swell foop. And with the cost savings, you could afford to get a second, identically-configured box. So there are plus sides, too. I guess VM giveth and VM taketh away. . .
Writing was never a problem. Reading the condition codes was the problem.
In order to support virtualization, one must be able to trick a program that is running in user mode into thinking that it is running in supervisor mode. For example, a virtualized Linux kernel needs to run in user mode (so that, for example, you can trap any attempts it makes to change the MMU registers; you don't want it to change the _real_ MMU registers, just what it _thinks_ are the real MMU registers). On an M68000, this was not possible, because the opcode used to read the condition codes ("MOVE SR,<ea>") was a user-level opcode. Thus a program could always determine its true run level.
On the MC68010 and later, "MOVE SR,<ea>" was made supervisor-only. So what does this mean? On a non-virtualized OS, if supervisor-level code does a "MOVE SR,<ea>", it returns the true result. On a virtualized OS, the virtual OS is running in user mode, so the "MOVE SR,<ea>" traps. The virtual machine underneath gets the condition codes, sets the "Supervisor" bit to 1, stores it in the specified destination (the "effective address"), and returns from the trap. To the virtual OS, it looks like the "MOVE SR,<ea>" executed as expected.
quite a lot really. This is a seperate OS entirely which you can give the user root access too. Even if they decide to rm -rf / all that will happen is their own virtual machine will wipe itself...the box will stay up and so will all the other vm's. I'm still undecided as to whether its useful or just a gimmick to have a box setup with 100+ VM's on it. Running windows in a vmware on my slackware desktop to test webpages is useful but 1000 linux servers on one boxen.....I'm not so sure.
on this discussion a lot has been said about VMWARE. i just wish to quickly poit out that VMWARE new licence is redicolously restrictive basically prohibiting any VMware machine to act as a SERVER for any service. Read it yourself if you dont believe it.
The basica idea behind it was to prevent peopel from buying the ""cheap"" 300 USD version and doing virtual hosting but in reality that licence states more than that.
SIncerely
Giovanni Tummarello
www.Wup.it
I was under the impression that jail(2) did that, too.