企业官网建设流程全解析

1. 为什么要把物理服务器搬进虚拟化

1.1 老机房的三个硬伤

我接触过的第一台"服务器"，是一台塞在机柜最底层、风扇声像吹风机的塔式机器。上面跑着文件共享、打印服务和一套内部用的登记系统。它没有任何冗余，电源只有一路，硬盘只有一块，管理员休假的时候没人敢碰它。这种场景在中小规模的 IT 环境里非常普遍，而它暴露出来的问题也就那三个：资源利用率极低、扩容周期极长、故障恢复基本靠人。

资源利用率低到什么程度？那台机器的 CPU 常年不到 5%，内存用掉三分之一，剩下的全在空转。你要是想再上一套新系统，标准流程是"打报告、批预算、采购、等货、上架、装系统"，快则两周，慢则两个月。而如果这台机器的主板坏了，恢复时间完全取决于你上一次备份是什么时候、备份能不能用、有没有人记得当时的配置细节。

虚拟化要解决的就是这三件事。把一台物理服务器的 CPU、内存、存储、网络切成多个相互隔离的逻辑单元，让每台虚拟机以为自己独占一台机器。资源利用率从个位数拉到 50% 以上是常态，新系统上线从"等采购"变成"改个配置点几下"，故障恢复从"重装重配"变成"从备份或模板重新拉起"。这个转变不是简单地换个工具，而是运维思路从"伺候机器"变成"管理资源池"。

1.2 vSphere 这套体系的角色分工

很多人刚接触 vSphere Client 的时候会懵，因为它不是一个软件，而是一整套东西，界面上又同时出现主机、集群、数据中心、数据存储、端口组这些名词。我习惯用"物业公司"来类比，理解起来会快很多。

ESXi是真正干活的那一层，装在物理服务器上，直接管理硬件，把 CPU、内存、磁盘、网卡抽象成资源。你可以把它想成一个小区的楼栋管理员，只管自己这一栋。它自己带一个非常简陋的本地控制台，只能做最基础的配置，日常管理不靠它。

vCenter Server是调度中心，把多台 ESXi 主机纳管起来，提供集群、高可用、迁移、权限、告警、模板这些能力。它是物业总部，管着好几个小区，能跨楼栋调人调物资。

vSphere Client是那个对外的服务窗口。你所有的操作，无论是看一眼某台虚机开没开机，还是给某个账号分配只读权限，都是通过它下发到 vCenter（或者直连单台 ESXi）。它是浏览器里的一个网页应用，不需要在本地装客户端。

搞清这三层关系很重要，因为后面所有的"检索不到对象""权限不对""看不到某个标签"的问题，八成都能归到"你到底连的是哪一层"上面。直连 ESXi 和连 vCenter，能看到的清单范围、能用的功能、能配的权限，是完全不同的两回事。

1.3 为什么我把"清单检索+界面定制"放在入门第一步

大部分人学虚拟化，第一件事是学怎么创建虚拟机。我觉得这个顺序有点问题。创建虚拟机是简单的，点几下向导就行；真正让人在日常运维里难受的，是资产看不清和界面不顺手。

资产看不清是什么感觉？接手一个环境，两百多台虚机，分布在几台主机上，你要回答这么几个问题：哪些虚机还在跑但没人认领？哪些虚机磁盘快满了？哪些虚机的快照堆积了半年没人清理？哪些虚机所在的主机 CPU 长期过载？如果只能靠鼠标一台一台点开看摘要，这一天基本就废了。

界面不顺手是什么感觉？默认视图给你的列是名字、开机状态、CPU、内存、IP 之类，但你真正天天要看的是"所属集群、所属主机、数据存储剩余、最近一次备份时间、责任人"。这些字段默认没有，你得一个个点进去找。

所以我通常建议的顺序是：先把环境跑起来，能连上、能看到东西，然后立刻把清单检索和界面定制这两件事做掉。原因很实际——这两件事做完，你对整个环境的认知会从"一坨黑盒"变成"一张能筛选的表"，后面所有的容量规划、故障排查、变更管理，都建立在这张表上。而且这两件事的投入产出比极高，一个下午就能见效。

2. 上手前的账本：资源测算与形态选型

2.1 CPU、内存、存储三个数字怎么算

