open-vm-tools-devel — List for open-vm-tools developer discussions.

Re: How do I specify different action for halt and reboot in open vm tools?

[James <jim...@te...>]

Hi Marcelo,

I'm trying to have a clean shutdown with reboot or power off
depending on what's called from VMtools.  The problem is this
is for trying to virtualize an existing custom linux setup
with it's own shutdown programs and scripts that make the call
to power off or reboot.

I see that I should instead let vmtools make the power off
or reboot call after all power-off scripts are run.

Thanks,
James


On 28-Jun-10 13:36 Marcelo Vanzin wrote:
> Hi James,
>
> On 06/24/2010 07:22 PM, James wrote:
>> Of course I also see that I can just add custom user scripts to
>> the /etc/vmware-tools/scripts/poweroff-vm-default.d/ directory
>> and that is just what I'm doing now.  The problem of course is that
>> if my script does the power off at the end the reboot doesn't happen,
>> and if my script just completes a shutdown and then halts the
>> power is not "turned off".
>
> What exactly are you trying to achieve here?
>
> If you're just trying to run different things depending on whether power off or
> reboot is happening, you're better off using the OS's own init/upstart/whatever
> for it and not use open-vm-tools.
>
> If you're tying to make sure the VM powers off when you shut down the VM from
> the VMware UI, you may want to look at lib/system/systemLinux.c;
>   currently it executes "shutdown -h" to shut down the VM, but I've seen cases
> where that doesn't really turn the power off (you'd need "shutdown -P" for those).
>

Re: How do I specify different action for halt and reboot in open vm tools?

[Marcelo V. <mv...@vm...>]

Hi James,

On 06/24/2010 07:22 PM, James wrote:
> Of course I also see that I can just add custom user scripts to
> the /etc/vmware-tools/scripts/poweroff-vm-default.d/ directory
> and that is just what I'm doing now.  The problem of course is that
> if my script does the power off at the end the reboot doesn't happen,
> and if my script just completes a shutdown and then halts the
> power is not "turned off".

What exactly are you trying to achieve here?

If you're just trying to run different things depending on whether power off or
reboot is happening, you're better off using the OS's own init/upstart/whatever
for it and not use open-vm-tools.

If you're tying to make sure the VM powers off when you shut down the VM from
the VMware UI, you may want to look at lib/system/systemLinux.c;
 currently it executes "shutdown -h" to shut down the VM, but I've seen cases
where that doesn't really turn the power off (you'd need "shutdown -P" for those).

-- 
- Marcelo

Re: How do I specify different action for halt and reboot in open vm tools?

[Ryan B. <rbe...@vm...>]

On 06/24/2010 07:22 PM, James wrote:
> On looking at the documentation for older vmware-guestd it shows
> the option of specifying different commands for halt and reboot.
>
>> /etc/vmware/vmware-guestd --halt-command<command>
>> where<command>  is the command to execute when ESX Server asks the guest service to halt the guest operating system.
>> /etc/vmware/vmware-guestd --reboot-command<command>
>> where<command>  is the command to execute when ESX Server asks the guest service to reboot the guest operating system.
>
> This is done in the /etc/vmware/dualconf.vm startup script.
>
> I can't find anything about dualconf.vm in open-vm-tools and the two options
> above are not even available for vmtoolsd.
>
> I figured out that I can specify custom poweron-script, resume-script,
> suspend-script, and poweroff-script in the [powerops] group of tools.conf
> but the only arguments to these scripts is the powerop type.  Looking
> at the source code I found some reference to halt and reboot but they
> both end up pointing to the same poweroff script.
>
> Of course I also see that I can just add custom user scripts to
> the /etc/vmware-tools/scripts/poweroff-vm-default.d/ directory
> and that is just what I'm doing now.  The problem of course is that
> if my script does the power off at the end the reboot doesn't happen,
> and if my script just completes a shutdown and then halts the
> power is not "turned off".

James,

As the code is written, you're out of luck.  For better or worse, reboot and 
power off have been handled identically since ... forever.

If you want to hack it yourself, you can probably get away with the following:

