企业官网建设流程全解析

前不久接到一个活儿，要给一台常年跑业务的 ESXi 主机上的 Ubuntu 虚拟机挂一块新硬盘。业务方的需求很朴素：原分配给数据盘的 500GB 空间已经用了 96%，不能再让服务冒风险，需要加容量。很多刚接触虚拟化的人会觉得，这不就是虚拟机设置里加块盘嘛，进去分区挂载就行。但真要落到生产环境，这中间牵扯到 ESXi 存储池容量、磁盘控制器、置备类型、分区表、文件系统、开机自挂载、快照状态——一层一层剥开以后，一个简单的“给虚拟机挂载新硬盘”操作，其实有十几个决策点。

这篇文章我会按照自己的实操习惯，把从 ESXi 控制台添加虚拟磁盘，到 Linux 虚拟机内部识别、分区、格式化、挂载的完整链路拆开讲一遍，顺便把我在生产环境踩过的坑和总结的排查思路一并分享出来。适合正在学 VMware 虚拟化、日常维护 ESXi 主机，或者要给现有虚拟机扩存储的工程师参考。整个操作难度不高，但细节决定成败。

1. 内容整体设计与思路拆解

1.1 这个需求到底要解决什么问题？

先搞清楚“挂载新硬盘”在虚拟化环境里到底指什么。很多人容易把两层操作混在一起：一层是在 ESXi 层面，给虚拟机添加一个虚拟磁盘设备，本质是在数据存储上创建一个 VMDK 文件，并把它挂到虚拟机的 SCSI 或 SATA 控制器上；另一层是在虚拟机操作系统内部，把这块新出现的块设备分区、格式化，然后挂载到某个目录，比如/data、/srv、/opt。

这两层缺一不可。仅仅在 vSphere Client 里添加了硬盘，客户机系统里看不到，这是新手最常遇到的情况；反过来，在系统里看到了设备但没有分区挂载，也不会被应用程序使用。所以下面第三章我会把两层操作都完整覆盖。

不同的加盘场景，需求重点不太一样。我归纳下来主要有三类：

• 系统盘空间不足：根分区快满了，想给根目录扩容。这种情况更推荐“扩容已有 VMDK + 扩展分区文件系统”，而不是新增一块盘。
• 数据盘需要独立容量：应用日志、数据库文件、备份目录要单独落盘。这种情况最适合“新增虚拟磁盘 + 新建挂载点”，也是本文重点。
• 容器或虚拟化平台本身需要扩展数据存储：给整个 ESXi 主机加物理硬盘，属于宿主机层面的操作，和本文的虚拟机关联低，但会直接影响你能给虚拟机分配多少空间。

我的建议是：除非确实需要扩根分区，否则数据类需求一律走“新增虚拟磁盘”路线。原因后面详细说。

1.2 加新盘 vs 扩容原盘：我为什么推荐加盘

操作前先在脑子里做一次方案对比。同样是解决空间不足，有几种常见做法：

从运维角度讲，新增一块虚拟磁盘比扩展现有磁盘要安全得多。扩展原有 VMDK 时，ESXi 层面只是把磁盘文件变大了，操作系统识别到的块设备大小也许变了，但分区表和文件系统并不会自动调整，你还需要用growpart、resize2fs或xfs_growfs去手工扩展。一旦虚拟机处于快照链中间，或者分区表格式特殊，非常容易翻车。

而新增一块虚拟磁盘，本质是一个全新的块设备，不触碰原有分区。你可以在测试环境里先演练一遍分区和挂载，再拿到生产环境操作，风险低得多。我个人的习惯是：系统盘保持“够用、干净”，所有业务数据、日志都往独立数据盘放，后续做备份、调整大小、甚至单独迁移这块数据盘都更方便。

1.3 开始动手前，先确认宿主机存储池

有几次加盘失败，不是虚拟机设置错了，而是宿主机数据存储空间根本不够。VMDK 不管用精简置备还是厚置备，都要占用对应数据存储的空间。所以第一件事，登录 vSphere Client 后，先到“存储”页面看一眼目标虚拟机所在数据存储的剩余容量。