在动手装之前，有一件事必须做：算账。不算账就上虚拟化，最常见的结局是"虚拟机越开越多，最后集体卡死"。

CPU 的算法是超分比。物理核数和虚拟 vCPU 数不是一比一的关系，因为绝大多数业务系统的 CPU 使用率是波动的，平均下来很低。业界常见的经验区间是 1:4 到 1:8，超过 1:10 就要非常小心了，一旦几台虚机同时出现计算高峰，就会互相拖累。举个具体的例子：一台双路 16 核的物理机，物理核数 32，按 1:6 计算，可以分配大约 192 个 vCPU。听起来很多，但要注意这是"能分配"不是"该分配"，实际规划里我一般按 1:4 保守起步，跑一段时间看真实负载再放宽。

内存基本不超分，或者只做轻微超分。内存和 CPU 的逻辑完全不同，虚机分配了 8GB 内存，只要它真的在用，物理机上就必须有对应的 8GB 真实内存。超分太多会触发内存回收机制（气球驱动、交换），性能会断崖式下跌。我自己的做法是物理内存的 80% 作为可分配上限，剩下的留给 ESXi 自身开销和突发余量。比如 256GB 内存的机器，按 200GB 左右来规划虚机。

存储要算两个维度：容量和 IOPS。容量好算，把所有虚机的磁盘加总，再乘一个冗余系数（我一般用 1.3 到 1.5，考虑快照、交换文件、临时文件）。IOPS 才是容易被忽略的：一台普通的业务虚机，空闲时可能只有几十 IOPS，但开机、装补丁、批量扫描的时候能冲到上千。如果底下是一块机械盘阵列，几十台虚机同时干活就会互相卡住。经验值是机械盘阵列按每块盘 100 到 150 IOPS 估算，全闪存阵列可以到每块盘数千 IOPS，量级差得很远。

提示：这些数字不是让你精确到个位，而是让你在开会时能拿出一份"为什么需要这么多内存"的说明。真实项目里，超分比和冗余系数一定要写进方案文档，后期扩容时才有依据。

2.2 单机 ESXi 还是 vCenter 纳管

这是形态选型上的第一个岔路，很多人第一次搭环境会纠结。

单台 ESXi 直连的好处是简单，装完系统配个 IP，浏览器打开就能用，不需要额外的虚拟机来跑管理中心，也不需要额外的数据库和证书体系。适合什么场景？实验室、测试环境、只有一两台物理机的边缘场景、以及"我就想先试试虚拟化是什么感觉"的入门阶段。缺点也很明确：没有集群、没有高可用、没有跨主机迁移、权限管理非常粗糙、模板和标签这些能力要么没有要么受限。

vCenter 纳管需要一个独立的部署单元（通常是部署成一台虚拟机），好处是功能完整：集群、HA、DRS、模板、标签、自定义属性、细粒度角色权限、集中告警、性能历史数据，全都在。代价是你多了一个"必须先活着"的组件——vCenter 挂了，日常的管理界面就用不了，虽然虚机本身还在跑，业务不受影响。

我的建议是：学习阶段先用单机直连把基本概念跑通，一周之内尽快过渡到 vCenter 纳管。因为清单检索和界面定制这两件事，在单机直连模式下能做的非常有限，标签、自定义属性、角色权限这些都得靠 vCenter。你如果一直停在单机模式，会误以为 vSphere 就这点能力。

2.3 Client 两种形态的取舍

还有一个容易踩的坑：客户端形态。历史上存在过需要本地安装的胖客户端和浏览器访问的 Web 客户端，现在主流是浏览器直接访问的 HTML5 版本，功能覆盖已经相当完整，性能视图、克隆、迁移、标签管理都能做。旧的那套基于插件的方式已经逐步退出，新手完全没必要去折腾它。

需要提醒的是浏览器选择。这类管理界面依赖现代浏览器的特性，用太老的浏览器会出现白屏、按钮点不动、弹窗不显示的问题。我实测下来，保持浏览器在较新版本，关掉那些会拦截脚本的扩展插件（尤其是广告拦截和隐私保护类），出问题的概率会低很多。另外缓存也是一个高频问题源，界面显示异常时先强制刷新或者清一次缓存，能省掉大量排查时间。

