(这个正确答案与这个问题表面上没有什么相似之处。提出问题并参考那个问题自己回答。)
考虑一个虚拟主机环境,其中为 VM 分配了 3 个独立的virtio
驱动器(显示为 3 个独立的块设备),并分配给 3 个独立的 VG(卷组)。
- 操作系统
/dev/vda
--vgroot - db--
/dev/vdb
vgdata - var--
/dev/vdc
vgvar
当虚拟机在线时,它/dev/vdb
就会消失。这可能是由于虚拟机被移动到新的虚拟机管理程序,但该特定卷被卡住,或者可能是疯狂的系统管理员删除了该卷并将其暂时放在另一台主机上。就我而言,我感到很幸运。
当卷恢复时,Linux 内核(实际上不是全部;但至少从 RHEL6 开始)不会将其分配给其原始驱动器号,因为该磁盘在技术上被视为“打开”,而是分配给一个新的块设备:/dev/vdd
。
之后,所有 LVM 命令,例如vgs
、 报告 :
/dev/data/db: read failed after 0 of 4096 at 10733158400: Input/output error
/dev/data/db: read failed after 0 of 4096 at 10733215744: Input/output error
/dev/data/db: read failed after 0 of 4096 at 0: Input/output error
/dev/data/db: read failed after 0 of 4096 at 4096: Input/output error
但是,pvscan
并vgscan
检测原始卷,但它们仍在尝试读取旧的块设备。重新安装也不行。为了争论,重新启动是不可接受的。该怎么办?
答案1
iscsi
这个问题在磁盘的相关讨论中得到了回答这里。由于我根本不使用 scsi,而是virtio
使用 Google 搜索,因此无法帮助找到我的答案。如果您遇到这个答案,请务必投票给吉塞佩的答案。简而言之,就是:
vgscan ; vgchange <vgname> --refresh