Vmrun fails with message "Error: The specified service provider was not found". E.g. # vmrun list Error: The specified service provider was not found Vmrun works OK if executed in the /opt/vmware/workstation/lib/vmware-vix directory. E.g. # (cd /opt/vmware/workstation/lib/vmware-vix; vmrun list) Total running VMs: 0 This appears to be a problem new to 6.5. I have been running vmrun without any problems with 6.0.X versions. emerge --info data: Portage 2.1.4.5 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r7 i686) ================================================================= System uname: 2.6.25-gentoo-r7 i686 Intel(R) Pentium(R) M processor 1.70GHz Timestamp of tree: Fri, 14 Nov 2008 04:45:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.5.2-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=pentium4 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://server.hpl.hp.com/gentoo http://gentoo.blueyonder.co.uk http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://server.hpl.hp.com/gentoo-portage" USE="X acpi alsa berkdb cairo cdr cli cracklib crypt cups dri dvd dvdr dvdread eds emboss encode evo fam firefox fortran gdbm gif gpm gstreamer hal iconv isdnlog jpeg mad midi mikmod mmx mp3 mpeg mudflap ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcre pdf perl png pppd python qt3support quicktime readline reflection session spell spl sse ssl svg tcpd tiff truetype unicode usb vorbis win32codecs x86 xml xorg xv zlib" ALSA_CARDS="ali5451" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev vesa radeon vga" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Hiya Anthony, Can you please check whether you have an entry in /etc/env.d/ called 90vmware-workstation? That will set up the path to point to vmware's opt/vmware/workstation/bin directory, and might affect programs that only work when run in a particular directory. If you don't have one, you can either re-install vmware-workstation-6.5 (it's been added to the ebuild a week ago or so), or you can simply copy /usr/portage/app-emulation/vmware-workstation/files/90vmware-workstation to /etc/env.d/. Don't forget to run env-update (and . /etc/profile if you're intending to run it in the terminal you're using).
Thanks Mike for the suggestion. I do have a 90vmware-workstation in /etc/env.d. My vmware-workstation install is fresh from the latest portage tree. No problems with this by the way that you don't already know about. Vmware itself works fine. This is quite an upgrade from 6.0.5! My current PATH is: PATH=/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.2:/opt/vmware/workstation/bin Hunting around at VMWare found a PDF that details vmrun, and this document suggests adding /usr/lib/vmware-vix/lib into the ld.so path. I was briefly encouraged by this: maybe vmrun dynamically loads libraries? So I created a 91vmware-workstation file with LDPATH="/opt/vmware/workstation/lib/vmware-vix". Running env-update complained that libxml2.so.2 was not a symbolic link. So I made it one. But no joy -- vmrun still gave the same error. I don't have a /usr/lib/vmware-vix/lib on my system, so it's possible that I'm on the right track, but with the wrong directory? I guessed at /opt/vmware/workstation/lib/vmware-vix. My 90vmware-workstation has no LDPATH line, just: PATH=/opt/vmware/workstation/bin ROOTPATH=/opt/vmware/workstation/bin MANPATH=/opt/vmware/workstation/man There may be a clue about what's different about vmrun in 6.5 in the following vmware posting: http://communities.vmware.com/message/1071415#1071415 Toward the end, 'mattrich' talks about libraries: "VMrun is built on top of the VIX API. Previously, it was statically linked with the VIX library, but now it uses the DLLs installed by VIX. You will need at least the libraries in C:\Program Files\VMware\VMware VIX\Workstation-6.5.0\32-bit and probably the entire C:\Program Files\VMware\VMware VIX\ to keep things simple." Although this refers to the Windows build, the same re-organisation may have been applied to the Linux build? Any help much appreciated.
I've now seen this problem on three systems that I maintain, and one system maintained by a colleague. These systems are similar, but have different application profiles and update histories. The last upgrade I did from 6.0.5, I actually removed /etc/vwware and /opt/vmware, so that the 6.5 was essentially a fresh install.
Progress! Although not yet a fix. Every time I run vmrun, a new log file is created in /tmp/vmware-<user>. Here's a sample: Nov 18 21:06:33.878: app| Log for VixWrapper pid=21977 version=1 build=build-118166 option=Release Nov 18 21:06:33.879: app| Host codepage=UTF-8 encoding=UTF-8 Nov 18 21:06:33.879: app| vixWrapper config file ./vixwrapper-config.txt not found Nov 18 21:06:33.879: app| Failed to load wrapper configuration file Nov 18 21:06:33.879: app| config points to non-existent implementation library './ws_server_esx-4/32bit/libvix.so' Nov 18 21:06:33.879: app| config points to non-existent implementation library './ws_server_esx-4/32bit/libvix.so' Nov 18 21:06:33.879: app| config points to non-existent implementation library './ws_server_esx-4/32bit/libvix.so' Nov 18 21:06:33.879: app| config points to non-existent implementation library './ws_server_esx-4/32bit/libvix.so' Nov 18 21:06:33.879: app| config points to non-existent implementation library './ws-5/32bit/libvix.so' Nov 18 21:06:33.879: app| config points to non-existent implementation library './ws-3/32bit/libvix.so' Nov 18 21:06:33.879: app| config points to non-existent implementation library './ws-3/32bit/libvix.so' Nov 18 21:06:33.879: app| config points to non-existent implementation library './ws-2/32bit/libvix.so' Nov 18 21:06:33.879: app| config points to non-existent implementation library './server-1/32bit/libvix.so' Nov 18 21:06:33.879: app| passed in VIX_SERVICEPROVIDER_DEFAULT, computed hostType as 3 Nov 18 21:06:33.879: app| Workstation installed version is 6.5.0 Nov 18 21:06:33.879: app| No implementation found for service provider 3, apiVersion -1 installedVersion 6.5.0 Nov 18 21:06:33.879: app| No Vix library found for provider 1 revision -1 Nov 18 21:06:33.879: app| No implementation libraries loaded, cannot call 'Vix_GetErrorText' So, the error is not being able to read vixwrapper-config.txt. This is fixed by running in the vmware-vix directory. The lines about config suggest there is a way to configure vmrun? I've now got the same error on a 4th vmware 6.5 installation, making 5 systems in all. I must be doing something very consistently wrong!
Success! In /etc/vmware/components/vmware-vix, file vmware-vix.py appears to handle the installation and setup of the VIX component of vmware. The lines DEST = LIBDIR/'vmware-vix' ... def PostInstall(self, old, new, upgrade): run(conf, '-s', 'vix.libdir', DEST) suggest that a line like vix.libdir = "/opt/vmware/workstation/lib/vmware-vix" should be added to the main /etc/vmware/config file. My config file has no such line. Adding this line to /etc/vmware/config fixes the problem with vmrun, which then operates as it should irrespective of the current directory. The problem appears to be why the PostInstall section of vmware-vix.py is either not running, or is failing.
Ok, I've identified this as an issue with the vmware-config.sh helper, so that when libdir was set in the config, vix.libdir was deleted. This has now been fixed in the tree, but without a revision bump (since there's a relatively simple workaround). Please feel free to reopen this bug if new installations don't solve the problem... 5:)
Hi Mike, Many thanks. I can confirm that this bug is fixed in 6.5.1. Anthony
(In reply to comment #6) > Ok, I've identified this as an issue with the vmware-config.sh helper, so that > when libdir was set in the config, vix.libdir was deleted. This has now been > fixed in the tree, but without a revision bump (since there's a relatively > simple workaround). > > Please feel free to reopen this bug if new installations don't solve the > problem... 5:) > Mike, I know the bug is closed, but I am seeing a similar problem on VMWare Server 2.0.0.122956 ... should I open a separate bug report? ( unfortunately, `find /opt/vmware -name '*vix*'` returns no results )
Hiya John, yeah, if you could please, since it uses a completely different installer...