注意：不要在生产管理界面所在的浏览器里装一堆不明来源的扩展。管理平面的会话凭证是有价值的，浏览器插件是最容易被忽视的泄露渠道。

3. 清单检索：让资产从"看得见"变成"查得到"

3.1 界面自带的检索能力与它的天花板

登录进去之后，左侧是清单树，顶部有一个全局搜索框。这个搜索框能干的事比你想象的少：它主要按名称匹配，输入虚机名的一部分能跳出来，输入 IP 有时候能匹配到（因为 IP 存在虚机的客户机信息里，前提是工具组件装了并且信息回传成功），但它不能做条件组合。你想查"所有属于 A 集群、开机状态、内存大于 16GB、并且打了某个标签的虚机"，搜索框做不到。

界面里还有几个可以用的入口：清单视图本身支持按列排序和简单的列筛选，某些视图支持关键字过滤；"相关对象"标签页能看到某台主机下的所有虚机；数据存储视图能看到哪些虚机占用了这个存储。这些在临时排查时够用，但没法沉淀成可复用的查询。

这就是天花板所在：界面适合"我知道名字，我去找它"，不适合"我不知道有哪些，我要筛出来"。而日常运维里，后者的场景其实更多——盘点、审计、容量评估、找僵尸虚机，全都是后者。

3.2 PowerCLI：把检索写成可复用脚本

真正解决问题的是命令行工具 PowerCLI。它是基于 PowerShell 的一套命令模块，装在一个管理终端上，连上 vCenter 之后就能把清单当对象查。

安装本身不复杂，在 PowerShell 里从官方仓库拉取模块安装即可。这里要注意执行策略的问题，如果脚本被拦住，需要先把当前会话的执行策略调整到允许运行脚本的级别：

# 以管理员身份打开 PowerShell Set-ExecutionPolicy -Scope CurrentUser RemoteSigned Install-Module -Name VMware.PowerCLI -Scope CurrentUser Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false Set-PowerCLIConfiguration -DefaultVIServerMode Multiple -Confirm:$false

最后那两行是有讲究的。第一行处理自签名证书的告警，实验环境里证书往往不是受信任 CA 签发的，不处理就会每次连接都弹确认。第二行把默认连接模式设为多连接，方便你同时挂着多个管理入口做对比查询。

连接命令如下：

Connect-VIServer -Server vc.lab.local -User 'reader@vsphere.local' -Password 'YourPassword'

连上之后，一条最简单的清单查询就可以跑起来了：

Get-VM | Select-Object Name, PowerState, NumCpu, MemoryGB, @{N='Host';E={$_.VMHost.Name}}, @{N='Cluster';E={$_.VMHost.Parent.Name}}, @{N='GuestOS';E={$_.Guest.OSFullName}}

这段代码里有两个知识点值得说透。Get-VM返回的是对象，不是文本，所以可以直接取属性。VMHost是虚机所在的主机，VMHost.Parent通常是集群（如果主机没有加入集群，Parent 就是数据中心），这种"顺着对象往上爬"的写法是 PowerCLI 里最常用的技巧，比自己去拼字段靠谱得多。

再复杂一点的检索，比如"找出所有快照超过 30 天没动过的虚机"，就需要组合快照对象：

Get-VM | Get-Snapshot | Where-Object { $_.Created -lt (Get-Date).AddDays(-30) } | Select-Object VM, Name, Created, @{N='SizeGB';E={[math]::Round($_.SizeGB,2)}}, @{N='DaysOld';E={[int]((Get-Date) - $_.Created).TotalDays}} | Sort-Object DaysOld -Descending

这个查询的现实价值很高。快照是虚拟化环境里最容易被滥用的功能，很多人把快照当备份用，拍完就忘了。快照文件会持续增长，还会拖慢虚机磁盘性能，严重的能把数据存储撑爆。写一条命令把这些"陈年快照"捞出来，比一个个点开虚机看快照管理器高效太多。

3.3 从原始清单到能交差的报表

查出来的东西要能交付，Export-Csv就够了，但直接导出的 CSV 有几个坑：编码不对会中文乱码，对象里有嵌套属性会显示成一串类型名。

