在你的環境中引入第二個Hypervisor，需要仔細計劃和測試。第二個Hypervisor必須和現有的一樣，完全支持預期的服務器硬件平臺、設備驅動和操作系統版本，當然還有應用程序。使用雙Hypervisor會有什么風險呢？需要怎么解決？

如果已經有一個第三方的Hypervisor管理工具，必須查清它與新Hypervisor的兼容性。如果同樣的管理工具可以同時掌握兩個Hypervisor，就可以簡化管理進程了。

首先要查看新Hypervisor的兼容性表，必須得拿著表親手在環境中操作。在服務器級做好開始的測試之后，把測試范圍擴展到應用程序負載下的整個網絡和存儲兼容性。

需要Hypervisor的學習周期

測試Hypervisor能給IT部門機會來精通安裝和管理。兩個Hypervisor是相似的，但是有必要了解兩者的不同，才能消除困惑，更快掌握配置。那些對現有Hypervisor熟練的人員才是最容易精通軟件的，因為有實際操作經驗。

虛擬化早期，IT工作站安裝平臺在多種服務器在按需分配的基礎上，Hypervisor出現。現在，這個安裝進程更加正式，主要是因為已經有Hypervisor用上了，所以知道在哪里安裝第二個Hypervisor特別重要。

另一個因素是購買多種Hypervisor的公司通常足夠大，可以在新平臺配置上對形式和記錄的級別做出要求。在動態數據中心、私有和公有云上，通過高級別的主動權來執行。IDC企業虛擬化軟件調查經理Gary Chen說：“我們打算一步步執行審查步驟。”

什么時候適合開始？

什么時候從一個Hypervisor換到另一個？這可能會比較模糊。很少會有一個單獨的契機來觸發平臺轉換。合適的時機，是基于每個公司的唯一需要和情況。比如說：如果成本是初級的驅動力，那么轉換的時機可能僅僅管理者覺得合適了。

另外一種情況，契機可能來源于對新功能和服務的需要，這些是舊的Hypervisor提供不了的。新的Hypervisor也許可以提供服務級的協議需求。重要的是了解需求，這些需求可以促成第二個Hypervisor的到來，除此之外還得考慮時間或其他能把新Hypervisor引入的情形。

現在，Hypervisor已經發展成完善、穩定、可靠的軟件平臺，但是記住風險也會向新的Hypervisor遷移。最大的風險是，管理層迫使IT部門購買與原來平臺根本不一樣的Hypervisor。如果沒有足夠時間給管理者測試和掌握新的工具，或者如果直接放棄了舊Hypervisor的功能和特征，恐怕會有潛在的危機。

另外一個風險是孤島。比如某個公司的windows部分購買了一個Hypervisor，同時該公司的linux部分購買了另一個Hypervisor。這種分離Hypervisor的做法導致優化IT失敗。“現在的人期望私有云遷移，而使用單獨的資源池則與之相反。”