open-vm-tools-discuss Mailing List for open-vm-tools (Page 13)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Is there a way to run a DOS virtual machine while allowing that machine to 
have Shared Folders with my XP host? 

Ryan Beasley wrote:
> Denis Leroy wrote:
>> I apologize if this is somewhat off-topic for open-vm-tools.
>>
>> Do you guys know what is the status of the XOrg vmmouse driver ? Is that
>> still maintained by VMWare ? Essentially, the vmmouse driver has been
>> broken for a while now on Fedora (since F-9) since it can't coexist with
>> input hotplugginh and the evdev driver. This will likely affect other
>> distros as well. This is filed upstream at
> 
> Hm.  Not cool.  I can't go into organizational specifics, but the driver is
> maintained by VMware + whoever else has commit access @ freedesktop.org.  I'll
> poke around internally & will see if I can get someone to check this one out.

Of course, considering that the source -is- publicly available, there's nothing 
to stop anyone else from digging in and contributing a fix themselves.  ;) 
(That's one of the goals of opening these things up in the first place, yeah?)

-- 
Ryan Beasley <rbe...@vm...>

Denis Leroy wrote:
> I apologize if this is somewhat off-topic for open-vm-tools.
> 
> Do you guys know what is the status of the XOrg vmmouse driver ? Is that
> still maintained by VMWare ? Essentially, the vmmouse driver has been
> broken for a while now on Fedora (since F-9) since it can't coexist with
> input hotplugginh and the evdev driver. This will likely affect other
> distros as well. This is filed upstream at

Hm.  Not cool.  I can't go into organizational specifics, but the driver is 
maintained by VMware + whoever else has commit access @ freedesktop.org.  I'll 
poke around internally & will see if I can get someone to check this one out.

-- 
Ryan Beasley <rbe...@vm...>

I apologize if this is somewhat off-topic for open-vm-tools.

Do you guys know what is the status of the XOrg vmmouse driver ? Is that 
still maintained by VMWare ? Essentially, the vmmouse driver has been 
broken for a while now on Fedora (since F-9) since it can't coexist with 
input hotplugginh and the evdev driver. This will likely affect other 
distros as well. This is filed upstream at

https://bugs.freedesktop.org/show_bug.cgi?id=17489

but seems ignored.

-denis

> > Hmm, the intent of this install-exec-hook is, among other things, to
> > ensure that hgfsmounter is setuid root, which is why the chown is
> > there.
> >
> > But I guess you're saying that it's not necessary because of the
> > following logic: 1) The user can run 'make install' as is, or under
> > sudo/su. 2) If sudo/su isn't used, there's no way to establish setuid
> >  root on the binary anyway. 3) If sudo/su is used, 'make install'
> > will guarantee that the owner/group is root by virtue of the fact
> > that the default actions for bin_PROGRAMS or sbin_PROGRAMS is to
> > install the file as the current user.
> >
> > Is that correct? If so, I'll remove the chown.
>
> Yes this is correct.
>
> Typically things like setuid or file ownerships are managed by the
> package spec file.
>
>
> >> - The module installation ignores DESTDIR, and so will also fail as
> >>  part of an non-root RPM build.
> >
> > Are you sure about that? I see this code in modules/Makefile.am:
>
> I'm sorry, my statement was inaccurate. The problem is the call to
> 'depmod', which requires root privileges. I would recommend to provide
> a
> configure option that disables the call to depmod. Similar options are
> very common for example in gnome applications, to disable the call to
> the desktop or mime info installation script (packagers prefer to do
> this from the spec files).
>
>
> >> - mount.vmhgfs gets installed in /usr/sbin instead of /sbin

Here's a patch to address the three make install issues. Let me know if it works for you and I'll apply it to the git repo.

