I’ve run into a bug with VirtualBox and at least Windows XP where trying to reboot or shutdown the VM causes the shutdown process to hang at the screen displaying: Windows is shutting down. This problem has to do with mouse pointer integration.
To fix the problem:
Start the VM
Machine > Disable Mouse Integration
Machine > Close > Save the machine state
Start the VM
At this point shutting down or restarting the VM should not hang. Thanks to this post for pointing me in the right direction.
On one server, the key didn’t exist. I ignored disabling autoplay on that server and the export worked out anyway.
Remove Any Virtualization Software and Verify Adequate Space
These are obvious, uninstall VMWare, VirtualPC, VirtualBox, etc. Find a spot to drop the OVF or VHD package.
Remove Any Network Interface Team
We weren’t doing anything fancy with our interfaces, so I ignored this. I figure if you are using a Network Interface Team, you would know it. Feel free to shoot me a comment on this if you have any insight.
I currently have the opportunity to use the XenConvert tool to move some physical servers to our customer’s XenServer environment. I have finished moving the first server, but I had to take a couple passes before finding a successful p2v plan.
OVA to XenServer
My first plan was to export an OVA file, transfer it to an existing VM on XenServer. Then use XenCenter to import the .ova file. Using the .ova approach is done by selecting Open Virtualization Format (OVF) Package and ticking the Create Open Virtual Appliance checkbox in the XenConvert workload screen.
Well the XenConvert to .ova finished successfully. But importing the .ova file using XenCenter failed. It kept failing on the EULA which wasn’t defined, nor necessary to define when exporting.
This initial error using XenCenter led me to try importing with XenConvert. It was a good idea, but reality didn’t play out, and I received an error again.
VHD to XenServer
My second plan was to just export the VHD. Again using XenConvert, I select the To: XenServer Virtual Hard Disk (VHD) in the initial workload screen. Again this conversion to a .vhd file completed successfully. After transferring to the existing VM on XenServer, I immediately went to XenConvert instead of XenCenter.
In XenConvert on the initial workload screen, I selected From: Microsoft Virtual Hard Disk (VHD) and To: XenServer. Selected the .vhd file from the file system. And filled in the Hostname, User name, Password and Workspace values in the XenServer connection parameters screen:
OVF to XenServer
My third plan was to export an OVF package.
This was never executed because the VHD approach worked. I will try this approach for the second server I am moving, so watch for updates on this post.
I have successfully imported the 3rd server using an OVF and XenConvert. I found that if the OVF fails, then the VHD method will likely fail as well. It boils down to having enough disk space to do the convert. I didn’t see much advantage to using the OVF. The OVF did allocate more RAM up front, but only provided 1 VCPU. I still had to manually configure dynamic RAM and allocate more VCPU after installing Xen Tools.
Disk space, disk space, disk space. XenServer needs lots of disk in order to restore. For example, restoring a 64gb VHD required 300gb of available disk.
Changing the default Storage Repository is possible with some xe commands, see this.
Using OVF only allocates the correct amount of maximum RAM after the convert. User still has to manually configure dynamic memory and specify the correct number of VCPUs.