$report = Get-VM | Select-Object Name, PowerState, NumCpu, MemoryGB, @{N='Host';E={$_.VMHost.Name}}, @{N='Cluster';E={$_.VMHost.Parent.Name}}, @{N='Datastore';E={(Get-Datastore -VM $_ | Select-Object -First 1).Name}}, @{N='UsedSpaceGB';E={[math]::Round((Get-HardDisk -VM $_ | Measure-Object CapacityGB -Sum).Sum,1)}} $report | Export-Csv -Path .\vm-inventory.csv -NoTypeInformation -Encoding UTF8

-NoTypeInformation必须加，否则第一行会多出一行类型声明，Excel 打开会很难看。-Encoding UTF8是为了让中文名不乱码。另外，如果虚机数量多，一条一条去查数据存储会很慢，这种情况我一般先一次性把所有数据存储和它们的对应关系缓存成哈希表，再在循环里查表，速度能快一个数量级。

清单做完之后，我通常会补三张"衍生表"：按主机汇总的虚机数与资源分配表、按存储汇总的占用与剩余表、无归属虚机清单（没有标签、没有备注、没装工具、长期零流量）。这三张表基本能支撑起一次完整的资源盘点汇报。

3.4 检索环节最容易踩的四个坑

第一个坑是权限导致的"清单不全"。你连上去之后Get-VM只返回了几台，第一反应通常是"命令写错了"，实际上是账号在 vCenter 里的权限只覆盖了某个文件夹或者某台主机。vSphere 的权限是分层的，上层可以继承到下层，但如果某处设置了"禁止继承"或者显式拒绝，就会形成一片你完全看不见的区域。排查方式很简单，换一个有全局只读权限的账号跑同样的命令，对比结果数量。

第二个坑是性能数据的默认保留期。你想查"过去 30 天的 CPU 峰值"，结果只有最近一天的数据，那是因为性能数据的保留策略按级别分层，越细粒度的数据保留越短。设计报表时要先确认数据颗粒度和保留时长能对上，否则做出来的图是残缺的。

第三个坑是客户机信息依赖工具组件。虚机的 IP、操作系统全名、磁盘使用率这些"内部信息"，靠的是装在虚机里的工具组件回传。没装或者没运行，这些字段就是空的。所以用 IP 做检索条件时，结果不可靠是常态，别把它当成唯一的定位手段。

第四个坑是对象数量大时的超时。环境规模上去之后，一条没加过滤的命令可能跑几分钟甚至超时。解决办法是先缩小范围，按文件夹、按集群、按标签分批取，再在本地合并。

提示：把常用检索封装成带参数的脚本函数，比如Get-VMInventory -Cluster "Prod" -Tag "Owner=TeamA"，用的时候传参就行，比每次手敲一长串管道要可靠得多。

4. 界面定制：把常用指标摆到顺手的位置

4.1 自定义属性与标签：先把分类标准定下来

界面定制这件事，很多人一上来就调列宽、换主题色，其实真正的第一步是决定用哪些维度给资产分类。维度定不下来，界面怎么调都是乱的。

vSphere 里有两套分类机制，用途不一样。自定义属性是键值对，一台虚机一个属性只能有一个值，适合放"唯一归属"的信息，比如责任人、资产编号、业务系统名、上线日期。标签可以一台虚机打多个，还能分组到不同类别里，适合放"多重归属"的信息，比如环境（生产/测试/开发）、合规级别、备份策略、成本中心。

我的经验是先定三到五个维度，不要贪多。一个典型组合是：

定好之后，用界面或者脚本批量打上去。脚本打标签比手工点快得多，尤其是新建虚机的时候可以在模板里预设，克隆出来自动继承。

# 批量给某个文件夹下的虚机打环境标签 $tag = Get-Tag -Name "生产" -Category "环境" Get-VM -Location (Get-Folder -Name "核心业务") | New-TagAssignment -Tag $tag

这里有个非常实用的技巧：在模板里就把标签和自定义属性设好。用模板克隆出来的虚机会继承这些元数据，新虚机一出生就带着归属信息，不会出现"这几十台虚机是谁的我也不知道"的局面。这一条我在好几个环境里推行过，效果比事后补救强太多。

