企业官网建设流程全解析

最近给一套新的测试环境做部署，客户采购了几台新服务器，要把虚拟化底座搭起来。ESXi 环境里安装虚拟机这件事，从界面操作看就是个"下一步下一步"的向导流程，但真落到生产环境，很多细节不到位，后面会冒出一连串麻烦。这篇文章把我实际动手部署虚拟机时梳理的完整流程、参数权衡和踩坑记录整理出来，给同样在搞 ESXi 虚拟化的朋友一个参考。

阅读路径大致是这样：先说 ESXi 平台下创建虚拟机之前你要想清楚哪些事，再讲镜像、存储、网络这些前置准备的细节，接着把创建向导的每一步拆开讲重点参数怎么选，最后列一份我在现场遇到过的典型问题和排查方法。如果你刚接触虚拟化，顺着看就能完整走完一台虚拟机的安装；如果已经有基础，可以直接跳到后面的问题排查和经验部分，那里有不少常规文档里不会写的细节。

1. 动手前的环境盘点：ESXi 虚拟化的底层逻辑

为什么要把"环境盘点"单独拎出来讲？因为虚拟机创建本身很简单，但 ESXi 和你在个人电脑上装 VMware Workstation 完全是两码事。ESXi 是裸金属 Hypervisor，直接跑在服务器固件和硬件之上，没有底层操作系统这一层。这意味着虚拟机的资源配置会直接落到物理设备上，你创建虚拟机时做的每一个决定，都跟物理机的资源利用率和后续运维挂钩。Workstation 里随手可改的配置，在 ESXi 上可能涉及关机、迁移甚至重建。

1.1 ESXi 的架构特性与部署场景

ESXi 的核心是一个叫 VMkernel 的微型内核，负责调度 CPU、内存、存储和网络资源。每台虚拟机在这个架构里相当于一组独立进程，拥有自己的虚拟 BIOS/UEFI、虚拟设备栈和客户机操作系统。这个架构的好处是开销小、性能接近物理机，坏处是资源分配失误的代价很大。举个简单的例子：内存超分过多的时候，宿主机出现内存压力，虚拟机会被强制进行内存页回收，表现就是整机卡顿、应用超时，严重时甚至触发内核层的 OOM 动作。

实际场景里，ESXi 虚拟机的常见用途包括业务应用部署、数据库承载、测试环境隔离，以及容器基础设施的底层支撑。不同用途对虚拟机配置的要求差异非常大。跑数据库的虚拟机，磁盘 I/O 是关键，存储控制器选型、磁盘格式、队列深度都会影响性能；跑普通 Web 服务的虚拟机，网络吞吐和 CPU 核数更关键；做桌面虚拟化的虚拟机，则更看重内存容量和图形处理能力。所以创建虚拟机之前，先要搞清楚这台机器将来干什么用。

我给现场的朋友一个习惯：接到虚拟机需求，先问三个问题——运行业务的类型是什么、峰值负载大概多大、可接受的维护窗口有多长。这三个问题的答案直接决定后续参数选择。比如一个内部报表系统，平时负载不高但月末跑批时 CPU 冲高，适合分配较多 vCPU 但内存不必顶满；一个实时交易类业务，低延迟敏感，需要设置 CPU 预留和内存锁定，避免资源竞争导致延迟抖动。提前把这些想清楚，后续就不会频繁拆虚拟机改配置。

1.2 为什么创建虚拟机有那么多前置条件

ESXi 里新建虚拟机的入口很简单，但也正因为入口简单，很多人忽略了前置条件，后面踩坑。这里的前置条件我按层级理一遍：

• 宿主机层面：ESXi 版本、许可证级别、硬件驱动兼容性、CPU 和内存余量、存储空间与存储类型。
• 网络层面：端口组（Port Group）、VLAN 划分、上行链路绑定策略、网络 I/O 控制。
• 虚拟机层面：客户机操作系统类型、虚拟硬件版本、启动方式（BIOS 还是 UEFI）、控制器类型、磁盘格式。

每一层背后都有明确逻辑。比如虚拟硬件版本必须和当前 ESXi 主机的支持列表匹配，否则虚拟机无法注册；将来要做 vMotion，还得看集群的 EVC 模式是否兼容当前 CPU 特性集。再比如启动方式，新版 ESXi 默认推荐 UEFI，但碰上某些旧版 Windows Server 或特定的 Linux 发行版，UEFI 支持不完善就会启动失败，这时候反而要退回 BIOS 模式。

