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:
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.
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?
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.
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
Sorry, I should have been clearer. Removing the unity.dll doesn't fix the converter problems. It makes that particular error go away.
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.
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.
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.
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 !
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.
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...
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.
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:
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!
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
Guys it seems VMware already release a patch in order to correct these issues.
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/