这里有个非常容易忽略的点：如果虚拟机已经在用某块数据盘的 Thin（精简置备），而宿主机的数据存储也所剩无几，你给虚拟机再分配一块 1TB 的虚拟磁盘，ESXi 是不是直接报错？不一定。Thin 情况下它会先显示创建成功，但后续虚拟机内开始写入数据时，VMDK 文件会动态膨胀，很快就可能把宿主机数据存储写满，导致所有虚拟机一起挂掉。这个连锁反应很恐怖。

因此加盘前至少做三件预检查：

• 确认目标虚拟机所在数据存储的剩余空间，建议保留 20% 以上余量。
• 确认目标虚拟机的磁盘控制器是否还有空闲位置，一个 SCSI 控制器最多挂 15 个设备。
• 确认虚拟机是否有快照，如果有，优先在维护窗口提交快照后再操作。

如果宿主机本身物理磁盘不够了，那就需要先在 ESXi 层面添加物理硬盘并创建或扩展 VMFS 数据存储，这属于另一个话题，但逻辑上要先于虚拟机加盘完成。

2. 核心细节解析与实操要点

2.1 磁盘控制器与设备类型怎么选

在 vSphere Client 添加新硬盘时，有一个不起眼但重要的选项：控制器位置。ESXi 为虚拟机提供多种磁盘控制器类型，常见的有 LSI Logic SAS、LSI Logic Parallel、VMware Paravirtual（PVSCSI）、SATA 控制器、NVMe 控制器。

选型的核心原则：新加的磁盘尽量挂到现有控制器上，且保持控制器类型不变。原因很简单，同一台虚拟机里混用多种控制器类型虽然技术上可行，但操作系统层面的设备命名、驱动加载顺序可能复杂化，在 Windows 虚拟机上尤其明显。比如你原本是 SATA 引导的虚拟机，突然加一块 PVSCSI 控制器的盘，系统里虽然能看到，但驱动没装好就会多一道波折。

如果是 Linux 虚拟机，大部分发行版内核自带了vmw_pvscsi和mpt3sas等驱动，PVSCSI 性能比 LSI Logic SAS 好很多，适合数据库类高 IO 场景。LSI Logic SAS 的兼容性更广，适合老系统或驱动不完善的系统。理性选择方式是先看虚拟机现在的控制器类型，保持一致即可。

另外一个细节：新硬盘要挂到哪个控制器，最好在添加硬盘的时候一次选对。虚拟机在开机状态下如果新加了一个控制器并挂盘，Linux 内核可能也能识别，但部分老版本系统可能需要重启。如果你在 ESXi 上创建虚拟机时用的是默认 SCSI 控制器，新盘同样选择该控制器下的空闲位置，识别最顺畅。

注意：修改已有磁盘的控制器位置属于高风险操作，可能导致系统无法引导。添加新盘时则相对安全，但也要避免和启动盘冲突。如果需要调整控制器位置，关机状态操作更稳妥。

2.2 置备类型：Thin 还是 Thick，别等创建完才后悔

每次在 vSphere Client 里添加硬盘，都会遇到“磁盘置备”选项，很多人直接默认 Thin，但这里有必要花一分钟理解差异。

Thin Provisioning 是精简置备，VMDK 文件一开始只占实际写入的数据量。比如你分配 1TB，初始可能只占 10GB，随着数据增加慢慢膨胀。优点是节省数据存储空间、创建速度快；缺点是如果宿主机数据存储空间不够，后续虚拟机写入直接报错，甚至影响同一数据存储上的其他虚拟机。

Thick Provisioning Lazy Zeroed 是厚置备延迟置零，创建时一次性分配固定大小的空间，但不对数据块做清零，相当于空间保证有了，性能一般。Thick Provisioning Eager Zeroed 是厚置备快速置零，创建时就把所有块写零，性能最稳定，也是 VMware Fault Tolerance 和 Oracle RAC 场景的硬性要求。

实际项目里我一般这样选：

