Slashdot Mirror
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.
In particular, VMware's "undoable disks" are great in this regard.
CEE5210S The signal SIGHUP was received.
Consider the possibilities.....
Multiple BSOD's running at the same time!
Here are some points to be considered.....
When I say "OK" and reboot, does this start another instance of Windows, or just jump me to the other blue screen?
Could one BSOD cause a another BSOD?
What exactly would the effect of a "Virtual BSOD" be?
Inquiring minds want to know......
The reason there's a value to virtual machines is because you can't buy half a computer [from reputable vendors!]. If you have four jobs that only require 1/4 of the resources of a modern PC, but they all need different security contexts, you must a) buy four servers or b) buy one server and run 4 virtual machines.
There's probably even some value in a beowulf cluster of virtual machines-- if you want to write and test cluster-based software when you don't have access to a cluster.
If youre hosting, you cant beat this solution
..)
Folks over at Solucorp
Have made kernel patch and utilites to make this almost painless, as well as some precompiled kernels, (I would laways roll my own but
This as I said kicks for hosting, its not just a chroot, and its not like the jail on BSD, its....well different.
This isnt somethign youre going to do on your desktop machine , its going to allow you to span resources, this is COMPLETLEY different from VMWare etc, for all the yahoos that are gonna say this has been around forveer.
After SEVERLY abusing our test server to hell an back starting 2-1 we are going to be offering hosting in this enviroment , we have clients that want their own playground but dont want the maintenece, some have semi-secure data theyre just no comfortable on a shared solution and cant quite justify a dedicated box, were already slated for 10 clients and with their current traffic and traffic times, they will all play very nicley on the same machine
P.S. LOAD up on the ram , and make sure to use SCSI , Low ram and Ide will work but start to bog under load, remeber you have 10 different Linux installations trying to access the disk at once.....
Sig went tro...aahemmm.....fishing........
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.
I was under the impression that jail(2) did that, too.