这些前置条件不是要劝退谁，而是想说清楚一个事：ESXi 环境里的虚拟机安装，本质上是一个硬件配置决策过程，不只是向导点击过程。想明白这一点，后面所有参数选择就都有据可循，遇到异常也能快速定位到具体环节。

2. 安装前的核心准备：镜像、存储与网络三板斧

准备工作做得越充分，创建过程越顺畅。我见过不少同事在向导里满屏找 ISO，或者虚拟机建完才发现端口组选错，这些都属于准备阶段就能避免的问题。这一节把三件最重要的事讲透：系统镜像怎么放、存储位置怎么选、网络参数怎么定。

2.1 系统镜像的获取与上传

ESXi 和 Workstation 不一样，宿主机上没有光驱这个概念。虚拟机的 CD-ROM 是从数据存储里的 ISO 文件挂载过来的，所以第一步是把 ISO 上传到数据存储。

上传方式常用的有三种：vSphere Client 的数据存储浏览器直接上传、网页端数据存储浏览器上传，或者用 scp 一类的命令行工具直接推到存储路径。我平时最常用网页端的数据存储浏览器，图形界面直接拖文件，不用额外装工具。大文件上传时要注意一个问题：网络状态不好时上传可能超时，客户端会报"上传失败"。这种情况我一般改用 scp 分块推，或者把 ISO 先切成几个小文件传到数据存储，再在存储端合并，稳定性更好。

还有一个细节：ISO 传完后建议核对文件大小和校验值。我在现场遇到过 ISO 上传到 95% 就断掉，但客户端提示成功的情况，结果虚拟机安装到一半报文件损坏，排查了半天才发现是镜像不完整。养成核对的习惯，能省很多无谓的折腾。

另外一个实操建议：给 ISO 文件命名带上版本号和系统类型，比如 win2022_zh-cn.iso、ubuntu_2204_lts.iso。数据存储里堆着一堆"1.iso"、"New.iso"的场景我在现场见得多了，时间一久根本分不清哪个是哪个。

注意：ISO 文件上传到数据存储后，不要在虚拟机挂载期间随意移动或删除。ESXi 不会阻止你删除，但会导致虚拟机 CD-ROM 失效，正在进行的系统安装会直接中断，数据丢失的风险非常高。

2.2 存储位置与磁盘格式的选择策略

ESXi 的存储分本地存储和共享存储两大类。本地存储就是宿主机内置磁盘，适合单机场景、临时环境、小规模测试；共享存储（比如 iSCSI、光纤存储、vSAN）适合集群场景，因为多台宿主机能访问同一份虚拟机文件，vMotion、HA 这些高级功能才跑得起来。

选存储位置时，除了看剩余空间，还要看数据存储的性能属性。同样是共享存储，全闪存阵列和机械盘阵列的 IOPS 差距是数量级的。数据库类虚拟机优先放 SSD 或全闪存数据存储，普通文件服务器放机械盘问题不大。如果环境里既有高性能存储也有大容量存储，按业务特性分开放置，成本和性能都能兼顾。

还有一个必须关注的参数：磁盘置备格式（Disk Provisioning）。ESXi 提供三种：

• Thick Provision Lazy Zeroed：创建时一次性分配全部空间，但不主动清零，写入性能较好，创建稍慢。
• Thick Provision Eager Zeroed：创建时分配全部空间并清零，性能和安全性最高，适合集群和容错场景，但创建耗时最长。
• Thin Provision：按需分配空间，创建快、初始占用小，但性能略低于 Thick，而且管理不当容易把数据存储写满。

我的习惯是：生产环境关键业务虚拟机用 Thick Eager Zeroed，避免运行时空间不足和性能波动；测试环境用 Thin Provision，节省空间。Thin Provision 最大的坑是数据存储被"写满"——界面上看着还有剩余空间，但虚拟机文件不断增长，最终导致需要分配新空间的操作全部失败。这种问题排查起来隐蔽性强，日志里往往是莫名其妙的 I/O 错误。

2.3 网络适配器模式与端口组的实际考量

ESXi 的网络虚拟化靠 vSwitch（虚拟交换机）实现，虚拟机网卡必须接在某个端口组上。创建虚拟机时选择网卡类型也很关键，常见的有 VMXNET3、e1000e、e1000。新版本 ESXi 和现代客户机系统，首选 VMXNET3，这是专门为虚拟化环境优化的 vNIC，性能好、队列多、支持高级特性。e1000 系列是模拟 Intel 千兆网卡，兼容性最好但性能明显弱于 VMXNET3，一般用于旧系统或者安装引导阶段。

