WO2012106980A1 - 多维智能服务点虚拟桌面方法及基础架构 - Google Patents

Description

多维智能服务点虚拟桌面方法及基础架构 技术领域

本发明涉及计算机虚拟化技术及应用领域， 更具体地讲， 涉及多维智能服务 点虚拟桌面基础架构。 背景技术

随着个人计算机的普及， 用户在软硬件购买、 升级及维护等方面的开支越来 越高， 管理和维护越发复杂， 安全问题日益凸显， 给企业、组织和个人带来诸多困 扰。 另一方面， 网络技术的发展日新月异， 虚拟化技术发展势头强劲， 出现了桌面 虚拟化的趋势， 即采用一种客户机-服务器（c- S)计算模型将个人计算机桌面环境 与物理硬件分离，在本地计算机显示和操作远程计算机桌面，而在远程计算机执行 程序和储存信息。桌面虚拟化为传统的个人计算机所带来的问题提出了一种有效的 解决方案。

虚拟桌面基础架构 （Virtual Desktop Infrastructure, 简称 VDI )特指使桌 面虚拟化成为可能的服务器计算模型，通过将所需的硬件和软件系统结合在一起来 支持虚拟化环境。 桌面操作系统和应用程序运行在数据中心的服务器上的虚拟机 (后简称虚机） 中， 用户可以通过网络从 PC、 上网本、 瘦终端等各种终端设备上 访问虚拟桌面和应用程序， 并能够获得完整 PC的使用体验。 VDI管理软件的核心 是通过一系列的策略对数据中心大量虚机所形成的虚机池进行集中管理，并利用传 输协议将桌面交付给终端用户。 威睿（VMWare) 公司的 ESXi， 思杰（Citrix) 公 司的 Xen， 微软 （Microsoft ) 的 Hyper-V都可用做 VDI的基础虚拟技术。 这些公 司也纷纷推出了自己的 VDI产品，分别为威睿的 VMWare View,思杰的 XenDesktop, 微软 VDI套装软件。

VDI进入市场多年， 但推行一直很困难， 主要原因有二。其一是性能问题， 尤 其是网络性能问题。 ESG (Enterprise Solutions Group)全称瀚思资讯集团有限公 司研究发现， 用户的很多担忧都是围绕网络性能展开， 数千张桌面图像从终点站 (即， 桌面、终端等)迁移到数据中心， 包括之后进行处理应用和数据请求的后续任 务， 这些对网络性能的影响是不言而喻的。 其二是价格问题， VDI和传统的终端服 务 (TS)在功能上有一定的相似性，虽然 VDI有可以为每个终端用户提供一个独立的 虚机， 不受其它用户或系统的影响的优势； 但相较而言， 价格昂贵。如何采用一种 有效的技术方案来提高 VDI的规模经济效益，使得当用户数增加到一定程度时， VDI 表现出比 TS更好的价格优势， 也是用户极为关注的问题。 尽管如此， 目前已有的 VDI解决方案中， 还没有一种能针对这两种问题的有效解决方法。 因而， 提出一种 多维智能可管理的服务点虚拟桌面方法，有效解决上述问题，成为本领域发展的关 键。 发明内容

本发明揭示了一种多维智能服务点虚拟桌面基础架构， 更准确地说， 是一种 结合多种软硬件及网络资源来支持虚拟化环境，在后台服务点对虚机、实机及虚拟 应用程序资源进行集中管理（相较于虚机而言， 这里的实机指物理的计算机）， 将 虚拟桌面按需交付给终端用户， 可提供渗透性服务和智能会话 （Session) ， 并随 着使用人数增多服务成本明显下降， 产生规模经济效益的虚拟桌面基础架构。

为了实现上述发明目的， 本发明采用的设计是：

将服务管理及电信网络管理的理念引入到虚拟桌面基础架构中。 系统由两维 构建， 横向的一维由客户设备、 访问接入点、业务交换点、 后台服务点组成， 构成 了虚拟桌面的传输路径； 纵向的一维由公司操作系统、 公司应用、用户应用、用户 数据和设置组成， 将虚机分成若干易于管理的层。 通过访问接入点， 业务交换点、 后台服务点对整个架构进行管理，其中后台服务点生成虚机和虚拟应用程序并对虚 机 /实机 /应用进行集中管理，访问接入点和业务交换点主要负责提供虚拟桌面传输 的网络管理和服务， 服务具有渗透性， 并提供统一编程接口， 可与第三方集成。

后台服务点通过将实机 /虚机纳入到统一的体系， 使得用户可以根据需要来灵 活地选择使用实机或虚机。一般而言，对于一些高密度媒体的高清传输， 可选择使 用实机。实机的管理通过实机管理中心来完成，虚机的管理通过虚机管理中心来完 成， 虚拟应用程序的管理通过虚拟应用管理器来完成。 通过将 SOD ( Service on Demand)客户端安装在虚机上来实现虚机和虚拟应用程序的整合， SOD的服务器端 一般安装在实机上。通过虚拟工作空间对分层应用进行管理。并采用版本树的方法 来实现虚机模板的升级更新。业务交换点主要提供呼叫连续和业务交换服务，虚机 /实机交换功能， 同时提供负载均衡、 规则和策略引擎、 服务监控、 SIP代理服务 以及统一编程接口。访问接入点主要提供远程访问管理和连接服务，采用扩展的连 接代理将实机和虚机连接在一起，并具有注册认证和单点登录功能， 同时提供负载 均衡、 规则和策略引擎、 服务监控、 SIP代理服务以及统一编程接口。

