最近我们的一台服务器因IPMI BMC故障而被吊死。 它是CentOS 6.3 OpenStack计算主机，提供带有qcow2后端的KVM虚拟机。
运行一个基于EC2 Ubintu的虚拟机镜像（精确服务器cloudimg-amd64-disk1.img）。
系统重启后，我发现一个奇怪的事情：在虚拟机上的ssh主机密钥被重新创build（13:25 – 重启时间）：
root@weather:~# ll /etc/ssh/*key -rw------- 1 root root 668 Nov 21 13:25 /etc/ssh/ssh_host_dsa_key -rw------- 1 root root 227 Nov 21 13:25 /etc/ssh/ssh_host_ecdsa_key -rw------- 1 root root 1679 Nov 21 13:25 /etc/ssh/ssh_host_rsa_key 我还发现，在FS恢复过程中，一些孤儿的i节点被删除了：
Nov 21 13:25:23 weather kernel: [ 0.901159] EXT4-fs (vda1): INFO: recovery required on readonly filesystem Nov 21 13:25:23 weather kernel: [ 0.902688] EXT4-fs (vda1): write access will be enabled during recovery Nov 21 13:25:23 weather kernel: [ 1.930773] EXT4-fs (vda1): ext4_orphan_cleanup: deleting unreferenced inode 1286 ...... Nov 21 13:25:23 weather kernel: [ 1.940810] EXT4-fs (vda1): ext4_orphan_cleanup: deleting unreferenced inode 53755 Nov 21 13:25:23 weather kernel: [ 1.940815] EXT4-fs (vda1): ext4_orphan_cleanup: deleting unreferenced inode 53754 Nov 21 13:25:23 weather kernel: [ 1.940819] EXT4-fs (vda1): 8 orphan inodes deleted
我的问题是：为什么SSH密钥可以重新创build？ 它可能是文件系统中数据丢失的结果吗？ 而今后如何预防呢？
qcow2caching模式设置为在libvirt虚拟机configuration中直写。 主机文件系统是将ZFS（zfsonlinux）放置在具有BBU的硬件RAID控制器上。
如果这是重新引导文件系统不一致的结果 – 我很困惑，因为ssh密钥文件没有改变，所有相关的数据预计将被同步到稳定的媒体。
没有人介入任何聪明的事情，所以我会说明白。
是的，这可能是由于文件系统中的数据丢失造成的。 我不能说Ubuntu的，但CentOS（RH风格）sshd启动脚本提供了自动创build的密钥，如果他们失踪，我认为ubuntu做了类似的事情。
如果您的虚拟机的文件系统由于底层主机的故障而损坏， 并且系统的ssh密钥被破坏， 那么我希望它们会自动重新生成，因此也就改变了。
那是怎么回事？ 可悲的是，在这一点上，我不认为有人可以说。
如果你的系统是tripwire d，那么你可以对FS进行一些基线审计，你可以比较当前状态，以便对VM映像发生的事情做出更明智的决定。 事实上，你必须做出一个商业决定，确定这台机器是否足够敏感，能够certificate彻底清理重build，还是只是耸耸肩，接受它作为其中一件事情。