虚拟机增加存储后系统不识别，多半不是硬件故障，而是操作系统没主动去“发现”这块新空间在宿主机层扩容或挂载磁盘后，你需要进系统里手动执行一次磁盘扫描、刷新分区表，再扩展文件系统。
下面直接按排查顺序拆解这个问题，多数情况下,你缺的只是以下某个操作步骤。
虚拟机磁盘扩容后不识别？先看卡在了哪一层
虚拟机加存储，跟物理机加硬盘还不完全一样，物理机插上硬盘开机，BIOS会替你发现它；虚拟机里加完磁盘，宿主机通常不会给客户机系统发送一个“热插拔通知”除非你的虚拟化平台配置了热插拔控制器，所以扩容后不识别,首先要判断是下面哪一层出了问题。
- 存储层没认到：虚拟机系统里连磁盘本身都看不到，
lsblk或磁盘管理里压根没有新增容量对应的那行记录。 - 分区表没刷新：磁盘是认出来了，但容量还是旧值,分区表还停留在扩容前的状态。
- 文件系统层没扩展：分区表已经占了新空间，但文件系统还是原来的大小，系统认为盘“没涨”。
判断方法很直接，以 Linux 为例执行 lsblk，看磁盘设备有没有变大的容量；再执行 fdisk -l 看分区有没有认到新空间，Windows 用户直接打开“磁盘管理”窗口，观察磁盘对应的图形条是否出现灰色未分配空间，这一步做完,问题基本就定位到具体层了。
| 故障现象 | 实际位置 | 典型表现 |
|---|---|---|
| 看不到磁盘设备 | 存储层 | VMware 里增加了磁盘，但系统内无任何新设备 |
| 磁盘有容量变化，分区没变化 | 分区表 | fdisk 显示整盘 200G，但分区仍 100G |
| 分区占满了，文件系统没变大 | 文件系统 | df -h 显示容量跟扩容前一样 |
Windows 虚拟机扩容后不识别怎么办
Windows 系统对磁盘变化相对“迟钝”，很多用户扩容完重新登录进系统，发现 C 盘还是老样子，急得又重启了一次,其实大部分情况不用重启。
先让 Windows 重新扫描一次磁盘
Windows 默认不会主动发现新增的磁盘空间，需要手动触发一次枚举操作，这一步是几乎所有 Windows 虚拟机扩容后不识别问题的突破口。
- 打开“设备管理器”。
- 展开“磁盘驱动器”。
- 在对应的虚拟磁盘名称上右键，点击“扫描检测硬件改动”。
扫描完成后，磁盘管理里通常会显示新的未分配空间，如果你用的是 VMware Workstation 或 ESXi，这一步基本就能让 Windows “看到”多出来的容量。
磁盘管理里找“未分配空间”，右键扩展卷
扫描完成后，按下 Win + X 打开“磁盘管理”，你会看到某一块磁盘的图形条右侧有一段黑色的“未分配”区域。
- 在已有的系统分区（C 盘）上右键，选择“扩展卷”。
- 按向导默认操作,把未分配空间并入系统分区。
- 点击完成后刷新一下资源管理器，C 盘容量就会变大。
有一个很常见的场景：VMware 增加磁盘后看不到未分配空间，结果发现是因为原有分区是 MBR 格式，且容量超过 2TB 上限，这类虚拟机扩容需要先转成 GPT 分区表格式才能继续扩展,转格式前务必先备份数据。
在线扩容时别忽略“只读”风险
Windows 虚拟机在线扩容后，部分磁盘可能被标记为“只读”，这是微软针对底层存储变更行为的保护机制，如果扩展卷选项是灰色不可点击的，先检查磁盘是不是变成了脱机或只读状态，右键磁盘名称，选择“联机”或者“重新激活”,再执行扩展操作。
Linux 虚拟机扩容后系统识别不到新空间
Linux 下的处理流程比 Windows 多一步，而且每一步的顺序都不能乱：确认设备大小、重新读取分区表、调整分区、扩展文件系统。
先确认内核是否发现了新容量
Linux 的磁盘扫描不像 Windows 有图形按钮可点，全得靠命令确认,先跑两个命令：
lsblk fdisk -l
lsblk 显示 sda 已经从 50G 变成 100G，说明存储层已经认到，问题出在分区上，如果还是原来的容量，说明内核还没感知到磁盘变化，此时需要让内核重新扫描 SCSI 设备,执行：
echo 1 > /sys/class/scsi_disk/0:0:0:0/device/rescan
路径里的 0:0:0:0 代表设备号，可能因环境而异，执行 ls /sys/class/scsi_device/ 查看实际路径，逐一执行也可以，操作完成后再次运行 lsblk,确认容量是不是已经变大。
用 partprobe 刷新分区表，避免重启
很多人扩容完直接跑 fdisk 去改分区，结果发现操作完系统还是显示旧分区，这是因为 Linux 内核缓存了旧的分区表,需要手动通知它重新读取。
分区编辑完成后,执行：
partprobe /dev/sda
partprobe 是 parted 工具包里的命令，用于通知内核重读分区表，部分云主机或老版本内核可能不支持热加载，出现 Device or resource busy 报错，这时只能计划内重启一下虚拟机，在大多数本地虚拟化环境中，partprobe 就能解决问题。
分区表扩完后，文件系统还得再“吃”一遍新空间
这步常被人忽略，哪怕分区已经占了整块盘 100G，文件系统依然停留在 50G 的认知上,不同的文件系统使用的命令不一样：
- ext4：
resize2fs /dev/sda1 - xfs：
xfs_growfs / - btrfs：
btrfs filesystem resize max /
执行完再跑 df -h，你会看到文件系统容量已经跟上分区的大小，需要留意的是，xfs 文件系统不支持缩容只支持扩容，在线扩容时不要瞎执行 xfs_growfs 的参数,按默认即可。
常见场景下的快速定位思路
虚拟化环境各不相同，处理方式也有些差异，结合一些高频场景,这里给你几条可验证的排查路径。
VMware 虚拟机扩容后不识别，优先查 SCSI 控制器
VMware 环境下，磁盘扩容完成后如果系统里完全找不到新空间，大概率是 SCSI 控制器类型不匹配或未啟用热插拔，开机状态下扩容时，右键虚拟机 → 编辑设置 → 将 SCSI 控制器类型改为“VMware Paravirtual”，并在选项里勾选“热添加”，但要注意，修改控制器类型可能导致系统内磁盘盘符变化,生产环境需谨慎评估。
虚拟机增加存储后重启不识别，可能是驱动没跟上
如果重启后依然不识别，问题多半出在虚拟磁盘驱动的加载顺序上，尤其 Windows 虚拟机装在非默认 IDE 控制器下时，系统启动阶段未加载虚拟 SCSI 驱动，导致磁盘全部脱机，进入设备管理器检查存储控制器项有没有黄色感叹号，有则重装对应的 virtio 或 VMware Tools 驱动。
面板里扩容了，但 fdisk 显示磁盘容量仍没变
这种情况常见于云平台或存储设备在线扩容后没有触发 SCSI 总线重新扫描，除了前文提到的 rescan 命令外，也可以从宿主机端执行媒体扫描操作，比如在 ESXi 中，对目标虚拟机执行“重新扫描所有存储设备”，再回到系统内用
fdisk -l 验证，部分用户在 OpenStack 平台也反馈过类似问题,通常需要给实例热挂载一个同样的空盘触发热插拔事件。
这几个坑最容易让人绕远路
围着“识别不到”这个问题折腾半天,最后发现是下面几个细节没注意。
- 扩展的是磁盘，不是分区：很多人在 VMware 界面对“硬盘 2”扩容，但系统里想扩的是“硬盘 1”上挂载的分区,这种操作不会产生任何效果。
- 扩容顺序反了：有人直接在磁盘末尾新建一个分区，然后重启再挂载，其实原有分区可以无损扩展,不必非得新建分区占掉整块盘。
- 文件系统在线扩容上限：部分老旧的 Linux 内核版本不支持某些文件系统的在线扩容，比如旧内核上的 ext4 在线扩容需要分区开头有保留空间，没留的话会直接扩容失败，行业共识认为，生产环境扩容前先看一下内核版本和文件系统类型,能省掉大量回滚时间。
- Windows 的 pagefile 占用了空间：磁盘管理里看着有几十GB的未分配空间，但扩展卷时循环报错，先临时把虚拟内存调到其他盘，扩展完再调回来,问题可能就消失了。
虚拟机增加存储后系统不识别，常见问题快答
Q1：Windows 的 C 盘扩容后容量没有变成新分配的大小？
执行设备管理器里的“扫描检测硬件改动”，再进磁盘管理确认磁盘上有未分配空间，如果没有未分配空间，说明扩容可能没作用到正确的磁盘编号上，检查虚拟机设置里的磁盘列表，确认你修改的是不是装有 C 盘的那块虚拟磁盘。
Q2：Linux 虚拟机扩容后 df -h 显示容量没变？
df 查的是文件系统大小，不是磁盘大小，先后台执行 lsblk 查看分区大小，分区已经变大就说明文件系统还没扩展，ext4 用 resize2fs，xfs 用 xfs_growfs，执行完再 df -h 就能看到变化。
Q3：扩容操作做完，虚拟机直接启动不了了？
这通常和磁盘扩容无关，而是扩容过程中虚拟磁盘文件损坏，或分区表被误操作改写，在宿主机上检查虚拟机日志，看有没有磁盘 I/O 错误记录，如果启动卡在 grub 界面，用系统安装镜像进入救援模式，检查 /boot 分区是否完整，下次扩容前,先对虚拟机做一次快照备份能够把风险降到底部。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/630815.html
