Is P2V-ing your existing machines into a VDI environment really an option?

At BriForum, Jim Moyle and I gave a fifteen minute session on whether or not it makes sense to P2V your existing machines into a VDI environment.

At BriForum, Jim Moyle and I gave a fifteen minute session on whether or not it makes sense to P2V your existing machines into a VDI environment. Even though we'd been talking the idea over since BriForum London, it wasn't until the day of our session that we realized we each had different ideas in mind for what exactly that meant. Jim's idea was that you would use your existing traditional desktop management infrastructure (Altiris, Ghost, SCCM, etc…) to re-deploy your existing desktop images into virtual machines as opposed to bare metal. This idea was met with thoughtful nodding and general acceptance as a method of avoiding the image and infrastructure building process. You'd still need a broker, but you could figure the rest out later.

I, apparently, went completely off the deep end, thinking it revolved around taking your existing PCs and converting them to virtual machines. Most people in the room seemed to come in with that same idea in their head, which can only mean one of two things:

  1. The attendees have joined me in the deep end
  2. They were fooled by the session's title because...well...I wrote the title.

Most people were concerned about the storage implications of bringing in the contents of every user's hard drive. I think that, even with the different systems, a lot can be done with dedupe or single instance storage solution. Even the craziest corporate machines are still probably 80-90% similar when you boil off all the junk.

Junk, actually, was the second biggest argument. Some people thought that moving the junk from the cubicles into the datacenter doesn't make any sense. It would cost more from a storage standpoint, plus it would conceivably lead to higher CPU and memory utilization for each VM. Our way of thinking there was that the management of those desktops doesn't change, so if you had a well-managed traditional desktop environment, you'd continue to have a well-managed virtual desktop environment and be well on your way to full-on desktop virtualization without the 18-month implementation time. Add to that any storage optimization put in place and you could end up with a halfway decent solution, even if not optimal. After the initial migration, admins could then focus on rolling users over to purpose-built images designed for VDI while still realizing some of the benefits during the image creation period.

I learned after the session about some colleagues that have done almost the exact thing we talked about (which would have been nice to know before the session!). Steve Greenberg and Joe Shonk, both BriForum speakers and Citrix CTPs did just such a project, and they shared a few of the details with me of a project they did where this A) made the most sense given the customer's requirements, and B) worked.

Skirting the typical project methodologies is not something companies are prone to doing, so you can imagine the circumstances surrounding such a project would be pretty unique. In this case, a Fortune 50 company (American Express) was buying the credit division of a Fortune 10 company (GE), and the desktops needed to be migrated to American Express while keeping the desktops isolated from the credit data for regulatory reasons (American Express owning Visa and Mastercard data would be frowned upon, for instance). Among the challenges they faced were:

  • Short time frame (90 days)
  • Little knowledge of the architecture of the existing systems and home-grown applications (around 100 total)
  • No access to licenses or installation media
  • Many use cases / departments (i.e. different images) around the organization
  • Not enough time to bench test everything on XenApp or in new environments

So, while XenApp and application virtualization would've been the preferred method given a longer time frame and better access to the applications, they concluded that the best course of action would be to go with XenDesktop by converting existing machines into virtual machines. They did this by locating the best system for each department, then using XenConvert to turn them into virtual machines that were later deployed to all the users in the department via Provisioning Server.

(Steve actually gave a presentation about it at Synergy in 2010, which you can watch here)

Of course, it's not that simple. Several tweaks had to be made to each image to optimize them for virtualization, like re-working antivirus & firewalls and removing the "Computer Reside of Applications and Personalization," or, C.R.A.P. (that was Steve's joke :). The end result, though, was that they converted existing traditional desktops to virtual desktops in a very short period of time with a large degree of success. American Express owned the desktops, and the data resided safely outside of their systems so that business as usual could continue throughout the transition.

After the initial project was complete and the dust had settled from the acquisition, they were able to rebuild some of the images from scratch as licenses, media, and information were tracked down for the systems. This, of course, led to a more streamlined and typical VDI environment.

This more or less fits perfectly with the thought that I had after listening to Jim at BriForum London. While the circumstances that drove the example are extreme, I'm left wondering if there is a broader use case for this concept. It's definitely not a method that will save money, but the time savings could be enough to draw some consideration. So, now that the concept is out there for all to see...what do you think?

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I actually didn't give much thought to this session or idea prior to BriForum...but after thinking about this more and more after BriForum it really rang true for me.  Projects are delayed by trying to create this new model for desktop management, which adds time between purchasing and a full rollout...therefore value derived from such a solution is also delayed and the hardware purchased in some cases up front gets older and older.  If a company purchased a large amount of the hardware for traditional HVD up front and then started on a conservative migration plan it's very conceivable this process would take months to years.

Rolling out XenApp for the easy task workers with no personalization and then cleaning up the rest with dedicated HVD pools where users can continue using their desktop the way they are used to (it's just hosted) and use traditional desktop management tools seems like the best and easiest way to move desktop virtualization forward while we wait for better layering tools to develop.

funny thing when i saw this post...i'm almost done with my own blog post on this very session... it really had me thinking...and I didn't expect that.


Use case to actually P2V a PC:  Unmanaged home PC upgrade.  I usually P2V the current image as a complete backup, then wipe out the hard drive to install the new OS, and then migrate from the virtual old.  2 months later when someone (no names here!) asks where this other file is that they stored in some obscure folder is I can still find it.


"it really had me thinking...and I didn't expect that."

That's how it was when I first heard of it, too! It's definitely a two-step process (migrate the traditional machines, then re-migrate them to *real* VDI images later), but I'm thinking there are more than a few use cases where it might be a plausible migration method. Maybe not ideal compared to traditional scenarios, but plausible.


We are sort of talking a halfway approach to this by letting the AppSense agent collect user profile and app config data for a couple of weeks.  When we migrate the user over, the desktop looks pretty much the same as their physical, and the "My Documents" has been moved to a redirected folder on a file share.  Pretty much the same end result (minus the "crap.")  This is kind of a new opportunity to gain some homogeneity (even if it is at the expense of 100% "like-for-like."  These ARE corporate assets, after all.  If your Turbo Tax data didn't come over for the ride, that is probably a GOOD thing <g>.


Agree with this. Trying to redesign everything day 1 results in no action and nothing get's done. Solve a few business use cases first the fastest way you can and p2v is fine, then worry about management as you expand and have already got business backing showing the value. No point redesigning the plant day 1 until you show real value.


I couldn't agree more -- decoupling migration from on-going management is the right thing for both IT and end-user productivity. End-users want to continue their work with minimal disruption and don't want their favorite apps to disappear  because of the migration. And IT typically must complete the migration with limited time  (e.g., moving offices, buying companies, etc.).

At Wanova, we developed a dedicated flow for automated mass migration (could be used for P2V or for P2P, e.g., desktop to laptop) which applies  a base-image for the target (virtual) devices and overlays them with individual user-installed apps, in addition to user-data and profiles. With WanOpt and Single-instance Store the overhead is limited, but most importantly, IT gets its work done quickly and users get their exact desktop environment quickly.