Joshua Daniel Franklin wrote:
> On Mon, Sep 8, 2008 at 6:45 AM, Denis Leroy wrote:
>> Was trying to get a trace from the hang, but now I'm having problems
>> reproducing the bug. I might have misdiagnosed the libicu cause. Sorry
>> for the confusion, things are working better now both with F-9 and
>> rawhide. dkms on poolshark.org is updated with some packaging fixes. Not
>> sure what happened, still looking into it.
> 
> Denis,
> 
> Thanks very much. I rebuilt the latest dkms rpm on my Fedora 9 VM. It installed
> fine and in GNOME I was able to drag over a PNG file without any trouble, and
> the "tools are not installed" message is gone. However, I still have
> to click inside
> the window to get a mouse (using either X11 or gpm) which it sounds like
> you're working on. I'd be happy to test again on Fedora 9 running in
> Fusion 2 beta when needed. Adar: I turned on logging, but I'm guessing you
> don't need it anymore.
> 

Joshua,

the mouse problem is not an open-vm-tools issue. It's the xorg vmmouse 
driver that's broken in XOrg 7.3. See

https://bugzilla.redhat.com/show_bug.cgi?id=434807

There is a workaround however. You'll have to create a 
/etc/X11/xorg.conf file manually (or with the system-config-display 
tool), and add a mouse section to force the vmmouse driver to load:

Section "InputDevice"
         Identifier  "Mouse0"
         Driver      "vmmouse"
         Option      "Device"      "/dev/input/mice"
EndSection

And add the following lines inside the "ServerLayout" section:
      Option "AutoAddDevices" "off"
      InputDevice    "Mouse0" "CorePointer

On Mon, Sep 8, 2008 at 6:45 AM, Denis Leroy wrote:
> Was trying to get a trace from the hang, but now I'm having problems
> reproducing the bug. I might have misdiagnosed the libicu cause. Sorry
> for the confusion, things are working better now both with F-9 and
> rawhide. dkms on poolshark.org is updated with some packaging fixes. Not
> sure what happened, still looking into it.

Denis,

Thanks very much. I rebuilt the latest dkms rpm on my Fedora 9 VM. It installed
fine and in GNOME I was able to drag over a PNG file without any trouble, and
the "tools are not installed" message is gone. However, I still have
to click inside
the window to get a mouse (using either X11 or gpm) which it sounds like
you're working on. I'd be happy to test again on Fedora 9 running in
Fusion 2 beta when needed. Adar: I turned on logging, but I'm guessing you
don't need it anymore.

Joshua

Adar Dembo wrote:
>>> Let's go for the logs. I'm trying to think of shared components
>>> between guestd and vmware-user; libicu definitely fits the bill,
>>> though there may be others.
>> Nice catch.
>>
>> I confirm this is a libicu problem. Reverting back from libicu 3.8.1 to
>> 3.8 makes vmware-guestd and vmware-user happy.
> 
> Cool. What's the next step? Should we do some debugging on our end, or would it be best to file a bug against libicu?
> 
> If you do file a libicu bug, please cc me on it.

Was trying to get a trace from the hang, but now I'm having problems 
reproducing the bug. I might have misdiagnosed the libicu cause. Sorry 
for the confusion, things are working better now both with F-9 and 
rawhide. dkms on poolshark.org is updated with some packaging fixes. Not 
sure what happened, still looking into it.

-denis

> > Let's go for the logs. I'm trying to think of shared components
> > between guestd and vmware-user; libicu definitely fits the bill,
> > though there may be others.
>
> Nice catch.
>
> I confirm this is a libicu problem. Reverting back from libicu 3.8.1 to
> 3.8 makes vmware-guestd and vmware-user happy.

Cool. What's the next step? Should we do some debugging on our end, or would it be best to file a bug against libicu?

If you do file a libicu bug, please cc me on it.

Adar Dembo wrote:
> Let's go for the logs. I'm trying to think of shared components
> between guestd and vmware-user; libicu definitely fits the bill,
> though there may be others.

Nice catch.

I confirm this is a libicu problem. Reverting back from libicu 3.8.1 to 
3.8 makes vmware-guestd and vmware-user happy.

Latest DKMS package

http://www.poolshark.org/dkms-open-vm-tools/dkms-open-vm-tools-0-1.2008.09.03.fc9.src.rpm

Note: doesn't work on Fedora 9 and newer. Fedora 8 is ok.

Adar Dembo wrote:
> Thanks for taking the time to describe each of these issues. I'm 
> guessing the compilation problems you were seeing got fixed in bug 
> 2048423?

