> 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.
>
> Howeve
> The first question is:
> what aspect of Virtualization does it test? Something about signals?
VmCheck_GetVersion makes the BDOOR_CMD_GETVERSION backdoor call, which, if
called within a VMware guest, will cause the vmm to place a "magic" number in
register EAX and return control to the guest.
> but the first one still remains:
> 1. this is always falling back to BDOOR_CMD_GETTIME case. Why? Is
> my WMWare too old?
Yes, I believe BDOOR_CMD_GETTIMEFULL is new for WS 6.0, and
BDOOR_CMD_GETTIMEFULL_WITH_LAG is new for WS 6.5. With Workstation 5.5.2, only
BDOOR_CMD_GETTIME is availab
> Basically, even though Debian's default gcc
> installation is now 4.3, the Debian kernel is still being built with
> gcc-4.1 for some reason.
I looked up this issue in Debian's bug tracking system and found this bug
report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507629
It's too bad t
> Host os: vist x64 u
> Guest os: Debian (lenny) kernel: 2.6.26
> vm station version: 6.5.1 build 126130
> gcc : 4.3.2
>
> I can't install vmware-tools for Debian (lenny), So i download the
> open-vm-tools (2008.11.18), i'm sure i was installed all packages for
> depends, but when i make it after
> I have a Ubuntu 8.0.4 guest running on ESX 3.5. Unfortunately, I have
> not been able to install vmware tools in this guest vm. I have
> downloaded the latest open vm tools. When I run vmware-config-tools.pl,
> it is unable to properly detect X server version. It prints the
> following message.
>
> Just for completeness, here's the updated patch for vmblock, which I've
> run through the vmblocktest tool that Adar posted. Seems a shame not to
> post it somewhere so you guys might as well have it!
>
> It's checkpatch and sparse clean, and applies against 2.6.27.
Thanks, Chris. When the vmb
> [EMAIL PROTECTED]:~/vmware/open-vm-tools$ autoconf
> configure.ac:176: error: possibly undefined macro: AM_INIT_AUTOMAKE
> If this token and others are legitimate, please use
> m4_pattern_allow.
> See the Autoconf documentation.
> configure.ac:209: error: possibly undefined macro: AM_
After noticing that the recent thread with Greg KH was entirely one-sided (his
mails were being discarded so it looked like I was speaking to myself), I made
a couple of changes to the behavior of the open-vm-tools-devel and
open-vm-tools-discuss mailing lists:
1) Posts from non-members are now
> > I'm not sure I see exactly how this will work out as painlessly as you
> > say, so let me describe my understanding of the situation and you can
> > correct my mistakes.
> >
> > Let's suppose we want to continue to ship out-of-tree as well as
> > in-tree drivers. The in-tree drivers are live in
> > Since we're on the subject, I also want to say a few words about
> > upstreaming VMware's kernel modules. In general we're getting more and
> > more comfortable about upstreaming as some of us have been socializing
> > the idea within the company. I think the remaining obstacle is this
> > idea
Chris,
I'm sorry that none of us replied to your mail, but better 3 months late than
never, right?
Thanks very much for taking the time to go through the vmblock code and
cleaning it up. As a developer I can imagine how annoying it must be to
translate a non-trivial piece of code from one codi
> What license are the tools (not the kernel modules) written with ?
>
> There are a number of copies of COPYING containing the LGPLv2+ (i.e. "or
> any later version"), while the source code mentions LGPLv2 (i.e. "no
> later version")...
Our intent was for LGPLv2 adhering bits to be "no later vers
> > Back in the June 20th code refresh we changed how vmware-guestd relays
> versioning information to the host. Now, one can now set a key/value pair
> in tools.conf which will cause the open-vm-tools to "opt-out" of VMware's
> Tools upgrading infrastructure. At the time I don't think we advertise
Back in the June 20th code refresh we changed how vmware-guestd relays
versioning information to the host. Now, one can now set a key/value pair in
tools.conf which will cause the open-vm-tools to "opt-out" of VMware's Tools
upgrading infrastructure. At the time I don't think we advertised this
> Also: In short what does "unity" provide?
> Or what does "--disable-unity" leave out?
I can answer this one. Unity is essentially "rootless mode" for a VM. Meaning,
the guest desktop is hidden, and all guest windows appear on the host desktop.
We've actually never tested Unity on FreeBSD guest
> I am trying to compile:
> open-vm-tools-2008.09.03-114782
> on FreeBSD 7
Thanks for trying out the open-vm-tools! It's too bad you're having
difficulties compiling; let's take a closer look and see what's going on.
> First I get an error during configure stating:
> configure: error: libXss not
> This tripped me up, so I thought I'd share the problem and solution
> just in case someone follows in my footsteps or if the developers are
> interested.
Thanks for the feedback.
> I tracked the problem down to the module Makefiles declaring
> "HEADER_DIR = /lib/modules/$(VM_UNAME)/build/includ
> Great! Thank you. Do you have any slightest any idea when it will be
> refreshed/released?
The schedule is monthly since the refreshes involve some work. Since the last
one took place in early September, it's likely the next one will be in early
October.
Could you just cherry pick the patch i
> I think it might be safe to remove the notice, but I'll double check with
> our legal department and ping the xorg guys. Thanks for reporting this
> issue.
OK, I just committed a patch that modifies the DEC license in region.c
according to what I found in http://bugs.freedesktop.org/show_bug.cg
> File lib/region/region.c contains following comment:
[snip]
> If I'm right, we (distribution) are not able to redistribute this file
> and thus not able to include open-vm-tools into distro. Is there
> anything that can be done? I would be very unhappy to remove
> open-vm-tools from SUSE. Thank
> So I tried to use the latest copy of open-vm-tools to use with VMCI on
> workstation 6.0.2. However, despite it building properly the module
> will not load. It gives an error that I referred to yesterday that I
> have tracked down to this change in vmci_drv.c:
>
> vmci_drv.c from: VMwareTools-
> I have tried to fix the problems in this new patch. Thank you for the
> review.
Thanks, this looks very good. I appreciate your diligence with our coding
standard; it's certainly not easy to pick up a new one.
Here is an additional round of comments:
- Can GuestApp_ControlRecord return a Bool
> This is my patch for 2008.08.08 release. This patch adds a
> simple "Record" panel to vmware-toolbox and "record" command
> to vmware-toolbox-cmd.
> I configured the build by "--without-procps --disable-unity",
> since I didn't install the two packages.
> I have tested the patch on rhel5, suse10
> That was a good call, I figured out It was actually failing on missing
> libXext-devel, adding that reported a failure on Xrandr which was
> actually Xrender-devel.'
Yeah, I should have noticed this in config.log:
configure:22092: checking for XineramaQueryVersion in -lXinerama
configure:22127:
> 1.) here is the config.log
> http://char1es.net/config.log
That's quite a prolific set of arguments passed to ./configure. Out of
curiosity, why so many?
> 2.) here are the files it installs
> [EMAIL PROTECTED] open-vm-tools]$ rpm -lq libXinerama libXinerama-devel
> /usr/lib/libXinerama.so.1
>
> I'm running a ./configure and it croaks on Xinerama even though it's
> install. Anybody have an idea where the issue could be at?
>
> checking for XineramaQueryVersion in -lXinerama... no
> configure: error: libXinerama not found. Please configure without
> multimon (using --disable-multimon), c
> I used to work on migrating vassert sdk from windows
> to linux platform, with the help of some internal engineers.
> The latest release of vassert sdk in windows supports start
> and stop recording inside the guest, and I just make the
> upgrade in linux. I think it useful to add a GUI f
ating to development of the open-vm-tools project
> Cc: Ragavan Srinivasan; Jason Lunz
> Subject: Re: [open-vm-tools-devel] [patch] linux
> vmware-guestd repeats unchanged guest nic info updates
>
> Jason,
> Thanks for the patch. It looks good to me.
>
> Aaron
>
> When I tried to build the open-vm-tools(2008.07.01
> release), the configure check couldn't find procps header
> files, so I added configure arguement --without-procps. The
> following build process looked well, no errors or warnings
> were experienced. Is there any concern by missing th
Thanks for sending this our way, Jason. The patch looks correct to me, but for
the sake of building good code review discipline, I'd like to wait for an
additional thumbs-up before committing it. Anyone out there feel like reviewing
Jason's patch?
Also, if you haven't already done so, could you
31 matches
Mail list logo
