VMware exec says Windows days are numbered (ComputerWorld)

Is the cost for this really higher than the cost for updating the library for only "one"
operating system per host?  I assume one of the following is true.

1 - You use the normal distro update mechanisms
2 - You use a custom update mechanism
3 - You don't have any rhyme or reason for update mechanisms

Does haveing various virtualized machines tend to move people from one choice to another?  I'd
expect there'd be some of 3, and then customer pressure to enable 2, products to do 2, or at
least a return to 1, among the vm-application providers.

There are certainly likely to be more raw updates, but the computation time to update is not
high, and the bandwith cost is solvable with networks.  The problem scenario is if each VM
explodes, you have more explosions, but I think you're somewhat screwed in a non-VM case as
well if you use 1 or 2 to automate exploding your entire server farm.

What am I missing?

I don't think the pain of updates to Linux is anywhere near the pain of updating MS products.
Not being in IT, I had always heard that patch Tuesday are the worst updates to apply as you
never have any idea of what they will break because of how convoluted the windows code base
is. Having hundreds of VM's as opposed to 1/3 as many Windows servers would seem to me at
least to be far easier to handle. Especially given how easy patching the major distributions
is now as most have auto security update systems you can use.

before you had six copies of an OS to patch and administer, after combining them you now have seven (the six virtual machines and the host OS)

unfortunately many people view virtual machines the way you do and don't ever update them, eventually this is going to start catching up with people.

there are valid reasons to do virtualization
if you have one or more of the following situations

1. you have programs that won't play well with each other that you want to isolate.
2. you have systems that require administrative access from different people that you want to isolate
3. you want to keep each system image as simple as possible to ease administration (accepting the cost of administering more systems)
4. you have systems that have peak uses that don't overlap

and the requirements of the systems are such that a single box can power them all

then it can save you power, rackspace, and possibly money to buy one box to host the other logical systems as virtual machines.

virtualization doesn't solve many problems by itself (in spite of what the vendors claim). yes, it allows you to do graceful migrations from one system to another (by suspending the virtual machine on one box and starting it on another), but only if all the settings are still valid in the new location (same network settings work, no connections to local resources, etc). but this is _not_ the same as making the application highly available, if the first machine crashes the second machine does not have a fully up-to-date copy of the virtual machine to run

Actually, the concept of a VM browser appliance, it's own little 
machine, /without/ that helper you mentioned, seems pretty appealing to 
me.  So it gets 0wn3d, so what?  Let it run amok in the VM where it can't 
touch anything else, and where shutting down the browser shuts down the 
VM, which is reset to a mostly clean state on restarting it.  Let the save 
dialog save in that sandbox, not anywhere out of it, and let the user 
access the stuff in that sandbox as they would stuff in a chroot from 
outside it.  The user could then cp/mv a file to elsewhere on the the 
parts of the system they can write to, but the browser and anything 
(plugins, etc) running in the same VM would have access only to the 
filesystem and machine in the VM.

One could even have a special VM supplied by their bank, that /only/ did 
banking, and was separate from all the other VMs.  Online games and the 
like could work similarly.  Mail?  Same thing, it's own VM, limited to 
writing to its own VM managed filesystem sandbox.  That one could have a 
browser in the VM as well, which would load when you clicked a link, but 
it too could only write in the common mail/browser sandbox, which would be 
separate from regular system browser sandbox.  The user in the hypervisor 
could of course copy files and etc between sandboxes or out of the 
sandboxes into the hypervisor level, but the apps within the VMs couldn't 
access anything outside their VM.

Of course this would play havoc with browser based system updates, since 
all they'd update would be their little VM, not the hypervisor, which 
would have to run its own updates, but that shouldn't be a problem.  The 
hypervisor could in fact have its own little update VM (it's a net based 
update fetching service so it goes in a VM, not directly on the 
hypervisor), limited to that one special service, with the hypervisor then 
copying the updates out of it and applying them on the main system.

Meanwhile, VMWare's still black-box proprietaryware, and as such, it's out 
of the question here, as of course are MS OSs in VM or out.  KVM or xen, 
sure; they aren't proprietaryware.

Duncan