Dizzy34
Contributor
Contributor

ESX5.1 immature: Converter and VMwareTools problems

Jump to solution

I probably made a huge mistake in upgrading an ESX5.0 host to 5.1 as I encounter several problems:

- Standalone converter 5.0 crashes as soon as the ESX5.1 host is selected as target (it was running fine w/ 5.0). KB2033315 confirms this problem for wich VMware doesn't provide any solution yet

- my VMs' Windows Application Eventviewer fills with vmwaretools errors such as the following:

Log Name:      Application
Source:        VMware Tools
Date:          23.09.2012 09:13:16
Event ID:      1000
Task Category: None
Level:         Warning
Keywords:      Classic
Description: [ warning] [vmusr:vmtoolsd] Failed registration of app type 2 (Signals) from plugin unity.

Hopefully I won't get any more severe problems. Anyway, if you have the choice, keep away from this version, at least build 799733, until such problems are resolved. Kind of disappointing from VMware, don't you think so ?

:smileyangry:

1 Solution

Accepted Solutions
RobertoR
Contributor
Contributor

Hi all, here there's a link that can resolve the problem http://kb.vmware.com/kb/2036350 

It seems that the upgrade didn't create the file tools.conf

You can create it like this:

[logging]
log = true
   
# Enable tools service logging to vmware.log
vmsvc.level = debug
vmsvc.handler = vmx
 
# Enable new "vmusr" service logging to vmware.log
vmusr.level = error
vmusr.handler = vmx

# Enable "Volume Shadow Copy" service logging to vmware.log
vmvss.level = debug
vmvss.handler = vmx
 
 
Save it as tools.conf in the appropriate folder for the guest OS.
 
  Windows XP and Windows Server 2000/2003  
  C:\Documents and Settings\All Users\Application Data\VMware\VMware Tools\tools.conf
 
  Windows Vista, Windows 7, and Windows Server 2008  
  C:\ProgramData\VMware\VMware Tools\tools.conf
 
  Linux, Solaris, and FreeBSD  
  /etc/vmware-tools/tools.conf
 
  After saving and closing, restart the Tools service.

View solution in original post

15 Replies
massador
Contributor
Contributor

I am experiencing similar problems. Upgraded from esxi 4.1 to 5.1 - seemingly no issues

Wanted to use stand alone converter 4.3 to work with offline machines on host - connected fine, but unable to use due to version  issue it seems

Upgraded to stand alone converter 5.0 and now when I select the exsi selection and then add in the IP address of my host with the root user and pasword, the application then hangs and crashes - unable to connect at all to the host

If I select physical online machine connection, then i can connect to the specified machine

I need to get in to convert some offline machines on the host and am unable to. I have checked the varius articles re the SSH and ports and all these check out fine and working according to those articles.

Any ideas?

0 Kudos
KlausK
Contributor
Contributor

There "unity" issue can be solved by deleting/renaming the unity.dll file from the plugins\vmusr subfolder. Why a VMware Workstation feature gets included in the toolset for ESXi is interesting to say the least.

Much more severe (at least to me) is the issue of the guest daemon not being able to handle two users logged in at the same time. When that happens, performance drops and the following error is reported once every second:

[ warning] [vmusr:vmusr] Error in the RPC receive loop: RpcIn: Unable to send.

So it seems their QA never tested the tools in a multi-user environment. I can't see how they could have missed that otherwise. I opened a support ticket on that problem.

0 Kudos
massador
Contributor
Contributor

Hi KlausK. I have searched my client system for the unity.dll file and it is not to be found.

I did locate it on a virtual server on the host and deleted the file

Running the converter program from both the laptop client and the virtual server still fail

I did go deeper this time to see if the from physical machine would go - it accepts my source physical machine, but when I tell it to go to the host machine with the root user and password, then that section also hangs - same error message as shown below. The client laptop is running Windows 7 and the virtiual server is running Windows 2008 - i do not get this error message from the laptop machine though, just have to close the hung application each time

See the error message from the server machine:

Appreciate any help here

Problem signature:

Problem Event Name: APPCRASH

Application Name: converter.exe

Application Version: 8.0.0.11006

Application Timestamp: 4e4f2a69

Fault Module Name: converter-logic.dll

Fault Module Version: 8.0.0.11006

Fault Module Timestamp: 4e4f270d

Exception Code: c0000005

Exception Offset: 000e818b

OS Version: 6.0.6002.2.2.0.305.9

Locale ID: 7177

Additional Information 1: d5e2

Additional Information 2: 925a0d2073becc4862a64ee189d250fb

Additional Information 3: 651e

Additional Information 4: 68885a75e655c19159ca130f9bb8a15a

0 Kudos
KlausK
Contributor
Contributor

Sorry, I should have been clearer. Removing the unity.dll doesn't fix the converter problems. It makes that particular error go away.

0 Kudos
virtual_dave1
Contributor
Contributor

I too am getting [ warning] [vmusr:vmusr] Error in the RPC receive loop: RpcIn: Unable to send.

On our XenApp VMs no less - useful!!!

Opening a ticket now.

0 Kudos
Kiolul
Contributor
Contributor

Hi KlausK,

