当我浏览VMware的VMtools存储库时，我发现它们在CentOS上是最新的，但不是Ubuntu的任何版本。
http://packages.vmware.com/tools/esx/5.5latest/ubuntu/dists/precise/main/binary-amd64/index.html
~# apt-cache search vmware-tools-esx-kmods vmware-tools-esx-kmods-3.2.0-29-generic - VMware OSP Tools meta package - Essential modules for the 3.2.0-29 kernel vmware-tools-esx-kmods-3.2.0-23-generic - VMware OSP Tools meta package - Essential modules for the 3.2.0-23 kernel vmware-tools-esx-kmods-3.2.0-29-virtual - VMware OSP Tools meta package - Essential modules for the 3.2.0-29 kernel vmware-tools-esx-kmods-3.2.0-23-virtual - VMware OSP Tools meta package - Essential modules for the 3.2.0-23 kernel vmware-tools-esx-kmods-3.2.0-29-generic-pae - VMware OSP Tools meta package - Essential modules for the 3.2.0-29 kernel vmware-tools-esx-kmods-3.2.0-23-generic-pae - VMware OSP Tools meta package - Essential modules for the 3.2.0-23 kernel ~# uname -r 3.2.0-57-generic 你可以看到最新的Ubuntu内核是3.2.0-57 ，最新的Vmtools是3.2.0-29内核。
题
这是否意味着我不应该使用VMware的正式VMtools，而是使用open-vm-tools ？
由于厂商还没有发布内核模块的更新版本，所以不得不忍受内核升级，但这只是游戏的一部分。 商业供应商有兴趣（或者至less如此他们告诉我）发布他们的工具的稳定和testing版本。 这使他们有一个保守的发行周期，并不总是与Linux社区的“发行早期和经常发行”一致。
游戏的一部分是确保你在受支持的configuration，如果不是这样，以后你对VMware的支持请求并不都以“使用社区提供的不支持的工具，不支持的configuration”结束，而是因为你通常不想再次猜测他们的工程师，除非你有充分的理由这样做。 这是一个支持的configuration的原因。
萨米莱恩有正确的想法。 跟踪VMware的官方工具，将内核固定在适当的版本上，密切关注你错过了哪些内核更新，以及错误地更新其存储库。