• 普通 Web 应用、测试环境、文件服务器：Thin，但要监控宿主机数据存储剩余容量。
• 数据库虚拟机、核心业务：Thick Provisioning Eager Zeroed，虽然创建时间长一点，但换回的是可预期的写入性能和空间保障。
• 空间本身就是瓶颈的集群：优先 Thin，配合容量告警和存储 vSAN 这类分布式存储来保证空间弹性。

2.3 热添加与冷添加：哪些场景必须关机

ESXi 支持在线添加新磁盘，虚拟机的 SCSI 控制器只要支持热插拔，Linux 和 Windows 都能在不关机的情况下发现新设备。但这不代表所有场景都适合在线操作。

纯测试虚拟机，我可以直接在线加盘，然后在 Linux 里执行：

echo "- - -" > /sys/class/scsi_host/host0/scan

重新扫描 SCSI 总线后，lsblk就能看到新盘。Windows 虚拟机则在“磁盘管理”里右键“重新扫描磁盘”即可。但要注意，这个在线识别是有条件的：客户机 OS 支持热插拔，且磁盘控制器驱动正确。

生产环境里，即便 ESXi 支持热添加，我仍然倾向于在维护窗口先关闭虚拟机，再添加硬盘并开机。原因有三点：避免在线操作时客户机 IO 状态不稳定；避免文件系统挂载配置写错后开机进入紧急模式而影响业务；方便同时检查虚拟机的硬件配置、快照状态、备份任务。

如果你的虚拟机是数据库、消息队列这类状态敏感的服务，强烈建议冷操作。在业务高峰期搞热插拔，出了事背锅的还是自己。

3. 实操过程与核心环节实现

3.1 ESXi 控制台添加新硬盘的完整路径

我用 vSphere Client 演示一遍标准操作路径。不同版本 UI 略有差异，但逻辑一致。

登录 vSphere Client，找到目标虚拟机，右键“编辑设置”。在弹出的窗口中点击“添加其他设备”，下拉菜单里选择“硬盘”。此时会出现一个新硬盘的配置区域，需要确认几项关键参数：

• 新硬盘大小：指定容量，比如 1024GB。注意这是虚拟磁盘大小，不是最终占用的数据存储空间。
• 磁盘置备：根据上一节的选择，决定是 Thin、Thick Lazy Zeroed 还是 Thick Eager Zeroed。
• 存储位置：必须选择虚拟机所在的数据存储，或者你希望数据存入的专用存储。
• 磁盘模式：一般选“独立/持久”或保持默认。如果这块盘要让快照排除在外，可以选择“独立-持久”，但生产环境我要提醒自己：独立盘不参与快照，备份策略要单独覆盖。
• 控制器位置：这里可以看到所有 SCSI 控制器，选择已有控制器下的空闲节点，比如“SCSI(0:1)”。

配置完成后点“保存”。如果虚拟机处于开机状态，ESXi 会热添加这块虚拟磁盘；如果关机状态，下次启动时自动出现。在 ESXi 的资源管理视图里，虚拟机的“硬盘”列表中会多出一块虚拟磁盘，状态显示“已连接”。

这里我习惯做一件事：在虚拟机“备注”里写清楚加了哪块盘、容量多少、用途是什么。比如“2025-01-20 添加 1TB 数据盘，挂载到 /data，控制器 SCSI 0:1”。这个习惯在接手别人虚拟机或自己几个月后回看时，价值极大。

3.2 Linux 虚拟机识别新硬盘的畅通做法

进入 Linux 系统后，第一步不是急着分区，而是确认操作系统已经识别到新磁盘。常用命令：

lsblk -f lsscsi fdisk -l cat /proc/partitions

我一般先跑lsblk。它会把块设备、类型、挂载点、文件系统列得很清楚。比如原来只有sda，新盘会显示为sdb。如果环境中存在 NVMe 或 virtio 设备，设备名可能是nvme0n1或vda，不要按字母顺序猜，要根据大小和lsscsi确认。

如果执行完这些命令都看不到新设备，先不要急着重启虚拟机。检查以下几项：

• 在 ESXi 里确认新磁盘确实处于“连接”状态且大小正确。
• 在虚拟机内部查看 SCSI 主机编号，执行：

ls /sys/class/scsi_host/

