Link: vmMBA.com: Refresh Now!.

Why would you replace a server that runs fine, meets SLAs, and is not fully depreciated?

This is a common obstacle to replacing a physical server with a VM when it is not yet "ready" to be refreshed. Historically, people have had a hard time producing a business case for these servers. Here, I present a framework that can help justify a "refresh now" plan, and it is based upon a few key requirements:

• Energy costs are real.  ...
  
• Shared Storage costs are decreasing.  ...
  
  
• Multi-core processors have an impact in two areas: ...
  

When you take into account some of the above factors, it's often quite easy to produce a strong business case for virtualizing servers that are not yet due for a refresh.

The following spreadsheet shows a per-VM analysis that determines the breakeven point, in months, for virtualizing a server that still has useful life remaining.

From VMware's Gerod Carfantan, a new blog vmMBA, "Exploring the Business Side of Virtualization." Here's an excerpt from his latest article: vmMBA.com: The Virtualization Adoption Lifecycle.

Level 5 - "Business Transformation [2008]

 

This is the year of Business Transformation through virtualization. 

Some organizations got a head start on Business Transformation in 2006-2007 through the uses of Virtual Desktop Infrastructure (VDI) and Virtual Software Lifecycle Automation (VSLA) tools like Lab Manager. These tools allowed them to change the way development infrastructure or desktop services were built and managed, without transforming their production server infrastructure.  We're seeing an increased adoption of those solutions, but my focus here is on the transformation of the way production servers are architected, built, managed, and commercialized.

Another key development is the concept of "Transient VMs".  Traditional (physical) server architecture means static servers, built for a purpose, and those servers typically "stick around" for a long, long time.  A server that is powered on and placed on the network is a server that must be patched and managed.  Transient VMs are those that are created for a purpose, but then may be archived or destroyed as required. 

Examples may include test VMs (clones of production, perhaps), development environments in Lab Manager, or legacy applications in VMs that can be powered off and archived for compliance reasons.  Plus, the great thing about powered-off VMs these days is that they can be patched with VMware Update Manager (in other words, the best of both worlds: a patchable VM that doesn't need to be managed on a day-to-day basis).

A third development is the use of advanced automation with virtualization.  VMs, because of their portability and flexibility, are a much better object for automation than physical machines.  This has given rise to solutions such as Dunes VS-O (now part of VMware), which automates hundreds of workflows that normally would be performed manually.

A fourth development is the fact that organizations (both outsourcers and internal IT shops) are offering new services that use virtualization at their core.  These includes Disaster Recovery (using internal assets instead of third parties), on-demand computing, or hosted virtual desktop.  For outsourcers in particular, it means that they can get new revenue streams, without increasing their customer's overall IT spend (usually, the customer gets more revenue, and the customer reduces costs).

A combination of organizational experience, experience in the systems integrator community, and product capability has given us the "perfect storm" in 2008 for business transformation.

Dan Kusnetzky, who has a blog here: Virtually Speaking on ZDNet, has written a number of thought pieces with his consulting/analyst hat over here: Recent Publications from the Kusnetzky Group at his website. He's usually exploring the interface between the technology of virtualization and operationalization in a business process.

I like this recent one: Virtualization: Evolution not Revolution (pdf link). In this short 3-pager, his basic point is that things move slowly in the enterprise data center, because IT managers must be risk averse.

The Golden Rules of IT

1) If it's not broken, don't fix it. Most organizations simply don't have the
time, the resources or the funds to re-implement things that are currently
working.

I think paradoxically this has been one driver for VMware's successful adoption. It is so easy to get started with VMware -- download VMware Server or a VI3 eval, then convert [warning: sound] some necessary but little-used old servers that are just sucking up electricity, and go. You don't need a special paravirtualized kernel, just whatever you were running (Windows, Linux, Solaris, etc.); don't need to recompile your app; don't need to get special hardware; and you don't even really need a SAN or other fancy enterprise storage to get started -- just virtualize, no re-implementation needed. The key point you need to realize at this level is that you treat a virtual machine just like its physical counterpart -- although try not to have every antivirus and backup job in every virtual machine on an ESX Server fire off at the same time.

