To P2V or not to P2V – the questions and benefits

| March 8, 2013 | 1 Comment

I was having a chat with a colleague a debate really. He’s a project manager working in IT for one of many multinational organizations in the City of London delivering a P2V project, this is the process of virtualizing your servers, migrating the operating system, application and data from a physical server to a virtual server running on an ESX host.

It was time to catch up with him and discuss how his project was going, it’s phase three, this means it’s the final phase over the last six years to virtualize the server estate, the project in summary is below (for background):

  • Phase one – virtualize all non production application servers, standardizing configurations during the process to reduce support calls and management overheads, this meant for example standardizing the disk space and memory to improve performance or reduce unncessary calls/alerts being generated.
  • Phase two – virtualize all infrastructure and application servers older than three years to allow IT to decommission any physical servers no longer supported under their support contract and reduce data center footprint.
  • Phase three – virtualize systems of all types based on usage metrics and industry standard performance analysis tools to reduce physical server footprint and data center capacity required. This might for example include physical servers deployed in the last 6 months if they could be easily virtualized due to actual load differing from anticipated load.

I was interested to further understand the scope and got us in a debate you see I have mixed views about P2V projects, I am more a fan of combining P2V with a build out program. By that I mean that we do a new for old swap and ask the application teams to test and migrate their applications to a new virtual machine running a newer operating system. Why? We’re only removing the hardware limitation, not the other factors that can generate just as many alerts or risks to stability that is: inadequate configurations (memory/disk space), maintained range of operating systems and configurations that might not meet current standards in terms of design, security baselines and best practice.
So what are the benefits of P2V only project: (Migrating physical server to a virtual machine)

  • Reduce number of physical servers
  • Allow physical servers to be re-organized and re-deployed if they have useable life left in them
  • Less disruption to the end users and application team or underlying infrastructure and application code
  • Path of least resistance – less testing, operational risk and quicker time to market

Advantages of P2V combined with new for old: (replacing physical server with a new virtual machine):

  • We still deliver a virtualized infrastructure – building a new virtual machine is non disruptive
  • Allows parallel run testing before switch over to the new machine and therefore easy roll back
  • Enables IT to bring all systems up to a supported platform (Windows 2008 for example) including layered components, middleware and database
  • Empowers IT to tackle multiple challenges and project goals through one offering, migrating off a physical server on an old operating system, using old SAN switches on old storage to be migrated to a virtual machine on fully supported recently deployed infrastructure – converging business benefit
  • Creates opportunity to standardize applications migrated to existing or next generation standards in configuration and security baselines, standardizing technical issues (development environment, failover and automation where posssible) with non technical, does the existing solution meet the application tiering emposed by the business, it’s tier1 does the current environment meet that requirement?
  • Can be used as an opportunity for both application empowerment (enhance functionality, possibilities from new operating system, middleware and new technologies), as well as training to understand how the application works, data flows for full end to end testing and support.
  • Facilitates the re-enforcing of corporate standards and architecture rules, all front office systems be hosted in data center two rather than three, as we now have the scope and opportunity to build out new systems and migrate rather than work around issues real or perceived.
  • We have one disruptive work stream, the migration to the new virtual machine rather than migrate to a virtual machine only to be contacted months later requesting layered components be upgrade, the server be scheduled for a rebuild to a newer operating system or downtime to extend the disk, allocate more memory or apply service packs.
  • We force the discussion – we’re going to build out a new server, do you actually need this server, or can you relocate that workload to another server where it might co-exist – we in essence initiate the discussion to see if it’s actually needed and in use.

Which should we be opting for then?

It’s going to depend on your circumstances, your operational, political and financial operating model, but I remain a fan of building out a new machine where possible and then migrating the workloads to the new machine, that way we have in essence (where posssible) we target several IT objectives, we have one ‘downtime’ or disruptive activity and move on using our new fully supported and optimized platform on a new OS.  More specifically we don’t migrate our existing challenges from a physical environment to a virtual one, just because it’s virtual does not mean the operating system, application code and layered components don’t still need upgraded to keep everything moving along and in line with both business requirements and vendor support.

Tags:

Category: Data Center, Servers, Virtualisation, VMWare

Leave a Reply

Your email address will not be published. Required fields are marked *