open-vm-tools in base

[Josh Paetzel]

> 
> On Jan 10, 2020, at 9:31 PM, Hiroki Sato <hrs at freebsd.org> wrote:
> 
> "Josh Paetzel" <jpaetzel at FreeBSD.org> wrote
>  in <46480be7-b1a1-4da8-97ea-c4b97b0b997c at www.fastmail.com>:
> 
> jp> I've socialized putting emulators/open-vm-tools-nox11 in base to a
> jp> small group of developers and gotten positive feedback, so I'm
> jp> widening the audience.
> jp>
> jp> Proposal: Put emulators/open-vm-tools-nox11 in the base system of
> jp> FreeBSD
> jp>
> jp> This port contains kernel modules and a binary to ease running FreeBSD
> jp> as a VM in a VMware virtualized environment.  VMware supports this
> jp> port by directly maintaining the code for it, however they do not
> jp> include the FreeBSD version of the tools in the hypervisors
> jp> anymore. (You can't just click "install guest tools" from the VMware
> jp> management interface)
> jp>
> jp> Because these kernel modules are out of tree they are broken with some
> jp> regularity by changes to HEAD.  By putting a version of them in tree
> jp> changes to HEAD that broke the drivers and kernel modules would be
> jp> more obvious to developers.
> jp>
> jp> I have never heard of a drawback or reason why you wouldn't want to
> jp> run these tools.  The main reason I see them not installed is due to
> jp> people not knowing about them or forgetting to install them, or
> jp> running VMs in environments where installing 3rd party software that
> jp> needs an internet link is problematic.
> jp>
> jp> I'd continue to proxy changes back upstream as I've been doing for
> jp> some time now.
> jp>
> jp> There is some precedent for this.  Driver(s?) that were once a part of
> jp> the tools have been moved to base already.  The VMXNET3 driver is an
> jp> example of this.  Also, the RC scripts that load the tools and start
> jp> the userland daemons run a VMware included binary to check if the
> jp> platform is supported by the tools, and just don't start them if it's
> jp> an unsupported platform, so there's no danger to just trying to start
> jp> them blindly across the default installs.
> 
> if_vmx was one ported from OpenBSD, not from open-vm-tools.  VMXNET3
> driver of open-vm-tools was maintained separately and removed
> recently.
> 

Ok, thanks for clarifying that.  I’d modify my statement to be “functionality the tools provided has been moved to base, ala VMXNET3”

In the bad old days you had to create the VM with an e1000 NIC, install the tools. Change rc.conf, shutdown the VM. Change the VM hardware and power it back on. These days you can select VMXNET3 and it just works. 

> jp> Since emulators/open-vm-tools (the master port to
> jp> emulators/open-vm-tools-nox11) depends on X11 and is not a candidate
> jp> to include in the base system, I'd like to keep the ability to install
> jp> the package/port for both open-vm-tools and open-vm-tools-nox11 and
> jp> let the user select which one is started.
> 
> I personally love to see open-vm-tools in the base system because it
> improves user's out-of-the-box experience.  As long as it is possible
> to install emulators/open-vm-tools to override the stock version, I
> see no harmful effect for both users who do not use VMware and ones
> who want to use the latest version of open-vm-tools for some reason.
> 
> However, one thing I want to point out is that open-vm-tools is not
> under BSDL.  LGPL for the userland utilities and libraries, and GPL
> for the kernel modules.  More specifically, the vmmemctl driver for
> FreeBSD is GPL'd, and vmblock is under 2-clause BSDL.  Do we accept
> GPL'd kernel modules?
> 
> Interestingly, modules for Solaris are under CDDL.  When FreeBSD
> Foundation visited VMware a while ago, they said GPL (or LGPL) was
> chosen for compatibility with Linux kernel and they might be able to
> release pre-GPL version of the source code under BSDL because they
> wanted vendors/developer communities to maintain open-vm-tools
> together.  I am not sure if this is still relevant because it was
> several years ago, but if we seriously think importing the kernel
> drivers and maintaining them actively, asking it again might be worth
> doing.
> 
> -- Hiroki

I am aware of the licensing issue. VMware is motivated to get the tools into the base system. They’ll dual license the current code to help facilitate that. (They want something in return, a CI environment set up so they can test FreeBSD on commit. Currently I build packages for them manually when they request)

I was not aware the Foundation had visited with VMware. It might be worth me syncing up directly with the Foundation on this. Can you get a meeting scheduled with the appropriate people on the Foundation side?

Thanks,

Josh Paetzel
FreeBSD - The Power to Serve