I encounter the same problem as you with the new vmtools 9.0.0

The message [ warning] [vmusr:vmusr] Error in the RPC receive loop: RpcIn: Unable to send. is reported every second too.

Could you tell me if you have received an answer from VMware tech or open a new thread about this problem?

Thx.

0 Kudos
virtual_dave1
Contributor
Contributor

Awesome - i am also getting

[ warning] [vmusr:vmtoolsd] Failed registration of app type 2 (Signals) from plugin unity.

on other VMs.  First one i found was a WSUS VM if that is in any way relevant.

I have SR open re: RPC Loop error, i have provided logs etc, will update thread if i hear anything of significance.

My VMTools version is 9.0.0 build 782409.

0 Kudos
Dizzy34
Contributor
Contributor

Filed an SR for the converter proble. VMware confirmed the problem, but no solution in sight so far.

Found a workaround for the converter problem:

- uninstall converter5.0

- install converter4.3

- when converting a machine, make sur to select hardware version 7 or 8. Choosing the default 9 will make the converter crash as well.

Hope that helps !

But here clearly, VMware messed up with QA/QC !

0 Kudos
massador
Contributor
Contributor

Hi. Many thanks, I agree with you on the going back to Converter 4.3 has worked and the option to select  7 or 8 - found this to work on the vm i did a test on.

Is bad news that stuff gets released before major issues detected, even worse when there is no idea of fix or even notice on site to say known issues, etc. Perfect world I suppose. Thanks again.

0 Kudos
RobertoR
Contributor
Contributor

Hi All.

ESXI 5.1

I agree with Klausk. I have the same problem

[ warning] [vmusr:vmusr] Error in the RPC receive loop: RpcIn: Unable to send.

with a lot of VMs (Windows 2008R2). For me it's more more severe.. My users log into the server via RDP and I found more then one message every second.. Can you imagine... a lot of user logged into different VMs into the same ESX5.1 and a lot of messages written in the same second...

I have opened an SR on 19/09/2012 Support asked me for VM logs and vmtools log also. I could give them VM logs but couldn't give them vmtools log becouse no TOOLS.CONF file found searching on C:\*.* enabling also the  hidden files option...

0 Kudos
RobertoR
Contributor
Contributor

Hi all, here there's a link that can resolve the problem http://kb.vmware.com/kb/2036350 

It seems that the upgrade didn't create the file tools.conf

You can create it like this:

[logging]
log = true
   
# Enable tools service logging to vmware.log
vmsvc.level = debug
vmsvc.handler = vmx
 
# Enable new "vmusr" service logging to vmware.log
vmusr.level = error
vmusr.handler = vmx

# Enable "Volume Shadow Copy" service logging to vmware.log
vmvss.level = debug
vmvss.handler = vmx
 
 
Save it as tools.conf in the appropriate folder for the guest OS.
 
  Windows XP and Windows Server 2000/2003  
  C:\Documents and Settings\All Users\Application Data\VMware\VMware Tools\tools.conf
 
  Windows Vista, Windows 7, and Windows Server 2008  
  C:\ProgramData\VMware\VMware Tools\tools.conf
 
  Linux, Solaris, and FreeBSD  
  /etc/vmware-tools/tools.conf
 
  After saving and closing, restart the Tools service.

Dizzy34
Contributor
Contributor

Hi folks,

Yet another problem came up: Converter 5.0 does not work w/ ESX 5.1, but Converter v4.3 allows P2V provided you stick w/ HW-version 8 at max. However, ther's no way to make a V2V-conversion, and the support's suggestion to install Converter 4.3 on the vm to be converted doesn't work either...

But I finally got out of the mess by downgrading to ESX 5.0 !  The procedure and conditions are described in KB1033604 and work only if no updates nor patches have been installed after the upgrade which was the case for me. Note, however, that VMwareTools from the previous version are not recovered and as a result, they can't be installed on a new VM from viclient interface (rightclick / install): you get the message about missing files and the recommendation to reinstall ESX ! This might work, but I prefered to download the Tools-ISO images and to install them onto new VMs from there.

I hope this helps at least some of you.

In the meantime, for those didn't upgrade, keep away from ESX5.1-799733 at least until the next release. Converter 5.1 is announced for December, so be patient.

Have a good day :smileycool:

0 Kudos
ethandlowry
Enthusiast
Enthusiast

Thank you Roberto for posting the actual solution to this and not just a workaround like the VMware article states. I created the file as you directed on the 3 VM's that I recently upgraded to 5.1 and the error immediately stopped. There was no need to restart the VMware Tools service. As soon as the file was there it stopped the errors.

Thanks!

0 Kudos
Gwi
Contributor
Contributor

RobertoR's fix totaly worked.

But in my case it wasn't an upgrade and I didn't need to restart the service.

Thanks,

- Gwi

0 Kudos
FranciscoBatist
Contributor
Contributor

Guys it seems VMware already release a patch in order to correct these issues.

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&e...

Credit to who deserves it... i fornd the reference to the VMware KB on Russ Burden Blog:

http://russburden.wordpress.com/2012/12/14/vmware-5-1-tools-rpc-receive-loop/

0 Kudos