桌面的传输采用 SIP协议和远程传输协议（可以是 Spice协议，也可以是 RDP 和 ICA协议， 下面分别予以介绍） 。 会话初始协议 （SIP) 是 IETF于 1999年提出 的一个基于文本的应用层信令控制协议，用于创建、修改和释放一个或多个参与者 的会话。 独立计算环境简单协议 （SPICE) 是红帽 （Red Hat) 公司收购 Qumranet 后获得的虚拟技术，是一种专门设计应用于虚拟环境的自适应远程传送协议， 旨在 为今天的带宽密集型应用（如多媒体、 VoIP)提供无缝的用户体验， 使用户在使用 虚拟桌面系统时感受到与使用物理桌面系统同样的体验。 Red Hat已开放了其 SPICE 托管虚拟桌面协议的源代码 SIP协议用于创建、更改和结束会话（Session)， Spice 协议用来传送虚拟桌面。 远程桌面传输协议（RDP) 是微软公司开发的一种用于连 接本地客户端到终端服务器， 保持两者之间会话的协议。 SIP协议可以控制信令， 使得一个用户可以获得多个会话从而可以同时使用多个虚机，其内在的时间机制可 以实现多个人同时使用一个虚机， 实现智能会话。 SIP可以建立端对端的覆盖网 (Overlay) ， 智能调度资源， 以涵盖由 Core (核心网） ， Edge (边缘网络） 到用 户设备组成的 overlay的网络，使得虚拟桌面的传输安全快速。在一较佳实施例中， 用于证券公司， 一个会话横跨多个屏幕显示。 在一较佳实施例中， 用于工厂， 多 个会话显示在一个大的屏幕上。

在虚机池管理部分， 引入了备用池和弹性池的方法。 为了解决教育培训机构 课间十分钟换课程的问题， 通过采用 l inked-clone技术生成与主虚机池相对应的 备用池， 并将备用池设置成 suspend (暂停）状态， 当课间需要快速更换课程时， 可以使用备用池来完成课程的绑定。备用池的使用包括备用池的生成、使用、优化 及退出。弹性池通过设置初始值、最大值、 门限值及预留值， 设定这些值之间的大 小关系， 并采用一定的算法来确定一定的规则， 以充分地利用虚机资源， 建立用户 和虚机之间的灵活取用关系。

具体而言， 本发明提出如下的技术方案：

根据本发明的一实施例， 提出一种多维智能服务点虚拟桌面基础架构， 包括: 后台服务点、业务交换点、访问接入点和客户设备。后台服务点在后台产生虚机和 虚拟应用程序， 后台服务点对虚机、虚拟应用程序、实机进行集中控制并分派给用 户； 业务交换点连接到后台服务点，业务交换点提供呼叫连续和业务交换服务，把 经交换后的实机 /虚机请求送到后台服务点， 同时控制业务交换服务； 访问接入点 连接到业务交换点，访问接入点提供远程访问管理和连接服务， 同时控制访问接入 服务； 客户设备连接到后台服务点、业务交换点和访问接入点， 客户设备选自下述 之一： 个人电脑、 笔记本电脑、 上网本、 手机、 手持终端。

其中后台服务点包括实机管理中心、 虚机管理中心、 虚拟应用管理器、 虚拟 工作空间管理器和虚拟化基础平台。实机管理中心管理后台的实机并向用户分派实 机；虚机管理中心管理后台的虚机并向用户分配虚机；虚拟应用管理器生成并管理 后台的虚拟应用程序并建立虚拟应用程序和虚机的结合；虚拟工作空间管理器对虚 拟应用进行分层管理；虚拟化基础平台包括多个主机，其中每一主机上使用基于内 核的虚机 （KVM)对硬件平台进行虚拟化。

其中实机管理中心包括实机连接管理器、 实机状态管理器、 代理控制器、 实 机列表、实机应用列表和使用情况报表。实机连接管理器接受用户使用实机的请求， 检査实机的状态， 将用户将要使用的 application (应用）消息通过代理控制器发 送给代理，并返回给业务交换点；实机状态管理器负责监控计算机的状态及状态的 转换； 代理控制器负责接收代理发送的消息， 发送操作应用的指令给代理， 并检查 代理发送的 heart beat消息以作出是否关闭实机的判断； 实机列表是用户可以注 册与自己的账号绑定的实机到实机列表中；实机应用列表是用户指定的使用的应用 程序的列表； 使用情况报表用于统计用户使用实机和应用的情况。

其中虚拟化基础平台包括基于终端协议的 Spice服务器、 会话发起协议 SIP 服务器， 所述 Spice服务器和会话发起协议 SIP服务器用于与客户设备交互。

其中业务交换点包括虚机交换器和实机交换器和业务交换服务控制器。 虚机 交换器和实机交换器根据用户的请求，连接到请求响应的虚机管理中心或者实机管 理中心； 业务交换服务控制器提供包括呼叫接续服务、 业务交换服务、 负载均衡、 规则和策略引擎、 Overlay管理、 服务监控、 SIP服务以及服务接口。

其中虚机交换器包括座位与教室管理数据库。 其中访问接入点包括 RAS服务器和连接代理。 RAS服务器管理远程访问并当用 户在防火墙外则为用户建立 VPN连接;连接代理提供客户端接入通道并向客户端传 输桌面屏幕与应用屏幕， 采用扩展的体系， 同时为后台的虚机和实机提供连接。

其中访问接入点进一步包括访问接入服务控制器， 为访问接入提供网络服务， 并提供统一编程接口与第三方集成。

其中访问接入服务控制器包括负载均衡器、 服务监控器、 SIP代理服务器、 Overlay管理器和管理控制台。负载均衡器提供负载均衡服务； 服务监控器对服务 请求进行监控和统计； SIP代理服务器接收虚拟桌面请求， 决定将这些请求传送到 何处， 并且将它们传送到下一服务器； Overlay管理器提供 SIP overlay管理； 管 理控制台提供管理控制界面。

其中连接代理提供客户端接入通道进一步包括根据用户的登录信息在认证中 心生成凭据， 并对凭据进行加密， 以完成统一认证授权与单点登录 （sso) 。

根据本发明的一实施例， 提出一种多维智能服务点虚拟桌面方法， 该方法包 括： 使用访问接入点、业务交换点、后台服务点控制虚拟桌面的生成、分派以及传 输。其中后台服务点在后台产生虚机和虚拟应用程序， 后台服务点对虚机、虚拟应 用程序、实机进行集中控制并分派给用户； 业务交换点连接到后台服务点，业务交 换点提供呼叫连续和业务交换服务，把经交换后的实机 /虚机请求送到后台服务点， 同时控制业务交换服务；访问接入点连接到业务交换点，访问接入点提供远程访问 管理和连接服务， 同时控制访问接入服务。

其中该方法进一步包括基于客户设备和用户的 SIP进行认证注册,在认证注册 时进行机器能力的协商，其中客户设备连接到后台服务点、业务交换点和访问接入 点， 客户设备选自下述之一： 个人电脑、 笔记本电脑、 上网本、 手机、 手持终端。

其中该方法进一步包括使用 SIP协议创建会话并建立客户设备和后台服务点 之间的连接；后台服务点査询客户设备的能力；启动 Spice协议将虚拟桌面屏幕从 后台服务点传送到客户设备上； 屏幕传送完毕后， 使用 SIP协议结束会话。

其中该方法进一步包括通过 SIP代理服务器的时间机制将多个会话进行汇聚， 以使多个用户使用一个虚机； 通过 SIP代理服务器使一个用户可以获得多个会话， 以使一个用户可以同时使用多个虚机。

其中该方法进一步包括将会话和事务作为共同的开支， 考虑每个经虚拟化后 的 SIP服务器具有相同的性能，将同一会话的事务分配到相同的 SIP服务器的负载 分配方法。

其中该方法进一步包括使用 SIP服务器及其连接建立虚拟 SIP Overlay的方 法， 在 Overlay节点对 Overlay进行管理， SIP端口接受信令， Spice端口接受虚 机屏幕， 并提供统一的 API接口。

其中该方法进一步包括通过 SIP客户端和 SIP服务器协议栈实现虚拟桌面的 端对端传输的方法。

根据本发明的一实施例， 提出一种虚机池管理方法， 包括： 设置初始值、 最 大值、 门限值及预留值； 设定初始值、 最大值、 门限值及预留值之间的逻辑关系， 根据初始值、最大值、门限值及预留值以及它们之间的逻辑关系实现从虚机池取用 虚机的规则。

其中该方法进一步包括采用 linked-clone技术生成与主虚机池相对应的备用 池，并将备用池设置成 suspend状态，将备用池里的虚机与主虚机池中的虚机配合 使用。

其中该方法进一步包括将备用池按时间做动态的指定， 搜寻闲置池的备用池 优化策略。

根据本发明的一实施例， 提出一种将虚拟应用程序和虚机结合的方法， 包括： 在服务端安装监控程序；监控程序收集文件信息和注册表信息，并封装打包成 tsap 文件； 根据客户端对应用的请求， 将 tsap文件串流到客户端供用户使用。

其中该方法进一步包括根据已有的用户机器信息和虚拟应用程序信息创建模 板， 并将 SOD客户端装在虚机上。

其中该方法进一步包括将虚机及虚机上的应用程序分成四个层： 公司操作系 统、公司应用、用户应用、用户数据和设置， 并采用虚拟工作空间对所述四个层进 行管理。

根据本发明的一实施例， 提出一种采用虚拟桌面基础架构的超范围屏幕显示 方法， 包括： 设置后台服务点， 后台服务点在后台产生虚机和虚拟应用程序， 后台 服务点对虚机、虚拟应用程序、实机进行集中控制并分派给用户； 在后台服务点设 置应用代理，应用代理包括两部分：高端部分为应用生成器，底端部分为虚拟接口； 启动应用程序，虚拟接口侦测写在显示内存上的应用数据，如果超过屏幕范围就计 算超出的屏幕个数，并通知应用生成器为每个超出的屏幕生成一个进程；将原应用 的屏幕和生成的进程的屏幕一起发送到客户端。

根据本发明的一实施例， 提出一种采用虚拟桌面基础架构的屏幕分区显示方 法， 包括： 在客户端为一个大屏幕的每个分区设置相同的 IP地址以及不同的 TCP 端口号； 根据发出虚拟桌面请求的分区的 IP地址和 TCP端口号， 将虚拟桌面返回 到该分区上。

本发明的有益效果如下：

( 1 )首创一种多维虚拟桌面方法， 横向的一维表示虚拟桌面的传输路径， 纵 向的一维表示虚机上的应用层次，这种体系设计使得整个系统具有更加严密的逻辑 性和高度的可控性。

(2 ) 多个服务点可提供自助式服务， 可按需繁殖， 并基于策略自动伸缩， 提 升了服务的渗透能力以及质量保证。

(3) 提供统一编程接口， 具有高度的灵活性及强大的定制功能。

(4)将 SIP协议引入 VDI中， 配合 Spice协议， 取代传统的远程桌面访问协 议， 可增强会话的可视性和可控性， 实现智能会话， 并可对视频、 多媒体等高密度 数据的传输进行加速。

(5 )采用了一种先进的覆盖网技术， 可实现端对端的传输， 在有效减少传输 路径提高传输效率的同时， 提高了传输的可靠性和安全性。

(6)引入分布式负载方法，将负载分布到各服务点，减少了服务器端的负担， 为 VDI负载均衡提出了一种有效的解决方案。 ( 7 ) 将虚机和实机管理纳入统一的体系， 两者之间可互通信息， 互为补充， 并采用扩展的连接代理， 为不同地点的用户请求提供了灵活多样的选择；

(8) 提出了一种新的弹性池策略， 可优化虚机池的管理；

(9)开发出了一种新的应用虚拟化串流技术， 大大加快了虚拟应用程序的获 取速度；

( 10) 通过将虚拟桌面及其上的应用程序和数据分成若干个相互独立的层， 并分发到用户端， 实现了一种新的分层虚拟桌面方法。

( 11 ) 用户可在任何时间任何地点任何设备上访问远程数据中心的资源， 按 需取用， 灵活多样。

( 12 ) 成本低廉。 一个用户可以同时使用多个虚机， 随着用户人数的增加成 本明显下降， 具有规模经济效应。 附图概述

下面参照附图， 对于熟悉本技术领域的人员而言， 从对本发明方法的详细描 述中， 本发明的上述和其他目的、 特征和优点将显而易见。

图 1A是本发明的多维智能服务点虚拟桌面基础架构的系统组成框图； 图 1B是本发明的多维智能服务点虚拟桌面基础架构的访问接入点部分的访问 接入服务控制器框图；

图 1C是本发明的多维智能服务点虚拟桌面基础架构的业务交换点部分的业务 交换服务控制器框图；

图 1D是本发明的多维智能服务点虚拟桌面基础架构的虚拟化基础平台层状结 构图；

图 2是本发明的实机注册的过程图；

图 3是本明的虚拟桌面基础架构系统（图 1A中连接代理 122) 单点登录的实 施过程图；

图 4是本发明的 （图 1A中连接代理 122) 的过程图；

图 5是本发明的图 1B中管理控制台 1237的过程图；

图 6是本发明的图 5中用户 SIP注册认证过程图；

图 7是本发明的用户请求虚机 /实机时与后台服务点 SIP会话的建立及结束过 程图；

图 8A是本发明的会话聚合器 （图 1B中的 SIP服务器 1235 ) 通过时间机制将 多个会话进行汇聚从而实现多个用户同时使用一个虚机的过程图；

图 8B是本发明的会话拆分器（图 1B中的 SIP服务器 1235 ) 为一个用户分配 多个会话从而实现一个人可以同时使用多个虚机的过程图；

图 9是本发明的 SIP Overlay节点的组成框图；

图 10是本发明的（图 1B中的负载均衡器 1231和图 1C中的负载均衡器 1331 ) 基于 SIP分配负载的过程图；

图 11是本发明的（图 1A中虚机交换器 131和实机交换器 132 )的工作过程图； - 图 12是本发明的 （图 1A中实机连接管理器 1411 ) 的过程图； 图 13是本发明的 （图 1A中代理控制器 1416) 的过程图；

图 14是本发明的 （图 1A中使用情况报表 1412) 的过程图；

图 15是本发明的 （图 1A中实机状态管理器 1414) 的过程图；

图 16是本发明的 （图 1A中虚机池管理器 1443 ) 隔夜换池策略 （实施例） 过 程图；

图 17是本发明的 （图 1A中虚机池管理器 1443 ) 备用池的创建的过程图； 图 18是本发明的 （图 1A中虚机池管理器 1443 ) 备用池使用策略的请求虚机 的过程图；

图 19是本发明的 （图 1A中虚机池管理器 1443 ) 备用池优化策略的过程图； 图 20是本发明的 （图 1A中虚机池管理器 1443 ) 备用池优化策略的退出虚机 的过程图；

图 21是本发明的 （图 1A中虚机池管理器 1443 ) 弹性池规则的过程图； 图 22是本发明的 （图 1A中虚拟应用管理器 143) 预部署动作的过程图； 图 23是本发明的（图 1A中虚拟应用管理器 143)预部署动作客户端序列表格 的过程图；

图 24是本发明的 （图 1A中虚拟应用管理器 143 ) SOD应用串流的过程图； 图 25是本发明的（图 1A中虚拟应用管理器 143与虚机管理中心 144)结合的 过程图；

图 26是本发明的 （图 1A中虚机管理中心 144) 虚机模板版本化的过程图； 图 27是本发明的（图 1A中虚拟工作空间管理器 142)对 VDI上的操作系统进 行分层管理的过程图；

图 28是发明的虚拟桌面基础架构在证券公司的较佳实施例图；

图 29是发明的虚拟桌面基础架构在工厂的较佳实施例图； 具体实施方式

概述

图 1A为总图，此桌面虚拟化的基础架构包括客户设备 11、访问接入点 12、 业务交换点 13、后台服务点 14。白色框是本专利涉及的软件部分（功能模块）； 虚线框为申请人于 2008年 12月 10日提交的申请号为" CN 200810204286.X" , 题为"移动虚拟化的基础设施以及基础平台"的专利申请中已经详细描述过的功 能模块。 因此， 虚线框将不多作说明。

