[FASherman]

I've spent this week unvirtualizing a virtualized environment I built for a client a few months ago. It was their first virtual I/O environment, and I spent a great deal of time coming up with a consistant, easy to understand naming and numbering convention for virtual adapter slots and virtual devices. That, in my opinion, is where success of failure is really determined, long before configuring your first virtual adapter or virtualizing your first hdisk.

The admin was able to easily maintain the system, but the storage people were the problem. They've been managing the DS8100-based SAN as though it was FICON, because they're mainframers.

It has lead to a nightmare scenario where the SAN is zoned through a combination of switch based port mapping and DS8100 mapping based on WWN. The DS8100 ONLY supports UNIX servers and only via FC SAN. Its really a no brainer. Run the SAN as an open fabric and manage access at the DS8100 only.

Anyway, this nightmare scenario has led to the storage management people pressing for dedicated hardware rather than virtualized hardware. Two p520 are now being replaced by 3 p520s, 1 p550 and 3 D20 RIO drawers and a bunch more hardware.

This also confirms my statements to clients the VIO, properly designed, will save you OVER 50% in implementation costs.

Using some techniques that IBM claimed wouldn't work - what do they know anyway? - I've got the process of unvirtualizing the server down to a 20 minute outage. By that, I mean at T+0, the applications on the virtualized server are brought down and at T+30, the applications are up and running on the new dedicated hardware server.

Since I'm sure others will experience the heartache of unvirtualizing an environment for various reasons - none of which I'll wager will ever be technical - I will write a case study in how to do this quickly, effectively and without putting the customer's data at risk at any point in the process.