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

[open-vm-tools-devel] VMWare Remote Console Protocol

[<joz...@as...>]

Hello,
I wonder if VMWare has documentation for 'MKSDisplayProtocol:VNC'  
available in public - ?
VMWare MUI has option 'Attach Console' however it requires OS compatible  
with VMWare Remote Console.
Maybe it would be possible to write Java applet for controlling guest OS  
console, however
I cannot find anything in this subject.

Regards,
Jakub

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[open-vm-tools-devel] [ open-vm-tools-Tracker-1805476 ] FreeBSD port of open-vm-tools

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

Tracker item #1805476, was opened at 2007-10-01 01:30
Message generated for change (Comment added) made by ragavan_s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1805476&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: Gamester17 (gamester17)
Assigned to: Nobody/Anonymous (nobody)
Summary: FreeBSD port of open-vm-tools

Initial Comment:
I like to put in a request for "Open Virtual Machine Tools for FreeBSD"

Why limit open-vm-tools to Linux?, why not port it to make it useable diretcly in BSD operating-systems such a FreeBSD.

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

>Comment By: Ragavan S (ragavan_s)
Date: 2007-10-05 16:58

Message:
Logged In: YES 
user_id=1859435
Originator: NO

Good news. We have decided to release the source for the FreeBSD ports of
the kernel modules. We plan to release all of the modules except one (the
vmblock module) under the GPL v2. We will most likely be releasing the
vmblock module under the BSD license because it is built on top of nullfs
(which is licensed under the BSD license).

We are currently going through the internal review process for
contributing this as well as cleaning up the code a bit. We hope to be able
to include this in the next drop of the tarball.

We will update this bug when the release happens.

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

Comment By: Adar Dembo (adembo)
Date: 2007-10-01 01:40

Message:
Logged In: YES 
user_id=1867590
Originator: NO

The various userlevel components (guestd, vmware-user, toolbox, etc.)
should compile and run in FreeBSD as is (we tested them in FreeBSD 6 I
believe). We didn't get a chance to test other BSD-based operating systems,
although it appears that at least one other person is trying to do that
(see
http://sourceforge.net/mailarchive/forum.php?thread_name=20070930225805.GA5615%40silence.homedns.org&forum_name=open-vm-tools-devel).

We also have FreeBSD ports of the kernel modules available in binary form;
we're currently evaluating whether to release them in source form, and if
so, under what license. When a conclusion about that is reached, I'll
update this bug with more information.

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

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

Re: [open-vm-tools-devel] Getting involved

[Charles N W. <ch...@th...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Elliot Lee wrote:
> On Mon, 2007-10-01 at 18:42 -0500, Justin M. Forbes wrote: 
>>> . Implementing a CLI for the tools. Some of this type of work has
>>> already been done (see
>>> http://chitchat.at.infoseek.co.jp/vmware/ ).
<snip>

> One thing I am curious on.  The kernel modules... Are there any
>> intentions to upstream them? I know the virt I/O bits could probably
>> eventually replace some of these (vmblock/vmnet).  I am guessing if
>> there was a desire to get the vm* drivers upstream, earlier rather than
>> later would be best...
> 
> Hey Justin, 
> 
> Sorry for the lag... I don't have a good official answer off the top of
> my head, but those of us inside of VMware have definitely done some
> thinking about upstreaming, and I'll do what I can to keep the issue on
> the agenda. Hopefully we'll have something more definitive to share with
> the rest of the group at some point.
> 
> Any particular reason you think earlier is better than later? (Other
> than the benefits that come from having the modules upstream in
> general... :)

I think (in regards to the I/O bits getting upstreamed) that it will
help the other hyper visor projects that are going on.
There have been a number of discussions on the kern virt list recently
regarding lguest and VMI. Very interesting stuff.

 I think adding the vmware tools into the mix could lead to some useful
cross polination.

Rusty Russel, are you on this list? :)

- --
Charles N Wyble ch...@th... (818) 280 7059
http://www.thewybles.com/~charles

President and CEO of Known Element Enterprises and affiliated companies.
http://www.knownelement.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBBgnkQPZV56XDBMRAvZBAKCW+Egx25U5AObTM8eKAfMJcbvx3ACfdBJv
A4p4A9iJhVZIi7oQDlpGhbo=
=cviN
-----END PGP SIGNATURE-----

Re: [open-vm-tools-devel] Getting involved

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

On Mon, 2007-10-01 at 18:42 -0500, Justin M. Forbes wrote: 
> > . Implementing a CLI for the tools. Some of this type of work has
> > already been done (see
> > http://chitchat.at.infoseek.co.jp/vmware/ ).
> > 
> This is indeed interesting and a CLI would be most useful from a
> software appliance standpoint.
> 
> > . Making the tools work with qemu, KVM, etc. Anthony Liguori
> > 
> Also interesting work, particularly with KVM.
> 
> > . Packaging on OS's where the code should already work
> >    . Debian
> >    . Fedora
> 
> Add rPath to this list.  I am working on this packaging righ tnow.
> 
> 
> One thing I am curious on.  The kernel modules... Are there any
> intentions to upstream them? I know the virt I/O bits could probably
> eventually replace some of these (vmblock/vmnet).  I am guessing if
> there was a desire to get the vm* drivers upstream, earlier rather than
> later would be best...

Hey Justin, 

Sorry for the lag... I don't have a good official answer off the top of
my head, but those of us inside of VMware have definitely done some
thinking about upstreaming, and I'll do what I can to keep the issue on
the agenda. Hopefully we'll have something more definitive to share with
the rest of the group at some point.

Any particular reason you think earlier is better than later? (Other
than the benefits that come from having the modules upstream in
general... :)

Best,
-- Elliot

Re: [open-vm-tools-devel] Getting involved

[Eric A. <and...@fr...>]

Elliot Lee wrote:
> Hi all,
> 
> Now that the code has been out for a little while, and the initial
> excitement has died down, I wanted to start a discussion to find out
> what everyone's impressions had been so far, and what you wanted out of
> the project.
> 
> If you are looking to get involved, please don't hesitate to speak up.
> Here are some specific things I know can use some work:
> . Code review
>    . Every check-in inside VMware gets reviewed, and it'd be great to be
> able to work with the community on doing reviews of the tools. One
> specific area that could especially use review is the kernel modules -
> any code in there that you can suggest improvements for?
> 
> . Implementing a CLI for the tools. Some of this type of work has
> already been done (see
> http://chitchat.at.infoseek.co.jp/vmware/ ).
> 
> . Improved logging. I've heard it mentioned that someone inside VMware
> had possibly started on integrating log4c into the tools, so ask for
> more details if you're interested.
> 
> . Ports to new OS's
>    . FreeBSD
>    . Solaris
>    . Your favorite OS
> 
> FreeBSD & Solaris mainly need kernel module attention. I don't want to
> discourage people from going ahead and making wonderful things happen
> here, but at the same time, please be aware that there are other efforts
> going on here, so speak up if you're interested.


I'm interested in helping out in the FreeBSD efforts.  Please let me
know what the current state of things are for the FreeBSD tools.  I
remember it being said that somebody (intern at VMWare?) had worked on
porting the kernel modules (vmblock and vmhgfs) to FreeBSD over the
summer, and either completed them or nearly did.  I would be interested
in testing them, cleaning up code, and making any necessary changes to
port to FreeBSD -CURRENT (7.x).


Thanks!
Eric

Re: [open-vm-tools-devel] Getting involved

[Eric A. <and...@vn...>]

Elliot Lee wrote:
> Hi all,
> 
> Now that the code has been out for a little while, and the initial
> excitement has died down, I wanted to start a discussion to find out
> what everyone's impressions had been so far, and what you wanted out of
> the project.
> 
> If you are looking to get involved, please don't hesitate to speak up.
> Here are some specific things I know can use some work:
> . Code review
>    . Every check-in inside VMware gets reviewed, and it'd be great to be
> able to work with the community on doing reviews of the tools. One
> specific area that could especially use review is the kernel modules -
> any code in there that you can suggest improvements for?
> 
> . Implementing a CLI for the tools. Some of this type of work has
> already been done (see
> http://chitchat.at.infoseek.co.jp/vmware/ ).
> 
> . Improved logging. I've heard it mentioned that someone inside VMware
> had possibly started on integrating log4c into the tools, so ask for
> more details if you're interested.
> 
> . Ports to new OS's
>    . FreeBSD
>    . Solaris
>    . Your favorite OS
> 
> FreeBSD & Solaris mainly need kernel module attention. I don't want to
> discourage people from going ahead and making wonderful things happen
> here, but at the same time, please be aware that there are other efforts
> going on here, so speak up if you're interested.


I'm interested in helping out in the FreeBSD efforts.  Please let me 
know what the current state of things are for the FreeBSD tools.  I 
remember it being said that somebody (intern at VMWare?) had worked on 
porting the kernel modules (vmblock and vmhgfs) to FreeBSD over the 
summer, and either completed them or nearly did.  I would be interested 
in testing them, cleaning up code, and making any necessary changes to 
port to FreeBSD -CURRENT (7.x).


Thanks!
Eric

Re: [open-vm-tools-devel] Getting involved

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

> One thing I am curious on.  The kernel modules... Are there any
> intentions to upstream them? I know the virt I/O bits could probably
> eventually replace some of these (vmblock/vmnet).  I am guessing if
> there was a desire to get the vm* drivers upstream, earlier=20
> rather than
> later would be best...

There was a brief discussion[1] about virtio a few weeks back. Note that
vmblock isn't a block device driver (a bit confusing given its name), so =
I
don't think it's necessarily relevant to virtio.

We are definitely interested in upstreaming the kernel modules, but =
it'll
take time and effort. The code must be made conformant to the Linux =
kernel
coding style, and then any design or implementation issues would have to =
be
worked out. There've been rumblings that some (such as vmblock) may need =
to
be reimplemented outright. See Elliot's e-mail where he referenced a =
Fedora
packaging bug; there was some brief discussion about this in that bug =
report.

[1]
http://sourceforge.net/mailarchive/forum.php?thread_name=3D1189726910.598=
2.50.c
amel%40bodhitayantram.eng.vmware.com&forum_name=3Dopen-vm-tools-devel

Re: [open-vm-tools-devel] Getting involved

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

> . Implementing a CLI for the tools. Some of this type of work has
> already been done (see
> http://chitchat.at.infoseek.co.jp/vmware/ ).
> 
This is indeed interesting and a CLI would be most useful from a
software appliance standpoint.

> . Making the tools work with qemu, KVM, etc. Anthony Liguori
> 
Also interesting work, particularly with KVM.

> . Packaging on OS's where the code should already work
>    . Debian
>    . Fedora

Add rPath to this list.  I am working on this packaging righ tnow.


One thing I am curious on.  The kernel modules... Are there any
intentions to upstream them? I know the virt I/O bits could probably
eventually replace some of these (vmblock/vmnet).  I am guessing if
there was a desire to get the vm* drivers upstream, earlier rather than
later would be best...

Justin

[open-vm-tools-devel] Getting involved

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

Hi all,

Now that the code has been out for a little while, and the initial
excitement has died down, I wanted to start a discussion to find out
what everyone's impressions had been so far, and what you wanted out of
the project.

If you are looking to get involved, please don't hesitate to speak up.
Here are some specific things I know can use some work:
. Code review
   . Every check-in inside VMware gets reviewed, and it'd be great to be
able to work with the community on doing reviews of the tools. One
specific area that could especially use review is the kernel modules -
any code in there that you can suggest improvements for?

. Implementing a CLI for the tools. Some of this type of work has
already been done (see
http://chitchat.at.infoseek.co.jp/vmware/ ).

. Improved logging. I've heard it mentioned that someone inside VMware
had possibly started on integrating log4c into the tools, so ask for
more details if you're interested.

. Ports to new OS's
   . FreeBSD
   . Solaris
   . Your favorite OS

FreeBSD & Solaris mainly need kernel module attention. I don't want to
discourage people from going ahead and making wonderful things happen
here, but at the same time, please be aware that there are other efforts
going on here, so speak up if you're interested.

. Making the tools work with qemu, KVM, etc. Anthony Liguori

. Packaging on OS's where the code should already work
   . Debian
   . Fedora
Talk to Denis Leroy, and see
https://bugzilla.redhat.com/show_bug.cgi?id=294341 - what's needed for
the time being is someone to maintain the package in livna.
   . Gentoo
Talk to Elias Probst, and see
http://bugs.gentoo.org/show_bug.cgi?id=192377
   . SuSE
   . Ubuntu
See https://launchpad.net/open-vm-tools

Of course, if you have your own ideas, bring them on!

Best,
-- Elliot

Re: [open-vm-tools-devel] vswprintf() required?

[Klaus H. <k....@ok...>]

Elliot Lee wrote:

> working on one possible fix. If you want to open a ticket in the
> Sourceforge tracker, that would make sure it doesn't get lost.

Bug ID 1805960.

> Thanks for reporting the bug!

Thanks for setting free the bears^Wtools.

ciao
     Klaus

[open-vm-tools-devel] [ open-vm-tools-Tracker-1805960 ] cannot build lib/string/str.c on systems without vswprintf()

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

Tracker item #1805960, was opened at 2007-10-01 23:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1805960&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: Klaus Heinz (kheinz)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot build lib/string/str.c on systems without vswprintf()

Initial Comment:
While trying to build the software on NetBSD 3 this
is the first real blocker because vswprintf() is not
available on NetBSD 3.

../str.c: In function `Str_Vsnwprintf':
../str.c:558: warning: implicit declaration of function `vswprintf'
*** Error code 1

While NetBSD 3 is not a supported guest operating system,
FreeBSD 4.x _is_ and does _not_ have the vswprintf()
function, which makes me believe open-vm-tools cannot
be built on FreeBSD 4.

Regards,
     Klaus Heinz

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

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

Re: [open-vm-tools-devel] vswprintf() required?

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

Hey Klaus,

On Mon, 2007-10-01 at 00:58 +0200, Klaus Heinz wrote:
> Hi,
> 
> it looks like building lib/string/str.c requires vswprintf(), the
> wide-character version of vsprintf. While trying to build the software
> on NetBSD 3 this is the first real blocker because vswprintf() is not
> available on NetBSD 3 (NetBSD 4 will have it).
> 
> I wonder how this is supposed to work on FreeBSD 4.x?

Yea, that's a little older system than may have been tested with the
first release. I personally did a build in FreeBSD 6.2/x864, but not
4.x.

> As far as I know
> this is a supported guest operating system but lacks vswprintf().

I actually ran into this specific issue on Thursday myself, and I'm
working on one possible fix. If you want to open a ticket in the
Sourceforge tracker, that would make sure it doesn't get lost.

Thanks for reporting the bug!

Best,
-- Elliot

[open-vm-tools-devel] [ open-vm-tools-Tracker-1805476 ] FreeBSD port of open-vm-tools

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

Tracker item #1805476, was opened at 2007-10-01 01:30
Message generated for change (Comment added) made by adembo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1805476&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: Gamester17 (gamester17)
Assigned to: Nobody/Anonymous (nobody)
Summary: FreeBSD port of open-vm-tools

Initial Comment:
I like to put in a request for "Open Virtual Machine Tools for FreeBSD"

Why limit open-vm-tools to Linux?, why not port it to make it useable diretcly in BSD operating-systems such a FreeBSD.

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

>Comment By: Adar Dembo (adembo)
Date: 2007-10-01 01:40

Message:
Logged In: YES 
user_id=1867590
Originator: NO

The various userlevel components (guestd, vmware-user, toolbox, etc.)
should compile and run in FreeBSD as is (we tested them in FreeBSD 6 I
believe). We didn't get a chance to test other BSD-based operating systems,
although it appears that at least one other person is trying to do that
(see
http://sourceforge.net/mailarchive/forum.php?thread_name=20070930225805.GA5615%40silence.homedns.org&forum_name=open-vm-tools-devel).

We also have FreeBSD ports of the kernel modules available in binary form;
we're currently evaluating whether to release them in source form, and if
so, under what license. When a conclusion about that is reached, I'll
update this bug with more information.

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

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

[open-vm-tools-devel] [ open-vm-tools-Tracker-1805476 ] FreeBSD port of open-vm-tools

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

Tracker item #1805476, was opened at 2007-10-01 08:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1805476&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: Gamester17 (gamester17)
Assigned to: Nobody/Anonymous (nobody)
Summary: FreeBSD port of open-vm-tools

Initial Comment:
I like to put in a request for "Open Virtual Machine Tools for FreeBSD"

Why limit open-vm-tools to Linux?, why not port it to make it useable diretcly in BSD operating-systems such a FreeBSD.

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

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

[open-vm-tools-devel] vswprintf() required?

[Klaus H. <k....@ok...>]

Hi,

it looks like building lib/string/str.c requires vswprintf(), the
wide-character version of vsprintf. While trying to build the software
on NetBSD 3 this is the first real blocker because vswprintf() is not
available on NetBSD 3 (NetBSD 4 will have it).

I wonder how this is supposed to work on FreeBSD 4.x? As far as I know
this is a supported guest operating system but lacks vswprintf().

ciao
     Klaus

[open-vm-tools-devel] [ open-vm-tools-Tracker-1797158 ] Open Virtual Machine Tools for windows

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

Tracker item #1797158, was opened at 2007-09-18 16:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1797158&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: stopka (stopka2top)
Assigned to: Nobody/Anonymous (nobody)
Summary: Open Virtual Machine Tools for windows

Initial Comment:
Open Virtual Machine Tools for windows users.


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

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

Re: [open-vm-tools-devel] [ open-vm-tools-Tracker-1796805 ] Cannot configure without X libraries

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

SourceForge.net schrieb:

> However, when running the configure script with --without-x
> --disable-multimon, the configure script exits with an error when
> trying to find the xrandr library:

It seems the guys at gentoo trying to create an ebuild have similar
problems:

<http://sourceforge.net/mailarchive/forum.php?thread_name=3D200709150522.=
43339.mail%40eliasprobst.eu&forum_name=3Dopen-vm-tools-devel>

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)

[open-vm-tools-devel] [ open-vm-tools-Tracker-1796805 ] Cannot configure without X libraries

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

Tracker item #1796805, was opened at 2007-09-17 22:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=989708&aid=1796805&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: misc
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alf Mel (alfmel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot configure without X libraries

Initial Comment:
Thank you for releasing these tools to the Open Source community.

I am trying out the new tools by trying to simply build the modules in a system that does not have X installed.  I do this because I don't install X on my servers to reduce the VM hard disk footprint.

However, when running the configure script with --without-x --disable-multimon, the configure script exits with an error when trying to find the xrandr library:

checking for pkg-config... yes
checking for XRRQueryVersion in -lXrandr... no
configure: error: libXrandr not found. Please install the libXrandr devel package(s).

The README file contains the following:

(*)Building Linux kernel modules:
1) ./configure
2) make modules

Since I cannot run configure successfully, I am not even able to compile the kernel modules that should not require any X libraries what so ever.

Could you fix your configure script to allow configuration without any X libraries?  Ideally, it would also be nice to know what packages will *not* be compiled due to failed X dependencies during configuration.

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

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

Re: [open-vm-tools-devel] FW: VMTools for other OSes

[Anthony L. <an...@co...>]

Zachary Amsden wrote:
>> The second question is whether you're interested in virtio for things
>> that you currently don't support.  Since ya'll were talking about
>> switching the drivers away from the current backdoor stuff, it seemed
>> like that would be a good time to perhaps shim in virtio.  Keep in mind,
>> there doesn't have to be only one virtio network driver.  The advantage
>> of virtio is if you guys port your driver over to virtio, other
>> hypervisors can potentially (easily) make use of it.
>>     
>
> Okay, that is worth noting, nice to sponsor the design, but I'm not sure
> we want any extra churn or destabilization of our drivers.  Bugs happen,
> and driver bugs happen a lot.  Paravirt bugs happen a lot more as well -
> the complexity of the system has been increased.  It seems like virtio
> unnecessarily exposes us to risk, when our standalone network driver
> module has a very much lower change rate.  We've gone on and evolved our
> network driver much farther (started long before virtio), and maybe the
> next version of it might fit in with virtio, but I think the vmxnet
> driver as is will be pretty much frozen in stone in any relevant time
> frame.  It's not worth rewriting the driver and increasing the
> maintenance burden of what will eventually become legacy.
>   

Yeah, I don't expect that it's worth it to rewrite the vmxnet driver if 
you're already happy with it.

>>> If we want a cleaner driver model that separates architecture and
>>> communication tranports from the driver implementation, shouldn't we be
>>> doing that at a higher level - one that actually has nothing at all to
>>> do with virtualization?
>>>   
>>>       
>> I really don't see it that way.  virtio as an abstraction makes sense
>> from two perspectives.  If you start with the assumption that most
>> paravirt device drivers of the same type (and roughly the same function)
>> are going have a bunch of roughly equivalent code, then virtio makes
>> sense as a way for those various drivers to share that common code.
>>     
>
> My point is, there is nothing inherently to do with paravirt about that.
>   

Yes, but I think it's rare to have such flexibility in the 
communications protocol of devices which is why something like virtio 
hasn't been done before.

>> But you guys have to do whatever makes sense for you.  virtio is
>> certainly not a solution for everything.
>>     
>
> It's much harder to take existing drivers and mold them to virtio than
> the other way around.  I expect we will keep virtio in mind as we work
> on new drivers though.  I need to brush up on the PCI aspects of
> detection to make sure it would work for us - we need to selectively
> bridge individual native PCI devices to virtio drivers.  If that can
> work, there is nothing to stop us from moving new devices to virtio.
>   

Yes, I think this is important too.

> Such a thing might actually be costly, however.  Virtio isn't in older
> kernels, and some new devices might be important to add to older
> kernels.  Until the broad Linux base has virtio support, we might need
> to maintain drivers which work with both virtio and non-virtio kernels.
>   

Or virtio has to be easily portable to older kernels.  I think the rest 
of us are going to have the same requirements here.

To boil this all down, my questions all came down to, if you're going to 
put significant effort into getting your drivers upstream, then I don't 
think it's significantly more effort to also look at integrating with 
the virtio effort.  If you're not going to put effort into getting 
vmxnet upstream, then it wouldn't be worth it at all.

Regards,

Anthony Liguori

> Obviously the right answer is, "Use a newer kernel, knucklehead!".  But
> That's a marketing cost basis decision that I have nothing to do with.
> Fortunately, as time progresses and older distros get phased out, the
> decision becomes easier.
>
> Thanks for the feedback,
>
> Zach
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
>
>   

Re: [open-vm-tools-devel] Gentoo integration

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

Looks like your e-mail was too large (40KB max? Hmm...), but I'll reply =
to it
on-list in case it'll help others.

> > > we're currently developing an open-vm-tools ebuild for
> > > inclusion into Gentoo
> > > Linux.
> > > The development progress can be tracked here:
> > > http://bugs.gentoo.org/show_bug.cgi?id=3D192377
> >
> > Cool, thanks for letting us know. Did you find the=20
> packaging guidelines
> > useful? Was there anything that could have used clarification?
>=20
> Yeah, the packaging guidelines were really helpful! Wouldn't=20
> have managed it=20
> at all without them. Thanks for this nice documentation.
> A little bit more clarification is needed, which tools are=20
> only needed in X=20
> environments.

OK, I'll update the wiki.

> > > Our current blockers are:
> > > - it doesn't build without X (missing libXrandr and probably
> > > libXtst too),
> > > although --disable-x and --without-multimon was given as argument
> > > to ./configure
> >
> > As you said towards the end of your e-mail, adding a=20
> --disable-X configure
> > option sounds like a good idea, though I think you'll need=20
> to disable both
> > the toolbox and vmware-user (there may be some usable=20
> pieces of vmware-user
> > that could build without the X devel libraries; I'm not sure).
>=20
> Is there a way to configure the tools without X (i.e. time=20
> sync between host &=20
> guest)?

Yeah, though it's not completely intuitive. See pages 144-146 in the WS6
manual (http://www.vmware.com/pdf/ws6_manual.pdf).

> > > - the file 'guestlib.so' isn't built - couldn't figure=20
> out why yet..
> >
> > Can you provide the build output? Is there some kind of error?
>=20
> I've attached a complete buildlog=20
> (with-X-but-no-guestlib.txt) to this mail.=20
> I've also attached a buildlog of a failing compilation without X libs=20
> (without-X.txt).
> Hope this helps finding the problem. If you guys need a=20
> developer access to a=20
> Gentoo box, contact me directly and I'll provide SSH access.

>From the logs:

i686-pc-linux-gnu-gcc -shared  .libs/vmGuestLib.o =
.libs/vmGuestLibPanic.o
.libs/stubs.o -Wl,--whole-archive ../lib/rpcOut/shared/.libs/libRpcOut.a
../lib/string/shared/.libs/libString.a
../lib/message/shared/.libs/libMessage.a
../lib/backdoor/shared/.libs/libBackdoor.a -Wl,--no-whole-archive
-march=3Dnocona -msse3 -Wl,-z -Wl,defs -Wl,-lc -Wl,-soname =
-Wl,libguestlib.so.0
-o .libs/libguestlib.so.0.0.0
(cd .libs && rm -f libguestlib.so.0 && ln -s libguestlib.so.0.0.0
libguestlib.so.0)
(cd .libs && rm -f libguestlib.so && ln -s libguestlib.so.0.0.0
libguestlib.so)

It should be libguestlib.so.0.0.0 inside libguestlib/.libs.

Re: [open-vm-tools-devel] Gentoo integration

[Elias P. <ma...@el...>]

On Sunday 16 September 2007 07:57:38 Adar Dembo wrote:
> > we're currently developing an open-vm-tools ebuild for
> > inclusion into Gentoo
> > Linux.
> > The development progress can be tracked here:
> > http://bugs.gentoo.org/show_bug.cgi?id=192377
>
> Cool, thanks for letting us know. Did you find the packaging guidelines
> useful? Was there anything that could have used clarification?

Yeah, the packaging guidelines were really helpful! Wouldn't have managed it 
at all without them. Thanks for this nice documentation.
A little bit more clarification is needed, which tools are only needed in X 
environments.

> > Our current blockers are:
> > - it doesn't build without X (missing libXrandr and probably
> > libXtst too),
> > although --disable-x and --without-multimon was given as argument
> > to ./configure
>
> As you said towards the end of your e-mail, adding a --disable-X configure
> option sounds like a good idea, though I think you'll need to disable both
> the toolbox and vmware-user (there may be some usable pieces of vmware-user
> that could build without the X devel libraries; I'm not sure).

Is there a way to configure the tools without X (i.e. time sync between host & 
guest)?

> > - the file 'guestlib.so' isn't built - couldn't figure out why yet..
>
> Can you provide the build output? Is there some kind of error?

I've attached a complete buildlog (with-X-but-no-guestlib.txt) to this mail. 
I've also attached a buildlog of a failing compilation without X libs 
(without-X.txt).
Hope this helps finding the problem. If you guys need a developer access to a 
Gentoo box, contact me directly and I'll provide SSH access.


> BTW, the reason VMwareDnD lives in /tmp is because it serves as the staging
> directory for files that have been dropped into the guest. These files
> should be wiped at startup time, otherwise they'll accumulate and fill up
> the disk. Unfortunately, the DnD protocol doesn't specify any kind of
> lifespan for dropped files, so we must keep them around until no
> application could possibly use them anymore (such as at reboot time).

Ok, you're right. I've reverted this behaviour to the default one.

Regards, Elias P.


-- 
A really nice number:
"09:F9:11:02:9D:74:E3:5B:D8:41:56:C5:63:56:88:C0"

Re: [open-vm-tools-devel] Gentoo integration

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

> we're currently developing an open-vm-tools ebuild for=20
> inclusion into Gentoo=20
> Linux.
> The development progress can be tracked here:
> http://bugs.gentoo.org/show_bug.cgi?id=3D192377

Cool, thanks for letting us know. Did you find the packaging guidelines
useful? Was there anything that could have used clarification?

> Our current blockers are:
> - it doesn't build without X (missing libXrandr and probably=20
> libXtst too),=20
> although --disable-x and --without-multimon was given as argument=20
> to ./configure

As you said towards the end of your e-mail, adding a --disable-X =
configure
option sounds like a good idea, though I think you'll need to disable =
both
the toolbox and vmware-user (there may be some usable pieces of =
vmware-user
that could build without the X devel libraries; I'm not sure).=20

> - the xferlogs tool which is mentioned in the packaging guide=20
> isn't included=20
> in the sources - what happened to this tool?

I see it mentioned in the packaging guidelines, but it's not in the =
source.
I'll look into this...

> - the file 'guestlib.so' isn't built - couldn't figure out why yet..

Can you provide the build output? Is there some kind of error?

> We're also doing some additional patching, maybe some of this=20
> changes sound=20
> useful to the upstream developers for changing/including them.
> - disabling the toolbox when X is not used (I'd wish to do this using=20
> a ./configure argument like --disable-toolbox)
> - modification of the VmwareDnD path, as /tmp is rather=20
> stupid if the user=20
> uses scripts which clean up /tmp on startup or similar. We're using=20
> now /var/tmp/vmware/dnd. Would be nice as ./configure argument=20
> like --dnd-dir=3D/var/foobar.
> - Gentoo specific initscript for the vmware-guestd (dummy=20
> replacement coming=20
> soon...)

In general we'd like to accept patches, though we still don't have the
infrastructure for it. We're working on putting together the =
contribution
agreement, and we still need to get source control up and running. Stay =
tuned
for updates on that.

For now, make whatever changes you need on your end, and when we can =
take
patches, you'll be able to remove yours.

BTW, the reason VMwareDnD lives in /tmp is because it serves as the =
staging
directory for files that have been dropped into the guest. These files =
should
be wiped at startup time, otherwise they'll accumulate and fill up the =
disk.
Unfortunately, the DnD protocol doesn't specify any kind of lifespan for
dropped files, so we must keep them around until no application could
possibly use them anymore (such as at reboot time).

[open-vm-tools-devel] vmhgfs and vmblock on FreeBSD

[Eric A. <and...@vn...>]

Hi all,

I'm thinking of porting the vmhgfs and vmblock drivers to FreeBSD.  I'll 
be focusing on 7-CURRENT.  I'm not sure yet what I'm in for, but 
hopefully it won't be too painful. :)  Any hints/tips/warnings before I 
start?

Thanks to the VMWare folks who have decided to make this stuff open 
source.  Now, if we could only get a Workstation 6 for FreeBSD hosts, 
we'd be rocking!  :)  Oh well, Fusion on MacOS is close..

Eric

Re: [open-vm-tools-devel] Gentoo integration - mail encoding

[Elias P. <ma...@el...>]

It seems Sourceforge has some problems detecting my mail encoding.
To see the bug at the Gentoo bugtracker, go to http://bugs.gentoo.org and=20
enter the number 192377 (one nine two three seven seven).

Regards, Elias P.

On Saturday 15 September 2007 05:22:43 Elias Probst wrote:
> Hi,
>
> we're currently developing an open-vm-tools ebuild for inclusion into
> Gentoo Linux.
> The development progress can be tracked here:
> http://bugs.gentoo.org/show_bug.cgi?id=3D192377
>
> Our current blockers are:
> - it doesn't build without X (missing libXrandr and probably libXtst too),
> although --disable-x and --without-multimon was given as argument
> to ./configure
> - the xferlogs tool which is mentioned in the packaging guide isn't
> included in the sources - what happened to this tool?
> - the file 'guestlib.so' isn't built - couldn't figure out why yet..
>
> If anybody knows how to solve some of this points we'd be glad!
>
> We're also doing some additional patching, maybe some of this changes sou=
nd
> useful to the upstream developers for changing/including them.
> - disabling the toolbox when X is not used (I'd wish to do this using
> a ./configure argument like --disable-toolbox)
> - modification of the VmwareDnD path, as /tmp is rather stupid if the user
> uses scripts which clean up /tmp on startup or similar. We're using
> now /var/tmp/vmware/dnd. Would be nice as ./configure argument
> like --dnd-dir=3D/var/foobar.
> - Gentoo specific initscript for the vmware-guestd (dummy replacement
> coming soon...)
>
> Regards, Elias P.


=2D-=20
A really nice number:
"09:F9:11:02:9D:74:E3:5B:D8:41:56:C5:63:56:88:C0"

[open-vm-tools-devel] Gentoo integration

[Elias P. <ma...@el...>]

Hi,

we're currently developing an open-vm-tools ebuild for inclusion into Gento=
o=20
Linux.
The development progress can be tracked here:
http://bugs.gentoo.org/show_bug.cgi?id=3D192377

Our current blockers are:
=2D it doesn't build without X (missing libXrandr and probably libXtst too)=
,=20
although --disable-x and --without-multimon was given as argument=20
to ./configure
=2D the xferlogs tool which is mentioned in the packaging guide isn't inclu=
ded=20
in the sources - what happened to this tool?
=2D the file 'guestlib.so' isn't built - couldn't figure out why yet..

If anybody knows how to solve some of this points we'd be glad!

We're also doing some additional patching, maybe some of this changes sound=
=20
useful to the upstream developers for changing/including them.
=2D disabling the toolbox when X is not used (I'd wish to do this using=20
a ./configure argument like --disable-toolbox)
=2D modification of the VmwareDnD path, as /tmp is rather stupid if the use=
r=20
uses scripts which clean up /tmp on startup or similar. We're using=20
now /var/tmp/vmware/dnd. Would be nice as ./configure argument=20
like --dnd-dir=3D/var/foobar.
=2D Gentoo specific initscript for the vmware-guestd (dummy replacement com=
ing=20
soon...)

Regards, Elias P.


=2D-=20
A really nice number:
"09:F9:11:02:9D:74:E3:5B:D8:41:56:C5:63:56:88:C0"