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

Re: [open-vm-tools-devel] RPM packages?

[Andrew B. <big...@vm...>]

Sean Dilda <se...@du...> wrote:
> For instance, I made the guess that 'vmblock' is used for
> drag-and-drop (something ESX users don't have to use).  However, its
> not clear to me if its used for anything else.

To answer just this question, vmblock is used for drag and drop and
file copy/paste in the host to guest direction.  The same module is
used on the host for the same features but in the guest to host
direction.  Neither of those features are available on ESX, as you
mentioned, and vmblock is not used for anything else.

Re: [open-vm-tools-devel] RPM packages?

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

Ragavan S wrote:
>> rPath Linux has open-vm-tools packaged and is shipping it enabled by
>> default on vmware flavors of the distro (and many users appliances).
>> Foresight Linux is coming soon.
> 
> I've started a wiki page to start keeping track of this information.
> http://open-vm-tools.wiki.sourceforge.net/Distro+Package+Status
> 

Thanks for keeping track of that.

> By the way, I am curious to see if you or the other packagers found
> the packaging guidelines doc helpful.
> http://open-vm-tools.wiki.sourceforge.net/Packaging
> 
> Are there any other pieces of information we can provide that would
> make your jobs easier?
> 

I did find the packaging page to be quite useful.  However, there are a 
couple pieces of extra information that would be useful.

For a lot of the components, I'm not really sure what they do, which 
makes it hard to know how to package them.  For instance, I made the 
guess that 'vmblock' is used for drag-and-drop (something ESX users 
don't have to use).  However, its not clear to me if its used for 
anything else.  Likewise, most of the other components don't have what 
they're used for specified.

I'd also like to note that the Packaging page references 
vmware-xferlogs, which isn't actually available in the source download.


Thanks,


Sean

Re: [open-vm-tools-devel] RPM packages?

[Ragavan S <rag...@gm...>]

> rPath Linux has open-vm-tools packaged and is shipping it enabled by
> default on vmware flavors of the distro (and many users appliances).
> Foresight Linux is coming soon.

I've started a wiki page to start keeping track of this information.
http://open-vm-tools.wiki.sourceforge.net/Distro+Package+Status

By the way, I am curious to see if you or the other packagers found
the packaging guidelines doc helpful.
http://open-vm-tools.wiki.sourceforge.net/Packaging

Are there any other pieces of information we can provide that would
make your jobs easier?

Ragavan

Re: [open-vm-tools-devel] Power functions in vmware-guestd

[Elliot L. <el...@vm...>]

On 11/6/07 7:44 PM, "Justin M. Forbes" <jmf...@li...> wrote:

>> From an appliance standpoint, it would be nice to give appliance
> developers the ability to add startup or shutdown scripts without
> modifying the open-vm-tools package themselves.  In this vein, we
> shipped the following script
> for /etc/vmware-tools/{poweroff,poweron,suspend,resume}-vm-default:
> 
> #!/bin/bash
> 
> execscript=$(basename $0)
> scriptdir=/etc/vmware-tools/scripts/$execscript.d
> 
> for file in $scriptdir/*
> do
>         [ -x $file ] && $file
> done
> 
> # To match output from older VMware Tools
> echo `date` ": Executing '$0'"
> 
> Realistically, the reboot or shutdown does a shutdown -r or -h so init
> does it's job normally, and I don't think that the scripts will get much
> use.  Unfortunately the host complains and an error dialog appears if
> they are not there, so we might as well give them the potential to be
> useful.

Hey Justin,

Thanks for the explanation. I think a .d scheme would be very useful and
very easy to do. Can't promise it for the next release (which I'm hoping
will be ready in a week or so), but I'll try if there's time. The main thing
I'd like feedback from others on is the actual directory path that these
scripts will be dropped into. I'm thinking of either

Scriptsdir="`dirname $0`"/scripts/`basename $0`.d"

(to match your current setup) or just

Scriptsdir=$0.d

The main constraint is that it has to work properly even if the scripts are
in /usr/local/etc or /var/fooblah.

Thoughts?
Best,
-- Elliot

Re: [open-vm-tools-devel] RPM packages?

[Justin M. F. <jmf...@li...>]

On Wed, 2007-11-07 at 17:23 -0800, Elliot Lee wrote:
> I agree 100% that it'd be nice to get more packages made. Here's what I know
> about distro packages so far:
> 
> . Debian has a package in contrib/experimental (
> http://packages.debian.org/open-vm-tools )
> . Ubuntu has a page for it at https://launchpad.net/open-vm-tools , but
> doesn't seem to have packaged it yet. They may wind up getting in there via
> Debian.
> . Gentoo is working on a package (
> http://bugs.gentoo.org/show_bug.cgi?id=192377 )
> . Fedora won't include the kernel modules unless they're included in the
> upstream Linux kernel, but someone has started packaging things in Livna.
> See http://bugzilla.livna.org/show_bug.cgi?id=1664 and
> http://bugzilla.livna.org/show_bug.cgi?id=1665
> . Don't know what's going on with OpenSUSE.
> . Any other distros people care about? Heiko, how is DevilLinux going? :)


rPath Linux has open-vm-tools packaged and is shipping it enabled by
default on vmware flavors of the distro (and many users appliances).
Foresight Linux is coming soon.

Justin

Re: [open-vm-tools-devel] RPM packages?

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

Elliot Lee wrote:
> On 11/7/07 1:29 AM, "Johannes Kastl" <oj...@gm...> wrote:

> Sean, unless someone else pops up soon, don't feel like you need permission
> to build RHEL packages on your own. Do you know of an existing repository of
> unofficial RHEL packages that is in wide use?
> 

I found the packages that were submitted to Fedora and ran with them. 
I ended up splitting out an extra subpackage (in case you don't want to 
install X-libs).  I also modified the init script (there are some things 
ESX doesn't need).  If anyone wants, you can find my packages here: 
http://www.duke.edu/~sean/rpms/open-vm-tools/

They're compiled against CentOS 5


Thanks,


Sean

Re: [open-vm-tools-devel] RPM packages?

[Elliot L. <el...@vm...>]

On 11/7/07 1:29 AM, "Johannes Kastl" <oj...@gm...> wrote:

> Sean Dilda schrieb:
>> I just ran into this project today and am looking to start using it (or
>> at least testing it out).  Before I delve into packaging it up, is there
>> anyone out there that's already made packages for RHEL 4/5?  Or anyone
>> who is in the process of making them?
> 
> Im not sure how the usage of this project ist planned, but it would be
> nice to have packages for more distributions, RHEL 4/5 or Fedora,
> openSUSE 10.x, Debian, Ubuntu,...
> 
> Then one could just install them from within the vm via the normal
> mechanism (apt, yum, smart,...).
> OJ

I agree 100% that it'd be nice to get more packages made. Here's what I know
about distro packages so far:

. Debian has a package in contrib/experimental (
http://packages.debian.org/open-vm-tools )
. Ubuntu has a page for it at https://launchpad.net/open-vm-tools , but
doesn't seem to have packaged it yet. They may wind up getting in there via
Debian.
. Gentoo is working on a package (
http://bugs.gentoo.org/show_bug.cgi?id=192377 )
. Fedora won't include the kernel modules unless they're included in the
upstream Linux kernel, but someone has started packaging things in Livna.
See http://bugzilla.livna.org/show_bug.cgi?id=1664 and
http://bugzilla.livna.org/show_bug.cgi?id=1665
. Don't know what's going on with OpenSUSE.
. Any other distros people care about? Heiko, how is DevilLinux going? :)

Please also note the packaging guidelines at
http://open-vm-tools.wiki.sourceforge.net/Packaging

Sean, unless someone else pops up soon, don't feel like you need permission
to build RHEL packages on your own. Do you know of an existing repository of
unofficial RHEL packages that is in wide use?

Anything I can do to help anyone move things forward with distro packaging?

Best,
-- Elliot

Re: [open-vm-tools-devel] RPM packages?

[Johannes K. <oj...@gm...>]

Sean Dilda schrieb:
> I just ran into this project today and am looking to start using it (or=
=20
> at least testing it out).  Before I delve into packaging it up, is ther=
e=20
> anyone out there that's already made packages for RHEL 4/5?  Or anyone =

> who is in the process of making them?

Im not sure how the usage of this project ist planned, but it would be
nice to have packages for more distributions, RHEL 4/5 or Fedora,
openSUSE 10.x, Debian, Ubuntu,...

Then one could just install them from within the vm via the normal
mechanism (apt, yum, smart,...).
OJ
--=20
As sure as night is dark and day is light, I keep you on my mind both
day and night.
And happiness I've known proves that it's right,
because you're mine, I walk the line. (Johnny Cash: I walk the line)

Re: [open-vm-tools-devel] Power functions in vmware-guestd

[Justin M. F. <jmf...@li...>]

On Tue, 2007-11-06 at 10:49 -0800, Elliot Lee wrote:
> 
> I believe that the missing scripts were actually an oversight and should be
> included in the next open-vm-tools release. Sorry about that!
> 
> Right now it looks like the scripts as they'll be shipped either execute
> another script directly, or just run a bunch of initscripts (/etc/init.d/*
> stuff). At this point, it sounds like you understand more about those
> scripts than I do. Are you mainly suggesting that each of the default
> scripts look in a scripts.d directory for other scripts to execute?
> 

Right, so the scripts themselves are not necessary, in fact the ones
that ship with the closed vmware-tools only do:

echo `date` ": Executing '$0'"

They are run before the shutdown or restart when called from the
console.  The console complains when they are not present as they are
reported not implemented, but the shutdown command should work fine.

>From an appliance standpoint, it would be nice to give appliance
developers the ability to add startup or shutdown scripts without
modifying the open-vm-tools package themselves.  In this vein, we
shipped the following script
for /etc/vmware-tools/{poweroff,poweron,suspend,resume}-vm-default:

#!/bin/bash

execscript=$(basename $0)
scriptdir=/etc/vmware-tools/scripts/$execscript.d

for file in $scriptdir/*
do
        [ -x $file ] && $file 
done

# To match output from older VMware Tools
echo `date` ": Executing '$0'"

Realistically, the reboot or shutdown does a shutdown -r or -h so init
does it's job normally, and I don't think that the scripts will get much
use.  Unfortunately the host complains and an error dialog appears if
they are not there, so we might as well give them the potential to be
useful.

Justin

Re: [open-vm-tools-devel] Power functions in vmware-guestd

[Elliot L. <el...@vm...>]

On 11/1/07 12:11 PM, "Justin M. Forbes" <jmf...@li...> wrote:

>> In that case, the default scripts would really just do the default
>> fallback.  In other words, the behavior would be the same if the scripts
>> were present or not.  In this case, it would be better to not package
>> the scripts, so that users could replace them without worrying about
>> getting trampled by their package manager, or more importantly, the
>> packaged implementation could be used while packages providing more
>> specific scripts could be packaged elsewhere without file conflicts.
>> 
> 
> Okay, a bit more reading and understanding the code here... I didn't
> realize those are pre/post scripts.  So the issue is that VMware
> Workstation or VMware Server shouldn't complain if guestd replies not
> implemented on those scripts, but no point in changing the client to
> give a fake response either.  It seems most sane to actually add/package
> those scripts and make them check some given dir
> (say /etc/vmware-tools/scripts.d) for the corresponding script and
> execute the script if it exists, exit cleanly if not.  that not only
> keeps the console from erroring or complaining about missing
> functionality, but allows people to package proper shutdown and startup
> scripts if they have any real needs.
> Sorry for the earlier confusion.

Hey Justin,

I believe that the missing scripts were actually an oversight and should be
included in the next open-vm-tools release. Sorry about that!

Right now it looks like the scripts as they'll be shipped either execute
another script directly, or just run a bunch of initscripts (/etc/init.d/*
stuff). At this point, it sounds like you understand more about those
scripts than I do. Are you mainly suggesting that each of the default
scripts look in a scripts.d directory for other scripts to execute?

Best,
-- Elliot

Re: [open-vm-tools-devel] Power functions in vmware-guestd

[Justin M. F. <jmf...@li...>]

On Thu, 2007-11-01 at 10:16 -0500, Justin M. Forbes wrote:
> On Thu, 2007-11-01 at 11:05 -0400, Sean Dilda wrote:
> > Justin M. Forbes wrote:
> > 
> > > Aha, after a bit of probing, it seems that it chokes
> > > when /etc/vmware-tools/poweroff-vm-default is not present instead of
> > > simply falling back to CONFVAL_HALT_DEFAULT, though I am not sure why it
> > > works on the second try.  I guess the question is, should we include
> > > default scripts, or just make the code DTRT if the scripts are not
> > > present.
> > > 
> > 
> > The right answer is probably to do both.  Include the scripts, and make 
> > sure the code DTRT if they're not there.
> > 
> In that case, the default scripts would really just do the default
> fallback.  In other words, the behavior would be the same if the scripts
> were present or not.  In this case, it would be better to not package
> the scripts, so that users could replace them without worrying about
> getting trampled by their package manager, or more importantly, the
> packaged implementation could be used while packages providing more
> specific scripts could be packaged elsewhere without file conflicts.
> 

Okay, a bit more reading and understanding the code here... I didn't
realize those are pre/post scripts.  So the issue is that VMware
Workstation or VMware Server shouldn't complain if guestd replies not
implemented on those scripts, but no point in changing the client to
give a fake response either.  It seems most sane to actually add/package
those scripts and make them check some given dir
(say /etc/vmware-tools/scripts.d) for the corresponding script and
execute the script if it exists, exit cleanly if not.  that not only
keeps the console from erroring or complaining about missing
functionality, but allows people to package proper shutdown and startup
scripts if they have any real needs.
Sorry for the earlier confusion.

Justin

Re: [open-vm-tools-devel] Power functions in vmware-guestd

[Justin M. F. <jmf...@li...>]

On Thu, 2007-11-01 at 11:05 -0400, Sean Dilda wrote:
> Justin M. Forbes wrote:
> 
> > Aha, after a bit of probing, it seems that it chokes
> > when /etc/vmware-tools/poweroff-vm-default is not present instead of
> > simply falling back to CONFVAL_HALT_DEFAULT, though I am not sure why it
> > works on the second try.  I guess the question is, should we include
> > default scripts, or just make the code DTRT if the scripts are not
> > present.
> > 
> 
> The right answer is probably to do both.  Include the scripts, and make 
> sure the code DTRT if they're not there.
> 
In that case, the default scripts would really just do the default
fallback.  In other words, the behavior would be the same if the scripts
were present or not.  In this case, it would be better to not package
the scripts, so that users could replace them without worrying about
getting trampled by their package manager, or more importantly, the
packaged implementation could be used while packages providing more
specific scripts could be packaged elsewhere without file conflicts.

Justin

Re: [open-vm-tools-devel] Power functions in vmware-guestd

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

Justin M. Forbes wrote:

> Aha, after a bit of probing, it seems that it chokes
> when /etc/vmware-tools/poweroff-vm-default is not present instead of
> simply falling back to CONFVAL_HALT_DEFAULT, though I am not sure why it
> works on the second try.  I guess the question is, should we include
> default scripts, or just make the code DTRT if the scripts are not
> present.
> 

The right answer is probably to do both.  Include the scripts, and make 
sure the code DTRT if they're not there.

Re: [open-vm-tools-devel] Power functions in vmware-guestd

[Justin M. F. <jmf...@li...>]

On Thu, 2007-11-01 at 09:38 -0500, Justin M. Forbes wrote:
> I have noticed when using shutdown guest or restart from the host, on
> the first attempt I get a pop up window saying that the request failed
> "because the corresponding VMware Tools script did not run
> successfully." Yet a second attempt at the same operation always seems
> to work.  Any ideas on the cause for that one?

Aha, after a bit of probing, it seems that it chokes
when /etc/vmware-tools/poweroff-vm-default is not present instead of
simply falling back to CONFVAL_HALT_DEFAULT, though I am not sure why it
works on the second try.  I guess the question is, should we include
default scripts, or just make the code DTRT if the scripts are not
present.

Justin

[open-vm-tools-devel] Power functions in vmware-guestd

[Justin M. F. <jmf...@li...>]

I have noticed when using shutdown guest or restart from the host, on
the first attempt I get a pop up window saying that the request failed
"because the corresponding VMware Tools script did not run
successfully." Yet a second attempt at the same operation always seems
to work.  Any ideas on the cause for that one?

Justin

Re: [open-vm-tools-devel] Subversion repository

[Trampus R. <tr...@vm...>]

Looks like Elliot's Ninja like skills fixed the problem before I saw it. =
=20

--Trampus

-----Original Message-----
From: ope...@li... on behalf of =
Trampus
Richmond
Sent: Fri 10/26/2007 5:22 PM
To: DIscussions relating to development of the open-vm-tools project;
DIscussions relating to development of the open-vm-tools project
Cc: ope...@li...
Subject: Re: [open-vm-tools-devel] Subversion repository
=20
I just tried it from two different browsers and I could see all the =
files and
file content.

--Trampus


-----Original Message-----
From: ope...@li... on behalf of =
Rick
Duff
Sent: Fri 10/26/2007 4:05 PM
To: DIscussions relating to development of the open-vm-tools project
Cc: ope...@li...
Subject: Re: [open-vm-tools-devel] Subversion repository
=20
The repository "appears" to be giving us empy files - even if I try
browsing the URL with a web browser, the files are there, but empty.

Rick..

On 10/26/07, Elliot Lee <el...@vm...> wrote:
> Hi all,
>
> I've imported the open-vm-tools-2007.09.04 release, and my 10.08 devel
> snapshot, into subversion on sourceforge. Right now the repository is
> read-only, but this is still a bit of progress. The big advantage with =
this
> setup is for any of you who are maintaining patches against the code =
base.
> Using subversion, you can checkout the code and keep your patch =
current, by
> merging your changes with any changes in the open-vm-tools code.
>
> To get the code, run:
>
> svn checkout
> https://open-vm-tools.svn.sourceforge.net/svnroot/open-vm-tools/trunk
>
> There are also two tags for the release and the snapshot. The trunk =
will
> continue to be updated as new code comes out.
>
> Right you can't commit to subversion. I apologize that things aren't =
set up
> for that yet. My understanding is that a contributor agreement is =
coming
> soon from inside VMware, and once that happens, we'll be in a lot =
better
> position to get a writeable source code repository going.
>
> Best,
> -- Elliot
>
>
> =
-------------------------------------------------------------------------=

> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a =
browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
>


--=20
Rick Duff
rg...@gm...

-------------------------------------------------------------------------=

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
open-vm-tools-devel mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel


-------------------------------------------------------------------------=

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
open-vm-tools-devel mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel

Re: [open-vm-tools-devel] Subversion repository

[Trampus R. <tr...@vm...>]

I just tried it from two different browsers and I could see all the =
files and
file content.

--Trampus


-----Original Message-----
From: ope...@li... on behalf of =
Rick
Duff
Sent: Fri 10/26/2007 4:05 PM
To: DIscussions relating to development of the open-vm-tools project
Cc: ope...@li...
Subject: Re: [open-vm-tools-devel] Subversion repository
=20
The repository "appears" to be giving us empy files - even if I try
browsing the URL with a web browser, the files are there, but empty.

Rick..

On 10/26/07, Elliot Lee <el...@vm...> wrote:
> Hi all,
>
> I've imported the open-vm-tools-2007.09.04 release, and my 10.08 devel
> snapshot, into subversion on sourceforge. Right now the repository is
> read-only, but this is still a bit of progress. The big advantage with =
this
> setup is for any of you who are maintaining patches against the code =
base.
> Using subversion, you can checkout the code and keep your patch =
current, by
> merging your changes with any changes in the open-vm-tools code.
>
> To get the code, run:
>
> svn checkout
> https://open-vm-tools.svn.sourceforge.net/svnroot/open-vm-tools/trunk
>
> There are also two tags for the release and the snapshot. The trunk =
will
> continue to be updated as new code comes out.
>
> Right you can't commit to subversion. I apologize that things aren't =
set up
> for that yet. My understanding is that a contributor agreement is =
coming
> soon from inside VMware, and once that happens, we'll be in a lot =
better
> position to get a writeable source code repository going.
>
> Best,
> -- Elliot
>
>
> =
-------------------------------------------------------------------------=

> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a =
browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
>


--=20
Rick Duff
rg...@gm...

-------------------------------------------------------------------------=

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
open-vm-tools-devel mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel

Re: [open-vm-tools-devel] Subversion repository

[Elliot L. <el...@vm...>]

On 10/26/07 4:05 PM, "Rick Duff" <rg...@gm...> wrote:

> The repository "appears" to be giving us empy files - even if I try
> browsing the URL with a web browser, the files are there, but empty.

Hi Rick,

Sorry about that; it's fixed now.

Short version - I goofed and didn't test thoroughly before sending out the
e-mail.

Long version - Doing a 'cp -a' of the snapshot code over the existing files
from the release created empty files on my system, which svn happily
imported. Looks like a bug in coreutils ('cp -rp' works fine)...

Best,
-- Elliot

Re: [open-vm-tools-devel] Subversion repository

[Rick D. <rg...@gm...>]

The repository "appears" to be giving us empy files - even if I try
browsing the URL with a web browser, the files are there, but empty.

Rick..

On 10/26/07, Elliot Lee <el...@vm...> wrote:
> Hi all,
>
> I've imported the open-vm-tools-2007.09.04 release, and my 10.08 devel
> snapshot, into subversion on sourceforge. Right now the repository is
> read-only, but this is still a bit of progress. The big advantage with this
> setup is for any of you who are maintaining patches against the code base.
> Using subversion, you can checkout the code and keep your patch current, by
> merging your changes with any changes in the open-vm-tools code.
>
> To get the code, run:
>
> svn checkout
> https://open-vm-tools.svn.sourceforge.net/svnroot/open-vm-tools/trunk
>
> There are also two tags for the release and the snapshot. The trunk will
> continue to be updated as new code comes out.
>
> Right you can't commit to subversion. I apologize that things aren't set up
> for that yet. My understanding is that a contributor agreement is coming
> soon from inside VMware, and once that happens, we'll be in a lot better
> position to get a writeable source code repository going.
>
> Best,
> -- Elliot
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
>


-- 
Rick Duff
rg...@gm...

[open-vm-tools-devel] Subversion repository

[Elliot L. <el...@vm...>]

Hi all,

I've imported the open-vm-tools-2007.09.04 release, and my 10.08 devel
snapshot, into subversion on sourceforge. Right now the repository is
read-only, but this is still a bit of progress. The big advantage with this
setup is for any of you who are maintaining patches against the code base.
Using subversion, you can checkout the code and keep your patch current, by
merging your changes with any changes in the open-vm-tools code.

To get the code, run:

svn checkout 
https://open-vm-tools.svn.sourceforge.net/svnroot/open-vm-tools/trunk

There are also two tags for the release and the snapshot. The trunk will
continue to be updated as new code comes out.

Right you can't commit to subversion. I apologize that things aren't set up
for that yet. My understanding is that a contributor agreement is coming
soon from inside VMware, and once that happens, we'll be in a lot better
position to get a writeable source code repository going.

Best,
-- Elliot

Re: [open-vm-tools-devel] Mouse Capture

[Adam T. <moz...@gm...>]

That is what I am seeing. the auto grab/ungrab feature doesn't work in IceWM
without vmmouse, yet it works in KDE/Xfce without vmmouse... The
vmware-guestd process is running in both instances... and vmware-user is
running in the instance of KDE for sure, I will have to check tomorrow
morning as to whether or not it is running for the others.

On 10/25/07, Adar Dembo <ad...@vm...> wrote:
>
> > > Just to clarify, you aren't even able to click the mouse
> > and have the guest
> > > grab the input? Or are you referring to automatic
> > grab/ungrab, where moving
> > > the mouse in and out of the guest will automatically
> > redirect input to it (or
> > > to the host)?
> >
> > I was able to click the vm and have it grab input, however I
> > was wanting the ability to automatically redirect the input.
> >
> > > Presumably you tested with KDE/IceWM/Xfce in the _host_,
> > not in the guest,
> > > right? That's how I interpreted your e-mail; I just want to be sure.
> >
> > I was testing with KDE/IceWM on the host, and KDE/IceWM/Xfce
> > on the guest. It seems as if only the guest's Window Manager
> > made a difference as to the ability to redirect the input.
> > Now, that being said I did find that if you use the vmmouse
> > module in xorg.conf that it removed any/all issues that I was
> > seeing. Now I am just curious as to why some Window Managers
> > need the module (IceWM) while others do not (KDE/Xfce).
>
> It sounds like you're talking about the "auto grab/ungrab" feature, but
> I'm
> not entirely sure because I don't know what you mean by "automatically
> redirect the input" above.
>
> If that's what we're talking about, know that vmmouse isn't the only
> provider
> of this feature; the vmware-user process is another. My guess is that
> you've
> been running vmware-user in the background and that the auto grab/ungrab
> provided by vmware-user on IceWM doesn't work for some reason. Can you
> confirm or deny this?
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
>

Re: [open-vm-tools-devel] open-vm-tools-2007.10.08 questions

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

> > 1) Is it really necessary to load the vmxnet driver inside=20
> a VMware ESX
> >    guest ?
>=20
> I think it isn't required.  On a RHEL5 VM running under ESX=20
> with VMware=20
> tools from ESX installed, vmxnet isn't loaded.  It looks like=20
> the init=20
> script they use checks /proc/bus/pci/devices for certain=20
> strings to see=20
> if vmxnet is needed.   Unfortunately that init script doesn't seem to=20
> have been included in the open source release, so we can't just reuse=20
> that code.

See my previous e-mail: whether or not the guest needs vmxnet depends on =
the
virtual networking device(s) exposed to that guest. The latest ESX can
support all three types of devices as far as I know.

I don't think you should need the check employed by the Tools init =
script,
because udev/hotplug should recognize the virtual nic well before any =
init
script has a chance to run. If udev sees a vmxnet backend, it'll load =
the
vmxnet module. If it sees an e1000 backend, it'll load Linux's e1000 =
module.
If it sees an AMD vlance, you should use an /etc/modprobe.d script to =
have it
try the vmxnet module before the pcnet32 module.

Re: [open-vm-tools-devel] open-vm-tools-2007.10.08 questions

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

> I finally finished packaging the open-vm-tools for Debian,

Great! Is your package targetted at Lenny? Or Sarge?

> but I do have=20
> some questions regarding a) VMware ESX (in conjunction with=20
> open-vm-tools) and b) the general rule of thumb regarding packaging.
>=20
> 1) Is it really necessary to load the vmxnet driver inside a=20
> VMware ESX
>     guest ?

To answer this let me give you some background on the variety of virtual
networking devices that VMware uses.

Today we support three virtual nics: morphable vlance, vmxnet, and =
e1000. I
believe the newest UI creation wizards (in the latest WS/Fusion =
releases)
will use e1000 for a 64-bit VM and morphable vlance otherwise, though =
through
the .vmx file you can always change a particular NIC to be any one of =
three
types.

The vmxnet and e1000 virtual nics are fairly straight forward: the =
former is
a VMware paravirtualized network device (with special vendor/device =
IDs),
while the latter should behave and look like a real e1000 card. The =
morphable
vlance is special, though. It appears to be an AMD vlance device that =
can be
driven by the pcnet32 module found in the Linux kernel. However, the =
vmxnet
module also claims to drive an AMD vlance, and when the vmxnet module is
loaded against a morphable vlance device, the vmxnet module will "morph" =
the
vlance device into the vmxnet virtual nic device I mentioned earlier, =
which
should result in higher performance networking.

>From a packaging perspective, you can't know ahead of time what virtual
hardware will available in the guest. Ideally you could just make the =
vmxnet
module available to the kernel and let udev or hotplug sort it out. The
problem is that because of the morphable vlance, udev should always =
prefer
the vmxnet module to the pcnet32 module, otherwise the full performance =
of a
morphable-vlance-as-vmxnet won't be realized because udev will load =
pcnet32
to drive the morphable vlance device (I think udev goes through modules =
in
alphabetical order).

We've accomplished this in the past by adding a
modprobe.d/modprobe.conf/modules.conf directive that forces "insmod =
pcnet32"
or "modprobe pcnet32" calls to first try and load the vmxnet module, and
failing that, the pcnet32 module. I think this is covered in our =
packaging
guidelines.

If you want your package to work both on real hardware and in a VMware =
guest,
you should make sure that loading pcnet32 means loading both vmxnet and
pcnet32 (in that order). If the vmxnet module finds a real AMD vlance =
device
(which apparently exposes less IO ports than our morphable vlance), it =
won't
grab it and the subsequent loading of pcnet32 should succeed.

> 2) Is there a rule of thumb on how to blacklist other=20
> ethernet drivers /
>     alias other drivers to vmxnet ?
>=20
>     I tried putting in an alias in /etc/modprobe.d (for=20
> e1000, since the
>     guest loads the "visible" ethernet device driver), which=20
> results in
>     e1000 still loading.
>=20
>     If I blacklist the e1000 driver, no network is operational.
>=20
>     Or is there no need at all to do this and it's just fine=20
> w/ e1000 and
>     it's safe to move the VM onto a different configured ESX host ?
>=20
>     I'm asking, since I do see "Adapter type: e1000" on one=20
> ESX host and
>     "Adapter type: flexible" on a different one.

Right, "flexible" means "morphable vlance". If e1000 is exposed to the =
guest,
vmxnet doesn't need to be loaded at all. But since your package doesn't =
know
whether the guest will get e1000 or morphable vlance (or a real vmxnet
backend, which the vmxnet module can drive), it should work for all =
cases.

When the VM is moved to a different ESX host (one that supports the =
hardware
version of the VM), the new host should expose the same virtual nics as
before.

Re: [open-vm-tools-devel] Mouse Capture

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

> > Just to clarify, you aren't even able to click the mouse=20
> and have the guest
> > grab the input? Or are you referring to automatic=20
> grab/ungrab, where moving
> > the mouse in and out of the guest will automatically=20
> redirect input to it (or=20
> > to the host)?
>=20
> I was able to click the vm and have it grab input, however I=20
> was wanting the ability to automatically redirect the input.
>=20
> > Presumably you tested with KDE/IceWM/Xfce in the _host_,=20
> not in the guest,=20
> > right? That's how I interpreted your e-mail; I just want to be sure.
>=20
> I was testing with KDE/IceWM on the host, and KDE/IceWM/Xfce=20
> on the guest. It seems as if only the guest's Window Manager=20
> made a difference as to the ability to redirect the input.=20
> Now, that being said I did find that if you use the vmmouse=20
> module in xorg.conf that it removed any/all issues that I was=20
> seeing. Now I am just curious as to why some Window Managers=20
> need the module (IceWM) while others do not (KDE/Xfce).=20

It sounds like you're talking about the "auto grab/ungrab" feature, but =
I'm
not entirely sure because I don't know what you mean by "automatically
redirect the input" above.

If that's what we're talking about, know that vmmouse isn't the only =
provider
of this feature; the vmware-user process is another. My guess is that =
you've
been running vmware-user in the background and that the auto grab/ungrab
provided by vmware-user on IceWM doesn't work for some reason. Can you
confirm or deny this?

Re: [open-vm-tools-devel] Mouse Capture

[Adam T. <moz...@gm...>]

> Just to clarify, you aren't even able to click the mouse and have the
guest
> grab the input? Or are you referring to automatic grab/ungrab, where
moving
> the mouse in and out of the guest will automatically redirect input to it
(or
> to the host)?

I was able to click the vm and have it grab input, however I was wanting the
ability to automatically redirect the input.

> Presumably you tested with KDE/IceWM/Xfce in the _host_, not in the guest,
> right? That's how I interpreted your e-mail; I just want to be sure.

I was testing with KDE/IceWM on the host, and KDE/IceWM/Xfce on the guest.
It seems as if only the guest's Window Manager made a difference as to the
ability to redirect the input.
Now, that being said I did find that if you use the vmmouse module in
xorg.conf that it removed any/all issues that I was seeing. Now I am just
curious as to why some Window Managers need the module (IceWM) while others
do not (KDE/Xfce).

> I don't know the requirements myself, but I'll try and find someone who
can
> elaborate.

Thanks for your interest so far,

Adam Tygart