这里有个很实际的坑：如果客户机是 Linux，安装时选了 e1000e，系统才能识别网卡；等后来装了 VMware Tools，网卡还是 e1000e。你想换成 VMXNET3 的话，必须关机修改虚拟硬件，然后在客户机里重新配置网络接口名——因为新的 vNIC 会生成全新的接口标识，原有的 eth0 配置直接作废。所以我的建议是：安装引导阶段可以用兼容性更好的网卡类型，等装完 VMware Tools、确认系统稳定之后，再计划切换为 VMXNET3，前提是你愿意承担一次网络配置的重新调整。

端口组的选择同样不能出错。创建虚拟机时的网络选项会列出宿主机上已有的端口组，选错了意味着虚拟机所属的 VLAN、安全策略、流量规则全都不对。我建议在创建端口组时就把名字起清楚，比如 VLAN10_Web、VLAN20_DB，比纯数字编号直观得多。端口组的命名规范看起来是小事，但在几十台虚拟机的环境里，混乱的命名会浪费大量排查时间。

3. 虚拟机创建向导全流程实操：关键参数逐项拆解

准备工作就位后，下面把创建虚拟机向导里的关键步骤逐项拆开讲。我用的是 vSphere Client 的 HTML5 界面，不同小版本的界面布局略有差异，但核心逻辑是一致的。这一节是全文操作量最大的部分，建议对照着界面一步步看。

3.1 创建向导核心参数逐项解析

在 vSphere Client 中右键宿主机或集群，选择"新建虚拟机"，进入向导。第一步选择"创建新虚拟机"，随后进入"选择名称和客户机操作系统"。

虚拟机名称建议用小写字母和数字，配合业务含义命名，比如 web-prod-01、db-test-02，不要用中文和特殊符号。虚拟机在数据存储上的文件名、配置文件路径都会带上这个名称，命名不规范，后面做脚本化运维、批量备份时会非常痛苦。

客户机操作系统类型的选择是关键点。ESXi 会根据你选择的系统类型设置默认虚拟硬件参数和兼容特性，比如是否启用某些 CPU 特性、默认内存推荐值。选错了系统类型虽然大多数时候不影响正常启动，但可能导致部分虚拟化特性没启用。比如选了"其他 Linux"，系统可能不启用某些高级 CPU 特性或 UEFI 安全启动，后续启动异常时排查方向会偏离。选择时尽量精确到具体发行版和版本号。

兼容性选项建议选择与当前集群 ESXi 版本对应的虚拟硬件版本。如果你不确定集群将来是否会保持或升级，选低一个版本反而更稳，因为虚拟硬件版本只能升不能降。这个点很多人忽略——我遇到过一台虚拟机为了兼容旧版本主机特意选了低版本虚拟硬件，后来集群升级完想用新特性，才发现必须关机去手动升级虚拟硬件版本，而且中间还有兼容性检查的红线，影响面比想象中大。

3.2 配置 CPU 与内存的计算方法

CPU 和内存是虚拟机性能的核心，也是资源超分的重灾区。ESXi 上的 vCPU 不是物理核心，而是虚拟处理器抽象。分配 vCPU 数量时，要结合客户机系统的并发线程数和物理机的核心总量。举个例子，物理机 32 核，你给 20 台虚拟机各配 4 vCPU，超分比是 4:1，日常负载不高时没问题，但如果几台虚拟机同时跑满，CPU Ready 时间会飙升，表现就是整机响应变慢、应用超时。

内存方面，ESXi 支持超额分配，超分部分在物理内存不足时会触发回收。我一般遵循一个经验：虚拟机初始内存设为日常负载的 1.5 倍左右，关键业务虚拟机设置内存预留，保证峰值期资源不被回收。比如一台 Java 应用服务器，日常占用 4GB 出头，我给 8GB，预留设为 6GB。集群内存充足时全部可用，内存紧张时也能保证不崩溃。内存预留过高会降低集群实际可用内存，设置时要在保障和利用之间找平衡。

CPU 高级参数里有三个概念值得花时间搞懂：预留（Reservation）、限制（Limit）、份额（Shares）。预留是保证给你的量，限制是最高可用量，份额是竞争时的权重。生产环境典型的做法是：核心业务虚拟机设置预留和高份额，测试虚拟机设置限制和低份额。这就像一台物理服务器同时跑多个业务，资源不够时优先保住核心业务，而非核心业务可以牺牲。

