我该如何安全地摆脱这种情况？
详情如下：
Xen 服务器已将块设备分配给 VM。但这些设备也被安装在Xen内部。
事实上已经有 44 个这样的块设备被挂载了。更糟糕的是，每个物理设备都可以通过 4 个路径看到，并且每个路径都安装在单独的安装点上。换句话说，每个设备实际上安装了 5 次。
VM 来宾操作系统通过 PowerPath 伪设备查看路径（作为 phy: 块设备分配给 domU）
一些设备被格式化为 ext2 和 reiserfs。
无需向我解释这里涉及的文件系统损坏风险。
我担心即使只是卸载文件系统也可能会导致损坏，并且感觉此时从主机上拔掉电源是最安全的选择。
请注意，所有虚拟机中的应用程序（大部分是 Oracle 数据库）仍在运行和使用。
我在调查 dom0 上的高 CPU 使用率时发现了这一点。有一个不可杀死的“find”进程，cwd -> /media/disk-12 是从 /dev/sdf1 挂载的，属于 /dev/emcpowerr
在有人问之前，我第一次看到进程无法被杀死并继续使用 CPU 和 RAM（与失效/僵尸进程不同），是当存在未完成的提交 I/O 时，例如同步已返回但物理上尚未在磁盘上。更常见的是，这种情况发生在磁带 I/O 上。
建议！？
PS 我希望设备一旦安装就会被“保留”，以防止这种事情发生？或者说这在 Linux 上是不可能的？
编辑：首先，我确信虚拟机管理程序中的 KDE 是罪魁祸首。看起来 KDE 正在安装它可以记录的设备来创建桌面图标。然而，同样的事情并没有发生在其他 Xen 服务器上，但所有其他服务器都运行的是旧版本的 SLES 和 KDE...V4 似乎是有问题的版本，3.4 的表现更好）。
此外，两个非关键虚拟机已挂起。关闭它们后，由于文件系统损坏，它们将无法再次启动。主/生产虚拟机仍在运行，其上的数据库仍在工作，但显然这是一颗定时炸弹。客户正在尝试在另一台服务器上的另一台虚拟机上重新构建环境，但在配置某些组件时遇到问题，因此我们正在等待...
无论如何，我觉得到目前为止，没有一个答案超过“最佳实践总是优雅地关闭”，我希望得到更具体的东西......无论如何，我觉得这种情况可能需要更加小心思维。关闭是否会导致未完成的 IO（特别是来自虚拟机管理程序的文件系统元数据更新）同步并导致潜在的重大文件系统损坏？
答案1
如果从单个安装点写入磁盘，则不会造成任何损害。进行干净的关闭，（如果愿意的话，将其从暂停状态备份）修复安装座。除了 Dom0 上所需的应用程序外，不要运行任何其他内容。 OTOH，如果分区是从多个路径写入的，那就很糟糕，而且会变得更糟。拔插头。
答案2
我没有具体的理由，但我的直觉告诉我，以下可能是最好的方法：
- 关闭应用程序。
- 通过网络将虚拟机中的所有数据复制到备份位置。
- 从 VM 内卸载文件系统。
- 关闭虚拟机。 （现在该主机上只有一个虚拟机运行）。
- 确保没有将 domU 设置为自动启动。
- 拔掉主机上的电源，以防止虚拟机管理程序执行任何“关闭”操作、同步未完成的 I/O 等。
- 启动虚拟机，希望虚拟机管理程序本身能够在断电后幸存下来。
- 如果失败，请重新搭建环境。 （虚拟机启动磁盘是基于文件的，但数据安装点驻留在分配为块设备的外部磁盘上）
- 检查虚拟机管理程序是否正在挂载属于 domU 的任何文件系统。在启动任何 domU 之前卸载这些文件系统）
- 关闭 KDE 自动安装。
- 启动 VM 并强制执行完整的 FS 检查。
11 的替代方案：启动 VM 并在不进行完整 fsck 的情况下挂载文件系统。
原因是我不希望 Xen 虚拟机管理程序有更多绝对必要的机会导致 domU 文件系统损坏。
答案3
我不是 Xen 专家，也没有这方面的经验。但如果我处在你的位置，我的做法是：首先我知道我可能会丢失数据（甚至可能是全部）；其次，我会尝试创建快照，然后挂起虚拟机，将它们恢复到安全的不同环境中。
我不想给你虚假的希望，但我认为如果你能恢复任何东西，你就会很幸运。
警告：遵循这些建议可能会让你失败全部数据。这取决于您是否值得冒险。
幸运的是，您的应用程序仍然可以运行，因为它们使用的数据都位于易失性内存中。您应该尝试利用这种情况（尝试评估每个应用程序是否可能出现这种情况）并将实时数据导出到网络共享（如果应用程序提供此类功能）。如果磁盘上有任何数据，则此导出函数可能会像您的find语句一样被“锁定”，或者由于磁盘数据更改/损坏而崩溃（并导致应用程序或操作系统崩溃）。
然后你可以尝试做一个实时快照，如下文章中的说明：在 Xen 中创建快照。我会选择逐字节快照，尽管它可能会像您的find命令一样卡住……但是，我不会抱有这么大的希望。
在执行上一个命令之前，您应该阅读 Citrix 的此文档，该文档有助于了解 Xen 中的快照 (PDF)。
祝你好运。