After finally getting the go-ahead to proceed with a project to virtualise your physical servers into a cloud environment, it may seem that the hard part is actually making it all happen. However, in most cases the actual migration is one of the easiest parts.
The most important part of migrating from a physical to a virtual infrastructure is making sure you have all the pieces in place before you move a single server, before you put anything into production, and even before you start testing. To that end, it's important to be fully aware of the features and limitations of the virtual environment whether it’s a shared cloud or a dedicated, private cloud.
In most cases the advanced features, like hot migrations and VM resizing, will be available on a public cloud but in smaller private cloud, the lack of these features isn't as critical as it might be. This is due to the smaller number of virtual servers and the general lack of unbalanced or highly-variable workloads. Either way, it's important to understand what you have in your toolkit before you start.
Handling the Virtualization Migration
Every infrastructure is different, so there are no ready-made plans to move servers from the physical to virtual realm, but there are general rules that you can follow.
Physical to Virtual (P2V) migration tools are available from a wide variety of vendors including our own 4D CloudScraper for migrations into the 4D Public Cloud. They work by creating an exact clone of your physical server including operating system, configuration and data then transferring that into your cloud provider or private cloud infrastructure. Many servers can be successfully migrated using these tools which will save time and hassle during the process. In some cases, (usually with servers running specialist applications, or servers requiring the use of hardware keys, or licenses that are bound to specific physical server elements like Ethernet MAC addresses) using P2V on these servers is more problematic than simply rebuilding them as virtual servers, but you should be able to migrate the majority of your servers without a problem.
The good news is that in most cases you can attempt a P2V migration of a server without causing problems on the physical server. Usually, the physical server will continue to run and the tool will simply create a snapshot from when you started. It then transfers that without affecting the running of your physical machine.
That said, before any migrations take place, make sure to test your backups. Always have a backup plan in place should something go wrong.
There are servers and applications that shouldn't be migrated using P2V tools. A good example of this is a Windows Domain Controller. Due to the way these operate it is much easier to just build a new domain controller in the cloud environment then add it into your domain before turning off your old physical server once everything has migrated across.
Other servers can either be migrated using P2V tools, or simply rebuilt as virtual servers. In some cases, rebuilding the servers is a great way to clean out the configuration and years of changes that can accumulate on older physical servers. Using P2V to migrate a physical server is not going to fix any existing problems, and may actually make them worse in some cases. If you’re unsure of the stability of your existing physical server, then we’d recommend doing a P2V but leaving the existing server for a few months as a fall back.
When you're doing a P2V, take steps to ensure that there isn't a time when the physical server and its virtual doppelganger aren't running simultaneously. The P2V process retains the entire presence of the physical server, including the names, domain membership, and IP addressing, so having two present on the network at once can cause significant problems. The best idea is to power down the physical server and remove the power cables following the migration, then power up the new virtual server.
The process of converting a physical server infrastructure to a cloud infrastructure doesn't have to happen overnight. You can start small by choosing one or two physical servers to convert, and let them run for a period of time as virtual servers in order to determine their viability. You can convert one or two servers per day, or per week. Generally, there is no need to attempt a full conversion all at once.
It may also be of benefit to combine a cloud migration and virtualisation initiative with a software or OS upgrade, perhaps migrating from Windows Server 2008 to 2012 for some of servers. This allows you to test both the new platform and the expected behaviour of the new server operating systems while retaining a fall-back position with the existing infrastructure.
Finally, as you progress through the migration, take your time at certain points to regroup and ensure that you're following your original plan. Also, make sure that plan includes implementation and testing of backups for your new cloud infrastructure.
Once you're done with all your migrations and rebuilds, you'll most likely wonder how you ever lived without the cloud!