我配虚拟机的习惯顺序是：先确认内存和 CPU 总量够不够，再看 CPU 超分比是否合理，最后设置预留和份额。顺序搞反的话，后面调参会发现资源层面已经卡死，只能重新规划。

3.3 磁盘容量与控制器类型的选择

创建向导的存储步骤里，要选择数据存储并指定磁盘大小和置备格式。磁盘大小的设定要考虑数据增长因素，但也不要盲目给大。Thin Provision 模式下虚拟磁盘文件会动态增长，一旦增长到很大的体量，将来做存储迁移、vMotion 都会更耗时，快照链也会变长。我一般建议初始磁盘大小按业务未来 6 到 12 个月的预期数据量来设，再留 20% 余量，而不是简单"给个 500GB 吧"。

控制器类型一般有 LSI Logic SAS、LSI Logic Parallel、PVSCSI 等。现代 VMware 环境里，Linux 和 Windows 系统优先用 PVSCSI，性能更好，VMware Tools 会安装对应驱动。LSI Logic SAS 兼容性更好但性能一般，用于安装引导阶段或者某些不识别 PVSCSI 驱动的系统。值得注意：虚拟机可以配置多个 SCSI 控制器，每块虚拟磁盘挂到不同控制器上，能提升并发 I/O 能力。高 I/O 负载场景下，这个配置细节能明显改善磁盘性能。

磁盘模式里有个"独立-持久"和"独立-非持久"的概念。独立磁盘不参与快照，非持久磁盘关机后数据不回写。生产环境不建议用非持久磁盘，因为数据丢失概率极高。我遇到过同事用非持久磁盘跑测试库，晚上关机第二天数据全没了的案例，排查了半天才意识到是磁盘模式的问题。快照机制很重要，但别让"非持久"这种模式溜进生产环境。

3.4 操作系统安装与 VMware Tools 的配合

创建完虚拟机后，进入"自定义硬件"界面，把 CD/DVD 驱动器设置为从数据存储上的 ISO 文件引导。有两个连接选项：启动时连接和连接。建议勾选"启动时连接"，否则虚拟机开机时可能不会自动读取 ISO，尤其部分客户机系统对 CD-ROM 变更不敏感，安装引导不起来还以为是系统镜像问题。

挂载 ISO 后开机进入系统安装流程，这一步和物理机装系统差不多，区别在于 ESXi 虚拟机的虚拟硬件有自己的特性。Windows 安装过程中，如果没有 VMware Tools 提供的虚拟驱动，某些设备会显示为未知设备，比如 VMXNET3 网卡和 PVSCSI 控制器。所以系统装完、网络配好之后，第一件事就是装 VMware Tools。

VMware Tools 在 Windows 系统里是 exe 安装包，在 Linux 系统里通常通过 open-vm-tools 包安装，也可以在客户机系统里挂载 VMware Tools 镜像。装完 VMware Tools 后，虚拟机的关机、重启指令才能真正做到从客户机内部优雅执行，而不是宿主机直接断电。没装 VMware Tools 的虚拟机，长期运行的风险很大，内存回收、I/O 队列、时钟同步都不受控，这是虚拟化环境里最常见的"慢"和"卡"的隐性原因。

还有一个小细节：虚拟机安装完成后，记得把 CD/DVD 的 ISO 挂载从"数据存储 ISO 文件"改为"客户端设备"或断开连接，防止客户机系统里误读光驱。生产环境的虚拟机，把 CD/DVD 设置成"客户端设备"并取消"启动时连接"，会更干净，也避免数据存储上的 ISO 文件被长期占用无法移动。

4. 常见安装问题与排查技巧实录

这一部分记录的都是我在实际环境里碰到过、或者帮同事排查过的问题。虚拟化环境的问题排查有一条主线：按"宿主机资源—存储—网络—客户机系统"的层次一步步排除，不要一上来就怀疑客户机系统内部的问题。下面按这个主线整理成速查表，每条都附上排查思路。

4.1 虚拟机无法开机的问题排查

虚拟机创建完点开机，直接报错，这是最让人头疼的场景之一。先看报错信息，常见的有：不支持请求的资源或模块、内存不足、虚拟磁盘文件无法访问。

