Networking

Unix and Linux network configuration. Multiple network interfaces. Bridged NICs. High-availability network configurations.

Applications

Reviews of latest Unix and Linux software. Helpful tips for application support admins. Automating application support.

Data

Disk partitioning, filesystems, directories, and files. Volume management, logical volumes, HA filesystems. Backups and disaster recovery.

Monitoring

Distributed server monitoring. Server performance and capacity planning. Monitoring applications, network status and user activity.

Commands & Shells

Cool Unix shell commands and options. Command-line tools and application. Things every Unix sysadmin needs to know.

Home » Featured, Virtualization

VMware vCenter Converter Standalone Notes

Submitted by on October 9, 2013 – 11:28 am 2 Comments

The vCenter Standalone Converter is a handy app you can run on your Windows or Linux PC to to P2V a remote server. As convenient as the Converter is, there are a few gotchas that can frustrate the heck out of you. First things first, download and install the Converter Standalone client software. You will need admin/root rights on your desktop to install and run the Converter correctly.

In the example below, we have Converter Client installed on a Windows PC to help us P2V an RHEL 5 server from a BL460c blade to vCenter.

Set Helper VM Root Password

The helper VM is a shell OS that facilitates data transfer between source and target VMs. You would like to set the root password in the helper VM to the same value as the source server. Open “%ALLUSERSPROFILE%VMwareVMware vCenter Converter Standaloneconverter-worker.xml” and set value “useSourcePasswordInHelperVm” to “true”.

Cleanup Source Physical Server

To ensure a relatively quick and error-free P2V migration, it is a good idea to do some cleaning on the source server. Make sure to delete or move any old logs, archives, backups, etc. You can temporarily offload this data to an NFS share and then copy it back to both the source server and its virtual clone.

Increase RW Timeout Threshold

Ther P2V process may take a long time, depending on the size of the source machine and network performance. The Converter process may fail if it runs into unexpected network delay. The reduce the chance of this happening, it may be a good idea to increase the RW timeout semaphore.

Increase read/write timeout semaphore: %ALLUSERSPROFILE%Application DataVMwareVMware vCenter Converter Standaloneconverter-agent.xml and modify/set writeTimeoutMS and readTimeoutMS to 480000 ms.

Launch Converter as Administrator

Right-click on the Converter Client icon and select “Run as Administrator”. The Converter will not function correctly unless you run it as Administrator.

Direct Root Access to Source Physical Server

On the source physical server, make sure you have direct admin/root login. With Linux/Unix systems, make sure you have direct root SSH enabled. Check /etc/sshd/sshd_config and make sure “PermitRootLogin yes” entry is present and uncommented. If you need to make changes to the config file, make sure to restart the sshd daemon: service sshd restart.

converter_001

 

To verify proper access to the source system, you can click on the “View source details…” link. If everything works as expected, you should see physical server summary information:

converter_002

 

Verify you can login directly as root via SSH. If you don’t know the password, but have sudo access with your personal account, then just change the password to something you can remember. These changes are, obviously, not secure, so make sure to put everything back the way it was after the conversion is done: on both source and target systems.

Superuser Access to the VMWare Infrastructure Server

In order to run a P2V process, you must have the access to the VMWare host needed to create and run VMs. Your personal login may not be enough. You should check with your vCenter admin. A better idea may be to use a service administrator account.

Make Sure You Have Enough Disk Space

It is very important to make sure there is enough space in the datastore to accommodate the new VM. It is not recommended to allow available space in the datastore to drop below 5%. You can use “View source details…” link (see above) to view the disk space requriements of your source physical server. Then select a datastore that has enough space plus at least 5% of the datastore’s total capacity.

Set IP, Gateway and DNS

When the helper VM starts, it need to be able to communicate with the source server. The helper VM can have the same network settings as the future virtual copy of the physical server. The Converter utility will default to DHCP. Since most Unix servers use static network configuration, the DHCP setting is not likely to work.

converter_003

In the Options window for the Conversion task, modify “Helper VM network” settings. Set all values – IP, subnet mask, default gateway, DNS, search domains – to the same values as you would in the resulting VM copy of your physical server.

converter_004

Verify Network VLAN

Click on the “Networks” selection in the Conversion task window. Make sure you selected the correct VLAN for the IP and the subnet mask you specified for the VM

NOTES

VMWare Standalone Converter v 5.0 does does not support RHEL 6.x. For RHEL/CentOS v6.x you would need to install Converter v5.5+. When using older version of the Converter on an unsupported RHEL/CentOS 6.x, you may see the following error at the very end (99%) of the migration process:

converter001

 

The reason for the error is that there is no longer an /etc/modprobe.conf file in RHEL6. There is now instead an /etc/modprobe.d directory. You would need to download Converter version 5.5 or later.

Print Friendly, PDF & Email

2 Comments »

  • johjeff says:

    Thanks. This is helpful. Should I be able to ping or ssh to the Helper VM? My migration seems to get stuck at 1%, so I would like to log into the Helper VM to see if there are any issues. It will not let me login with either root or user via the console.

  • Bill says:

    This blog had the key to my problem, and the solution.
    The Linux helper VMs will default to DHCP, which can be a complete disaster (as DHCP usually is)
    The clue to set the helper VM IPs solved my problem, so a million thanks!

Leave a Reply

%d bloggers like this: