移動虛擬化的基礎設施以及基礎平臺的製作方法

2023-06-16 03:28:56 1

專利名稱：移動虛擬化的基礎設施以及基礎平臺的製作方法
技術領域：
本發明涉及一種移動虛擬化的基礎設施，該移動虛擬化的基礎設施涉及手機用戶如何獲取在機房裡的虛機(包括手機虛機及PC虛機)及其上應用的屏幕，尤其是手機虛機如何經由模擬器QEMU在機房伺服器上產生及如何運用虛機池來管理大量虛機。
背景技術：
隨著計算機和網際網路技術的進步，出現了個人電腦作業系統虛擬化的趨勢，即個人電腦的作業系統不是真實地在本地運行，而是集中在一個可虛擬大量作業系統的遠端機房運行，再將作業系統的界面通過網絡發送到各個終端。在個人電腦作業系統虛擬化的應用領域中有所謂桌面虛擬化基礎設施(VirtualDesktop Infrastructure)的技術，簡稱為VDI。 VDI的管理軟體能掌控在機房裡大量的虛機所形成的虛機池，而利用RDP把桌面傳到啞終端上。V麗are公司的ESXi、思傑公司的Xen、和微軟的Hyper-V都可用做VDI的基礎虛擬技術。 而另一方面，當今高端的智慧型手機已經越來越像個人電腦(PC) 了，例如黑莓或蘋果iphone都可瀏覽網際網路、檢查電子郵件、聽音樂、看電影、照相、導航、或者就是打電話。手機性能需求的不斷提升，導致手機製作成本一直居高不下，因此近年來提出了移動虛擬化(virtual mobile)的概念，即在機房裡用固網資源虛擬大量虛機，再將屏幕傳輸至手機終端。 與傳統的手機技術相比，移動虛擬化的優勢為(l)將自動化擴充到任何會攜帶手機的人，他們可以經由屏幕傳輸，使用運行在機房裡虛機上的PC老應用或手機新應用。(2)虛擬化可以增加手機安全性，例如無虞病毒攻擊或手機遺失。(3)手機虛機更易適配客戶端的真手機，且傳屏數據量少，所需頻寬低。(4)可利用到機房裡大量廉價的CPU、內存、硬碟與固網資源。 在移動虛擬化的背景之下，提出一種可用的、高效的移動虛擬化的基礎設施(Virtual Mobile infrastructure, VMI)，成為本領域亟待解決的問題。

發明內容
本發明的目的是提供一種移動虛擬化的基礎設施，更確切地說是涉及企業或移動電信公司能將PC和/或手機虛機的屏幕傳到手機上的基礎設施。 通過虛機交換機的特徵，創建了一個機制可利用本發明的VMI移動虛擬化基礎設
施獲取適配的手機屏幕以及廉價的虛機。在一個較佳實施例中，還可以套接第三方VDI開
發商的產品(例如Citrix XenDesktop，LeoStream，etc.)，從而獲取PC虛機的屏幕。並且
由於採用虛機管理方法，企業或移動電信管理員可管理成千上萬虛機。 為了實現上述目的，本發明採用了一種移動虛擬化的基礎設施，其包括 基礎平臺，包括多個主機，其中每一主機上使用運行在主機作業系統上的QEMU進
程虛擬至少一個具有客戶作業系統及內存的手機虛機；
數據管理中心，管理所述基礎平臺產生的手機虛機並向用戶分派所述手機虛機；
虛機交換機，連接所述基礎平臺及所述數據管理中心，所述虛機交換機根據來自手機客戶端的用戶請求，讓用戶選取手機虛機及運行在手機虛機上的手機應用；以及
基於移動終端協議的伺服器，用於與手機客戶端交互。 在本發明的一實施例中，基礎平臺進一步包括使客戶作業系統的QEMU進程與內核共享主機內存的裝置。 在本發明的一實施例中，所述基礎平臺進一步包括用以獲取子進程和/或主機的性能狀態的性能代理器。 在本發明的一實施例中，所述移動虛擬化的基礎設施進一步包括用以改善QEMU的軟體匪U的裝置，其中頁表查找到客戶作業系統內存區虛擬地址所對應的物理地址，再將該物理地址當成偏移量來按位運算彙編指令中的地址。 在本發明的一實施例中，所述基礎平臺進一步包括以客戶作業系統源碼和平臺調試工具的開放程度來處理虛擬化的I/O設備調試預處理器，其中如果完全源碼開放就重新編譯使能直接運行在x86平臺上，如果平臺調試工具開放則在QEMU上用工具進行I/O驅動調試，否則用硬體開發板及BSP輔助逆向工程。 在本發明的一實施例中，所述基於移動終端協議的伺服器運行於所述基礎平臺的主機作業系統中。 在本發明的一實施例中，所述基於移動終端協議的伺服器進一步包括 在屏幕傳送前將鏡像按比例縮放、旋轉、壓縮以進行屏幕適配的裝置； 在屏幕傳送前將之辨識鏡像改變、辨識文字，然後只傳文字及改變方塊區的裝置。 在本發明的一實施例中，所述手機客戶端包括將GPS經緯度從數據通道傳給所
述伺服器，支持回音消除及按傳收雙方頻寬、手機配備而從多種音頻加碼器談判取得最優
方法的裝置。 在本發明的一實施例中，所述數據管理中心進一步包括 虛機分派器，建立對話期、從虛機池取到最合適的虛機、分派虛機給手機客戶端； 虛機池管理器，以多種服務來選取虛機池中的合適虛機、返回虛機到虛機池裡、檢
查虛機狀態，並以背景工作的不斷檢查虛機池狀態來符合一規則引擎的規則； 虛機伺服器管理器，管理多個主機並使用平臺應用接口與所述基礎平臺交互；以
及 管理控制臺，用以統一以下資源的任意組合管理人員、組織、模板、虛機、應用、套餐和伺服器。 在本發明的一實施例中，所述規則引擎包含用來控制虛機的生成與銷毀，啟動與
停止的規則，其中所述規則可由管理員以高等計算機語言創建、編輯、保存、刪除。
在本發明的一實施例中，所述虛機交換機包括連接代理，提供手機客戶端接入通
道，並向手機客戶端傳輸桌面屏幕與應用屏幕。 在本發明的一實施例中，所述連接代理的手機客戶端接入進一步包括統一認證與授權以完成kerberos安全協議與單點登錄。 在本發明的一實施例中，所述虛機交換機包括人員與團體管理資料庫、應用與套餐管理資料庫、以及虛機伺服器與模板管理資料庫。
在本發明的一實施例中，還包括用以進行模板管理的裝置，其使用模板綁定以下 設置信息的一種或幾種虛機與內存、CPU、應用、主機、手機作業系統。 在本發明的一實施例中，還包括VDI套接器，其中所述虛機交換機經由所述VDI套 接器套接至外部VDI產品，以讓用戶選取運行在外部VDI產品中的PC虛機及PC應用。
在本發明的一實施例中，所述VDI套接器進一步包括 PC連接代理，告知外部VDI產品用戶登錄後所取得的虛機要運行什麼應用，等待 PC應用代理激活了該應用後，再通知手機客戶端準備用移動終端協議接收應用屏幕；
PC應用代理，預先安裝在外部VDI產品的虛機上，當虛機被啟動，應用代理自己被 激活，再激活所指定的PC應用，然後告訴PC連接代理應用成功與否；若成功，則將應用屏幕 傳至手機客戶端；當手機客戶端斷開，PC應用代理就關閉應用。
另一方面，本發明提出一種移動虛擬化的基礎平臺，包括
多個主機，其中每一主機包括 運行在主機作業系統上的至少一 QEMU模擬器，以虛擬至少一個具有客戶操作系 統及內存的手機虛機； 使客戶作業系統的QEMU進程與內核共享主機內存的裝置； 獲取子進程和/或主機的性能狀態的性能代理器； 基於移動終端協議的伺服器，用於與手機客戶端交互。
在本發明的一實施例中，上述的移動虛擬化的基礎平臺還包括 用以改善QEMU的軟體匪U的裝置，其中頁表查找到客戶作業系統內存區虛擬地址
所對應的物理地址，再將該物理地址當成偏移量來按位運算彙編指令中的地址。
在本發明的一實施例中，上述的移動虛擬化的基礎平臺還包括 以客戶作業系統源碼和平臺調試工具的開放程度來處理虛擬化的I/O設備調試
預處理器，其中如果完全源碼開放就重新編譯使能直接運行在x86平臺上，如果平臺調試
工具開放則在QEMU上用工具進行I/O驅動調試，否則用硬體開發板及BSP輔助逆向工程。 本發明為企業和移動電信提供了一種在移動網上訂閱應用軟體的方法，該方法是
在手機作業系統虛擬化的基礎上，創建了移動終端協議的客戶端，讓用戶可接入、取得虛
機、運行應用、得到手機應用屏幕、因而可以運行任何手機作業系統及手機應用軟體。另外，
由於套接第三方VDI產品，也可在手機上運行任何PC作業系統及PC應用軟體。 在本發明中，客戶用的不是啞終端而是智慧型手機，通過遠程桌面協議(Remote
desktop protocol, RDP)或與RDP兼容的移動終端協議(MobileTerminal protocol, MTP)
來獲取屏幕。屏幕不但來自於(a)PC虛機(後臺與VDI—樣，但附加手機屏幕適配器)；且
可來自於(b)機房裡的手機虛機。