"Correct" way:
- Add appropriate CONFNAME_REBOOTSCRIPT and CONFVAL_REBOOTSCRIPT_DEFAULT macros 
to conf.h.
- Change CONFNAME_POWEROFFSCRIPT to CONFNAME_REBOOTSCRIPT in powerOps.c for the 
reboot case.
- Define your own handler for "reboot-vm".

Quick'n'dirty way:
- Hack System_Shutdown in systemLinux.c.

Hope this helps.

-- 
Ryan Beasley :: MTS, Guest Components - Applications :: VMware, Inc.

How do I specify different action for halt and reboot in open vm tools?

[James <jim...@te...>]

On looking at the documentation for older vmware-guestd it shows
the option of specifying different commands for halt and reboot.

> /etc/vmware/vmware-guestd --halt-command <command>
> where <command> is the command to execute when ESX Server asks the guest service to halt the guest operating system.
> /etc/vmware/vmware-guestd --reboot-command <command>
> where <command> is the command to execute when ESX Server asks the guest service to reboot the guest operating system.

This is done in the /etc/vmware/dualconf.vm startup script.

I can't find anything about dualconf.vm in open-vm-tools and the two options
above are not even available for vmtoolsd.

I figured out that I can specify custom poweron-script, resume-script,
suspend-script, and poweroff-script in the [powerops] group of tools.conf
but the only arguments to these scripts is the powerop type.  Looking
at the source code I found some reference to halt and reboot but they
both end up pointing to the same poweroff script.

Of course I also see that I can just add custom user scripts to
the /etc/vmware-tools/scripts/poweroff-vm-default.d/ directory
and that is just what I'm doing now.  The problem of course is that
if my script does the power off at the end the reboot doesn't happen,
and if my script just completes a shutdown and then halts the
power is not "turned off".

James

RE: Is it possible to access VMware clock ticks backlog from the Open VMware Tools?

[Vlasov, V. <vv...@me...>]

Hi Dmitry.

Telling "embedded backlog" I mean some kind of buffer which holds
undelivered clock ticks.
This is not related to VMware Tools, it is part of VMware and works even
if tools are not installed.

I think you know it better than me that VMware Workstation virtualizes
clock devices and delivers it's ticks to guest OS. If OS is busy that
delivery can be delayed and stored to so called backlog. Then backlog
will be catched up as quick as possible.

So, I'm asking about this internal buffer, is it available for tools?
Is there any interface to it?

I'm writing simplified sync daemon which contains interface to VMware
backdoor only and would like to track backlog too in order to don't
allow oversync.

Best regards
Vladimir Vlasov
 -----Original Message-----
 From: Dmitry Torokhov [mailto:dt...@vm...] 
 Sent: Thursday, June 17, 2010 8:42 PM
 To: Vlasov, Vladimir
 Cc: ope...@li...
 Subject: Re: Is it possible to access VMware clock ticks backlog from
the Open VMware Tools?

 Hi Vladimir,

 On Monday, June 14, 2010 09:44:05 pm Vlasov, Vladimir wrote:
 > Hi.
 > 
 > VMware has embedded backlog for delayed clock ticks so guest can
catch up
 > after starvation. Is there any way to access this backlog from the
Open
 > VMware Tools?
 > 
 > Tools contain guestd which can sync guest to host and I think it
should
 > have such access in order to sync properly. I downloaded source and
tried
 > to find something but failed.
 > I'll try better but may be someone already know something regarding
subj?
 > 

 I am not sure what you mean by "embedded backlog". The timeSync plug-in
in mmtoolsd (residing in services/plugins/timeSync/) implements the 
 synchronization algorithm. It basically queries host for current time
and > then slows down or speeds up guest clock to get back in sync with
the host.

You can enable and disable time synchronization via vmware-toolbox or
vmware-toolbox-cmd.

I hope this answered your question.

Thanks,
Dmitry

Re: Is it possible to access VMware clock ticks backlog from the Open VMware Tools?

[Dmitry T. <dt...@vm...>]