Yes probably, along with the kernel modules not compiling on very recent
kernels.

> Hmm, the intent of this install-exec-hook is, among other things, to 
> ensure that hgfsmounter is setuid root, which is why the chown is 
> there.
> 
> But I guess you're saying that it's not necessary because of the 
> following logic: 1) The user can run 'make install' as is, or under 
> sudo/su. 2) If sudo/su isn't used, there's no way to establish setuid
>  root on the binary anyway. 3) If sudo/su is used, 'make install'
> will guarantee that the owner/group is root by virtue of the fact
> that the default actions for bin_PROGRAMS or sbin_PROGRAMS is to
> install the file as the current user.
> 
> Is that correct? If so, I'll remove the chown.

Yes this is correct.

Typically things like setuid or file ownerships are managed by the
package spec file.

>> - The module installation ignores DESTDIR, and so will also fail as
>>  part of an non-root RPM build.
> 
> Are you sure about that? I see this code in modules/Makefile.am:

I'm sorry, my statement was inaccurate. The problem is the call to
'depmod', which requires root privileges. I would recommend to provide a
configure option that disables the call to depmod. Similar options are 
very common for example in gnome applications, to disable the call to 
the desktop or mime info installation script (packagers prefer to do 
this from the spec files).

>> - mount.vmhgfs gets installed in /usr/sbin instead of /sbin
> 
> Does this matter if there's also a symlink from /sbin/mount.vmhgfs to
>  /usr/sbin/mount.vmhgfs? Looking at the code, the very last action in
>  install-exec-hook is:
> 
> -$(LN_S) $(DESTDIR)$(sbindir)/mount.vmhgfs \ 
> $(DESTDIR)/sbin/mount.vmhgfs &> /dev/null
> 
> That should guarantee a symlink from /sbin/mount.vmhgfs, right?

The ln command fails because $(DESTDIR)/sbin doesn't exist. Simply
create the directory first, that fixes it.

>> - after I got everything built and prepared, guestd seems to hang 
>> on startup, using up 100% cpu. Vmware workstation reports 'Your VM 
>> tools is out of date' (i'm using workstation 6.5 on linux host). Is
>>  there a way to compile in more debug information that I could 
>> report ?
> 
> Yes, see my reply to Joshua Franklin to see how guestd/vmware-user 
> logging can be enabled. Let's start from there and add more serious 
> instrumentation if logging doesn't help.

Log attached. As you can see it's pretty short. The last entry is 
'[vmsvc]: Registering callback 'Vix_1_SyncDriver_Thaw'.

The hang occurs with both Fedora 9 and Fedora rawhide.

> What Xorg version is in Fedora 9? I noticed this same issue with 
> Ubuntu Intrepid; turns out new versions of Xorg use input-hotplug 
> which cannot detect vmmouse. I think we're trying to address this by 
> switching over to the VMware USB mouse (different from vmmouse) and 
> improving evdev's support for this mouse, but I don't know the 
> specifics or the status.

Xorg 7.3. vmmouse seems to be pretty thoroughly broken for it. Even by 
specifying vmmouse in xorg.conf, the driver loads correctly but doesn't 
work correctly (x,y coordinates are incorect). I see bug reports in 
launchpad about this as well.

> I've been working on a more recent version of my dkms packages. The
> 09-03 release is the first in a long time that actually compiles on
> rawhide (after working around an icu bug, bug 461348, will be pushed to
> rawhide in a few days), although it's still far from working. Some of
> the issues i ran into:

Thanks for taking the time to describe each of these issues. I'm guessing the compilation problems you were seeing got fixed in bug 2048423?

> - 'make install' tries to 'chown' some files (in the hgfsmounter
> install-exec-hook). This will fail on most packaging system, since
> packages are rarely built as root. I don't think the chown is necessary
> anyway.

Hmm, the intent of this install-exec-hook is, among other things, to ensure that hgfsmounter is setuid root, which is why the chown is there.

But I guess you're saying that it's not necessary because of the following logic:
1) The user can run 'make install' as is, or under sudo/su.
2) If sudo/su isn't used, there's no way to establish setuid root on the binary anyway.
3) If sudo/su is used, 'make install' will guarantee that the owner/group is root by virtue of the fact that the default actions for bin_PROGRAMS or sbin_PROGRAMS is to install the file as the current user.