有几个host0、host1目录就说明有几个 SCSI 控制器。热添加后需要重新扫描，逐个执行：

echo "- - -" > /sys/class/scsi_host/host0/scan echo "- - -" > /sys/class/scsi_host/host1/scan

扫描完再执行lsblk看结果。如果是老系统，可能要安装sg3_utils，用rescan-scsi-bus.sh脚本完成扫描。工具没有装的话，apt install sg3-utils或yum install sg3_utils，一条命令解决。

提示：如果没有任何 SCSI 设备列表，可以检查虚拟机的磁盘控制器类型。某些精简定制系统没带 PVSCSI 驱动，就识别不了新加盘。这种情况要么把新盘挂到原有控制器（LSI Logic SAS 兼容性高），要么在客户机系统里补驱动后重启。

3.3 分区、格式化与挂载全流程（GPT + ext4 示例）

确认系统识别到/dev/sdb之后，开始真正“挂载”的过程。这块盘是全新的，我用 GPT 分区表，因为它没有 2TB 限制，也是当前所有 Linux 发行版默认支持的分区表格式。

第一步，创建 GPT 分区表并新建一个分区：

parted /dev/sdb --script mklabel gpt parted /dev/sdb --script mkpart primary ext4 1MiB 100% partprobe /dev/sdb

这里1MiB是起始位置，留出头部空间给分区表；100%表示使用整块盘。分区完成后，lsblk会看到/dev/sdb1。

第二步，格式化文件系统。ext4 是通用型选择，特别适合作为数据盘或日志盘：

mkfs.ext4 /dev/sdb1

如果你需要更好的大文件和高并发性能，也可以用 XFS：

mkfs.xfs /dev/sdb1

选 ext4 还是 xfs，取决于应用需求。数据库场景我更倾向 XFS 配合 LVM；普通业务、Web 文件、日志存储，ext4 完全够用，维护起来也简单。

第三步，挂载到目录：

mkdir -p /data mount /dev/sdb1 /data df -hT /data

第四步，配置开机自动挂载。这一步非常关键，如果只 mount 不写/etc/fstab，重启后系统不会自动挂载新盘。用 UUID 而不是设备名，避免设备节点漂移：

blkid /dev/sdb1

输出类似：

/dev/sdb1: UUID="8e6d31e2-1f1b-4a3a-9a9a-1f1b4a3a9a9a" TYPE="ext4" PARTUUID="..."

然后编辑/etc/fstab，加入一行：

UUID=8e6d31e2-1f1b-4a3a-9a9a-1f1b4a3a9a9a /data ext4 defaults,nofail,noatime 0 2

字段含义分别是：设备 UUID、挂载点、文件系统类型、挂载参数、是否需要 dump 备份、fsck 检查顺序。数据盘我用nofail，意思是即使盘不在，系统也能正常启动，不至于卡在紧急模式；noatime可以减少访问时间戳写入，降低磁盘 IO，对大多数业务都友好。

写完/etc/fstab后，执行：

mount -a

这一条是验证配置是否有语法错误，顺便把所有/etc/fstab里列出的未挂载分区全部挂上。如果没有报错，再执行df -hT /data确认容量正确。最后重启一遍虚拟机，验证自动挂载生效，这一步别省。

3.4 Windows 虚拟机加盘速览

Windows 虚拟机加盘的整体路径和 Linux 类似，区别在客户机内部操作。磁盘管理器打开方式：右键“此电脑” -> 管理 -> 磁盘管理，或者Win + R输入diskmgmt.msc。

新磁盘会显示为“未知”和“未初始化”。右键该磁盘选择“初始化磁盘”，分区表类型选 GPT。然后在新分配的空间上右键“新建简单卷”，一路下一步，分配盘符，文件系统选 NTFS，完成即可。如果虚拟机在线加盘后磁盘管理器里没看到，右键“磁盘管理”左侧的“磁盘管理”节点，选择“重新扫描磁盘”，一般就能刷出来。

