Bladewatch.com

I was interviewing one of the AtoV consultants about a VMware project that had gone wrong and it was fascinating to read what issues it was that they had, and how they were resolved.

The key issues were:

• Inadequate capacity – resulting in poor performance or perception of performance which is just as important
• Lack of a unified voice – three different groups that supported the ‘VMware’ infrastructure, comprising Linux/Windows and the ESX part
• Requirement for processes definition and acceptance – every time a user requested a virtual machine there was a different work-flow to follow or no work-flow resulting in calls going into the IT function somewhere
• No clean-up strategy – a server might get virtualized but the hardware re-used without accountability – the organization now had hundreds of virtual machines with a similar number of physical servers – 4 physical servers had been removed as they were below spec.
• Ineffective standards on what a virtual machine would be with concepts of marginal cost and benefit.
• No project drive to actively and retrospectively virtualize hardware – strategy was going forward, not addressing the existing server estate resulting in many servers being ruled out of scope
• No overriding strategy linked to business need – this is where we need to be, and this is how we’re going to do it
• Too much business override concepts – one application team had negotitated that they were out of scope – this gave voice to others saying the same thing, resulting in few teams really using it as they should

These issues resulted in:

• Poor perception of VMware and virtualization
  • The technology and standards were restrictive – the machine specifications supported were set
  • The end user community lacked knowledge and support of the platform
  • The IT had a luke warm perception of the technology (or the way they did it)

• Poor delivery and user feedback
  • Building a virtual machine took too long – it might take a few days for a virtual machine to get built
  • The roll back functionality within virtualization was not enabled and there was no process to manage it if it was – so no roll back benefit of the platform
  • The specifications allocated to a virtual machine were not aligned to the operating system or user requirements
  • The platform was olden days in configuration with no disaster recovery or failover scenario
• Lack of investment and the organization contemplating a new data center and hardware refresh project at massive cost

What did AtoV suggest and deliver?

A range of process, best practice and some open source applications to create:

• A small/medium/large virtual configuration per operating system supported
• A definition of what was in and out of scope for the virtualization project – with illustration of support from senior business teams
• A user interface and vehicle to directly talk to the virtualization team and stakeholders illustrating backing of the platform
• Organization based best practice about virtualization, service delivery identifying a virtualization voice
• A virtualization overview to discuss project priorities, to move from where they were to the next generation platform

The results, a project which virtualized all x86 hardware older than HP Proliant G4, resulting in a project with aims of virtualizing 85% of the x86 server estate excluding specific roles and applications. A unified voice for virtualization project which encompassed the target, virtualization, migration and decommission of each system targetted – project success defined by hardware decommission and acceptance of the business unit on their virtual machine.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.