In part one of this series, we looked at selecting an enterprise virtualization platform, and at some of the benefits gained. In part two we looked at some of the challenges involved in selecting hardware to run the platform on, and we also discussed storage, networking, and servers/blades. Part three took a closer look at networking issues, and in Part 4 we gave some practical, nuts-and-bolts advice for how to tune your VMware enterprise setup. In this final installment, we look at the issue of physical-to-virtual conversion, and give tips on best practices.
The biggest challenge facing a physical-to-virtual (P2V) migration in an enterprise setting is not actually technical—though there is a technical challenge, as well. Rather, the actual challenge is the timing, paperwork, and ample red tape to you'll have to face on a system-by-system basis, as well as a general cultural clash against the status quo.
In any sufficiently large environment, there are multiple tiers of service, ranging from mission-critical to development to lab systems, each with different uptime expectations, and different levels of expendability. So it's a good idea is to begin at the bottom, with the least important systems, and work your way up. The benefit of this approach is that any kind of early failure in the process won't be cared about too much, and because you'll have more experience with the P2V process by the time you migrate the mission-critical systems. But before we get to talking about various P2V migration strategies, we have to look at a very large reality in most enterprise environments: legacy systems, and red tape.
Read the comments on this post
No comments:
Post a Comment