You are here

vmware

Slow mouse pointer acceleration in Linux under VMWare

Until becoming a Mac user, I used Mandriva. It was Mandriva 2009 and KDE4 that pushed me away.

Mandriva 2010 is actually much better. KDE4 is a little better now, while in 2009 it was unusable. KDE3 is still much better.

I installed Mandriva 2010.0 in VMWare Fusion 3 on my iMac. Everything is working really well; the speed is as good as native really. The only problem has been that in the default installation the mouse speed changes between the Mac desktop and Linux one. Under Linux, the pointer would slow down; as the pointer leaves the VMWare window is snaps back to normal Mac speed.

The solution is to install the xorg mouse driver; yes, you need VMWare-Tools but this does not include direct support in xorg.

On Mandriva you need to:

sudo urpmi x11-driver-input-vmmouse

After installing, mouse speed remains the same across Mac and Linux.

VMWare can't be run purely from the command line

VMControl error -16: Virtual machine requires user input to continue

If you see that when manipulating a VMWare machine, you'll need to connect the management console and click on the window VMWare will show you.

vmware-server-console or whatever you use.

I can't see that even a hard reset can get rid of this without starting the graphical interface. If there is a way to get a machine back from the command line only, I'd be thankful to hear of it.

vmware-cmd <machine> reset not working?

If your VMWare client crashes and becomes none responsive regularly (e.g. you're running a Windows client), it's a good idea to have a script monitoring it and calling reset when it dies.

The first obstacle I encountered was when "vmware-cmd /mymachine.vmx reset" was run and I got the following:

VMControl error -8: Invalid operation for virtual machine's current state: Make sure the VMware Server Tools are running

This obscure error was because I didn't read the documentation. 'Reset' takes an argument, see [1]. By default, it will try to do a 'soft' reboot - i.e. it will only talk to vmware-tools inside the machine and try a clean reboot. If the machine is dead, that's not going to happen. The answer is to use 'hard' or 'trysoft'. I prefer trysoft. If a response is not found from vmware-tools, it tells VMWare to do a "hard" reset of the client.

Here's the bit of perl I'm using to monitor my VMWare machine:

#!/usr/bin/perl -w

use strict;
use Net::Ping;

# This is the host we check is up.
my $host = "192.168.16.54";

# Explict binding, not normally needed.
#my $local_addr = "192.168.16.23";

my $p = Net::Ping->new();
#$p->bind($local_addr);
if( !$p->ping($host) )
{
print "MachineX is down, forcing VMWare client reset...\n";
`/opt/vmware/server/bin/vmware-cmd "/var/lib/vmware/Virtual Machines/client directory/client configuration.vmx" reset trysoft`
}

[1] http://www.vmware.com/support/esx2/doc/vmware-cmd.html#1012418

VMWare Server error 0xed00

Dec 30 13:08:21 hostname vmware-authd[13919]: The "/opt/vmware/server/lib/bin/vmware-vmx" process did not start properly. Exit 0xed00

I was getting the above on one of my old soon-to-be-replaced servers after it had crashed and been rebooted. I put VMWare server on it recently to run an SBS2003 image, as it runs perfectly on that machine's Duron and horribly on the Pentium3 of my normal VMWare box. VMWare + Pentium3 does not mix, as I have been slow to recognise.

Any, to cut the story short:
VMWare must see your ~/.vmware directory. Even if you are using the remote console, the machine running the VM needs to see the .vmware dir in the home directory of the user you are running the VM as.

I have a single /home shared over my network, and this machine - for reasons of very basic security - has never auto-mounted /home. When I set up VMWare, /home was there. After the reboot, /home wasn't.

If the error message had said that to start with, I might have got back to work an hour ago.

Keywords: 
Subscribe to RSS - vmware