Is that correct? If so, I'll remove the chown.

> - The module installation ignores DESTDIR, and so will also fail as
> part
> of an non-root RPM build.

Are you sure about that? I see this code in modules/Makefile.am:

        for MOD in $(MODULES); do \
                $(INSTALL) -d $(DESTDIR)`eval echo '$$'$${MOD}dir`; \
                $(INSTALL) -m644 $(MODULES_OS)/$$MOD/$$MOD.ko $(DESTDIR)`eval echo '$$'$${MOD}dir`; \
        done

I see $(DESTDIR) prefixes, what's missing? I mean, there's no path separator between $(DESTDIR) and the rest, but I think that shouldn't matter because every module directory (vmblockdir, vmcidir, etc.) begins with $(MODULES_DIR) which is an absolute path, thus already prefixed with a path separator.

> - mount.vmhgfs gets installed in /usr/sbin instead of /sbin

Does this matter if there's also a symlink from /sbin/mount.vmhgfs to /usr/sbin/mount.vmhgfs? Looking at the code, the very last action in install-exec-hook is:

        -$(LN_S) $(DESTDIR)$(sbindir)/mount.vmhgfs \
                $(DESTDIR)/sbin/mount.vmhgfs &> /dev/null

That should guarantee a symlink from /sbin/mount.vmhgfs, right?

> - after I got everything built and prepared, guestd seems to hang on
> startup, using up 100% cpu. Vmware workstation reports 'Your VM tools
> is
> out of date' (i'm using workstation 6.5 on linux host). Is there a way
> to compile in more debug information that I could report ?

Yes, see my reply to Joshua Franklin to see how guestd/vmware-user logging can be enabled. Let's start from there and add more serious instrumentation if logging doesn't help.

> - can't move the mouse out of the VM window. Somehow Xorg is not using
> the vmmouse driver ? The system runs without an xorg.conf file (as is
> the norm nowadays), but it should have selected the right drivers by
> default.

What Xorg version is in Fedora 9? I noticed this same issue with Ubuntu Intrepid; turns out new versions of Xorg use input-hotplug which cannot detect vmmouse. I think we're trying to address this by switching over to the VMware USB mouse (different from vmmouse) and improving evdev's support for this mouse, but I don't know the specifics or the status.

> - running vmware-user yields the same hang problem as guestd.

Let's go for the logs. I'm trying to think of shared components between guestd and vmware-user; libicu definitely fits the bill, though there may be others.

> >> It seemed to work fine and shows up in "dkms status"...
> >> but I still get "VMware Tools is not installed."  and
> >> copy/paste does not work. Should it?
> >
> > Can you verify that vmware-guestd is running? The UI's Tools status
> notification comes from messages sent by vmware-guestd.
> >
> > Are you using a console or are you within an X11 session? Can you
> verify that vmware-user is running?
>
> X11. Yep, "ps x" shows both are running.