客户设备 1 1指各种用户终端设备， 既可以是传统 PC, 个人笔记本， 也可 以是上网本， 手机等终端设备， 即可以是各种胖痩终端设备。 如果是胖终端， 可以像普通 PC—样使用， 也可以将其虚拟化后使用。 图 1A所示的系统中， 客 户设备 11通过访问接入点 12和业务交换点 13从后台服务点 14取得虚机及应 用屏幕。

访问接入点 12的负责为客户设备 11建立到后台服务点 14的连接， 对连 接进行管理， 并提供网络服务。 其中连接代理 122负责与后台服务点 14的连 接工作， 并令虚机分派器 1441获取虚机。 远程访问服务器（RAS ) 121可提供 远程访问支持， 即为外部用户建立 VPN 连结。 典型的设置是这样的： 访问接 入点安装在 Access网络侧或核心网边缘 （Edge) 侧， 其底层硬件可为交换机、 路由器或服务器集群。 访问接入点 12 同时可提供自助式的服务， 具体可提供 负载均衡、 策略和规则引擎、 服务监控、 SIP服务、 会话 （Session) 转换等服 务以及统一编程接口 API (含多个接口） ， 服务具有渗透性， 并基于策略自动 地增缩。

业务交换点 13 主要负责虚机和实机的业务交换， 根据用户选择的虚机或 实机业务将其切换到相应的后台管理中心。 典型的设置是这样的： 业务交换点 13安装在核心网或核心网边缘侧 （Edge) ， （其底层硬件可为交换机、 路由器 或服务器集群） 。 业务交换点 13还拥有人员与团体管理数据库 1321， 座位与 教室管理数据库 1322， 应用与套餐管理数据库 1323， 以及虚机服务器和模板 管理数据库 1324。 这些数据库是由后台服务点 14中的虚机管理中心 144中的 管理控制台 1442进行管理。 业务交换点 13通过连接代理 122的统一认证授权 系统决定用户是否有权取得所订阅应用的屏幕。 业务交换点 13 并能判断该应 用是从虚机管理中心 144的后台过来， 还是从实机管理中心 143的后台过来， 从而采取适当的 PC屏幕适配措施。 业务交换点同时可提供自助式的服务， 具 体可提供虚拟网络管理、 负载均衡、 策略和规则引擎、 服务监控等服务以及统 一编程接口。

