ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

VMware Tools 8.8.0 tar.gz 安装与排错全攻略

VMware Tools 8.8.0 tar.gz 安装与排错全攻略 简介面向VMware虚拟化平台的运维人员和虚拟机使用者VMware Tools 8.8.0-471268 安装包用于改善虚拟机在 Workstation、ESXi 等宿主环境中的图形显示、磁盘读写、网络传输与时间同步表现特别适合 Linux/Unix 类虚拟机的驱动部署与工具集成。该压缩包共包含2477个文件以目标文件.o1598个、动态库.so196个和属性配置文件properties199个为主同时配有少量 Shell 脚本、conf 配置、XML 与 HTML 辅助文件整体大小约56.61MB目录内驱动模块、服务脚本和检测工具较为齐全可支撑安装时的自动配置。目前已有307人浏览学习对寻找旧版 VMware Tools 的用户具有一定参考价值。正确安装并启用后虚拟机可获得图形加速、磁盘I/O优化、网络性能增强、时间同步、共享文件夹自动挂载与剪贴板互通等能力还支持热迁移、快照管理和更完善的电源管理策略在多显示器与分辨率适配上也更加完整是维护旧版虚拟化环境或排查工具兼容性问题时的实用组件。1. 这个 tar.gz 到底能干什么先弄清你手上的是哪一类 VMwareTools如果你在一个旧 Linux 虚拟机或者公司遗留的离线镜像里翻出了VMwareTools-8.8.0-471268.tar.gz第一反应不是解压而是先搞清楚它的边界这是 VMware 官方为 Linux guest 虚拟机分发的VMware Tools 安装包用 tar.gz 封装面向 Linux/Unix 系虚拟机而不是 WindowsWindows 拿到的通常是 iso 镜像。8.8.0 属于 VMware Tools 8.x 时代的产品build 号 471268 决定了它对应的 VMware 平台版本和 Linux 内核兼容范围。它能解决的是虚拟机黑匣子问题——没有这套工具你在宿主机上看到的虚拟机 IP、拖拽文件、共享目录、时钟同步基本都不可用关机也只能靠硬断电。适合谁一类是维护 2013 年前后 ESXi/Workstation 环境的老手另一类是在内网离线服务器上装完系统、必须手工把 Tools 装上去的运维。下文我按实际交付路径写先讲怎么解压和装再讲每个模块怎么验最后把 8.8.0 的老毛病一次说清。2. 解压与安装前准备校验文件、补齐依赖、跑通最小安装动手前把 VMware Tools 的安装套路讲透这个 tar.gz 解压后是一堆 rpm 包、deb 包和一个 Perl 脚本vmware-install.pl。真正的安装不是解压本身而是靠这个脚本调编译器把内核模块现场编出来所以成败大头在编译环境不在解压动作。2.1 先校验完整性再解压sha256 和 tar 命令的最小组合拿到VMwareTools-8.8.0-471268.tar.gz习惯是先用ls -l看体积是否合理再用sha256sum和官方发布值比对防止传输损坏或被人动过手脚。校验通过后解压# 校验文件完整性与发布值比对 sha256sum VMwareTools-8.8.0-471268.tar.gz # 解压到当前目录 tar -xzvf VMwareTools-8.8.0-471268.tar.gz # 确认目录结构 ls -l vmware-tools-distrib/tar的-x是解压-z表示 gzip 解压-v打印过程文件-f指定文件名。解压后你能看到vmware-install.pl、lib、doc和一个installer目录。如果在纯内网环境没有 sha256 基准值至少对比文件大小和中央目录里的文件数量再往后走。注意解压路径不要带中文和空格否则脚本后续找模块路径容易出玄学问题。2.2 依赖三件套gcc、make、kernel headers少一个都白装vmware-install.pl会把内核模块vmhgfs、vmxnet、vmblock 等用本机内核头文件编译进内核树这意味着目标机器必须装好了与当前内核版本严格一致的 kernel-devel/kernel-headers。检查命令# 检查 gcc 与 make gcc --version make --version # 查看当前内核版本 uname -r # 检查内核头文件是否匹配以 el7 为例 ls /usr/src/kernels/$(uname -r)/ rpm -qa | grep kernel-devel如果gcc不存在脚本不会立刻报错而是在编译阶段给出 “Unable to find gcc” 之类提示最容易翻车的是 kernel-devel 没装或版本与uname -r不一致。Debian/Ubuntu 系则用apt-get install linux-headers-$(uname -r)补齐。这一步不要跳我在生产环境见过太多人解压后直接跑脚本卡在编译阶段半小时找不到原因最后一看 kernel-devel 根本没装。2.3 交互式安装最小命令跑通一条默认路径依赖齐了直接以 root 身份运行安装脚本cd vmware-tools-distrib/ sudo ./vmware-install.pl # 非交互模式下可以这样预设 # sudo ./vmware-install.pl -d交互过程中脚本会依次询问安装路径、是否保留旧版本、每个模块是否编译。这里提示一下-d参数让脚本全部取默认值适合路径都在标准位置的干净系统但如果你在自定义内核或容器环境里不要用-d逐项确认更稳。安装完脚本一般会提示Enjoy your VMware Tools或让你重启虚拟机但我建议先别重启花三分钟验证模块和服务的状态因为重启后如果 Tools 起不来你只能通过宿主机控制台去排查操作成本高得多。3. 装完不是终点逐模块验证 vmhgfs、vmtoolsd 和时钟同步很多人装完 VMware Tools 就关机重启然后发现共享目录不生效、宿主机看不到 IP于是怀疑安装失败。实际原因是 VMware Tools 由三块独立的东西组成——内核模块、用户态服务 vmtoolsd、以及一堆配套脚本任何一环没起来都算半残。这一章按模块讲清楚怎么验证。3.1 先验内核模块加载情况lsmod 与 vmware-tools 目录对照模块编译完需要被内核加载验证模块是否真实可用是第一优先# 查看与 vmware 相关的内核模块 lsmod | grep vm # 预期至少出现 vmhgfs、vmxnet、vmw_vmci、vmw_balloon 等 # 查看模块文件确认编译产物 find /lib/modules/$(uname -r) -name vmhgfs* -o -name vmxnet*正常情况lsmod里能看到 vmhgfs 和 vmw_vmci。如果只有模块文件但没有加载多半是加载顺序或配置问题可以手动modprobe vmhgfs但每次重启后要确认系统是否自动加载。从 8.8.0 这个版本开始模块加载已经由用户态服务接管不会在 rc.local 里配 modprobe所以服务起来了模块通常也跟着起来。3.2 vmtoolsd 服务状态与运行日志vmtoolsd 是用户态守护进程负责和宿主机通信、发送心跳、接收宿主机下发的高级指令。检查方式# 检查服务状态不同发行版命令有差异 service vmware-tools status # 或 systemctl status vmware-tools # 查看日志位置 ls -l /var/log/vmware-tools.log tail -100 /var/log/vmware-tools.log日志里重点看有没有vmhgfs挂载失败的段、有没有vmtoolsd起不来但没退出的情况。这里有个容易误判的点service vmware-tools status显示 running 不代表内核模块正常vmtoolsd 起来只是用户态就绪内核模块加载失败它照常运行日志里能看出端倪。我在线上还见过宿主机的虚拟网络适配器类型和模块不匹配导致 vmxnet3 起不来的情况所以验证不能只看服务一个维度。3.3 共享目录与时间同步的二次确认共享目录是最直观的功能指标验证思路是先在宿主机设置共享文件夹再在客户机里看挂载点。时间同步则要看 vmtoolsd 的心跳是否触发宿主机做时钟校准。具体命令# 检查共享目录挂载点是否已挂载 df -h | grep hgfs # 若没有尝试手动挂载 mount -t vmhgfs .host:/ /mnt/hgfs # 检查工具集功能列表 vmware-toolbox-cmd stat speed vmware-toolbox-cmd stat hosttime第 2 条命令能打印宿主机时间和网速如果输出报错说明 vmtoolsd 和宿主机之间的通信不正常要去查防火墙和虚拟机的 VMCI 设置。共享目录挂在/mnt/hgfs下点开能看到宿主机共享名对应的目录如果挂载了但看不到内容多半是共享名带空格或权限不对。这节的操作几乎覆盖了日常使用 VMware Tools 的所有验证路径顺手把这些命令记成一个小脚本以后每装一台机器就刷一遍。4. VMwareTools-8.8.0 安装失败的 5 个常见坑现象、原因、解法一条龙把我在多个 Linux 发行版上装这个版本踩过的坑按“现象 → 原因 → 解决”列在下面每一条都是真实复现过的问题不是理论推演。4.1 坑一交互脚本卡在 What is the location of the directory of C header files现象执行./vmware-install.pl后脚本停在询问 C header 路径的交互上你输入默认路径/usr/src/linux/include也报找不到。原因系统没有安装与当前内核匹配的 kernel headers。脚本会按几个固定路径探测头文件找不到就停下来问用户很多新手以为是什么路径输错了其实根因只是没装开发包。解决先按第 2 章的检查命令确认 kernel-devel/linux-headers装好后再重新执行脚本。这里提醒一点在 CentOS 6 上yum install kernel-devel装的可能不是uname -r对应的版本装完用rpm -qa | grep kernel-devel校验不对就直接列出已安装版本手动匹配。4.2 坑二编译 vmhgfs 模块时提示 Unable to find the vmhgfs source现象安装过程进展到编译 vmhgfs 模块时报找不到源码目录脚本中止或提示需要指定 VMware Tools 源码路径。原因解压后的vmware-tools-distrib目录没有放在脚本默认搜索路径里或者你把目录结构破坏了比如只拷贝了 installer 子目录到别的机器。这个版本的源码目录在vmware-tools-distrib/lib/modules/source下移动或删减都会让脚本找不到。解决回到完整解压目录重新执行安装确认lib/modules/source下的.tar文件都在。我在实际环境中遇到过一次为了节省空间把lib目录挪走导致安装失败老老实实回归原始目录结构就好了。4.3 坑三装完重启后lsmod看不到 vmhgfs共享目录无效现象安装过程无报错服务也 running但/mnt/hgfs不存在lsmod | grep vmhgfs没有任何输出。原因内核模块编译成功后未被自动加载。8.8.0 的模块加载由 vmtoolsd 负责但 vmtoolsd 可能因为 VMCI 设备未开启或宿主机版本不匹配而没有完成加载动作另一种可能是内核模块版本和当前内核不匹配insmod 失败被静默忽略。解决先手动加载并看报错modprobe vmhgfs如果报版本信息不匹配去查模块编译用的内核版本是否和当前uname -r一致。如果确认编译期内核版本没问题检查虚拟机设置里是否禁用了 VMCI 设备开启后重启再试。4.4 坑四安装到最后提示 The configuration of VMware Tools failed现象脚本编译模块全部通过了最后一步配置时报错退出没有打出 Enjoy 提示。原因常见是/etc/vmware-tools或/usr/lib/vmware-tools下残留了旧版本配置文件脚本重写时权限不足或配置冲突导致失败。解决备份旧配置后清理残留再装mv /etc/vmware-tools /etc/vmware-tools.bak mv /usr/lib/vmware-tools /usr/lib/vmware-tools.bak cd vmware-tools-distrib/ sudo ./vmware-install.pl注意如果系统里有旧版 open-vm-tools要先卸载掉否则两个服务抢同一份配置安装时看不出来重启后一定打架。4.5 坑五升级内核后 Tools 失效虚拟机 IP 又在宿主机上消失了现象虚拟机做了内核升级比如yum update后内核从 3.10 升到 3.10.x重启后宿主机看不到了 IPVMware Tools 服务启动失败。原因内核模块是针对旧内核编译的新内核下模块签名校验或版本不匹配加载直接被拒vmtoolsd 连接宿主机失败。解决没有捷径必须重装 VMware Tools让模块对新内核重新编译一遍cd vmware-tools-distrib/ sudo ./vmware-install.pl也可以通过vmware-config-tools.pl单独重新编译模块比全量安装快。如果这套环境不想再为内核升级买运维单建议直接迁移到 open-vm-tools下一章讲取舍。5. 版本对齐与取舍8.8.0 老包和 open-vm-tools 该怎么选维护老环境的人迟早要面对一个选择继续用官方 tar.gz 老包还是换发行版自带的 open-vm-tools。这一章的结论先行centos 7 及更新的系统无脑选 open-vm-tools8.8.0 只在 ESXi 5.x/Workstation 9 时代的老内核上有意义。5.1 build 号 471268 和宿主平台的对应关系VMware Tools 版本号分两段产品版本 8.8.0 和 build 号 471268。前者对外标识功能版本线后者对应具体的 VMware 平台 build。从我的使用经验看471268 出现在 Workstation 9.0 和 ESXi 5.1 同期发布的工具包批次中也就是说这个包主要服务的是 2012-2013 年的宿主平台和同期 Linux 发行版CentOS 6.x、Ubuntu 12.04 等。如果你现在的宿主是 Workstation 15 或 ESXi 6.7 以上继续用 8.8.0 不是不能用但共享目录和剪贴板功能在较新的内核上编译成功率会明显下降vmtoolsd 与宿主机之间的通信协议也可能不兼容。判断方法很简单在宿主机上右键虚拟机点 “Install VMware Tools”如果弹出的安装包版本远高于 8.8.0就没必要用手里这个老包。5.2 从 tar.gz 迁到 open-vm-tools卸载与替换步骤open-vm-tools 是 VMware Tools 的开源版本由发行版维护打包好处是跟随内核版本走不用手动编译模块。替换流程# 卸载老版官方 Tools 前先停服务 sudo service vmware-tools stop # 运行安装目录里的卸载脚本 cd vmware-tools-distrib/ sudo ./vmware-uninstall-tools.pl # 用发行版包管理器安装 open-vm-tools # CentOS/RHEL sudo yum install open-vm-tools # Debian/Ubuntu sudo apt-get install open-vm-tools注意卸载脚本的动作是把内核模块从内核树里移除不是简单删文件。卸载后检查lsmod | grep vm确认没有残留模块再装 open-vm-tools。迁移后共享目录不再叫 /mnt/hgfs而是由 systemd 挂载到/mnt/hgfs的一个变体实现功能等价但如果你有脚本硬编码了挂载路径迁移后要一起改。我见过有人迁完 open-vm-tools 后没改脚本导致共享目录里的定时任务全部静默失败的例子。5.3 迁移时注意三个差异点避免翻车第一名称差异open-vm-tools 的服务叫vmtoolsd而不是vmware-toolssystemd 启用命令是systemctl enable vmtoolsd网上老教程会让你用service vmware-tools start这套在 open-vm-tools 下是不存在的。第二配置目录open-vm-tools 的认证和配置文件在/etc/vmware-tools下但工具命令换成了vmware-toolbox-cmd和vmtoolsd老脚本里调用vmware-toolbox-cmd还兼容但直接用vmware-config-tools.pl的脚本要去掉。第三功能覆盖open-vm-tools 里默认不含 vmhgfs 的某些高级选项比如共享目录的访问控制真需要完整功能的场景建议还是回官方包。综合讲做运维决策时按这个顺序判断——内核版本老、宿主平台老用 8.8.0内核新、宿主平台新直接用 open-vm-tools两者掺杂的以内核能编译通过为第一标准。6. 验证整套安装的最后一招用 debug 日志和一套检查脚本收尾最后分享一个我自己的习惯每次装完 VMware Tools不管哪个版本我都会先开 debug 模式跑一遍再关掉。很多人不看日志出了问题就重装其实 VMware Tools 的日志信息量足够解决绝大多数问题。6.1 临时打开 debug 模式抓现场vmtoolsd支持前台调试模式可以带着-v参数直接运行并输出详细日志到终端# 前台运行调试模式观察输出 sudo vmtoolsd -v -b /var/run/vmware-tools.pid # 配合日志跟踪 sudo tail -f /var/log/vmware-tools.log-v打 verbose 日志-b指定 pid 文件避免与已有服务冲突。生产环境不要常开 debug磁盘会写入大量日志而且带来无谓的 IO。调试完 CtrlC 退出再用service vmware-tools start把服务拉起来。抓日志时要抓重启后的前 30 秒服务起不来和宿主机联系不上的报错都在这段里。6.2 我常用的三分钟检查脚本以下脚本是我的固定动作放到/usr/local/bin/check-vmtools.sh#!/bin/bash # 检查 VMware Tools 三个维度模块、服务、工具命令 echo 1. kernel modules lsmod | grep vm || echo NO VM MODULES FOUND echo 2. service status if systemctl status vmtoolsd /dev/null 21; then echo vmtoolsd is running else echo vmtoolsd not running, check the log fi echo 3. toolbox command vmware-toolbox-cmd stat speed || echo toolbox-cmd failed逻辑很简单第一段查内核模块有没有加载第二段查用户态服务起没起来第三段用 toolbook 命令反向验证 vmtoolsd 与宿主机通信链路。任何一段失败日志定位方向都不一样模块失败看内核编译和加载服务失败看配置文件toolbox 失败看 VMCI 和网络——这个区分能帮你把排查时间从一小时缩小到五分钟。6.3 我踩过的最后一个坑升级前留好后悔药最后交代一个我自己的血泪习惯。那年在一台满是业务的 CentOS 6 虚拟机上重装 VMware Tools我没有保留旧版本的 tar.gz结果新包装完发现 vmtoolsd 和公司内部的监控 Agent 冲突想回滚却找不到旧包最后只能加班降级。自那以后我在每台机器上都留一份当前版本的 VMware Tools 安装包放在/opt/soft下并在/etc/yum.conf或/etc/apt/sources.list里锁住内核版本避免强制升级带来的模块失配。如果你维护的机器不止一台建议顺手写个内网本地源把VMwareTools-8.8.0-471268.tar.gz这类老包统一归档按宿主机版本分目录放后续重装系统就不用再满世界找安装包了。这套习惯不算高深但能帮你把 VMware Tools 从“黑匣子”变成环境里一块可维护的积木。希望帮到你。本文还有配套的精品资源点击获取
返回列表