使用3gppmcim的虛擬機遷移的製作方法

2023-05-04 09:23:11 2

使用3gpp mcim的虛擬機遷移的製作方法
【專利摘要】一種遷移虛擬機的方法，包括：管理第一計算環境(如計算雲)的第一管理器發起當前在第一計算環境中的第一vM2ME(虛擬的機器對機器設備)上執行的虛擬機到第二計算環境(如另一計算雲)的遷移。一旦VM已經遷移，第一管理器就禁用第一vM2ME的執行。
【專利說明】使用3GPP MCIM的虛擬機遷移
【技術領域】
[0001]本發明涉及「虛擬機」在計算環境(諸如「計算雲」)上的執行，並且具體地涉及虛擬機從一個計算環境到另一計算環境的遷移或者在計算環境內的遷移。
【背景技術】
[0002]「虛擬機」(VM)是「正常主機作業系統內的完全隔離的訪客作業系統安裝」。VM是像物理機器一樣執行程序的機器(例如計算機)的軟體實現。目前，利用軟體仿真、硬體虛擬化或者(最常見地)這兩者一起來實施虛擬機。「硬體虛擬化」(或平臺虛擬化)指的是創建像具有作業系統的真實計算機一樣表現的虛擬機。在這些虛擬機上執行的軟體與底層硬體資源是分離的。
[0003]VM通常是由運營商為與運營商籤有合同(訂閱)的訂戶運行的。VM的作業系統和軟體是由訂戶決定的，並且VM鏡像(VM 「鏡像」是預配置的VM的作業系統二進位文件和元數據(例如，所需的RAM數量))是由訂戶創建的，因此從運營商的角度看是不可信的。
[0004]存在多種用於提供針對虛擬機的虛擬化平臺的解決方案。在這些系統中，多個虛擬機可以運行在一臺物理機器上。無限且動態分配的資源的抽象被稱為雲平臺或就稱為雲。
[0005]運營商正逐漸跨越服務成為比特管道提供方，而這並不是他們想要的位置；他們想要提供服務。已安裝的身份管理系統是能夠用於提供具有身份和受訪管理(IAM)形式的新服務以及針對各種服務的安全保障的一個事物。
[0006]現有解決方案存在眾多問題。運營商的一些關鍵資源是客戶群和針對客戶的身份管理以及安裝的基礎設施。業務是基於用於收費、服務質量(QoS)、安全、漫遊、互聯互通、月艮務級別協議(SLA)等的標準化3GPP機制的。對於雲技術而言，類似種類的標準幾近沒有。這使得運營商很難將其關鍵資源與雲平臺整合到一起。換言之，問題在於:運營商能夠如何使用雲計算從其現有的關鍵資源中受益。因此，也很難估計有多少運營商可以從雲計算模式受益，並且進入新的業務領域。
[0007]出於例如在尖峰時段期間負載均衡的原因和彈性，使用VM遷移。通常，VM被轉移(遷移)到具有更好的資源狀況的某個其他雲。VM也可以在雲內的不同主機之間遷移。
[0008]在VM運行在Xen管理程序(hypervisor)上的情況下，管理員可以跨LAN(區域網)在物理主機之間「實時遷移」Xen VM，而不喪失可用性。在該過程期間，LAN迭代地將VM的存儲器複製到目的地，而不停止其執行。該過程需要大約60?300ms的中斷，以在VM在其最終目的地處開始執行之前完成最終同步，從而提供無縫遷移的假象。類似的技術可用於將VM的運行暫停到磁碟並切換到另一 VM，在稍後的日期恢復第一 VM-參見如2011年10月 14 H 所下裁的 http: //en.wikipedia.0rg/wiki/Xen。
[0009]圖18示出了已知的「實時遷移」方法中的主要步驟。這是「預複製」遷移，其中在遷移VM之前，VM存儲器被複製到新位置。
[0010]最初，在步驟(a)中，在一個管理程序(管理程序B)上執行的VM的所有存儲器頁面被複製到另一管理程序(管理程序B)。該步驟將花費有限的時間，可以預料到在該時間期間VM的一些存儲器頁面將會被更新。在步驟(a)的複製期間更新的頁面被稱為「髒頁面」，以及在步驟(b)中，所有髒頁面(即，在步驟(a)的持續時間期間被更新的所有頁面)被複製到管理程序B。在步驟(b)期間更多的頁面會變髒，因此在步驟(C)中將根據需要多次重複將髒頁面複製到管理程序B的過程，直到髒頁面的數量變小。
[0011]一旦髒頁面的數量已經變得足夠小，就在步驟(d)中停止該VM，並且管理程序A運行所在的CPU的寄存器、設備狀態和當前存儲器髒頁面被複製到管理程序B。最後，在步驟(e)中，在管理程序B上恢復該VM。
[0012]還存在已知的「後複製」遷移方法，其中，在已經改變執行主機之後，複製VM存儲器。

【發明內容】

[0013]本發明的第一方面提供了一種遷移虛擬機的方法。管理第一計算環境的第一管理器發起當前在第一計算環境中的第一 VM2ME(虛擬的機器對機器設備)上執行的虛擬機到第二計算環境的遷移。一旦VM已經遷移，第一管理器就禁用第一 VM2ME的執行。
[0014]第二計算環境可以是由不同於第一管理器的第二管理器來管理的。例如，第一計算環境可以是由第一管理器管理的第一計算雲，而第二計算環境可以是由第二管理器管理的不同的第二計算雲一使得VM從一個計算雲遷移到另一計算雲。備選地，第一和第二計算環境可以都在同一計算雲中(並且因此具有彼此相同的管理器)，使得VM從計算雲中的一個主機遷移到相同計算雲中的另一主機。
[0015]在發起虛擬機的遷移之前:第一管理器可以發送針對在第二計算環境中建立用於執行VM的vM2ME的請求。
[0016]第一管理器可以在接收到對已經在第二計算環境中的虛擬管理域中供應了用於虛擬機的MCIM的確認之後發起對虛擬機的遷移。
[0017]在虛擬機遷移到第二計算環境之後，第一管理器可以指示第二管理器激活第二計算環境中的vM2ME。
[0018]第一管理器可以發起對第一計算環境中為虛擬機供應的虛擬的機器對機器設備的釋放。
[0019]第一管理器可以指示與第一計算環境關聯的運營商阻止第一計算環境中的與虛擬機關聯的MCIM。備選地，第一管理器可以指示與第一計算環境關聯的運營商丟棄第一計算環境中的與虛擬機關聯的MCM。
[0020]本發明的第二方面提供了一種遷移虛擬機的方法。所述方法包括:在管理計算環境的管理器上接收用於將當前在另一計算環境中執行的虛擬機遷移到所述計算環境的請求。所述管理器發起在所述計算環境中供應用於執行虛擬機的MCIM，然後指示在所述計算環境中激活虛擬機。
[0021]本發明的第一方面涉及由「舊」計算環境的管理器執行的方法，所述「舊」計算環境的管理器也即VM當前正在其上執行並且正要從其遷離的計算環境的管理器。與此相對，第二方面涉及由「新」計算環境的管理器執行的互補方法，所述「新」計算環境也即VM正被遷移到的計算環境的管理器。[0022]所述計算環境中的用於執行虛擬機的MCIM可以在所述計算環境的虛擬管理域中供應。
[0023]所述另一計算環境可以由不同於所述管理器的另一管理器來管理。
[0024]所述管理器可以向另一管理器通知供應用於虛擬機的MCM。
[0025]所述管理器可以在接收到來自另一管理器的指令之後，指示在所述計算環境中激活虛擬機。
[0026]所述管理器可以指示虛擬管理域激活虛擬機。
[0027]所述管理器可以向另一管理器通知在所述計算環境中激活虛擬機。
[0028]本發明的第三方面提供了一種遷移虛擬機的方法。所述方法包括:在歸屬運營商處決定用於與所述歸屬運營商關聯的並且當前在第一計算環境上執行的虛擬機的新的執行環境。所述歸屬運營商發起在不同於第一計算環境的第二計算環境上供應用於執行虛擬機的vM2ME的MCM(MCM-2)。當歸屬運營商接收到對供應了 MCM的確認時，歸屬運營商指示管理第一計算環境的第一管理器將虛擬機遷移到第二計算環境。
[0029]本發明的第一和第二方面涉及由「舊」計算環境的管理器和「新」計算環境的管理器執行的方法。第三方面涉及由既非「舊」計算環境的管理器也非「新」計算環境的管理器的運營商所執行的補充方法。
[0030]在接收到針對虛擬機的新的執行環境的請求時，虛擬機可以與歸屬運營商提供的用於在第一計算環境中執行虛擬機的另一 MCIM(MCM-1)相關聯。
[0031]在虛擬機已經被遷移到第二計算環境之後，歸屬運營商可以阻止所述歸屬運營商提供的用於在第一計算環境中執行虛擬機的所述另一 MCIM(MCM-1)。
[0032]第二計算環境可以由不同於第一管理器的第二管理器來管理。
[0033]歸屬運營商可以指示第二管理器在第二計算環境中激活虛擬機。
[0034]在第二計算環境中激活虛擬機之後，歸屬運營商可以指示第一管理器丟棄第一計算環境中為虛擬機供應的虛擬的機器對機器設備。
[0035]本發明的第四方面提供了一種配置用於遷移虛擬機的電信網絡實體。所述網絡實體包括:處理器和存儲程序指令的存儲器，所述程序指令在由所述處理器執行時，使得所述網絡實體發起當前在由所述網絡實體管理的第一計算環境中執行的虛擬機到第二計算環境的遷移。所述指令還使得所述網絡實體禁用第一計算環境中的虛擬機的執行。
[0036]所述指令還可以使得所述網絡實體在發起虛擬機的遷移之前發送針對在第二計算環境中建立用於執行VM的νΜ2ΜΕ的請求。
[0037]所述指令還可以使得所述網絡實體在接收到對已經在第二計算環境中的虛擬管理域中供應了用於虛擬機的MCIM的確認之後發起虛擬機的遷移。
[0038]所述指令還可以使得所述網絡實體在虛擬機遷移到第二計算環境之後指示第二管理器激活第二計算環境中的VM2ME。
[0039]所述指令還可以使得所述網絡實體發起對第一計算環境中為虛擬機供應的虛擬的機器對機器設備的釋放。
[0040]所述指令還可以使得所述網絡實體指示與第一計算環境關聯的運營商阻止第一計算環境中的與虛擬機關聯的MCIM。
[0041]所述指令還可以使得所述網絡實體指示與第一計算環境關聯的運營商丟棄第一計算環境中的與虛擬機關聯的MCIM。
[0042]本發明的第五方面提供了一種配置用於遷移虛擬機的電信網絡實體。所述網絡實體包括:處理器和存儲程序指令的存儲器，所述程序指令在由所述處理器執行時，使得所述網絡實體接收用於將當前在另一計算環境中執行的虛擬機遷移到由所述網絡實體管理的計算環境的請求。所述指令還使得所述網絡實體發起在由所述網絡實體管理的計算環境中供應用於執行虛擬機的MCIM，以及指示在由所述網絡實體管理的計算環境中激活虛擬機。
[0043]所述指令還可以使得所述網絡實體發起在所述計算環境的虛擬管理域中的雲中供應用於執行虛擬機的MCIM。
[0044]所述指令還可以使得所述網絡實體向另一管理器通知供應用於虛擬機的MCM。
[0045]所述指令還可以使得所述網絡實體在接收到來自另一管理器的指令之後，指示在所述計算環境中激活虛擬機。
[0046]所述指令還可以使得所述網絡實體指示虛擬管理域激活虛擬機。
[0047]所述另一計算環境可以由不同於所述網絡實體的另一管理器來管理，並且所述指令還可以使得所述網絡實體向所述另一管理器通知在雲中激活虛擬機。
[0048]本發明的第六方面提供了一種配置用於管理虛擬機的電信網絡實體。所述網絡實體包括:處理器和存儲程序指令的存儲器，所述程序指令在由所述處理器執行時，使得所述網絡實體決定用於當前在第一計算環境中執行的虛擬機的新的執行環境，所述虛擬機與所述網絡實體相關聯。所述指令還可以使得所述網絡實體發起在不同於第一計算環境的第二計算環境中供應用於執行虛擬機的VM2ME的MCM，以及當所述網絡實體接收到對供應了MCIM的確認時，指示管理第一計算環境的第一管理器將虛擬機遷移到第二計算環境。
[0049]在接收到針對虛擬機的新的執行環境的請求時，虛擬機可以與由歸屬運營商提供的另一 MCM(MCM-1)相關聯，以及所述指令還可以使得所述網絡實體在虛擬機已經被遷移到第二計算環境之後阻止所述另一 MCM(MCM-1)。
[0050]第二計算環境可以由不同於第一管理器的第二管理器管理，並且所述指令還可以使得所述網絡實體指示第二管理器在第二計算環境中激活虛擬機。
[0051]所述指令還可以使得所述網絡實體當在第二計算環境中激活虛擬機之後，指示第一管理器丟棄第一計算環境中為虛擬機供應的虛擬的機器對機器設備。
[0052]本發明的第七方面提供了一種包含指令的計算機可讀介質，所述指令在由處理器執行時，使得所述處理器執行所述第一、第二或第三方面的方法。
[0053]本發明的第八方面提供了一種電腦程式，其在由處理器執行時，使得所述處理器執行所述第一、第二或第三方面的方法。
[0054]在本發明的任意方面或實施例中，第一計算環境和/或第二計算環境可以是虛擬化的計算環境，但是本發明不限於此。
[0055]本申請的一個概念在於描述正在使用MCM/3GPP身份的VM如何才能在各雲之間(或在不同的虛擬化計算環境之間)遷移或者在同一雲中的各主機之間遷移。這允許實現VM的新型漫遊服務。取決於(但不限於)物理位置要求，有可能從一個雲系統遷移到另一雲系統。例如，針對受災地區的服務可被遷移到較近的雲系統，以便最小化成本，最大化帶寬(在災區，帶寬通常是非常稀缺的資源)。[0056]該解決方案建立在利用可下載訂戶模塊的基礎上，所述可下載訂戶模塊例如是如3GPPTR33.812(版本9.2.0，日期2011年6月22日)中定義的MCM，其用於向VM提供3GPP身份和憑證，所述3GPP身份和憑證可用於識別VM並且用於向VM提供安全性和QoS。本發明還提供對3GPP TR33.812中定義的遷移的修改，以允許支持VM遷移。
[0057]為了便於描述，在本發明的描述中使用的可下載訂戶模塊將被稱為「MCIM」。然而，應該理解:本申請中使用的術語「MCIM」旨在表示任何類型的可下載訂戶模塊，並且本發明並不限於在3GPP TR33.812中定義的特定的可下載訂戶模塊。
【專利附圖】