OK, could you upload your VMX log (vmware.log) as well as the vmware-user and vmware-guestd logs? You can obtain the latter by editing the tools.conf file (it's probably in /etc/vmware-tools) and adding the following two lines:

log = "true"
log.file = "/path/to/file"

After that, the processes should start logging themselves to /path/to/file and /path/to/file.<pid> (vmware-user typically can't write to the same log as vmware-guestd). I'd especially like to see the logging done at startup for both processes, so after you've enabled logging, restart them.

Joshua Daniel Franklin wrote:
> Hello, I'm running VMWare Fusion 2 beta and trying to get
> open-vm-tools installed in a Fedora 9 VM.
> 
> I first tried the download on the main page but ran into the
> procps header problem, so I rebuilt the Fedora 8 RPM at
> http://www.poolshark.org/dkms-open-vm-tools/
> dkms-open-vm-tools-0-1.2008.05.15.fc8.src.rpm	

I've been working on a more recent version of my dkms packages. The 
09-03 release is the first in a long time that actually compiles on 
rawhide (after working around an icu bug, bug 461348, will be pushed to 
rawhide in a few days), although it's still far from working. Some of 
the issues i ran into:

- 'make install' tries to 'chown' some files (in the hgfsmounter 
install-exec-hook). This will fail on most packaging system, since 
packages are rarely built as root. I don't think the chown is necessary 
anyway.

- The module installation ignores DESTDIR, and so will also fail as part 
of an non-root RPM build.

- mount.vmhgfs gets installed in /usr/sbin instead of /sbin

- after I got everything built and prepared, guestd seems to hang on 
startup, using up 100% cpu. Vmware workstation reports 'Your VM tools is 
out of date' (i'm using workstation 6.5 on linux host). Is there a way 
to compile in more debug information that I could report ?

- can't move the mouse out of the VM window. Somehow Xorg is not using 
the vmmouse driver ? The system runs without an xorg.conf file (as is 
the norm nowadays), but it should have selected the right drivers by 
default.

- running vmware-user yields the same hang problem as guestd.

On Fri, Sep 5, 2008 at 4:57 PM, Adar Dembo wrote:
>> I first tried the download on the main page but ran into the
>> procps header problem, so I rebuilt the Fedora 8 RPM at
>> http://www.poolshark.org/dkms-open-vm-tools/
>> dkms-open-vm-tools-0-1.2008.05.15.fc8.src.rpm
>
> You could also use the Sourceforge download and pass --without-procps to configure. Doing that will cause some code in vmware-guestd to be skipped, but that doesn't matter at all to Fusion.

I may try that after getting this first VM working.

>> It seemed to work fine and shows up in "dkms status"...
>> but I still get "VMware Tools is not installed."  and
>> copy/paste does not work. Should it?
>
> Can you verify that vmware-guestd is running? The UI's Tools status notification comes from messages sent by vmware-guestd.
>
> Are you using a console or are you within an X11 session? Can you verify that vmware-user is running?

X11. Yep, "ps x" shows both are running.

>> By the way, Fedora 10 is nearing beta so it would be
>> great to get this working there too. It's pretty easy for
>> me to build a livecd iso from the devel tree so if anyone
>> wants to play with it let me know and I'll put up a
>> download of a livecd that includes dev tools.
>>
>> Or, if you're running Fedora, you can build a custom devel
>> livecd easily by following these instructions:
>> http://spevack.livejournal.com/31634.html
>
> I don't have the bandwidth to do that right now, but I just thought I'd add that I too would appreciate seeing a Fedora 10 package.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> open-vm-tools-discuss mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-discuss
>

> I first tried the download on the main page but ran into the
> procps header problem, so I rebuilt the Fedora 8 RPM at
> http://www.poolshark.org/dkms-open-vm-tools/
> dkms-open-vm-tools-0-1.2008.05.15.fc8.src.rpm

You could also use the Sourceforge download and pass --without-procps to configure. Doing that will cause some code in vmware-guestd to be skipped, but that doesn't matter at all to Fusion.

> It seemed to work fine and shows up in "dkms status"...
> but I still get "VMware Tools is not installed."  and
> copy/paste does not work. Should it?

Can you verify that vmware-guestd is running? The UI's Tools status notification comes from messages sent by vmware-guestd.

Are you using a console or are you within an X11 session? Can you verify that vmware-user is running?

> By the way, Fedora 10 is nearing beta so it would be
> great to get this working there too. It's pretty easy for
> me to build a livecd iso from the devel tree so if anyone
> wants to play with it let me know and I'll put up a
> download of a livecd that includes dev tools.
>
> Or, if you're running Fedora, you can build a custom devel
> livecd easily by following these instructions:
> http://spevack.livejournal.com/31634.html

I don't have the bandwidth to do that right now, but I just thought I'd add that I too would appreciate seeing a Fedora 10 package.

Adar Dembo wrote:
>> So does this mean that if I run them on *any* guest in my cluster, and
>> something goes wrong, VMWare won't help me?  Or is it just the case that
>> if I say "my guest OS is broken,
>> and-by-the-way-I'm-running-open-vm-tools" they'll tell me to go away?
>>
>> I guess what I'm wondering is would I be likely to get support if:
>>
>> - I was running open-vm-tools most of the time
>> - a problem occurred
>> - I switched to ESX Tools and confirmed the problem still existed
>> - *then* called support?
> 
> I honestly don't know, and I think a lot of is done by ear. So you'll call them and describe your problem, and if it's something to do with the guest they might ask you what version of Tools you're running, and then you'll tell them you're using the open-vm-tools, and they might try to help you anyway, or they may ask you to reproduce the problem with the ESX Tools installed, or reproduce the problem after uninstalling the open-vm-tools, etc.

Thanks for the opinion.  I haven't had the pleasure of dealing with 
VMWare support yet, even though we have a contract.  Nothing has gone 
wrong yet!  I just know that if it were some other companies' support 
I'd be told that installing open-vm-tools once on any guest invalidated 
my support contract :-)

