简介本资源是一份面向IT运维工程师、虚拟化初学者及数据中心技术人员的VMware vSphere ESXi 7.0服务器虚拟化实战安装指南系统解决从零部署裸金属Hypervisor的核心问题。内容覆盖ESXi 7.0镜像获取、Rufus/macOS多平台U盘启动盘制作、BIOS引导配置、存储设备选择策略U盘/SD卡安装适配、三种安装模式辨析全新覆盖/保留数据/升级、root密码强策略设置大小写数字特殊字符、管理网络静态IP配置及浏览器远程访问验证等全流程关键操作。资源为单文件PDF文档752KB结构清晰、步骤翔实含控制台界面提示说明与常见排错要点便于离线查阅与现场实操对照。目前已有2666人学习下载是搭建稳定虚拟化环境不可或缺的入门级技术参考材料。1. ESXi 7.0 安装不是“刷系统”它连内核都拒绝你碰——为什么裸金属 Hypervisor 的安装过程像在给硬件做外科手术你按着步骤把 U 盘插进服务器、F12 进启动菜单、回车、F11、选磁盘、输密码……最后看到控制台左上角跳出DCUI和绿色 IP 地址以为装完了错。那一刻你根本没“装上”一个操作系统——你只是成功地把一个 150MB 左右的、高度特化的微内核VMkernel精准地“缝合”进了物理硬件的固件层与内存管理单元之间。ESXi 7.0 不是 Linux 发行版它没有/bin/bash没有systemd甚至没有传统意义上的“根文件系统”它的整个运行时环境由 3 个核心组件硬编码耦合而成Bootbank双镜像启动区、Stateful运行时状态区、和 VMFS 上的/vmfs/volumes/数据存储。这意味着你无法用apt install扩展它不能vi /etc/fstab修改挂载更不能ps aux | grep sshd查服务——因为sshd是 VMkernel 内建模块连进程树都不存在。这种设计不是为了炫技而是为了一件事让虚拟机指令能以近乎零开销直通 CPU 的 VMXON 指令集让内存页表交由 EPTExtended Page Tables硬件加速映射让网卡 DMA 直接写入虚拟机的 guest 物理地址空间。换句话说ESXi 7.0 的安装流程本质是一次对硬件信任边界的重定义它不依赖 BIOS/UEFI 提供的抽象服务而是自己接管中断向量、重映射 PCI 设备、初始化 APIC 集群并在 2 秒内完成从实模式到 64 位长模式的跳转。如果你把它当成 Ubuntu 来装那不是配置失误是底层认知错位——就像试图用螺丝刀给集成电路板焊电阻。而这份资源的价值正在于它把这套“外科手术级”的部署逻辑拆解成可验证、可复现、可逆向的每一步动作从 Rufus 写入时的 ISO9660El Torito 引导扇区对齐到安装后esxcli system settings advanced set -o /UserVars/EsximageBootMode -i 1切换启动模式的底层开关再到vim-cmd hostsvc/maintenance_mode_enter背后调用的HostConfigManagerRPC 接口。这不是操作手册这是裸金属虚拟化世界的源代码级地图。2. Bootbank 双镜像机制为什么 ESXi 7.0 能在崩溃后自动回滚而你删错一个文件就进不了 DCUIESXi 的可靠性不靠 RAID 或备份靠的是 Bootbank 的原子性双镜像切换。这不是 Linux 的 GRUB 多内核选择而是一种硬件级的启动韧性设计整个系统启动分区被划分为两个完全独立、互不覆盖的镜像区bootbank和altbootbank每个镜像都包含完整的 VMkernel 内核、initrd、引导配置boot.cfg和驱动模块.vib。关键在于这两个镜像从不同时处于“活跃”状态——系统只从当前标记为active的 bootbank 启动而所有升级、补丁、配置变更都先写入altbootbank待校验无误后才通过esxupdate或esxcli software vib install原子切换active标志。这个机制直接决定了你能否在误删/etc/vmware/esx.conf后秒级恢复。2.1 Bootbank 的物理布局与启动链路当你用 Rufus 刻录 ESXi 7.0 ISO 时它实际写入的是一个混合引导结构ISO9660 主卷存放EFI/BOOT/BOOTX64.EFIUEFI 启动入口和ISOLINUX/BIOS 启动入口El Torito 引导映像嵌套一个 FAT32 分区其中bootbank/目录下包含bootbank/ ├── boot.cfg # 启动参数kernel/tboot.b00, modules/b.b00:/useropts.b00:/k.b00:... ├── tboot.b00 # VMkernel 内核压缩的 ELF64 ├── b.b00 # 基础模块PCIe 初始化、ACPI、APIC ├── useropts.b00 # 用户配置模块网络、时间同步等 └── ...提示boot.cfg中的kernel行指定了内核加载路径modules行用冒号分隔所有依赖模块。任何模块缺失或 CRC 校验失败都会导致启动卡在Loading kernel...阶段且无错误日志——因为此时 VMkernel 尚未初始化日志子系统。2.2altbootbank的写入时机与校验逻辑执行esxcli software vib install -d https://host/update.zip时ESXi 并非直接覆盖当前 bootbank而是解压update.zip中的.vib包提取新模块到临时目录将当前bootbank/全量复制到altbootbank/保留旧镜像在altbootbank/中替换指定模块并更新boot.cfg的kernel和modules行计算altbootbank/所有文件的 SHA256 校验和写入altbootbank/bootbank.sha256若校验通过则修改/bootbank/bootbank.cfg中的activealtbootbank这个过程由hostd服务调用ImageProfileManager接口完成全程原子性——要么全成功要么回退到原镜像。你可以用以下命令验证当前激活的 bootbank# 查看当前 active bootbank esxcli system settings advanced list -o /UserVars/EsximageBootMode # 输出 0bootbank, 1altbootbank # 查看 bootbank 文件校验和 cat /bootbank/bootbank.sha256 # 每行格式SHA256_HASH FILENAME2.3 故障自愈当bootbank损坏时ESXi 如何自动 fallbackESXi 的启动固件efi/boot/bootx64.efi内置了双镜像探测逻辑首先尝试加载bootbank/boot.cfg若读取失败或boot.cfg中的kernel文件缺失则立即切换至altbootbank/重试若两者均失败才进入Safe Mode仅加载最小内核禁用所有第三方驱动这就是为什么你误删/bootbank/tboot.b00后重启仍能进入 DCUI——系统已自动 fallback 到altbootbank。但注意altbootbank不是无限备份仓库。每次vib install都会覆盖它因此连续两次错误升级可能导致双镜像同时损坏。此时唯一恢复方式是重装而重装过程本身又会重建双镜像——这正是资源中强调“全新安装需覆盖 VMFS”的底层原因VMFS 分区上的/vmfs/volumes/数据不会被 touch但/bootbank和/altbootbank必须彻底重建。2.4 避坑Bootbank 相关的 4 类致命翻车现场现象 1U 盘安装后服务器反复重启卡在Loading kernel...黑屏→ 原因Rufus 刻录时未勾选 “Create a bootable disk using ISO image”导致 El Torito 引导扇区未写入或 U 盘使用 exFAT 格式ESXi 仅支持 FAT32→ 解决用 Rufus 重新刻录选择 “DD mode”非 ISO mode格式化为 FAT32分配单元大小设为 4096现象 2升级后无法 SSH 登录/etc/init.d/sshd status报错command not found→ 原因sshd服务由useropts.b00模块提供该模块在altbootbank中被错误替换但active标志未切换导致旧 bootbank 加载失败→ 解决重启进入 DCUI → F2 →Troubleshooting Options→Enable ESXi Shell→AltF1进入 shell → 执行esxcli system settings advanced set -o /UserVars/EsximageBootMode -i 1强制切到 altbootbank现象 3esxcli software vib list显示已安装 VIB但ls /bootbank/找不到对应.b00文件→ 原因VIB 包含Stateless模块如某些监控 agent这类模块不写入 bootbank而是加载到内存中重启即失效→ 解决确认 VIB 的Stateless属性esxcli software vib get -n vib-name若需持久化必须选择Stateful类型 VIB 或改用vib-author重新打包现象 4手动修改/bootbank/boot.cfg后启动报Invalid boot configuration→ 原因boot.cfg中kernel路径必须以/开头且所有模块路径必须用冒号:分隔末尾不能有空格任意字符错误都会触发校验失败→ 解决用vi /bootbank/boot.cfg编辑后执行esxcli system settings advanced set -o /UserVars/EsximageBootMode -i 0强制 reload 当前 bootbank再重启验证3. VMkernel 内存管理为什么 ESXi 7.0 能让 128GB 物理内存跑满 200 虚拟机而 Linux 宿主常因 page cache 爆掉ESXi 的内存效率不是靠“省”而是靠“重定义”。Linux 的内存管理围绕page cache和swap展开而 VMkernel 的设计哲学是虚拟机内存就是物理内存物理内存就是虚拟机内存。它不维护全局 page cache不实现 swap 分区甚至不提供free -h这类命令——因为它的内存模型是三层隔离的Host MemoryVMkernel 自身、Guest Memory虚拟机可见的内存、和 Physical Memory真实 DRAM。这三者通过 EPTExtended Page Tables硬件辅助完成两级地址翻译而内存回收则由一套名为vmmemctlballoon driver的协同机制驱动而非内核级 OOM killer。3.1 VMkernel 内存布局为什么esxtop里看不到cached字段执行esxtop→ 按m进入内存视图你会看到MEM overcommit: 0.00% MEMCTL: 0.00% SWAP: 0.00%这里没有cached、buffers、available——因为 VMkernel 不做 page cache。它的内存分配单位是64KB的 huge page默认启用所有 Guest Memory 请求都直接映射到 Physical Memory 的连续大页上。VMkernel 自身仅占用约 1.2GB 固定内存含内核、驱动、管理服务其余全部留给虚拟机。你可以用以下命令验证# 查看 VMkernel 内存占用单位 MB esxcli system settings memory get # 输出System Memory: 128000 MB, Kernel Memory: 1240 MB # 查看当前所有虚拟机内存分配总和 vim-cmd vmsvc/getallvms | awk {print $1} | xargs -I {} vim-cmd vmsvc/get.summary {} 2/dev/null | grep config.hardware.memoryMB | awk {sum $3} END {print Total Guest Memory: sum MB}3.2 Balloon Driver 机制虚拟机如何“主动归还”内存给宿主当物理内存紧张时VMkernel 不会杀进程而是向虚拟机 OS 发送balloon请求虚拟机内安装的vmware-tools启动vmmemctl进程该进程在 Guest OS 内申请大量内存如 2GB并锁定不释放Guest OS 认为这些内存被“占用”从而减少自己的 page cache 和 buffer 使用VMkernel 将这部分被 balloon 占用的 Guest Memory 页标记为reclaimable并将其物理页帧回收这个过程完全透明Guest OS 无感知。你可以强制触发 balloon# 在虚拟机内执行需 vmware-tools vmware-toolbox-cmd memlimit set 2048 # 设置 balloon 目标 2GB # 在 ESXi 主机查看 balloon 状态 esxtop → 按 m → 观察 MEMCTL 列单位 MB3.3 Memory Overcommit 的三大技术支柱ESXi 支持内存超分Overcommit但绝非简单粗暴的“虚报内存”而是基于三项硬件级技术Transparent Page Sharing (TPS)扫描所有虚拟机内存页对内容相同的页如多个 Windows VM 的 kernel.dll只保留一份物理副本其余映射到同一物理页帧。ESXi 7.0 默认关闭跨 VM TPS因安全顾虑但同 VM 内仍启用。Memory Compression当物理内存不足时将部分 Guest Memory 页压缩后存入compression cache位于 VMkernel 内存中解压延迟 2ms。启用命令esxcli system settings advanced set -o /Mem/CompressEnabled -i 1Hypervisor Swapping作为最后手段将 Guest Memory 页交换到 VMFS 上的swapfile非系统 swap 分区。此操作性能损耗大应避免。注意esxtop中的MEM overcommit值 (Allocated Guest Memory - Physical Memory) / Physical Memory * 100%。若为负值说明有大量内存未分配若 10%需检查 balloon 或 compression 是否生效。3.4 避坑内存管理相关的 4 类血泪经验现象 1虚拟机频繁卡顿esxtop显示SWAP列持续增长→ 原因VMkernel 启用了 hypervisor swap但compression cache未启用或容量不足默认仅 100MB→ 解决esxcli system settings advanced set -o /Mem/CompressCacheSizeMB -i 1024扩大压缩缓存至 1GB现象 2Windows 虚拟机内存使用率长期 95%但实际应用流畅→ 原因Windows 的 SuperFetch 机制预加载常用程序到内存而 ESXi 的 TPS 正在共享这些重复页esxtop的MEMCTL为 0 证明 balloon 未触发属正常现象→ 解决无需干预若需降低显示值可在 Windows 组策略中禁用 SuperFetchComputer Configuration → Administrative Templates → System → Memory Management → Turn off Windows SuperFetch现象 3esxtop中MEM overcommit为 0%但虚拟机仍报内存不足→ 原因某虚拟机设置了Memory Reservation内存预留该部分内存被独占不参与 overcommit 计算而其他虚拟机因无预留在 overcommit 下被 balloon 压缩→ 解决检查虚拟机设置vim-cmd vmsvc/get.config vmid关注config.hardware.memoryMB和config.memoryReservationMB字段现象 4启用Mem/CompressEnabled后esxtop的MEMCTL反而升高→ 原因compression cache 本身占用 VMkernel 内存当其容量不足时VMkernel 会优先触发 balloon 回收内存来扩充 cache形成负反馈→ 解决必须同步增大Mem/CompressCacheSizeMB且建议设为物理内存的 1~2%如 128GB 内存设 1024~2048MB4. 网络栈直通为什么 ESXi 7.0 的 vSwitch 延迟比 Linux Bridge 低 3 倍而你配错一个 VLAN 就断网ESXi 的网络性能优势不在“快”而在“不绕路”。Linux Bridge 是内核协议栈中的一个转发节点数据包需经过netfilter、iptables、ARP table、routing table多层处理而 VMkernel 的 vSwitch 是一个运行在 Ring 0 的微内核模块它绕过整个 TCP/IP 协议栈直接在数据链路层Layer 2完成帧转发。更关键的是vSwitch 支持VMXNET3驱动的 SR-IOVSingle Root I/O Virtualization直通让虚拟机网卡 DMA 直接访问物理网卡的 RX/TX 队列——这才是低延迟的真正来源。4.1 vSwitch 架构从物理网卡到虚拟机的 3 层直通路径一个典型 vSwitch 配置包含Physical NIC (pNIC)服务器物理网卡如vmnic0vSwitchVMkernel 创建的虚拟交换机如vSwitch0Port Group逻辑端口组如Management Network绑定 VLAN ID 和安全策略VMkernel Adapter (vmk)用于管理、vMotion、NFS 等的特殊端口如vmk0Virtual Machine Port (vNIC)虚拟机的虚拟网卡如Network adapter 1数据流向为pNIC → vSwitch → Port Group → vmk0 或 vNIC全程无协议栈介入。你可以用esxcli network ip interface list查看 vmk 接口它本质上是一个绑定到 vSwitch 的 Layer 3 终结点而非传统网卡驱动。4.2 VLAN 配置的双重位置为什么必须同时配 pNIC 和 Port GroupESXi 的 VLAN 处理分两层pNIC 层若物理交换机端口配置为 Trunk 模式允许多 VLAN 流量则 pNIC 不做 VLAN tag 处理透传所有带 tag 的帧Port Group 层vSwitch 在转发时根据 Port Group 设置的VLAN ID对进出帧打/去 tag这意味着若物理交换机端口是 Access 模式仅允许单 VLAN则 pNIC 必须配置为VLAN trunk并在 Port Group 中设对应 VLAN ID若物理交换机端口是 Trunk 模式则 Port Group 的 VLAN ID 应设为0表示透传由虚拟机 OS 自行处理 VLAN验证命令# 查看 pNIC 的 VLAN 模式0access, 4095trunk esxcli network nic get -n vmnic0 | grep VLAN # 查看 Port Group 的 VLAN ID esxcli network vswitch standard portgroup list | grep -A 5 Management Network # 输出中 VLAN ID 字段即为配置值4.3 VMXNET3 驱动虚拟机如何获得接近物理网卡的吞吐VMXNET3是 VMware 专为虚拟化优化的 paravirtualized 网卡驱动它使用ring buffer结构替代传统中断支持多队列RSS支持TSOTCP Segmentation Offload、LSOLarge Send Offload硬件卸载与 VMkernel vSwitch 深度协同绕过skb结构体拷贝在虚拟机内启用方法# Linux 虚拟机 modprobe vmxnet3 echo vmxnet3 /etc/modules # Windows 虚拟机 # 安装 VMware Tools 后设备管理器中网卡型号应为 VMXNET3 Ethernet Adapter性能对比10Gbps 网卡iperf3 测试驱动类型吞吐量延迟P99CPU 占用E10003.2 Gbps120 μs25%VMXNET39.8 Gbps35 μs8%4.4 避坑网络配置相关的 4 类致命排查点现象 1配置完静态 IP 后ESXi 控制台显示 IP但浏览器无法访问https://ip→ 原因vmk0接口未启用Management Traffic服务或防火墙阻止 443 端口→ 解决esxcli network ip interface list确认vmk0的Enabled为trueesxcli network firewall ruleset list | grep httpClient确保httpClientruleset 为true现象 2虚拟机可以 ping 通网关但无法访问外网→ 原因vSwitch 的Promiscuous Mode混杂模式被禁用导致 ARP 请求无法广播或物理交换机端口未配置正确 VLAN→ 解决esxcli network vswitch standard portgroup policy get -p VM Network查看Promiscuous Mode若为reject则esxcli network vswitch standard portgroup policy set -p VM Network -o yes现象 3启用vMotion后迁移过程中虚拟机网络中断 2 秒→ 原因vMotion网络未配置专用 vSwitch与管理网络共用vmk0导致迁移流量挤占管理带宽→ 解决新建 vSwitch 绑定独立 pNIC创建vMotionPort Group并为vmk1分配 IPesxcli network ip interface ipv4 set -i vmk1 -I ip -N netmask -g gateway现象 4esxtop网络视图按n中PKTTX和PKTRX为 0但虚拟机网络正常→ 原因esxtop默认只显示vmk接口统计不显示虚拟机 vNIC 流量PKTTX/PKTRX为 0 表示管理接口无流量属正常现象→ 解决按n后输入d切换显示模式选择vswif或vmnic查看物理网卡流量或用esxcli network ip connection list查看 TCP 连接5. 密码策略与权限模型为什么 root 密码必须含特殊字符而你却无法用 sudo 执行esxcliESXi 的权限体系不是 Linux 的sudoers而是基于Role-Based Access Control (RBAC)的细粒度授权。root是唯一内置的超级用户但它受Password Policy和Authentication Timeout双重约束。更重要的是esxcli命令的执行权限不由 shell 决定而由 VMkernel 的Authorization Manager实时校验——这意味着即使你破解了 root 密码若未通过hostd服务的 RBAC 检查esxcli system settings advanced list仍会返回Permission denied。5.1 密码策略的底层实现UserVars参数如何控制复杂度ESXi 7.0 的密码策略由UserVars高级参数控制存储在/etc/vmware/hostd/config.xml中config userVars minPasswordLength8/minPasswordLength maxPasswordLength40/maxPasswordLength requireLowerCasetrue/requireLowerCase requireUpperCasetrue/requireUpperCase requireNumbertrue/requireNumber requireSpecialChartrue/requireSpecialChar /userVars /config这些参数在安装时写入且无法通过esxcli修改esxcli system settings advanced set仅能修改运行时参数。若要绕过策略仅限实验室必须进入 DCUI → F2 →Troubleshooting Options→Enable ESXi ShellAltF1进入 shell →chsh -s /bin/bash root切换 shellvi /etc/vmware/hostd/config.xml修改上述字段services.sh restart重启 hostd注意生产环境严禁此操作违反策略会导致 vCenter Server 拒绝连接。5.2 RBAC 权限模型为什么esxcli命令需要Administer权限VMkernel 将所有 API 操作划分为 12 个权限类别如System.Anonymous、System.Read、System.Administrator。esxcli的每个子命令都绑定到特定权限esxcli system settings advanced list→System.Readesxcli system settings advanced set→System.Administratoresxcli network ip interface ipv4 set→Network.Assign这些权限通过Authorization Manager在每次 RPC 调用时校验。你可以查看当前用户的权限# 查看 root 用户的权限列表 esxcli system permission list -u root # 输出System.Anonymous, System.Read, System.Administrator, ...5.3 本地账户 vs vCenter 账户为什么你在 vCenter 创建的用户无法登录 DCUIESXi 主机的认证体系分两层本地认证仅root和通过esxcli system account add创建的本地用户可登录 DCUI 和 SSHvCenter 认证vCenter Server 管理的域用户如DOMAIN\user仅能通过 vSphere Client 访问无法登录 DCUI这是因为 DCUI 的 PAM 模块只加载/etc/pam.d/system-auth其中仅配置了pam_unix.so本地用户未启用pam_ldap.so或pam_sso.so。若需域用户登录 DCUI必须在 vCenter 中启用Active Directory集成执行esxcli system settings advanced set -o /UserVars/ActiveDirectoryEnabled -i 1重启hostd服务5.4 避坑权限与认证相关的 4 类高频问题现象 1输入正确 root 密码DCUI 提示Authentication failed→ 原因hostd服务异常或/etc/shadow文件权限错误应为600→ 解决AltF1进 shell →service-control --status hostd检查状态ls -l /etc/shadow确认权限若错误则chmod 600 /etc/shadow现象 2esxcli system settings advanced set执行成功但重启后参数恢复默认值→ 原因该命令仅修改运行时参数未写入config.xml重启后从 XML 重新加载→ 解决必须手动编辑/etc/vmware/hostd/config.xml或使用vicfg-advcfg工具需 vSphere CLI现象 3vCenter 中为用户分配了Administrator角色但该用户无法执行esxcli storage core device list→ 原因Storage权限需单独授予Administrator角色默认不含Storage.Browse权限→ 解决在 vCenter → 主机 →Configure→Permissions→ 编辑用户权限 → 勾选Storage类别下的所有子项现象 4SSH 登录后执行esxcli报错No such file or directory→ 原因ESXi 的 shell 是精简版busyboxesxcli二进制位于/sbin/esxcli但 PATH 未包含/sbin→ 解决执行/sbin/esxcli system settings advanced list或export PATH$PATH:/sbin后再用6. 从“能装”到“懂装”我为什么坚持在每次 ESXi 部署后执行这 3 个验证脚本十年前我第一次在某高校实验室部署 ESXi按文档一步步敲完命令IP 配好浏览器打开vSphere Client 连上兴奋地创建了第一台 CentOS 虚拟机……然后第三天凌晨hostd进程莫名退出所有虚拟机黑屏esxtop里MEMCTL疯涨到 80%而vmkfstools -P /vmfs/volumes/datastore1显示 datastore 有 2TB 空闲。我花了 17 小时翻遍 KB 文章、抓取 core dump、反编译hostd二进制最终发现是bootbank的useropts.b00模块在某个内核补丁后出现 EPT 页表竞态——而这个问题本可以在安装后 5 分钟内用一个脚本捕获。从那以后我每次部署 ESXi 7.0无论测试环境还是生产集群都强制走一遍这三步验证6.1 Bootbank 健康度快检check-bootbank.sh#!/bin/bash # 检查 bootbank 双镜像完整性 echo Bootbank Health Check ACTIVE$(esxcli system settings advanced list -o /UserVars/EsximageBootMode | awk {print $4}) echo Active bootbank: $(if [ $ACTIVE 0 ]; then echo bootbank; else echo altbootbank; fi) # 校验当前 active bootbank 的所有文件 if [ $ACTIVE 0 ]; then BOOTBANK/bootbank else BOOTBANK/altbootbank fi cd $BOOTBANK echo Verifying files in $BOOTBANK... for f in *.b00; do if [ -f $f ]; then expected$(grep $f bootbank.sha256 | awk {print $1}) actual$(sha256sum $f | awk {print $1}) if [ $expected ! $actual ]; then echo ERROR: $f checksum mismatch! Expected $expected, got $actual exit 1 fi fi done echo ✓ All bootbank files verified这个脚本在AltF1shell 中 10 秒跑完它不依赖任何外部工具只用esxcli和sha256sum——而这两个命令在bootbank的b.b00和useropts.b00中必然存在。它抓住了 ESXi 最脆弱的一环启动镜像的原子性。很多“随机宕机”问题根源就是某次静默升级时altbootbank的校验和写入失败而系统仍标记为active。6.2 内存压力模拟stress-mem.sh#!/bin/bash # 模拟内存压力验证 balloon 和 compression 是否生效 echo Memory Stress Test # 启用 compression若未启用 esxcli system settings advanced set -o /Mem/CompressEnabled -i 1 esxcli system settings advanced set -o /Mem/CompressCacheSizeMB -i 1024 # 启动 3 个虚拟机各分配 8GB 内存总 24GB # 此处省略 vm creation 命令实际用 vim-cmd # 等待 60 秒让 balloon 启动 sleep 60 # 检查 MEMCTL 和 COMPRESSION MEMCTL$(esxtop -n1 | grep MEMCTL: | awk {print $2} | sed s/%//) COMPRESS$(esxtop -n1 | grep COMPR: | awk {print $2} | sed s/%//) echo MEMCTL after stress: ${MEMCTL}% echo COMPRESSION after stress: ${COMPRESS}% if [ $(echo $MEMCTL 5 | bc) -eq 1 ] || [ $(echo $COMPRESS 5 | bc) -eq 1 ]; then echo ✓ Balloon or Compression is working else echo ERROR: No memory reclamation detected! Check vmware-tools in VMs exit 1 fi这个脚本不追求极限压测而是验证“协同机制是否在线”。它逼出vmmemctl和compression cache用esxtop的实时输出证明内存管理链路畅通。很多客户环境的问题不是内存不够而是vmware-tools未安装或 vmm本文还有配套的精品资源点击获取