Bugzilla Bug 192377

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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=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 an attachment (id=130968) [details]
Dummy initscript - 0.1

A dummy initscript. Only dependencies are defined
start/stop/restart just displays a dummy message

Created an attachment (id=130969) [details]
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 an attachment (id=130970) [details]
Patch for disabling the toolbox - 0.1

This patch disables the toolbox make target when USE="-X"

Created an attachment (id=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 an attachment (id=131045) [details]
open-vm.initd - Version 0.2

A working initscript for open-vm-tools

Created an attachment (id=131048) [details]
xautostart.conf 0.1 (-> $FILESDIR)

sorry, forgot to include this previously...

Created an attachment (id=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:)