> I think you'll be fine if you're willing to reproduce problems with the ESX Tools before calling support. And then, if you aren't able to reproduce the problem, file a bug here so we can see why the open-vm-tools might be responsible.

But of course!  I'm a rabid bug filer, even if I don't quite have the 
time to be a rabid bug fixer...

Cheers,

-- 
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: ege...@fe...

> So does this mean that if I run them on *any* guest in my cluster, and
> something goes wrong, VMWare won't help me?  Or is it just the case that
> if I say "my guest OS is broken,
> and-by-the-way-I'm-running-open-vm-tools" they'll tell me to go away?
>
> I guess what I'm wondering is would I be likely to get support if:
>
> - I was running open-vm-tools most of the time
> - a problem occurred
> - I switched to ESX Tools and confirmed the problem still existed
> - *then* called support?

I honestly don't know, and I think a lot of is done by ear. So you'll call them and describe your problem, and if it's something to do with the guest they might ask you what version of Tools you're running, and then you'll tell them you're using the open-vm-tools, and they might try to help you anyway, or they may ask you to reproduce the problem with the ESX Tools installed, or reproduce the problem after uninstalling the open-vm-tools, etc.

I think you'll be fine if you're willing to reproduce problems with the ESX Tools before calling support. And then, if you aren't able to reproduce the problem, file a bug here so we can see why the open-vm-tools might be responsible.

Thanks Adar,

Adar Dembo wrote:
> [snipped a bunch of incredibly useful answers]
> 
> 4) The ESX 3.5 Tools are supported by VMware when used in conjunction
> with ESX 3.5 hosts. If it's important to you to get quick support
> from VMware's support organization, you have no choice but to use the
> ESX 3.5 Tools. The level of support you'll get from the open-vm-tools
> is going to be "best-effort", meaning, whomever responds to e-mails
> like these, bug reports on Sourceforge, and bug reports in the Debian
> package.

So does this mean that if I run them on *any* guest in my cluster, and
something goes wrong, VMWare won't help me?  Or is it just the case that 
if I say "my guest OS is broken, 
and-by-the-way-I'm-running-open-vm-tools" they'll tell me to go away?

I guess what I'm wondering is would I be likely to get support if:

- I was running open-vm-tools most of the time
- a problem occurred
- I switched to ESX Tools and confirmed the problem still existed
- *then* called support?

Cheers,

-- 
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: ege...@fe...

Hello, I'm running VMWare Fusion 2 beta and trying to get
open-vm-tools installed in a Fedora 9 VM.

I first tried the download on the main page but ran into the
procps header problem, so I rebuilt the Fedora 8 RPM at
http://www.poolshark.org/dkms-open-vm-tools/
dkms-open-vm-tools-0-1.2008.05.15.fc8.src.rpm	

It seemed to work fine and shows up in "dkms status"...
but I still get "VMware Tools is not installed."  and
copy/paste does not work. Should it?

By the way, Fedora 10 is nearing beta so it would be
great to get this working there too. It's pretty easy for
me to build a livecd iso from the devel tree so if anyone
wants to play with it let me know and I'll put up a
download of a livecd that includes dev tools.

Or, if you're running Fedora, you can build a custom devel
livecd easily by following these instructions:
http://spevack.livejournal.com/31634.html

