- Backups
- Disaster Recovery
- Physical to Virtual Conversions
- Maintenance
- Monitoring
- Alerting
- Verifying Configurations
- Operating the Environment Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Physical to Virtual Conversions
When a virtualization infrastructure is implemented, the first virtual machine installed is typically going to be brand-new installations of Windows for your vCenter and SQL servers. Many times, a project like this also serves as a good time to clean up and move toward the latest server operating systems. Regardless at some point, you need to begin moving some of the existing physical workloads over and retaining their configurations.
VMware provides a free download for a product that will assist in this migration. VMware vCenter Converter Standalone 5.0 allows the conversion of physical systems as well as systems that are already virtualized. When performing physical to virtual conversions, you should be aware of the following things.
For all systems, you should do the following:
- Prior to conversion
- Perform a survey of the server and its applications.
- Identify server and application owners for approval and verification testing upon completion.
- Identify performance and configuration of CPU/memory/disk versus actual usage.
- Identify destination for virtual machine (host placement and storage placement).
- Identify and record network configurations.
- Identify downtime and schedule for system(s).
- During conversion
- Place virtual machine on host and storage per design.
- Adjust configurations of CPU/memory/disk as appropriate.
- After conversion
- Remove nonpresent devices.
- Remove legacy software.
- Install VMware Tools.
- Reconfigure the network.
- Perform basic testing.
- Verify functionality with server and application owners.
- Fully uncable and remove decommissioned physical servers.
Issues and Troubleshooting
Physical to virtual conversions can fail to start. Typically, we have found this is because of one of the following reasons:
- No Permissions Admin$
- Firewall exists between server to be converted and vCenter
- Incorrect DNS configurations
In some cases, administrators have removed the admin$ share on a server, which is required for the vCenter Converter agent installation when installing remotely. You can install the client locally or re-create the share to resolve these issues.
When a firewall exists, it can cause a failure if certain ports are not reachable. VMware Knowledge Base article 1010056 details the required ports to be allowed through the firewall (see Appendix A for a link).
If DNS configurations are not correct on a source virtual machine, this can also cause failures. Ensure DNS is correct or update DNS so that the system to be converted can reach the vCenter server.
Besides these basic considerations, you should also consider a few special cases:
- Domain controllers
- Windows Server with OEM installations
- SQL, Exchange, and other applications servers
- Linux
- Virtual to virtual conversions (V2V)
Domain Controllers
Active Directory domain controllers have special considerations to take when looking at physical to virtual conversions. Although there are methods to perform a P2V conversion, it is our recommendation you don’t and instead create new virtual servers. Domain controllers are extremely sensitive to hardware changes and a failure in following the P2V process at any step can cause major replication issues that will be visible throughout your infrastructure. Creating new servers allows for a clean and safer migration. The recommended process is as follows. Note this may vary depending on how many Active Directory domain controllers you have, their location, and whether they remain physical or not.
- Create one or more brand-new Windows virtual machines.
- Promote these two domain controllers using dcpromo.
- Ensure replication via the command line using the repadmin tool.
- Transfer FSMO roles.
- Transfer DHCP servers.
- Verify role transfer.
- If the domain controller is also a DNS server, ensure DNS is running on new systems.
- Power down physical domain controller and verify functionality. If no issues exist, power back on and demote existing physical systems using dcpromo (FSMO role will be transferred there also).
- Decommission physical hosts.
- Reconfigure DNS settings for servers/workstations to reflect any new IP addresses.
Windows Server with OEM Installations
Another case for consideration is any physical Windows servers that were originally installed with OEM media. Per Microsoft’s licensing agreement, these licenses are tied to the original physical hardware and as a result the right to continue using the installed operating system does not carry over. Microsoft licensing is outside the scope of this book; however, two things can be drawn from this situation:
- You are not in compliance with your licensing. You need to have or purchase an additional Microsoft server license.
- You are running a version of Windows you are not licensed for. You need to either install a fresh instance of Windows using volume licensed media or perform an in-place upgrade using the volume licensed media.
If you have ignored these recommendations, you will find that once you bring the newly converted virtual machine online, it will require activation. With OEM installation, the key that is required to activate is not necessarily the one that was on the sticker on the box. With that said, you might be able to activate the software installation; however, you need to ensure you are in compliance with Microsoft licensing as soon as possible thereafter.
Although vendor background screens are typically a clear indication that OEM installations are present, you can also check the product ID for OEM to verify. If it is not present, you are fine. You can script this to check for multiple servers in your environments using various product and key software products that reveal this information. Additionally, you can use code like this PowerShell snippet to gather this information. The following code sets $Prod_ID to the ProductID of the machine it is run on:
$Prod_ID=(get-item 'HKLM:\Software\Microsoft\Windows NT CurrentVersion').getvalue('ProductID')
SQL, Exchange, and Other Applications Servers
Although vCenter Converter will make multiple passes through your data, it is important to consider what could be lost in the transition time in between bringing the physical host down and the last time the data was copied. As a result, it is recommended that you stop all application services.
In addition, consider file shares. You may declare in an email that the server will be down this Saturday, but that doesn’t stop someone from changing data. This data could end up being changed at a time of transition and would in effect be lost. Therefore, it is recommended that you unshare any file shares during the conversion process. Additionally, you should remove any temporary files or any data that is no longer needed. This greatly decreases the time involved when converting and optimizes the amount of physical storage being used.
Linux
This chapter has talked a lot about virtualizing Windows servers, but now the focus shifts to Linux servers. Linux servers follow a slightly different process and, as a result, there are some things you should be aware of. For starters, the process for Linux does not deploy an agent, but instead a helper virtual machine is deployed on the destination vSphere host. This helper machine will ultimately become the production virtual machine once it has copied all of the data from the physical Linux machine.
You should consider a few important things:
- You must ensure you have SSH access to the Linux machine when doing an online conversion and you must have root access when doing so.
- Only certain flavors of Linux are supported for online conversions. Presently, these are certain versions of Red Hat, SUSE, and Ubuntu.
- Customization during the conversion process is not supported for Linux guest operating systems.
V2V and Other Methods
Physical machines are not the only machines that may need to be brought into a new infrastructure. For example, you may have existing virtual machines running on storage not accessible to the new environment. You may also have these virtual machines running in a Hyper-V environment. Additionally, you may choose to do an offline conversion by using an imaging product. Regardless of the source, vCenter Converter allows for all of these options when using any of the following supported methods.
The following virtual machine formats are supported for cold conversion:
- Microsoft Hyper-V
- Microsoft Virtual Server
- Microsoft Virtual PC
- Parallels Desktop
- VMware Workstation, GSX Server, Player, Server, Fusion, ESX
The following image formats are supported:
- Symantec Backup Exec System Recovery
- Norton Ghost
- Acronis
- StorageCraft
Additionally, during the conversion process, you can convert any running Windows virtual machine by specifying a powered-on machine as the source.
Offline Boot Disc
When an offline conversion is desired in addition to the mentioned image formats, you can use the VMware vCenter Converter Boot CD. The boot CD is no longer provided as of vCenter Converter 4.3; however, it is still available for download with valid support for a vSphere 4.x Enterprise Edition or greater license. At the time of this writing, there are no current plans to release a vCenter Converter Boot CD for vSphere 5.0; however, version 4.0.1 build 16134 is the latest version and is supported for conversions from a source to a vCenter 5 infrastructure.
The offline boot disc is based on Windows PE and allows the import of network drivers to build a new image if required. The lack of network drivers is the most common reason the offline boot disc does not work.