Now when that works great and you do want to see how to take more advantage of the opportunities afforded by virtual infrastructure, then you do have to do some more planning -- maybe get more storage, certainly get some expertise and evaluation of your current infrastructure, and start to figure out how this affects your processes when a new server can be provisioned in a few minutes and your DR plan is finally something more than just a fantasy.

Ultimately you end do up with a data center that looks, acts, and is managed quite differently than what you started with. So was that by evolution or revolution?

(Anyway, Dan has a lot of great stuff there; read up, then go forth and virtualize carefully but with great ultimate success.)

[Update: enterprise software is sexy when it is innovative. The relevance of this article to the current discussion is left as an exercise to the reader.]

Martin talks about seven key areas to watch when deploying virtual infrastructure in order to keep end-user perceptions in line with reality and to not pre-emptively blame virtualization for other infrastructure issues.

Blade Watch » Key issues with vmware.

Proactively resolve issues which might cause delays or problems with the consolidation, life’s too short, and since perception remains key it’s important. Use the migration time to improve the servers you consolidate, clear down those files, check the configurations, check the patch revisions, the layered components, and most of all above else ensure your network connection is as close to ‘production’ i.e, development as possible.  There’s no point migrating 10 servers from 100/full to 10/half if the users are going to complain about network speeds.

I’ll give you an example, when migrating your windows 2000 DL360’s, some of them may have 256mb ram, and a 4gb drive for C.  Double the ram memory, increase the C drive to a reasonable size so you aren’t visiting them later causing an outage which will be associated with IT, with vmware.

Martin MacLeod is on a roll these days at Blade Watch. How to do chargebacks and resource accounting were huge topics the last two years at VMworld. Expect more from VMware on best practices for operationalizing your virtual infrastructure. How do you do chargeback? How do you account for slicing a big server into lots of little servers?

Link: Blade Watch » The cost of a virtual infrastructure.

Say I virtualize a DL380G4.  Now this bank depreciate their servers
over 3 years, the server is two years old, who pays the depreciation?
The application team are saying, well you’re taking the box of us, you
pay it, but then who owns the asset.  Can IT take this 380, and swap it
for a Proliant 5000 to get rid of some legacy hardware?

Also there was some internal debate about costs. Buying and paying
for a DL380G4 in the model above is easy, say it’s £6000 for the server
including all the bits, the software, the memory, the disks etc, that’s
£2000 a year (excluding support cost).  What is the cost of a virtual
server?  They’re currently having an emotional conversation with an
application team saying that their virtual server has 1 processor and
1GB RAM, therefore it should be cheaper than a server with 2 processors
and 1.5gb RAM. But do we really want to go that granular with our
charging?

Martin MacLeod at Blade Watch has some great observations on virtualization from the data center floor. Check out his whole VMware category. On Sunday's post, he talks about how virtualization can affect even something simple like asset tracking. At VMworld, chargeback was a hot topic. Link: Blade Watch » The need to manage my datacenter.

WSNT9007 is a DL380G1 running windows nt 4. ... It has an asset tag 300587, that’s how purchasing track it, but that tag means nothing to the support team to them it’s WSNT9007. Now, the application team require the server be added to our active directory, as part of this the name has to change to WS29007, this is done following the change process, and all the records are changed, someone tells purchasing that the £350 support cost is now for the new name, that asset tag corresponds to new name etc.

The server is virtualized to a vmware session. The physical hardware 300587 is now in fact WS29008, but WS29007 still exists (as a virtual server), the support team know this (as do the infrastructure teams), but now, how do we track all these changes, relate everything? How do I know that WS29007 is now running on the hardware for the old server, and how do i relate this in charge back etc. It sounds simple in a small server estate but scale it up to 45 application teams, 3500 servers and you see the importance of two things due diligence with your datacenter management, and the accuracy of the information you have for your servers.