内存不足的错误，多半是宿主机可用内存不够，或者内存预留配置不合法。前面提到内存超分是常态，但如果创建虚拟机时设置了内存预留，ESXi 在创建时就会预留物理内存，宿主机不够直接就失败。解决办法是降低预留值，或者先关掉一些测试虚拟机释放内存。

虚拟磁盘文件无法访问，大多数是数据存储路径或权限问题。排查时先看磁盘文件所在目录是否存在、文件名是否符合规范。另外，如果是共享存储，还要检查多台宿主机对同一数据存储的挂载状态是否一致。我遇到过一个案例：同一数据存储被挂载到两台宿主机，其中一台的 iSCSI 会话中断了，虚拟机注册不了，恢复存储连接后才解决。

还有容易被忽略的开机失败原因：虚拟硬件版本过高。如果虚拟机是从较新版本环境导出的模板创建的，而当前宿主机较旧，可能因为虚拟硬件版本不兼容导致无法开机。创建时通常会有提示，但如果是导入 OVF/OVA 模板，提示往往不明确，只能按层次排查确认。

4.2 网络不通的排查清单

虚拟机创建完，系统也装好了，结果 ping 不通，这个问题的出现频率非常高。排查顺序建议固定下来：

• 先在 vSphere Client 的虚拟设备界面看网卡状态，确认"已连接"和"启动时连接"都勾选了。
• 再检查端口组是否正确，特别是 VLAN 和物理上行链路的配置。
• 然后看客户机内部 IP 配置是否正确，DHCP 是否获取到地址。
• 如果客户机系统里网卡显示"网络电缆被拔出"，查看网卡类型是否被客户机正确识别，比如 Windows 下缺少对应驱动，设备管理器里会显示未知设备。

另一个常见情况：客户机里网络通了，但其他虚拟机访问不了这台新虚拟机。这个大多是防火墙或安全策略问题，先检查客户机系统自带防火墙，再检查 ESXi 主机层面的防火墙规则。ESXi 自身有默认防火墙策略，如果开启了特定端口或者跑了第三方安全工具，要注意规则是否匹配。

我多次排查这类问题后总结了一个习惯：在虚拟机里先 ping 网关和外部地址，同时从宿主机侧看端口组的统计信息，用二分法锁定故障层级。这样比漫无目的地抓包高效得多。

4.3 存储性能与空间告警的常见原因

数据存储空间告警，是最容易收到又最容易忽略的告警。前面提到 Thin Provision 的按需分配机制，虚拟机文件会随时间增长，如果数据存储容量本身就紧，告警会反复出现。处理办法：删除过期快照、迁移不用的虚拟机、扩展数据存储，或者把 Thin 磁盘转为 Thick 前先规划好空间。

存储性能异常的表现是虚拟机磁盘 I/O 延迟升高，VMware Tools 或客户机里的监控工具能看到磁盘响应时间变大。排除方法也不复杂：

• 检查宿主机存储控制器是否出现故障或降级，比如 RAID 卡电池失效导致写缓存降级，这种情况性能下降非常明显。
• 检查数据存储是否被薄式置备磁盘写满，导致文件系统碎片化和元数据操作变慢。
• 检查虚拟机磁盘控制器类型，PVSCSI 的并发队列能力比 LSI Logic 强很多，磁盘性能有问题时优先看看这里。

还有一个容易被忽略的点：快照链过长。虚拟机的快照文件是增量方式写入的，快照层级越多，读取时需要回溯的数据块越多，I/O 延迟会显著上升。如果你发现某台虚拟机磁盘性能突然下降，先看快照管理器，十次里有七八次是快照堆太多了。

4.4 克隆与迁移中的典型坑

虚拟机创建后，通过克隆功能可以快速部署多台相同配置的虚拟机。但克隆前要养成一个习惯：先对源虚拟机做系统标准化，比如修改主机名、清理临时文件、重置 Windows 的 SID、调整网络配置避免冲突。否则克隆出来的机器要么主机名重复，要么网络配置互相干扰，对生产环境造成麻烦。

还有 vMotion 迁移时的坑。虚拟机需要共享存储才能做无中断的 vMotion；如果虚拟机放在本地存储上，迁移时会触发磁盘移动，这意味着需要额外的时间复制磁盘文件。如果业务承载在本地存储上，规划时就要预留迁移窗口，不要等到业务高峰期才做迁移。

