虚拟化是个好东西。但是如果物理主机出现宕机，其影响会是致命的——这甚至可能会让人渴望回到“每项功能一个物理服务器”的时代，仔细分析一下怎样做会对公司和用户有用，并决定用何种最佳的方式解决可能会出现的突发问题吧。

任何虚拟化战略的第一步，都应该包括如何处理预想中的灾难恢复。很多东西并不那么适合于虚拟化环境:

任何已经混乱无序或过于陈旧的东西

很多人将物理设备转变为虚拟机，随之它就可以被复制或存储了。在某些情况下，这种做法是有用的，但是在其他特殊情况下，这种做法实际上只是让一些杂 乱无序的旧操作系统维持了更长的使用时间而已，它们早已超过了应有的使用期限。例如，一个已经使用了几年的Windows XP电脑被转换成了虚拟镜像。照这种情况来说，该系统已经历了无数次的软件升级、删除内容等操作。又有几年过去后（以及伴随着更多的系统变更），无疑的 是，现在这个XP系统将表现出严重的CPU过载及反应时间过慢等问题。其实，更好的决策是从头创造一个全新的映像，并以有序方式安装必要软件，而不是让这 个千疮百孔的操作系统转为一个虚拟系统重新上线。

任何必须要保证安全的内容

这条与第5条有些许不同。如果对任何含有管理者不想让其他员工接触到的安全信息的系统进行虚拟化，也许就会构成一定安全风险。管理者可以在虚拟机器 上设置访问许可，防止其他人能够进行控制，但是如果那些员工有能力控制主机系统，那么这种控制手段也许就被规避了。他们也许依然能够在任何地方复制 VMware文件，进行关闭服务器等操作。

任何没有经过测试的关键任务

如果没有在虚拟平台上做过测试的话，就不要急于迁向虚拟化。即使需要花费时间，也要先测试了再说。对源进行拷贝，然后制定测试计划，确保所有程序或 者服务器如预期的运转。如果需要的话，在下班时间进行这一切。毕竟，在晚上11点发现问题总比在早上9点强。将原始源代码保持离线（仅仅是关掉，但不要断 开/删除/卸载），直到确保如预期那样朝着新目标进发。