Sources for good information on large VMware conversion

Not sure if you wanted some more general virtualisation pitfalls, but I would add the following:-

An important thing to consider is the number of disk spindles you have for storage. It's quite easy to look at physical servers that you are planning to virtualise, and just say I need X amount of memory, and Y amount of disk space, and Z amount of network bandwidth.

When you run physical servers your data/apps are quite likely striped across multiple disks in a RAID array. When they get virtualised they share the storage on the new array created for your VMs. As a result of the consolidation, you will inevitably end up with fewer physical disks, which in turn has an impact on the speed with which you can read/write your data.

If for example you have 200 servers with 3 disks each in a RAID 5 array, that amounts to 600 disks. If you virtualise these servers you will likely consolidate these disks onto a greatly reduced number of physical spindles. You need to plan your deployment carefully to make sure that your storage arrays can deal with the throughput required. Balancing the loads can be crucial.

As IT Warrior says above, you MUST have the performance data for your servers. Without it you cannot make an informed decision about hardware requirements and VM placement. Before running the conversion you need a clear idea of which ESX server, and storage array the the VM will end up on.

Another issue you will want to consider before you go ahead is some sort of strategy incorporating DRS and HA. If an ESX box dies, what happens to the VMs that were running on it? Do you let HA automatically start them up again on other servers? Do you have enough spare resources on your ESX servers to take on the additional load? Do you want to prevent certain VMs from being automatically placed together on the same physical ESX box (DCs etc.)?

If you can fit it in, I would recommend going on the 4 day VI3 - Install and Configure course. As you say, your exposure to VMware is limited, and this course will not only give you valuable hands-on technical knowledge, I believe it will help you in understanding the issues that you may face along the way. It is a more general course, but conversions will be covered. Additionally it gives you an opportunity to ask questions of the instructor that may be relevant to your project.

Rik

Without knowing what types of servers they are, it's difficult to say. It will be dependent on the applications, and the amount of data on the servers.

One thing you need to check is that your applications are supported on virtualised servers. We have some apps that the supplier refuses to support on a virtualised platform.

Also, if you have any apps that are licensed on a per CPU basis, you may want to check what the licensing policy says about virtual CPUs. The advice given to me in this area is that when creating a virtual machine always start with a single virtual processor for test purposes to see what performance you get, and only use virtual SMP if you really need the extra performance. I'm not an expert in this area but I believe the reason to limit use of virtual SMP is to reduce scheduling issues and to avoid having to do things like setting CPU affinity. One of the reasons virtualisation works so well is that a great deal of servers only use on average 7-15% of their available CPU resources. You may well find that a single virtual CPU running on a modern processor is more than enough for your servers. It may be that all of the old physical servers purchased were dual processor by default, but that they never really needed to be. The hardware performance stats will guide you in this matter.

If you have any servers/apps that are dependant on specific hardware (fax servers etc), that could cause you an issue. If you have any server apps that use a dongle for anti-piracy purposes, that again could be a problem.

I would recommend reading (if you haven't already) the VMware Converter Enterprise Administration Guide (found on http://www.vmware.com/support/pubs/vi_pages/vi_pubs_35.html ) as it also highlights a few reasons why a machine may not successfully convert.

One thing in the guide that may be relevant is that it says:-

"NOTE If the remote physical machine is running under Windows NT 4 or Windows 2000, you might have
to reboot the machine after the agent is installed."

Now I can't remember if that means you get a button asking if you wish to reboot the remote server, or if you have to manually reboot the machine yourself. If you have a large number of NT/2000 it's probably worth confirming that first.

My advice would be to have an audit list of your servers with both hardware and software listed. Check that the servers are using standard hardware, check that the OS can be virtualised (check service pack if required), and check that the apps are supported in a virtual environment. Things like dongles may not be listed on hardware audit lists, so if you suspect an app may use something like that do a manual check. This should help you identify any potential issues.

In terms of timescale, I would suggest selecting a few boxes with disk/data sizes at the bottom and top end, and running some test conversions to get a range of times for conversion. (you may also need to look to see if the older machines are limited by 10/100Mb NICs) From that you could come up with an idea of time for running the conversions across all of your machines. I think your real problem is coming up with a satisfactory testing strategy from which you make the decision that the server has been successfully virtualised. If it takes less than an hour to convert a particular server, how long will it take to decide that it works?

It may be that you convert a WIndows 2000 file server, and test it out for a certain period until you are happy with it. You may then decide to make a decision that any Windows 2000 file servers running on the same hardware can be successfully converted if the conversion process itself reports a successful conversion. This process could then be repeated for different types of servers/hardware.

This sort of block decision approach would have to be balanced with your confidence in the conversion process, and the criticality of the server being converted. In an ideal world without the time constraints you are under, you would want to test each box, but I think you would be pushed to do that in two months.

As a final thought, you may want to think about your backup processes. Are you running agents within each of the old servers? Will there be any performance hit on the ESX box, or storage array, if they are all scheduled to kick off at the same time? When they ran on separate boxes it wouldn't have mattered but with the hardware consolidated it may now be an issue.

Rik