vsphere_static_160x300
Badges

vexpert_logo_100x57

gestaltitbadge

follow-me-twitter

Subscribe to me on FriendFeed

Comments / DISQUS
Feedjit.com

Detailed P2V Analysis Flowchart for the “Fruit in the Canopy”

Virtualization can be credited for popularizing the phrase “low hanging fruit” as a referral to the set of physical servers so underutilized they are easy virtualization candidates. Now, as virtual infrastructures (VI) mature and larger, more resource intensive applications are being considered for physical to virtual (p2V) migrations, administrators and application owners need to figure out how to adapt existing VI designs to accommodate the “fruit” still left in the “tree canopy”.

Anyone who has already “harvested” their own “low hanging fruit” knows there is so much to consider. The p2v tool and process are the tip of the iceberg, change control is just below the surface, and there are many more technical challenges hidden in the depths. I’ve blogged in the past about treating the migration to VI the same as you would changing physical data centers. It’s not just server builds and operating system installs.

These same challenges experienced during the initial consolidation are still there for the rest of the bunch, but most likely on a much more public and political scale. In fact, since more times than not these same servers were left out of the first consolidation scenario as “bad virtualization candidates, it’s likely time to


redesign the entire environment to now support a potentially 100% virtual data center.

To help visualize what is really needed, Rick Vanover created a great flow chart that, although it illustrates a complex process, may be the simplest starting point for understanding how to get the rest of the applications/servers virtualized. Vanover’s Virtualization Review post titled Advanced Virtual Conversion Flowchart provides for download a Visio diagram he presented recently at the 2009 TechMentor Conference. Vanover says it best:

“This is more detail than you would need for the typical conversion, but is helpful when you have difficult systems that you haven’t converted for any reason yet”

What impressed me is that the flowchart takes you through a logical process to consider all factors and their impact. For example, storage and networking each have their own decision points. Using the flowchart makes the administrator realize that just because the consolidation tool says there is room in the current VI and the hosts have enough RAM, CPU, network ports, and disk doesn’t mean the p2v will be a snap and the planning is over.

Here is a screen shot of one of the tabs in the .vsd.rvanover p2v conversion checklist

Read Vanover’s post and get a copy of the Visio. On a server by server basis, combine your favorite capacity planning tool’s results with the flowchart’s process before picking the rest of the “fruit in the canopy”.

Related Posts

  • Dracolith
    Some of the most important considerations may not be on the chart.
    And it seemed are really items "Workload"; Disk space/storage isn't _that_ much separate from Memory requirements. Almost like "Workload" is used as a sort of vague "catch all" on the chart.

    Peripherals and access to specific networks are also a resource. One resource not mentioned is network usage, network performance requirements (E.g. Packets per second), CPU usage is mentioned, but 'CPU scheduling requirements' arent, eg

    Think along the lines of app sensitivity to timing and Jitter, and suitability of Virtual NICs and vCPUs. For example: Asterisk is highly time-sensitive; you may be able to provide 10x the memory, CPU, and all the needed peripherals while virtualized, but the VoIP audio quality is unacceptable when virtualized (for more than a few simultaneous calls).

    The VM isn't running on the CPU 100% of the time, so the vCPU ticks aren't the real clock ticks -- VMware simulates them, and in some cases acts to "catch up" the VM.

    The capacity planning tools can't tell you this, either. I expect NTP servers, and some other audio and video streaming servers/apps are also quite possibly un-virtualizable. In RHEL 4, in particular, NTP abysmally fails at anything close to accurate timekeeping.

    You need to test the application, or check with the vendor.
    Instead of just considering "Workload" and P2V experiences last, some apps should be ruled out immediately.
  • Dracolith,

    Great points, and I can argue that workload is a generic
    representation of all the gorey details you dive deeper into. Your
    point is well explained regardless.

    As far as certain apps always being unvirtualize -able, consider a
    single VM as a guest on it's own host and not consolidated. There are
    many unique advantages and VI features that make it worth doing this,
    and solve the possible resource contention.
blog comments powered by Disqus
Hyper9 Cowabunga
Support VM /ETC
Support VMETC.com

Support VMETC.com

Free Business and Tech Magazines and eBooks
@rbrambley tweets
Advertisements
VMTN Roundtable Podcasts
Subscribe



Add to Google Reader or Homepage
Subscribe in NewsGator Online
Add to netvibes
Add to Plusmo