注意：标签的分类和取值一定要提前约定并写进规范。我见过一个环境里"生产""PROD""正式"三种写法并存，最后做筛选时得写三个条件，非常难受。

4.2 列、视图与筛选器的定制

清单视图的列是可以自己选的。默认给的那几列（名称、开机状态、CPU、内存、IP）远远不够日常使用。我一般会把这几列加上：所属集群、所属主机、数据存储、已用空间、客户机操作系统、自定义属性中的责任人、标签。

列的调整逻辑是"你每天要看的三秒内必须能看到"。凡是需要点进虚机摘要页才能看到的信息，只要它是高频的，就应该提到列表里。加完之后把列宽调好，这个布局会保存在你的用户偏好里，下次登录还在。

视图层面，左侧清单树有几种预设视角：主机和集群、虚机和模板、存储、网络。每种视角下的对象类型不同，能加的列也不同。存储视角下看的是数据存储的容量、类型、可访问主机；网络视角下看的是标准交换机、分布式交换机、端口组。做容量盘点的时候我会在存储视角待很久，做网络排查时切到网络视角。

筛选是另一个提效点。虽然界面上的筛选能力有限，但"按列筛选"在应对具体问题时够用：按开机状态筛出所有关机虚机（找僵尸），按主机筛出某台机器上的所有虚机（做维护前确认），按数据存储筛出占用同一存储的虚机（做迁移规划）。

4.3 角色与权限：让每个人都只看到自己那一摊

界面定制的深层版本，是让不同角色登录后看到不同的东西。这件事靠的是权限体系，而权限体系的基础又是你在 4.1 里定的那些维度。

vSphere 的权限模型是"对象 + 用户/组 + 角色"，权限沿着清单层级向下继承。角色是一组权限的集合，系统自带只读、管理员等预设角色，也可以自定义。我的做法通常是这样切：

• 平台管理员：在根层级授予管理员角色，能看全部、改全部。
• 业务运维：在对应的资源文件夹或集群层级授予操作类角色，只能管自己那摊虚机。
• 审计/财务：授予全局只读，只能看不能改，用于盘点和成本分摊。
• 备份服务账号：只授予与备份相关的必要权限，且限定在特定文件夹。

这里最容易犯的错误是图省事在根层级给管理员权限。一旦给了，这个人能看到全部资产、能删任何虚机、能改任何配置，出了问题责任都说不清。正确做法是权限尽量往下压，压到"刚好够用"的那一层。

另一个细节是用组而不是用个人。人员会流动，一个人离职你就要去翻所有对象找他的权限，非常容易漏。统一用安全组授权，人员变动只改组内成员，权限对象一个都不用动。

4.4 告警与性能视图的定制

告警是界面上最值得花时间调的部分。默认告警一大堆，动不动就红一片，看久了就麻木了，真正重要的反而被淹没。我的做法是先关掉噪音，再补上业务关心的自定义告警。

噪音主要来自两类：一是阈值太敏感，正常的瞬时波动就触发；二是对象已经被弃用但告警还挂着。前者调阈值和持续时间（比如"持续 15 分钟超过 85%"比"瞬时超过 85%"有用得多），后者直接禁用或删除。

自定义告警我会加这么几条，都是实际踩过坑的：

• 快照存在时长超过 7 天（这是虚拟化环境里最容易失控的东西）
• 虚机磁盘剩余空间低于 15%（靠工具组件回传，要确认组件在跑）
• 主机内存使用率持续 30 分钟超过 90%（说明该扩容或迁走了）
• 数据存储剩余空间低于 20%（撑爆存储是灾难级故障）
• 虚机连续关机超过 30 天（僵尸资源识别）

性能视图方面，默认的性能图表是分散在各个对象里的。日常看容量趋势，我更依赖按对象类型聚合的视图，看整体分布而不是单台。真正要做长期趋势分析，还是得把数据导出来用表格工具画，界面里的图表适合"现在有没有问题"，不适合"三个月后会不够用"。

5. 一次完整的落地走查：从裸机到可查询的清单

5.1 步骤一：裸机安装与基础网络

这一段我用一台实验用的物理服务器走一遍完整流程，机器配置是双路 8 核、128GB 内存、两块 SSD 做系统盘、四块大容量盘做数据盘、双千兆网卡。