快照是 ESXi 里的双刃剑，前面说过多次。快照不是备份，正式环境做变更前打一个快照，变更完成确认无误后立即删除。快照留着超过一周，等于给自己埋雷。我见过最夸张的一个环境，一台虚拟机打了十二级快照链，数据存储空间被吃掉大半，磁盘 I/O 慢到业务无法使用，清理快照花了整整一个维护窗口。

5. 模板化部署与运维规范化经验

虚拟机创建不是一次性的动作。对于经常要部署新系统的环境，模板化是真正提效的关键，也是我从一次次重复劳动里悟出来的心得。这一节聊聊模板部署的思路，以及快照、备份、文档这些"不性感但保命"的习惯。

5.1 用模板批量部署虚拟机的思路

ESXi 的模板机制允许把一台配置好的虚拟机固化为模板，之后每次"从模板部署虚拟机"，只要指定名称和资源池，几分钟就能生成一台新虚拟机。模板化的最大价值不是省那几十分钟的安装时间，而是消除手工安装带来的配置漂移——每台机器都从同一个标准化基线出发，后续管理成本大幅下降。

模板的建立流程是：安装并配置好一台标准虚拟机，打补丁、装 VMware Tools、配好基础服务和监控代理，然后转换为模板。Windows 虚拟机在转换前最好运行 sysprep 重置系统标识，否则批量部署出来的机器 SID 相同，加入域时容易出现安全标识符冲突。Linux 相对简单，把主机名和网络配置改成占位值，部署后用脚本替换。

部署后的个性化也得提前想好：克隆出来的虚拟机共享同一套配置模板，IP、主机名、应用配置必须通过定制脚本完成。我习惯在模板里预留一个初始化脚本，部署后自动配置 IP、加入监控系统、更新密钥，这样一台新机器从模板部署到上线可以压缩到十分钟以内。模板的维护也是持续性的，系统补丁一更新，模板也得跟着更新，否则部署出来的机器又带着旧补丁，失去模板化的意义。

5.2 快照策略与备份习惯

快照和备份是两回事。快照用于变更前回滚，备份才是灾难恢复的保障。没有备份的虚拟机，在生产环境里就像没有安全气囊的车，平时没事，出事就是大事。

针对 ESXi 虚拟机，常用的备份方式有几类：基于 CBT（Changed Block Tracking）的增量备份、整机导出 OVF/OVA、以及第三方备份方案。我个人的习惯是：关键业务虚拟机每周做一次整机备份，日常变更前打快照，备份至少保留两周。这个频率可以按业务风险调整，但底线是变更前必须有快照和备份，而且备份要定期做恢复演练，否则永远不知道备份文件能不能用。

还有一个细节：给虚拟机打快照前，检查磁盘模式。独立持久磁盘是不参与快照的，如果数据盘是独立模式，必须单独处理，否则你以为快照能备份数据盘，结果数据盘根本没被保护。这个坑不大，但踩一次就够疼。

5.3 个人实操心得

最后说点我做 ESXi 虚拟机安装维护这几年积累的体会。

第一条：虚拟化部署最怕自以为是。网上教程很多，但每台宿主机的固件版本、驱动、存储类型都可能不同。创建虚拟机前，先花半小时看一下宿主机硬件信息和兼容性状态，比出问题后再排查高效得多。有时候一根内存条的故障状态没被及时发现，就会让整台宿主机上的虚拟机性能异常。

第二条：文档的重要性被严重低估。我见过太多环境，几十台虚拟机部署完没有任何台账，出问题的时候根本不知道找谁、不知道看哪台。虚拟机名称、IP、用途、负责人、创建时间、对应的备份策略，这些信息应该形成一个台账，每次部署新虚拟机就更新。这个习惯看起来很麻烦，但半年后你会庆幸当初记下来了。

第三条：虚拟机的运维没有终点。ESXi 版本升级、补丁更新、存储扩容、网络架构调整，每一次变化都可能影响虚拟机。虚拟机不是创建完就万事大吉的，持续的健康检查、资源配置调整、快照清理，才是保障稳定运行的核心。这些工作不性感，但确实是最重要的。

如果一定要我再总结一条最值得记住的经验，那就是：创建虚拟机之前，先想清楚这台虚拟机未来三到六个月会变成什么样。资源够不够、存储扩展方不方便、网络能不能升级，这些在创建那一刻就决定了上限。虚拟化环境最大的成本不是建虚拟机，而是建完之后的运维成本——把上限想清楚，后面的日子会轻松很多。