Hi Vladimir,

On Monday, June 14, 2010 09:44:05 pm Vlasov, Vladimir wrote:
> Hi.
> 
> VMware has embedded backlog for delayed clock ticks so guest can catch up
> after starvation. Is there any way to access this backlog from the Open
> VMware Tools?
> 
> Tools contain guestd which can sync guest to host and I think it should
> have such access in order to sync properly. I downloaded source and tried
> to find something but failed.
> I'll try better but may be someone already know something regarding subj?
> 

I am not sure what you mean by "embedded backlog". The timeSync plug-in in 
vmtoolsd (residing in services/plugins/timeSync/) implements the 
synchronization algorithm. It basically queries host for current time and then 
slows down or speeds up guest clock to get back in sync with the host.

You can enable and disable time synchronization via vmware-toolbox or vmware-
toolbox-cmd.

I hope this answered your question.

Thanks,
Dmitry

Is it possible to access VMware clock ticks backlog from the Open VMware Tools?

[Vlasov, V. <vv...@me...>]

Hi.

VMware has embedded backlog for delayed clock ticks so guest can catch
up after starvation.
Is there any way to access this backlog from the Open VMware Tools?

Tools contain guestd which can sync guest to host and I think it should
have such access in order to sync properly.
I downloaded source and tried to find something but failed.
I'll try better but may be someone already know something regarding
subj?

 

Best regards

Vladimir Vlasov

 

Re: cross compiling vmtools and installing?

[Ryan B. <rbe...@vm...>]

On 06/09/2010 02:02 PM, Marcelo Vanzin wrote:
>
> procps is used to collect information about processes and their resource usage.
> I'm not really sure what features currently use that information.
>

procps is used to extract guest memory statistics, which the Tools then publish 
(ultimately) to the vmkernel on vSphere 4.  Said stats are used in 
debugging/support instrumentation and may influence VMK memory management decisions.

It doesn't provide anything useful to customers running under Workstation or Fusion.

-- 
Ryan Beasley :: MTS, Guest Components - Applications :: VMware, Inc.

Re: cross compiling vmtools and installing?

[Marcelo V. <mv...@vm...>]

Hi James,

On 06/08/2010 11:38 AM, James wrote:
> What are the features I get by enabling procps and libdnet support?
> What would I be missing if I do not have them?
>
> I have added procps and libdnet to my build but I don't see any
> difference in my vSphere client.

libdnet is used to collect information about the guest's network configuration. 
This can be seen in the VM's summary pane in the vSphere client, where the VM's 
IP addresses (along other information) are listed. It is also used for some 
features like wake-on-lan support, IIRC.

procps is used to collect information about processes and their resource usage. 
I'm not really sure what features currently use that information.

-- 
- Marcelo

Re: cross compiling vmtools and installing?

[James <jim...@te...>]

What are the features I get by enabling procps and libdnet support?
What would I be missing if I do not have them?

I have added procps and libdnet to my build but I don't see any
difference in my vSphere client.

James


On 24-May-10 11:47 Marcelo Vanzin wrote:
> Hi James,
>
> On 05/22/2010 07:17 PM, James wrote:
>> After installing and starting it I get a number of warnings
>> about /etc/redhat-release, /etc/redhat-version etc type files not found.
>> There were different ones for various distributions but I have
>> a 2.6.23 kernel from scratch.
>> Google couldn't tell me anything about what should be in those files
>> so I created the redhat versions of them and added a version number
>> string
>> of "5.4" to it.
>
> The easiest way to get rid of those warnings is to have a working
> "lsb_release" executable in your system. The code will first try to
> execute "lsb_release -sd" and then fall back to looking at a bunch of
> release files (for compatibility with older distributions).
>
> Here's a sample output from my Ubuntu box:
>
> $ lsb_release -sd
> Ubuntu 10.04 LTS
>
>> This seems to have silenced those warnings but I still get [guestinfo]
>> warnings "Failed to get vmstats" and "Failed to get nic info".
>
> The vmstats warning might be because you did not compile with procps
> support. The warning is a little too strong in that case (and we should
> probably make it less so), but you don't need to worry about it if
> that's the case.
>
> The 'nic info' warning is similarly explained if you didn't compile with
> libdnet support. Same thing, if that's the case, no need to worry,
> although I understand the warning is annoying. :-)
>