Windows 上有个细节：如果虚拟机是 IDE 控制器引导的老系统，并且新盘挂到了 SCSI 控制器，某些精简版 Windows 可能缺少驱动，会在设备管理器里报“未知设备”。解决办法是安装 VMware Tools，它会自动补全虚拟化相关的磁盘控制器驱动。这也是为什么我一直强调，VMware Tools 如果不装，虚拟机的很多“高级功能”都是摆设。

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

4.1 加了盘虚拟机里却看不到，先别重启

这个问题出现的频率极高。我已经在前面提到重新扫描 SCSI 总线的做法，这里再给一个完整的排查清单：

• 第一，确认 ESXi 虚拟机硬件里确实存在新磁盘，且“已连接”勾选状态。
• 第二，执行lsscsi和lsblk看设备是否存在。
• 第三，扫描所有 SCSI host：

for host in /sys/class/scsi_host/host*; do echo "- - -" > $host/scan; done

• 第四，检查内核是否加载了对应控制器的驱动。PVSCSI 的模块名是vmw_pvscsi，运行lsmod | grep vmw_pvscsi查看。
• 第五，如果还不行，可能真是控制器类型不兼容，或者虚拟机处于未分配状态，需要在 ESXi 里确认“存储位置”是否可用。

这些排查步骤做完，绝大多数问题都能定位到具体环节，而不是盲目重启虚拟机。重启的确能解决一部分驱动扫描问题，但不解决根因，下次加盘还会遇到。

4.2 fstab 写错导致进不了系统怎么办

/etc/fstab是最容易让新手翻车的文件，没有之一。一旦写错设备 UUID 或挂载参数，重启时系统可能进入 emergency mode，屏幕上提示类似“Failed to mount /data”或“Timed out waiting for device”。

真遇到了别慌。系统在 emergency mode 会等待输入 root 密码，先以只读方式挂载根文件系统。执行：

mount -o remount,rw /

然后编辑/etc/fstab，把刚才写错的那一行注释掉或改对，再reboot即可恢复正常。

更稳妥的做法，是我前面提到的写nofail参数。只要数据盘那一行有nofail，即使盘真的没插上，系统也只是跳过挂载，不会卡在启动流程。生产环境里这个参数能救你很多次。

经验之谈：每次改完/etc/fstab，一定先执行mount -a，确认输出为空（说明所有条目都能正常挂载），然后再考虑重启验证。把“验证挂载”当成一个固定步骤，而不是可选项。

4.3 大于 2TB 的分区表陷阱

机械硬盘时代 MBR 分区表只支持最高 2TB 的寻址空间，超过 2TB 的部分会被截断或无法识别。虚拟化时代，你给虚拟机加一块 3TB 或 4TB 的虚拟磁盘，分区表格式必须用 GPT，否则客户机系统里看到的容量不对。

有些旧分区是用 MBR 创建的，后来通过 ESXi 扩容让磁盘超过 2TB，此时在客户机里继续扩展分区会受限。我的建议是：新盘直接 GPT，避免后面这些破事。如果旧数据盘是 MBR 且容量还没超过 2TB，需要扩容到更大，最安全的方式是——先备份数据，用 GPT 新盘挂载，迁移数据，再废弃旧盘。虽然多一步，但比在线转换分区表安全太多。

4.4 快照、权限和存储空间引发的“疑难杂症”

这是生产环境最容易吃大亏的几个点。

快照问题：虚拟机存在多层快照时，ESXi 上扩容已有 VMDK 可能失败，或者扩容后快照无法正常提交/删除。即使只是给虚拟机新增一块独立数据盘，我也会先检查快照状态。如果虚拟机已经卡在快照链上很久，不如先在低峰期把快照清理掉再做变更。否则后续每次磁盘操作都可能受到连带影响。

权限问题：部分用户登录 vSphere Client 后发现“编辑设置”是灰的，或提示“虚拟机监控程序功能对该用户不可用”。这大概率是权限不够，需要管理员账户或分配了“虚拟机.硬件.编辑”权限的账号。用 vCenter 管理的集群，还要注意角色和权限继承关系，不是能登录就等于能改硬件。

