可怕的情况 - 文件系统由多个独立的操作系统实例同时挂载

Question

我如何安全地摆脱这种情况？

详情如下：

xen 服务器已将块设备分配给 VM。但这些设备也已经安装在 Xen 中。

事实上，这些块设备中有 44 个是这样安装的。更糟糕的是，每个物理设备在 4 条路径上可见，并且每条路径都安装在单独的挂载点上。换句话说，每个设备实际上安装了 5 次。

VM 来宾操作系统通过 PowerPath 伪设备（作为 phy：块设备分配给 domU）查看路径

一些设备被格式化为 ext2 和 reiserfs。

无需向我解释这里涉及的文件系统损坏风险。

恐怕只是卸载文件系统也有可能造成损坏，觉得此时拔掉主机的电源，是最安全的选择。

请注意，所有 VM 中的应用程序（大部分为 Oracle 数据库）仍在运行和使用中。

我在调查 dom0 上的高 CPU 使用率时发现了这一点。有一个无法杀死的“查找”进程，cwd -> /media/disk-12 从/dev/sdf1 挂载，属于/dev/emcpowerr

在有人问之前，我曾经见过进程无法被杀死并继续使用 CPU 和 RAM（与失效/僵尸进程不同）时，是当有未完成的提交 I/O，例如同步返回但尚未物理上磁盘时. 更常见的是，这发生在磁带 I/O 上。

建议！？

PS我希望设备在安装后被“保留”，以防止这种事情？或者这在 Linux 上是不可能的？

编辑：首先，我确信管理程序中的 KDE）是罪魁祸首。看起来 KDE 正在安装它可以在日志记录中创建桌面图标的设备。然而，同样的事情不会发生在其他 Xen 服务器上，但所有其他服务器都运行更旧版本的 SLES 和 KDE ...... V4 似乎是有问题的，3.4 表现更好）。

此外，两个非关键虚拟机已挂起。关闭它们后，由于文件系统损坏，它们将无法再次启动。主/生产虚拟机仍在运行，其上的数据库仍在运行，但显然这是一个定时炸弹。客户正尝试在另一台服务器上的另一台 VM 上重新构建环境，但在配置某些组件时遇到问题，因此我们正在等待...

无论如何，我觉得到目前为止没有一个答案不仅仅是“最佳实践总是优雅地关闭”而且我希望得到更具体的东西......无论如何，我觉得这种情况可能需要更加小心思维。关闭是否会导致未完成的 IO（特别是来自管理程序的文件系统元数据更新）同步并导致潜在的主要文件系统损坏？

Answer 1

我没有具体的理由，但我的直觉告诉我，以下可能是最好的方法：

1. 关闭应用程序。
2. 通过网络将虚拟机中的所有数据复制到备份位置。
3. 从 VM 内卸载文件系统。
4. 关闭虚拟机。（现在该主机上只有一个虚拟机运行）。
5. 确保没有 domU 设置为自动启动。
6. 拔掉主机上的电源，以防止虚拟机管理程序执行任何“关闭”操作、同步未完成的 I/O 等。
7. 启动虚拟机，希望虚拟机管理程序本身能够在断电后幸存下来。
8. 如果失败，请重新搭建环境。（虚拟机启动磁盘是基于文件的，但数据安装点驻留在分配为块设备的外部磁盘上）
9. 检查虚拟机管理程序是否正在挂载属于 domU 的任何文件系统。在启动任何 domU 之前卸载它们）
10. 关闭 KDE 自动安装。
11. 启动 VM 并强制执行完整的 FS 检查。

11 的替代方案：启动 VM 并在不进行完整 fsck 的情况下挂载文件系统。

原因是我不希望 Xen 虚拟机管理程序有更多绝对必要的机会导致 domU 文件系统损坏。