[ open-vm-tools-Tracker-3009525 ] fedora13 x64: make fails: symbol 'dlsym@@GLIBC_2.2.5'

[SourceForge.net <no...@so...>]

Tracker item #3009525, was opened at 2010-05-31 15:42
Message generated for change (Tracker Item Submitted) made by vbadziong
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3009525&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libraries
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Volker Badziong (vbadziong)
Assigned to: Nobody/Anonymous (nobody)
Summary: fedora13 x64: make fails: symbol 'dlsym@@GLIBC_2.2.5'

Initial Comment:
Hello,

running make on fedora 13 x64 fails with the follwing error:

...
/usr/bin/ld: ../lib/auth/.libs/libAuth.a(authPosix.o): undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
/usr/bin/ld: note: 'dlsym@@GLIBC_2.2.5' is defined in DSO /lib64/libdl.so.2 so try adding it to the linker command line
/lib64/libdl.so.2: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[1]: *** [vmware-user] Error 1
make[1]: Leaving directory `/home/user/Downloads/open-vm-tools-2010.04.25-253928/vmware-user'
make: *** [all-recursive] Error 1

This can be fixed with setting LIBS prior to running configure:

export LIBS=-ldl
./configure 

Is this a fedora 13 error or related to open vm tools?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3009525&group_id=204462

[ open-vm-tools-Tracker-3009522 ] fedora13: configure error: libproc not found (lib64/3.2.8)

[SourceForge.net <no...@so...>]

Tracker item #3009522, was opened at 2010-05-31 15:37
Message generated for change (Tracker Item Submitted) made by vbadziong
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3009522&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libraries
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Volker Badziong (vbadziong)
Assigned to: Nobody/Anonymous (nobody)
Summary: fedora13: configure error: libproc not found (lib64/3.2.8)

Initial Comment:
Hello,

trying to run ./configure on fedora 13 x64 yields the following error message:

...
checking for ecvt... yes
checking for fcvt... yes
checking for pthread_mutex_init in -lpthread... yes
checking for getstat in -lproc... no
checking for getstat in -lproc-3.2.7... no
configure: error: libproc not found. Please configure without procps (using --without-procps) or install procps - http://procps.sourceforge.net

....although "libproc-3.2.8.so" is installed below /lib64/.

Adding the following symbolic link fixes the issue, ./configure works afterwards...

# ln -s /lib64/libproc-3.2.8.so /lib/libproc.so


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3009522&group_id=204462

Re: cross compiling vmtools and installing?

[Marcelo V. <mv...@vm...>]

Hi James,

On 05/22/2010 07:17 PM, James wrote:
> After installing and starting it I get a number of warnings
> about /etc/redhat-release, /etc/redhat-version etc type files not found.
> There were different ones for various distributions but I have
> a 2.6.23 kernel from scratch.
> Google couldn't tell me anything about what should be in those files
> so I created the redhat versions of them and added a version number string
> of "5.4" to it.

The easiest way to get rid of those warnings is to have a working "lsb_release" 
executable in your system. The code will first try to execute "lsb_release -sd" 
and then fall back to looking at a bunch of release files (for compatibility 
with older distributions).

Here's a sample output from my Ubuntu box:

$ lsb_release -sd
Ubuntu 10.04 LTS

> This seems to have silenced those warnings but I still get [guestinfo]
> warnings "Failed to get vmstats" and "Failed to get nic info".

The vmstats warning might be because you did not compile with procps support. 
The warning is a little too strong in that case (and we should probably make it 
less so), but you don't need to worry about it if that's the case.

The 'nic info' warning is similarly explained if you didn't compile with libdnet 
support. Same thing, if that's the case, no need to worry, although I understand 
the warning is annoying. :-)

-- 
- Marcelo

Re: cross compiling vmtools and installing?

[James <jim...@te...>]

Thanks Marcelo.  Your instructions worked well.

I have some further questions for you or anyone else on the list.

After installing and starting it I get a number of warnings
about /etc/redhat-release, /etc/redhat-version etc type files not found.
There were different ones for various distributions but I have
a 2.6.23 kernel from scratch.
Google couldn't tell me anything about what should be in those files
so I created the redhat versions of them and added a version number string
of "5.4" to it.
This seems to have silenced those warnings but I still get [guestinfo]
warnings "Failed to get vmstats" and "Failed to get nic info".

I'm guessing the previous two files tells guestinfo how to retrieve
the latter guestinfo.

What /etc/<dist>-release /etc/<dist>_version should I use or emulate?
What do I put in those files?  How do I resolve the guestinfo warnings?

If there is a FM to read or even code pointers to help me sort this out
I would appreciate getting pointed in the right direction.

Thanks,
James



On 20-May-10 11:32 Marcelo Vanzin wrote:
> Hi James,
>
> On 05/19/2010 02:41 PM, James wrote:
>> I am trying to cross compile the open vmware tools package
>> and have it added to the target directory tree. The linux target will
>> not have gcc and other build tools available. The target will
>> also be console only with no X features.
>>
>> I am able to get make to finish (after a few minor changes).
>>
>> I see that vmtoolsd is a wrapper script which does something
>> with libtool libraries but it's not clear what that is exactly.
>> I copied the .libs/vmtoolsd to the target and the services/plugins
>
> That file is the intermediate output generated by libtool (AFAIK). To
> get the final binaries you need to run "make install".
>
> You can use DESTDIR (as in "make install DESTDIR=/some/temp/dir") to
> install things into a temp directory, and then copy the binaries from
> there. I recommend configuring with "--without-root-privileges" when
> doing that.
>

RE: open-vm-tools commitment by VMware

[Adar D. <ad...@vm...>]

> This is nothing new.  From day one open-vm-tools has not been supported 
> by VMware.  What this means is that open-vm-tools doesn't go through 
> VMware's normal QA and release cycle, and thus if you call up to VMware 
> support with a problem with open-vm-tools, they won't help you.
> 
> However, VMware is funding the development of open-vm-tools, and taking 
> some (if not all) of the improvements made in open-vm-tools to help 
> improve the official VMware Tools offering.  In other words, 
> open-vm-tools is a open source development release, nothing more, 
> nothing less.

Yes, Sean has it exactly right: open-vm-tools is an open source development project whose code is slurped up into official VMware Tools releases. Because open-vm-tools can be customized and built in so many different ways, and because we can't conceivably test all of those configurations, we can't support the code itself. But we can and do support the official VMware Tools, whose code is effectively the same as the open-vm-tools (albeit less bleeding edge, since it has gone through a product stabilization cycle).

In the referenced Novell bug report, John was alluding to the potential confusion that the lack of supportability brings to VMware users. He was arguing that by automating the installation of open-vm-tools on all VMware images, users are now automatically getting a configuration that VMware can't support, and may not know how to "opt-out" of open-vm-tools and "opt-in" to the official VMware Tools. Different users will make different choices if asked to choose between Tools that are supported and Tools that will work out of the box; the installation media shouldn't force one choice.

Of course, the ideal situation would be for the installed Tools to both work out of the box AND be supported. We've been remiss about discussing exactly what we're planning, but we're going to release some more information when it's done.

Re: cross compiling vmtools and installing?

[Marcelo V. <mv...@vm...>]

Hi James,

On 05/19/2010 02:41 PM, James wrote:
> I am trying to cross compile the open vmware tools package
> and have it added to the target directory tree.  The linux target will
> not have gcc and other build tools available.  The target will
> also be console only with no X features.
>
> I am able to get make to finish (after a few minor changes).
>
> I see that vmtoolsd is a wrapper script which does something
> with libtool libraries but it's not clear what that is exactly.
> I copied the .libs/vmtoolsd to the target and the services/plugins

That file is the intermediate output generated by libtool (AFAIK). To get the 
final binaries you need to run "make install".

You can use DESTDIR (as in "make install DESTDIR=/some/temp/dir") to install 
things into a temp directory, and then copy the binaries from there. I recommend 
configuring with "--without-root-privileges" when doing that.

-- 
- Marcelo

cross compiling vmtools and installing?

[James <jim...@te...>]

Hello,

I am trying to cross compile the open vmware tools package
and have it added to the target directory tree.  The linux target will
not have gcc and other build tools available.  The target will
also be console only with no X features.

I am able to get make to finish (after a few minor changes).

I see that vmtoolsd is a wrapper script which does something
with libtool libraries but it's not clear what that is exactly.
I copied the .libs/vmtoolsd to the target and the services/plugins

Can anyone provide some guidance on what needs to be
copied from the build tree to the target directories?

Thanks,
James

Re: open-vm-tools commitment by VMware

[Dominique L. <Dom...@TM...>]

>>> On 5/10/2010 at 15:43, Sean Dilda <se...@du...> wrote: 
> This is nothing new.  From day one open-vm-tools has not been supported 
> by VMware.  What this means is that open-vm-tools doesn't go through 
> VMware's normal QA and release cycle, and thus if you call up to VMware 
> support with a problem with open-vm-tools, they won't help you.
> 
> However, VMware is funding the development of open-vm-tools, and taking 
> some (if not all) of the improvements made in open-vm-tools to help 
> improve the official VMware Tools offering.  In other words, 
> open-vm-tools is a open source development release, nothing more, 
> nothing less.

Yes, this is correct: the troublesome words in the statement is the more or less 'official' suggestion to remove the open-vm-tools from the
distribution. The support itself, well that is ok, and worked fine in the past.

Dominique

Re: open-vm-tools commitment by VMware

[Sean D. <se...@du...>]

This is nothing new.  From day one open-vm-tools has not been supported 
by VMware.  What this means is that open-vm-tools doesn't go through 
VMware's normal QA and release cycle, and thus if you call up to VMware 
support with a problem with open-vm-tools, they won't help you.

However, VMware is funding the development of open-vm-tools, and taking 
some (if not all) of the improvements made in open-vm-tools to help 
improve the official VMware Tools offering.  In other words, 
open-vm-tools is a open source development release, nothing more, 
nothing less.

On 5/7/10 7:27 AM, Dominique Leuenberger wrote:
> Hi everybody,
>
> As this message is in a public tracker I do not see any reason why I should not be allowed to forward this message from vmware directly (original
> reference: https://bugzilla.novell.com/show_bug.cgi?id=591085 )
>
>>>> On 5/6/2010 at 20:34,<bug...@no...>  wrote:
>> --- Comment #4 from John Savanyo<jsa...@vm...>  2010-05-06 18:34:31 UTC
>> ---
>> Actually, VMware does not officially support these open-vm-tools, so we
>> recommend that you remove them from the distro. VMware distributes tools and
>> source code for drivers with each VMware product release that are intended
>> for
>> use with that particular combination of OS release and hypervisor.
>>
>> You should also be aware that we are in the process of upstreaming our
>> kernel
>> drivers and expect them to be included in the base kernel. This will
>> eliminate
>> the need for users to hassle with building and installing drivers. The
>> vmxnet3
>> virtual NIC was in 2.6.32, the vmw_pvscsi virtual HBA was in 2.6.33 and the
>> balloon driver (vmmemctl) has been accepted recently into 2.6.34. The
>> vmxnet3
>> and vmw_pvscsi should already be in 11.3 and hopefully vmmemctl will be in
>> milestone7.
>
> I'm sure other distro-packagers are interested in this view of vmware regarding the open-vm-tools as well. It almost sounds like a commitment to let
> them die, which would be a pity (current ouf-of-box experience in a vmware guest is rather good: it 'just works(tm)' )
>
> I call the discussion open! Are other packers considering to drop the tools? What's there purpose of existence if we're not supposed to ship them to
> our users?
>
> Best regards
> Dominique
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel

Re: open-vm-tools commitment by VMware

[Joshua D. F. <jdf...@gm...>]

On Fri, May 7, 2010 at 4:27 AM, Dominique Leuenberger wrote:
> As this message is in a public tracker I do not see any reason why I should not be allowed to forward this message from vmware directly (original
> reference: https://bugzilla.novell.com/show_bug.cgi?id=591085 )
>
>>>> On 5/6/2010 at 20:34, wrote:
>> --- Comment #4 from John Savanyo @vmware.com 2010-05-06 18:34:31 UTC
>> ---
>> Actually, VMware does not officially support these open-vm-tools, so we
>> recommend that you remove them from the distro. VMware distributes tools and
>> source code for drivers with each VMware product release that are intended
>> for
>> use with that particular combination of OS release and hypervisor.

Remove open-vm-tools? Let's see how well VMWare is doing with keeping the
"official" VMWare Tools updated for new OS releases, such as Ubuntu 10.04 Lucid:

http://www.google.com/search?hl=en&q=+site:communities.vmware.com+"VMware+tools"+lucid

open-vm-tools isn't flawless on Ubuntu Lucid but at least it works! If I ever
need official VMWare support for a vm I'll reproduce the problem with
officially supported software. No need to remove working code from distros.


>> You should also be aware that we are in the process of upstreaming

That seems to be the main point of the open-vm-tools project and it's a
wonderful goal. But why in the world would any OS not ship the code in the
meantime which does "eliminate the need for users to hassle with building
and installing drivers" (well, most of the hassle).


>  It almost sounds like a commitment to let
> them die, which would be a pity (current ouf-of-box experience in a vmware guest is rather good: it 'just works(tm)' )

I wouldn't say that, more like a commitment to continue pushing the
bleeding edge. For example, from the "open-vm-tools 2010.04.25 release"
announcement:

* The pvscsi driver was removed from the open-vm-tools distribution (it
        is upstream as of Linux 2.6.33).

http://sourceforge.net/mailarchive/message.php?msg_name=4BD72B8B.2020200%40vmware.com

open-vm-tools commitment by VMware

[Dominique L. <Dom...@TM...>]

Hi everybody,

As this message is in a public tracker I do not see any reason why I should not be allowed to forward this message from vmware directly (original
reference: https://bugzilla.novell.com/show_bug.cgi?id=591085 )

>>> On 5/6/2010 at 20:34, <bug...@no...> wrote: 
> --- Comment #4 from John Savanyo <jsa...@vm...> 2010-05-06 18:34:31 UTC 
> ---
> Actually, VMware does not officially support these open-vm-tools, so we
> recommend that you remove them from the distro. VMware distributes tools and
> source code for drivers with each VMware product release that are intended 
> for
> use with that particular combination of OS release and hypervisor. 
> 
> You should also be aware that we are in the process of upstreaming our 
> kernel
> drivers and expect them to be included in the base kernel. This will 
> eliminate
> the need for users to hassle with building and installing drivers. The 
> vmxnet3
> virtual NIC was in 2.6.32, the vmw_pvscsi virtual HBA was in 2.6.33 and the
> balloon driver (vmmemctl) has been accepted recently into 2.6.34. The 
> vmxnet3
> and vmw_pvscsi should already be in 11.3 and hopefully vmmemctl will be in
> milestone7.

I'm sure other distro-packagers are interested in this view of vmware regarding the open-vm-tools as well. It almost sounds like a commitment to let
them die, which would be a pity (current ouf-of-box experience in a vmware guest is rather good: it 'just works(tm)' )

I call the discussion open! Are other packers considering to drop the tools? What's there purpose of existence if we're not supposed to ship them to
our users?

Best regards
Dominique 

Git down?

[Ira C. <vm...@ir...>]

Is git down right now or is it just me unable to clone?

git clone git://git.opensource.vmware.com/opensource/open-vm-tools/
Initialized empty Git repository in /root/open-vm-tools/.git/
fatal: read error: Connection reset by peer


-Ira

[ open-vm-tools-Tracker-2994267 ] RpcChannel_Start and RpcChannel_Stop not defined

[SourceForge.net <no...@so...>]

Tracker item #2994267, was opened at 2010-04-29 09:56
Message generated for change (Comment added) made by dtor
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2994267&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libraries
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: mrbazmondo (barry-davis)
Assigned to: Nobody/Anonymous (nobody)
Summary: RpcChannel_Start and RpcChannel_Stop not defined

Initial Comment:
gcc version 3.4.3
glib-2.16.1
pkg-config-0.23
open-vm-tools-2010.04.25-253928
open-vm-tools-2010.03.20-243334

This line needs to be added to lib/rpcChannel/rpcChannel.c to get it to compile
#define G_IMPLEMENT_INLINES

Otherwise RpcChannel_Start and RpcChannel_Stop are not defined during link as they've only been declared external with no definition

----------------------------------------------------------------------

>Comment By: Dmitry Torokhov (dtor)
Date: 2010-05-04 09:37

Message:
I see. In this case you need to make sure that glib (and glibconfig.h) in
your distribution is set up properly to match the features that your
compiler supports - they should figure our the valid inlining syntax so
that we can simply use G_INLINE_FUNC without needing any custom flags.

Thanks.

----------------------------------------------------------------------

Comment By: mrbazmondo (barry-davis)
Date: 2010-05-04 02:38

Message:
A custom LFS based distribution. Let me know if there are any other package
versions you wish to know. Its also using glibc-2.3.4.

----------------------------------------------------------------------

Comment By: Dmitry Torokhov (dtor)
Date: 2010-04-29 10:05

Message:
What distribution is this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2994267&group_id=204462

[ open-vm-tools-Tracker-2994267 ] RpcChannel_Start and RpcChannel_Stop not defined

[SourceForge.net <no...@so...>]

Tracker item #2994267, was opened at 2010-04-29 16:56
Message generated for change (Comment added) made by barry-davis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2994267&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libraries
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: mrbazmondo (barry-davis)
Assigned to: Nobody/Anonymous (nobody)
Summary: RpcChannel_Start and RpcChannel_Stop not defined

Initial Comment:
gcc version 3.4.3
glib-2.16.1
pkg-config-0.23
open-vm-tools-2010.04.25-253928
open-vm-tools-2010.03.20-243334

This line needs to be added to lib/rpcChannel/rpcChannel.c to get it to compile
#define G_IMPLEMENT_INLINES

Otherwise RpcChannel_Start and RpcChannel_Stop are not defined during link as they've only been declared external with no definition

----------------------------------------------------------------------

>Comment By: mrbazmondo (barry-davis)
Date: 2010-05-04 09:38

Message:
A custom LFS based distribution. Let me know if there are any other package
versions you wish to know. Its also using glibc-2.3.4.

----------------------------------------------------------------------

Comment By: Dmitry Torokhov (dtor)
Date: 2010-04-29 17:05

Message:
What distribution is this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2994267&group_id=204462

[ open-vm-tools-Tracker-2994630 ] open-vm-tools release, panic trace

[SourceForge.net <no...@so...>]

Tracker item #2994630, was opened at 2010-04-30 10:38
Message generated for change (Comment added) made by holcapek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2994630&group_id=204462

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Holcapek (holcapek)
Assigned to: Nobody/Anonymous (nobody)
Summary: open-vm-tools release, panic trace

Initial Comment:
Yes, both vmxnet (Lance) and vmxnet3 are configured for the guest. And this time I attached the right file with the backtrace (picked the wrong one previously, as you have probably noticed). The backtrace is fomr another vmcore I captured, but it is the very same each time.

I\'m using open-vm-tools-2009.12.16-217847.tar.gz, which is, as I understand, the last release containing vmxnet3 (since it made it into upstream kernel recently and was removed from open-vm-toos).

----------------------------------------------------------------------

>Comment By: Jan Holcapek (holcapek)
Date: 2010-04-30 10:44

Message:
Sorry, this should have been attached to 2993559, which I have created
using Google account.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=2994630&group_id=204462