P2V pre-migration checklist - and considerations

My prevoius post was a P2V post migration checklist. This post is a pre-migration checklist which is about all the information that should gathered and checked before doing any P2V conversions.

I have been involved in a number of larger P2V projects (+50 P2V's) and, in my experience, proper planning is a key element for a succesful project. Typically, you, as a VMware- or P2V person, have no real knowledge of the Windows servers to be converted - their just another server. This means that you rely on other people to collect relevant data on your behalf. Such a setup has an important implication. As you have no knowledge of the server, it cannot be released into production by yourself, you should let a Windows guy verify the OS after which it can be handed over for application testing. Resources for both tests should be allocated up front by the project manager and they should be standing by in the agreed maintenance window.

In regards to the length of maintenance windows, we have had the most succes with long time frames during weekends - e.g. 36 hours from Saturday 08.00 a.m. to Sunday 08.00 p.m. Obviously, such a window can be difficult to obtain, but it has two significant advantages: 1) Specifying the actual conversion time can be tricky - it happens that a 30 GB server takes 12 hours to convert for one reason or the other. 2) It is less stressfull to do P2V's during weekends and a long window will let you work at your own pace, Furthermore, conversions can run over night if they have large disks (e.g. + 200 GB).

Now, a few words about the checklist. Over time, it has been gradually extended as we have learned important lessons - some of them the hard way where. For example, a server that hadn't been checked for hardware dongles, then you need to roll back - or e.g. a VLAN that hadn't been properly trunked... A specific list will match a specific scenario so, typically, the list will be modified to some degree for each project. However, a large part of the list will remain the same, so hopefully it can be used for inspiration. We use Sharepoint 2007 to organise the lists. These can be dynamically updated, which is practical when multiple persons have to update at the same time.

• Servername
• OS type
• Server model

• Has Capacity Planner run for this server?

• # of CPU sockets
• # of CPU cores
• Amount of physical memory installed
• Physical disk capacity (C-drive, D-drive, etc.)

• Current CPU usage (preferably from cap. planner)
• Current memory usage (preferably from cap. planner)
• Current physical disk usage (C-drive, D-drive, etc.)

• # vCPU’s that should be assigned
• Amount of memory to be assigned to VM
• Sizes of vDisks after resizing (C-drive, D-drive, etc. – remember separate .vmdk’s for each logical volume)
• Total size of vDisks (then you can sum up total disk capacity needed and ask for storage up front)

• Local administrator credentials (local windows accounts are recommended)
• “Ipconfig /all” screendump attached to list (this is to ensure you have the right IP and mac address)?
• ILO-information (address, credentials) (if you have to do cold migration)
• Has server been defragmented (this can significantly speed up conversion rates)?
• Has server been checked for hardware dongles?
• Has VLAN been trunked?
• Do server application licenses have any binding to MAC or IP address?

• Remote access type (RDP, Netop)? (for stopping services up front)
• Physical server location

• Applications on server
• What services to stop on server before conversion

• OS tester contact info
• Application tester contact info (for pre- and post migration test)

• Server to be converted by (employee)
• Date for conversion
• Conversion progress/status (not begun, P2V begun, handed over to OS testing, released to production, etc.)
• Has physical server been shut down?
• Notes