移动虚拟化的基础设施以及基础平台的制作方法

专利名称：移动虚拟化的基础设施以及基础平台的制作方法
技术领域：
本发明涉及一种移动虚拟化的基础设施，该移动虚拟化的基础设施涉及手机用户如何获取在机房里的虚机(包括手机虚机及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日
发明者汤传斌 申请人:运软网络科技(上海)有限公司;汤传斌