> I'm setting up an ESX box and since I'm going to have a number of
> Debian
> servers on it I'd prefer to use the open-vm-tools to the VMWare ESX
> Tools.  It's just so much easier to upgrade.
>
> However, having not used the open-vm-tools before, I'm interested to
> know what the practical differences are.  Is there any advantage to
> using the ESX version of the tools?

Fundamentally speaking there is no difference between the ESX 3.5 Tools (I presume you're using ESX 3.5) and the open-vm-tools; both represent snapshots of the same code base taken at different points in time. That said, there are a few practical differences:

1) The ESX 3.5 Tools contain a few components that haven't been open-sourced, namely the vmdesched module and the Tools auto-upgrader. The former is experimental and generally useless to 99.9% of customers, and the latter isn't useful in the open-vm-tools, so it's unlikely that you'll care about these.
2) The ESX 3.5 Tools, as far as I know, don't have a Debian package. So your installation experience will likely be less pleasant than if you used the open-vm-tools Debian package.
3) The ESX 3.5 Tools are, at this point in time, quite a bit older than the open-vm-tools. The open-vm-tools code base reflects our top-of-tree, usually off by a month at most. The ESX 3.5 Tools branched from the top-of-tree almost two years ago.
4) The ESX 3.5 Tools are supported by VMware when used in conjunction with ESX 3.5 hosts. If it's important to you to get quick support from VMware's support organization, you have no choice but to use the ESX 3.5 Tools. The level of support you'll get from the open-vm-tools is going to be "best-effort", meaning, whomever responds to e-mails like these, bug reports on Sourceforge, and bug reports in the Debian package.

Hi,

I'm setting up an ESX box and since I'm going to have a number of Debian 
servers on it I'd prefer to use the open-vm-tools to the VMWare ESX 
Tools.  It's just so much easier to upgrade.

However, having not used the open-vm-tools before, I'm interested to 
know what the practical differences are.  Is there any advantage to 
using the ESX version of the tools?

Thanks in advance for the help!

Cheers,

-- 
Eric Gerlach, Network Administrator
Federation of Students
University of Waterloo
p: (519) 888-4567 x36329
e: ege...@fe...

> I want to install Open VM Tools BUT do I install them on the Ubuntu host
> that is running VMware or in the Ubuntu client?

The Tools are supposed to be installed in the client (or in our terminology, the "guest"). That would be Ubuntu Hardy, in your case.

When you tried to install Tools from the VM menu, what happened? Did you see an error of some kind? If not, check the CD-ROM device in the guest. The "Install Tools" option will just mount the Tools ISO image in the guest's CD-ROM drive, and after that you'll need to continue the installation manually within the guest by accessing the CD-ROM drive.

This seems a silly question BUT I am running VMware on an Ubuntu gutsy 
host and have a Ubuntu hardy quest vm.

Attempts to install the vmware tools from the VM menu selection failed.

I want to install Open VM Tools BUT do I install them on the Ubuntu host 
that is running VMware or in the Ubuntu client?

Thanks
R.Parr, RHCE, TemporalArts

Ryan,

	Thank you for the patched file!
This fixed the "Shrink" tab option for FreeBSD 7!

FreeBSD Ports is one revision behind.
They have open-vm-tools-2008.05.02-90473
Open VM Tools is up to: open-vm-tools-2008.07.01-102166.tar.gz

FreeBSD Ports needs to update to the latest:
open-vm-tools-2008.07.01-102166.tar.gz
AND
Replace
/usr/ports/emulators/open-vm-tools/work/open-vm-tools-2008.05.02-90473/lib/w
iper/wiperPosix.c
with this file wiperPosix.c 
(file is attached for others who may need this, you need to unzip it via
gzip -d wiperPosix.c.gz)

This would bring FreeBSD Ports up to date for open-vm-tools on FreeBSD 7 and
fixes the "Shrink" tab option.

My hope is that the Open Virtual Machine Tools team will add this patch
permanently going forward
And
That the FreeBSD committer for the open-vm-tools port will update to the
latest and use the patched wiperPosix.c

Thank you,

Ernie Wilson
www.N3NCY.com