安装镜像引导起来之后，第一个交互界面就是选择安装目标盘。这里要特别注意别选错——我见过不止一次把数据盘当成系统盘格掉的案例。判断方法很简单：先把数据盘的线拔了，只留系统盘装完再接回去。这个笨办法比在安装界面里反复确认容量要可靠。

安装完成后机器重启，控制台界面会显示一个地址。这时候必须做三件事：配管理 IP、配网关和 DNS、改 root 密码。管理 IP 建议单独划一个管理网段，不要和业务网混在一起。原因很实际：业务网上的广播风暴、大流量传输、地址冲突，都有可能把管理通道一起拖垮，到时候你想登进去处理都进不去。

配置完之后在浏览器里访问这个地址，就能看到登录界面了。这时候是单机模式，功能有限，只能做基础的主机配置。

5.2 步骤二：虚拟交换机与端口组

网络是新手最容易糊掉的一块，我用一个类比说清楚。虚拟交换机相当于一个虚拟的物理交换机，虚机通过虚拟网卡接到这个交换机上，交换机再通过物理网卡（上行链路）接到真实的物理交换机。端口组相当于虚拟交换机上的一个个"插座"，每个端口组可以带不同的 VLAN 标记，虚机接到哪个端口组，就走哪个 VLAN。

一张物理网卡对应一个上行链路。如果只有一张网卡，那虚拟交换机就只有一条出口，网卡坏了网络就断了。所以标准做法是至少两张网卡做冗余，把两张网卡都挂到同一个虚拟交换机上，配置成主备或负载均衡模式。

管理流量和虚机流量也建议分开。我的常规做法是建两个虚拟交换机：一个只挂管理网卡，跑管理地址、vCenter 通信；另一个挂业务网卡，跑虚机的业务流量。这样业务侧怎么折腾，都不会影响到你远程管理。

端口组命名要有规矩，别用默认的"VM Network"一路到底。我一般按"环境-用途-VLAN"来命名，比如prod-web-110、test-db-120。名字起好，后面在清单里看到网卡接在哪个端口组，一眼就知道是什么业务。

5.3 步骤三：存储接入与第一台虚机

存储这块，本地盘和共享存储的区别一定要搞清楚。本地盘只能被本机访问，虚机存在上面就绑死在这台主机上，主机挂了虚机就起不来。共享存储（不管是通过网络访问的存储设备还是分布式存储）可以被多台主机同时访问，是后面做高可用和迁移的前提。

实验环境用本地盘没问题，但心里要清楚这个限制。生产环境我建议至少给集群准备共享存储，不然高可用和迁移这些能力都是空的。

创建第一台虚机，走一遍向导就行：选客户机操作系统、选存储位置、配 CPU 和内存、配磁盘大小和置备方式、配网卡接到哪个端口组、挂载安装镜像、开机装系统。这里有个容易忽略的点是磁盘置备方式。厚置备是创建时就把空间全占掉，性能稳定但占容量；精简置备是用了多少占多少，省容量但写入时会有额外的开销，而且容易"账面看着够，实际写满"。我的习惯是系统盘用厚置备，数据盘可以用精简，同时把存储的剩余空间告警设好。

装完系统之后，立刻做两件事：装工具组件（这样 IP、操作系统信息才能回传，清单才完整）、把它转成模板（后面所有同类型虚机都从模板克隆，保证一致性）。转模板之前记得把机器关机，并且把机器名、网络配置这些会冲突的东西清理干净。

5.4 步骤四：接入 vCenter、建数据中心与集群

单机能干的活就到这里。接下来部署 vCenter 把它纳管起来。部署方式是把它本身也作为一台虚机部署到某台 ESXi 上，走安装向导，指定部署目标、配 IP、设单点登录域名和管理密码。

部署完成之后登录进去，第一件事是建数据中心对象，第二件事是建集群并把主机加进去。数据中心在 vSphere 里更像一个逻辑容器，可以按机房、按楼层、按业务线来划分，它本身不占资源。集群才是资源的边界，高可用、资源调度这些能力都作用在集群上。

把主机加入集群的时候会有一个"锁定模式"的选项。这个模式的作用是：开启后，直接用 root 账号登录主机的控制台会被限制，必须通过管理中心来操作。它的价值是收口管理入口，避免有人绕过审计直接改配置；代价是管理中心不可用的时候，排查会麻烦一些。我一般在新环境稳定运行一段时间之后再开。

