What would happen if your physical server running VMware ESX Server were to fail? If you don't have failover options...
in place, you'd be in trouble. The good news is that you can eliminate this worst-case scenario without buying more hardware. You just need a redundant virtual machine (VM) file server.
In the first part of this series, I discussed setting up a file server VM using iSCSI attached storage in the guest VM. Now, if your server fails, you could attach the iSCSI storage to another physical server, but that might require remapping of drives and more downtime for users. Since the file server is a virtual machine, it would be ideal to be able to start it up on another ESX Server after a short downtime. Since there is no shared storage between the two ESX servers, the only feasible way to maintain availability is to have a copy of the file server guest virtual machine on both ESX Servers. These virtual machines would need to be synced in case any changes occur to the virtual machine. Presumably the only changes would occur after patching since the only virtual drive is the system volume.
You could copy the virtual machine files manually once a month after patch Tuesday. Best practices requires that the virtual machine be shut down before the file copy. This would mean downtime for the users or an early morning for the administrator. The solution used in this article gets by the downtime limitation by using VMware Converter 3.0.1 Enterprise to schedule a "conversion" of the target virtual machine to a new location on another ESX server while the target virtual machine is still running.
VMware Converter 3.0.1 Enterprise allows you to use a tool called p2vtool.exe. This is a command-line interface for VMware Converter 3.0.1. It should be noted that there is only experimental support for p2vtool.exe. However, I have tested the scripted conversion presented in this article several times with no failures. In order to use the p2vtool.exe to convert your existing VM there are a few prerequisites.
- You must have access to an account that has Administrative privileges on the source VM.
- If you want an email message to be sent after the conversion is completed you must use a scripting language such as Powershell or VBscript.
- You must install VMware Converter 3.0.1 with an enterprise license on a Windows machine (in this case Windows XP sp2 is used).
- You must create an xml file that contains the parameters for p2vtool.exe to perform the conversion.
Once VMware Converter 3.0.1 is installed on the Windows XP management computer, it is time to start scripting! The first step is to create the xml file that p2vtool.exe needs to process the conversion request. The sample file used in this scenario is listed below.
--Begin Code-- <?xml version="1.0" encoding="UTF-8" ?> <p2v version="2.1" xmlns="https://www.vmware.com/v2/sysimage/p2v" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://www.vmware.com/v2/sysimage/p2v p2v.xsd" uninstallAgentOnSuccess="0"> <source> <liveSpec> <creds host="source_vm" username="Administrator" password="youradminpassword" /> </liveSpec> </source> <dest> <managedSpec vmName="Test-Migrate"> <!-- username and password may be omitted, in which case you will be interactively prompted for credentials --> <creds host="target_esx_server" username="root" password="yourrootpassword" /> </managedSpec> </dest> <importParams targetProductVersion="PRODUCT_MANAGED" /> <postProcessingParams> <reconfigParams /> </postProcessingParams> </p2v> --End Code--
The parameters in this xml file are explained in the help documentation that comes with VMware Converter 3.0.1 in the p2vtool.exe usage section. P2vtool.exe usage is listed near the end of the help file in an appendix. The reason that the source VM is treated as a physical machine is to allow the VM to keep running while the conversion is taking place. A VM to VM conversion can only happen if the source VM is powered off during the conversion process. For demonstration purposes all of the script files and xml file were placed in C:\p2v.
Since more administrators are discovering Powershell there is both a Powershell and VBscript script listed in this article. The Powershell script requires a couple of files. You need the following:
- The p2v.ps1 Powershell script file.
- A regular p2v.cmd file to call the p2v.ps1 file so that the task can be scheduled appropriately.
The reason for the p2v.cmd file is that "ps1" (Powershell script) files do not have a file association in Windows XP by default. However, you can invoke the execution of a "ps1" file using the regular "cmd" command-line. You could add the file association manually in the registry. For simplicity the "p2v.cmd" file is used instead. The p2v.cmd file is listed below.
--Begin Code-- powershell -command "& 'c:\p2v\p2v.ps1' " --End Code--
The p2v.ps1 file is available for download here.
There is one more prerequisite that may need to be done in order for the p2v.ps1 file to run. By default, Powershell is set so that only commands that are typed into the Powershell prompt will be interpreted. This means that Powershell will not execute scripts. To confirm this, type "Get-ExecutionPolicy" at the Powershell prompt. By default the policy is set to "Restricted", so only typed commands are interpreted. In order for the p2v.ps1 file to run, the execution policy must be set to at least "Remote Signed". This means that Powershell scripts created locally will run, but downloaded scripts will not run. To set the execution policy in Powershell type "Set-ExecutionPolicy
If you prefer to use a VBscript, I have created the p2v.vbs version of the conversion as well. The p2v.vbs file is available for download here.
The p2v.vbs script can be scheduled to run at your desired interval. Please note that the p2v.vbs script is a little more processor intensive due to the fact that it is monitoring the "p2vtool.exe" process to determine the finish time of the conversion.
After the process is complete, both the p2v.ps1 and the p2v.vbs scripts will email the admin listed in the script with additional information. This is necessary because there is some manual cleanup required after the conversion takes place. First, after the second scheduled task, there will be two VMs with the same name. One of the VMs needs to be deleted. Second, since the source VM was converted as if it was a physical machine, some extra devices need to be removed from the VM settings and it needs to be added to the appropriate vSwitch. The image of the VI client and the steps necessary to clean up the newly converted VM are listed below.
Note the extra hardware listed in the image below.
Remove the extra hardware as necessary and add a new Network Adapter device that is tied to the appropriate vSwitch. First, select the Ethernet Adapter device and click "next."
Next, choose the appropriate named network and ensure that the "Connect at power on" box is checked. Click "next."
Review the settings on the final screen to ensure that they are correct. Click "Finish."
Congratulations, you have just set up a redundant VM file server. If the main ESX server fails, then you can just boot the file server VM on the other ESX server. The recovery process is manual if it is needed. However, you do not have the extra expense of a VMotion-capable infrastructure. If your user or customer SLA tolerates a manual fail-over process, then this is one way to accomplish it without breaking the bank.
About the author: Harley Stagner has a wide range of knowledge in many areas of the IT field, including network design and administration, scripting and troubleshooting. Of particular interest to Harley is virtualization technology. He was the technical editor for Chris Wolf and Erick M. Halter's book Virtualization: From Desktop to the Enterprise and currently writes his own blog at www.harleystagner.com.