Virtualizing Server Pitfalls - Part 1 - Updated 6/23/09

Firstly, I want to begin with a big disclaimer – this my approach to the P2V’d Virtual Machine. I accept ABSOLUTELY no responsibility for any unforeseen and unwanted side-effects.

Most of you know or have read that I have taken a new position, no longer with Comcast. In the new job, I have become “Virtual Boy”, dealing with everything Virtual. So, I thought that I would pass along some of my insight for your P2V / V2V ventures. This will probably be a multiple part message.. So, bare with me.

Windows 2000 servers are probably what most people are trying to get rid of in their environment, but can’t seem too... because of software limitations. These are also the most problematic to virtualize. Here are some items that you need to be aware of during your migration process.

Pre-Migration Process

1. Software – All servers have some kind of raid/teaming/Compaq (HP) crap software for the system. This needs to be removed, to the best you can, before attempting a P2V convert.
2. Services – If you are not able to remove the software, disable the service.
3. Hidden devices – such as network cards. (you know the ones with the IPs that you need) This has bitten me a couple of times. But, there is process to have them show up and uninstall them - KB Article.
4. Multiple Network Interfaces – This comes back to the “teaming” situation. You really should break the team and set them up as a single interface.
5. Use a block copy method rather than the file method – With the block copy method, you are able to bypass the file locks that Window places on a file that is in use.
6. Oh.. That brings up a good point – Make sure that no one is saving data to the server! Simply, it probably will not be there after the convert.
7. HALs are a big deal – but – with most name brands, this is really not an issue. Buy name brand servers, not Bob’s Server.
8. Key FABs and External Cards – It can’t take them with it. There is a workaround for the USB Keys, but not for cards. (Link)
9. Local Administrator Account - Make sure that you have the local administrator account username and password. (or make an account for you to use, just in case)

Post-Migration Process

1. Turn off the physical server before you power the VM. If you don’t… (Well, can’t fix….) Many tools out there will power down the physical server for you. However, I have found that the power down process take longer than my new VM to boot. So, power the box down and verify that it is truly off before powering on the VM.
2. Install the VM tools and reboot.
3. Adjust your RAM requirements – Here is a perfect time to down the amount of RAM that you have allocated. Truly evaluate how much RAM you really need.
4. Check connectivity – Just because it says that you are “connected”… CHECK! Do various Ping sweeps from the server. Also, you may want to check and verify that you can RDP (TS) to the VM from your workstation. (Assuming you could before)
5. Remote issues – I have not found a solution to this issue, as of yet. Various Windows 2000 servers lose the ability to be able to remote into them from your workstation. Everything else works on the server… but, you are not able to RDP to the server.
6. Domain Account - I have had several issues where the new virtual server is unable to log you into the domain. Log in using your admin account, verify your IP settings (including DNS), take it out of the domain (do not put in your credentials and do not reboot), re-add it back to the domain. Now Reboot. This way, you did not remove the computer account in AD. Basically, you changed the SID on the computer object.
7. Application / Services Check – It should go without saying… Verify that your application and services are running.
8. Finally, Check your server! Check the Event Log for errors, log into the applications on the server, check, check, and do it all over again!

I will append to this entry as I remember or find things to post about.