下面參照附圖，對於熟悉本技術領域的人員而言，從對本發明方法的詳細描述中，
本發明的上述和其他目的、特徵和優點將顯而易見。
圖1A是本發明的移動虛擬化的基礎設施的系統組成框圖； 圖IB是本發明的移動虛擬化的基礎設施的QVisor主機層狀結構圖； 圖2是圖1A中虛機交換機12的工作流程 圖3是圖1A中管理控制臺142的流程圖，也提供圖1中人員與團體管理122、應用 與套餐管理123、虛機伺服器和模板管理124的管理界面； 圖4是圖3中步驟312模板管理的流程圖； 圖5是圖1A中連接代理121的流程圖； 圖6是圖5中步驟502的統一認證授權系統(UAAS)流程圖； 圖7是圖1A中虛機分派器141的流程圖； 圖8是圖1A中虛機池管理器143的流程圖； 圖9是圖8中步驟802政策管理器的流程圖； 圖10是圖1A中虛機伺服器管理器145的流程圖； 圖11是圖1A中QVisor應用接口 146其中之"創建虛機"的流程圖； 圖12是圖1A中QVisor應用接口 146其中之"克隆虛機"的流程圖； 圖13是圖1A中QVisor應用接口 146其中之"啟動虛機"的流程圖； 圖14是圖1A中QVisor應用接口 146其中之"停止虛機"的流程圖； 圖15是圖1A中QVisor應用接口 146其中之"刪除虛機"的流程圖； 圖16是圖1A中QVisor應用接口 146其中之"取得虛機狀態"的流程圖； 圖17是圖1A中QVisor應用接口 146其中之"取得虛機"的流程圖； 圖18是圖1A中QVisor應用接口 146其中之"取得虛機列表"的流程圖； 圖19是圖1A中QVisor應用接口 146其中之"取得運行虛機列表"的流程圖； 圖20是圖1A中QVisor應用接口 146其中之"取得停止虛機列表"的流程圖； 圖21是圖1A中QVisor應用接口 146其中之"取得虛機性能值"的流程圖； 圖22是圖IB中虛機性能代理155的流程圖； 圖23是圖1A中QVisor主機151的"共享QEMU和內核"部分流程圖; 圖24是圖1A中QVisor主機151的"改進QEMU Soft匪U"部分流程圖； 圖25是圖1A中QVisor主機151的"1/0設備調適預處理器"部分流程圖； 圖26是圖IB中MTP伺服器152的"適配手機屏幕"部分流程圖； 圖27是圖IB中MTP伺服器152的"智能傳屏"部分流程圖； 圖28是圖1A中MTP客戶端111的"手機端音頻與衛星定位數據處理器"部分流
程圖； 圖29是圖IB中應用代理154的流程圖。 圖30是應用啟動與關閉時序圖。
具體實施例方式
概述 圖1A是本發明的移動虛擬化的基礎設施的系統組成框圖。此移動虛擬化的基礎 設施包括虛機交換機12、可選的第三方VDI產品13、數據管理中心14以及基礎平臺15 (本 發明中稱為QVisor平臺)。數據管理中心14的一個例子是申請人銷售的VMI產品威寧數 據中心。 圖IA所示的系統中，手機客戶端11通過虛機交換機12可以從數據管理中心14 取得手機虛機的屏幕。其中，數據管理中心14會與QVisor平臺15互動，而由QVisor主機151來提供多個手機虛機。在一個可選實施例中，手機客戶端11還可以從第三方VDI的產 品13取得PC虛機的屏幕。 虛機交換機12的作用是使應用屏幕可以從VDI的PC虛機和VMI的手機虛機兩種 後臺傳到手機客戶端11上。典型的VMI設置是這樣的虛機交換機安裝在一個地緣的節點 上，同時掌控多個上述數據管理中心12和多個VDI產品13。這裡，虛機交換機12可以讓用 戶選擇運行在VMI (手機虛機)或第三方VDI (PC虛機)管理系統之上的應用。
在一個例子中，VDI系統也可以和運軟的專利申請"一種應用虛擬化在公網 上的通用商務方法"相結合(美國專利公開號US 2008/0183641A1與中國專利公開號 CN101231731A)。申請人的銷售產品TRANS0D的客戶端和伺服器端都可運行在數據管理中 心裡，可以輔助應用的自動部署。 虛機交換機12的連接代理121負責與外部VDI產品13或VMI產品數據管理中心 14的接入工作。連接代理121包括PC連接代理1211與手機連接代理1212。虛機交換機 12還擁有人員與團體管理資料庫122，應用與套餐管理資料庫123，以及虛機伺服器和模板 管理資料庫124。這些資料庫是由數據管理中心14中的管理控制臺142進行管理。虛機交 換機12通過連接代理的統一認證授權系統決定用戶是否有權取得所訂閱應用的屏幕。虛 機交換機12並能判斷該應用是從第三方的VDI後臺過來，還是從數據管理中心的QVisor 後臺過來，從而採取適當的手機屏幕適配措施。 VDI第三方產品13是通過PC應用代理131、 PC連接代理1211與VMI套接，形成 "VDI套接器"。 數據管理中心14是手機虛機的管理系統，它包含了虛機分派器141、管理控制臺 142、虛機池管理器143、虛機性能監測器144、虛機管理伺服器145和QVisor應用接口 146。 數據管理中心含有當前所有虛機的狀態，能利用虛機池管理系統向QVisor獲取虛機，加以 分派。獲取虛機時需要通過虛機伺服器管理系統連接到QVisor應用接口 。 QVisor應用接 口包含虛機的創建銷毀，啟動停止，虛機的獲取，虛機列表的獲取，活動虛機列表的獲取，停 止虛機列表的獲取，以及性能數據接口 。 QVisor平臺15是VMI的基礎技術，可包含多個QVisor主機151，每個QVisor主機 運行作業系統152，在作業系統上又可運行性能代理154、MTP伺服器153及多個QEMU的子 進程155。在QEMU上再運行某個行動作業系統156(0S)，例如WinMobile， gPhone， iPhone 等。當手機作業系統啟動後，其上的應用代理157會自行啟動。QVisor平臺15的層狀組織 結構如圖1B所示。QVisor平臺執行性能監測，QEMU及內核共享，內存分頁優化，輸入輸出 設備調試的預處理的功能。 實現本發明的移動虛擬化的基礎設施，需要MTP客戶端111通過MTP協議與MTP服 務器端153進行通信，其中MTP客戶端是智慧型手機11的一個軟體，而MTP的伺服器153則 是運行在QVisor主機151的作業系統上。MTP協議在下面將詳細介紹。
移動終端協議(MTP)客戶端安裝在手機上(但如果WinMobile手機已有RDP (遠 程桌面)6. 0客戶端或iPhone手機已有Safari瀏覽器則不必)。該客戶端上可以看見用戶 訂閱的應用套餐。如果用戶點擊套餐裡的應用，在虛機交換機12上存有用戶專有信息以資 驗證，而後數據管理中心14會透過QVisor應用接口 146去QVisor平臺15取得虛機，這時 應用代理157會激活應用並把第一個應用屏幕傳到客戶的手機上。
虛機奪換機 圖2給出了虛機交換機12的工作流程情況。虛機交換機工作流程具體包括
步驟201，用戶以登錄請求(用戶名和密碼)與所訂閱的應用進入虛機交換機；
步驟202，判斷用戶是否訂閱了任何應用。如是，轉入步驟204，否則必須先進行步 驟203才能進行步驟209 ; 步驟203，在默認移動虛機上激活默認移動應用，實際是讓用戶得到移動虛機的操 作系統桌面； 步驟204，判斷用戶所訂閱的是否為PC應用。如是，轉入步驟205，否則轉入步驟 207 ; 步驟205，進入PC連接代理1211，找到最佳PC虛機並將之啟動；PC連接代理將在 下文參照圖5進一步說明； 步驟206，通知PC應用代理131激活PC應用，然後轉入步驟209 ;PC應用代理將 在下文參照圖29進一步說明；在一例子中，如果第三方VDI產品可以套接，PC應用代理131 可以用CN101231731A號專利公開的"一種應用虛擬化在公網上的通用商務方法及其迷你 伺服器"技術來激活並串流到PC虛機上； 步驟207，進入移動連接代理1212 :找到最佳手機虛機並將之啟動；並通知手機應 用代理157在虛機上激活移動應用；移動連接代理的流程將在下文參照圖5進一步說明；
步驟208， MTP伺服器傳輸應用的第一屏給客戶端。 圖2開始了從用戶的角度來看整個系統流程的說明。在步驟202判斷用戶是否訂 閱了任何應用的時候，必須要調用數據管理中心的人員組織、應用套餐資料庫，因此下面的 圖3給出數據管理中心的說明。圖4則是與圖3有關的一個數據管理中心的功能(模板管 理)。在說明的時候，插入了圖3與圖4這些管理員的操作，如果仍要以用戶的角度來看整 個系統流程，可直接跳到圖5。
數據管理中心 圖3給出了管理控制臺142的工作流程情況。管理屏幕是實現資源管理系統 (Resource management system, RMS)的一種方法。資源管理系統的概念就是統一管理人 員、組織、模板、虛機、應用、套餐和伺服器。在過去，微軟的活動目錄(Active Directory, AD)對人員管理相當風行，但遊動四方的手機用戶卻無AD管理之必要。相反地"非AD"的 輕量級電話簿接入協議(LDAP)可用來管理人員組織，甚至可實現多組織、多房客的資料庫 以符合電信公司的需求。VMI的管理控制臺142把上述資源整合在單一系統中，而後臺則用 各資源資料庫表來實現。流程包括 步驟301，首先是管理員進入管理控制臺142，該管理控制臺提供一交互式界面讓 管理員進行操作； 步驟302，判斷操作是否為管理人員及團體。若是，轉入步驟303，否則轉入步驟
304 ; 步驟303，進行輕量級電話簿接入協議(LDAP)，其中會操作虛機交換機12中的人 員與團體管理資料庫122; 步驟304，判斷操作是否為管理應用及套餐。若是，轉入步驟305，否則轉入步驟
306 ;
9
步驟305，操作虛機交換機12中的應用與套餐的資料庫123 ; 步驟306，判斷操作是否為管理虛機。若是，轉入步驟307，否則轉入步驟310 ; 步驟307，虛機伺服器管理，細節見圖10，其過程大致是先轉入步驟308的QVisor
應用接口 146，再由步驟309在QVisor主機151裡創建、啟動、停止、刪除虛機等； 步驟308，從步驟307而來的虛機伺服器管理器的各個功能會通過網絡服務(web
services)的方式調用QVisor應用接口 146來創建、啟動、停止、刪除虛機等； 步驟309， QVisor主機151裡運行在QEMU 153上的客戶作業系統會被啟動或停
止； 步驟310，判斷操作是否為管理QVisor主機。若是，轉入步驟311，否則轉入步驟 312 ; 步驟311，操作QVisor主機的資料庫表； 步驟312，進行模板管理，細節見圖4及下文的相關描述。 樽板管理 圖4是模板管理的處理流程圖。模板管理的概念就是使用模板綁定了虛機與內 存、CPU、應用、主機、手機作業系統等設置信息。與VDI不同的是，模板不再受限於活動目錄 (AD)或其他網絡管理工具(例如不必顧忌AD的入域及出域)。多個虛機可以有相同模板。
步驟401，管理員進入模板管理； 步驟402，判斷操作是否為建立模板。若是，轉入步驟403，否則轉入步驟404 ;
步驟403，從界面取得模板的名字、鏡像ID(與鏡像存儲的路徑有關)、模板類型 (即不同的手機作業系統)、內存、CPU、應用、以及用戶指定的那些會按模板信息來安裝虛 機的主機，並把這些信息在資料庫模板表裡建立一條模板記錄； 步驟404，判斷操作是否為查找模板。若是，轉入步驟405，否則轉入步驟408 ;
步驟405，判斷用名字還是類型查找。若是用名字，轉入步驟406，否則轉入步驟 407 ; 步驟406，用名字過濾資料庫模板表；
步驟407，用類型查找資料庫模板表； 步驟408，判斷操作是否為更改內存及CPU。若是，轉入步驟409，否則轉入步驟 412 ; 步驟409，虛機伺服器管理，細節見圖IO及參照圖IO的描述，其過程大致是先轉入 步驟410的QVisor應用接口 ，再由步驟411在Qvisor主機151裡更改虛機內存及CPU等；
步驟410，從步驟409而來的虛機伺服器經理的更改虛機內存及CPU等功能會通過 web services的方式調用QVisor應用接口來更改虛機內存及CPU ;
步驟411，在QVisor主機151裡更改虛機內存及CPU的設置；
步驟412，非法操作，報錯。
連接代理 圖5是連接代理(connection broker)的處理流程圖。連接代理有兩種，PC連接 代理與手機連接代理。這裡的流程圖在觀念上並無不同。但PC連接代理由於要接通各種第 三方VDI產品，所以可能有不一樣的需求。 一般而言，移動連接代理由於手機應用啟動快， 所以等待後臺應用屏幕不是太大的問題。PC連接代理1211是組成VDI套接器的一部分。
步驟501，首先用戶以用戶名/密碼/應用名向伺服器請求登錄； 步驟502，判斷用戶是否通過UAAS認證授權，細節見圖6。若是，轉入步驟504，否
則轉入步驟503 ; 步驟503，告訴客戶端顯示錯誤信息； 步驟504，令虛機分派器141獲取虛機IP，細節見圖7 ; 步驟505，從應用列表查到應用ID ; 步驟506，連接應用，包括(a)告知虛機上的應用代理157用戶所訂閱的應用ID ; (b)等待，直到應用啟動或失敗；(c)通知MTP客戶端111應用已啟動，準備接收應用的第一 屏幕，或告以啟動失敗報錯。 圖6是統 一 認證授權系統(Unified Authentication and Authorization System, UAAS)的處理流程圖。UAAS用來執行kerberos安全通訊協議以及單點登陸(Single Sign-0n，SS0) 。 Kerberos主要用於計算機網絡的身份鑑別(Authentication)，其特點是用 戶只需輸入一次身份驗證信息就可以憑藉此驗證獲得的票據(ticket-granting ticket, TGT)訪問多個服務，即SSO。由於在每個客戶端Client和服務Service之間建立了共享密 鑰，使得該協議具有相當的安全性。
步驟601 ，用戶向伺服器請求虛機； 步驟602，電信伺服器得知用戶沒有票據於是向UAAS伺服器詢問客戶公司代理服 務器的URL ; 步驟603， UAAS伺服器告知客戶公司代理伺服器的URL (UniformResource Locator,統一資源位置)； 步驟604，電信伺服器要用戶把UAAS代理伺服器重定向為用戶公司代理伺服器的 URL ; 步驟605，用戶提交他的授權的憑證(credential);
步驟606， UAAS代理伺服器處理用戶公司的授權； 步驟607，公司(即LDAP的域組件Domain Component, DC)傳回用戶的票據TGT ; LDAP是輕量級電話簿接入協議的縮寫。 步驟608， UAAS代理伺服器將用戶ID和TGT傳到UAAS伺服器以完成授權； 步驟609， UAAS伺服器傳回代理伺服器的PGT ; 步驟610， UAAS代理伺服器傳回用戶的TGT和PGT ; 步驟611，用戶提交PGT給電信伺服器； 步驟612，電信伺服器傳回虛機的RDP URL ; 步驟613，用戶提交TGT並且在虛機上登錄。 虛機管理和分派 圖7是虛機分派器的處理流程圖。虛機分派器141建立對話期(session)，指派虛
機池管理器143取得最適合的虛機，並分派虛機給用戶。流程如下 步驟701，連接代理121把已認證授權了的用戶送到虛機分派器141 ; 步驟702，虛機分派器141為用戶建立一個對話期； 步驟703，判斷所請求的虛機是靜態或動態虛機。若是靜態虛機，轉入步驟704，否 則轉入步驟705 ;步驟704，取得已指定給用戶的靜態虛機信息；
步驟705，從虛機池取到最合適的虛機，細節見圖8 ; 步驟706，分派虛機給用戶(虛機啟動後， 一個應用代理(如圖1A)會在這個虛機 上自動激活)。 圖8給出虛機池管理器的處理流程圖。由圖可見，流程分為兩部分其一是不斷循 環的背景工作(background Worker)，檢查控制池的大小是否合乎政策管理器的要求。另一 則是提供各種服務(Services)給虛機分派器取得虛機、返回虛機、檢查虛機狀態、檢查池 的大小。能這樣做是因為手機虛機可以迅速從硬碟啟動，所以在背景工作的循環裡不會有 長時間的等待。不像在VDI裡的PC虛機，由於尺寸過大，其啟動常需管理員手動處理。具
斷虛機池管理器是否處於初始化時間。若是，轉入步驟802，否則轉入
體流程如下步驟801
步驟806 ;步驟802步驟803步驟804步驟805步驟806
入步驟817 ;步驟807步驟808步驟809:步驟810步驟811:步驟812:步驟813
812 ;步驟814步驟815步驟816步驟817
入步驟819 ;步驟818步驟819
則轉入步驟821 ;
步驟820步驟821
轉入步驟823步驟822步驟823
-個背景工作線程不斷檢查控制池的大小； ,從政策管理器取到負荷平衡或節能的政策，細節見圖9 ; ,判斷虛機池是否符合政策。若是，轉入步驟805，否則回到步驟804 ; ,新建、啟動、停止或刪除虛機(細節見圖10)以符合政策； ,判斷虛機池管理器的服務是否為取得虛機。若是，轉入步驟807，否則轉
，主機起始計數為0; ，模板起始計數為0;
，判斷下個主機是否已超過範圍。若是，轉入步驟816，否則轉入步驟810 ;
，虛機起始計數為0;
，判斷下個模板是否已超過範圍. 判斷下個虛機是否已超過範圍。
若是，轉入步驟808，否則轉入步驟812 ;
n， ，， ，，AHUKU^w口。若是，轉入步驟810，否則轉入步驟813;
，判斷所予虛機特性是否符合所需。若是，轉入步驟814，否則轉入步驟
,已找到虛機、模板和主機，把該模板裡的虛機減少一個； ,叫虛機管理伺服器更新虛機狀態； ,記錄並報錯"目前沒有適當虛機"；
,判斷虛機池管理器的服務是否為返回虛機。若是，轉入步驟818，否則轉 ,把所予主機的模板增加一個虛機，並更新狀態；
,判斷虛機池管理器的服務是否為檢查虛機狀態。若是，轉入步驟820，否 ,虛機池檢查員回報某個虛機狀態；
,判斷虛機池管理器的服務是否為檢查虛機池。若是，轉入步驟822，否則
12
圖9給出政策管理器(規則引擎)的處理流程圖。虛機池政策就是由規則引擎來 產生，而規則是程式設計師、客服人員或網管人員用高等語言(如Groovy)編寫而成。 步驟901，進入規則引擎； 步驟902，判斷操作是否為創建規則。若是，轉入步驟903，否則轉入步驟905 ; 步驟903 ，展示編輯屏幕； 步驟904，保存規則； 步驟905，判斷操作是否為導入(load)規則。若是，轉入步驟906，否則轉入步驟 908 ; 步驟906，展示規則列表； 步驟907，導入(load)規則至編輯屏幕； 步驟908，判斷操作是否為修改規則。若是，轉入步驟909，否則轉入步驟913 ; 步驟909，展示規則列表； 步驟910，導入(load)規則至編輯屏幕； 步驟911，修改規則； 步驟912，保存規則； 步驟913，判斷操作是否為刪除規則。若是，轉入步驟914，否則轉入步驟917 ; 步驟914，展示規則列表； 步驟915，當用戶選取某個規則，則高亮(Highlight)顯示該規則； 步驟916，刪除規則； 步驟917，非法操作，報錯。 圖10給出虛機伺服器管理器的處理流程圖。雖然QVisor平臺會有多個主機同時 運行，但管理這些主機的任務卻屬於虛機伺服器管理器145。因此虛機伺服器管理器145維 護主機的資料庫表，以及每個QVisor主機151所管轄的虛機，和這些虛機的狀態。虛機服 務器管理器提供許多虛機的操作，如下所述 步驟1001，進入虛機的操作； 步驟1002，判斷操作是否為克隆虛機。若是，轉入步驟1003，否則轉入步驟1006 ; 步驟1003，從資料庫以虛機ID查找主機； 步驟1004，通過QVisor應用接口 146來克隆虛機，細節見圖12 ; 步驟1005，進行克隆好的虛機對用戶的綁定； 步驟1006，判斷操作是否為啟動虛機。若是，轉入步驟1007，否則轉入步驟1011 ; 步驟1007，從資料庫以虛機ID查找主機； 步驟1008，從資料庫以用戶名查找虛機； 步驟1009，通過QVisor應用接口 146來啟動虛機，細節見圖13 ; 步驟1010，生成MTP傳輸地址； 步驟1011，判斷操作是否為停止虛機。若是，轉入步驟1012，否則轉入步驟1015 ; 步驟1012，從資料庫以虛機ID查找主機； 步驟1013，從資料庫以用戶名查找虛機； 步驟1014，通過QVisor應用接口 146來停止虛機，細節見圖14 ; 步驟1015，判斷操作是否為銷毀虛機。若是，轉入步驟1016，否則轉入步驟1020 ;
步驟1016，從資料庫以虛機ID查找主機；
步驟1017，從資料庫以用戶名查找虛機；
步驟1018，刪除虛機對用戶的綁定； 步驟1019，通過QVisor應用接口 146來刪除虛機，細節見圖15 ; 步驟1020，判斷操作是否為創建虛機。若是，轉入步驟1021，否則轉入步驟1024; 步驟1021，從資料庫選取可用的主機； 步驟1022，通過QVisor應用接口 146來創建虛機，細節見圖11 ; 步驟1023，進行創建好的虛機對用戶的綁定； 步驟1024，進行其它虛機狀態，虛機列表，虛機性能值的操作。 圖11-21詳述QVisor的應用接口。大部分的接口是資料庫與數據結構操作，但啟
動虛機則是作業系統(如Li皿x或MS Windows)的指令去運行QEMU與客戶作業系統；停止
虛機則是殺掉該進程。 圖11給出創建虛機的處理流程圖。 步驟1101，取得鏡像路徑與虛機的平臺名； 步驟1102，從資料庫查找平臺記錄以取得內核、內存、機器和執行文件信息；
步驟1103，查找最大t即Number(虛擬網卡的序列號)； 步驟1104，生成皿id和MAC號碼；UUID (Universal Unique Identifier)是指在一 臺機器上生成的數字，它保證對在同一時空中的所有機器都是唯一的。MAC(Media Access Control,介質訪問控制)地址是燒錄在Network InterfaceCard(網卡，NIC)裡的，也叫硬 件地址。 步驟1105，以下列參數皿id、 macft、平臺名、鏡像路徑、t即N咖ber、和虛機狀態二
POWERED-OFF (停止)，把虛機加入資料庫QVisor表中； 步驟1106，返回生成虛機。 圖12給出克隆虛機的處理流程圖。 步驟1201，如果要克隆的虛機沒有uuid則報錯； 步驟1202，如果要克隆的虛機狀態為運行(ru皿ing)則報錯； 步驟1203，用鏡像路徑與虛機的平臺名創建虛機； 步驟1204，如果虛機不能被創建則報錯； 步驟1205，把創建好的虛機加入虛機列表； 步驟1206，返回。 圖13給出啟動虛機的處理流程圖。 步驟1301，如果找不到虛機的皿id則報錯； 步驟1302，如果虛機狀態為運行(running)則報錯； 步驟1303，取得執行指令名、機器名、內存大小、內核路徑、鏡像名、鍵盤滑鼠驅 動； 步驟1304 ，取得MAC地址、tap 、國家、QEMU路徑和MTP埠 ； 步驟1305，激活進程用上述參數執行QEMU和其客戶作業系統(guestOS);執行 時使用Linux指令fork或Windows的createProcess 。這些指令為QEMU建立了一以個 子進程，該子進程又以參數方式將客戶作業系統運行起來。
步驟1306，把建好的虛機加入虛機列表； 步驟1307，返回。 圖14給出停止虛機的處理流程圖。 步驟1401，如果找不到虛機的uuid則報錯； 步驟1402，如果虛機狀態為停止(POWERED-OFF)則報錯； 步驟1403，取得虛機的進程ID (PID); 步驟1404，殺掉PID的進程；執行時使用Linux指令kill。 Kill會將QEMU連帶 客戶作業系統一起殺死。對Windows作業系統則用指令TerminateProcess 。 步驟1405，等待到進程完全被殺死； 步驟1406，把虛機狀態設為停止(POWERED-OFF);把MTP埠設為nil ; 步驟1407，返回。 圖15給出刪除虛機的處理流程圖。 步驟1501，如果虛機狀態為運行(running)則報錯； 步驟1502，如果找不到虛機的皿id則報錯； 步驟1503，把所予uuid的虛機刪除； 步驟1504，清理虛機內存空間； 步驟1505，從資料庫QVisor表刪除虛機紀錄； 步驟1506，從虛機列表刪除虛機； 步驟1507，返回。 圖16給出取得虛機狀態的處理流程圖。 步驟1601，判斷虛機是否在列表中。若是，轉入步驟1603，否則轉入步驟1602 ; 步驟1602，返回狀態=N/A ; 步驟1603，換到(switch to)找得虛機的狀態。若狀態是運行(RUNNING)，轉入步
驟1604，若狀態是停止(POWERED-OFF)，轉入步驟1605，若狀態是N/A，轉入步驟1606 ; 步驟1604，把虛機狀態設為運行(RUNNING); 步驟1605，把虛機狀態設為停止(POWERED-OFF); 步驟1606，把虛機狀態設為N/A ; 步驟1607，返回。 圖17給出取得虛機的處理流程圖。 步驟1701，用所予uuid把虛機從虛機列表中找到； 步驟1702，判斷是否在列表中找到了。若是，轉入步驟1703，否則轉入步驟1704 ; 步驟1703，把找到的虛機改為適當Web service格式並返回； 步驟1704，返回空值。 圖18給出取得虛機列表的處理流程圖。 步驟1801，把當前指針設為內部虛機列表的頭； 步驟1802，判斷當前指針是否為空值。若是，轉入步驟1806，否則轉入步驟1803 ; 步驟1803，把當前虛機改為適當Web service格式； 步驟1804，把虛機加入連接列表； 步驟1805，把當前指針設為內部虛機列表的下一個，然後轉入步驟1802 ;
步驟1806，返回連接列表。 圖19給出取得運行虛機列表的處理流程圖。 步驟1901，把當前指針設為內部虛機列表的頭； 步驟1902，判斷當前指針是否為空值。若是，轉入步驟1907，否則轉入步驟1903 ;
步驟1903，判斷當前當前虛機狀態是否為運行。若是，轉入步驟1904，否則轉入步 驟1906 ; 步驟1904，把當前虛機改為適當Web service格式；
步驟1905，把虛機加入連接列表； 步驟1906，把當前指針設為內部虛機列表的下一個，然後轉入步驟1902 ; 步驟1907，返回連接列表。 圖20給出取得停止虛機列表的處理流程圖。 步驟2001，把當前指針設為內部虛機列表的頭； 步驟2002，判斷當前指針是否為空值。若是，轉入步驟2007，否則轉入步驟2003 ;
步驟2003，判斷當前當前虛機狀態是否為停止。若是，轉入步驟2004，否則轉入步 驟2006 ; 步驟2004，把當前虛機改為適當Web service格式；
步驟2005，把虛機加入連接列表； 步驟2006，把當前指針設為內部虛機列表的下一個，然後轉入步驟2002 ; 步驟2007，返回連接列表。 圖21給出取得虛機性能的處理流程圖。 步驟2101，以請求的虛機或/和主機值進入； 步驟2102，判斷虛機是否為運行狀態。若是，轉入步驟2103，否則轉入步驟2106 ; 步驟2103，取得所予虛機的進程ID (PID); 步驟2104，用pid調用性能代理，細節見圖22 ; 步驟2105，返回所予虛機或整體主機的CPU、內存、和心跳信息； 步驟2106，報錯返回。 QVisor平臺 圖22-25是QVisor平臺的特性說明。由於本發明把手機作業系統運行在QEMU的 模擬器上，所以優化QEMU或子進程來提高性能就非常重要。另一方面，本發明通過一些獨 特的調試工具組合，形成了手機作業系統虛擬化的預處理器(圖25)，具體說明如下
圖22給出性能代理的處理流程圖。性能代理154運行在QVisor主機151的Li皿x 作業系統平臺上。手機作業系統本身可能沒有相關CPU/內存使用率的系統接口。即使有， 也只與模擬的CPU和內存有關，但不是物理的。因此在Li皿x上運行性能代理154以監測 各個手機作業系統的性能以及虛機的心跳。性能代理執行Li皿x指令如"free"， "top"， "vmstat"，"ps aux"以取得CPU和內存使用統計數字，還有進程狀態。如果有進程沒有回 應，性能代理有能力將之殺死。流程如下
步驟2201，以pid或主機值進入； 步驟2202，判斷進程是否還在運行。若是，轉入步驟2203，否則轉入步驟2205 ;
步驟2203，執行Linux指令行ps，top，或vmstat ;ps是Linux的指令，用來顯示進程狀態，類似於Windows的任務管理器。如果再附加參數ux可以得知運行進程的CPU與內 存使用率。Top是Li皿x的另一指令，有類似顯示進程狀態的功能，可以互動方式動態顯示。 vmstat則能顯示更多的內核線程、IO、虛擬內存、CPU Trap的統計信息；相對於Windows XP 與Vista，進程狀態則可用Windows Management Instrumentation (麗I)裡的函數Col lectingHighCPUUtilizationEvents來取得。 步驟2204，返回所予進程或整體主機的CPU、內存、和心跳信息；
步驟2205，報錯返回。 圖23給出共享QEMU和內核的處理流程圖。由於每個客戶作業系統(guest0S)原 本都有自身內核的內存及QEMU重複所佔的內存，這些浪費的內存如能共享，則能將節省的 內存用來給更多的客戶作業系統。再加上手機作業系統不大，又可與系統數據完全分離，一 個只能運行2-4個PC虛機的雙核4G內存的X86主機，大約能運行60或更多個(由於共 享)手機虛機。具體流程如下
步驟2301 ，賦予QEMU和內核的物理內存； 步驟2302，判斷能否打開內核和QEMU文件。若能，轉入步驟2304，否則轉入步驟 2303 ; 步驟2303，文件打不開，報錯； 步驟2304，利用lseek找到兩個文件的尺寸(size);並利用ftok計算共享 內存的鍵值(key) ;lseek是C程序語言庫的函數，可利用文件的位移量找出文件長度； ftok 函數則為Li皿x的系統函數，用以獲取key的值來創建或者打開信號量，共享內存和 消息隊列； 步驟2305，判斷Key的值是否為-1。若是，轉入步驟2306，否則轉入步驟2307 ;
步驟2306，報ftok錯； 步驟2307，計算Shmat所要的參數Loading address = ram base+((physical— page_descriptor+start_loading_address) & target—page—mask)+kernel_QEMU_load_ address ;意即客戶作業系統的絕對內存地址是下列三個量的總和(l)ram的基礎地址， (2)物理內存頁的翻譯過後的絕對地址，和(3)內核/QEMU的導入地址；
步驟2308， Shmget 是Linux的系統函數，用以獲得或創建一個IPC共享內存區 域，並返回相應的標識符。這裡判斷Shmget (key, size, IPC_Creat)的返回值是否EEXIST。 若是，轉入步驟2309，否則轉入步驟2311 ; 步驟2309，共享內存已存在(主叫的子進程並非該主機上的第一個進程)；
步驟2310，Shmat是Linux的系統函數，為子進程附上(Attach)它的共享內存， 這樣主叫的子進程就可以利用Shmat(shm_id， loading_address)與第一個進程共享內存；
步驟2311，主叫的子進程是該主機上的第一個進程，返回。 步驟2301-2311給出的是Linux的內核共享解決方法。但如果主機是Windows XP 或Vista，則要用到Win32開發環境裡有關內存管理的系統服務，將客戶作業系統及QEMU兩 個執行文件當成同一個子進程，利用CreateFileM即ping的函數取得文件的handle。此 後，其它的子進程則以OpenFileM即ping的函數及第一次取得的handle來共享第一個子 進程的內存。 圖24給出改進QEMU Soft匪U的處理流程圖。在QVisor的設置下，內存管理通常是用QEMU的軟體內存管理單元(Memory Management Unit，匪U)。軟體匪U模擬了匪U的 功能，例如用軟體來實施地址翻譯和內存保護。當客戶應用通過匪U翻譯而使用到一個內 存位置時，QEMU會替一個作業系統區域，按位運算(mask)列表檢索的結果，把所需虛擬地 址轉換成物理地址。這樣的改進可以使內存接入快十倍。具體流程如下
步驟2401 ，進入QEMU Sof t匪U ; 步驟2402，判斷操作是否為創建虛機。若是，轉入步驟2403，否則轉入步驟2404 ;
步驟2403，賦予客戶作業系統(guest OS) —個內存區； 步驟2404，判斷操作是否為客戶作業系統地址翻譯。若是，轉入步驟2405，否則轉 入步驟2409 ; 步驟2405，頁表查找該客戶作業系統虛擬內存區的開始； 步驟2406，判斷操作是否找到了虛擬內存區的地址。若是，轉入步驟2408，否則轉 入步驟2407 ; 步驟2407，超出範圍，報錯； 步驟2408，把頁表中與虛擬地址對應的物理地址設為Guest_OS_offset ; 步驟2409，判斷操作是否其它非區翻譯操作。若是，轉入步驟2411，否則轉入步驟
2410 ; 步驟2410，執行其它操作(例如內存保護)； 步驟2411 ，把Guest_OS_of f set "按位運算Mask"到彙編指令的目標地址 (destination address)。 圖25給出I/O設備調試預處理器的流程圖。如果手機所支持的I/O device在 數據中心太慢，可用數據中心的合適設備取代，例如手機SD card卡改為可掛起的硬碟， 64M內存改為129M。如果客戶作業系統的源碼完全開放且以高等語言如C或java(像谷歌 gPhone的Android)方式提供，則可以將之重新編譯，調試1/0，使其直接運行在X86主機上 而不經過QEMU模擬器，這樣性能就可大幅提高。否則就需要安裝業界提供的手機開發板及 BSP (board supportpackage例如Samsung 2410)做板上調試。I/O驅動與QEMU模擬的一 般1/0硬體來調試的時候，通常是用WinCE或WinMobile Platform Builder,而對Android 則是基本的"make"工具。調試的時候，I/O驅動與QEMU的周邊設備模擬器都可能要修改。 如果這些開發工具都不具備，則需述諸逆向工程。由此可見，這裡的預處理器能適應不同開 放程度的手機作業系統。具體流程如下 步驟2501，判斷設備是否大小合適。若是，轉入步驟2503，否則轉入步驟2502 ;
步驟2502，改為數據中心的大型設備(例如SD卡改為硬碟，64M RAM改為128M 等)，然後進行步驟2503 ; 步驟2503，判斷是否手機作業系統源碼完全開放。若是，轉入步驟2504，否則轉入 步驟2505 ; 步驟2504，將源碼重新編輯，調試I/O設備，使該作業系統可直接運行在X86主機 上； 步驟2505 ，安裝手機板上(on-board) BSP工具和客戶作業系統平臺構建 (platform building)工具(若有)； 步驟2506，判斷是否客戶作業系統有平臺構建工具。若有，轉入步驟2507，否則轉
18入步驟2508 ; 步驟2507，啟動客戶作業系統平臺構建工具； 步驟2508，以逆向工程取得客戶作業系統10 IRQ號碼以及中斷(interrupt)地 址； 步驟2509，完成板上周邊設備驅動調適過程；
步驟2510，調試QEMU所模擬的設備驅動； 步驟2511，判斷是否QEMU能運行客戶作業系統。若是，轉入步驟2512，否則轉入 步驟2506 ; 步驟2512， QEMU調試完成。 圖26，27，28是有關移動終端協議(Mobile Terminal Protocol, MTP)的部分流 程圖。MTP是基於VDI的終端協議技術(例如開源的VNC，微軟的RDP，或思傑的ICA)，並適 應本發明的VMI的需求而改進。基本的終端協議技術在此不贅，但手機的需求是屏幕適配 (圖26)，智能傳屏(圖27)，與音頻和GPS數據的傳輸(圖28) 。 MTP客戶端的實現較為繁 復，例如WinMobile手機要用C++， J2ME手機要用java，而iPhone手機要用Safari腳本。
圖26給出適配手機屏幕MTP伺服器的部分流程圖。鏡像操作在伺服器端進行，一 方面是利用伺服器的強大功能，另一方面，壓縮必在傳屏之先進行。 步驟2601，判斷是PC虛機還是手機虛機。若是PC虛機，轉入步驟2602，若是手機 虛機，轉入步驟2603 ; 步驟2602，屏幕可以是原始PC屏幕，或是申請人中國專利公開號CN101231731A所 揭示技術所適配的PC屏幕，轉入步驟2610 ;
步驟2603 ，取得手機請求http頭； 步驟2604，判斷是否資料庫包含該手機的信息。若是，轉入步驟2606，否則轉入步 驟2605 ; 步驟2605，報錯並在伺服器日誌中記錄，這樣未來可以更新手機信息的資料庫。目 前無法適配。轉入步驟2610 ; 步驟2606，在伺服器的資料庫裡找到該款手機的屏幕的高度與寬度。比較虛機的 高度與寬度； 步驟2607，判斷是否需要旋轉90度。若是，轉入步驟2608，否則轉入步驟2609 ;
步驟2608， changeDisplaySetting(高，寬)成為changeDisplaySetting(寬， 高)； 步驟2609，按比例縮放屏幕鏡像； 步驟2610，將屏幕送給手機。 圖27給出智能傳屏的伺服器端部分流程圖。 步驟2701，取得屏幕鏡像； 步驟2702，比較前一幀以識別鏡像改變； 步驟2703，識別文本文字； 步驟2704，經由數據通道傳送文字； 步驟2705，經由鏡像通道傳送其它方塊區的改變鏡像； 步驟2706，若是第一屏，則傳送整屏；
步驟2707，返回。 圖28給出音頻與衛星定位(GPS)數據處理器的手機端部分流程圖。至於伺服器 端的音頻邏輯與手機端類似，在此不贅。伺服器端只接收GPS數據。 步驟2801，判斷是否衛星定位或音頻數據。若是衛星定位數據，轉入步驟2802，若 是音頻數據轉入步驟2803 ; 步驟2802，經由數據通道傳輸GPS衛星定位經諱度數據，再轉入步驟2808 ;
步驟2803，與伺服器談判(negotiate)音頻標準(按傳收雙方頻寬、手機配備而從 多種音頻加碼器談判取得最優方法)； 步驟2804，判斷是否談判成功。若是，用協議後的標準，轉入步驟2805，否則用 G. 722標準，再轉入步驟2805 ; 步驟2805，判斷是傳出或傳入。若是傳出，轉入步驟2806，若是傳入，轉入步驟 2809 ; 步驟2806，用談判後的標準來加碼；
步驟2807，從音頻通道傳出加碼後的音頻；
步驟2808，經由多通道將數據傳到伺服器端；
步驟2809 ，從音頻通道傳入數據；
步驟2810，用談判後的標準來解碼；
步驟2811，消除回音。 圖29給出應用代理的流程圖。應用代理是一個運行在客戶作業系統上的程序，掌 控應用的啟動。與連接代理相似，應用代理也有兩種，PC應用代理131與移動應用代理157。 流程圖在觀念上並無不同。但PC應用代理由於要接通各種第三方VDI產品，所以可能有不 一樣的需求。例如PC應用代理可以分別與思傑(Citrix)的XenA卯，微軟公司的App-V，申 請人的TranSOD產品協同作業。PC應用代理是組成VDI套接器的一部分，可以通過申請人 申請公開號為CN101231731A的一種應用虛擬化在公網上的通用商務方法把PC應用虛擬化 後以手機來點播。 步驟2901，虛機啟動後，將自身初始化； 步驟2902，以已知虛機IP位址及用戶ID，向連接代理請求應用的ID ;
步驟2903，從連接代理收到應用的ID ; 步驟2904，判斷是否默認的應用。若是，轉入步驟2905，否則轉入步驟2906 ;
步驟2905，啟動默認應用，呈現歡迎屏幕； 步驟2906，應用代理取得手機或PC應用執行文件路徑並將之啟動；
步驟2907，判斷是否應用啟動成功。若是，轉入步驟2908，否則轉入步驟2909 ;
步驟2908，通知連接代理應用已啟動，連接代理再告訴MTP客戶端lll準備接收應 用第一屏幕； 步驟2909，通知連接代理應用啟動失敗，連接代理再告訴MTP客戶端111報錯。
圖30給出應用啟動與關閉時序圖。圖30可用於解釋PC應用和手機的應用。例 如連接代理可看成是PC連接代理或手機連接代理；應用代理可看成是PC應用代理或手機 應用代理，其餘類推。如果從手機的角度來看，該時序圖解釋了MTP客戶端111，手機連接代 理1212，在QEMU裡的MTP伺服器153，手機虛機156，手機應用代理157之間的時序關係應用代理157啟動連接某虛機的主機後，處於等待中； MTP客戶端111發送用戶身份和應用名給手機連接代理1212 ; 手機連接代理1212驗證用戶身份後，取得該虛機，並向其主機發送應
虛機的主機發送應用名給手機應用代理157 ;
手機應用代理157啟動應用。若成功，轉入3006。否則，轉入3008 ; 應用啟動成功，通知MTP伺服器153傳送應用界面； MTP伺服器153連接MTP客戶端111成功，顯示虛機上的應用界面； 應用啟動失敗，通知手機連接代理1212 ; 手機連接代理1212通知MTP客戶端111應用啟動失敗； 客戶端111斷開，通知手機連接代理1212 ;
手機連接代理1212通知虛機的主機； 虛機的主機通知手機應用代理157 ;
手機應用代理157關閉應用。
在實際的部署環境中，完全有可能將虛機交換機12與數據管理中心14全部署於 電信公司、或全部署於企業內、或將虛機交換機12部署於電信，數據管理中心14部署於企 業。涉及本發明的1/0調試預處理器用於任何手機型號的作業系統虛擬化均可。
根據上述流程的描述可以得出，採用以上移動虛擬化的基礎設施，一方面為企業 和移動電信提供了一種在移動網上訂閱應用軟體的方法，該方法是在手機作業系統虛擬化 的基礎上，創建了移動終端協議的客戶端，讓用戶可接入、取得虛機、運行應用、得到手機應 用屏幕、因而可以運行任何手機作業系統及手機應用軟體。另一方面，由於套接第三方VDI 產品，也可在手機上運行任何PC作業系統及PC應用軟體。 綜上所述，本發明結合了手機板上調試及QEMU模擬技術，作業系統虛擬化技術和 虛擬桌面的基礎設施技術，為企業及電信運營商提供了一種移動虛擬化的基礎設施。
前面提供了對較佳實施例的描述，以使本領域內的任何技術人員可使用或利用本 發明。對這些實施例的各種修改對本領域內的技術人員是顯而易見的，可把這裡所述的總 的原理應用到其他實施例而不使用創造性。因而，本發明將不限於這裡所示的實施例，而應 依據符合這裡所揭示的原理和新特徵的最寬範圍。步驟3001步驟3002步驟3003
用名；步驟3004步驟3005步驟3006步驟3007步驟3008步驟3009步驟3010步驟3011步驟3012步驟3013
2權利要求
一種移動虛擬化的基礎設施，其特徵在於，包括基礎平臺，包括多個主機，其中每一主機上使用運行在主機作業系統上的QEMU進程虛擬至少一個具有客戶作業系統及內存的手機虛機；數據管理中心，管理所述基礎平臺產生的手機虛機並向用戶分派所述手機虛機；虛機交換機，連接所述基礎平臺及所述數據管理中心，所述虛機交換機根據來自手機客戶端的用戶請求，讓用戶選取手機虛機及運行在手機虛機上的手機應用；手機客戶端，運行於用戶的手機上，以發送手機虛機及手機應用請求，以及基於移動終端協議的伺服器，用於與手機客戶端交互。
2. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，所述基礎平臺進一步包括使客戶作業系統的QEMU進程與內核共享主機內存的裝置。
3. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，所述基礎平臺進一步包括用以獲取子進程和/或主機的性能狀態的性能代理器。
4. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，還包括用以改善QEMU的軟體匪U的裝置，其中頁表查找到客戶作業系統內存區虛擬地址所對應的物理地址，再將該物理地址當成偏移量來按位運算彙編指令中的地址。
5. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，所述基礎平臺進一步包括以客戶作業系統源碼和平臺調試工具的開放程度來處理虛擬化的I/O設備調試預處理器，其中如果完全源碼開放就重新編譯使能直接運行在x86平臺上，如果平臺調試工具開放則在QEMU上用工具進行I/O驅動調試，否則用硬體開發板及BSP輔助逆向工程。
6. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，所述基於移動終端協議的伺服器運行於所述基礎平臺的主機作業系統中。
7. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，所述基於移動終端協議的伺服器進一步包括在屏幕傳送前將鏡像按比例縮放、旋轉、壓縮以進行屏幕適配的裝置；在屏幕傳送前將之辨識鏡像改變、辨識文字，然後只傳文字及改變方塊區的裝置。
8. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，所述手機客戶端包括將GPS經緯度從數據通道傳給所述伺服器，支持回音消除及按傳收雙方頻寬、手機配備而從多種音頻加碼器談判取得最優方法的裝置。
9. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，所述數據管理中心進一步包括虛機分派器，建立對話期、從虛機池取到最合適的虛機、分派虛機給手機客戶端；虛機池管理器，以多種服務來選取虛機池中的合適虛機、返回虛機到虛機池裡、檢查虛機狀態，並以背景工作的不斷檢查虛機池狀態來符合一規則引擎的規則；虛機伺服器管理器，管理多個主機並使用平臺應用接口與所述基礎平臺交互；以及管理控制臺，用以統一以下資源的任意組合管理人員、組織、模板、虛機、應用、套餐和伺服器。
10. 根據權利要求9所述的移動虛擬化的基礎設施，其特徵在於，所述規則引擎包含用來控制虛機的生成與銷毀，啟動與停止的規則，其中所述規則可由管理員以高等計算機語言創建、編輯、保存、刪除。
11. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，所述虛機交換機包括連接代理，提供手機客戶端接入通道，並向手機客戶端傳輸桌面屏幕與應用屏幕。
12. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，所述連接代理的手機客戶端接入進一步包括統一認證與授權以完成kerberos安全協議與單點登錄。
13. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，所述虛機交換機包括人員與團體管理資料庫、應用與套餐管理資料庫、以及虛機伺服器與模板管理資料庫。
14. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，還包括用以進行模板管理的裝置，其使用模板綁定以下設置信息的一種或幾種虛機與內存、CPU、應用、主機、手機作業系統。
15. 根據權利要求1所述的移動虛擬化的基礎設施，其特徵在於，還包括VDI套接器，其中所述虛機交換機經由所述VDI套接器套接至外部VDI產品，以讓用戶選取運行在外部VDI產品中的PC虛機及PC應用。
16. 根據權利要求15所述的移動虛擬化的基礎設施，其特徵在於，所述VDI套接器進一步包括PC連接代理，告知外部VDI產品用戶登錄後所取得的虛機要運行什麼應用，等待PC應用代理激活了該應用後，再通知手機客戶端準備用移動終端協議接收應用屏幕；PC應用代理，預先安裝在外部VDI產品的虛機上，當虛機被啟動，應用代理自己被激活，再激活所指定的PC應用，然後告訴PC連接代理應用成功與否；若成功，則將應用屏幕傳至手機客戶端；當手機客戶端斷開，PC應用代理就關閉應用。
17. —種移動虛擬化的基礎平臺，包括多個主機，其中每一主機包括運行在主機作業系統上的至少一 QEMU模擬器，以虛擬至少一個具有客戶作業系統及內存的手機虛機；使客戶作業系統的QEMU進程與內核共享主機內存的裝置；獲取子進程和/或主機的性能狀態的性能代理器；基於移動終端協議的伺服器，用於與手機客戶端交互。
18. 根據權利要求17所述的移動虛擬化的基礎平臺，其特徵在於，還包括用以改善QEMU的軟體匪U的裝置，其中頁表查找到客戶作業系統內存區虛擬地址所對應的物理地址，再將該物理地址當成偏移量來按位運算彙編指令中的地址。
19. 根據權利要求17所述的移動虛擬化的基礎平臺，其特徵在於，還包括以客戶作業系統源碼和平臺調試工具的開放程度來處理虛擬化的I/O設備調試預處理器，其中如果完全源碼開放就重新編譯使能直接運行在x86平臺上，如果平臺調試工具開放則在QEMU上用工具進行I/O驅動調試，否則用硬體開發板及BSP輔助逆向工程。
全文摘要
本發明公開了一種移動虛擬化的基礎設施及基礎平臺，在一基礎平臺上運行主機作業系統並在其上利用QEMU進程虛擬至少一個具有客戶作業系統及內存的手機虛機，數據管理中心管理基礎平臺產生的手機虛機並向用戶分派手機虛機。在手機客戶端與伺服器之間基於諸如RDP的移動終端協議進行通信。通過虛機交換機的特徵，創建了一個機制可利用本發明的VMI移動虛擬化基礎設施獲取適配的手機屏幕以及廉價的虛機。在一個較佳實施例中，還可以套接第三方VDI開發商的產品(例如Citrix XenDesktop，LeoStream，etc.)，從而獲取PC虛機的屏幕。並且由於採用虛機管理方法，企業或移動電信管理員可管理成千上萬虛機。
文檔編號H04W88/04GK101754466SQ20081020428
公開日2010年6月23日 申請日期2008年12月10日 優先權日2008年12月10日
發明者湯傳斌 申請人:運軟網絡科技(上海)有限公司;湯傳斌