> > The only requirement would be that the host be able to support your
> selected VM software.
> >
> > In many respects it could make deployment, maintenance and recovery much
> easier -- you wouldn't need to care about the host OS, and if the hardware
> failed, they would need to install the OS, the VM host SW and then copy
> your base VM into the system.

> But I WOULD need to worry about host OS?

For my point of view, no you wouldn't -- using a VM solution would mean that you would care very little about the host OS.

> Linux is all 64bit nowadays, and any decent packaged distribution has
> Apache, PHP and Firebird already available. Although 'modern'
> distributions can be the same pain as windows :(

Yes, but how many distros are there?

How many different definitions of the "standard" fodlers/install paths do you want to have to deal with?

By creating a *32bit* VM with all of the tools that *you* need, you can be guaranteed compatibility across all of the Linux platforms as well as most of the modern Windows platforms.

> Windows is just a mess? And that is the point... 'install the OS' ...
> WHICH windows OS and the 32 bit or 64bit builds of Apache, PHP and
> Firebird. VM is just another unnecessary layer in my book?

Yes, a VM is an additional layer, but that layer can make the difference between you being a solution supplier (VM) vs. a systems engineer (non-VM) by allowing you to get out of having to worry about the underlying hardware/software details.

Layers aren't always bad things -- it is just a question of what they can allow you to do.

Further, most VM Host software actually has a very low overhead.

If that wasn't the case, no-one would be moving major applications like email and database servers to VMs.


Sean