This is an old thread that is obsolete since approx June 2015 Open-VM-Tools was published on Github and fully implemented as the sole option replacing commercial (proprietary) Tools published by VMware.
Although this project is actively maintained, TW is a rolling release which often implements changes before anyone else which will <regularly> break the patches in this project. Report any problems and wait a week or two. Or, modify whatever scripts you use to install a specific version of patched tools. But, YMMV. Even other stable openSUSE will break from time to time, but expect a particularly difficult life using TW. I <do not> recommend running TW as any kind of virtualization Host unless you’re willing to deal with this kind of issue regularly.
A <TW-only> requirement you have to manually install is the legacy network tools package
zypper in net-tools-deprecated
After installing the above special dependency, you can modify and run the main script as described in “Quickest Start”
With Tumbleweed (and all recent versions of openSUSE/SLES) the open-vm-tools that is included with the product is the one we recommend using (no other compiling/work/etc required). On distributions with kernel versions higher than 4.0, the old vmhgfs kernel module has been replaced with a FUSE based vmhgfs implementation. In order to access shared folders with this new client, the only command that is required is:
guest@linux-8z47:~> vmhgfs-fuse .host:/downloads mnt/
guest@linux-8z47:~> ls -l mnt/
total 1
drwxr-xr-x 1 guest users 324 Jun 9 09:37 downloads
If you have multiple shared folders, you can mount them all though:
guest@linux-8z47:~> vmhgfs-fuse .host: mnt/
guest@linux-8z47:~> ls -l mnt/
total 3
drwxr-xr-x 1 guest users 324 Jun 9 09:10 downloads
drwxr-xr-x 1 guest users 324 Jun 9 09:38 temp
drwxr-xr-x 1 guest users 324 Jun 9 10:37 testing
To see what shared folders are available on your system, you can run:
guest@linux-8z47:~> vmware-hgfsclient
downloads
I just tested the above commands on Tumbleweed-20160307, and they work fine out of the box. Shared folders are not auto-mounted (we’re looking into adding this), but the above commands should help. Keep in mind that you must have the appropriate rights to the directory you are using for the mount point. I should also note that Drag and drop, copy and paste, etc. all work correctly as well. In Tumbleweed-20160605, there is a problem with Drag and Drop due to some gnome library changes. This has been resolved and should be fixed in the next drop of Tumbleweed.
Thanks for your post which has significant importance.
I’ll check out this new implementation as I have time.
Big question for me…
VMware tools is much more than just the shared file system which has almost universally been implemented using the Plan 9 protocol, this new FUSE approach sounds like a significant departure.
VMware Tools also provides extended support for mouse events, a shared clipboard, enhanced display, extended support for a variety of I/O devices and a virtual keyboard off the top of my head.
If you are suggesting replacing VMware Tools, is this package whose name suggests mainly support for shared folders a replacement for all of VMware Tools functionality?
Also, have you tested video on all versions?
In particular, for about 3 mths now, video display auto-fit, aka auto resize when the window size changes like going to full screen has been broken for 13.2. LEAP and TW work fine.
Is there an advantage to this FUSE approach, in my mind it suggests a possibly simpler implementation that does not require compiling kernel modules that fit the running kernel. Are there any other differences? There have been opinions in the long ago past that FUSE does not perform as well as native kernel file systems, but maybe that could have only been because of implementation?
If this new package for shared folders lacks other VMware Tools functionality, is it instead intended to be installed side by side with VMware tools?
As for auto-mounting, if you haven’t already discovered VMware somewhat uniquely uses a systemd mount service (was easier to see in earlier systemd. Nowadays, systemd mounting is so varied it’s harder to trace), so likely can be a very simple configuration modification.
open-vm-tools are the opensource version of VMware’s proprietary VMware Tools. However, this does not mean they offer the same functionality. For an overview of open-vm-tools, check out the official github repo, or their knowledgebase.
VMware officially recommends open-vm-tools for distributions which provide these tools. This may be simply because it’s easier for the user (they are just included in the distro), but I believe it is also because they offer the core features used most commonly. These tools offer a shared clipboard, (at least some) mouse events, and an enhanced display - although I’m not sure if they address every feature you might be using. (I’ve been unable to find a direct open-vm-tools to VMware Tools feature comparison chart. If you can find one, or can point out specific features missing in open-vm-tools, I’d love to hear about them.)
Also, have you tested video on all versions?
In particular, for about 3 mths now, video display auto-fit, aka auto resize when the window size changes like going to full screen has been broken for 13.2. LEAP and TW work fine.
I’ve tested quite a few versions, but definitely not all of them. Also, I’ve noticed differences in behavior based on the environment the VM is actually running in. For example, dynamic window resize works well in Fusion, but on an older Linux VMware Workstation it does not work. Shared Folders are not provided or supported in ESXi. etc… I am aware of a problem with drag and drop for the past few months. VMware just updated their github project with a new -gtk3 branch of this code which seems to solve all the problems I’m aware of at the moment. We should be able to release this new version to Tumbleweed (and make it available in OBS for 13.2, etc.) in the very near future.
Is there an advantage to this FUSE approach, in my mind it suggests a possibly simpler implementation that does not require compiling kernel modules that fit the running kernel. Are there any other differences? There have been opinions in the long ago past that FUSE does not perform as well as native kernel file systems, but maybe that could have only been because of implementation?
No longer requiring the kernel module is an improvement from my perspective. No hassle of compiling the module, no tainted kernel, etc… From a performance and stability perspective, I believe VMware is sold on the FUSE approach and they are committed to solving any problems that are identified. If you know of any problems, or run into any, I think VMware will jump on them after they are reported.
If this new package for shared folders lacks other VMware Tools functionality, is it instead intended to be installed side by side with VMware tools?
No - AFAIK, these two packages cannot be installed at the same time. Again, if you try open-vm-tools and run into missing features, please report them as a bug (to VMware, but you can also report the bug to SUSE, and we’ll bring VMware into the bug from that direction.)
As for auto-mounting, if you haven’t already discovered VMware somewhat uniquely uses a systemd mount service (was easier to see in earlier systemd. Nowadays, systemd mounting is so varied it’s harder to trace), so likely can be a very simple configuration modification.
Yes, I think it will end up being something like that. At this point, I’m just trying to determine whether or not auto-mounting is a good thing. Do you have an opinion here?
As described earlier in this thread, VMware deprecated/terminated work on their proprietary VMware Tools a little over a year ago, and since then everyone has been directed to use the community version (with VMware’s full support). The vmware-tools-patches project described in this Forum thread is a way to make the installation and re-installation of any version (even older versions) of VMware Tools as simple and easy as possible.
So, there is no other Tools versions and there is nothing to compare anything against another except the various community versions among themselves.
Most people will use VMware Tools for the enhanced graphical display and shared folders. Others might use VMware Tools for the enhanced I/O devices although I don’t remember anyone posting about that.
So, there is definitely more to be supported than “just” shared folders.
Auto-mounting is a highly desirable configuration, one of the most commonly asked questions about shared folders.
And, auto-mounting is a standard option (also an option to make the mount read-only) in Workstation.
ESXi might not support shared folders officially because technically no one is supposed to log in locally to an ESXi instance. But, just as people know how to log in locally, it should be possible for people to set up shared folders (I would think).
VMware still provides their version of VMware Tools. As an example, the latest version is 10.0.8, and was released back in April of this year. VMware also owns and contributes to the open-vm-tools project, and committed a change to the -gtk3 branch](GitHub - vmware/open-vm-tools at stable-10.0.7-gtk3) just 3 days ago. (The open-vm-tools project is open-source, and they accept contributions from the community, but VMware is still the upstream maintainer.)
As I understand it, Rasa’s project (which is fantastic, btw) contains various patches to ensure the tools are compatible with newer kernels. This was definitely required a while back, but I believe the official VMware Tools (and open-vm-tools) have caught up. (I haven’t used Rasa’s version for a while though, so I could be wrong.)
Most people will use VMware Tools for the enhanced graphical display and shared folders. Others might use VMware Tools for the enhanced I/O devices although I don’t remember anyone posting about that.
So, there is definitely more to be supported than “just” shared folders.
Right. In the open-vm-tools project, VMware states the following regarding these two projects:
“Our goal is to work towards making the open source version as close to the commercial version as possible. However, we do currently make use of certain components licensed from third parties as well as components from other VMware products which are only available in binary form.”
I read the above statement to mean that most major features should be in both VMware Tools and open-vm-tools. However, I think there are very likely some features which exist in only the VMware Tools version. I do know that enhanced graphical display, shared folders, drag-and-drop, vgauth, deploy package, and many other features exist in open-vm-tools. It would be nice to have a table describing which features are available in which tool, but I’m not aware of an authoritative one right now.
Auto-mounting is a highly desirable configuration, one of the most commonly asked questions about shared folders.
And, auto-mounting is a standard option (also an option to make the mount read-only) in Workstation.
Yes, I think auto-mounting is the right way to go as well. We’ll look into it a bit more.
ESXi might not support shared folders officially because technically no one is supposed to log in locally to an ESXi instance. But, just as people know how to log in locally, it should be possible for people to set up shared folders (I would think).
The interface into ESXi does not allow the creation or assignment of a shared folder to a VM. There could be some back door I don’t know about, but it just something that is prevented due to the security risk.
I suspect that licensing you’re quoting from the open-vmware-tools website is a relic.
I checked my Workstation 11 which has been continually updated and it still has some ancient version of VMware Tools, so in actuality I suspect that commercial and proprietary Tools are one and the same… The open sourced versions have been good enough for awhile now that the proprietary code has likely been fully deprecated.
Unless you can obtain some relatively recent commercial version of Tools to compare with an open-vmware-tools package, I don’t know any other likely way to verify what might be true.
The only VMware source for Tools is a public repo, I don’t know if you’d consider this open or commercial. AFAIK there is no separate Tools download through “My VMware” – If any commercial version exists, it’s supposed to be packaged with the paid VMware product. https://packages.vmware.com/tools/releases/10.0.8/sles11sp4/x86_64/index.html
As I noted, although no one is supposed to be able to login locally to an ESXi, that didn’t stop people from immediately figuring out how to hack in when ESXi first launched (and VMware since hasn’t done anything to prevent) because some things can’t be done remotely, it’s a matter of fact.
BTW -
If you inspect the rasa project,
You’ll notice that it extracts the individual modules out of VMware Tools before installing…
I wonder if you are able to replace the current hgfs module that compiles kernel modules with your FUSE implementation, whether that is an approach that might ensure no loss of Tools functionality while implementing your FUSE approach.
You’d also get a clear idea what you’re asking people to give up by your current approach which is to substitute your package for open vmware tools.
I don’t know if it would be immediately accepted as an official implementation, but that shouldn’t stop you from creating your own fork.
Hmm… I’m not sure if we’re on the same page here. The subject to this thread is essentially “[How to] mount shared folders in Tumbleweed VM using open-vm-tools”. You mentioned that open-vm-tools should not be used (comment #21). My response (in comment #22) is that the open-vm-tools package that ships with Tumbleweed can be used to mount shared folders through the vmhgfs-fuse command. This is not “my” FUSE implementation, it is simply what is provided with the official (and VMware recommended) open-vm-tools package.
Whether or not open-vm-tools addresses every use case of VMware Tools is another topic.
I’ll check to see if something changed since I last noticed.
As recently as less than a week ago I’m almost certain that open-vmware-tools (10.0.6) still compiled hgfs kernel modules likely implementing the Plan 9 protocol and did not AFAIK implement hgfs as FUSE.
Yes, the open-vm-tools project does include the hgfs kernel module, but we (SUSE - I’m one of the maintainers of the package in OBS) don’t ship the kernel module any more due to VMware recommending the FUSE approach. (All other VMware kernel modules are included with the kernel itself.)
OK,
I’ll be doing some methodical testing although it’ll take awhile…
I assume then that this kernel integration with the “other” Tools functions is being done upstream and not by the SUSE kernel maintainers?
Need to know that to know which Guests are effected by this change…
So, it should be a part of open-vmware-tools already, integration probably started about 5 months ago with full implementation within the past month plus or so.
And, as the above references suggest, can cause issues in some scenarios.
Might be, if you haven’t installed Tools 10.0.8 you might not have seen this yet, though.
Correct. SUSE’s role here is really more of a packager of open-vm-tools. We obviously deal with any bugs we encounter, and, if necessary, work directly with VMware for in-depth issues. (I know of several people within SUSE or the openSUSE community who contribute to the open-vm-tools project in some way.)
Need to know that to know which Guests are effected by this change…
open-vm-tools has been included in openSUSE for quite some time, but we only starting officially provided this for SLES in the 11SP4 and 12 timeframe. Shortly after that, open-vm-tools 10.0.0 came out with their FUSE approach. At that time, we heard VMware considered the hgfs kernel module deprecated. However, I have seen some additional patches in open-vm-tools that bring that into question. Either way, we switched to the FUSE approach for any SUSE/openSUSE distribution that has a kernel version >= 4.x. (No longer tainting the kernel is a big deal for us.)
If you do get around to testing this, I’d like hear about any deficiencies or problems you find. Also, it’s perfectly fine to continue to build from the rasa project (or anywhere else), but if the included open-vm-tools work, it’s just easier to go that route. YMMV.
Thx especially for that tidbit about kernel >= 4.x if that applies to all openSUSE distro versions.
May explain somewhat why Tools running on LEAP and TW seem to be working fine while 13.2 has been slightly broken (fingers crossed about anything else in the remaining 13.2 life cycle) for awhile now.
Early result (I’ll post something comprehensive when I’m completed testing)
**Testing procedure:
**Running Workstation 11 which is a currently fully supported version (12 was released awhile ago). Workstation is fully up to date.
Created brand new installs for each openSUSE version to assure nothing from older VMware Tools (and other) might pollute results. I doubt for now, but if a reason appears to test upgrading or migrating Guest machines which have had older VMware Tools installed, I will do so then.
Testing <only> the vmhgfs fuse implementation for shared folders for now. When this has been completed, then will test other Tools functionality since the new approach requires that older Tools not be installed (although I saw a post elsewhere that old and new can be installed and run concurrently despite the above response to this question).
**
Early Results:**
**LEAP and Tumbleweed **running 4.x kernels seem to work as described. A bug… It looks like the mounted shared folder and its contents can only be read with root permissions (assume mounted to a subdirectory of /mnt) by default. Should be fixed by maintainers, but for now I can fix that myself.
**13.2 **running the 3.16.7 kernel does not support hgfs-fuse (which has to be built into the kernel). But, it looks like the hgfs-fuse User Tools might be installed, so for instance the very useful new command to display available Share Folders works
vmware-hgfsclient
Interestingly, it looks like the display autofit which stopped working in my regular 13.2 machines seems to work in this brand new install without installing Tools. It’ll be interesting when I install Tools to see if autofit breaks or if I have unknown “stuff” that have accumulated in my machines.
The information in this thread can be considered obsolete.
From today moving forwards, VMware Users should instead reference the SDB:VMware Tools just created.
The new SDB contains information relevant to all versions of openSUSE running on any VMware product.
For anyone running 13.2,
It looks like Tools is a problem.
Install one of the older Tools packages, and auto-fit is broken.
But, Shared Folders doesn’t seem to be possible without installing the older Tools.
So, given the choice I personally have opted to install the older Tools to have Shared Folders functionality, and then manually change the screen resolution (in my case using the LXDE display tool). It’s not an ideal solution, but I live with it. Alternative likely is to just upgrade from 13.2 to LEAP some day. Or, downgrade the kernel to a release on or before February 2016 when the problem first occurred.
Or, I might put some thought into whether it might be possible to deploy the Shared Folder in a different way… perhaps as a Raw Disk. Am avoiding any solution that requires networking so networking doesn’t become the point of vulnerability.
As I noted, although no one is supposed to be able to login locally to an ESXi, that didn’t stop people from immediately figuring out how to hack in when ESXi first launched (and VMware since hasn’t done anything to prevent) because some things can’t be done remotely, it’s a matter of fact.
