1、需求背景
vcs集群，问题是在app14主机在测试丢包问题时，重启了app14的主机，重启时业务迁移到app20备机上了，但是app20上怀疑当时没有迁移成功，出现了共享盘的IO error问题。后经过核查发现app13,14,15,16对应的共享盘在app20备机上状态都不正常，如下：
同时，在app20该主机上使用fdisk -l也无法看到对应的/vdb/vdc/vdd/vde/vdj五块盘。
经过确认，vdb/vdc/vdd/vde/vdj跟云盘对应关系如下：
|
磁盘 |
云盘 |
|
/dev/vdb |
medapp13-data |
|
/dev/vdc |
medapp14-data |
|
/dev/vdd |
medapp15-data |
|
/dev/vde |
medapp16-data |
|
/dev/vdj |
medapp14_20_50g |
目前备机上没跑业务，文件系统挂载如下：
[/root]# df -Th
目前app14上在跑业务，文件系统挂载如下：
$df -Th
App20本地挂载文件：
#cat /etc/fstab
App14挂载文件：
#cat /etc/fstab
注意，上面均未发现这些lv文件系统被使用了。
2、处理思路
这里面有两个问题：
- 未使用的云盘，可以从tecs层面去掉。
未使用的云盘为如下四块：
- 对于共享的在资源组中的盘，需要在app20虚机上，在tecs层面重新卸载然后在挂载。
![]()
3、执行步骤
3.1.删除未使用的云盘
3.1.1.卸载app20虚机上的无用云盘
root用户登陆app20：
针对要移除的vg，先去除激活:
vgchange -an vgapp15
vgchange -an vgapp16
vgchange -an vgapp13
里面没看到vgapp14，就不需要去除激活，后面其他主机也一样（能看到的就需要去激活，不能看到的就不做，注意该操作只针对vgapp13,vgapp14,vgapp15,vgapp16这四个vg，其他vg不能做任何操作）。
卸载不需要重启虚机，对虚机没有影响。
3.1.6.卸载后检查
# vgscan
不能看到vgapp13,vgapp14,vgapp15,vgapp16这四个vg在上述虚机上。
# fdisk -l |grep Disk
不能看到medapp13_20_50g/medapp14_20_50g/medapp15_20_50g/medapp16_20_50g这四个云盘对应的四个50g的磁盘了。
3.2.重新卸载/挂载IO error的盘
3.2.1.重新挂载app20的共享盘
3.2.1.1.卸载
卸载后对虚机来说是立即生效的。无需重启虚机。
输入虚机app20的名称，下拉列表中会有对应的数据，选中后点确定就可以完成重新挂载。
我这个图中是因为该磁盘并未从app20上卸载（已经挂在app20上了），所以显示没有符合条件的数据。挂载完成后，注意挂载到了系统层面的具体哪个盘(/dev/vd?)，后面我们直接根据这个去操作系统层面检查挂载。重新挂载后根据经验来说虚机层面不需要重启，可以在线识别。
3.2.1.3.检查挂载
# fdisk -l |grep Disk
可以看到对应大小的磁盘，上面3.2.1.2步骤中可以看到对应的云盘挂载到操作系统层面是/dev/vd?，直接检查对应的/dev/vd?即可。
# vgscan
通过该命令也可以看到对应的vg。
4、影响说明
1、对于3.1的操作，卸载无用的盘，并释放对应的云盘可以回收磁阵空间，同时也可以降低错误概率。卸载对业务没有感知，不影响业务。
2、对应3.2的操作，由于当前业务都是跑在主机上的，备机app20上并没有业务，所以重新卸载和挂载共享盘，对业务也没有影响。
3、资料参考
https://www.linuxtechi.com/fixing-lvm-io-errors/