If you have ever had to justify the deployment of a new server, you will know what an uphill struggle it can be to clear all kinds of technical and business hurdles. Some of these can be addressed by virtualisation, but often all that does is move the bottlenecks further down the line, as well as add a few “virtual” problems …
>> Another, arguably better, approach is to automate the processes involved and allow self-service provisioning.
Personally I really, really, really do not think that is in any way an answer to the problem of end of life management for virtual servers. I'd argue exactly the opposite - it means business users can provision themselves a server on a whim, not tell anyone, and then just forget about it when they change their mind.
It's bad enough if servers are centrally and you can record their creation, but when the techies find themselves with no free resources and a gazillion unknown servers, then it's going to be even harder.
Unless part of that automation system requires the 'owner' to log in and refresh their server from time to time - without which it will just get turned off automatically. That is often the *only* way to deal with some of these servers (whether real or virtual) - turn them off and see who (if anyone) complains.
Not so fast, tiger
> a couple of Linux servers for system testing – no problem, just press a few buttons.
Hardly! You still have to go through the same change control disciplines: justification, risk and impact analysis (which are even more onerous when adding to shared hardware), cost recovery and cross-charging for all of the above PLUS actually pressing those few buttons.
If you're using VMs as a way to subvert the process, you're almost certainly doing it wrong. If you have no controls in place (Ahhh, bliss. Them were t' days) they it's just as easy to pull a gash box out of "the cupboard" and kick off an unattended install.
The other thing to be aware of about virtualisation, is that nothing is free. If you do have a honkin' big server that is good to host a dozen VMs, who pays when number 13 is needed? Does the sponsor have to budget for a whole new server, or do you divvy up the costs for the box amongst the services who asked for the VMs? If you do the latter, then there's not much saving in admin terms between the work needed to do that and buying in a separate server for each function (which, generally the users prefer anyway).