存储空间被写满：前面提过 Thin 置备的连锁风险，这里再增加一个具体场景。虚拟机内df -h显示/data还有几百 GB 可用，但宿主机数据存储已经报警，因为多个 Thin 虚拟机在同时增长。这种“客户机空闲但宿主机危险”的错觉非常容易被忽略。运维上要有宿主机存储容量告警，设置一个低于 15% 或 20% 就报警的阈值，别等事故来了再补救。

5. 从单机挂载到存储规划：几个值得养成的习惯

5.1 给虚拟磁盘做命名与描述

虚拟机的 VMDK 文件默认叫vmname_1.vmdk、vmname_2.vmdk，时间一长根本分不清哪个是系统盘哪个是数据盘。我在 vSphere Client 的虚拟机“备注”里会写清楚：系统盘大小、数据盘大小、挂载点、控制器位置、新增日期。偶尔也会在虚拟机“编辑设置”里选择某个磁盘后查看“磁盘文件”位置，把关键信息记录到内部运维文档。

如果是 vCenter 环境，还可以通过标签功能给虚拟机打上“数据盘-1TB”、“日志盘-500GB”之类的标签。这些看起来和“挂载硬盘”没什么直接关系，但真正等你需要找一块盘做迁移或扩容时，有记录和没记录的区别就是几小时和五分钟的区别。

5.2 挂载之后一定要做的事

新数据盘挂载完成，业务开始写入，这不是终点。我通常会紧接着做三件事：

第一，把这个挂载点纳入备份策略。在/data目录可能存放大量业务数据的情况下，单独把它加入备份任务，避免漏备。第二，记录 UUID 和挂载点到一个固定文档或配置管理工具中，方便后续自动化巡检。第三，如果是数据库类服务，考虑把数据库目录迁移到新盘，并合理安排目录权限和属主。

有一个我踩过不止一次的坑：数据盘挂载后没有注意挂载点权限，结果应用写入时提示Permission denied。解决办法很简单，创建目录后按应用用户设置属主：

chown -R appuser:appgroup /data chmod 755 /data

Linux 的目录权限和数据存储是两套逻辑，虚拟化层面解决不了系统权限问题。

5.3 慎用直通，VMDK 才是虚拟化存储的主流

相关热词里频繁出现 SSD 直通、SATA 直通、NVMe 直通这类关键词。我理解很多人在搞 NAS 虚拟机、软路由、开发板挂载时，会想把物理硬盘直通给虚拟机，以获得更原始的性能。但从虚拟化最佳实践来看，除非你有特别明确的需求，否则我不建议在 ESXi 里轻易做硬盘直通。

直通硬盘会让虚拟机失去 vMotion 在线迁移能力，快照功能也大打折扣，备份策略要重新设计。而且 ESXi 本身也分不清直通盘的 SMART 状态或故障告警，管理上麻烦不少。普通业务场景，VMDK 磁盘加 Thin/Thick 置备已经完全够用。如果追求性能，可以给数据存储用 SSD 或全闪阵列，再让虚拟机用 PVSCSI 控制器，效果比直通更可控。

5.4 扩展已有磁盘的场景补一句

如果你的需求确实不是加数据盘，而是把现有系统盘或数据盘扩得更大，思路略有不同。ESXi 层：关闭虚拟机，编辑设置，修改磁盘大小，注意确认没有快照。Linux 层：

growpart /dev/sda 1 resize2fs /dev/sda1

XFS 则使用：

xfs_growfs /

这个过程会直接操作现有分区表和文件系统，风险高于新增一块盘。操作前必须确认数据已备份，最好在测试虚拟机里先完整演练一遍。我在很多文章里都强调过：加盘是最安全的存储扩展方式，扩容已有分区则是最后手段。

最后再分享一个源自实际运维的小习惯。我每次给虚拟机加完盘，都会顺手在宿主机上看一眼数据存储剩余空间和该虚拟机的实时 IO 曲线。别小看这一眼，它曾经帮我提前发现了一次 Thin 置备导致的宿主机存储容量告警。那次经历了之后，我给自己定了一条规矩：任何虚拟机磁盘变更操作，都必须附带宿主机存储容量检查项。这个习惯延续至今，帮我避开了不少连锁故障。