尧图网页设计 
简介面向VMware虚拟化运维人员与系统管理员Win11安装VMware PowerCLI资源包提供了完整的环境部署组件与自动化管理工具。包内共2000个文件以PowerShell脚本(ps1)为核心配合psd1/psm1模块定义、dll运行库、xml/json配置文件和cat安全目录等整体压缩包约143.15MB可支持从安装到调用的全流程操作。已有230人学习下载内容贴合Windows 11环境下的实际部署需求。资源中不仅包含GuestDiskExpansion等磁盘扩展脚本还整合了vCenter、ESXi、ImageBuilder等多类管理模块并附带验证命令与模块清单方便读者快速搭建PowerCLI工作环境、确认安装结果进而实现虚拟机创建、存储配置、健康监控等日常自动化任务。 写这篇文章的起因特别简单我在新换的 Win11 笔记本上执行Install-Module VMware.PowerCLI结果被一堆报错折腾到怀疑人生。VMware PowerCLI 说白了就是管理 vSphere 环境那一套 PowerShell 命令行工具装好之后你在终端里敲命令就能批量处理虚拟机、宿主机、存储、网络这些资源比在 vCenter 的 Web 界面里点鼠标效率高出一个量级尤其适合几十台甚至上百台虚拟机需要批量开机、批量改配置、批量打标签的场景。这篇文章就是写给刚接触虚拟化运维、想在 Win11 上用命令行管理 VMware 环境的人也顺手帮被 Windows 平台各种权限报错折腾到崩溃的老伙计们避个坑。国内网络环境下从 PowerShell Gallery 拉模块经常超时或者断流这个问题我会单独拎出来讲属于必踩的坑。整体内容按照环境准备→安装执行→连接配置→问题排查的顺序走每一步都附带我实际操作的记录和参数解释你可以照着敲也可以根据自己的环境调整。1. 装之前先给 Win11 环境把把关1.1 版本选择和前置条件PowerCLI 从 12.0 开始改用了年份命名规则后面大版本直接跟着实际发布节奏走比如 12.x、13.x 这种。不同大版本对 PowerShell 版本的要求不一样装之前如果不先确认版本要求很容易出现装上了但用不了的尴尬局面。我这里直接给一个简洁的对照说明方便你判断PowerCLI 大版本最低 PowerShell 版本推荐环境12.0Windows PowerShell 5.1 或 PowerShell 7.0.3Win11 自带 5.1但建议用 7.x12.1 ~ 12.7PowerShell 7.0.3建议 PowerShell 7.213.0PowerShell 7.2建议 PowerShell 7.3/7.4我在 Win11 上实测发现Win11 自带的 Windows PowerShell 5.1 确实能装 PowerCLI 12.0但后面使用Connect-VIServer连接新版 vCenter 的时候容易遇到 TLS 协议不匹配的报错而且 5.1 对很多 REST API 接口的支持不如 PowerShell 7 干净。所以我建议直接用 PowerShell 7这也和当前 VMware 官方主推的方向一致。安装 PowerShell 7 的方法很简单在 Win11 的 Microsoft Store 里搜PowerShell装那个由微软发布的版本或者去 GitHub 的 PowerShell 仓库下载 win-x64.msi 安装包装完在终端里输入pwsh就能进入 PowerShell 7 环境。注意区分Windows PowerShell 5.1 的终端是蓝色的PowerShell 7 的终端通常是黑色的别搞混。1.2 执行策略和模块路径检查PowerShell 默认的执行策略是Restricted也就是禁止运行任何脚本而Install-Module需要执行模块安装脚本所以第一件事就是放开执行策略。用管理员身份打开 PowerShell 7执行下面的命令Get-ExecutionPolicy如果输出是Restricted或者AllSigned就需要改成RemoteSigned。RemoteSigned的意思是本地脚本可以运行从网上下载的脚本必须经过签名才能运行这是安全性比较平衡的一个策略Set-ExecutionPolicy RemoteSigned -Scope CurrentUser-Scope CurrentUser只对当前用户生效不需要动系统级策略避免影响其他用户。其实Install-Module这个操作本身只是把模块文件下载到指定目录再导入如果后续还有模块自动加载脚本或者你自己写了 ps1 脚本调用 PowerCLI就会触发执行策略限制提前改好一劳永逸。接下来确认一下模块安装路径。PowerCLI 安装后会默认放到当前用户的Documents\PowerShell\Modules目录下这也是 PowerShell 7 的默认用户级模块路径。查看方式$env:PSModulePath输出会包含多个路径用分号分隔其中至少有一个是你当前用户的路径。这个路径决定了Import-Module能不能找到你安装的 PowerCLI。如果你之前用过旧版 PowerCLI而旧版是装在C:\Program Files\WindowsPowerShell\Modules这种系统级路径下的那会出现同一台机器里存在两个 PowerCLI 版本的情况后面 Import 的时候会加载到旧版本这类问题在常见问题部分我会专门说。2. 执行安装步骤和加速方案2.1 直接安装与参数解读环境检查没问题之后进入安装环节。PowerCLI 是通过 PowerShell Gallery 发布的模块标准安装命令就一行Install-Module -Name VMware.PowerCLI -Scope CurrentUser这里有几个参数需要解释清楚。-Scope CurrentUser指定安装到用户级目录不写这个参数在某些情况下会默认走AllUsers路径那就需要管理员权限。-Name模块名称必须是VMware.PowerCLI这个模块是一个元模块安装它的时候会把 VMware 家的一堆子模块一并拉下来包括VMware.VimAutomation.Core、VMware.VimAutomation.Cis.Core、VMware.VimAutomation.Storage、VMware.VimAutomation.Srm、VMware.VimAutomation.Nsxt等等所以这个模块的体积比较大安装过程需要从远程仓库拉不少文件。如果中间遇到 NuGet 版本过低或者 PowerShellGet 版本过老的提示先更新一下包管理组件Install-Module -Name PowerShellGet -Force -Scope CurrentUser-Force参数会强制覆盖安装最新版本新装的 PowerShellGet 会自带新版 NuGet provider。装完之后需要重开一个终端窗口让新组件生效。2.2 国内网络环境下的安装加速这是整个安装流程里最让人头疼的一步。PowerShell Gallery 的仓库服务器在国外国内直连下载 PowerCLI 这种一百多兆的模块包经常下到一半连接断开或者直接超时报PackageManagement\Install-Package : 无法解析远程名称这类错误。我试过在命令行设置代理也试过挂镜像源最后发现最稳的方式是使用国内可用的 NuGet 镜像源。给你一套我实测能用的大致加速方法在 PowerShell 里手动添加一个 NuGet 包源指向国内镜像地址然后安装模块时指定这个镜像源。具体执行方式Register-PSRepository -Name LocalMirror -SourceLocation https://nuget.cdn.azure.cn/v3/index.json -InstallationPolicy Trusted注意这里的镜像地址属于公共 NuGet 镜像不同地区访问稳定性有差异如果这个源不可用建议换一个可用的 NuGet 镜像地址核心思路就是让安装包下载走国内可达的 CDN 节点。执行完上面这一行之后用指定仓库安装Install-Module -Name VMware.PowerCLI -Scope CurrentUser -Repository LocalMirror -Force-Repository LocalMirror会让 PowerShellGet 只从这一个指定仓库搜索和下载模块避免默认仓库优先导致又重新走境外线路。我按照这个方式实测安装速度从百分之五就断开提升到了两三分钟全量装完。装完之后可以执行Get-Module -ListAvailable VMware.PowerCLI确认版本信息。2.3 验证安装结果模块装完不代表万事大吉需要确认模块能被正常加载。执行Import-Module VMware.PowerCLI首次导入会比较慢因为元模块要加载一堆子模块屏幕可能会卡住几秒到十几秒这是正常现象别急着 CtrlC。如果导入过程中出现红色报错大概率是依赖模块没有装全或者版本冲突。导入成功后再执行一下Get-Command -Module VMware.PowerCLI | Select-Object Name | Measure-Object这条命令统计当前模块暴露了多少个可用的 cmdlet正常情况应该有几百个如果你看到数量明显偏少比如只有几十个那说明部分子模块加载失败通常和 PowerShell 版本或者 TLS 设置有关具体排查方法在后面章节细说。3. 连接 vCenter 或 ESXi 的首次配置3.1 处理证书信任和 CEIP 提示PowerCLI 安装好之后第一件事就是连接 vCenter 或者 ESXi 主机。连接命令是Connect-VIServer但第一次执行几乎必弹证书确认提示因为 vmware 默认使用的 TLS 证书不是 Windows 系统公共证书库信任的 CA 签发的PowerCLI 会因为你没信任这个证书而直接拒绝连接。直接修改 PowerCLI 的配置项可以跳过证书检查对于内部测试环境来说是省事的选择Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false-InvalidCertificateAction Ignore的含义是遇到非法证书时不阻断连接-Confirm:$false避免执行过程中反复弹确认。这里我需要多说一句生产环境强烈不建议关闭证书信任检查比较稳妥的做法是把 vCenter 的 CA 证书导入到 Windows 的受信任的根证书颁发机构存储区这样既有证书校验又能正常连接。首次连接还会遇到CEIP客户体验改善计划的提示配置项里默认会问你是否愿意加入。在自动化和无人值守场景下这个交互提示会卡住脚本所以建议提前关掉Set-PowerCLIConfiguration -ParticipateInCEIP $false -Confirm:$false3.2 连接命令和常用初始化选项配置完成之后就可以正式连接了。连接 vCenter 为例Connect-VIServer -Server vcenter.example.com -User administratorvsphere.local -Password 你的密码这里注意-User参数在连接 vCenter 时要用 UPN 格式也就是administratorvsphere.local这种。如果连接的是 ESXi 主机用户名直接用root就行。密码写在命令行里有泄露风险我建议在交互式终端里直接执行不带-Password的Connect-VIServer这样 PowerShell 会弹出安全输入提示密码以掩码方式录入会更安全。连接成功后PowerCLI 的$global:DefaultVIServer变量会自动持有当前连接的服务器对象后续跑Get-VM、Get-VMHost这些命令时默认就在这个连接上执行不需要每次都指定-Server。如果日常使用过程中不需要某些大型子模块比如 SRMSite Recovery Manager或 NSX-T可以通过配置延迟加载机制来减少启动时间。在 PowerShell profile 里设置环境变量指定启动时只加载核心模块$env:POWERCLI_CONFIGURATION_FLOW_CONTROL Minimal这个配置项对不同版本的 PowerCLI 支持程度不同如果你的版本不识别该参数忽略即可不会影响主流程。3.3 断开连接与会话管理操作的收尾同样重要用完记得断开连接释放服务端的会话资源特别是脚本里开了多个连接的时候不主动断开会在 vCenter 上留下大量无用的会话Disconnect-VIServer -Server * -Force -Confirm:$false-Server *表示断开所有连接的服务器-Force表示即使有依赖也会强制断开。在长期跑批任务的脚本里建议在脚本结束前统一执行这段清理逻辑避免后续任务因为会话数量达到上限而连接失败。4. 常见问题与排查技巧实录4.1 Install-Module 报错和网络超时这是我在 Win11 上安装时遇到的第一个问题报错信息大致是PackageManagement\Install-Package: 未能解析此远程名称: www.powershellgallery.com很明显就是网络不通不是命令写错。这时候不要反复重试默认仓库直接用我前面说的镜像源方案。如果镜像源也不稳定还可以考虑用离线包方式在一台网络环境好的机器上用Save-Module -Name VMware.PowerCLI -Path C:\modules把模块保存成文件夹然后再用 U 盘或者内网传输工具拷贝到目标机器放到本机模块目录里Import-Module就能识别。这个方式适合离线环境也适合网络长期不稳定的场景。4.2 模块加载慢和子模块不全如果你执行Import-Module VMware.PowerCLI时等待时间过长可能是首次加载需要初始化所有子模块导致的。Win11 上尤其明显因为系统每次导入模块时还要检查模块签名的有效性。加载慢的解决办法是把不需要的子模块排除掉只导入核心模块Import-Module VMware.VimAutomation.Core Import-Module VMware.VimAutomation.Cis.CoreVMware.VimAutomation.Core包含虚拟机、宿主机、存储等核心管理 cmdlet对于大部分日常操作已经足够。如果你的任务只涉及虚拟机生命周期管理直接用这个模块就能跑起来加载速度能提升一倍以上。子模块数量偏少还有一个隐藏原因PowerShell 7 的模块加载机制会按 CPU 架构区分路径如果你安装的是 x64 版 PowerShell但之前通过某些兼容模式运行了 x86 版的 PowerShell模块路径会被重定向导致导入不到正确的模块。排查方式是先确认当前$PSVersionTable.Platform的输出是否包含Win32NT以及[System.Runtime.InteropServices.RuntimeInformation]::ProcessArchitecture是不是X64。4.3 与旧版 PowerCLI 的冲突老运维机器上多半装过 PowerCLI 6.5 或者 10.x 这些旧版本Win11 上直接升级安装新版新旧模块文件会同时存在于不同路径。有时候Get-Module -ListAvailable VMware.PowerCLI返回多个版本而Import-Module加载到的却是旧版导致部分新 cmdlet 找不到。正确做法是把旧版模块目录整个删除卸载干净再装新版。旧版默认的位置通常在C:\Program Files\WindowsPowerShell\Modules\VMware* C:\Program Files (x86)\VMware\Infrastructure\PowerCLI删除前先确认Get-Module -ListAvailable列出的 ModuleBase 路径只删对应版本目录不要误删还在使用的新版文件。清理完后重开终端再执行Install-Module装新版。4.4 PowerShell 5.1 与 PowerShell 7 混用造成的怪问题我在 Win11 上还遇到过一个诡异情况明明安装成功了但只有pwsh里能用Connect-VIServer在 Windows PowerShell 5.1 里却提示命令不存在。原因是 PowerCLI 12.1 之后的版本对模块清单文件PSModuleInfo的声明做了调整只允许 PowerShell 7 加载5.1 直接拒绝。如果你确实需要在 Windows PowerShell 5.1 里使用 PowerCLI只能安装 12.0 版本并且要在 5.1 环境里重新执行Install-Module让模块落盘到 5.1 对应的模块目录不能跨版本共享模块文件。我在两个终端环境之间切换时就因为共用同一个模块目录吃过亏最后是分开目录各装各的才解决。5. 版本升级和卸载重装的正确姿态PowerCLI 的迭代步伐不算慢尤其是大版本升级时直接把旧版本覆盖式升级往往会在依赖包上出问题。更推荐的方式是彻底卸载旧版本再安装Get-Module -ListAvailable VMware.PowerCLI | Uninstall-Module -ForceUninstall-Module只会移除模块本身不会自动清理旧版依赖的子模块所以在卸载 PowerCLI 元模块之后还需要手动查看VMware.*开头的模块还有哪些然后逐一卸载Get-Module -ListAvailable VMware.* | Uninstall-Module -Force执行这个命令的时候注意确认列表里没有你自己写的自定义模块避免误删。卸载干净之后再按前面的流程安装新版就能减少大量来源不明的报错。升级到新版本后之前保存的 PowerCLI 配置文件通常可以继续使用内容存储在%APPDATA%\VMware\PowerCLI\目录下如果需要完全回到默认状态把这个目录备份后清空PowerCLI 会在下次启动时重新生成默认配置。6. 结合 Win11 场景的几点实操心得最后分享几个在 Win11 这个环境下特有的小经验。Win11 的终端默认是 Windows Terminal它有一个特性如果你之前用管理员权限打开了 Windows Terminal 窗口那后续在这个窗口里启动的所有 PowerShell 标签页都继承管理员权限这时候执行Install-Module会走系统级路径和你平时普通权限安装的模块路径不一致容易引发模块找不到的错乱。我的习惯是安装和日常使用分离安装时用管理员权限日常使用用普通权限两个窗口分开。还有一个 Win11 系统本身的问题休眠和快速启动会导致系统时间漂移而 VMware 的连接协议里对时间同步要求比较严格容易出现SSL: CERTIFICATE_VERIFY_FAILED这类报错。如果你安装了 PowerCLI 之后连接时偶尔报时间相关的证书错误先检查一下系统时间是不是漂移了同步时间后再连接基本就正常了。另外建议给自己的 PowerShell profile 里加一行初始化配置每次打开终端自动加载 PowerCLI 核心模块省去手动Import-Module的麻烦# 编辑 profile notepad $PROFILE在打开的 profile 文件里加入Import-Module VMware.VimAutomation.Core -ErrorAction SilentlyContinue Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false Set-PowerCLIConfiguration -ParticipateInCEIP $false -Confirm:$false-ErrorAction SilentlyContinue的作用是模块不存在时不让报错刷屏。这样配置好之后终端一开就可以直接敲Connect-VIServer使用效率会高不少。本文还有配套的精品资源点击获取 Win11安装VMware PowerCLI避坑指南：从环境配置到连接vCenter
简介面向VMware虚拟化运维人员与系统管理员Win11安装VMware PowerCLI资源包提供了完整的环境部署组件与自动化管理工具。包内共2000个文件以PowerShell脚本(ps1)为核心配合psd1/psm1模块定义、dll运行库、xml/json配置文件和cat安全目录等整体压缩包约143.15MB可支持从安装到调用的全流程操作。已有230人学习下载内容贴合Windows 11环境下的实际部署需求。资源中不仅包含GuestDiskExpansion等磁盘扩展脚本还整合了vCenter、ESXi、ImageBuilder等多类管理模块并附带验证命令与模块清单方便读者快速搭建PowerCLI工作环境、确认安装结果进而实现虚拟机创建、存储配置、健康监控等日常自动化任务。 写这篇文章的起因特别简单我在新换的 Win11 笔记本上执行Install-Module VMware.PowerCLI结果被一堆报错折腾到怀疑人生。VMware PowerCLI 说白了就是管理 vSphere 环境那一套 PowerShell 命令行工具装好之后你在终端里敲命令就能批量处理虚拟机、宿主机、存储、网络这些资源比在 vCenter 的 Web 界面里点鼠标效率高出一个量级尤其适合几十台甚至上百台虚拟机需要批量开机、批量改配置、批量打标签的场景。这篇文章就是写给刚接触虚拟化运维、想在 Win11 上用命令行管理 VMware 环境的人也顺手帮被 Windows 平台各种权限报错折腾到崩溃的老伙计们避个坑。国内网络环境下从 PowerShell Gallery 拉模块经常超时或者断流这个问题我会单独拎出来讲属于必踩的坑。整体内容按照环境准备→安装执行→连接配置→问题排查的顺序走每一步都附带我实际操作的记录和参数解释你可以照着敲也可以根据自己的环境调整。1. 装之前先给 Win11 环境把把关1.1 版本选择和前置条件PowerCLI 从 12.0 开始改用了年份命名规则后面大版本直接跟着实际发布节奏走比如 12.x、13.x 这种。不同大版本对 PowerShell 版本的要求不一样装之前如果不先确认版本要求很容易出现装上了但用不了的尴尬局面。我这里直接给一个简洁的对照说明方便你判断PowerCLI 大版本最低 PowerShell 版本推荐环境12.0Windows PowerShell 5.1 或 PowerShell 7.0.3Win11 自带 5.1但建议用 7.x12.1 ~ 12.7PowerShell 7.0.3建议 PowerShell 7.213.0PowerShell 7.2建议 PowerShell 7.3/7.4我在 Win11 上实测发现Win11 自带的 Windows PowerShell 5.1 确实能装 PowerCLI 12.0但后面使用Connect-VIServer连接新版 vCenter 的时候容易遇到 TLS 协议不匹配的报错而且 5.1 对很多 REST API 接口的支持不如 PowerShell 7 干净。所以我建议直接用 PowerShell 7这也和当前 VMware 官方主推的方向一致。安装 PowerShell 7 的方法很简单在 Win11 的 Microsoft Store 里搜PowerShell装那个由微软发布的版本或者去 GitHub 的 PowerShell 仓库下载 win-x64.msi 安装包装完在终端里输入pwsh就能进入 PowerShell 7 环境。注意区分Windows PowerShell 5.1 的终端是蓝色的PowerShell 7 的终端通常是黑色的别搞混。1.2 执行策略和模块路径检查PowerShell 默认的执行策略是Restricted也就是禁止运行任何脚本而Install-Module需要执行模块安装脚本所以第一件事就是放开执行策略。用管理员身份打开 PowerShell 7执行下面的命令Get-ExecutionPolicy如果输出是Restricted或者AllSigned就需要改成RemoteSigned。RemoteSigned的意思是本地脚本可以运行从网上下载的脚本必须经过签名才能运行这是安全性比较平衡的一个策略Set-ExecutionPolicy RemoteSigned -Scope CurrentUser-Scope CurrentUser只对当前用户生效不需要动系统级策略避免影响其他用户。其实Install-Module这个操作本身只是把模块文件下载到指定目录再导入如果后续还有模块自动加载脚本或者你自己写了 ps1 脚本调用 PowerCLI就会触发执行策略限制提前改好一劳永逸。接下来确认一下模块安装路径。PowerCLI 安装后会默认放到当前用户的Documents\PowerShell\Modules目录下这也是 PowerShell 7 的默认用户级模块路径。查看方式$env:PSModulePath输出会包含多个路径用分号分隔其中至少有一个是你当前用户的路径。这个路径决定了Import-Module能不能找到你安装的 PowerCLI。如果你之前用过旧版 PowerCLI而旧版是装在C:\Program Files\WindowsPowerShell\Modules这种系统级路径下的那会出现同一台机器里存在两个 PowerCLI 版本的情况后面 Import 的时候会加载到旧版本这类问题在常见问题部分我会专门说。2. 执行安装步骤和加速方案2.1 直接安装与参数解读环境检查没问题之后进入安装环节。PowerCLI 是通过 PowerShell Gallery 发布的模块标准安装命令就一行Install-Module -Name VMware.PowerCLI -Scope CurrentUser这里有几个参数需要解释清楚。-Scope CurrentUser指定安装到用户级目录不写这个参数在某些情况下会默认走AllUsers路径那就需要管理员权限。-Name模块名称必须是VMware.PowerCLI这个模块是一个元模块安装它的时候会把 VMware 家的一堆子模块一并拉下来包括VMware.VimAutomation.Core、VMware.VimAutomation.Cis.Core、VMware.VimAutomation.Storage、VMware.VimAutomation.Srm、VMware.VimAutomation.Nsxt等等所以这个模块的体积比较大安装过程需要从远程仓库拉不少文件。如果中间遇到 NuGet 版本过低或者 PowerShellGet 版本过老的提示先更新一下包管理组件Install-Module -Name PowerShellGet -Force -Scope CurrentUser-Force参数会强制覆盖安装最新版本新装的 PowerShellGet 会自带新版 NuGet provider。装完之后需要重开一个终端窗口让新组件生效。2.2 国内网络环境下的安装加速这是整个安装流程里最让人头疼的一步。PowerShell Gallery 的仓库服务器在国外国内直连下载 PowerCLI 这种一百多兆的模块包经常下到一半连接断开或者直接超时报PackageManagement\Install-Package : 无法解析远程名称这类错误。我试过在命令行设置代理也试过挂镜像源最后发现最稳的方式是使用国内可用的 NuGet 镜像源。给你一套我实测能用的大致加速方法在 PowerShell 里手动添加一个 NuGet 包源指向国内镜像地址然后安装模块时指定这个镜像源。具体执行方式Register-PSRepository -Name LocalMirror -SourceLocation https://nuget.cdn.azure.cn/v3/index.json -InstallationPolicy Trusted注意这里的镜像地址属于公共 NuGet 镜像不同地区访问稳定性有差异如果这个源不可用建议换一个可用的 NuGet 镜像地址核心思路就是让安装包下载走国内可达的 CDN 节点。执行完上面这一行之后用指定仓库安装Install-Module -Name VMware.PowerCLI -Scope CurrentUser -Repository LocalMirror -Force-Repository LocalMirror会让 PowerShellGet 只从这一个指定仓库搜索和下载模块避免默认仓库优先导致又重新走境外线路。我按照这个方式实测安装速度从百分之五就断开提升到了两三分钟全量装完。装完之后可以执行Get-Module -ListAvailable VMware.PowerCLI确认版本信息。2.3 验证安装结果模块装完不代表万事大吉需要确认模块能被正常加载。执行Import-Module VMware.PowerCLI首次导入会比较慢因为元模块要加载一堆子模块屏幕可能会卡住几秒到十几秒这是正常现象别急着 CtrlC。如果导入过程中出现红色报错大概率是依赖模块没有装全或者版本冲突。导入成功后再执行一下Get-Command -Module VMware.PowerCLI | Select-Object Name | Measure-Object这条命令统计当前模块暴露了多少个可用的 cmdlet正常情况应该有几百个如果你看到数量明显偏少比如只有几十个那说明部分子模块加载失败通常和 PowerShell 版本或者 TLS 设置有关具体排查方法在后面章节细说。3. 连接 vCenter 或 ESXi 的首次配置3.1 处理证书信任和 CEIP 提示PowerCLI 安装好之后第一件事就是连接 vCenter 或者 ESXi 主机。连接命令是Connect-VIServer但第一次执行几乎必弹证书确认提示因为 vmware 默认使用的 TLS 证书不是 Windows 系统公共证书库信任的 CA 签发的PowerCLI 会因为你没信任这个证书而直接拒绝连接。直接修改 PowerCLI 的配置项可以跳过证书检查对于内部测试环境来说是省事的选择Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false-InvalidCertificateAction Ignore的含义是遇到非法证书时不阻断连接-Confirm:$false避免执行过程中反复弹确认。这里我需要多说一句生产环境强烈不建议关闭证书信任检查比较稳妥的做法是把 vCenter 的 CA 证书导入到 Windows 的受信任的根证书颁发机构存储区这样既有证书校验又能正常连接。首次连接还会遇到CEIP客户体验改善计划的提示配置项里默认会问你是否愿意加入。在自动化和无人值守场景下这个交互提示会卡住脚本所以建议提前关掉Set-PowerCLIConfiguration -ParticipateInCEIP $false -Confirm:$false3.2 连接命令和常用初始化选项配置完成之后就可以正式连接了。连接 vCenter 为例Connect-VIServer -Server vcenter.example.com -User administratorvsphere.local -Password 你的密码这里注意-User参数在连接 vCenter 时要用 UPN 格式也就是administratorvsphere.local这种。如果连接的是 ESXi 主机用户名直接用root就行。密码写在命令行里有泄露风险我建议在交互式终端里直接执行不带-Password的Connect-VIServer这样 PowerShell 会弹出安全输入提示密码以掩码方式录入会更安全。连接成功后PowerCLI 的$global:DefaultVIServer变量会自动持有当前连接的服务器对象后续跑Get-VM、Get-VMHost这些命令时默认就在这个连接上执行不需要每次都指定-Server。如果日常使用过程中不需要某些大型子模块比如 SRMSite Recovery Manager或 NSX-T可以通过配置延迟加载机制来减少启动时间。在 PowerShell profile 里设置环境变量指定启动时只加载核心模块$env:POWERCLI_CONFIGURATION_FLOW_CONTROL Minimal这个配置项对不同版本的 PowerCLI 支持程度不同如果你的版本不识别该参数忽略即可不会影响主流程。3.3 断开连接与会话管理操作的收尾同样重要用完记得断开连接释放服务端的会话资源特别是脚本里开了多个连接的时候不主动断开会在 vCenter 上留下大量无用的会话Disconnect-VIServer -Server * -Force -Confirm:$false-Server *表示断开所有连接的服务器-Force表示即使有依赖也会强制断开。在长期跑批任务的脚本里建议在脚本结束前统一执行这段清理逻辑避免后续任务因为会话数量达到上限而连接失败。4. 常见问题与排查技巧实录4.1 Install-Module 报错和网络超时这是我在 Win11 上安装时遇到的第一个问题报错信息大致是PackageManagement\Install-Package: 未能解析此远程名称: www.powershellgallery.com很明显就是网络不通不是命令写错。这时候不要反复重试默认仓库直接用我前面说的镜像源方案。如果镜像源也不稳定还可以考虑用离线包方式在一台网络环境好的机器上用Save-Module -Name VMware.PowerCLI -Path C:\modules把模块保存成文件夹然后再用 U 盘或者内网传输工具拷贝到目标机器放到本机模块目录里Import-Module就能识别。这个方式适合离线环境也适合网络长期不稳定的场景。4.2 模块加载慢和子模块不全如果你执行Import-Module VMware.PowerCLI时等待时间过长可能是首次加载需要初始化所有子模块导致的。Win11 上尤其明显因为系统每次导入模块时还要检查模块签名的有效性。加载慢的解决办法是把不需要的子模块排除掉只导入核心模块Import-Module VMware.VimAutomation.Core Import-Module VMware.VimAutomation.Cis.CoreVMware.VimAutomation.Core包含虚拟机、宿主机、存储等核心管理 cmdlet对于大部分日常操作已经足够。如果你的任务只涉及虚拟机生命周期管理直接用这个模块就能跑起来加载速度能提升一倍以上。子模块数量偏少还有一个隐藏原因PowerShell 7 的模块加载机制会按 CPU 架构区分路径如果你安装的是 x64 版 PowerShell但之前通过某些兼容模式运行了 x86 版的 PowerShell模块路径会被重定向导致导入不到正确的模块。排查方式是先确认当前$PSVersionTable.Platform的输出是否包含Win32NT以及[System.Runtime.InteropServices.RuntimeInformation]::ProcessArchitecture是不是X64。4.3 与旧版 PowerCLI 的冲突老运维机器上多半装过 PowerCLI 6.5 或者 10.x 这些旧版本Win11 上直接升级安装新版新旧模块文件会同时存在于不同路径。有时候Get-Module -ListAvailable VMware.PowerCLI返回多个版本而Import-Module加载到的却是旧版导致部分新 cmdlet 找不到。正确做法是把旧版模块目录整个删除卸载干净再装新版。旧版默认的位置通常在C:\Program Files\WindowsPowerShell\Modules\VMware* C:\Program Files (x86)\VMware\Infrastructure\PowerCLI删除前先确认Get-Module -ListAvailable列出的 ModuleBase 路径只删对应版本目录不要误删还在使用的新版文件。清理完后重开终端再执行Install-Module装新版。4.4 PowerShell 5.1 与 PowerShell 7 混用造成的怪问题我在 Win11 上还遇到过一个诡异情况明明安装成功了但只有pwsh里能用Connect-VIServer在 Windows PowerShell 5.1 里却提示命令不存在。原因是 PowerCLI 12.1 之后的版本对模块清单文件PSModuleInfo的声明做了调整只允许 PowerShell 7 加载5.1 直接拒绝。如果你确实需要在 Windows PowerShell 5.1 里使用 PowerCLI只能安装 12.0 版本并且要在 5.1 环境里重新执行Install-Module让模块落盘到 5.1 对应的模块目录不能跨版本共享模块文件。我在两个终端环境之间切换时就因为共用同一个模块目录吃过亏最后是分开目录各装各的才解决。5. 版本升级和卸载重装的正确姿态PowerCLI 的迭代步伐不算慢尤其是大版本升级时直接把旧版本覆盖式升级往往会在依赖包上出问题。更推荐的方式是彻底卸载旧版本再安装Get-Module -ListAvailable VMware.PowerCLI | Uninstall-Module -ForceUninstall-Module只会移除模块本身不会自动清理旧版依赖的子模块所以在卸载 PowerCLI 元模块之后还需要手动查看VMware.*开头的模块还有哪些然后逐一卸载Get-Module -ListAvailable VMware.* | Uninstall-Module -Force执行这个命令的时候注意确认列表里没有你自己写的自定义模块避免误删。卸载干净之后再按前面的流程安装新版就能减少大量来源不明的报错。升级到新版本后之前保存的 PowerCLI 配置文件通常可以继续使用内容存储在%APPDATA%\VMware\PowerCLI\目录下如果需要完全回到默认状态把这个目录备份后清空PowerCLI 会在下次启动时重新生成默认配置。6. 结合 Win11 场景的几点实操心得最后分享几个在 Win11 这个环境下特有的小经验。Win11 的终端默认是 Windows Terminal它有一个特性如果你之前用管理员权限打开了 Windows Terminal 窗口那后续在这个窗口里启动的所有 PowerShell 标签页都继承管理员权限这时候执行Install-Module会走系统级路径和你平时普通权限安装的模块路径不一致容易引发模块找不到的错乱。我的习惯是安装和日常使用分离安装时用管理员权限日常使用用普通权限两个窗口分开。还有一个 Win11 系统本身的问题休眠和快速启动会导致系统时间漂移而 VMware 的连接协议里对时间同步要求比较严格容易出现SSL: CERTIFICATE_VERIFY_FAILED这类报错。如果你安装了 PowerCLI 之后连接时偶尔报时间相关的证书错误先检查一下系统时间是不是漂移了同步时间后再连接基本就正常了。另外建议给自己的 PowerShell profile 里加一行初始化配置每次打开终端自动加载 PowerCLI 核心模块省去手动Import-Module的麻烦# 编辑 profile notepad $PROFILE在打开的 profile 文件里加入Import-Module VMware.VimAutomation.Core -ErrorAction SilentlyContinue Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false Set-PowerCLIConfiguration -ParticipateInCEIP $false -Confirm:$false-ErrorAction SilentlyContinue的作用是模块不存在时不让报错刷屏。这样配置好之后终端一开就可以直接敲Connect-VIServer使用效率会高不少。本文还有配套的精品资源点击获取