VMware Inc. released a opensource version of their vmware-tools, called open-vm-tools. I've created an initial ebuild which is far from being finished, but just wanted to follow the 'release early, release often' mantra.
Created attachment 130783 [details] first incomplete ebuild for app-emulation/open-vm-tools-20070904_p56574 More information for packagers can be found at http://open-vm-tools.wiki.sourceforge.net/Packaging This ebuild should work so far on x86 and amd64. What it currently does: - compiles without errors - respects the useflags X and xinerama - installs a PAM policy file What still needs to be done: - place the kernel modules in the target directories - make $MY_PV dynamic, currently it's hardcoded, but probably the versionator.eclass will do a good job here - initscript for vmware-guestd (is this needed or is this daemon automagically started by the corresponding kernel module?) - installation of doc files into /usr/share/doc - ....
Elias, Thanks for the great work in getting an ebuild ready just a day or so after release! It looks good, have you considered using the vmware-mod.eclass to do the building and installation of the various modules for you? I haven't had a chance to examine the tar ball, so I don't know if they're packaged the same way as they were for the official vmware-blah-tools, but you might be interested in looking at vmware-workstation-tools, both 5.5 and 6 (which is in the vmware overlay). They give two different examples of how we previously packaged up the tools, and might offer a way of automating more of the task? Either way, thanks again for getting on this, great work! We'll probably end up integrating it into the one we finally use... 5:)
Created attachment 130850 [details] new version - still buggy Did some further development. Still not working, as the usage of the vmware-/linux-mod eclass didn't went as smooth as expected. Will continue development in ~18 hours. Regards, Elias P. Sorry for submitting not working ebuilds, but I think it's best providing what I've done so far in the case, someone else wants to continue development.
Created attachment 130868 [details] Ebuild version 0.0.3 - Capable of compiling and installing the modules Hiya Elias, Once again thanks for the work you're doing on this. Since you're doing such a sterling job, I decided to clear a little time tonight and jump in. I've been through your previous ebuild and made some modifications (I obsoleted the old one and started an [arbitrary] ebuild numbering scheme so we can keep track). 5;) It now doesn't use vmware-mod.eclass (they don't package it in quite the same that they used to for vmware official, so it's probably easier not to use the same code). It does successfully use the linux-mod eclass to build, install and track all of the required modules. It should also be configuring and compiling everything, it simply isn't installing it yet. Unfortunately I've gotta get some sleep now, so it's back over to you. Keep up the great work! 5:)
Created attachment 130895 [details] Ebuild version 0.0.4 - Compiles & installs modules and tools Ok, a slightly newer version. It now installs most of the tools (I can't seem to find source code for xferlogs anywhere). It requires a couple of files to go in ${FILESDIR} for copying to /etc/vmware-tools. To do list before it hits the main tree: * vmware-guestd init script * check everything works without segfaults/problems * clean-up the in-ebuild sedding if possible (perhaps by using patches) * figure out why libguest.so isn't being built (no shared object created) * anything else I've forgotten... 5;)
Do these tools work for all of the VMware products? Do they work on the older versions, too? Is there loss of functionality? If so, I would much rather take these and get them into the tree and replace the older tools with these. Also, are we sure the license is GPL-2? That could really be nice, if it is, as it means we can distribute it on our release media, which is something people have been asking to get for a long time now and we were unable to provide (because of the modules) due to licensing.
(In reply to comment #6) > Do these tools work for all of the VMware products? Do they work on the older > versions, too? Is there loss of functionality? As far as I can see, neither do they need a newer release of any VMware product, nor they're restricted to a specific one. Also they should provide all the functionality the proprietary ones provided. > If so, I would much rather take these and get them into the tree and replace > the older tools with these. Also, are we sure the license is GPL-2? That > could really be nice, if it is, as it means we can distribute it on our release > media, which is something people have been asking to get for a long time now > and we were unable to provide (because of the modules) due to licensing. That's what is VMware trying to reach: making distributions shipping the vmware tools out-of-the box. And yes, they are GPL-2! That's really great. There are also plans making qemu being able using the open-vm-tools (there are some posts on the mailinglist regarding this: http://sourceforge.net/mailarchive/forum.php?thread_name=46E6E3C5.4000305%40codemonkey.ws&forum_name=open-vm-tools-devel). Replacing the proprietary tools should only happen after excessive testing of the open tools, but if they should prove reliability - yes, replace the old ones ASAP! Regards, Elias P.
Created attachment 130967 [details] Ebuild version 0.0.5 - patches instead of sed / it really installs modules Changes: * Configuration files in ${FILESDIR} now available (see attachment) * Dummy initscript in ${FILESDIR} now available (see attachment) * Replaced 'sed' statements - now using patches (see attachment) * Using ${ROOT} where possible * Dependencies are blocking now the proprietary vmware-*-tools * Compiling/installing the modules works now properly * Added x11-libs/libXtst to the dependencies * Added pam to IUSE * Creation of /var/tmp/vmware/dnd directory TODO-List: * vmware-guestd init script * check everything works without segfaults/problems * make it build without X/xRandr/xTst * figure out why libguest.so isn't being built (no shared object created) * check, whether we should set proper user/group permissions on the utilities/tmp-dnd-directory I've also posted to the open-vm-tools-devel mailinglist at sourceforge.net. I hope we can resolve some of the problems: http://sourceforge.net/mailarchive/forum.php?thread_name=200709150522.43339.mail%40eliasprobst.eu&forum_name=open-vm-tools-devel Regards, Elias P.
Created attachment 130968 [details] Dummy initscript - 0.1 A dummy initscript. Only dependencies are defined start/stop/restart just displays a dummy message
Created attachment 130969 [details, diff] Patch for changing the path to the dnd directory - 0.1 This patch changes the path of the dnd directory from /tmp/VmwareDnD to /var/tmp/vmware/dnd because /tmp/VmwareDnD would be deleted on startup by tmpcleaner scripts.
Created attachment 130970 [details, diff] Patch for disabling the toolbox - 0.1 This patch disables the toolbox make target when USE="-X"
Created attachment 131043 [details] Ebuild version 0.0.8 - now with integrated fluxcompensator Another update of the ebuild (ver 0.0.8 because I've continued versioning in my internal development): Changes: * Using ikelos' way of building modules again + some additional modifications * ebuild creates now a 'vmware' group * Some elog output added * Working initscript included * Removed the patches for changing the path of the dnd directory as suggested on the open-vm-tools-devel mailinglist * Creation of dnd-tmpdir is now done by the initscript instead of the ebuild * Further usage of ${ROOT} instead of / * RDEPEND doesn't include virtual/linux-sources anymore TODO: * make it build without X/xRandr/xTst * figure out why libguest.so isn't being built (no shared object created) * Testing whether all works as expected....
Created attachment 131045 [details] open-vm.initd - Version 0.2 A working initscript for open-vm-tools
Created attachment 131048 [details] xautostart.conf 0.1 (-> $FILESDIR) sorry, forgot to include this previously...
Created attachment 131049 [details] tools.conf 0.1 (-> $FILESDIR) sorry, forgot to include this previously...
Some comments on the vmware-guestd init script: - /tmp/VMwareDnD needs to be mode 1777. During a DnD operation, vmware-user will try to make a subdirectory in /tmp/VMwareDnD, and since vmware-user can run as any user on the system, the parent directory must be world writable. To prevent malicious users from unlinking the newly created subdirectory, we mark /tmp/VMwareDnD as sticky (the '1' in 1777). Then only the owner of the subdirectory and/or root can unlink it. - After creating /tmp/VMwareDnD, you must also mount the vmblock filesystem. You should also unmount it when guestd goes down. Use something like "mount -t vmblock none /proc/fs/vmblock/mountPoint". - If you really want to change /tmp/VMwareDnD to something else, you can pass a "root" module option with the new directory. Something like "modprobe vmblock root=/path/to/new/dnd/root". However, you'll need to patch lib/dnd/dndLinux.c and replace fileRoot with the same thing (see DnD_GetFileRoot).
Thanks very much for the info Adar! I've checked the entire ebuild into our overlay (which can be found at http://overlays.gentoo.org/proj/vmware/) and made some changes to the ebuild. First off it had a typo (VmwareDnD and VMwareDnD), the permissions are now fixed and we also now mount a vmblock type fs on /proc/fs/vmblock/mountPoint. I tried it out, and it worked! Sure enough, files were successfully turning up in /tmp/VMwareDnD... 5:) Thanks again for the help, it looks like we're nearly set with this!
Been putting this ebuild through its paces. The ebuild still requires X libs even if USE="-X", but I see that seems to be an upstream problem with the configure step. I would like to request that either: 1. The loading of vmblock modules and mounting of /tmp/VMwareDND be configurable for enable/disable via /etc/conf.d/vmware-tools OR 2. The starting of vmware-guestd and vmblock/VMwareDND be separated into two different init scripts I have vmware guest servers that are non-gui. I want vmware-guestd running for time sync purposes, but I do not want VMware DnD on these machines. BTW, fantastic work. The ebuild is really shaping up nicely. Thanks.
I believe open-vm-tools should also have: /etc/vmware-tools/poweroff-vm-default /etc/vmware-tools/poweron-vm-default Otherwise using graceful Shutdown & graceful Restart give errors. The scripts from vmware-server-tools work fine for me.
(In reply to comment #19) > I believe open-vm-tools should also have: > > /etc/vmware-tools/poweroff-vm-default > /etc/vmware-tools/poweron-vm-default > > Otherwise using graceful Shutdown & graceful Restart give errors. The scripts > from vmware-server-tools work fine for me. > Yeah, you should get the suspend-vm-default and resume-vm-default scripts too. We forgot to include these in the source package; they'll be in the next release.
(In reply to comment #20) > (In reply to comment #19) > > I believe open-vm-tools should also have: > > > > /etc/vmware-tools/poweroff-vm-default > > /etc/vmware-tools/poweron-vm-default > > > > Otherwise using graceful Shutdown & graceful Restart give errors. The scripts > > from vmware-server-tools work fine for me. > > > > Yeah, you should get the suspend-vm-default and resume-vm-default scripts too. > We forgot to include these in the source package; they'll be in the next > release. > I must admit I only looked at the suspend/resume scripts briefly, however they did appear to be some kind of distro-specific (SuSE?) net-reinitialization scripts. I am able to suspend/resume with no problems, no loss of net, and no complaints from vmware without them. So what are they for exactly?
(In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #19) > > > I believe open-vm-tools should also have: > > > > > > /etc/vmware-tools/poweroff-vm-default > > > /etc/vmware-tools/poweron-vm-default > > > > > > Otherwise using graceful Shutdown & graceful Restart give errors. The scripts > > > from vmware-server-tools work fine for me. > > > > > > > Yeah, you should get the suspend-vm-default and resume-vm-default scripts too. > > We forgot to include these in the source package; they'll be in the next > > release. > > > > I must admit I only looked at the suspend/resume scripts briefly, however they > did appear to be some kind of distro-specific (SuSE?) net-reinitialization > scripts. I am able to suspend/resume with no problems, no loss of net, and no > complaints from vmware without them. So what are they for exactly? The gist of the default suspend/resume scripts is "drop any DHCP leases just before suspend, and renew them on resume". They were implemented long ago, I think as far back as 2001. They can be useful if you suspend the VM, move it to a different networking subnet, and resume it. Or if you are operating behind NAT, then it might be useful to do in general. They're not SuSE specific, though; we try to find the appropriate init.d networking script regardless of distro. They should work on all of our supported distros (the RHELs, SLESs, and Ubuntus of the world). It's possible they don't work properly on Gentoo, so if you can patch them so they do work, feel free to do that.
Ok, I'm interested in understanding the impact loading and mounting the vmblock driver has on a box without X, but if it's purely to avoid files randomly appearing in /tmp/ then I guess I can understand it. Either way, in the overlay there's now a conf.d file that should get installed, and if you set the variable in to to anything other than yes, you'll just get guestd started and stopped. Finally, does someone have any reference scripts for these poweron/poweroff/suspend things? I've check the open-vm sourceforge site's CVS and SVN repos but they're both empty and they don't appear to be in the source release. For now I'm just gonna leave them out until the next source release, unless people would say they have a large impact?
(In reply to comment #23) > Ok, > > I'm interested in understanding the impact loading and mounting the vmblock > driver has on a box without X, but if it's purely to avoid files randomly > appearing in /tmp/ then I guess I can understand it. There should be no impact. The driver is driven from userspace via ioctls to a proc node, and without X, vmware-user won't run and nobody will issue said ioctls. > Finally, does someone have any reference scripts for these > poweron/poweroff/suspend things? I've check the open-vm sourceforge site's CVS > and SVN repos but they're both empty and they don't appear to be in the source > release. For now I'm just gonna leave them out until the next source release, > unless people would say they have a large impact? You can get them from previous Tools binary-only releases. Without some sort of scripts, though, a VM configured for soft power operations will pop-up an error dialog box after a power operation (resume, suspend, etc.).
> > Either way, in the overlay there's now a conf.d file that should get installed, > > and if you set the variable in to to anything other than yes, you'll just get > > guestd started and stopped. Awesome, thanks. =) > > Finally, does someone have any reference scripts for these > > poweron/poweroff/suspend things? I've check the open-vm sourceforge site's CVS > > and SVN repos but they're both empty and they don't appear to be in the source > > release. For now I'm just gonna leave them out until the next source release, > > unless people would say they have a large impact? > > You can get them from previous Tools binary-only releases. Without some sort of > scripts, though, a VM configured for soft power operations will pop-up an error > dialog box after a power operation (resume, suspend, etc.). > I got them from vmware-server-tools. vmware will only complain if the power off/on scripts are not included. vmware does not complain if the suspend/resume ones are not included, but as Adar stated they are necessary to make guests' release/obtain DHCP leases on suspend/resume respectively. I haven't had a chance to revisit the vmware suspend/resume scripts since my last post, but they are probably in need of modification to work properly utilizing Gentoo's own network scripts/framework.
on "/etc/init.d/vmware-tools start": /etc/init.d/vmware-tools: line 18: no: command not found on "/etc/init.d/vmware-tools stop": /etc/init.d/vmware-tools: line 52: no: command not found Suggest change from: if "${VM_DRAG_AND_DROP}" == "yes"; to: if [[ ${VM_DRAG_AND_DROP} == "yes" ]];
Please take a look at the vmware overlay. Some of the issues are already fixed there. Will continue development, as soon as upstream (or somebody else) releases a fix for compiling open-vm-tools without X. https://sourceforge.net/tracker/index.php?func=detail&aid=1796805&group_id=204462&atid=989708 My only Gentoo-VM is X-less. Regards, Elias P.
Elias, we recently put out a development snapshot that supports --without-x properly. Can you give it a shot?
Hi Adar, Thanks for the note, I'll work up an ebuild for the snapshot in the next couple of days. I've got another Gentoo developer who may be able to test it for us too, so I'll post any results I hear of back here. Thanks again, and keep up the good work... 5:)
Ok, the snapshot is now in the overlay and compiles with X. Could some people please test it out without X and report back here? Thanks... 5:)
(In reply to comment #30) > Ok, the snapshot is now in the overlay and compiles with X. Could some people > please test it out without X and report back here? Thanks... 5:) Thank you for the updated ebuild. It compiles and works fine on my X-less box. But there's still one question, especially to the VMware guys: Does Drag'n'Drop really work without X in the guest? I can't drop any files to the VMware Server Console. Is there anything else that needs to be configured? Regards, Elias P.
Elias, I don't believe vmware-servers-1.0.3 or 1.0.4 support drag and drop into or out of linux. Also, if you were to drag into an X-less box, you'd find the file in /tmp/VMware-DnD/ under a random directory, so the transfer would occur, but I doubt it would get copied into the current working directory. Thanks for your help testing out the x-less builds, that was pretty much the last hurdle before putting this in the tree, so once the vmware guys make a full release rather than a snapshot, I'll move the ebuilds into the main tree! 5:)
Elias: DnD only works when X is running. Otherwise vmware-user doesn't run, and thus there's no drop pseudo-target in the guest. Any attempt to drag a file over the console border should result in the cursor changing into some sort of symbol indicating no DnD is possible. Mike: You are correct, the Server UI doesn't support DnD either. Basically the only time DnD will work is if you're running a Windows WS4+ (or Linux WS6+) or Fusion UI with vmware-user running in the guest. Even then, I'm not sure if Linux guest support will work until you hit WS6, though it's worth trying out.
Hiya guys, sorry for having gone all quiet on this front, personal problems took precedence. I've just added the latest version of the open-vm-tools stable release to the overlay, please give it a test (particularly the no-X guys) and let me know if there are any problems. If not, I'll try and get this package into the tree in the next week or so... 5:)
I've been running this latest ebuild for a while now on several VMs running under ESX 3.0, Workstation 6, and Server 1.0. All of my VMs are USE=-X and everything seems to be running great!
Ok, that's fantastic and exactly the feedback I was looking for, depending on the time I have over christmas, this should hit the tree late Decemeber or early January. Thanks very much to everyone who's tested this, and particularly to Elias for his work on the ebuilds... 5:)
Sorry, couldn't follow my bugtracker mails during the last weeks. open-vm-tools is running here with USE="-X" also really fine using vmware-server. Thank you ikelos!
Ok, this has just been checked into the main tree. This should mean we can start dropping the various vmware-*-tools packages over time. I think we can now mark this bug as FIXED! Thanks for your help everybody... 5:)
