Virtual environments continue to justify their presence in the data center, and most data center managers will...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
eventually be challenged with the task of moving physical systems to virtual environments. In this tip, I will provide some best practices to ensure your migration is successful and occurs without incident. The first step in starting with a P2V (physical-to-virtual) migration is to identify the tools that you will use to execute your migration and the systems you want to migrate. From there, you can lay out the plan that will dictate how you migration will proceed from the perspective of a user or connected system.
Preparing for the virtual migration could actually take longer than the migration itself, but considering the risk of some systems where you may have great pain to go back the planning is worthwhile. Here are some good pre-migration planning tasks that make the actual migration very smooth:
- Determine virtualization candidacy. There are many factors in your environment that will determine the parameters for this question. (Check out this TechTarget tip that shows how to determine if a system is a candidate to go to the virtual space.) Clean the file system. If you have files and data kept needlessly on the system to be migrated, get it out of there. With conversion tools, the total contents of the drives are migrated to the virtual environment so you want to make sure there is no wasted space.
- Fight for downtime before you begin. When you embark on a mass P2V migration, you need to be able to justify to the business a certain amount of downtime to successfully complete the migration. In an ideal situation, the amount of downtime would simply be the time required to change DNS (if necessary) and shut down the migrated system on the old physical host and power on the new virtual machine after all preparation.
- Determine resource provisioning. This is probably the most important decision point to make in a P2V migration. You definitely do not want to under provision a systems resources from the start, and yet reserving too many resources for the guest OS that will not be used is a waste of expensive host hardware.
- Double check your storage and network situation. Storage and networking are usually the biggest obstacles in the virtualized environment. So, make sure you have the correct connectivity and adequate storage for the entire inventory of machines to be virtualized.
- Ensure support from any vendors. Certain software and system vendors do not support virtualized environments. So be sure that you are not putting your organization in an undesired state.
Many organizations have decided to have all virtual machines exhibit a nomenclature that, at least to the server administrator, indicates that the system is a virtual machine. During the P2V process, you are poised with an interesting decision point. Depending on your server nomenclature, the standard may be to indicate in the server name that there is an element indicating the virtual placement.
If your organization has a nomenclature that indicates a virtual presence, you are positioned in a unique situation to determine what is the correct nomenclature to use when proceed during a virtual migration environment. Admittedly, the easy choice is to maintain the exact system name during the migration process. When the same name is maintained during the migration process, the transition can be transparent to all relevant connections to the system. This is, of course, assuming all connectivity is maintained. This makes conversion quite easy, but you should consider the extra effort to convert the newly created guest OS to the new system nomenclature.
It is too easy in the chaos of a virtualization blitz to end up with more instances of your operating system than you started with in the project. Be sure to make sure the original system that was migrated to the virtual environment is not repurposed, but retired. After migration, you do not want to find out that the original system that was migrated to the virtual environment still exists as a physical system for another purpose. One easy way to manage the migration process so that you don't over step the licensing boundaries is to limit your TCP/IP addresses that are available for your virtual hosts, this doesn't enforce duplicate licensing situations, however. This is one area where the follow-through of your virtualization project is critically important to maintain your licensing compliance.
VMware: Old to New
When you are migrating within a VMware environment, some additional specific options are presented while performing the virtual to virtual (V2V) migration. Migrating virtual machines from an older host to a new host, you may be able to consider the following options:
- VMware Converter Tool: Takes the snapshot when the conversion starts and writes an image of the system on the new host.
- VMware Clone Process: The VMware clone task will copy the existing virtual machine to the new host environment, and if you specify, core options can be configured on the migration, modeling the Windows SysPrep tool for Windows systems.
- VMware Migrate Process: This option will move the virtual machine from the current host to the new host, not leaving a virtual machine on the original host.
Understand volume shadow copy service
If you use any tool that can convert Windows systems while they are running, they may use the Volume Shadow Copy Service to perform the migration. In this situation, the image will be taken of the system at the start of the conversion. And once the conversion is complete, you would then shut down the system. Keep in mind, however, that the time between the start of the conversion and when you shut down the original system has only occurred on the physical system. The newly created virtual system will be out of date in this regard. This is critically important for domain controllers (mentioned below) but also important for anything that maintains transitive data or logging.
Migration testing before live use
The concept of a P2V or V2V migration generally leaves the entire functionality of the system intact. However, for any system being migrated there should be a series of checks performed after the migration before it is placed back in the normal role. Here are some ways to check the newly migrated virtual machines:
- In the newly migrated virtual machine remove all unnecessary hardware from the inventory. Especially if migrating from a physical host, you may have USB interfaces, floppy drives, or even audio adapters that you may not need or be supported on your virtual host.
- Boot the system up on the virtual host without the network adapters connected in the configuration. This is a soft disconnect, and in VMware ESX, that option is performed by de-selecting the 'connect at power-on' option.
- If applicable, stop your critical application if it does not behave well in an offline environment.
- Reboot the virtual machine several times after the migration to make sure all logs are clean and no issues arise after subsequent boots.
- While the network adapter is in the soft disconnect state, ensure that the network configuration is correct for the new location in the virtual environment. Virtual migrations may remove the previous interface from the hardware inventory and the network configuration that came with that interface.
- Be sure also to look at extended network configuration such as DNS server order, DNS suffix, and all other network configuration items that may need to change based on the new location. Also take this time to change or prepare any changes outside of this system including DNS entries if applicable.
After running through that series of tests, reconnect the network adapter to the virtual machine when the guest virtual machine is turned off. In doing this series of checks, you will save precious time the first time you turn the virtual machine on by having all of the minor tweaks corrected before you attempt to go live with the migrated system.
Windows domain controllers need different treatment
Moving a domain controller from a physical box to a virtual instance poses special considerations that in a best practices situation needs to be handled differently. The primary reason that this is an issue revolves around how the machine is placed on the new virtual environment. Many administrators want to minimize the downtime of the domain controller, so you may tend to use a tool that is optimized for use online. The issue is that if the domain controller is running, every moment in time increments internal calculations for the domain. This is mainly because, if the P2V migration tool performs its conversion while the system is running, once the virtual system is brought online it runs the potential of corrupting the Active Directory database locally, with other domain controllers, and the computer accounts.
There are two good ways that I will show in this tip to convert a domain controller. The safest way is to perform a new build on the virtual environment, and bring this system into the domain as a new domain controller. After it is brought into the domain as a new domain controller, ensure the global catalog trait and other roles are transferred over as applicable. Once these are brought online you can demote and remove the first system from the domain.
The other way is just as safe, but requires some downtime. In the situation where you have a VMware host on an older version of ESX, you can perform the clone task on the virtual machine. This clone task will copy it to the new host in a powered off state. The powered off state is critically important because the domain controller would not get out of sync with the rest of the domain in this situation. This method is only recommended when there are additional domain controllers available to function while the first system is being migrated.
Choose the correct migrations strategy
Depending on the parameters you have to migrate the physical machines to virtual machines, you have to decide upon the correct strategy to maintain your uptime requirements, maintain licensing parameters, select a path that will not cause issues downstream. All the while making it a transparent migration for the systems and users connected to the systems at hand. Be sure not to fall into the trap where you simply use a conversion tool like VMware Converter or PlateSpin PowerConvert to migrate physical machines quickly and not consider the implications outlined above to achieve the most successful migration.
Rick Vanover is an MCSA-certified system administrator for Belron US in Columbus, Ohio. Previous roles included software engineering roles with Siemens and Dematic in Grand Rapids, Michigan, working with complex supply chain execution systems. Rick has been working information technology for over 10 years and virtualization technologies for over seven years and has been publishing articles online for over six years.