后台服务点 14 (一般是数据中心）是虚机、 实机和虚拟应用程序的后台管 理系统， 由虚机管理中心 144、 实机管理中心 141、 虚拟应用管理器 143和虚 拟工作空间管理器 142组成， 一般安装于核心网络中。 虚机管理中心中 144的 虚机池管理 1443 引入了弹性池规则和备用池规则。 实机管理中心 141 负责对 实机及其应用列表的管理， 监控实机的状态， 生成用户使用实机及其上的应用 的报告， 接受用户的使用请求并打开相应的应用供用户使用。 虚拟应用管理器 143 通过在计算机上模拟出应用程序的使用环境， 将应用程序虚拟化， 其操作 独立于操作系统和本地桌面上的其他应用程序， 从而达到在计算机上即使不安 装软件， 也可以在虚拟环境中正常运行软件的目的。 虚拟工作空间管理器 144 负责对应用分层的管理， 根据企业管理的需求， 可对操作系统及其上的应用进 行分层， 从下至上依次为公司操作系统、 公司应用、 用户应用、 用户数据&设 置 （这样可实现层与层之间的独立性， 层之间的相互关联性， 有利于不同权限 的管理员对不同层的管理） 。

实现本发明的桌面虚拟化的基础架构， 需要 SIP客户端 111和 Spice客户 端 112通过 SIP协议和 Spice协议与 SIP服务器端 1457和 Spice服务器端 1456 进行通信， 其中 SIP客户端 111是客户设备的一个软件， 而 SIP服务器 1457 则是运行在虚拟化基础平台 145的 Linux内核操作系统上。

SIP客户端 111和 SPICE客户端 112安装在客户设备 11上， 但注意这里 根据客户设备的性能不同， 会有不同的可选情况。 当客户设备性能很差 （很痩 的终端） 以致无法运行 SIP和 Spice时， 选择在客户设备上安装 RDP客户端， SIP客户端安装在访问接入点， 从访问接入点开始使用 SIP协议。 当客户设备 是定制的瘦终端时， 则客户设备上仅安装 SIP客户端， 还需要一个驱动器来接 受虚机屏幕， 客户端仅作 SIP通信使用。 还要注意企业内部用户和外部用户的 区别。 访问接入点 12 可以自动辨别客户终端是胖终端或瘦终端， 如果是胖终 端， 则使用 SIP和 Spice, 否则使用 RDP即可。 还有一种就是电子书包 （胖终 端） ， 只需从服务器下载镜像后， 便可自己在客户端跑， 只需要跟服务器同步。 用户点击所需的应用， 在访问接入点的连接代理上存有用户专有信息以资验证 (用户通过 SSO认证， 信息保留在访问接入点上） ， 在业务交换点 13上切换 到相应的虚机或实机应用。 若用户请求的是虚机， 后台服务点 14 会通过虚拟 化平台应用接口去虚拟化基础平台取得虚机， 这时应用代理会激活应用并把第 一个虚机上的虚拟桌面传到客户设备 11 上； 若用户请求的是实机， 后台服务 点 14 会查看所请求的实机的状态， 命令应用代理激活应用并把实机上的第一 个虚拟桌面传到客户设备上。

图 1 B的访问接入服务控制器 123是访问接入点中的一个服务模块， 提供 自助式的虚拟化计算和资源服务， 服务可按需繁殖， 并基于策略自动地增缩。 负载均衡器 1233用于实现负载均衡的； 策略和规则引擎器 1232提供策略和规 则引擎； 服务监控器 1235用于监控服务请求的； Overlay管理器 1231是用于 管理 SIP Overlay的， SIP端口传输信令， Spice端口传输虚拟桌面， 并为信令 和虚拟桌面建立 Overlay连接； SIP服务器 1234可以将会话进行聚合和拆分， 使得多个用户可以同时使用一个虚机， 一个用户可以同时使用多个虚机； 服务 接口 1236提供统一编程接口， 可与第三方集成。

图 1 C的业务交换服务控制器 133是业务交换点 13中的一个服务模块， 可提供呼叫接续和业务交换， 可以实施呼叫开始、 中断或中继交换的。 和前述 访问接入点 12中的访问接入服务控制器 123相似， 可提供自助式的虚拟化计 算和资源服务， 服务点可按需繁殖， 并基于策略自动地增缩。 业务交换服务控 制器 133包括 Overlay管理器 1331，策略和规则引擎器 1332，负载均衡器 1333， SIP服务器 1334， 呼叫接续 1335， 业务交换 1336， 服务监控器 1337， 服务接 口 1338， 管理控制台 1339。 具体可提供负载均衡、 规则和策略引擎、 服务监 控、 Overlay管理、 SIP服务以及统一编程接口 （其各模块功能与访问接入点 12 中的相似， 在前面已作描述） 。

图 1D 的虚拟化基础平台 145是 VDI的基础技术， 提供 VDI的基础支撑 平台， 可包括多个主机， 其中每一主机上使用基于内核的虚机 （Kernel Based Virtual Machine,KVM ) 1452 对硬件平台进行虚拟化， 内核 KVM1452 与 QEMU1453进程通信虚拟至少一个具有客户操作系统及内存的虚机 1454(底层 既可以是 KVM， 也可以是 ESX， Xen或 Hyper-V) 。 虚拟化基础平台执行性能 监测， QEMU及内核共享， 内存分页优化，输入输出设备调试的预处理的功能。

实现本发明的虚拟桌面基础架构，需要 SIP客户端 111和 Spice客户端 112 通过 SIP协议建立与虚拟化基础平台上 SIP服务 1457的通信，从而为此次会话 建立一个连接。 连接建立好后， 启动 Spice服务器， 将虚拟桌面从后台传到客 户端。 之后再用 SIP协议结束会话。 图 2-图 4给出了注册认证和单点登录的过程。

图 2注册实机图

图 2描述了实机的注册过程， 这里的实机是相对虚机而言的， 指的是未经 硬件虚拟化的计算机，亦即通常所说的真实物理计算机，实机处于后台服务点。 在使用实机之前， 需要对实机进行注册， 实现过程如下：

步骤 201， 在用户的 My Real Machine (我的实机） 界面增加一台 pc (个 人计算机， 亦即实机） ， 输入 ip地址 /机器名等信息；

步骤 202， 在 Application List (应用列表）界面增加 application (应用）信 息， 输入 app (应用） 的安装路径和 exe (可执行文件） 的名字等信息；

步骤 203， 保存后， 显示一个下载界面， 让用户可以下载代理 （agent) 和 spice 服务器， 提示用户安装；

步骤 204， 提示用户测试当前 pc是否可用， 可用通过发送和接收一些测试 的 Message (信息） 来测试一下代理和 spice server (服务器） 是否安装正确。 图 3 单点登录

单点登录 （SSO) 主要是为了解决用户权限管理的复杂化、 用户及权限管 理模块重复开发、 存在系统安全隐患等一系列问题， 使得用户登录了其中的一 个应用系统， 便可以直接使用其它的应用系统。 单点登录的过程如下： 用户输 入用户名 /密码， 登录单点登录认证系统。 认证中心 （AC ) 根据用户提交的信 息， 验证用户的身份。 如果是合法用户， 就根据用户信息和权限创建凭据 (Ticket), 否则拒绝登录。 为了保证凭据数据的安全， 每个凭据都有一组根据非 对称加密算法生成的密钥 （公钥 KA和私钥 KB ) ， 凭据中的数据均用与凭据 相对应的公钥加密， 并用摘要算法 （如 MD5/SHA) 生成校验信息。 认证中心 将合法用户的凭据通过网络传送到用户所在的计算机上保存。 用户选择自己需 要访问的应用系统 VDI后， 向应用系统服务器发送自己的凭 ¾， 并开始转入应 用系统的认证程序。 应用系统在认证中心验证凭据的有效性， 如： 是否由认证 中心所发、 是否超过有效期等。 应用系统根据用户计算机上凭据的信息， 由摘 要算法生成摘要，通过对比校验信息和摘要校验凭据的完整性。如果经过验证， 凭据是合法且有效， 就从认证中心取得凭据的私钥对提交的凭据的数据进行解 密， 并读取其中所含有的用户信息。应用系统 VDI验证用户是否具有访问本系 统的合法身份 （确定是否有访问权限， 是否通过本级管理员审批并开通） ， 若 身份合法，则根据其具有的权限配置相应的使用权限，否则拒绝进入 VDI系统。 在用户结束系统的使用后， 由用户注销凭据， 若系统超时， 凭据自动销毁。

步骤 301， 用户输入用户名和密码；

步骤 302， 用户请求登录到单点登录认证系统；

步骤 303， 认证中心根据用户提交的信息， 验证用户的身份；

步骤 304， 判断用户是否为合法用户。 如果是， 转入到步骤 306， 否则转 入到步骤 305 ;

步骤 305， 提示户名或密码错误， 拒绝用户登录；

步骤 306， 根据用户信息和权限创建凭据；

步骤 307， 为了保证凭据数据的安全， 每个凭据都有一组根据非对称加密 算法生成密钥 (公钥和私钥） ， 将凭据中的数据用公钥进行加密；

步骤 308， 用摘要算法 （如 MD5/SHA ) 生成校验信息；

步骤 309， 认证中心将合法用户的凭据；

步骤 310， 通过网络传送到用户所在的计算机上保存；

步骤 311， 动态生成用户界面；

步骤 312， 凭据到达 SSO客户端；

步骤 313， 存储凭据在计算机上；

步骤 314， 选择 VDI子系统；

步骤 3 15， 自动登录 VDI子系统

步骤 316， 发送凭据到 VDI系统

步骤 317， 凭据到达 VDI子系统

步骤 318， 将凭据发送到认证中心；

步骤 319， 凭据到达认证中心；

步骤 320， 验证凭据 TA有效性；

步骤 321， 判断凭据是否有效。 如果有效， 转入到步骤 323， 否则转入到 步骤 322;

步骤 322 , 用户重新登录；

步骤 323， 判断凭据是否完整。 若是， 转入到步骤 325， 否则转入到步骤

324；

步骤 324， 用户重新登录；

步骤 325， 用私钥解密凭据；

步骤 326， 判断用户是否具有访问权限。 若是， 转入到步骤 328.， 否则转 入到步骤 327;

步骤 327， 用户没有访问权限；

步骤 328， 根据权限自动生成 VDI子系统界面;

步骤 329， 使用 VDI子系统功能；

步骤 330， 使用结束用户退出；

步骤 331， 系统超时；

步骤 332 , 注销凭据。 图 4 连接代理

连接代理 122是 VDI系统中最重要的部分之一，其过程如下： 用户向服务 器发出登录请求， 若用户在防火墙外， 则连接代理 122为用户建立 VPN (虚拟 专用网络）连接； 否则， 直接转到下一步判断用户是否通过 SSO认证授权； 若 没有通过认证， 则告诉客户端显示错误信息， 若通过认证， 则把请求传到 SIP 代理服务器， SIP 代理服务器解析地址并向下一跳发出呼叫请求； 请求到达业 务交换点中的虚机 /实机交换器， 若用户请求的是虚机上的应用， 则切换到虚机 入口， 并连接到后台的虚机管理中心， 令虚机分派器获取虚机， 从应用列表查 到应用 ID，找到最佳虚机，并通知应用代理在虚机上激活应用，最后启动 Spice 服务器， 传应用的第一屏给客户端； 若用户请求的是实机上的应用， 则切换到 实机入口， 并连接到后台的实机管理中心， 査询实机列表和应用列表， 选择使 用某台实机下的某个应用，找到最佳实机，并通知应用代理在实机上激活应用， 最后启动 Spice服务器， 传应用的第一屏给客户端 （注意这里， 实机也是和虚 机一样， 采用 SIP协议发起会话， 采用 Spice传送实机屏幕； 在连接代理中也 可体现 SIP, 只是侧重点有所不一。 在传统的 VDI中， 没有使用 SIP协议的情 况下，通过连接代理建立连接， 是因为传统的屏幕传送协议 RDP只仅仅负责屏 幕的传送； 而我们采取 SIP协议后， 则是以连接代理的连接功能为主， 贯穿整 个虚拟桌面基础架构， 内含 SIP代理连接， 用于 SIP通信。 ）

这里的连接代理（扩展的连接代理） 将实机和虚机整合到一个体系， 可以 同时连接到实机管理中心和虚机管理中心。

步骤 401， 用户向服务器发出登录请求；

步骤 402， 连接代理判断用户是否在防火墙之外。 若是， 转入到步骤 403， 否则转入到步骤 404;

步骤 403， 连接代理为用户建立 VPN连接；

步骤 404， 判断用户是否通过 SSO认证授权。 若是， 转入到步骤 406， 否 则转入到步骤 405;

步骤 405， 告诉客户端显示错误信息；

步骤 406， SIP服务器转发请求到下一跳服务器；

步骤 407， 虚机 /实机交换器为请求选择相应的虚机或实机入口； 步骤 408， 若用户请求的是虚机， 则连接代理令虚机分派器获取虚机， 从 应用列表查到应用 ID (身份） ； 若用户请求的是实机， 则连接代理令实机连接 管理器査询实机和应用状态；

步骤 409， 连接应用， 分三步进行， （a) 告知虚机或实机上的应用代理应 用 ID, (b)等待， 直到应用启动或失败，（c) 通知 SIP 客户端应用已启动， 准备 接受应用的第一屏幕， 或告以启动失败报错。

图 5-图 10给出了 SIP会话和网络管理过程。 图 5 会话管理控制台

图 5给出了会话管理控制台的工作过程图。 当用户请求 （会话） 到达可管 理的服务点时， 通过管理控制台操作操作一系列的管理工具来处理会话， 从而 实现负载均衡、 会话的智能性、 安全性等。 具体步骤如下- 步骤 501， 服务监控器监控到用户请求虚机 /实机；

步骤 502， 判断用户是否通过 SIP注册认证。 若通过， 转入到步骤 504， 否则转入到步骤 503 ; 步骤 503， 告诉客户端显示错误信息；

步骤 504， 负载均衡器根据规则把请求分配到 SIP服务器；

步骤 505， 判断操作是否是聚合会话。 若是， 转入到步骤 506， 否则转入 到步骤 507 ;

步骤 506， 进入会话聚合器， 关于会话聚合器， 会在后面的图 8A中详细 说明；

步骤 507， 判断操作是否是拆分会话。 若是， 转入到步骤 508， 否则转入 到步骤 509;

步骤 508， 进入会话拆分器， 关于会话拆分器， 会在后面的图 8B 中详细 说明；

步骤 509， 虚拟 SIP Overlay (覆盖网） 管理节点决定请求的转发路径； 步骤 510， 会话管理还包括安全管理， QoS (服务质量） 管理， 会话统计 管理等管理功能。 图 6 SIP注册认证

用户代理客户端向注册服务器发出注册请求， 注册分为两种， 包括用户的 注册和机器的注册， 如果是机器的注册， 则将机器的 IP地址、机器名等信息注 册到注册服务器中 （这种注册是对固定机器的注册， 可以机器的相关信息登录 到系统） ； 如果是用户的注册， 则在注册界面输入用户名、 密码等信息， 注册 信息存入位置服务器 （这种注册方式很灵活， 用户可在不同地点的不同机器上 以用户名和密码登录到系统） 。 若注册服务器得知用户没有发认证消息， 发送 应答消息 401 (Unauthorized) 向用户代理要求认证证书， 用户重发包含认证信 息的注册请求， 注册服务器对认证消息进行验证。 若验证通过， 注册服务器 验证通过并返回 OK; 若验证未通过， 则要求用户重发包含认证信息的注册请 求， 后续步骤同上。 若注册服务器得知用户注册请求中携带认证消息， 则后续 步骤同上。 注册信息存入位置服务器。

用户代理客户端向用户代理服务器端发出 Invite (会话邀请） 请求， 代理 服务器得知用户没有发认证消息， 即发送应答消息 407 ( Proxy- Authentication Request) 向用户要求认证证书； 用户发送 ACK (确认） ， 用户重发包含认证 信息的 Invite请求， 代理服务器对请求进行认证， 并发 200 OK确认。 注册服 务器将注册认证信息存储在位置服务器中。 用户代理服务器端对用户代理客户 端所发送的 INVITE方法中的会话描述 SDP (会话描述协议） 进行分析， 若客 户设备具有接收和解码服务器端发送的多媒体信号的能力， 则说明双方可以正 常通信， 否则显示客户端错误。

步骤 601， 用户代理客户端向注册服务器发出注册请求；

步骤 602， 判断是否要求用户机器注册。 若是， 转入到步骤 603， 否则转 入到步骤 604;

步骤 603， 在注册界面输入用户机器的 IP地址、 机器名等信息； 步骤 604， 在注册界面输入用户名、 密码等信息； 步骤 605， 判断注册请求中是否携带了认证消息。 若是， 转入到步骤 607， 否则转入到步骤 606;

步骤 606， 注册服务器发送应答消息 401 (Unauthorized) 向用户代理要求 认证证书；

步骤 607， 注册服务器对认证消息进行验证；

步骤 608， 用户重发包含认证信息的注册请求；

步骤 609， 判断注册请求中携带的认证消息是否通过验证。 若通过， 转入 到步骤 610， 否则转入到步骤 608;

步骤 610， 注册服务器发送 200 OK确认验证通过；

步骤 611， 将用户的注册信息存入位置服务器；

步骤 612， 用户代理客户端向用户代理服务器端发出 Invite请求； 步骤 613， 判断 Invite请求中是否携带了认证消息。 若 Invite请求中携带 了认证消息， 转入到步骤 617， 否则转入到步骤 614;

步骤 614， 代理服务器发送应答消息 407 ( Proxy- Authentication Request) 向用户要求认证证书；

步骤 615， 用户发送确认消息 ACK;

步骤 616， 用户重发包含认证信息的 Invite请求；

步骤 617， 代理服务器对认证消息进行验证；

步骤 618， 判断 Invite请求中的认证消息是否通过验证。 若通过验证， 转 入到步骤 619， 否则转入到步骤 617;

步骤 619， 用户代理服务器端对用户代理客户端所发送的 INVITE方法中 的会话描述 SDP进行分析； SIP使用 SDP来进行能力交换， 当前， SIP还不如 H.245有完整灵活的协商能力， 因为受制于 SDP的表达方式， 例如 SIP不支持 不对称能力交换 (只收或只发)以及声频和视频编码的并发能力。 当 SIP 为主叫 方时， SIP在 INVITE方法的会话描述中指示其能够接受的媒体类型及其参数， 还可以指示其愿意发送的媒体类型。

步骤 620， 判断客户设备是否具有接收和解码服务器端发送的多媒体信号 的能力。 若是， 转入到步骤 322， 否则转入到步骤 321 ;

步骤 621， 客户端错误， 即客户端设备不具备接收服务器端所发送的虚机 / 实机屏幕的能力， 用户若想使用 VDI系统， 需要改换终端设备， 或者改换 SIP 客户端， 安装 RDP客户端， 这当然一种备选方案；

步骤 622， 双方可以正常通信， 即客户端设备可以接收服务器端所发送的 虚机 /实机屏幕。 图 7为 SIP会话过程图

(当然 Invite请求和 Option请求的先后顺序可以改变）客户端发起会话请 求 Invite请求虚机。 后台服务点收到用户的请求， 并且正确处理了这个请求， 则发出临时应答 lxx。 客户端收到临时应答消息， 判断是否超时， 若超时， 则 客户端重新发起会话请求 Invite请求虚机； 若未超时， 则继续等待来自后台服 务点的响应。 在后台服务点， 若还需要附加操作才能完成这个请求， 并将本请 求转发到其他的服务器上处理， 则发出重定向 3xx应答； 若请求包含错误的格 式或者不能在这个服务器上完成， 则发出客户端错误 4xx应答； 若服务器不能 正确地处理这个显然合法的请求， 则发出服务器错误 5xx应答； 若请求不能被 任何服务器处理， 则发出全局错误 6xx应答； 若请求已经成功接收， 并且正确 处理了这个请求， 则发出成功处理 200OK响应。 客户端若收到 3xx-6_XX响应， 则客户端重新发起会话请求 Invite请求虚机 （表示此次请求虚机失败） ； 若收 到 200 OK响应， 则继续等待下一响应。 服务器端向客户端发出 Option请求， 询问客户端是否具有接收和解码服务器端发送的多媒体信号 （媒体类型和媒体 参数） 的能力。 客户端收到 Option请求， 若服务器端发送的多媒体信号（媒体 类型和媒体参数） 在自己可以接受的媒体类型及参数的范围内， 则客户端可与 服务器正常通信， 返回 200 OK, 并做好传输媒体流的准备； 反之， 双方无法通 信， 会话结束 （这一步机器能力的协商也可以在注册认证过程中完成， 作为一 种可选方案。 该方案灵活性差， 但使用方便， 使得在后面的会话过程中无需再 考虑机器能力的交换） 。 服务器端收到 200 OK响应， 开始准备传屏。 通过任 务驱动器， 计算屏幕的位置， 并调用 Spice协议， 传送屏幕。 客户端收到服务 器端传送的 Spice数据流，并发 200 OK响应确认。服务器端如果等待响应超时， 则重新准备传屏； 反之，在正常等待时间内收到 200 OK响应。客户端发送 Bye 请求释放呼叫， 服务器端收到 Bye请求， 发 200 OK响应。

步骤 701， 注册结束；

步骤 702， 客户端向后台服务点发起会话请求， 请求虚机 /实机； 步骤 703， 客户端收到来自后台服务点的临时应答消息；

步骤 704， 判断应答是否超时。 若是， 转入到步骤 702， 否则转入到步骤

705；

步骤 705， 判断是否收到响应 3xx-6xx。

步骤 706， 客户端收到后台服务点的 200 OK响应；

步骤 707， 客户端收到后台服务点的 Option请求；

步骤 708， 判断客户端是否具有接收和解码后台服务点发送的多媒体信号 的能力。 若能接收， 转入到步骤 710， 否则转入到步骤 709;

步骤 709，客户端不具备接收和解码后台服务点发送的多媒体信号的能力， 双方无法通信， 会话结束；

步骤 710， 客户端具备接收和解码后台服务点发送的多媒体信号的能力， 客户端可与服务器正常通信， 返回 200 OK;

步骤 711， 确认， 开始客户端和后台服务点之间的媒体流传输；

步骤 712， 客户端等待接收后台服务点发送的虚机屏幕；

步骤 713， 客户端收到服务器端传送的 SPICE数据流， 即虚机屏幕； 步骤 714， 客户端收到虚机屏幕后， 发 200 OK响应给后台服务点； 步骤 715， 客户端发送 Bye请求释放呼叫；

步骤 716， 后台服务点等待用户注册成功； 步骤 717， 后台服务点收到用户请求；

步骤 718， 后台服务点发临时应答；

步骤 719， 判断后台服务点是否成功处理客户端请求。 若是， 转入到步骤 724， 否则转入到步骤 720， 步骤 721， 步骤 722， 步骤 723 ;

步骤 720， 重定向；

步骤 721， 客户端错误；

步骤 722， 服务器端错误；

步骤 723， 全局错误；

步骤 724， 后台服务点成功处理客户端请求， 发 200 OK响应；

步骤 725， 服务器端向用户端发出 Option请求， 以询问客户端是否具备接 收和解码后台服务点发送的多媒体信号的能力；

步骤 726， 后台服务点收到客户端的 200 OK响应；

步骤 727， 后台服务点做好传屏的准备工作；

步骤 728， 任务驱动， 计算屏幕位置；

步骤 729， 调用 SPICE, 传送屏幕；

步骤 730， 判断等待响应是否超时；

步骤 731， 收到 200 OK响应；

步骤 732， 收到 Bye请求， 发 200 OK响应。 图 8 会话转换器

通过 SIP服务器的转换功能， 可以实现多个用户使用一台虚机， 一个用户 同时使用多台虚机， 从而为用户灵活分配虚机， 提高资源的利用率， 实现智能 会话， 这是本发明的一大特色。

图 8A为会话聚合器， 描述了多用户使用一个虚机的过程。

步骤 8101， 用户选择应用向后台服务点发出虚机 /实机的使用请求； 步骤 8102， 请求到达 SIP服务器 （会话转换器） ， SIP服务器既可以在访 问接入点， 也可以在业务交换点和后台服务点， 这里的 SIP服务器是指在访问 接入点的 SIP服务器；

步骤 8103， 请求被划分在计时器计时的汇聚时间间隔内， SIP有一个时间 机制， 可确定一个极小的时间段， 对时间段内的请求进行汇聚后再发送出去； 步骤 8104， SIP服务器计算该时间段 （间隔） 内的所有虚机请求的个数， SIP服务器内可设置一计数器来统计时间段内虚机的个数；

步骤 8105， 判断请求的个数是否大于 1。 若大于 1， 转入步骤 8107， 否则 转入步骤 8106;

步骤 8106， 判断请求的个数是否等于 1。 若等于 1， 转入步骤 8108， 否则 转入步骤 8101 ;

步骤 8107， 将多个请求汇聚成一个会话请求后发往后台服务点； 步骤 8108， 将单个请求直接发往后台服务点；

步骤 8109， 后台服务点为该请求分配一个虚机 /实机； 步骤 8110， 判断该请求是否是将多个原始请求汇聚后的请求。 若是， 转入 步骤 8112， 否则转入 8111 ;

步骤 8111， 应用代理打开相应的应用， 并将屏幕直接返回给用户； 步骤 8112， 将汇聚后的请求分解成原始请求， 应用代理为每个原始请求打 开其请求的应用， 并将屏幕分别返回给各用户。

图 8B为会话拆分器，描述了一个用户使用多个虚机的过程。由于 SIP Proxy Server ( SIP 代理服务器） 的主要任务是完成消息转发， 在转发请求之前， 它 可以改写原请求消息中的内容。 它也可代表其它客户机发起请求， 既充当服务 器又充当客户机。 这里使用 SIP Proxy Server的功能， 可以为一个用户分配多 个会话， 从而实现一个用户同时使用多个虚机。

步骤 8201， 用户选择应用向后台服务点发出虚机 /实机的使用请求； 步骤 8202， 请求到达 SIP服务器 （会话转换器） ；

步骤 8203， 判断用户是否请求多个虚机。 若用户请求多个虚机， 转入步骤 8204， 否则转入步骤 8205 ;

步骤 8204， SIP服务器根据用户的要求， 向后台服务点发送多个会话请求； 步骤 8205, SIP服务器路由请求到后台服务点；

步骤 8206， 后台服务点为每个会话请求分配一个虚机；

步骤 8207， 后台服务点为该会话请求分配一个虚机；

步骤 8208， 后台服务点将多个虚机返回给一个用户；

步骤 8209， 后台服务点将单个虚机返回给一个用户； 图 9 Virtual SIP OVERLAY (虚拟 SIP覆盖） 节点

该图给出了 SIP Overlay节点 91的组成， 众多 SIP服务器及其上的 SIP链 接构成了 SIP overlay网络。 在该 overlay节点 91中， API 913 接口提供统一的 接口， 实现 overlay网络间的相互连接， Overlay管理 912负责对 Overlay节点 进行管理， 为信令和虚拟桌面的传输建立 Overlay。 端口有 Spice端口 9111和 SIP端口 9112， SIP端口 9111用于转发信令流的， Spice端口 9112用于转发虚 拟桌面流的。 SIP用户代理 90既可以是 SIP用户代理客户端， 也可以是 SIP用 户代理服务器端。 图 10 基于 SIP的负载均衡

图 10给出了基于 SIP的负载均衡的实现过程。 由于 SIP有会话和转换两 种事务， 而会话又是一种状态， 被 Invite事务创建， 被 BYE事务结束。 因而 SIP有事务和会话两方面的开支。因而可以采用将相同的会话分配到相同的 SIP 服务器上的方法。 （这样的负载均衡方法的优点是易于管理） 假设每个 SIP服 务器都是经过虚拟化后平均分配的服务器， 具有相同的性能。 实现过程如下： 步骤 1001， 客户端发出虚机 /实机请求到达负载均衡器；

步骤 1002， 负载均衡器判断该请求是否是 Invite请求。 若是， 转入到步骤 1005， 否则转入到步骤 1003 ; 步骤 1003， 判断该请求是否是 Bye请求。 若是， 转入到步骤 1006， 否则 转入到步骤 1004;

步骤 1004， 通过负载均衡器， 将该请求分配到与之相同 CALL-ID所在的 SIP服务器上 （同一会话内的所有相关的 SIP消息都使用同一个 Call-ID) ； 步骤 1005， 将该请求的 CALL-ID记录在负载均衡器中；

步骤 1006， 通过负载均衡器， 找到与 bye请求 Call-ID相同的请求所在的 SIP服务器 i， Count(i)=count(i)-l _;

步骤 1007， For i=l to n, 査看 SIP服务器 SIP(i) (假设有 n个 SIP服务器）； 步骤 1008， 判断 SIP(i)上是否是空载。 若是， 转入步骤 1010， 否则转入到 步骤 1009;

步骤 1009， 判断 i是否小于^ 若 i小于 n， 转入到步骤 1007， 开始执行 下一次循环， 否则转入到步骤 1011 ;

步骤 1010， 设置 Count(i)=0;

步骤 1011， 负载均衡器找到 count ( i) 最小的 SIP服务器， 并将请求分配 到该服务器上；

步骤 1012， 将该 Invite请求分配到 SIP(i)服务器；

步骤 1013， 设置 Count(i)=count(i)+l， 并开始等待下一个请求的到来； 图 11-15是实机管理部分， 给出了实机管理的过程。

图 11 VM/RM交换器

图 11给出了虚机 /实机交换器的工作流程情况。 在我们的 VDI中， 用户可 根据自己的需要， 选择使用虚机或实机， 其交换由实机 /虚机交换器来完成， 具 体实现过程如下：

步骤 1101， 用户发出登录请求并进入交换器；

步骤 1102， 判断用户是否选择实机。 若选择实机， 转入步骤 1103， 否则 转入步骤 1104;

步骤 1103， 切换到实机入口；

步骤 1104， 切换到虚机入口；

步骤 1105，判断用户选择的实机和应用，通知应用代理在实机上激活应用， 并将 ip/spice port (端口） 号返回；

步骤 1106， 找到最佳虚机， 并通知应用代理在虚机上激活应用； 步骤 1107， Spice服务器： 传应用的第一屏给客户端。 图 12 实机连接管理器

图 12给出了实机连接管理器的工作流程情况。 Connection Manager (连接 管理器） 负责接受用户使用 pc (个人计算机） 的请求， 首先会检査 pc的状态 是否可用，然后会将客户将要使用的 application (应用）消息通过代理 Controller (控制器）发送给代理， 让它打开对应的 application (应用） 。 然后 connection manager (连接管理器） 返回信息给 switch (交换器） ， 同时记录用户的使用情 况。 其实现过程如下：

步骤 1201， 实机连接管理器收到用户使用实机的请求；

步骤 1202， 实机连接管理器查询实机列表和应用列表， 选择使用某台实机 下的某个应用；

步骤 1203，实机连接管理器检査 pc的状态是否为 power on (接通电源的）。 若为 power on， 转入到步骤 1205， 否则转入到步骤 1204;

步骤 1204， 将检査结果返回给交换机， 通知用户 pc没有启动， 无法使用； 步骤 1205， 发送需要启动的应用信息给代理， 修改 pc的状态；

步骤 1206， 判断应用是否启动。 若应用已经启动， 转入到步骤 1208， 否 则转入到步骤 1207;

步骤 1207， 返回给交换机， 通知用户应用启动失败， 无法使用； 步骤 1208， 将 pc的 ip/vnc port等信息返回给交换机。 图 13 代理控制器

图 13给出了代理控制器的工作过程图。 代理控制器负责接收代理发送给

ActiveMQ的消息， 包括 pc的 poweron/poweroff 以及用户 login/logout (登录 / 登出） ； 当用户请求使用 pc时， 代理控制器发送打开 /关闭 app的指令给代理。 代理会在 pc 启动之后定时发送 heart beat (心跳） 给代理控制器， 如果超时没 有收到 heart beat, 就会认为这台 pc已经 poweroff, 用户就无法使用。 实现过 程如下：

步骤 1301， 代理控制器接收代理发送的 heart beat;

步骤 1302， 代理控制器接收代理发送给 ActiveMQ的消息；

步骤 1303， 代理控制器判断在一定时间内是否收到 heartbea 若收到， 转到步骤 1315， 否则转入到步骤 1309;

步骤 1304， 代理控制器用户是否发出了 login请求。 若是， 转入到步骤

1310， 否则， 转入到步骤 1305；

步骤 1305， 代理控制器判断用户是否发出了 logout请求。 若是， 转入到 步骤 1311 , 否则转入到步骤 1306;

步骤 1306， 代理控制器判断用户是否发出了 power on请求。 若是， 转入 到步骤 1312， 否则转入到步骤 1307;

步骤 1307， 代理控制器判断用户是否收到 power off请求。 若是， 转入到 步骤 1313， 否则转入到步骤 1308;

步骤 1308，代理控制器判断用户是否请求使用 pc。若是，转入到步骤 1314， 否则转入到步骤 1315 ;

步骤 1309， 通知该 pc已经 poweroff, 用户就无法使用；

步骤 1310， 发送 login的指令给代理；

步骤 1311， 发送 logout的指令给代理；

步骤 1312， 发送 power on的指令给代理；

步骤 1313， 发送 power off的指令给代理； 步骤 1314， 发送打开 /关闭应用的指令给代理;

步骤 1315， 无动作。 图 14获得实机 /应用的使用记录

图 14 给出了获取实机 /应用的使用记录的过程图。 根据用户使用 pc/application的记录， 生成用户使用情况的报表， 包括每个 application的使用 时间统计， pc的使用时间统计等。 具体实现过程如下：

步骤 1401， 以请求的实机 /应用值进入；

步骤 1402， 判断实机是否为运行状态。 若是， 转入到步骤 1404， 否则转 入到步骤 1403 ;

步骤 1403， 报错返回；

步骤 1404， 取得所予实机的进程 ID (PID) ；

步骤 1405， 用 pid调用性能代理；

步骤 1406， 返回所予实机的 CPU, 内存， 心跳信息， 使用时间以及应用的 使用时间；

步骤 1407， 生成应用使用情况报表。 图 15实机状态管理器

图 15给出了实机状态管理器的工作过程图。 实机状态管理器负责监控 pc 的状态，是 poweron/poweroff/using中的一种，负责状态的转换。实现过程如下： 步骤 1501， 状态管理器得到实机的状态；

步骤 1502; 判断状态是否为 Power on。 若是， 转入到步骤 1506， 否则转 入到步骤 1503 ;

步骤 1503， 判断状态是否为 Power off。 若是， 转入到步骤 1506， 否则转 入到步骤 1504;

步骤 1504; 判断状态是否为正在使用状态。 若是， 转入到步骤 1506， 否 则转入到步骤 1505 ;

步骤 1505 ; 状态 =N/A (空） ；

步骤 1506; 返回状态。 图 16-21是虚机池管理部分。

图 16 隔夜换池策略图

图 16给出了隔夜换池策略的过程图。

按照课程时间表， 事先安排某类虚机池给某班级 （而不让学生自己选操作 系统） 。 VDI必须有按照课程时间表预先安排虚机池的策略管理。 譬如前一天 知道某班级第二天要切换到不同操作系统， 就在隔夜自动按照课程时间表进行 切换。 这种策略比较没有弹性应付课程突然改的情况， 而且仍然有当天换池， 要学生等待的情况。 总图 1A中座位与教室管理数据库， 就是用于存放这一部 分的数据的。 实现流程如下：

步骤 1601， 在模板上创建虚机， 并以虚机模板克隆虚机；

步骤 1602， 每天早上， 打开虚机；

步骤 1603， 调用课程表；

步骤 1604， 根据课程表， 将教室与虚机池静态绑定；

步骤 1605， 晚上课程结束后， 关闭虚机；

步骤 1606， 还原虚机。 图 17 用于批量还原的备用池图

图 17给出了备用池的创建的过程图。 备用池主要用来解决课程突然改变 的情况， 这就要求在课间 10 分钟内更换课程。 由于大批量虚机的还原和开启 需要相当长的吋间， 一般很难在课间这么短的时间内完成更换课程表的任务， 这时就需要用到备用池。 创建步骤如下：

步骤 1701， 创建主虚机池；

步骤 1702， 设置主虚机池的默认状态为 power on;

步骤 1703， 采用 linked-clone, 创建对应的备用池， 通过池名来与主虚机 进行一一对应， 这里采用 linked-clone方法， 是为了节省物理服务器资源； 步骤 1704， 设置备用池的默认状态为 suspend, 这样设置是为了能在很短 的时间内江备用池中的虚机恢复到正常工作状态。 图 18备用池使用策略一请求虚机

图 18给出了备用池使用策略—请求虚机的过程。 在主虚机池和备用池配合 使用的情况下， 用户请求虚机， 若—主虚机池中的虚机够用， 则使用主虚机池中 的虚机， 否则使用与主虚机池相应的备用池中的虚机， 步骤如下：

步骤 1801， 用户请求虚机；

步骤 1802，判断主池中虚机状态是否为 power on。若是，转入到步骤 1803， 否则转入到步骤 1804;

步骤 1803， 分配虚机给用户

步骤 1804， 判断备用池中对应的备用虚机状态是否为 power On。 若是， 转入到步骤 1803， 否则转入到步骤 1805 ;

步骤 1805， 判断主池中虚机状态是否为 suspend。若是， 转入到步骤 1805， 否则转入到步骤 1807;

步骤 1806， 系统自动帮其开机并分配给用户使用；

步骤 1807， 判断备用池中对应的备用虚机状态是否为 suspend。 若是， 转 入到步骤 1806， 否则转入到步骤 1808;

步骤 1808， 告知用户无虚机可用。 图 19 备用池优化策略 图 19给出了备用池的优化策略。 除了图 16的隔夜换池的功能， 还必须有 临时切换到备用池的功能。并且要有在众多教室之间搜寻闲置池的功能。最后， 其实所有的虚机池都可以看成是备用池， 然后把教室和备用池按时间做动态的 指定 （dynamic assignment) 。 实现过程如下：

步骤 1901， 课程表发生临时改变；

步骤 1902， 把教室和备用池按时间做动态的指定；

步骤 1903， from time=9AM, next classtime to 10PM, Dec 31， 2010

步骤 1904， 清除所有的 pool.assigned = false

步骤 1905， For classroom=l to n

步骤 1906， For pool^l to n

步骤 1907， 判断教室是否在此时的课程表中。 若是， 转入到步骤 1905， 否则转入到步骤 1913 ;

步骤 1908， 判断 pool[l]. assigned = true? 若是， 转入到步骤 1905， 否则转 入到步骤 1909;

步骤 1909， 判断 VDIOptimalPolicy( )= EnergySaving? 若是， 转入到步骤

1910, 否则转入到步骤 1911 ;

步骤 1910， 判断 EnergyEfficiency (pool) < 60%?若是， 转入到步骤 1905， 否则转入到步骤 1911 ;

步骤 191 1， pool has not yet complete batch-revert? 若是，转入到步骤 1905， 否则转入到步骤 1912;

步骤 1912， Pool[l]. assigned = true; assigned_pair [time] = (classroom, pool)。 图 20 备用池使用策略一退出虚机

图 20 给出了备用池使用策略一退出虚机的过程。 备用池使用完后， 用户 要归还虚机， 退出备用池。 步骤如下：

步骤 2001， 用户发出退出虚机的请求 ；

步骤 2002， 系统将该虚机放入还原 （revert) 等待队列；

步骤 2003， 将该 desktop的状态置为还原 （REVERTING) 。 图 21 弹性池规则

图 21 给出了弹性池的规则图。 为了更加充分地利用虚机资源， 就不需要 把虚机池与教室静态绑定， 而是建立灵活的取用关系， 这就需要使用到一定的 规则。 其实现过程如下：

步骤 2101， 设置弹性池大小参数；

步骤 2102， 初始四种值 （ηήη= 始值， max=最大值， threshold门限值， 1"0 13100=预留值， 且 1< Threshold (阀值) Provision (预留） < min (初始） < max ) ；

步骤 2103， 判断用户是否请求虚机。 若是， 转入到步骤 2107， 否则转入 到步骤 2104; 步骤 2104， 判断用户是否归还虚机。 若是， 转入到步骤 2108， 否则转入 到步骤 2105 ;

步骤 2105， 非法操作， 报错；

步骤 2106， 无动作；

步骤 2107， 判断"闲置且 0\^1" 011的虚机<='1¾^1101(1，， 且闲置且 power on的机器+正在启动的虚机<= Provision' ? " 若是， 转入到步骤 2112， 否则转 入到步骤 2106;

步骤 2108， 找出该 pool中处于 idle (闲置） 状态超过一定时间的虚机； 步骤 2109， 判断" RUNNING - idle < min？ "。 若是， 转入到步骤 2113， 否 则转入到步骤 2110;

步骤 2110， 关闭的虚机数量= idle;

步骤 2111， 调用 clone, clone数量 = 'Provision，值;

步骤 2112， 判断是否有 Power off的虚机存在。 若是， 转入到步骤 2115， 否则转入到步骤 2111 ;

步骤 2113， 关闭的虚机数量= RUNNING - min ；

步骤 2114， 调用 power on虚机， 且调用 clone, clone数量 = 'Provision，值； 步骤 2115， 判断" Power off的虚机数量 < Provision- (闲置且 power on的机 器 +正在启动的虚机)？ "。 若是， 转入到步骤 2114， 否则转入到步骤 2116;

步骤 2116， 调用 power on虚机,数量 Provision- (闲置且 power on的机器 + 正在启动的虚机） 。 图 22-图 27给出了应用虚拟化、应用分层、虚机和虚拟应用程序的结合过 程。

图 22 预部署动作过程图

图 22给出了预部署动作的实现过程图。 预部署动作的目的是为了搜集用 户计算机的各种软硬件信息， 为后面的创建虚机模板提供依据。 其实现为客户 端和服务器的相互交互过程， 步骤如下- 步骤 2201， 客户端用户注册；

步骤 2202， 检査用户注册信息；

步骤 2203， 收集 PC信息并发送到服务器

步骤 2204， 保存基本的 pc信息；

步骤 2205， 收集注册表中所有的文件扩展信息并送到服务器；

步骤 2206， 保存用户文件链接信息；

步骤 2207， 从注册表査看用户是否安装了来自服务器的应用；

步骤 2208， 找到所有用户文件扩展的链接应用并返回客户端；

. 步骤 2209， 发送所有用户安装的应用到服务器；

步骤 2210， 保存用户安装的应用；

步骤 2211， 从注册表査看无法识别的路径并发给服务器；

步骤 2212， 保存其它的软件注册路径； 步骤 2213， 收集用户桌面快捷方式信息并发给服务器;

步骤 2214， 保存用户快捷方式信息；

步骤 2215， 上传用户个人的数据；

步骤 2216， 发送用户数据到服务器；

步骤 2217， 保存用户数据信息；

步骤 2218， 请用户提供 cd或上传 exe，dll;

步骤 2219， 列出未序列化的应用到客户端；

步骤 2220， 上传 exe或 dll;

步骤 2221， 保存用户上传的信息；

步骤 2222， 用户确认所有的信息；

步骤 2223， 服务器端确认结束。 图 23 预部署动作客户端序列表格图

图 23 给出了预部署动作客户端的序列表格图。 客户端的作用主要管理用 户的授权， 收集用户需要的计算机相关的信息。 实现步骤如下- 步骤 2301， 用户向客户端发出开始请求；

一 步骤 2302， 预部署动作客户端从活动目录 （AD ) 中搜集用户信息； 步骤 2303， 预部署动作客户端发送基信息到其服务器端；

步骤 2304， 判断返回是否成功。 若是， 转入到步骤 2306， 否则， 转入到 步骤 2305;

步骤 2305， 用户退出；

步骤 2306， 预部署动作客户端搜集相关的信息；

步骤 2307， 用户想选择相关的信息；

步骤 2308， 预部署动作客户端传送基信息、应用信息， 并上传相关的文件 到预部署动作服务器端；

步骤 2309， 预部署动作客户端向其服务器端发送结束通知；

步骤 2310， 用户最终确认；

步骤 2311 , 预部署动作客户端确认或取消；

步骤 2312， 用户退出。 图 24 SOD应用串流

图 24给出了 SOD应用串流的实现过程图。 在应用虚拟化的情况下， 应用 程序是从数据中心或者其它网络位置提供的，并在虚拟环境下的远程 client (客 户端） 上本地运行。 虚拟化应用程序在真空区中运行， 并且其操作独立于操作 系统和本地桌面上的其他应用程序。 它通过在计算机上模拟出软件使用的环 境， 从而达到在计算机上即使不安装软件， 也可以在虚拟环境中正常运行软件 的目的。 这意味着几种好处， 软件不再需要传统下载、 安装、 卸载步骤； 直接 使用软件， 无需重启、 等待时间； 不同应用程序兼容， 不产生冲突； 不再为应 用程序的故障、 更新、 迁移问题困扰。 SOD应用串流基于 Sequencer (序列器） 和 Client (客户端）两部分已准备好的基础上。 Sequencer部分的功能主要是对 Application suite (应用套装）进行虚拟化预处理， Sequencer的具体实现已在图 22中详细说明， client的功能主要是运行启动 Sequencer已经 sequence (序列化） 的 Application包中的应用程序， Client的具体实现己在图 23中详细说明。根据 实际需求， SOD客户端可以装在远程的终端客户设备上， 也可以安装在后台服 务点的虚机或实机上。 SOD应用串流实现步骤如下：

客户端的操作步骤为- 步骤 2401， 用户进入操作界面；

步骤 2402， 根据用户权限选择应用；

步骤 2403， 从应用列表査到应用 ID;

步骤 2404， 判断用户是否第一次使用该应用。 若是， 转入到步骤 2405， 否则转入到步骤 2407;

步骤 2405， 应用响应通过 config (配置） 文件连到 SOD 服务器端； 步骤 2406， 收到服务器端的应用文件流；

步骤 2407， 在客户端使用虚拟应用程序；

服务器端的操作步骤为：

步骤 2410， 启动服务器；

步骤 2411， 安装监控目录， 开启监控程序；

步骤 2412， 开始安装应用；

步骤 2413， 监控注册表、 安装到 C盘的文件等信息；

步骤 2414，判断安装过程是否结束。若安装过程结束，则转入到步骤 2415， 否则转入到步骤 2413 ;

步骤 2415， 收集各种文件信息， 注册表信息；

步骤 2416， 对文件进行排序；

步骤 2417， 封装打包成 tsap文件；

步骤 2418， 收到客户端发出的应用请求；

步骤 2419， 通过应用 ID查找到相应的应用；

步骤 2420， 将应用文件串流到客户端。 图 25 VDI和 SOD的结合

图 25描述的是 VDI与 SOD的结合的过程，主要通过将虚拟应用程序安装 在虚机上来实现。 当然在实际应用中， 也可以为用户提供多种选择， 用户既可 以使用虚机上的虚拟应用程序， 也可以使用虚机上实际安装的应用程序。 实现 过程如下：

步骤 2501， 搜集内存、 CPU、 应用、 主机、 操作系统等设置信息； 步骤 2502， 通过以上信息建立一条模板记录；

步骤 2503， 以模板记录信息创建虚机， 创建虚机的具体过程己在申请号为 "CN 200810204286.X"的专利中详细说明； 步骤 2504， 将 SOD客户端安装在虚机上；

步骤 2505， 提供镜像文件；

上述搜集的信息主要通过图 22 中预部署动作过程来得到的， 并以此信息 为依据， 构建模板。 用户请求使用虚机上的虚拟应用， SOD客户端程序会自动 找到后台服务器（SOD服务器端）上的应用， 然后将应用串流到虚机上， 用户 便可以使用虚机上的虚拟应用程序。 图 26 模板版本化

图 26描述了模板版本化的实现过程。 在公司组织内， 不同的部门往往有 不同的模板， 模板也往往会遇到升级更新的问题， 可以采用版本树的方法解决 模板版本化的问题， 实现过程如下：

步骤 2601， 将模板固定好；

步骤 2602， 装操作系统， 提供 image文件；

步骤 2603， 装 VDI, 确定模板上应部署的动作；

步骤 2604， 出现了新的模板要求， 更换新的模板版本；

步骤 2605， 构建版本树， 最初的版本设为树的根节点；

步骤 2606， 将新的版本放在树的叶节点上；

步骤 2607， 不断扩展树的子节点；

步骤 2608， 定期对版本树进行评估；

步骤 2609， 去掉冗余的老节点， 优化版本树。 图 27 分层虚拟桌面

图 27给出了分层虚拟桌面 （layered- VDI) 方法， 根据公司的组织形式将 桌面及其上的应用进行分层， 这样做有利于管理员进行分层管理， 不同的管理 员有不同的管理权限， 可以负责管理不同的层， 层与层之间是独立的， 层内是 相关的。从另一方面， 用户使用 VDI， 从本质上是使用虚拟桌面上的应用程序， 如何方便快捷安全地使用应用， 才能最大地体现 VDI的价值。 在本发明中， 从 下至上依次将虚拟桌面分为公司操作系统、 公司应用、 用户应用、 用户数据& 设置四个层次。 实现过程如下：

步骤 2701， 依据公司的组织形式分层： 从下至上依次为公司操作系统、 公 司应用、 用户应用、 用户数据&设置；

步骤 2702， 采用虚拟工作空间管理器对每层分别进行管理；

步骤 2703， 设置不同的管理员和用户权限： 电信级管理员、 公司操作系统 管理员、 公司应用管理员、 用户权限设置；

步骤 2704， 不同的管理员根据相应的权限进入自己的管理界面； 步骤 2705， 管理员对相应职责内的应用进行管理； 图 28超范围屏幕显示 图 28 描述了本发明的虚拟桌面基础架构用于证券公司的一较佳实施例， 主要用于解决证券公司的一个会话横跨多个屏幕显示的问题。 图 28 给出了当 显示数据超过屏幕范围吋， 如何用多个屏幕显示数据的工作过程图。 主要思想 是： 应用代理由两部分组成， 一部分 （高端的） 叫应用生成器， 底端的叫虚拟 接口。 当应用跑起来后， 虚拟接口侦测写在显示内存上的应用数据， 如果超过 屏幕范围就计算超出的屏幕个数， 并通知应用生成器为每个超出的屏幕生成一 个进程。 将原应用的屏幕和生成的进程的屏幕一起发送到客户端。 具体流程如 下：

步骤 2801， 客户端选择应用请求虚机 /实机 （客户端发出请求的方式是多 样的， 可以是某一个设备发出请求， 也可以是用户开机时自动生成的） ；

步骤 2802， 请求到达后台服务点 （请求被传送到后台服务点） ； 步骤 2803， 应用代理打开相应的应用程序；

步骤 2804， 判断应用是否正常启动。 如果应用启动， 转入到步骤 2806， 否则转入到步骤 2805;

步骤 2805， 告诉客户端应用启动失败， 报错， 此次请求结束；

步骤 2806， 一旦获知应用已经启动， 应用代理自动监测应用数据； 步骤 2807，判断显示数据是否超出了屏幕范围。若超过，转入到步骤 2808， 否则转入到步骤 2809;

步骤 2808， 计算显示数据超出的屏幕个数， 应用代理生成相应个数的进程 (一个进程就是一个应用） ；

步骤 2809， 启动 spice服务器， 将应用屏幕发往客户端；

步骤 2810， 启动 spice服务器， 将原应用的屏幕和生成的进程的屏幕发送 到客户端；

步骤 2811， 客户端接收屏幕， 在显示器上显示。 图 29 屏幕分区显示

图 29描述了本发明的虚拟桌面基础架构用于工厂的一较佳实施例， 主要 用于解决工厂的多个会话在一个大的屏幕上显示的问题。 图 29 给出了屏幕分 区显示的工作过程图。 主要是为了解决将一个大屏幕分成多个区， 每个区显示 不同的内容的问题。 主要思想是： 在客户端为一个大屏幕的每个分区设置相同 的 IP地址， 不同的 TCP端口号， 以此来区分每个分区， 根据请求虚拟桌面的 分区的 IP地址和 TCP端口号， 将虚拟桌面返回到该分区上。 工作过程如下： 步骤 2901， 客户端将同一显示屏的不同分区设置同一 IP 地址的不同端口 号；

步骤 2902， 用户 （选择应用） 请求虚机 /实机；

步骤 2903， 请求到达后台服务点；

步骤 2904， 判断客户端是否要求 seamless (无缝的） （seamless是指客户 端是否要求一打开电脑， 接收的第一屏幕不是桌面， 而是应用程序） 。 如果是， 转入到步骤 2905， 否则转入到步骤 2906; 步骤 2905， 应用代理查看应用列表；

步骤 2906， 应用代理打开应用；

步骤 2907， 找到应用并启动应用；

步骤 2908， 启动 spice服务器， 将屏幕返回到客户端；

步骤 2909， 客户端根据 IP和端口号把应用屏幕送到相应的显示屏区域; 步骤 2910， 刷新屏幕。 上述实施例是提供给熟悉本领域内的人员来实现或使用本发明的， 熟悉本 领域的人员可在不脱离本发明的发明思想的情况下， 对上述实施例做出种种修 改或变化， 因而本发明的保护范围并不被上述实施例所限， 而应该是符合权利 要求书提到的创新性特征的最大范围。

Claims

权 利 要 求

1. 一种多维智能服务点虚拟桌面基础架构， 其特征在于， 包括- 后台服务点， 在后台产生虚机和虚拟应用程序， 后台服务点对虚机、 虚拟 应用程序、 实机进行集中控制并分派给用户；

业务交换点， 连接到后台服务点， 业务交换点提供呼叫连续和业务交换服 务， 把经交换后的实机 /虚机请求送到后台服务点， 同时控制业务交换服务； 访问接入点， 连接到业务交换点， 访问接入点提供远程访问管理和连接服 务， 同时控制访问接入服务；

客户设备， 连接到访问接入点， 客户设备选自下述之一： 个人电脑、 笔记 本电脑、 上网本、 手机、 手持终端。

2. 如权利要求 1 所述的多维智能服务点虚拟桌面基础架构， 其特征在于， 所 述后台服务点包括- 实机管理中心， 管理后台的实机并向用户分派实机；

虚机管理中心， 管理后台的虚机并向用户分配虚机；

虚拟应用管理器， 生成并管理后台的虚拟应用程序并建立虚拟应用程序和 虚机的结合；

虚拟工作空间管理器， 对虚拟应用进行分层管理；

虚拟化基础平台， 使用基于内核的虚机 （KVM) 对硬件设备进行虚拟化。

3. 如权利要求 2所述多维智能服务点虚拟桌面基础架构， 其特征在于， 所述 实机管理中心包括：

实机连接管理器， 接受用户使用实机的请求， 检査实机的状态， 将用户要 使用的应用 （application) 消息通过代理控制器发送给代理， 并返回给业务交 换点；

实机状态管理器， 负责监控物理计算机或者实机的状态及状态的转换； 代理控制器， 负责接收代理发送的消息， 发送操作应用的指令给代理， 并 检查代理发送的心跳 （heart beat) 消息以作出是否关闭实机的判断；

实机列表， 用户可以注册与自己的账号绑定的实机到实机列表中； 实机应用列表， 用户指定的使用的应用程序的列表；

使用情况报表， 统计用户使用实机和应用的情况。

4. 如权利要求 2所述的多维智能服务点虚拟桌面基础架构， 其特征在于， 所 述虚拟化基础平台包括- 基于终端协议的独立计算环境简单协议 （Spice ) 服务器、 会话发起协议 SIP服务器，所述 Spice服务器和会话发起协议 SIP服务器用于与客户设备交互。

5. 如权利要求 1 所述的多维智能服务点虚拟桌面基础架构， 其特征在于， 所 述业务交换点包括：

虚机交换器和实机交换器， 根据用户的请求， 连接到请求响应的虚机管理 中心或者实机管理中心；

业务交换服务控制器， 提供包括呼叫接续服务、业务交换服务、负载均衡、 规则和策略引擎、 覆盖网 （Overlay)管理、 服务监控、 SIP服务以及服务接口。

6. 如权利要求 5 所述的多维智能服务点虚拟桌面基础架构， 其特征在于， 所 述虚机交换器包括： 座位与教室管理数据库。

7. 如权利要求 1 所述的多维智能服务点虚拟桌面基础架构， 其特征在于， 所 述访问接入点包括：

远程访问 （RAS ) 服务器， 管理远程访问， 当用户在防火墙外则为用户建 立虚拟专有网络 （VPN) 连接；

连接代理， 提供客户端接入通道， 并向客户端传输桌面屏幕与应用屏幕， 同时为后台的虚机和实机提供连接。 '

8. 如权利要求 1 所述的多维智能服务点虚拟桌面基础架构， 其特征在于， 所 述访问接入点进一步包括：

访问接入服务控制器， 为访问接入提供网络服务。

9. 如权利要求 8 所述的多维智能服务点虚拟桌面基础架构， 其特征在于， 所 述访问接入服务控制器包括：

负载均衡器， 提供负载均衡服务；

服务监控器， 对服务请求进行监控和统计；

SIP代理服务器， 接收虚拟桌面请求， 决定将这些请求传送到何处， 并且 将它们传送到下一服务器；

覆盖 （Overlay) 管理器， 提供 SIP Overlay管理；

管理控制台， 提供管理控制界面。

10.如权利要求 7所述的多维智能服务点虚拟桌面基础架构， 其特征在于， 所 述连接代理提供客户端接入通道进一步包括： 根据用户的登录信息在认证中心生成凭据， 并对凭据进行加密， 以完成统 认证授权与单点登录 （SSO) 。

11.一种多维智能服务点虚拟桌面方法， 其特征在于， 该方法包括：

使用访问接入点、 业务交换点、 后台服务点控制虚拟桌面的生成、 分派以 及传输；

其中后台服务点接收业务交换点发送的虚拟桌面请求， 根据请求的业务在 后台产生虚机和虚拟应用程序， 后台服务点对虚机、 虚拟应用程序、 实机进行 集中控制并分派给请求方；

业务交换点接收来自访问接入点的虚拟桌面请求， 对请求进行业务交换控 制， 把经交换后的请求送到后台服务点；

访问接入点接收来自客户设备的虚拟桌面请求， 对请求进行访问接入控 制， 并将请求转发到业务交换点。

12.如权利要求 11所述的多维智能服务点虚拟桌面方法， 其特征在于， 进一步 包括：

使用 SIP 认证注册机制对客户设备和用户进行身份验证,在认证注册时进 行机器能力的协商， 其中客户设备连接到访问接入点， 并经访问接入点连接到 业务交换点和后台服务点， 客户设备选自下述之一： 个人电脑、 笔记本电脑、 上网本、 手机、 手持终端。

13.如权利要求 12所述的多维智能服务点虚拟桌面方法， 其特征在于， 进一步 包括：

使用 SIP协议创建会话并建立客户设备和后台服务点之间的连接； 后台服务点査询客户设备的能力；

启动 Spice协议将虚拟桌面屏幕从后台服务点传送到客户设备上； 屏幕传送完毕后， 使用 SIP协议结束会话。

14.如权利要求 12所述的多维智能服务点虚拟桌面方法， 其特征在于， 进一步 包括：

通过 SIP代理服务器的时间机制将多个会话进行汇聚， 以使多个用户使用 一个虚机；

通过 SIP 代理服务器使一个用户可以获得多个会话,以使一个用户可以同 时使用多个虚机。

15.如权利要求 12所述的多维智能服务点虚拟桌面方法， 其特征在于， 进一步 包括- 将同一 SIP会话的事务请求分配到相同的 SIP服务器，

以 SIP会话为基本单元来计算负载开支的负载分配。

16.如权利要求 12所述的多维智能服务点虚拟桌面方法， 其特征在于， 进一步 包括：

使用 SIP服务器及其连接建立虚拟 SIP Overlay的方法， 在 Overlay节点 对 Overlay进行管理， SIP端口接受信令， Spice端口接受虚机屏幕。

17.如权利要求 12所述的多维智能服务点虚拟桌面方法， 其特征在于， 进一步 包括：

通过 SIP客户端和 SIP服务器协议栈实现虚拟桌面的端对端传输的方法。

18.—种虚机池管理方法， 其特征在于， 包括：

设置初始值、 最大值、 门限值及预留值；

设定初始值、 最大值、 门限值及预留值之间的逻辑关系，

根据所述初始值、 最大值、 门限值及预留值以及它们之间的逻辑关系实现 从虚机池取用虚机的规则。

19.如权利要求 18所述的虚机池管理方法， 其特征在于， 进一步包括- 采用链接克隆 （linked-clone) 技术生成与主虚机池相对应的备用池， 并将 备用池设置成暂停（suspend)状态， 将备用池里的虚机与主虚机池中的虚机配 合使用。

20.如权利要求 18所述的虚机池管理方法， 其特征在于， 进一步包括：

将备用池按时间做动态的指定， 搜寻闲置池的备用池优化策略。

21.—种将虚拟应用程序和虚机结合的方法， 其特征在于， 包括- 在服务器端安装监控程序；

监控程序收集文件信息和注册表信息， 并封装打包成 SOD应用 （tsap ) 文 件；

根据客户端对应用的请求， 将 tsap文件串流到客户端供用户使用。

22.如权利要求 21所述的方法， 其特征在于， 进一步包括: 根据已有的用户机器信息创建模板记录， 并将随需而动的服务（Service on Demand, SOD) 客户端装在虚机上。

23.如权利要求 21所述的方法， 其特征在于， 进一步包括：

将虚机及虚机上的应用程序分成四个层： 公司操作系统、 公司应用、 用户 应用、 用户数据和设置， 并采用虚拟工作空间对所述四个层进行管理。

24.—种采用虚拟桌面基础架构的超范围屏幕显示方法， 其特征在于， 包括： 设置后台服务点， 后台服务点在后台产生虚机和虚拟应用程序， 后台服务 点对虚机、 虚拟应用程序、 实机进行集中控制并分派给用户；

在后台服务点设置应用代理， 应用代理包括两部分： 高端部分为应用生成 器， 底端部分为虚拟控制台；

启动应用程序， 虚拟控制台侦测写在显示内存上的应用数据， 如果超过屏 幕范围就计算超出的屏幕个数， 并通知应用生成器为每个超出的屏幕生成一个 进程；

将原应用的屏幕和生成的进程的屏幕一起发送到客户端。

25.—种采用虚拟桌面基础架构的屏幕分区显示方法， 其特征在于， 包括： 在客户端为一个大屏幕的每个分区设置相同的 IP地址以及不同的 TCP端 口号；

根据发出虚拟桌面请求的分区的 IP地址和 TCP端口号， 将虚拟桌面返回 到该分区上。