加完主机，把集群的高可用打开，把接入控制策略选成"集群资源百分比"，预留一部分资源作为故障切换的余量。这个百分比要根据集群里最大一台主机的资源占比来定，宁可多留一点。

5.5 步骤五：跑通第一份清单与完成界面定制

到这一步，环境已经有了，接下来就是标题里的那两件事。

先跑清单。用前面 3.2 的脚本连上去，把虚机清单、主机清单、存储清单、快照清单四份数据导出。然后核对数量：管理中心里显示的虚机总数和脚本导出的行数对不对得上，对不上就说明有权限盲区或者对象被过滤了。这一步的核对很关键，它是你后面所有数据的信任基础。

再定分类。把属于哪个业务、归谁负责、什么环境、什么备份策略这四件事，通过自定义属性和标签落到每一台虚机身上。手工补也行，脚本批量打也行，新虚机靠在模板里预设来继承。

然后调界面。把常用列加上，把视图按环境拆开，把告警阈值按前面的思路调一遍，把权限按角色分好。做完这些，你登录进去看到的第一屏，应该就是"我最关心的那些机器和指标"，而不是一堆无关的默认信息。

最后补一份文档，把这套约定写下来：分类维度定义、标签取值规范、角色权限对照表、常用检索脚本清单。这份文档的价值在交接的时候体现得最明显。

6. 常见问题与排查技巧实录

6.1 连不上、证书报错、登录转圈

现象一：浏览器打不开管理界面，提示连接超时。先确认管理地址能不能 ping 通，再确认端口通不通。管理界面用的是特定的 HTTPS 端口，如果网络里有策略拦截了非标端口，就会连不上。其次是确认服务本身起来了没有，通过主机的直接控制台重启一下管理服务，大多数"网页打不开"的问题都能解决。

现象二：页面能打开，但登录后一直转圈或者白屏。八成是浏览器缓存或者扩展的问题。先换一个干净的浏览器窗口（无痕模式）试，能进就是缓存或扩展的锅。其次是浏览器版本太旧，前端资源加载不全。我遇到过一台机器因为系统时间不对，导致前端的一些校验直接失败，页面卡在加载状态，排查了很久才发现是时间同步的问题。

现象三：证书告警。实验环境用自签证书，浏览器会提示不安全。生产环境应该换成受信任的证书，并且把管理中心和主机的证书体系理顺——证书过期是虚拟化环境里非常经典的故障，过期之后管理中心和主机之间的通信会断，表现为各种奇怪的"操作失败"。

现象四：PowerCLI 连接时报证书错误。前面提到过，用Set-PowerCLIConfiguration -InvalidCertificateAction Ignore处理。但要注意这只是跳过校验，生产环境应该把 CA 证书导入到信任链里。

6.2 清单里对象"消失"或数量对不上

这是最高频的一类问题，我总结下来有三个原因，排查顺序也按这个来。

第一，权限范围不覆盖。换管理员账号跑同样的查询，如果数量对上了，那就是权限问题。回到权限视图，看看目标对象上有没有"禁止继承"的设置，或者有没有显式拒绝的条目。这类问题的隐蔽性在于界面上"看不到"和"不存在"长得一模一样，很容易误导排查方向。

第二，对象确实不在你查的范围内。比如某个虚机被放在了一个独立于集群之外的资源池里，或者挂在某个你没注意到的文件夹下。用不带任何过滤的全量查询跑一遍，再按上级对象归组，就能发现"漏网"的那些。

第三，查询条件写错。这个看着幼稚但真的常见。比如按标签筛选时标签名字打错一个字，按名称匹配时用了大小写敏感的比较，按状态筛选时把"已挂起"排除掉了。写完查询先跑一次不带条件的版本，确认基数对，再逐步加条件，一步步缩小范围。

6.3 虚机卡顿但资源看起来没满

这类问题最磨人，因为从汇总数据上看一切正常。我的排查顺序是这样的：

先看主机的实际负载，而不是虚机的分配值。虚机分配了 8 个 vCPU，不代表它真的能用满 8 个。主机 CPU 如果长期 90% 以上，超分比就已经过线了，所有虚机都在排队等 CPU 时间片。

