Thursday, March 28, 2013

VMware Converter configuration Tips

If you just install VMware Converter and start running it with it’s default configuration, I’m sure you will be successfully.
But, there are a few features, when enabled, make your life easier.

I, personally, like to enable those features just after the installation. It will guarantee that the functionality is there when I need it.

The configuration file that controls Converter features is converter-worker.xml (in some older versions of Converter it’s converter-agent.xml).

You can find it on:
C:\ProgramData\VMware\VMware vCenter Converter Standalone (For Windows 2008)
or  %ALLUSERSPROFILE%\VMware\VMware vCenter Converter Standalone (older systems)

Take a backup of the file before you change it.

Let’s start with a tip about performance:
Starting with Converter 5.0, now it encrypts the traffic with SSL to provide more secure, but it also decreases the performance. If you run your conversions tasks within your private network, generally, you should not be worried about it, so you can disable the encryption and boost the conversion performance.

- open the file and look for the string (nfc) and under it
- change it from (useSsl)false(/useSsl) to (useSsl)true(/useSsl)
- restart Converter service to the change take effect.

more details: KB2020517

This tip is related with privileges on Linux
Some times when you are converting a Linux server, you might want to logging in to the helper virtual machine, well by default Converter prevents that.
To enable it you need:

- open the file
- change the flag from (useSourcePasswordInHelperVm)false(useSourcePasswordInHelperVm) to
- restar Converter service to the change take effect.

 more details: KB1008209

The last one is about using a user other than root to convert a Linux Server.
It’s not unusual when you have to use another user, it might be because of some security restrictions, limited access to root passwords, etc.. 
To enable the use of others users

- open the file
- change the flag from (useSudo)false(useSudo) to (useSudo)true(useSudo)
- restar Converter service to the change take effect.

more details: KB1008164

Don’t forget to adjust /etc/sudoers to allows you to run every command without asking password, the configuration would looks like this:


If you still getting an error like: "Unable to query the live Linux source machine. Make sure that you can run sudo without entering a password when logged in to the source machine over SSH as ‘username’.

Check again /etc/sudoers and make sure the entry bellow is not present or is commented.

Defaults requiretty

Basically it says to run commands with elevated privileges through SUDO, you must be logged in locally, not through a SSH session or remotely somehow, that’s why Converter fails.

Well, that are my best practices, there are a bunch of configurations you can tweak on the Converter configuration file, just adjust it accordingly with your needs.

In case of  if anything goes wrong, just restore the configuration file backup you took before changing anything, I’m pretty sure you did , right ;)

Thursday, March 7, 2013

Update Manager Service not starting on a fresh install

This week I ran into a fresh install of vSphere and Update Manager 5.1.

Everything went fine with SSO, Inventory Services and vCenter, but Update Manager had a different story, despite the fact the installation went fine too, no errors and the tables were created on the database as it would be, the service was not starting up.

On the attempt to start Update Manager I got the following error:

"Windows Could not start the VMware Update Manager service on local computer. Error 1067: the process terminated unexpectedly"

Checking Update Managers’ log there were several messages like: Failed to get the module name for process….

Well making a long story short, after some troubleshooting I realize the problem was my ODBC connection with the database.

As you probably know, you cannot use the SQL client which comes by default with Windows, instead you need to install the SQL Native Client, which is provided by SQL Server Feature Pack.

And as you could imagine there are several versions of them, depending on the SQL server version, release, service pack…

On this implementation, I’ve been using SQL Native Client 11 for vCenter connection with no problem at all, but apparently Update Manager does not like this version.

After I installed SQL Native Client 10 and changed the Update Manager ODBC connection to use this client version everything went as expected and the service started just fine.

Since my vCenter was working fine I saw no reason to remove the Native Client version 11.

Now my server has been running both versions concurrently with no problem.
SQL Native Client 11 for vCenter ODBC connection.
SQL Native Client 10 for Update Manager ODBC connection.

See you next

Who am I

My photo
I’m an IT specialist with over 15 years of experience, working from IT infrastructure to management products, troubleshooting and project management skills from medium to large environments. Nowadays I'm working for VMware as a Consulting Architect, helping customers to embrace the Cloud Era and make them successfully on their journey. Despite the fact I'm a VMware employee these postings reflect my own opinion and do not represents VMware's position, strategies or opinions. Reach me at @dumeirell

Most Viewed Posts

Blog Archive