-----Original Message-----
From: Ryan Beasley [mailto:rbe...@vm...] 
Sent: Friday, July 04, 2008 2:29 PM
To: Ern...@gm...
Subject: Re: [open-vm-tools-discuss] vmware-toolbox Shrink partition on
FreeBSD 7?

Ernest G. Wilson II wrote:
> Ryan,
> 
>         Do you have a patch that works with current open vm tools?
> open-vm-tools-2008.07.01-102166
> 

Hi, Ernie,

Thanks for trying this out.  Sorry it didn't work.  (You didn't copy & 
paste the patch contents from your mail client to a file, did you?  ;).)

The patch against 102166 is identical to the original that I generated 
against 101911.  In addition, I have no trouble applying the original 
patch to 102166 in a FreeBSD 7.0 VM with the system's original patch(1) 
2.1.  :/

In the interest of saving you some time, I'm attaching a locally patched 
version.  Hope this helps.

And, again, thanks for reporting this.  If you notice other things not 
working as they should, don't hesitate to let us know.

> rbeasley@rbeasley-bsd7-1 tmp> date
> Fri Jul  4 11:20:51 PDT 2008
> rbeasley@rbeasley-bsd7-1 tmp> uname -srm
> FreeBSD 7.0-RELEASE i386
> rbeasley@rbeasley-bsd7-1 tmp> patch -v
> Patch version 2.1
> rbeasley@rbeasley-bsd7-1 tmp> patch
open-vm-tools-2008.07.01-102166/lib/wiper/wiperPosix.c
~/patches/ovt-bsdversion-lib_wiper_wiperPosix.c.patch 
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |diff -ru open-vm-tools-e.x.p-101911/lib/wiper/wiperPosix.c
open-vm-tools-e.x.p-00000/lib/wiper/wiperPosix.c
> |--- open-vm-tools-e.x.p-101911/lib/wiper/wiperPosix.c  2008-06-30
09:45:56.000000000 -0700
> |+++ open-vm-tools-e.x.p-00000/lib/wiper/wiperPosix.c   2008-07-02
16:29:21.000000000 -0700
> --------------------------
> Patching file open-vm-tools-2008.07.01-102166/lib/wiper/wiperPosix.c using
Plan A...
> Hunk #1 succeeded at 36.
> Hunk #2 succeeded at 210.
> Hunk #3 succeeded at 246.
> done

-- 
Ryan Beasley <rbe...@vm...>

2007	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (6)	Oct (6)	Nov	Dec
2008	Jan (7)	Feb	Mar	Apr	May (4)	Jun (2)	Jul (4)	Aug (2)	Sep (18)	Oct (5)	Nov (13)	Dec (14)
2009	Jan (9)	Feb (14)	Mar (8)	Apr (9)	May (28)	Jun (10)	Jul (1)	Aug (16)	Sep (10)	Oct	Nov (2)	Dec
2010	Jan (2)	Feb (21)	Mar (11)	Apr (8)	May (1)	Jun	Jul (23)	Aug (11)	Sep	Oct (12)	Nov	Dec (6)
2011	Jan	Feb (1)	Mar (4)	Apr (2)	May (2)	Jun (4)	Jul (4)	Aug (2)	Sep	Oct (7)	Nov	Dec (9)
2012	Jan (4)	Feb (5)	Mar (2)	Apr	May	Jun (1)	Jul (1)	Aug	Sep	Oct	Nov (3)	Dec
2013	Jan	Feb	Mar (7)	Apr	May	Jun	Jul (4)	Aug	Sep (5)	Oct (1)	Nov	Dec
2014	Jan (1)	Feb (3)	Mar (3)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun (2)	Jul	Aug (6)	Sep	Oct	Nov	Dec (2)
2016	Jan (1)	Feb	Mar (9)	Apr (3)	May (1)	Jun (4)	Jul	Aug (1)	Sep	Oct	Nov	Dec
2017	Jan (2)	Feb	Mar (1)	Apr (3)	May	Jun	Jul (1)	Aug	Sep	Oct	Nov (1)	Dec (1)
2018	Jan	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2020	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (2)	Nov	Dec

open-vm-tools-discuss Mailing List for open-vm-tools (Page 13)

open-vm-tools-discuss — For general project discussions. Use the developer list for technical discussion.