網絡是由一組設備組成的，它使用一個網絡管理系統以確保網絡的互聯性，而服務管理系統則為其增加了必要的“服務至網絡”意識。

這是一個偉大的模式——這一模式已歷經數十年而不衰——但是，由于虛擬化的出現，這一模式也開始變得過時了。

基于抽象和實例化，虛擬化也擁有它自身的管理模式。從希望部署的抽象服務或設備開始入手——可能是一個路由器或者一組路由器，也可能是一個基于一組路由器而開發的VPN服務。然后，就可以部署那些抽象的虛擬資源——計算能力、應用程序、數據存儲、虛擬連接等等，總之不管是什么吧——來實現它。即便是使用最簡單的描述，虛擬化的兩個事實也是越來越明顯的。首先一點，虛擬化應跳過服務和資源之間所有的低層次步驟，這就意味著通常在這個階段都要跳過所有那些看上去很美的管理程序。但是，如果虛擬網絡能夠讓云計算供應商通過直接操作虛擬設備而新建虛擬網絡服務，那么我們就有理由認為，虛擬設備并不知道關于他們整體服務屬性的任何信息，同樣它們也不知道它們之間的相互關系。迷失在這樣的管理環境中——也就是說將一個服務的各個部分與服務整體相聯系的能力，反之亦然。

因此，虛擬網絡管理要求供應商保留一個當服務創建時所建立關系的記錄，這樣一來，他們就能夠在以后必要的時候執行恢復管理環境的操作。這是非常重要的一個步驟，但卻幾乎總是在云計算網絡實施中被忽略，即通常只是開發服務，而軟件疊加與網絡設備并不存在任何特殊的鏈接。你可以使用這種方法開發出最佳服務，但它卻不是基于SLA、合同承諾的托管服務。

關于虛擬化的第二個發現就是，虛擬化創建的抽象資源是不同于它們的物理資源的。不必使用真實的物理設備開發虛擬交換機、路由器或防火墻;相反，你可以使用托管的、基于軟件的功能。這就使管理條線變得更為復雜了。例如，一個虛擬防火墻可能實際上是由若干托管進程以及一對網絡連接組成的。如果這個防火墻是一個物理設備，那么我們就可以發送一個用于讀取其管理信息庫(MIB)的SNMP命令，以便于檢查防火墻的狀態。但是，由于在我們的虛擬網絡服務中并不存在任何的物理防火墻組件，因此也就沒有可供讀取的MIB。即便每個組件都存在一個MIB，那MIB數據又是如何與虛擬防火墻功能相關聯的呢?我們還必須考慮組件之間網絡連接的狀態，因為在物理世界中連接性是根本不存在的。

除了上述兩個與虛擬網絡管理相關的戰略問題以外，還有一個很現實的問題。請設想以下的應用場景，在幾個不同的數據中心中有幾十臺物理服務器上運行著虛擬機，而數據中心之間只是通過主干光纖相連。現在，則可以想象一下，虛擬網絡服務是如何跨這個復雜平臺進行工作的。可能有一千個客戶和兩千個服務，以及十二臺服務器和一個跨數據中心的鏈接。為了發現任意一個服務的狀態，我們就必須檢查該服務所使用的資源的管理接口，從而導致成千上萬的服務向有限的資源發出這樣的服務請求。這就對網絡流量管理提出了極高的要求，單單為響應管理請求就會對資源造成了極大的應用負載壓力。

針對虛擬網絡服務而新興的管理模式

整個行業還沒有對虛擬管理給出全部的答案，但是我們已經在管理模式的定義和管理流量的控制方面取得了一些進展。這兩方面都隨著虛擬管理經驗的增長而將逐漸得到完善。

在管理模式方面，我們看到了兩個方向的發展趨勢。一個就是虛擬設備模式，其軟件定義或虛擬網絡功能包括了一個可代表它們所創建的虛擬設備的管理組件。你可以在無論哪個最方便的功能集合中進行管理組件開發，這一模式為創建基于方便管理而不是嚴格功能性的虛擬設備提供了潛力。

另一種模式就是服務驅動的運行模式，其功能集合都是為創建服務而定義的。例如，云計算供應商使用TM論壇的信息構架(SID)GB922 服務域模式就可以在他們定義服務組合的同時給出管理關系的定義。因此，一個泛化的過程能夠在任意一點提供一個管理試圖——從而完全地消除了每個服務的管理單元。

盡管市場上對目前的OSS/BSS系統是否不適合新的基于虛擬化的服務還存有疑慮，但是運營商們在很大程度上是繼續發展這些系統而不是取代它們也非常說明問題。統一數據模式和衍生服務運行模式的組合似乎與運營商們在虛擬服務管理上的未來目標是相當一致的，同時它還保留了與目前OSS/BSS軟件和實踐的聯系。事實上，運營商們希望這些組合能夠適合TM論壇和他們自己OSS/BSS系統的發展，從而為運營商迎來一個全新的、云計算驅動的、基于虛擬化的美好未來。