【附圖說明】
[0058]將通過示例並且參考附圖來描述本發明的優選實施例，在附圖中:
[0059]圖1是VM遷移的示意說明圖；
[0060]圖2是從一個選定的歸屬運營商(SHO)到另一 SHO的VM遷移的實施例的不意說明圖；
[0061]圖3是針對圖2中的遷移的信令圖；
[0062]圖4是從一個受訪運營商的雲到另一受訪運營商雲的VM遷移的實施例的不意說明圖；
[0063]圖5示出了針對恆定存在點(constant Point of Presense)的路由；
[0064]圖6示出了存在點的變化；
[0065]圖7是針對圖4的遷移的信令圖；
[0066]圖8是示出Xen管理程序的示意框圖；
[0067]圖9是用於重新供應VM2ME的一個過程的信令圖；
[0068]圖10(a)是可信環境的示意框圖；
[0069]圖10(b)是M2MEP的示意框圖；
[0070]圖10 (C)是MNO提供用於訂戶的VM的M2MEP的一個場景的示意框圖；
[0071]圖11是MNO提供用於訂戶的VM的m2MEP的另一場景的示意框圖；
[0072]圖12是MNO提供用於訂戶的VM的m2MEP的另一場景的示意框圖；
[0073]圖13是vM2ME的示意框圖；
[0074]圖14是示出根據本發明一個實施例的方法的示意流程框圖；
[0075]圖15是示出根據本發明另一實施例的方法的示意流程框圖；
[0076]圖16是示出根據本發明另一實施例的方法的示意流程框圖；
[0077]圖17是根據本發明實施例的節點的示意流程框圖；
[0078]圖18是一種已知的用於遷移VM的實時遷移方法的不意框圖。
【具體實施方式】
[0079]首先，將定義和/或解釋在本發明的描述中使用的各種術語。
[0080]「訂戶身份模塊」 (SIM卡)被用於識別使用行動裝置的訂戶，以及向行動網路運營商認證訂戶，使得網絡運營商可以授權訂戶使用當前與該SIM關聯的行動裝置，以便使用該行動裝置發送和接收呼叫/數據。(S頂識別訂戶，訂戶是與運營商籤了訂閱合同的個人或組織，並且與該SIM關聯的行動裝置的用戶可以不同於所述訂戶一然而為了簡單起見，將假定行動裝置的用戶也是訂戶)。通常，SIM包含識別所述訂戶的識別信息，並且還包含用於建立在與SM關聯的設備與網絡之間的通信且保證該通信的安全的信息(例如加密信息，所述加密信息使得SIM能夠加密從該行動裝置發送的語音或數據，以及解密接收到的語音或數據)。
[0081]目前，用於行動裝置的個人身份信息通常保存在行動裝置的SIM(訂戶身份模塊)卡上，或者保存在行動裝置的USM(通用訂戶身份模塊)卡上。SM卡、USM卡或nCC是具有持久性存儲器的微處理器晶片。在3G網絡中，SM或US頂可以是運行在通用集成電路卡(UICC)上的應用。
[0082]存儲在通用集成電路卡nCC(SM卡，或者運行在上的SM應用)上的3GPP(第三代合作夥伴計劃)憑證被用於識別3GPP設備和用於建立在設備與3GPP網絡之間的通信且保證該通信的安全。已安裝的用於3GPP訂戶管理的基礎設施以及用於它的標準化技術是3GPP運營商的關鍵資源。
[0083]M2M(機器對機器)設備是能夠經由有線系統或無線系統與其它設備通信的設備。M2M設備的例子包括電錶或煤氣表、交通攝像頭和自動售貨機。M2M設備具有SM，該SM用於識別設備並且用於建立去往/來自該設備的通信且保證該通信安全。
[0084]優選地，M2M設備包含可信環境(即TRE)以及通信模塊CM。CM是這樣的通信端點，其與運營商的3GPP網絡交互，並建立用於VM的必要隧道。在3GPP網絡與VM之間的業務是由MCM認證的(見下文)。虛擬化平臺、CM和TRE的組合被稱為M2MEP (機器對機器設備平臺)。
[0085]可信環境(TRE)使用可信平臺模塊(TPM)和安全的引導裝載程序來提供用於管理程序、管理域(例如，Xen管理程序的DomO)的可信運行時環境。TRE可以在任何時候由被授權對該TRE進行驗證的外部機構進行驗證。外部機構例如使用基於TPM的遠程證明來驗證用於管理程序和管理域的安全引導過程。TRE提供針對供應、存儲、執行和管理的硬體和軟體保護以及分隔。
[0086]原則上，M2ME的SM可被提供為傳統的SM卡。然而，因為可以在廣泛分散的位置提供大量的M2ME，所以例如在網絡運營商發生改變的情況下必須訪問每個M2ME是不方便的。因此，已經存在將SIM遠程下載到M2ME的提議。例如，3GPP TR33.812，「Feasibilitystudy on the security aspects of remote provisioning and change of subscription forMachine to Machine (M2M) equipment」,提出了對可下載USIM的研究的3GPP結果，也稱為MCIM(表示機器通信身份模塊)。針對機器對機器(M2M)的通信場景的該解決方案基本上用基於軟體的、可被下載到設備(例如下載到M2ME)的MCM(或USM)來替代WCC卡。MCM執行原本由常規SIM卡執行的功能，如認證訂戶，以及建立去往/來自設備的通信且保證該通信的安全，等等。
[0087]正如物理設備可以配備有SM —樣，虛擬機也可以配備有SM，具體地是MCM。MCIM和一個或多個VM的組合被稱為「vM2ME」 ( 「虛擬機器對機器設備」)。MCM與管理域中的虛擬接口相關聯。此外，該虛擬接口與VM相關聯。該關聯例如可以用由管理域的管理員和/或由MNO籤署的證書來表達。MCIM向網絡運營商識別和認證VM和/或訂戶，並且能夠實現在VM與網絡之間的通信。出於本申請的目的，MCM指示用於M2ME接入3GPP網絡的M2M安全數據和功能的聚集。[0088]M2MEP是運行vM2ME所需要的，並且MCM和相關的VM必須一起部署在M2MEP上。
[0089]在本申請中將使用下述術語等:
[0090]MCIM:-Μ(ΠΜ是3GPP中研究的新概念。如上面所解釋的，MCM是對設備(如Μ2ΜΕ)進行認證並且保護去往/來自設備的通信的建立和安全的訂戶身份模塊。與必須以物理方式插入到設備中的傳統SM卡相比，MCIM可被遠程下載到設備。目標是提供使得設備能夠從設備的實際歸屬運營商下載其網絡憑證，其中設備的擁有者已經與設備的實際歸屬運營商籤訂了服務協議。目前，共同商定的操作過程如下:
[0091]1.設備的擁有者輸入與行動網路運營商的服務協議，並註冊他/她的設備。
[0092]2.掌管行動裝置(g卩，向設備提供初級憑證)的發現和註冊功能(DRF)被告知設備的選定歸屬運營商(SHO)並且存儲該映射。
[0093]3.行動裝置開機，且它將掃描可用的行動網路以便嘗試連接到3GPP受訪網絡運營商(VNO)/初始連接功能(ICF)。M2ME(機器對機器設備)上存儲的初級憑證被用於連接到網絡，並且它們向DRP指出設備的當前歸屬網絡。
[0094]4.DRP將向M2ME通知註冊到它的SH0，並且將設備重定向到由該SHO操作的SHO/MCIM下載和供應功能(DPP)。
[0095]5.接著，行動裝置將連接到該SH0/DRF，並下載正確的憑證，使得設備能夠開始按設備的所有者與行動網路運營商之間的服務協議來使用SHO訂閱。
[0096]MCM的當前範圍 是類似於擁有者通常不具有物理接入而是需要遠程管理的類傳感器設備。
[0097]如上文提到的，本文使用的術語「MCIM」旨在包括任何可下載的訂戶身份模塊。
[0098]雲計算(CC)提供用於客戶端的無限量的聯網、計算和存儲資源的抽象。該抽象是通過對數據中心中的基礎設施、平臺和軟體的虛擬化來實現的。在基礎設施層面，虛擬化是利用所謂的管理程序來實現的。雲計算提供計算、軟體、數據訪問和存儲服務，它們不要求訂戶知道提供服務的系統的物理位置和配置。雲計算提供商經由網際網路來提供應用，這些應用可從網絡瀏覽器以及臺式計算機應用和移動應用來訪問，而業務軟體和數據被存儲在遠程位置的伺服器上。雲計算需要既針對連接到虛擬機(VM)的用戶也同樣針對VM本身的聯合身份管理。
[0099]在這些系統中，多個虛擬機可以運行在一臺物理機器上。對無限和動態分配的資源的抽象被稱為雲平臺或就稱為雲。虛擬機運行在隔離的運行時環境(在Xen術語中，稱SdomU)中，而對虛擬化平臺的控制機制運行在特定的運行時環境(稱為domO)中。
[0100]在本申請中使用術語「雲」的場合，該術語可以表示具有由國家標準與技術研究所針對計算雲定義的特性的任何計算環境，即下述特性:
[0101]?彈性；
[0102]?按需進行；
[0103]?廣泛的網絡訪問(即，用戶應該能夠通過任何技術(蜂窩、固定寬帶等)訪問雲;
[0104]?資源池；
[0105]?測量服務的能力(「雲」應該是能夠測量資源消耗，如磁碟空間、CPU/周期等，以便有可能進行收費)。[0106]應該注意，雲中並不要求「虛擬化」。
[0107]在基礎設施層面，虛擬化是通過虛擬機管理器(VMM)來實現的，該VMM也被稱為管理程序。(在本申請中將使用術語「管理程序」)。管理程序是允許多個作業系統(稱為訪客)並發運行在一個主機計算機上的多種硬體虛擬化技術之一。Xen是眾所周知的並且廣泛使用的管理程序。Xen系統具有如圖8中示意描繪的概念上分層的結構，其中Xen管理程序802作為駐留在硬體801上的最低的且有最高特權的層。在該層之上存在一個或多個訪客作業系統803、804，其中管理程序802跨多個物理CPU來調度該一個或多個訪客作業系統。在Xen術語中被稱為「域O」 (domO)的第一訪客作業系統803默認情況下在管理程序802引導時自動引導，並接收對所有物理硬體的特殊管理特權和直接受訪權限。系統管理員可以登錄到domO以便管理在Xen術語中被稱為「域U」 (domU)的任何另外的訪客作業系統804。圖8也示出了域O訪客作業系統803和兩個另外的訪客作業系統804，但是另外的訪客作業系統804的數目並不限於2個。
[0108]VM可以運行在domU域上(如圖10(c)中所示)。管理程序向運行在domU域上的VM隱藏了物理硬體，並且向VM呈現一組模擬的虛擬設備。
[0109]虛擬交換機(vSwitch)805是以軟體實現的，並且與管理程序802集成在一起。此夕卜，管理程序實現與每個domU訪客作業系統804的虛擬網絡接口卡(vNIC)806。( 「NIC」或「網絡接口卡」是將計算機連接到計算機網絡的計算機硬體組件；目前，大多數的計算機具有內置的網絡接口，並且這被稱為「PNIC」或「物理網絡接口卡」。「vNIC」或「虛擬網絡接口卡」模擬針對虛擬機的物理網絡接口卡，並且是運行在管理程序上。)
[0110]應該注意，術語「domO」和「domU」是專用於Xen管理程序的。然而，一般而言，管理程序將允許運行多個訪客作業系統，其中一個訪客作業系統在管理程序引導時自動引導並接收特殊管理權限。在管理程序引導時自動引導的訪客作業系統可被稱為「虛擬管理域」。
[0111]開放式VSwitch可以作為運行在管理程序內的軟交換機來工作，並且也已被實現在硬體(即交換機)中。用於交換矽的控制棧。它已經被移植到多種虛擬化平臺和交換晶片組上。
[0112]雲OS:- 「雲作業系統」或「雲OS」管理管理程序、域訪客(VM)，(虛擬)交換機和數據中心的其他資源。
[0113]本發明的方法可能會涉及下述各方中的一些或全部:
[0114]「擁有」 一個或多個VM的VM擁有者，其中VM擁有者具有與運營商的用於運行VM的訂閱(即，合同)。(VM擁有者並不擁有運行他/她的VM的計算環境)。VM擁有者也可被稱為「訂戶」，因為他們具有與運營商的訂閱。
[0115]為了方便起見，本發明的詳細描述將假設存在單一 VM，但這並不意味著本發明的應用排除了兩個或更多個VM的遷移。
[0116]「歸屬運營商其是VM擁有者已經與之籤訂合同的運行該擁有者的VM的運營商。
[0117]儘管「歸屬運營商」已與VM擁有者籤了合同，但是歸屬運營商並不一定運行擁有者的VM。歸屬運營商可以與另一運營商(稱為「受訪運營商」)籤訂合同，在該情況下受訪運營商運行該VM。在圖2的實施例中，VM可以由歸屬運營商運行或者由受訪運營商運行，但在圖7的實施例中，VM始終由受訪運營商運行。
[0118]原則上,運營商(不論是歸屬運營商,還是受訪運營商)自身可以操作運行擁有者的VM的計算環境。可選地，根據來自運營商的合同，運行擁有者的VM的計算環境可由另一實體(稱為「雲管理器來操作和管理。
[0119]VM擁有者的顧客可以訪問VM，例如在向VM擁有者付款後訪問VM。然而，這些顧客不參與本申請中描述的遷移過程。
[0120]在本申請中，「訂閱」是在訂戶和運營商之間的基於MCM的關聯(這裡，如上所述，「MCM」通常可以表示可下載的訂戶身份模塊)。
[0121]在本申請中，當描述遷移時，術語「舊」和「新」將分別被用於表示遷移前和遷移後。因此，例如，「舊」雲管理器是在遷移之前執行擁有者的VM的雲的管理器，「新」雲管理器是在遷移之後執行擁有者的VM的雲的管理器。
[0122]將參照從一個計算雲到另一計算雲的VM遷移或者在一個計算雲內的VM遷移來描述本發明。然而，參考在計算雲之間的或者在計算雲內部的遷移進行的對本發明的描述僅是用於示例，並且本發明不限於在計算雲內使用，而是可以應用到其他計算環境中，例如，應用在應用級進程遷移中或者應用在分布式編程中，在所述分布式編程中不同的應用模塊可在任意處理器/位置上執行。
[0123]本發明將參照Xen管理程序進行描述，諸如「domO」和「domU」之類的術語將被分別用於指代管理域和運行時環境。這僅是為了方便描述，並且本發明可以實現在其他管理程序上。
[0124]共同未決申請PCT/EP2011/......(Marks&Clerk案號PX210336W0)描述了具有MCM
管理的VM的系統的整體操作，該申請在下文中稱為「P34573」，以引用的方式將其全文併入本文中。
[0125]P34573中提出的解決方案將私有(電信)雲中的虛擬機與3GPP行動網路訂閱加以綁定，並且允許現有的雲作業系統與3GPP系統之間的互操作。共同未決申請PCT/EP2011/(Marks&Clerk案號PX210379W0)描述了在P34573中提出的系統中執行MCM的初始供應的備選方式，並且該文檔中提出的遷移方案也利用了這些供應方案，該申請在下文中稱為「P34691」，以引用的方式將其全文併入本文中。
[0126]本發明解決了如何實現在一個計算環境與另一計算環境之間或者在同一計算環境中的不同主機之間的VM遷移，以支持在P34573中描述的系統。如上文提到的，計算環境可以是虛擬化計算環境，但是本發明並不限於此。本發明將具體參考雲之間的VM遷移或者同一雲中的主機之間的VM遷移來描述,但是這僅是作為不例，而不表不本發明局限於在雲之間的VM遷移或者在同一雲中的主機之間的VM遷移。在本發明中，公開了用於以適合於行動網路運營商的電信雲的方式結合/使用3GPP憑證/MCIM概念(即虛擬的機器對機器設備或「vM2ME」 )來遷移VM的遷移機制。
[0127]本申請中的基本概念在於:描述正在使用MCM/3GPP身份的VM如何才能在雲之間遷移或者在同一雲中的主機之間遷移。取決於(但不限於)物理位置要求，有可能從一個雲系統遷移到另一雲系統。例如，針對受災地區的服務可被遷移到較近的雲系統，以便最小化成本，最大化帶寬(在災區，帶寬通常是非常稀缺的資源)。
[0128]該解決方案包括利用如3GPP TR33.812中定義的MCM來向VM提供3GPP身份和憑證，所述3GPP身份和憑證可被用於識別VM並且用於向VM提供安全和QoS。可以修改如3GPP TR33.812中定義的遷移以便也支持VM遷移。[0129]圖1是示出了一個或多個VMlOl在雲作業系統102(例如，在數據中心中)上執行的示意圖。雲0S102通過3GPP網絡103連接到網際網路104。圖1示出了示例情景，其中行動網路運營商(MNO) 105既是3GPP網絡103的運營商也是數據中心或雲0S102的運營商。訂戶106是VMlOl的擁有者(此處，示出了兩個VM，但可以存在任意數目的VM)，其向通過網際網路104訪問VMlOl的顧客(未示出)提供服務。(所述顧客例如可以是訂戶的顧客、訂戶自己(如果訂戶是自然人)、訂戶的僱員或者與訂戶關聯的個人或組織(如果訂戶是公司)，等等)。)VM擁有者/訂戶106具有與MN0105的訂閱。每個VMlOl至少與一個MCM相關聯，而VMlOl及其關聯MCM的組合形成vM2ME。
[0130]圖10(a)?圖10(c)使用圖8中介紹的分層概念示出了在vM2ME的構建期間的概念階段。注意:為了清楚起見，圖8中示出的一些單元，如vSwitch805和V NIC806，在圖10(a)?圖10(c)中已被省略，但是其實際上將是存在的。如圖10(a)中所示，通過安裝可信平臺模塊(TPM) 1008連同安全的引導裝載程序(未示出)，可信環境(TRE) 1009被定義為圍繞dom01003和駐留在硬體1001上的管理程序1002。(安全的引導裝載程序在引導期間執行一系列動作以確保安全的初始狀態。)在3GPP TR33.812 「Feasibolity study on thesecurity aspects of remote provisioning and change of subscript ion for Machine toMachine (M2M) equipment」(下文中簡稱為「3GPP TR33.812」)中討論了用於機器對機器設備(M2ME)的可信環境(TRE)。
[0131]TRE1009由外部機構進行驗證。TRE驗證例如可以通過使用平臺驗證機構(PVA)提供的遠程認證機制來完成-該PVA可以驗證該雲OS正在如3GPP TR33.812中討論的TRE上運行MCM，其還包括針對由管理程序實現的運行時環境隔離的要求。TPM還可被用於向PVA提供對vM2ME的狀態的驗證。
[0132]圖10(b)示出了 M2MEP1010，其包括圖10(a)的TRE1009的所有元素以及安裝用於在dom01003中執行的通信模塊(CM) 1006。
[0133]圖10(c)示出了 VM2ME1000的示例，其包括圖10(b)的M2MEP1010的所有元素以及安裝用於在domO訪客作業系統1003中的CM(通信模塊)1006 一起執行的MCM1005和在domU訪客作業系統1004中執行的關聯的VM1007。圖10(c)還示出了 vM2ME1000的概念結構如何與圖1的訂閱中涉及的各方相關聯——所述各方即MNO(對應於圖1的MN0105)以及擁有VM的實體(對應於圖1的訂戶106)。如圖所示，MNO操作虛擬化平臺(VM2ME1000)，而訂戶是MCM1005和關聯的VM1007的擁有者。
[0134]如所描述的，TPM1008被提供在硬體1001中。在圖10(c)中，MCM是vM2ME的一部分，vM2ME自身構建在圖10(a)的TRE1009上。TPM1008用於執行對管理程序1002和訪客管理域(dom0) 1003的安全引導，並且用於存儲敏感信息，如MCM。
[0135]注意:圖10(c)僅示出了一個VM1004，然而在訂戶擁有的VM2ME中可以存在不止一個VM以及關聯的MCM1005和CM1006。
[0136]在下文中，描述MCIM+VM的遷移的兩種備選方案。第一解決方案利用來自當前的受訪運營商的MCIM，而第二備選方案始終利用來自歸屬運營商的MCIM，即VM始終具有來自同一運營商的MCIM。
[0137]首先，將給出對MCM管理的VM的背景概述。
[0138]對於每個VM，下載MCM(儘管不止一個VM可以與MCM相關聯)，並且將其與CM(通信模塊)相關聯。對這些的存儲、處理和運行可以存在變化；在P34573中介紹了四種不同的場景。簡單總結一下，在P34573中介紹的4種場景如下:
[0139]I) MCIM 和 CM 位於 domO 中(圖 10 (C))；
[0140]2) MCM和CM位於運營商的虛擬機中，該虛擬機連接到訂戶的虛擬機(圖11);
[0141]3)MCM和CM位於正在運行訂戶的服務的同一虛擬機中(圖12);
[0142]4) MCM和CM位於物理接口網絡卡上(圖13)。
[0143]圖10(c)已經在上文進行了描述。
[0144]圖11示出了使用如前所述的分層概念的VM2ME1100。在這種情況下，VMM或管理程序1102駐留在硬體1101上，並且存在TRE，該TRE可選地基於TPMl 108。管理程序1102支持虛擬化平臺的DomOl 103和DomU域1104a、1104b。圖11示出了安裝用於與domU域1104a中的MNO-VMl 107中的CMl 106 一起使用的MCMl 105，並且還示出了另一 domU域1104b中的關聯的訂戶的VM1109。VM2ME1100運行訂戶的(不可信的)VMl 109。
[0145]圖11還示意性地示出了圖11的VM2ME1100的概念結構如何與涉及的各方相關聯。在該實施例中，雲OS管理員1110操作虛擬化平臺(VM2ME1100)，以及MNO擁有運行在雲中的MN0-VM1107，而訂戶是MCM1105和關聯的VM1109的擁有者。雲OS管理員1110可以是第三方公共雲提供商公司，或者可以是在具有第三方雲提供商的布置下操作平臺的ΜΝ0。
[0146]注意:在圖1 1的場景中，訂戶創建其自己的VM鏡像，該VM鏡像從MNO的角度看是不可信的，並且因此不能包含訂戶的MCM1105。因此，MCMl 105必須在MNO信任的單獨VMl 107中存儲/執行。為了綁定訂戶的VM1109與可信MNO-VMl 107，MNO必須部署這兩個VM。這允許創建VM之間的有效關聯。換言之，MNO代表訂戶向公共雲請求用於這兩個VM的資源。
[0147]在圖12所示的場景中，不存在訂戶的VM，而是代之以MNO的VM作為用於其顧客的經認證的服務(進程)的平臺來工作。(「經認證的」服務是被證明是可信的並且將如預期那樣執行的服務-其也被稱為「軟體保證」。)ΜΝ0的經認證的VM是由MNO創建的服務平臺。VM可以容宿一個或多個MCM。服務與MCM之間的綁定發生在VM的作業系統(OS)中。
[0148]圖12示出了使用如前所述的分層概念的VM2ME1200。在該情況下，第三方雲平臺的VMM或管理程序1202駐留在硬體1201上，並且存在TRE，該TRE可選地基於TPM1208。管理程序1202支持虛擬化平臺的Dom01203，以及MNO的VM1207 (在DomU1204中)。MNO的VM1207包括經認證的服務1208、網絡接口控制器1209、和作業系統(OS) 1210，以及一個或多個CM1206和關聯的MCM1205。(網絡接口控制器(也稱為「網絡接口卡」、「網絡適配器」、「LAN適配器」以及類似術語)是將計算機連接到計算機網絡的計算機硬體組件。)
[0149]圖12還示意性地示出了 VM2ME1200的概念結構如何與涉及的各方相關聯。在該情況下，第三方雲OS管理員1211操作虛擬化平臺(VM2ME1200)，以及MNO擁有MN0-VM1207，而訂戶是MCM1205的擁有者，並且訂閱了 MN0-VM1207提供的經認證的服務。因此，MNO充當在第三方的雲中運行的服務的選定歸屬運營商(SHO)。
[0150]在圖13所示的場景下，VM2ME1300包括pNIC1307(並且因此也包括TRE)、硬體上1301上的管理程序1302以及Dom01303，在所述Dom01303中安裝了配置管理器1308。VM1309執行在管理程序1302支持的DomU域1304中。在圖13中，示出了單一執行環境(虛擬功能—)1310，但是在？[(:1307中可以存在多個這種執行環境。在VF1310中包括CM1306和與VM1309關聯的MCM1305。
[0151]在圖10(c)到圖13的場景中，MCM+CM—起構成了 3GPP通信端點，並充當VM的數據機。用於將MCM+CM連接到3GPP網絡的接入可以是如圖1所示的3GPP接入，或者非3GPP接入，其中非3GPP接入是更有可能的場景。非3GPP接入可以要麼是可信的非3GPP接入，要麼是不可信的非3GPP接入。通過這些非3GPP接入的通信就像3GPP規範(如TS23.401，TS23.402)中描述地那樣工作。
[0152]如果期望VM在遷移時保持相同的IP位址的話，MCIM+CM除了能夠充當數據機之外，還能夠執行NAT (網絡地址轉換)功能。備選地，在MCM+CM與VM之間的通信也可以是純L2 (0SI的層2)通信，並且由MCM+CM來處理IP。
[0153]利用所提出的解決方案，在VM與如網際網路中的對等體(peer)之間的所有業務將經由使用的MCM所屬的3GPP運營商的網絡來路由。這在VM位於除了 3GPP運營商網絡之外的某個其他網絡中的情況下有可能會導致非優化的路由。在該情況下，有可能利用當地突破(breakout)來獲得從VM到網際網路的直接接入。
[0154]虛擬化環境中的管理程序負責VM的不同資源是彼此隔離的。MCM與VM的隔離取決於MCM+CM的運行方式和位置(如在圖10(c)到圖13的場景中描述的那樣)。
[0155]所提出的解決方案也可以通過用物理替代容宿VM的主機中的MCM來實現。然而，這種備選方案存在例如與移動性有關的限制。
[0156]圖2示出了本發明的一個實施例，其中，具有來自受訪運營商的MCM的VM201從一個SH0205a遷移到另一 SH0205b。每個SH0205a、205b操作各自的雲0S202a、202b，其中，雲0S202a、202b通過各自的接入網絡203a、203b連接到網際網路204，接入網絡203a、203b可以是如圖2所示的3GPP網絡，或者可以是非3GPP網絡。在遷移之前，VM201最初綁定到MCIM (MCIMl)，而在遷移之後其被綁定到新SHO處的新Μ(ΠΜ(Μ(ΠΜ2)。假定:在開始時VM位於其歸屬運營商(即「舊SH0」205a是歸屬運營商)的雲中，並且VM被遷移到受訪運營商網絡(新SHO2O5W的雲中。
[0157]本實施例的範圍在於描述虛擬機如何利用受訪運營商的MCM(參見3GPPTR33.812)實現在運營商的數據中心(的內部或者)之間遷移。該解決方案基於P34573，P34573描述了虛擬M2ME與雲作業系統(OS)和3GPP網絡的集成中的基本部分。
[0158]每個虛擬機與3GPP訂閱或者多個訂閱相關聯(即使接入網是非3GPP接入網)。這允許實現在運營商的數據中心之間的VM遷移，並且實現在具有3GPP基礎設施的運營商之間收費以及安全性。
[0159]圖3示出了遷移場景。概括而言，如上文所述，VM和MCM形成VM2ME。從本質上講，在遷移之前，存在由VM和第一 MCM形成的第一(原始的)vM2ME。MCM。在遷移過程中，該MCIM(屬於第一運營商)被禁用、阻止並且可選地被最終銷毀。在遷移期間，(從新網絡)供應新MCM，然後遷移VM，從而形成新VM2ME (舊VM+新MCM)。
[0160] 在當前的服務SHO的雲管理器(也即圖2中的雲202a，或者「舊的雲管理器」)想要移動VM到另一雲時，其發信號通知目標雲(即圖2中的雲202b)，並且向其請求用於新vM2ME的資源(消息I)。該請求包含VM和3GPP通信模塊(CM)的要求(例如，VM所需要的存儲器數量)。在遷移之後，新vM2ME將與新MCM —起(圖2的MCM2)形成遷移後的VM。在收到消息I後，新的雲管理器(例如，圖2中的雲202b的管理器)分配新雲中的用於新vM2ME(在圖3中未示出)的資源。
[0161]接下來發生新MCM的遠程供應。下面將參考圖9，步驟2?12，更全面地描述用於此的過程的示例，但是概括而言，新的雲管理器或者具有可用於新VM2ME的初級MCIM憑證的池，或者其與新SHO交互以針對每個vM2ME來接收這些憑證。
[0162]一旦已經向新domO中的vM2ME供應新MCM，向舊的雲管理器發回信號通知該操作的結果(消息2)。
[0163]如果消息2表明已經成功供應新MCM，則舊的雲管理器開始將VM遷移到新位置。VM遷移過程通過作為XEN平臺(或其他類似平臺)的標準部分的基於管理程序的機制來實現。
[0164]在VM已經遷移到新位置之後，舊的雲管理器發信號通知新的雲管理器激活vM2ME (消息3a)，並且進而新的雲管理器發信號通知新雲的domO激活vM2ME (消息4a)。新的雲管理器通過將MCM設置為「激活的」來激活VM2ME，並向舊的雲管理器返回狀態消息(消息5a和6a)。
[0165]與消息3a並行的，舊的管理器發信號通知舊雲的domO:應該禁用vM2ME(消息3b)。這也發信號通知:CM應該拆除到3GPP網絡的連接(類似於行動電話的關機)，或者備選地向3G網絡通知即將發生切換(遷移)。(CM採取的動作取決於在舊雲和新雲中是否將使用相同的MCM-如果在兩個雲中將使用相同的MCIM，則應該存在切換。然而，如下文解釋的，在不同的雲中使用相同的MCIM憑證(甚至會話憑證)不是好的解決方案，因為其具有較弱的安全性。)
[0166]舊domO禁用舊雲中的VM2ME，並向舊的雲管理器發送確認(消息4b)。
[0167]舊的雲管理器還發信號通知舊SHO:與VM關聯的舊MCM應該被移動到受阻狀態(消息5b)。舊SHO將舊MCM設置為「受阻」狀態，然後發送對此的確認給舊的雲管理器(消息6b)(並且有可能會向關聯的DPF和DRF報告該變化)。特徵5b ( 「阻止MCM」)通知3G運營商不允許該MCM再次上線，直至另行通知為止。實際上，CM不能就決定「打開」VM2ME。
[0168]如果遷移失敗，則舊的雲管理器將很可能不阻止舊MCM，並且啟用舊VM2ME使得VM可以返回到在舊雲中運行(未示出)。
[0169]從新的雲管理器發送的消息6a還可以包括用於新M CM的標識信息。舊的雲管理器可以使用該信息來維持保留在舊雲中的受阻MCIM與新雲中的VM2ME之間的關聯。
[0170]如果消息6a示出對VM2ME的激活已經成功，則舊的雲管理器發信號通知舊domO丟棄在舊雲中的與VM關聯的VM2ME(消息7)。在收到該消息時，舊domO丟棄舊vM2ME，並發送確認給舊的雲管理器(消息8)。
[0171]在VM已從「歸屬」雲202a遷移到「受訪」雲202b之後的某個時間，可能需要將VM遷移回歸屬雲202a。當/如果VM被遷移回歸屬雲202a，發生與圖3所示的類似的事件序列-但是，針對該第二遷移的圖3中的「舊的雲管理器」是受訪雲202b的管理器，而針對該第二遷移的圖3中的「新的雲管理器」是歸屬雲202a的管理器。
[0172]在從歸屬雲202a到受訪雲202b的第一遷移與從受訪雲202b回到歸屬雲202a的第二遷移之間的主要差異在於:當針對遷移的請求(圖3中的消息I)到達歸屬雲202a的管理器時，歸屬雲202a的管理器可以識別出要遷移的VM2ME是其自身的VM之一(該VM在第一遷移之前曾在舊雲202a上執行)，並且已經存在分配給該VM的、現在處於受阻狀態的MCM。於是，第二遷移中所需的遠程供應僅是重新建立vM2ME以及使得現有MCM返回到活動狀態(或者，如果在第一遷移之後已經完全移除MCM，則可能重新供應MCM)。在此之後，第二遷移如圖3中那樣繼續進行。在VM已經遷移回原始雲之後，受訪雲202a中的MCM將被刪除。
[0173]當然，也有可能是下述情況:當VM在雲之間移動時，歸屬雲202a中的用於VM的舊MCM始終被消滅。在這種情況下，舊MCM從不會被設置為受阻狀態，而是被丟棄。在這種變型中，圖3中的步驟5b是「移除MCM」，而不是「阻止MCM」。
[0174]如所指出的，圖3中所示的新MCM的遠程供應可以如圖9中的階段2~12中所示那樣執行。(在被關注的P34691中更全面地描述了圖9的遠程供應。)在圖3的過程中不要求圖9中的階段0，並且圖3的階段I替代了圖9的階段I。
[0175]圖9中的階段2到12:
[0176]階段2:SH0 ( 即，圖3中的「新」 SH0)將用於VM的初級憑證(如初級MCIM)與建立VM2ME的請求一起傳送給雲管理。雲管理器通常將是第三方雲管理器，也即雲管理器不是運營商，而是向運營商提供雲基礎設施的第三方。
[0177]階段3:新的雲管理器向domO請求用於新VM的資源，並且還向DomO提供初級MCM。(請求用於新VM的資源還隱含地創建針對MCM的CM新實例。)
[0178]階段4 =D omO預留用於新vM2ME的資源，向新雲的TPM安裝初級憑證，並且安裝與新的初級MCIM關聯的CM軟體模塊的新實例。然後，它向雲管理器返回分配狀態。
[0179]階段5:為所考察的VM分配的CM開始自舉過程(類似於3GPP TR33.812中描述的過程)，並且連接到DRF，DRF將向DPF轉發請求(基於在該流程的開始時執行的或者現有的註冊-註冊可以是現有的註冊，即其執行與該遷移無關，而是始終存在DRF中的註冊信息和DPF中的M(HM)。
[0180]階段6:在DPF將允許MCM供應之前，其將檢查M2MEP的TRE是否處於有效狀態。DPF向選定歸屬運營商(SHO)給出PCID和TRE信息。
[0181]階段7:歸屬運營商要求PVA驗證M2MEP的TRE。
[0182]階段8 =PVA驗證M2MEP的TRE並返回結果。
[0183]階段9:如果TRE被正確驗證，SHO現在可以供應訂戶MCM。SHO在DPF中安裝訂戶 MCM。
[0184]階段10:R0/DPF向階段4中建立的並且在DomO中運行的通信模塊(CM)的新實例發送訂戶MCM。
[0185]階段11:當在CM中已經安裝訂戶MCM之後，domO向DPF發信號通知安裝狀態。
[0186]階段12:具有新供應的MCM的CM執行網絡附著(如3GPP附著過程)。一旦成功執行，則它觸發下一條消息。
[0187]在階段8中，PVA可以使用「可信第三方」(TTP)來驗證TRE，其中TTP另外稱為「秘密保證機構」。存在一種已知的認證過程，在該認證過程中稱為「挑戰者」的那方向「驗證者」發送認證請求。該驗證者生成公鑰/私鑰對(稱為認證身份密鑰(AIK))，並向驗證者和挑戰者都信任的TTP發送公共部分。TTP生成AIK證書，在證書上簽名，並將籤名證書發送給驗證者。該驗證者將接收到的AIK證書發送給挑戰者，而挑戰者利用TTP公鑰驗證AIK證書(並且還可以執行其他驗證步驟)。在階段8中，PVA可以充當該類型的過程中的「挑戰者」，並且驗證者與可信執行環境集成在一起。
[0188]圖2的實施例可被備選地用於在同一雲內主機之間遷移VM。在這種情況下，圖3示出的新的雲管理器和舊的雲管理器是相同的實體，並且消息l、2、3a和6a被省略。VM從一臺主機遷移到同一雲中的另一主機，而不是在不同雲之間遷移。
[0189]在圖2的實施例中，現有的3GPP基礎架構並不需要修改。在任何時候，當時的雲運營商提供針對VM的網際網路連接-使得在遷移之前歸屬雲運營商提供針對VM的網際網路連接，因為歸屬雲運營商是在遷移之前的當前運營商，並且在遷移之後受訪雲運營商提供針對VM的網際網路連接，因為受訪雲運營商是遷移之後的當前雲運營商。這樣做的優點在於:一旦VM從當前雲提供商獲取網絡配置(IP位址)，發送給VM的或從VM發送的分組不經由另一運營商的3GPP網絡進行路由。其缺點在於:當遷移時，VM的網絡配置(IP位址)將發生變化，以及VM必須意識到該網絡配置(IP位址)變化；而且，連接到VM的訪客端在遷移時丟失活動連接。下述情況是可能的:維護針對訂戶VM的DNS表項的運營商根據VM遷移來更新DNS表項。
[0190]3GPP TR33.812描述了 MCM的多個生命周期狀態，並且規定MCM應該能夠存在於下述生命周期狀態中的任一狀態中:
[0191]「已安裝」:MCM的實例已經創建，並且在Μ2ΜΕ的註冊表中具有表項；
[0192]「激活」:MCM的實例被授權用於操作用途。
[0193]「選定」:該 狀態標誌著與MCIM的會話的開始。只有激活的MCIM可被選定。當會話結束時，MCIM回到激活狀態。
[0194]「受阻」:MCM的實例已被暫時去激活，並且不能使用。其示例是當專用PIN的狀態變為「受阻」時。對MCIM的解封使其恢復到激活狀態。
[0195]「退休」:永久不可用、但仍在Μ2ΜΕ中實例化的MCM實例。其示例是下述情況:憑證被永久刪除，但MCM的被其他應用使用的一些可執行組件仍然存活。
[0196]「已刪除」:MCM被永久地從Μ2ΜΕ的存儲器中刪除。刪除可被應用到處於上述生命周期狀態中的除選定狀態之外的任一狀態下的MCIM。
[0197]這些生命周期狀態在電信運營商的雲中也是有效的。當如圖2所示的VM暫時從其歸屬SHO雲(其安裝所在的雲)遷移到另一 SHO雲時，需要一些澄清。在這種情況下，歸屬SHO的雲中的MCIM可以進入激活狀態或受阻狀態中的任一者。其中，「受阻」是優選的狀態，因為這表明歸屬SHO的雲中的MCM不應該被使用。當VM被遷移回歸屬SHO雲時，MCM應該再次進入「激活」狀態(然後進入「選定」狀態)。
[0198]儘管VM暫時位於受訪雲中，其MCM在活動時將處於「激活」狀態或者「選定」狀態。受訪雲中的MCM不是與歸屬SHO中的MCM相同的MCM，而是僅在臨時受訪的雲中使用的新MCM。受訪雲中的MCM可以通過利用與歸屬SHO的雲中的PCID相比而言不同的PCID來使用常規供應方法來供應。從臨時受訪的雲的角度來看，除了將暫停的VM鏡像從歸屬SHO的雲傳送到這個雲的遷移過程之外，VM僅是另一 VM。
[0199]通過改變MCM(SM)而不是將新的雲提供商視為受訪運營商實現的將VM鏡像從一個運營商「漫遊」到另一運營商的管理方面落到參與遷移的雲提供商上，並且由服務級別協議(SLA)來負責。這些管理方面可以至少部分地通過例如下述方式來解決:利用運營商之間的關於在VM遷移情況下的收費的特殊SLA，以及使用本地突破以便不一定經由歸屬SHO網絡來路由所有業務。
[0200]應當注意:如果圖2的方法被用於在同一雲的不同主機之間遷移VM，則原則上在遷移之後VM重用相同的MCM憑證是有可能的。如果VM在不同的運營商之間遷移並且新運營商要重用舊運營商的網絡中曾使用的相同MCIM憑證，則有可能存在安全性問題，因此如上所述，在向新運營商遷移時提供新MCIM是優選的。然而，在運營商沒有發生改變的情況下，安全性對於遷移而言不怎麼成問題。
[0201]雲場景中的MCM的內容與任何其他MCM場景並無不同。
[0202]在圖2的實施例中，在遷移時受訪雲向VM給予新MCM。在備選實施例中，如圖4所示，VM始終具有來自同一運營商的MCIM，即使在遷移之後也是如此。這在VM在雲之間遷移時可以提供無縫的連接性，允許在不同數據中心之內和之間的VM遷移，並且使得有可能實現針對使用3GPP基礎設施的VM業務的收費和安全性。
[0203]該備選實施例描述了虛擬機如何能夠在不同的第三方/運營商數據中心之內(即，從主機到另一主機)或者在之間遷移，同時依然使用來自優選SHO的MCIM(3GPPTR33.812)。該解決方案基於在已經關注的P34573中描述的方法，具體地關注其中的對虛擬M2ME與雲作業系統(OS)和3GPP網絡的集成的描述。
[0204]圖4示出了操作諸如3GPP網絡402之類的提供到網際網路403的連接的接入網的SH0401。SH0401可以在與訂戶的合同下操作VM404，並且向VM404供應MCM，但是與圖2的情況的不同在於:VM不(或不需要)在SH0401操作的雲上執行。作為替代，SH0401與其他運營商405A、405B籤有供應計算雲資源的合同(圖4中示出了操作各自的雲406A、406B的兩個運營商405A、405B，但是本發明不限於此)。運營商405A、405B的雲406A、406B通過合適的接入網(如3GPP網絡407A、407B)連接到SH0。
[0205]圖4示出了這樣的情形:VM當前運行在運營商A(405A)的雲406A上，並且希望將VM遷移到在運營商B(405B)的雲406B上運行-也即，VM要從一個受訪運營商遷移到另一受訪運營商。本實施例令VM即使在遷移時也維持相同的網絡配置(包括IP位址)，其中折中考慮了在網際網路的主機和VM之間的三角路由。
[0206]下面的討論將集中於在不同於SHO的雲提供商之間遷移VM的場景。本文檔中介紹的遷移場景被示出在圖4?7中。
[0207]在圖4的實施例中，VM經由3GPP網絡407A、407B從一個受訪運營商的雲遷移(「漫遊」)到另一受訪運營商的雲。在圖4中，VM最初與第一 MCM (MCM-1)綁定在一起，而在遷移之後與另一 MCM(MCM-2)綁定在一起。MCM-1和MCM-2都是由SH0401供應的。在VM的遷移之前和之後，去往/來自VM的業務都是經由SHO的3GPP網絡路由的。
[0208]換言之，在圖4的實施例中，始終是相同的SHO向VM2ME提供MCM，即使其被遷移到另一運營商的雲。這允許實現在運營商之間的「傳統」漫遊協議。除非針對受訪3GPP網絡中的VM使用到網際網路的本地突破，否則去往/來自VM的所有業務都經由歸屬運營商的網絡進行路由。(在3GPP運營商之間可以協定用於這種VM遷移的特定SLA，以便處理數據漫遊。)
[0209]VM將始終從SHO的網絡獲得IP位址。通過適當的配置(例如，為訂閱提供永久IP位址，並且利用各種MCMs與訂戶之間的映射信息)，有可能讓VM始終具有相同的網絡配置。這將意味著不需要任何DNS更新以便保持服務是可獲得的且是活動的；即，VM將始終在網絡中具有相同的存在點(POP)。這被示於圖5中。因為SHO能夠將從客戶端到VM的業務(反之亦然)路由到當前正在執行VM的雲運營商，所以無論當前哪個雲運營商在執行VM，客戶端都可以經由SHO通過網際網路訪問VM。無論當前哪個雲運營商在執行VM，VM的PoP始終在SHO中。
[0210]與此相反，在如上所述的遷移中，圖2的實施例可能存在路由問題。這示於圖6中，圖6示出了 VM的POP是當前執行VM的雲運營商。因此，當VM從一個雲運營商遷移到另一雲運營商時VM的PoP發生改變。
[0211]圖7示出了實現圖4的實施例所需的信令的示例。這在很大程度上建立在圖9所示的自舉機制上。
[0212]階段1:VM當前正在一個雲上執行，例如圖4的雲406A。SHO決定它想將VM移動到新的執行環境(例如另一雲)中，並且決定新的執行環境的身份。該決定可以是SHO接收請求的結果，所述請求例如是來自訂戶的、針對VM的新的執行環境的請求，如果如此，該請求可以包含對請求哪個目標雲(例如圖4中的雲406B)的指示。(該SHO可以具有多個雲運營商，其中該SHO與這些雲運營商籤有用於遷移VM的SLA。)備選地，SHO可以接收僅要求VM的新的執行環境而沒有指定任何特定目標雲的請求，在這種情況下SHO可以從可用於VM的備選中選擇新的執行環境。作為另一備選方案，SHO可以在沒有收到請求的情況下，甚至可能在訂戶不知道的情況下，決定VM的新的執行環境。
[0213]接下來，SHO發信號通知目標雲(其是圖4中的雲406B)，並且向目標雲請求用於新vM2ME的資源。該請求包含對VM的要求(例如，VM所需的存儲器數量)以及對3GPP通信模塊(CM)的要求。 [0214]接下來，發生針對新雲中的VM2ME的MCM的遠程供應。這與圖9中的步驟0、2~11中示出的序列基本相同。因為在圖7的實施例中MCIM始終由SHO提供，對MCIM的遠程供應發生在SHO與新雲之間。
[0215]階段2:—旦已經向新domO中的VM2ME供應新MCM，新雲的通信模塊執行3GPP網絡附著(對應於圖9的階段9)。這充當去往SHO的、表明已經成功供應MCIM的信號。
[0216]階段3:SH0現在發信號通知舊的雲管理器:vM2ME CM正在運行，並且可以轉移VM。作為該消息的結果，舊的雲管理器將VM轉移(遷移)到新的雲管理器。VM遷移可以通過任何合適的方法來完成，例如，通過在圖18中一般性描述的方法，通過另一預複製遷移方法，或者通過後複製遷移方法來完成。
[0217]階段4:當遷移完成時，舊的雲管理器發信號通知SHO:關聯的舊MCM應該被移動到 「受阻」狀態。
[0218]階段5:SH0請求新的雲管理器激活新雲中的VM2ME。
[0219]階段6:vM2ME被配置並且VM被啟動。例如，可以請求管理域(新domO)啟動VM，並且該管理域使得CM使用MCM (來自vM2ME)來設立到3GPP網絡的連接。此外，該階段還設立VM的新連接，使得VM的業務去往3GPP網絡-在實踐中，這是通過創建虛擬網絡接口來完成的，該虛擬網絡接口被綁定到VM，並且其另一端被隧穿到3G網絡(在P34573中描述了隧穿的詳情)。
[0220]階段7:當VM2ME正在新雲中運行時，新domO通知新的雲管理器:vM2ME正運行在新雲中。
[0221]階段8:新的雲管理器向SHO提供該狀態。
[0222]階段9:與消息5?8並行的，舊的雲管理器發信號通知舊domO:舊雲中的vM2ME應該被禁用。
[0223]階段10:在禁用舊雲中的VM2ME之後，舊domO向舊的雲管理器提供該狀態。
[0224]階段11:如果消息8表明新VM2ME成功運行，則SHO發信號通知舊的雲管理器丟棄舊雲中的vM2ME。
[0225]階段12:舊的雲管理器發信號通知舊domO丟棄舊雲中的vM2ME。
[0226]階段13:在丟棄舊雲中的VM2ME之後，舊domO向舊的雲管理器返回該狀態。
[0227]階段14:舊的雲管理器向SHO返回該狀態。
[0228]如圖2的實施例一樣，圖4的實施例可以備選地用於在同一雲的主機之間遷移VM。在這種情況下，SHO請求在VM當前正執行在的同一雲中的新主機上預留新vM2ME，圖7中示出的新的雲管理器和舊的雲管理器是相同的實體，並且VM從一個主機遷移到同一雲中的另一主機，而不是在雲之間遷移。
[0229]在圖4和圖7的實施例中，MCM的生命周期與上文針對圖2的實施例描述的生命周期非常類似。
[0230]3GPP TR33.812描述了 MCM的多個生命周期狀態。它們在電信雲情況下也是有效的。需要當VM暫時從其當前雲(其當前安裝所在的雲，例如圖4的雲406A)遷移到另一雲時的情況的一些澄清。在這種情況下，在原始雲中為VM供應的MCIM可以進入「受阻」狀態或者可被丟棄。
[0231]「受阻」狀態表明原始雲的MCM不應該被使用。當/如果VM被遷移回原始雲(例如，經歷另一遷移，回到圖4的雲406A)，發生與圖7中所示的類似的事件序列，並且MCM應該再次進入「激活」狀態(然後進入「選定」狀態)。圖7中的不同之處在於:當針對另一遷移的請求到達舊雲時，舊的雲管理器可以識別出要遷移的VM2ME是其管理的VM2ME之一，並且已經存在已分配的、處於「受阻」狀態的MCM。於是，遠程供應僅是重新建立VM2ME以及將現有MCM移動到「活動」狀態(或者，如果該MCM已經從domO移除，則可能重新供應該MCIM)。
[0232]下述情況也是可能的:當VM鏡像在雲之間移動時，MCM始終被新的MCM替代。在這種情況下，當在遷移VM時MCIM從不會被設置為「受阻」狀態，而是被丟棄。這意味著圖7中的步驟5變成「移除MCM」，而不是「阻止MCM」。丟棄MCM還包括:從SH0/R0 (註冊運營商)移除MCM。換言之，在VM已經遷離受訪雲之後，該雲中的MCM將被刪除。
[0233]儘管VM位於其他雲(例如雲406B)中，當VM是活動的情況下其MCM將處於「激活/選定」狀態。在其他雲406B中的MCM與先前的雲406A中的MCM不相同，而是將僅在該其他雲406B中使用的新MCM。該MCM的供應(在圖7的階段I與階段2之間)可以遵循利用同一 SHO分配的PCID的常規的供應方法。遷移後的PCID可以保持不變，以使得在遷移期間MCM與VM之間的映射較簡單。
[0234]從臨時受訪雲的角度來看，除了將暫停的VM鏡像從原始雲傳送到這個雲的遷移過程之外，VM就是另一 VM。從一個運營商向另一運營商「漫遊」 VM鏡像的合同方面落在參與的雲提供商和SHO上，並且由SLA來負責。[0235]作為在每個受訪運營商網絡中始終向VM提供新MCM的備選方案，下述情況是可能的:無論VM正在訪問哪個運營商，VM始終具有相同的MCM(只要訂閱是有效的)。這將與出國時的常規行動電話漫遊類似，並且可以通過始終將PCID與相同的MCM關聯來實現。
[0236]在實踐中，這將意味著:在漫遊時，將存在下載的2個或更多個MCIM的副本。對於圖4的示例，將在最初容宿VM的雲406Α處存在下載的MCM的一個副本(其中，MCM處於「受阻」狀態)，而在當前容宿VM的雲406Β處存在下載的MCM的另一副本(其中，MCIM處於「活動」狀態)。這將使得對漫遊VM的收費方面比較容易，因為它將服從常規的漫遊收費原則(儘管該方案可能存在弊端，例如，VM的憑證將在多個運營商之間共享)。
[0237]所提出的解決方案具有眾多優點。例如，它利用現有的3GPP標準來提供在一個雲提供商的物理機器之間，甚至在一個雲供應商和不同的雲提供商之間，遷移VM的安全方式。在圖2的實施例中，當前(受訪)運營商為VM提供直接的網際網路連接，因此消除了經由歸屬運營商的三角路由，並且最小化了網際網路客戶端的延遲。在圖4的實施例中，無論VM要遷移到哪個雲，VM都可以保持相同的網絡配置(包括其公共IP位址)_其結果是，將始終可在網絡中的相同存在點聯繫到該VM。此外，現有的3GPP收費機制可被應用於在運營商的數據中心之間漫遊的VM。
[0238]從顧客的角度來看，所提供的解決方案是非常簡單的；顧客向單個雲運營商購買用於VM的資源。在此之後，資源分配等是由雲運營商完成的，與其他雲解決方案相比，顧客並不需要做特殊的事情。
[0239]VM可被遷移的範圍在一定程度上可以是由顧客控制的。例如，顧客可以與運營商籤訂SLA。SLA可以限定針對可能遷移的界限-例如，SLA可以聲明VM可以遷移到特定受訪運營商數據中心集合。作為另一示例，SLA可以允許VM基於尖峰時段以及在運營商之間已經建立的遷移/ 「漫遊」協議來進行遷移。可以重用現有的3GPP漫遊SLA。另外，3GPP規範還定義了用於歸屬運營商網絡與受訪運營商網絡之間的控制業務的安全保護。這些安全關聯可被用於保護VM遷移。
[0240]如果制定了這樣的SLA，則雲提供商(例如，可能是位於歐洲的雲提供商)可以與其他運營商(例如，位於北美的雲提供商以及位於亞洲的雲提供商)達成SLA，並基於雲提供商自身網絡中的負載無縫地四下移動訂戶的VM。這意味著，例如，在雲服務提供商自身網絡的尖峰時段期間，一些VM可被移動到世界上的處於晚上或者出於其他一些原因存在空閒資源的其他地方。而且，有可能甚至不需要運營商之間的這種SLA，而代之為運營商可以在支付一定的費用的情況下彼此提供雲服務，其與企業對企業的服務類似。
[0241]3GPP架構和標準已經定義了許多安全特徵，這種特徵這將使得這種服務便於MNO部署。雲提供商例如可以直接利用在3GPP網絡中找到的QoS和收費功能。此外，這賦予MNO新的明確的商務/服務角色，這種角色使得它們在雲業務中不再僅是作為比特管道提供者。
[0242]圖14是示出了在本發明的方法中由舊的雲管理器執行的主要步驟的流程框圖。在步驟1403中，舊的雲管理器發起當前正執行在舊雲中的舊VM2ME上的VM到新的執行環境的遷移。新的執行環境可以是在新雲中，或者可以是在舊雲中的新主機。一旦遷移完成，雲管理器禁用(步驟1404)舊vM2ME。
[0243]在新的執行環境是在新雲中的情況下，在步驟1403中的遷移之前，雲管理器可以向新的雲管理器發送(步驟1401)針對新VM2ME的請求。在這種情況下，新的雲管理器將在新雲中為VM供應新MCM，以及舊的雲管理器在接收到供應了新MCM(步驟1402)之後發起對VM的遷移。
[0244]同樣，在新的執行環境是在新雲中的情況下，在步驟1403的遷移之後，雲管理器可以指示(步驟1405)新的雲管理器激活新VM2ME。
[0245]一旦VM運行在新的執行環境中，該雲管理器可以丟棄(步驟1406)舊vM2ME(已在步驟1404中禁用)，從而釋放委託給舊VM2ME的資源，供再利用。該雲管理器也可以阻止或丟棄與VM關聯的舊MCM(步驟1407)。
[0246]圖15是示出了在本發明的方法中由「新」的雲管理器執行的主要步驟的流程框圖，在該方法中VM從一個雲中的執行環境遷移到另一雲中的新的執行環境。在步驟1501中，新的雲管理器接收針對VM的新vM2ME的請求；該請求來自正在對VM當前執行所在的雲進行管理的雲管理器。響應於該請求，新的雲管理器發起對用於VM的新MCIM的供應(步驟1502)。新的雲管理器還預留用於VM的新VM2ME的資源。隨後，在VM已遷移到新雲之後，新的雲管理器激活新vM2ME (步驟1505)。
[0247]當完成了對新MCM的供應時，新的雲管理器還可以向舊的雲管理器進行報告(步驟1503)。步驟15035處的對新vM2ME的激活可以在接收到(步驟1504)來自舊的雲管理器的激活新vM2ME的指令之後。
[0248]當完成了對新VM2ME的激活時，新的雲管理器還可以向舊的雲管理器進行報告(步驟 1506)。
[0249]圖16是示出了在圖4和7的方法中由SHO執行的主要步驟的流程框圖。在步驟1602中，SHO決定發起當前執行在「舊」雲中的「舊」 VM2ME上的VM到新的執行環境的遷移。新的執行環境可以是在新雲中，或者可以是舊雲中的新主機。SHO可以在接收到(步驟1601)針對新的執行環境的請求之後做出該決定，甚或可以在不存在這樣的請求的情況下做出該決定。
[0250]然後，SHO在新的執行環境中供應(步驟1603)用於VM的MCM，並且還發送在新的執行環境中預約用於VM的新vM2ME的資源的請求。
[0251]一旦SHO接收到對已經在新的執行環境中供應了用於VM的MCM的確認，SHO就指示(步驟1604) VM當前正執行所在的舊雲的雲管理器:將VM遷移到新的執行環境。
[0252]在確認VM已被遷移到新的執行環境之後，SHO於是可以指示(步驟1605)包含新的執行環境在內的雲的雲管理器(例如新的雲管理器)激活新VM2ME。
[0253]在確認VM已被遷移到新的執行環境之後，SHO還可以阻止或丟棄(1606)舊的執行環境中的與VM關聯的MCM。
[0254]一旦VM在新的執行環境中運行，SHO就可以丟棄(步驟1607)舊vM2ME，從而釋放委託給舊vM2ME的資源，供再利用。
[0255]圖17是體現本發明的電信網絡實體1700的示意框圖。圖17示出了一個示例，其中電信網絡實體1700是包含多個伺服器1702的分布式計算環境1701的管理器。例如，分布式計算環境1701可以是計算雲，並且電信網絡實體1700可以是雲1701的雲管理器，並且因此可以控制雲1701中的虛擬化平臺上發生的事情。電信網絡實體可以經由網際網路(未示出)和合適的接入網1705(例如3GPP網絡)接收來自用戶的在雲1701上執行的作業，並且在雲1701的一個或多個伺服器1702上調度所述作業。
[0256]電信網絡實體1700包含伺服器1703，伺服器1703根據諸如磁碟或光碟之類的計算機可讀介質1704上包含的電腦程式代碼或指令來工作。
[0257]電信網絡實體1700可以在雲的伺服器上操作一個或多個VM。計算機可讀介質1704可以使得伺服器1703執行本發明的用於將VM從雲1701的伺服器1702之一遷移到雲1701的伺服器1702中的另一個伺服器的方法，和/或執行本發明的用於將VM從雲1701的伺服器1702之一遷移到另一雲(在圖17中未示出)的方法，和/或執行本發明的用於將VM從另一雲(在圖17中未不出)遷移到雲1701的伺服器1702之一的方法。
[0258]附錄
[0259]以下是在本申請中使用的縮寫:
[0260]PVA:平臺驗證機構。根據3GPP TS33.812，第5.1.3.5.8節:「PVA是負責核實用於驗證M2M設備是否為可信平臺的憑證的權威機構。PVA還可以頒發這些憑證。
[0261]PVA支持以下功能:
[0262]-核實平臺憑證，所述平臺憑證宣稱作為保存MCM應用和憑證的平臺的M2ME的真實性和完整性；
[0263]-向DPF和SHO提供與對M2ME的核實是成功還是失敗有關的信息。
[0264]-在需要時，如在遠程更新M2ME之後，獲取新的平臺憑證。
[0265]平臺憑證(PfC)的內容和格式例如可以具有下述變型。PfC可能包含若干部分，其中的一些部分是設備特定的，而一些部分是一組設備通用的。例如，(1)M2MES公鑰，其充當用於驗證的信任的根(公共的，通用的)；(2)M2ME中存儲的設備特定的私鑰(秘密的，設備特定的)；(3)頒發給M2M ES的對應公鑰的證書(公共的，設備特定的)，其宣稱預期的M2M的系統狀態。在這種場景下，PfC需要由PVA在製造之前以安全方式獲得，在製造期間內嵌在或初始化在M2ME中；並且可以在平臺核實期間與其他信息一起提供。
【權利要求】
1.一種遷移虛擬機的方法，所述方法包括在管理第一計算環境的第一管理器處: 發起當前在第一計算環境中的第一 VM2ME上執行的虛擬機到第二計算環境的遷移；以及 禁用所述第一 vM2ME的執行。
2.根據權利要求1所述的方法，其中，所述第二計算環境是由不同於所述第一管理器的第二管理器來管理的。
3.根據權利要求1或2所述的方法，包括:在發起虛擬機的遷移之前，所述第一管理器發送針對在所述第二計算環境中建立用於執行VM的VM2ME的請求。
4.根據權利要求1、2或3所述的方法，包括:所述第一管理器在接收到對已經在所述第二計算環境中的虛擬管理域中供應了用於所述虛擬機的MCIM的確認之後，發起對所述虛擬機的遷移。
5.根據權利要求2、3或4所述的方法，還包括:在所述虛擬機遷移到所述第二計算環境之後，所述第一管理器指示所述第二管理器激活所述第二計算環境中的vM2ME。
6.根據任一前述權利要求所述的方法，還包括:所述第一管理器發起對所述第一計算環境中為所述虛擬機供應的虛擬的機器 對機器設備的釋放。
7.根據任一前述權利要求所述的方法，還包括:所述第一管理器指示與所述第一計算環境關聯的運營商阻止所述第一計算環境中與所述虛擬機關聯的MCM。
8.根據權利要求1~5中任一項所述的方法，還包括:所述第一管理器指示與所述第一計算環境關聯的運營商丟棄所述第一計算環境中與所述虛擬機關聯的MCIM。
9.一種遷移虛擬機的方法，所述方法包括: 在管理計算環境的管理器上接收用於將當前在另一計算環境中執行的虛擬機遷移到所述計算環境的請求； 由所述管理器發起在所述計算環境中供應用於執行所述虛擬機的MCIM ;以及 所述管理器指示在所述計算環境中激活所述虛擬機。
10.根據權利要求9所述的方法，其中，所述計算環境中的用於執行所述虛擬機的MCIM是在所述計算環境的虛擬管理域中供應的。
11.根據權利要求9或10所述的方法，其中，所述計算環境由不同於所述管理器的另一管理器來管理。
12.根據權利要求11所述的方法，還包括:所述管理器向所述另一管理器通知對用於所述虛擬機的MCM的供應。
13.根據權利要求11或12所述的方法，其中，所述管理器在接收到來自所述另一管理器的指令之後，指示在所述計算環境中激活所述虛擬機。
14.根據間接從屬於權利要求10的權利要求13所述的方法，其中，所述管理器指示所述虛擬管理域激活所述虛擬機。
15.根據權利要求11~14中任一項所述的方法，包括:所述管理器向所述另一管理器通知在所述計算環境中激活所述虛擬機。
16.—種遷移虛擬機的方法，所述方法包括: 在歸屬運營商處，決定用於當前在第一計算環境中執行的虛擬機的新的執行環境，所述虛擬機與所述歸屬運營商關聯；由所述歸屬運營商發起在不同於所述第一計算環境的第二計算環境中供應用於執行所述虛擬機的vM2ME的MCM(MCM-2)； 當所述歸屬運營商接收到對供應了所述MCIM的確認時，所述歸屬運營商指示管理所述第一計算環境的第一管理器將所述虛擬機遷移到所述第二計算環境。
17.根據權利要求16所述的方法，其中，在接收到針對所述虛擬機的新的執行環境的請求時，所述虛擬機與所述歸屬運營商提供的用於在所述第一計算環境中執行所述虛擬機的另一 MCM(MCM-1)相關聯。
18.根據權利要求17所述的方法，還包括:在所述虛擬機已經被遷移到所述第二計算環境之後，所述歸屬運營商阻止所述歸屬運營商提供的用於在所述第一計算環境中執行所述虛擬機的所述另一 MCM(MCM-1)。
19.根據權利要求16、17或18所述的方法，其中，所述第二計算環境由不同於所述第一管理器的第二管理器來管理。
20.根據權利要求19所述的方法，包括:所述歸屬運營商指示所述第二管理器在所述第二計算環境中激活所述虛擬機。
21.根據權利要求20所述的方法，包括:在所述第二計算環境中激活所述虛擬機之後，所述歸屬運營商指示所述第一管理器丟棄所述第一計算環境中為所述虛擬機供應的虛擬的機器對機器設備 。
22.一種配置用於遷移虛擬機的電信網絡實體，所述網絡實體包括處理器和存儲程序指令的存儲器，所述程序指令在由所述處理器執行時，使得所述網絡實體； 發起當前在由所述網絡實體管理的第一計算環境中執行的虛擬機到第二計算環境的遷移；以及 禁用所述虛擬機在所述第一計算環境中的執行。
23.根據權利要求22所述的電信網絡實體，其中，所述指令還使得所述網絡實體:在發起虛擬機的遷移之前，發送針對在所述第二計算環境中建立用於執行VM的VM2ME的請求。
24.根據權利要求22或23所述的電信網絡實體，其中，所述指令還使得所述網絡實體:在接收到對已經在所述第二計算環境中的虛擬管理域中供應了用於所述虛擬機的MCIM的確認之後，發起所述虛擬機的遷移。
25.根據權利要求22、23或24所述的電信網絡實體，其中，所述指令還使得所述網絡實體:在所述虛擬機遷移到所述第二計算環境之後，指示所述第二管理器激活所述第二計算環境中的νΜ2ΜΕ。
26.根據權利要求22~25中任一項所述的電信網絡實體，其中，所述指令還使得所述網絡實體:發起對所述第一計算環境中為所述虛擬機供應的虛擬的機器對機器設備的釋放。
27.根據權利要求22~26中任一項所述的電信網絡實體，其中，所述指令還使得所述網絡實體:指示與所述第一計算環境關聯的運營商阻止所述第一計算環境中與所述虛擬機關聯的MCM。
28.根據權利要求22~26中任一項所述的電信網絡實體，其中，所述指令還使得所述網絡實體:指示與所述第一計算環境關聯的運營商丟棄所述第一計算環境中與所述虛擬機關聯的MCM。
29.一種配置用於遷移虛擬機的電信網絡實體，所述網絡實體包括處理器和存儲程序指令的存儲器，所述程序指令在由所述處理器執行時，使得所述網絡實體: 接收用於將當前在另一計算環境中執行的虛擬機遷移到由所述網絡實體管理的計算環境的請求； 發起在由所述網絡實體管理的計算環境中供應用於執行所述虛擬機的MCIM ;以及 指示在由所述網絡實體管理的計算環境中激活所述虛擬機。
30.根據權利要求29所述的電信網絡實體，其中，所述指令還使得所述網絡實體:發起在所述計算環境的虛擬管理域中供應用於執行所述虛擬機的MCIM。
31.根據權利要求29或30所述的電信網絡實體，其中，所述指令還使得所述網絡實體:向所述另一管理器通知對用於所述虛擬機的MCIM的供應。
32.根據權利要求29、30或31所述的電信網絡實體，其中，所述指令還使得所述網絡實體:在接收到來自所述另一管理器的指令之後，指示在所述計算環境中激活所述虛擬機。
33.根據直接或間接從屬於權利要求30的權利要求32所述的電信網絡實體，其中，所述指令還使得所述網絡實體:指示所述虛擬管理域激活所述虛擬機。
34.根據權利要求29~33中任一項所述的電信網絡實體，其中，所述另一計算環境由不同於所述網絡實體的另一管理器來管理，並且所述指令還使得所述網絡實體:向所述另一管理器通知在所述計算環境中激活所述虛擬機。
35.一種配置用於管理虛擬機的電信網絡實體，所述網絡實體包括處理器和存儲程序指令的存儲器，所述程序指令在由所述處理器執行時，使得所述網絡實體: 決定用於當前在第一計算環境中執行的虛擬機的新的執行環境，所述虛擬機與所述網絡實體相關聯； 發起在不同於所述第一計算環境的第二計算環境中供應用於執行所述虛擬機的vM2ME的MCIM ；以及 當所述網絡實體接收到對供應了 MCIM的確認時，指示管理所述第一計算環境的第一管理器將所述虛擬機遷移到所述第二計算環境。
36.根據權利要求35所述的電信網絡實體，其中，在接收到針對所述虛擬機的新的執行環境的請求時，所述虛擬機與由所述歸屬運營商提供的另一 MCIM(MCM-1)相關聯，並且所述指令還使得所述網絡實體:在所述虛擬機已經被遷移到所述第二計算環境之後阻止所述另一 MCM(MCM-1)。
37.根據權利要求35或36所述的電信網絡實體，其中，所述第二計算環境由不同於所述第一管理器的第二管理器來管理，並且所述指令還使得所述網絡實體:指示所述第二管理器在所述第二計算環境中激活所述虛擬機。
38.根據權利要求37所述的電信網絡實體，其中，所述指令還使得所述網絡實體:當在所述第二計算環境中激活所述虛擬機之後，指示所述第一管理器丟棄所述第一計算環境中為所述虛擬機供應的虛擬的機器對機器設備。
39.一種包含指令的計算機可讀介質，所述指令在由處理器執行時，使得所述處理器執行根據權利要求1~21中任一項所述的方法。
40.一種電腦程式，其在由處理器執行時，使得所述處理器執行根據權利要求1~21中任一項所述的方法。
【文檔編號】G06F9/48GK104025052SQ201180076087
【公開日】2014年9月3日 申請日期:2011年12月29日 優先權日:2011年12月29日
【發明者】派屈克·薩爾梅拉, 克裡斯蒂安·斯拉沃夫, 朱卡·於利塔洛 申請人:瑞典愛立信有限公司