再看内存有没有触发回收。主机的内存使用率接近上限时，会启动内存回收机制，虚机的性能会明显下降，但虚机自己看到的内存使用率可能还是正常的。这个指标要专门去看。

然后看存储的延迟。容量够不代表性能够。存储的读写延迟如果偏高，虚机的磁盘操作会全部变慢，表现就是"系统卡，但 CPU 和内存都不高"。这个是最容易被忽略的，因为容量告警不响，人就以为存储没问题。

最后看网络和客户机内部。端口组的策略配置、物理网卡的带宽是否跑满、虚机内部的进程占用，这些都要排一遍。

提示：把上面这几个指标做成一个固定的排查表，每次遇到性能问题按顺序过一遍，比凭直觉乱猜要快得多。我自己的表就五列：主机 CPU 实际使用率、主机内存实际使用率、存储延迟、网络吞吐、客户机内部负载。

6.4 常见问题速查表

7. 个人踩坑心得与可扩展的方向

7.1 几条不写在文档里的经验

第一条，清单的准确性比清单的完整性更重要。刚开始做盘点的时候，我总想把所有字段都抓下来，结果导出的表几十列，没人看得下去。后来我改成只保留八到十列核心字段，加上一份"补充说明"文档，反而被真正用起来了。报表这东西，能被人打开看第二眼，才有价值。

第二条，标签和自定义属性一定要在虚机创建的那一刻就写进去。事后补的成本高得吓人，因为很多东西过几个月就没人记得了。我现在的做法是把"责任人、业务系统、环境、备份策略"这四个字段做成新建虚机的必填项，从模板继承或者用脚本在克隆后立即写入。这一条推行起来会有一点阻力，但坚持下来收益极大。

第三条，别迷信超分比。文档上写 1:8 是常见区间，但那是有前提的——你的业务负载确实是波动的。如果跑的是数据库这类持续高负载的东西，超分比必须压到很低。判断依据永远是实测数据，不是纸面经验。

第四条，管理平面的稳定性要单独保障。虚拟化环境有个特点：管理组件本身也跑在虚拟化环境里。所以规划的时候必须给它留出独立的资源，别让它和业务虚机抢。我见过一次因为资源争抢导致管理中心响应极慢，明明主机都活着，但谁也管不了，最后只能去物理机上手动处理。

第五条，脚本要先在只读环境里验证。PowerCLI 威力很大，一条Remove-开头的命令敲错一个参数就能删掉一片东西。我的习惯是：所有写操作的脚本，先在测试环境跑一遍，确认输出符合预期；所有查询脚本，用只读账号跑，从根上杜绝误操作。

7.2 清单与界面之后还能做什么

把清单和界面这两件事做完，其实已经打开了几个很自然的延伸方向。

一是告警和清单联动。清单告诉你"有哪些东西"，告警告诉你"哪些东西出问题了"。把两者结合，就能做出"按业务系统分组的健康度视图"，汇报的时候比一堆零散告警有说服力得多。

二是容量趋势。清单是一次快照，定期跑（比如每周一次）导出的数据积累起来，就能画出资源增长曲线，用来回答"什么时候需要扩容"这个必然会来的问题。这件事越早开始越好，因为趋势需要历史数据，历史数据只能靠时间攒。

三是自动化的资产核对。把清单和配置管理记录、监控系统的资产列表做交叉比对，能自动发现"监控里有但虚拟化里没有"或者"虚拟化里有但监控没覆盖"的差异，这类差异往往就是管理盲区。

四是模板和规范的闭环。当清单里的元数据足够规范，就可以反向要求模板必须带这些元数据，新建虚机必须走模板，形成"创建即规范"的闭环。这一步做完之后，资产盘点从"每年折腾一次"变成"随时能查"。

我个人的体会是，虚拟化这套东西上手不难，难的是把它管得清楚。前面那些创建虚机、配网络的步骤，看文档半天就能学会；真正拉开运维水平差距的，是你能不能在三分钟内回答出"我们现在有多少资源、被谁用着、哪里快不够了"。清单检索和界面定制，就是让这三个问题变得能回答的最短路径。