用于替换虚拟机盘的方法和系统
阅读：1028发布：2020-08-15
专利汇可以提供用于替换虚拟机盘的方法和系统专利检索，专利查询，专利分析的服务。并且至少一个目标虚拟盘描述符与至少一个源虚拟盘描述符合并，该目标虚拟盘描述符描述与目标虚拟化环境中的现有目标 虚拟机 关联的至少一 块 虚拟盘，该源虚拟盘描述符描述与源关联的至少一块虚拟盘。执行该合并，以获取和目标虚拟化环境兼容的至少一个合并的虚拟盘描述符。根据至少一个合并的虚拟盘描述符，用与源关联的至少一块虚拟盘来替换与目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘。，下面是用于替换虚拟机盘的方法和系统专利的具体信息内容。
1.一种用于替换虚拟机盘的方法，包括：
将至少一个目标虚拟盘描述符与至少一个源虚拟盘描述符合并以获取和所述目标虚拟化环境兼容的至少一个合并的虚拟盘描述符，该目标虚拟盘描述符描述与目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘，该源虚拟盘描述符描述与源关联的至少一块虚拟盘；以及
根据所述至少一个合并的虚拟盘描述符，用与所述源关联的所述至少一块虚拟盘来替换与所述目标虚拟化环境中的所述现有目标虚拟机关联的所述至少一块虚拟盘。
2.如权利要求1所述的方法，其中，在所述合并和替换步骤中，所述虚拟化环境包括目标云环境。
3.如权利要求2所述的方法，其中：
所述源包括在所述目标云环境外部的客户源；并且
所述替换包括将与所述源关联的所述至少一块虚拟盘迁移到与所述现有目标虚拟机关联的所述至少一块虚拟盘。
4.如权利要求3所述的方法，还包括比较以下两者的虚拟资源：
与所述现有目标虚拟机关联的至少一块虚拟盘；以及
与所述目标云环境外部的所述客户源关联的所述至少一块虚拟盘；
其中，所述合并响应于所述虚拟资源的所述比较表明其兼容性。
5.如权利要求4所述的方法，还包括检查所述合并步骤的成功，其中，所述替换是响应于所述检查表明所述合并步骤的所述成功。
6.如权利要求3所述的方法，还包括针对至少一个额外的源虚拟盘来重复所述合并和替换步骤。
7.如权利要求6所述的方法，还包括更新整体实例描述符。
8.如权利要求1所述的方法，其中，所述合并包括：
检查与所述至少一个源虚拟盘描述符关联的至少一个源属性；
检查与所述至少一个目标虚拟盘描述符关联的至少一个目标属性；以及
将多个合并规则应用于所述至少一个源属性和所述至少一个目标属性，以获取所述至少一个合并的虚拟盘描述符；
其中，所述合并规则在所述至少一个合并的虚拟盘描述符中持久化源属性和目标属性，所述源属性是确保所述目标虚拟化环境中继续的虚拟机运行所需的，且所述目标属性是所述目标虚拟化环境成功地采用所述虚拟机所需的。
9.如权利要求8所述的方法，其中，在所述应用步骤中，所述合并规则包括：
持久化与所述源关联的所述至少一块虚拟盘的虚拟盘输入-输出控制器；
持久化与所述源关联的所述至少一块虚拟盘的块大小和块数量；
持久化与所述现有目标虚拟机关联的所述至少一块虚拟盘的虚拟盘唯一描述符。
10.如权利要求1所述的方法，还包括转换源实例以获取源盘映像。
11.如权利要求1所述的方法，其中：
所述目标虚拟机具有目标虚拟机配置；
所述目标虚拟机被容纳在目标管理程序上；并且
在所述合并步骤中，与所述目标虚拟化环境的所述兼容性至少包括与所述目标虚拟机配置和所述目标管理程序的兼容性。
12.如权利要求11所述的方法，其中，所述目标虚拟机具有目标操作系统；并且其中，与所述目标虚拟化环境的所述兼容性还包括与所述目标操作系统的兼容性。
13.如权利要求1所述的方法，其中：
所述源包括备份源；并且
所述替换包括使用与所述备份源关联的至少一个盘映像来恢复与所述现有目标虚拟机关联的所述至少一块虚拟盘。
14.如权利要求1所述的方法，其中，在用与所述源关联的所述至少一块虚拟盘来替换与所述目标虚拟化环境中的所述现有目标虚拟机关联的所述至少一块虚拟盘时，在所述替换之前和之后维护所述现有目标虚拟机的唯一描述符。
15.如权利要求1所述的方法，还包括提供一种系统，其中，所述系统包括单独的软件模块，每个单独的软件模块在计算机可读的存储介质中实现，并且其中，所述单独的软件模块包括MergeDiskMetaData模块和PutDisk模块；
其中
由在至少一个硬件处理器上执行的所述MergeDiskMetaData模块来执行所述合并；并且；
由在至少一个硬件处理器上执行的所述PutDisk模块来执行所述替换。
16.一种用于替换虚拟机盘的系统，该系统包括装置，其被配置为执行如权利要求1到
15中的任何一个所述的方法步骤。
用于替换虚拟机盘的方法和系统
技术领域
背景技术
发明内容
[0003] 本发明的原理提供用于替换虚拟机盘的技术。
[0004] 在一个方面，示例性方法包括将至少一个目标虚拟盘描述符与至少一个源虚拟盘描述符进行合并的步骤，该目标虚拟盘描述符描述与目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘，该源虚拟盘描述符描述与源关联的至少一块虚拟盘。执行该合并，以获取和目标虚拟化环境兼容的至少一个合并的虚拟盘描述符。进一步的步骤包括根据至少一个合并的虚拟盘描述符、用与源关联的至少一块虚拟盘来替换与目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘。
[0005] 如这里所使用的，“促进”一动作包括执行该动作、使该动作更容易、帮助执行该动作、或使得该动作被执行。于是，作为示例而不是限制，在一个处理器上执行的指令可以通过发送合适的数据或命令使得或帮助动作被执行，促进在远程处理器上执行的指令所执行的动作。为了避免疑问，在操作者通过执行动作之外来促进动作时，该动作仍然是由某个实体或实体组合来执行的。
[0006] 本发明的一个或多个实施例或其元素可以以计算机程序产品的形式来实现，该计算机程序产品包括具有用于执行所指出的方法步骤的计算机可用程序代码的计算机可读存储介质。此外，本发明的一个或多个实施例或其元素可以以系统（或装置）的形式来实现，该系统（或装置）包括存储器以及至少一个处理器，该处理器耦合到存储器且可操作地执行示例性方法步骤。另外，在另一方面，本发明或的一个或多个实施例其元素可以以装置的形式来实现，该装置用于实现这里描述的一个或多个方法步骤；该装置可以包括：(i)软件模块，其被存储在计算机可读存储介质（或多个这样的介质）中并且可以在硬件处理器上实现，或者(ii)软件模块或某些硬件模块的组合；以及(i)-(ii)中的任一个实现这里阐述的特定技术。
[0007] 本发明的技术可以提供非常有益的技术效果。例如，一个或多个实施例可以提供下列优势中的一个多个：
[0008] ·提供用与源虚拟机关联的一块或多块虚拟盘来替换与目标虚拟机关联的相同数量的虚拟盘的能力；
[0009] ·使得托管云（managed cloud）等能够导入现有的虚拟机和/或虚拟机映像；
[0010] ·使虚拟机能恢复到之前的状态。
附图说明
[0012] 图1示出了根据本发明的实施例的云计算节点；
[0013] 图2示出了根据本发明的实施例的云计算环境；
[0014] 图3示出了根据本发明的实施例的抽象模型层；
[0015] 图4示出了根据本发明的方面的高阶流程图；
[0016] 图5示出了根据本发明的方面的详细流程和框图；
[0017] 图6示出了根据本发明的方面的示例性系统框图；
[0018] 图7示出了根据本发明的方面的示例性系统图，其包含重要阶段的系统状态；
[0019] 图8示出了根据本发明的方面的在源环境中并且迁移到云之后的当前服务器；
[0020] 图9和10示出了图8的服务的替代迁移方法；
[0021] 图11示出了根据本发明的方面的示例性供应流程；
[0022] 图12示出了根据本发明的实施例的实例捕获；
[0023] 图13示出了根据本发明的实施例的采用和调整过程；
[0024] 图14示出了根据本发明的实施例的“创建服务器”弹出的示例性屏幕视图；
[0025] 图15示出了根据本发明的方面的供应流程中的调整的示例性概览；
[0026] 图16示出了根据本发明的方面的组合流程图和框图；
[0027] 图17示出了根据本发明的一个或多个方面的要被迁移到目标环境的源环境；
[0028] 图18示出了根据本发明的一个或多个方面的图5中的源环境可迁移至的目标环境；
[0029] 图19示出了根据本发明的一个或多个方面的用于云迁移的管理基础架构分析中的示例性阶段；
[0031] 图21示出了根据本发明的一个或多个方面的用于服务器的小子集的非限制示例性结果；
[0032] 图22示出了根据本发明的方面的示例性系统框图；
[0033] 图23示出了根据本发明的方面的示例性快照管理器；
[0034] 图24示出了根据本发明的方面的基于虚拟映像库的示例性实现；
[0035] 图25示出了根据本发明的方面的示例性回滚至长期快照；
[0036] 图26是根据本发明的方面的流程图，示出了计算在迁移期间对映像做出的确切改变的步骤；
[0037] 图27是根据本发明的方面的示例性过程流；并且
[0038] 图28是根据本发明的方面的快照管理系统的示例性软件架构图；
[0039] 图29示出了根据本发明的方面的示例性系统图；
[0040] 图30示出了根据本发明的示例性方法；
[0041] 图31示出了根据本发明的方面的示例性“交换”流程图；
[0042] 图32示出了根据本发明的方面的示例性“合并虚拟资源描述符”流程图；
[0043] 图33示出根据本发明的方面的另一示例性系统图；
[0044] 图34示出了虚拟机映像和实例的相关方面；
[0045] 图35示出了根据本发明的方面的虚拟机资源描述符的第一实施例；
[0046] 图36示出了根据本发明的方面的虚拟机资源描述符的第二实施例；
[0047] 图37是根据本发明的方面的用于更新目标虚拟机描述符的示例性方法步骤的流程图；
[0048] 图38是根据本发明的方面的示例性预备方法步骤的流程图；
[0049] 图39是根据本发明的方面的示例性软件架构图；
[0051] 图41示出了根据本发明的方面的样本离线调整的流程；
[0052] 图42示出了根据本发明的方面的示例性流程图；
[0053] 图43示出了根据本发明的方面的示例性标准化架构；
[0054] 图44-46示出了根据本发明的方面的示例性调整阶段；
[0055] 图47示出了根据本发明的方面的示例性架构。
具体实施方式
[0056] 云计算是一种服务交付模式，用于对共享的可配置计算资源池进行方便、按需的网络访问。可配置计算资源是能够以最小的管理成本或与服务提供者进行最少的交互就能快速部署和释放的资源，例如可以是网络、网络带宽、服务器、处理、内存、存储、应用、虚拟机和服务。这种云模式可以包括至少五个特征、至少三个服务模型和至少四个部署模型。
[0057] 特征包括：
[0058] 按需自助式服务：云的消费者在无需与服务提供者进行人为交互的情况下能够单方面自动地按需部署诸如服务器时间和网络存储等的计算能力。
[0060] 资源池：提供者的计算资源被归入资源池并通过多租户模式服务于多重消费者，其中按需将不同的实体资源和虚拟资源动态地分配和再分配。一般情况下，消费者不能控制或甚至并不知晓所提供的资源的确切位置，但可以在较高抽象程度上指定位置（例如国家、州或数据中心），因此具有位置无关性。
[0061] 迅速弹性：能够迅速、有弹性地（有时是自动地）部署计算能力，以实现快速扩展，并且能迅速释放来快速缩小。在消费者看来，用于部署的可用计算能力往往显得是无限的，并能在任意时候都能获取任意数量的计算能力。
[0062] 可测量的服务：云系统通过利用适于服务类型（例如存储、处理、带宽和活跃用户帐号）的某种抽象程度的计量能力，自动地控制和优化资源效用。可以监测、控制和报告资源使用情况，为服务提供者和消费者双方提供透明度。
[0063] 服务模型如下：
[0064] 软件即服务(SaaS)：向消费者提供的能力是使用提供者在云基础架构上运行的应用。可以通过诸如网络浏览器的瘦客户机接口（例如基于网络的电子邮件）从各种客户机装置访问应用。除了有限的特定于用户的应用配置设置外，消费者既不管理也不控制包括网络、服务器、操作系统、存储、乃至单个应用能力等的底层云基础架构。
[0065] 平台即服务(PaaS)：向消费者提供的能力是在云基础架构上部署消费者创建或获得的应用，这些应用利用提供者支持的程序设计语言和工具创建。消费者既不管理也不控制包括网络、服务器、操作系统或存储的底层云基础架构，但对其部署的应用具有控制权，对应用管理环境配置可能也具有控制权。
[0066] 基础架构即服务（IaaS）：向消费者提供的能力是消费者能够在其中部署并运行包括操作系统和应用的任意软件的处理、存储、网络和其他基础计算资源。消费者既不管理也不控制底层的云基础架构，但是对操作系统、存储和其部署的应用具有控制权，对选择的网络组件（例如主机防火墙）可能具有有限的控制权。
[0067] 部署模型如下：
[0068] 私有云：云基础架构单独为某个组织运行。云基础架构可以由该组织或第三方管理并且可以存在于该组织内部或外部。
[0069] 共同体云：云基础架构被若干组织共享并支持有共同利害关系（例如任务使命、安全要求、政策和合规考虑）的特定共同体。共同体云可以由共同体内的多个组织或第三方管理并且可以存在于该共同体内部或外部。
[0070] 公共云：云基础架构向公众或大型产业群提供并由出售云服务的组织拥有。
[0071] 混合云：云基础架构由两个或更多部署模型的云（私有云、共同体云或公共云）组成，这些云依然是独特的实体，但是通过使数据和应用能够移植的标准化技术或私有技术（例如用于云之间的负载平衡的云突发流量分担技术）绑定在一起。
[0072] 云计算环境是面向服务的，特点集中在无状态性、低耦合性、模块性和语意的互操作性。云计算的核心是包含互连节点网络的基础架构。
[0073] 现在参考图1，其中显示了云计算节点的一个例子。图1显示的云计算节点10仅仅是适合的云计算节点的一个示例，不应对本发明实施例的功能和使用范围带来任何限制。总之，云计算节点10能够被用来实现和/或执行在此所述的任何功能。
[0074] 云计算节点10具有计算机系统/服务器12，其可与众多其它通用或专用计算系统环境或配置一起操作。众所周知，适于与计算机系统/服务器12一起操作的计算系统、环境和/或配置的例子包括但不限于：个人计算机系统、服务器计算机系统、瘦客户机、厚客户机、手持或膝上装置、基于微处理器的系统、机顶盒、可编程消费电子产品、网络个人电脑、小型计算机系统﹑大型计算机系统和包括上述任意系统的分布式云计算技术环境，等等。
[0075] 计算机系统/服务器12可以在由计算机系统执行的计算机系统可执行指令（诸如程序模块）的一般语境下描述。通常，程序模块可以包括执行特定的任务或者实现特定的抽象数据类型的例程、程序、目标程序、组件、逻辑、数据结构等。计算机系统/服务器12可以在通过通信网络链接的远程处理装置执行任务的分布式云计算环境中实施。在分布式云计算环境中，程序模块可以位于包括存储装置的本地或远程计算系统存储介质上。
[0076] 如图1所示，云计算节点10中的计算机系统/服务器12以通用计算装置的形式表现。计算机系统/服务器12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件（包括系统存储器28和处理单元16）的总线18。
[0077] 总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构（ISA）总线，微通道体系结构（MAC）总线，增强型ISA总线、视频电子标准协会（VESA）局域总线以及外围组件互连（PCI）总线。
[0078] 计算机系统/服务器12典型地包括多种计算机系统可读介质。这些介质可以是能够被计算机系统/服务器12访问的任意可获得的介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
[0079] 系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器（RAM）30和/或高速缓存存储器32。计算机系统/服务器12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质（图1未显示，通常称为“硬盘驱动器”）。尽管图1中未示出，可以提供用于对可移动非易失性盘（例如“软盘”）读写的盘驱动器，以及对可移动非易失性光盘（例如CD-ROM,DVD-ROM或者其它光介质）读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品，该程序产品具有一组（例如至少一个）程序模块，这些程序模块被配置以执行本发明各实施例的功能。
[0080] 具有一组（至少一个）程序模块42的程序/实用工具40，可以存储在存储器28中，这样的程序模块42包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本发明所描述的实施例中的功能和/或方法。
[0081] 计算机系统/服务器12也可以与一个或多个外部装置14（例如键盘、指向装置、显示器24等）通信，还可与一个或者多个使得用户能与该计算机系统/服务器12交互的装置通信，和/或与使得该计算机系统/服务器12能与一个或多个其它计算装置进行通信的任何装置（例如网卡，调制解调器等等）通信。这种通信可以通过输入/输出（I/O）接口22进行。并且，计算机系统/服务器12还可以通过网络适配器20与一个或者多个网络（例如局域网（LAN），广域网（WAN）和/或公共网络，例如因特网）通信。如图所示，网络适配器20通过总线18与计算机系统/服务器12的其它模块通信。应当明白，尽管图中未示出，其它硬件和/或软件模块可以与计算机系统/服务器12一起操作，包括但不限于：微代码、装置驱动器、冗余处理单元、外部盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
[0082] 现在参考图2，其中显示了示例性的云计算环境50。如图所示，云计算环境50包括云计算消费者使用的本地计算装置可以与其相通信的一个或者多个云计算节点10，本地计算装置例如可以是个人数字助理（PDA）或移动电话54A，台式电脑54B、笔记本电脑54C和/或汽车计算机系统54N。云计算节点10之间可以相互通信。可以在包括但不限于如上所述的私有云、共同体云、公共云或混合云或者它们的组合的一个或者多个网络中将云计算节点10进行物理或虚拟分组（图中未显示）。这样，云的消费者无需在本地计算装置上维护资源就能请求云计算环境50提供的基础架构即服务（IaaS）、平台即服务（PaaS）和/或软件即服务（SaaS）。应当理解，图2显示的各类计算装置54A-N仅仅是示意性的，云计算节点10以及云计算环境50可以与任意类型网络上和/或网络可寻址连接的任意类型的计算装置（例如使用网络浏览器）通信。
[0083] 现在参考图3，其中显示了云计算环境50（图2）提供的一组功能抽象层。首先应当理解，图3所示的组件、层以及功能都仅仅是示意性的，本发明的实施例不限于此。如图3所示，提供下列层和对应功能：
[0084] 硬件和软件层60包括硬件和软件组件。硬件组件的例子包括：主机，例如系统；基于RISC（精简指令集计算机）体系结构的服务器，例如IBM系统；IBM 系统;IBM 系统；存储装置；网络和网络
组件。软件组件的例子包括：网络应用服务器软件，例如IBM 应用服务器软
件；数据库软件，例如IBM 数据库软件。（IBM,zSeries,pSeries,xSeries,
BladeCenter,WebSphere以及DB2是国际商业机器公司在全世界各地的注册商标)。
组件。软件组件的例子包括：网络应用服务器软件，例如IBM 应用服务器软
件；数据库软件，例如IBM 数据库软件。（IBM,zSeries,pSeries,xSeries,
BladeCenter,WebSphere以及DB2是国际商业机器公司在全世界各地的注册商标)。
[0085] 虚拟层62提供一个抽象层，该层可以提供下列虚拟实体的例子：虚拟服务器、虚拟存储、虚拟网络（包括虚拟私有网络）、虚拟应用和操作系统，以及虚拟客户端。
[0086] 在一个示例中，管理层64可以提供下述功能：资源供应功能：提供用于在云计算环境中执行任务的计算资源和其它资源的动态获取；计量和定价功能：在云计算环境内对资源的使用进行成本跟踪，并为此提供帐单和发票。在一个例子中，该资源可以包括应用软件许可。安全功能：为云的消费者和任务提供身份认证，为数据和其它资源提供保护。用户门户功能：为消费者和系统管理员提供对云计算环境的访问。服务水平管理功能：提供云计算资源的分配和管理，以满足必需的服务水平。服务水平协议（SLA）计划和履行功能：为根据SLA预测的对云计算资源未来需求提供预先安排和供应。
[0087] 工作负载层66提供云计算环境可能实现的功能的示例。在该层中，可提供的工作负载或功能的示例包括：地图绘制与导航；软件开发及生命周期管理；虚拟教室的教学提供；数据分析处理；交易处理；以及移动桌面。
[0088] 迁移到托管云
[0089] 硬件基础架构即服务（HIaaS）云提供基本（bare-bone）虚拟机作为服务。它还可以提供操作系统（OS）甚至软件，但典型地不会为OS或软件提供支持。托管基础机构即服务（MIaaS）云提供全服务的虚拟机。服务例如可以包括OS补丁并支持OS的安全性和合规性。MIaaS的一个显著方面是通过下列方式实现更简单的管理：标准化为特定的一组目录映像，实例从该组映像生成；在部署期间将这些实例自动链接到管理工具；以及/或不给客户OS级别的管理权限，从而实例上的操作系统保持为云管理员配置它们的样子。
[0090] MIaaS云不会自然地具有外部实例的导入或注册特征，因为MIaaS的一个显著方面是通过下列方式实现更简单的管理：标准化为特定的一组目录映像，实例从该组映像生成；在部署期间将这些实例自动链接到管理工具；以及，典型地，不给客户OS级别的管理权限，从而实例上的操作系统可保持为云管理员配置它们的样子。因此，在迁移到MIaaS云时，简单地使用源实例上的P2V（物理到虚拟）转换，或直接地复制已经虚拟化的实例，然后期望它们在云管理程序（cloud hypervisor）上运行，通常是不可行的。这是因为它们将无法满足上述标准（通过所述标准更简单的管理在MIaaS云中实现），因此它们对于MIaaS云的管理来说是不可接受的。
[0091] 此外，关于MIaaS云，标准注册（即使得新实例为通用IaaS云管理系统以及MIaaS云的特定管理系统所知）典型地被内置于从目录映像的供应（provisioning）中。有利地，一个或多个实施例提供了新的注册过程，其中，外部实例可被包含在到MIaaS云的迁移中。确实，一个或多个实施例有利地提供了一种系统和方法，用于快速地迁移到MIaaS（且更一般地，IaaS）云。该方法包括实例以映像形式传送至云；（运行中或映像形式的）实例调整为云标准；以及实例注册到云OSS和BSS系统（运行和业务支持系统）中。可选的附加步骤解决之前的分析、测试和处理失败，以及/或开始和结束改变窗口以及实际停机时间，以最小化风险和运行中断。
[0092] 一个或多个实施例有利地提供了一种系统化（以及甚至自动化）的将客户实例快速地迁移到MIaaS云中的方法，其不涉及重新安装过程。一个或多个实施例可用于MIaaS云迁移，并且能够进行物理到虚拟风格的实例导入。
[0093] 一个或多个实施例提升了对基础架构自身以及该基础架构的管理两者进行标准化的能力。相信这样的标准化将转而允许降低IT运行成本并允许进一步的自动化。一个或多个实施例提供了一种迁移到MIaaS云的技术，它比需要重新安装的技术要便宜地多。
[0094] 如上所述，一个或多个实施例提供了一种迁移技术，其具有下列一种或多种优势：
[0095] ·显著的覆盖率（可以使用该方法的实例以及因而工作负载的百分比，），[0096] ·低成本，其特别受到所需的手动工作的限制（特别是与重新安装方法相比较），[0097] ·短的迁移时间（因为改变窗口/允许的运行中断典型地较短），
[0098] ·低风险（例如，应用运行中断超过计划的风险），以及/或
[0099] ·可预测性（即，针对该迁移技术选择的工作负载将很可能获得成功）。
[0100] 现在注意图4，从想要迁移的现有客户环境（见图5）中的实例401开始。在步骤404中，将实例以映像形式传送至云。如果这不成功，保留原来的客户版本401并重新计划迁移；例如，将它保留在原来的环境中，或者执行经典的迁移至服务提供者环境，其中它可以保持为物理实例，或者可以对实例进行显著的改变从而它变为可虚拟化。另一方面，如果步骤
404成功，在步骤406中，实现对（运行中和/或映像形式的）实例的调整，以确保它符合云标准。如果这不成功，保留原来的客户版本401并重新计划迁移；例如，在没有云标准的客户环境或服务提供者环境中或者在HIaaS云中将它虚拟化，或者执行更为复杂的重新安装迁移，其中，单独的软件组件被重新安装，并且客户数据被单独地而不是在整个映像中传送。另一方面，如果步骤406成功，在步骤408中，执行实例在云OSS和BSS系统中的注册。如果步骤408不成功，保留原来的客户版本401并重新计划迁移；例如，通过与步骤404或406失败时相同的方法。另一方面，如果步骤408成功，结果是成功地迁移到MIaaS云410。
404成功，在步骤406中，实现对（运行中和/或映像形式的）实例的调整，以确保它符合云标准。如果这不成功，保留原来的客户版本401并重新计划迁移；例如，在没有云标准的客户环境或服务提供者环境中或者在HIaaS云中将它虚拟化，或者执行更为复杂的重新安装迁移，其中，单独的软件组件被重新安装，并且客户数据被单独地而不是在整个映像中传送。另一方面，如果步骤406成功，在步骤408中，执行实例在云OSS和BSS系统中的注册。如果步骤408不成功，保留原来的客户版本401并重新计划迁移；例如，通过与步骤404或406失败时相同的方法。另一方面，如果步骤408成功，结果是成功地迁移到MIaaS云410。
[0101] 注意到云注册的开始的子步骤可在调整之前发生或者可以与调整交错地发生。但是，从逻辑的角度来看，最终注册（即导入的实例作为云托管实例的最终接受）应该在调整结束之后。
[0102] 转到图5，更详细地描述非限制的示例性方法。客户环境402通过广域网（WAN）514等连接到MIaaS云环境410。开始，执行发现过程518，来确定物理520和虚拟522实例两者以及它们在客户环境402中的配置。在步骤524中执行分析和计划。如果结果是不利的，则寻求其他的方法，例如物理到物理（P2P）迁移、应用重新安装、遗留系统的保持等，如图526所示。此外，如果步骤518、524中的任一个表明需要小的修复（即对实例的小改变，以使它们与云兼容），在步骤516执行相同的步骤，且过程流程回到步骤518。另一方面，如果步骤524表明使用这里公开的一种或多种技术的迁移是可行的，流程进入步骤528中的基线测试和备份。
在步骤528中，如530所示，运行一组测试例来证明源系统满足需要在目标环境中保持的标准，例如，在其所有功能测试例或性能要求下仍然测试正确。这么做是为了确保在迁移过程之前修复已经存在的任何错误。此外，如图532所示，执行备份过程，以允许在迁移过程中遇到任何问题时能恢复。优选地，在完成备份532之前，物理或虚拟实例520或522上的应用被停止，从而在改变将不会被复制到MIaaS云环境的条件下客户环境中不会有进一步的改变。
处理然后进入步骤534，其中，要迁移的实例被捕获。一个或多个说明性实施例集中于迁移至MIaaS云的特定方面，这主要是按每个实例进行的。置于整体迁移，典型地在多个实例的波中执行，每个波例如在每个周末尝试保持工作负载或者交互实例在一个波中。在Athey等在2011年9月1日的美国专利申请公开20110213883“System and method for object migration using waves”（使用波的对象迁移的系统和方法）以及Devarakonda等在2012年
5月3日的美国专利申请公开20120109844“Total cost-based migration waves planning”（基于总成本的迁移波计划）中公开了这样的方面，所述专利申请公开的全部内容为所有目的通过引用显式地结合于此。
在步骤528中，如530所示，运行一组测试例来证明源系统满足需要在目标环境中保持的标准，例如，在其所有功能测试例或性能要求下仍然测试正确。这么做是为了确保在迁移过程之前修复已经存在的任何错误。此外，如图532所示，执行备份过程，以允许在迁移过程中遇到任何问题时能恢复。优选地，在完成备份532之前，物理或虚拟实例520或522上的应用被停止，从而在改变将不会被复制到MIaaS云环境的条件下客户环境中不会有进一步的改变。
处理然后进入步骤534，其中，要迁移的实例被捕获。一个或多个说明性实施例集中于迁移至MIaaS云的特定方面，这主要是按每个实例进行的。置于整体迁移，典型地在多个实例的波中执行，每个波例如在每个周末尝试保持工作负载或者交互实例在一个波中。在Athey等在2011年9月1日的美国专利申请公开20110213883“System and method for object migration using waves”（使用波的对象迁移的系统和方法）以及Devarakonda等在2012年
5月3日的美国专利申请公开20120109844“Total cost-based migration waves planning”（基于总成本的迁移波计划）中公开了这样的方面，所述专利申请公开的全部内容为所有目的通过引用显式地结合于此。
[0103] 在536可见，该实例捕获步骤可以同时包括例如具有一种或多种合适工具的物理到虚拟（P2V）和虚拟到虚拟（V2V）技术。合适工具的一个非限制示例是Migrate，一种用于快速和高效的P2V（更广义地，任何地方到任何地方）迁移的物理/虚拟转换工具；该工具可以从美国德克萨斯州休斯顿的NetIQ公司获得；另一种是VMware vCenter Converter，其可以从美国加利福尼亚州Palo Alto的VMware公司获得。在一个或多个非限制的示例性实施例中，步骤534的最终结果是虚拟机盘格式（VMDK）文件。
[0104] 需要强调，这里提到了很多产品名称；这些仅作为给技术人员的示例，并传达发明人对最佳实施方式的理解。它们不是要限制权利要求，除非在权利要求中显式地说明，而被认为是相应一般软件产品的示例；例如， Migrate广泛地代表物理/虚拟转换工具。
[0105] 如步骤538所示，捕获的实例然后通过网络514传输到云位置410。启动盘外部的数据544可以从上述vmdk文件单独地传输（见542），特别是如果它较大并且数据传输可以更早开始的话。如540所示，通过使用合适的工具来控制传送，实例和数据通过网络514来传输。这样的工具的非限制的例子包括上述PLATESPIN工具以及用于数据的Softek透明数据迁移设施 工具（美国纽约州Armonk的国际商业机器公司的注册商标）。数据544典
型地不受MIaaS云的特殊方面的影响，即，它可被迁移并且通过一般的方式链接回到vmdk。
为了避免混乱，图中忽略了关于数据544的更多细节。
型地不受MIaaS云的特殊方面的影响，即，它可被迁移并且通过一般的方式链接回到vmdk。
为了避免混乱，图中忽略了关于数据544的更多细节。
[0106] 在步骤546中，对传输的实例554进行功能测试，该实例是从云管理程序上的映像重启的。如547所示，这可以包括例如执行测试例的集合或子集；在调整之间这可以被重复若干次。同时，需要注意，在起初到达云环境410时，传输的实例位于MIaaS云着陆区（landing zone）中。如果此时功能测试成功，处理流程进行到实例调整和采用556。这是修改实例的重要步骤，因此它可以在标准的MIaaS环境中运行。在所有调整之后，并且可能在特定的调整步骤之间，功能测试被重复，如从步骤556到546的逆向箭头所示。在每个成功的功能测试之后，如步骤550所示实例可被备份（即可以取实例的快照552）（例如，作为高效实例库552中的vmdk文件）以用于以后的引用，作为实例的最近的看起来正确的状态。如果在所有调整556之后功能测试成功，在MIaaS云生产区域574中的云管理程序558上对传输的实例进行实例化。另一方面，如果在其重复的某一次中功能测试不成功，处理流程进行到修复步骤548。修复过程可以通过若干种途径来进行。典型地，错误消息将被分析并与最近的改变关联。在功能测试546第一次执行时，这些最近的改变是虚拟化和新的管理程序。在后续执行中，它们是自前一次执行功能以来的调整所做的改变。为此，引用在这些最后的改变之前的实例的快照552是有用的。如果这些错误的修复不成功（这可以通过重新运行功能测试来确定），流程回到步骤528，即该实例的迁移（至少在该时刻）停止，并且用备份来恢复客户环境402中的源实例520或522。当修复成功时，处理前进，就好像该功能测试立即成功，即进行第一次或下一次调整，或者在已完成所有调整的情况下，在MIaaS云生产区域574中的云管理程序558上对实例进行实例化。
[0107] 在实例调整和采用步骤556中，管理程序554上的实例被调整为云交付标准并被采用到云BSS和OSS，如568所示。如570所示，该过程使用调整子流所扩展的供应流程。例如，MIaaS的标准供应流程（即，用于从云目录选择而不是迁移的实例）可以在资产管理系统、监控系统中注册新实例，并为其开始记账（accounting）和记费（billing）。可以从标准供应流程重用该功能。另一方面，标准供应流程可以不安装在普通实例上MIaaS云所需的特定监控代理，因为它们将被预安装在云目录映像中。因此，安装该代理将是特殊的调整流程的一部分。类似地，对云目录映像所具有的级别的安全补丁的更新可以是调整流程中的额外步骤。当所有调整步骤之后的功能测试最终已成功完成时，如所述的，在生产区域574的云管理程序558上发生实例化。
[0108] 在一个或多个实施例中，着陆区域是为了迁移到MIaaS而添加的特殊区域，因为在MIaaS云环境（见项目554）的管理程序上第一次启动实例以进行测试和调整时，它们还没有满足云标准，且因此普通的云管理不能处理它们。它们也不会满足安全云中的OS管理所提供并假设的安全标准。为此，可以至少通过使用不同的服务器来容纳（host）管理程序以从物理上分离着陆区域572和生产区域574，并且通过防火墙来将它们进行分离，如这两个区域之间的两个箭头所示该防火墙仅允许受控制的信息通过。此外，存储系统可以是分离的。物理分离的另一个好处是，云管理系统（例如容量和性能管理）于是不需要处理管理程序，该管理程序部分具有正常的托管的云实例，而部分具有还不可管理的导入实例。但是，也可以使用逻辑分离，即，信任云管理程序不会让可能不安全的导入映像影响其他映像，并将云管理系统扩展为处理被分区的管理程序。
[0109] 一旦在生产区域574中的云管理程序558上实例化相关的迁移的实例，例如可以进行用户接受测试560，以验证性能相当于基线。如果不是这样，在562进行修复，以校正管理程序558上的实例。如果合适，该修复过程可以利用实例库552或替代技术526；如果这发生，可以从生产区域574再次移除实例，直到它被修复。用户接受测试560中的测试例优选地应与基线测试中的测试例相同。如果用户相关的功能由多个实例（例如web服务器、应用服务器和数据库）来执行，它们通常一起覆盖多个实例。相反，功能测试可以仅针对每个实例。当测试560成功时，在步骤564中执行切换（cut-over），并考虑任何客户域名服务器（DNS）改变，等等，如565中所示。在完成切换时，如566所示，迁移的实例以照常运行（business as usual，BAU）的方式在MIaaS云生产区域中运行。
[0110] 在图5中，可以理解，在一个或多个示例性实施例中，步骤516、528和560是在客户的范围内而步骤518、524、526、434、538、550、556和564是在云服务提供者的范围内。步骤546、548和562具有双方之间的混合的性质。
[0111] 图6示出了示例性系统图。客户环境402包括一个或多个源实例684（对应于图5中的初始物理或虚拟实例520和522）以及传送代理682。网络514提供客户环境402和MIaaS云环境410之间的连接。环境410包括着陆区域572、生产区域574和管理区域680。传送的实例686位于着陆区域572中（元素554表示在管理程序上运行的实例）。最终的目标实例668位于生产区域574中（元素558表示在管理程序上运行的实例）。云管理区域680包括多个管理组件。传送核心组件690与传送代理682结合工作，执行源实例684到传送实例686的实例传送。
调整组件692协调关于图5中的着陆区域572讨论的调整过程。注册组件694将调整的实例注册到MIaaS云的正常管理系统，这里由BSS和OSS696、698来表示。如568所示，云OSS和BSS系统（运行和业务支持系统）698、696为步骤556提供输入。MIaaS云中的OSS和BSS的正常功能是管理生产区域574中的实例。但是，着陆区域572还至少需要最小的OSS，例如用于容量管理且由此在源实例684进入时找到合适的位置（具有足够容量的服务器和存储）。如果着陆区域与生产区域物理分离，则在更详细的级别上，OSS也可被分离。在任何情形下，调整组件
692和注册组件694准备实例以被接收到OSS698中，因此，在它们需要与OSS需求相关的知识这一点上，至少存在抽象的连接。典型地不需要用于着陆区域的BSS，因为在着陆区域中，实例受到迁移过程的控制，并且对于客户或端用户还不可见。
调整组件692协调关于图5中的着陆区域572讨论的调整过程。注册组件694将调整的实例注册到MIaaS云的正常管理系统，这里由BSS和OSS696、698来表示。如568所示，云OSS和BSS系统（运行和业务支持系统）698、696为步骤556提供输入。MIaaS云中的OSS和BSS的正常功能是管理生产区域574中的实例。但是，着陆区域572还至少需要最小的OSS，例如用于容量管理且由此在源实例684进入时找到合适的位置（具有足够容量的服务器和存储）。如果着陆区域与生产区域物理分离，则在更详细的级别上，OSS也可被分离。在任何情形下，调整组件
692和注册组件694准备实例以被接收到OSS698中，因此，在它们需要与OSS需求相关的知识这一点上，至少存在抽象的连接。典型地不需要用于着陆区域的BSS，因为在着陆区域中，实例受到迁移过程的控制，并且对于客户或端用户还不可见。
[0112] 图7示出了在重要的时刻（即在重要的阶段）的系统状态；即初始状态707、在传输709之后、以及在切换（云BAU）711之后。在状态707中，客户的现有管理工具703管理客户环境402中的物理实例520和虚拟522实例两者。所述实例被存储在存储705中（例如，关于备份步骤528和532所述的，但还有实例的普通外部存储，如果它是在服务器外部（例如在存储区域网络中或者在网络文件系统中）的话）。实例被捕获。如以上关于536所讨论的，该实例捕获可以包括例如使用一种或多种合适工具的物理到虚拟（P2V）和虚拟到虚拟（V2V）技术两者；传输可以经过WAN514（这可以包括例如最终的虚拟专用网络（VPN）（在迁移完成之后的正常运行期间用于客户和云环境之间的通信）或者临时线路）或通过物理介质的传送。在一个实施例中，云环境410包括云着陆区域572中的云提供者硬件和管理程序554、云生产区域中的云提供者硬件和管理程序558、以及共享存储701。该实施例是如上所述的着陆区域和生产区域的完全物理分离和仅逻辑分离之间的折中，在前一情形下，甚至存储也是分离的，在后一情形下，甚至管理程序也会被共享并且区域分离将通过管理程序来实施，这两者都在可能的实施例中。该混合实施例的一个好处是，从着陆区域到生产区域的最终传送不需要复制数据；只是将属于该实例的存储卷的所有权变更为生产区域。
[0113] 在传输之后，如709所示，在着陆区域572中的云提供者硬件和管理程序554上物理和虚拟实例520、522现在都已被虚拟化，分别如720、722所示，并且在此进行调整和测试。迁移的数据被存储在共享区域701中。优选地，源实例520、522在传送之前已被关闭，如以上关于备份528所解释的。一种极端的情形是，它们根本不在运行（对于520，物理服务器被关闭；对于522，从管理程序移除实例），但典型地只会停止它们上面的服务（从而不会进行在云生产区域中恢复照常运行时会丢失的改变）。如果可区分只读服务，例如，在信息网页上浏览，这些可保持运行。此外，在迁移失败时典型地仍会在客户管理工具中保持实例520和522，从而可以快速恢复客户环境中的运行。
[0114] 在切换之后，在云BAU（照常运行）状态下，如711所示，客户环境711中的物理、虚拟和存储资源520、522被关闭，并且它们使用的存储705被释放。同时，如关于图5所述的，任何需要的调整和修复都已完成，分别如724、72所示，在云生产区域中的云提供者硬件和管理程序558上物理和虚拟实例520、522两者都已被虚拟化。在着陆区域和生产区域的部分物理分离的该实施例中，迁移的数据仍被存储在共享存储701中。使用完全的物理分离，将会有两个不同的存储系统，一个在着陆区域中且一个在生产区域中，并且数据在阶段709位于前者上而在阶段711位于后者上。BAU云处理在568所示的OSS和BSS系统（运行和业务支持系统）698、696的控制下发生。可以向客户管理工具703提供与生产区域574的接口。但是，这典型地仅涉及在应用层上进行管理的那些特定工具，而执行OS级别功能的工具（例如OS性能管理）已被568中的云OSS替代。例如，实例（开始是520或522，然后是720或722，最后是724或726）可以包含数据库，且用户可以具有数据库管理工具作为703的一部分。MIaaS云（与PaaS云相反）典型地不会执行数据库管理。因此，客户数据库管理工具获取到实例724或726上的该数据库的链接。该方法使用云的客户链接到其在云上的实例的正常方式，例如VPN；这与MIaaS云的任何分区或管理限制不会冲突。需要注意，图7示出了一个小时到两天的示例性时间以从初始状态707移到“传输后”状态709，以及从两个小时到一天的示例时间以从“传输后”状态709移到“切换云BAU之后”的状态711。这些值旨在为技术人员提供有益的例子但不是要限制。
[0115] 一个或多个实施例由此提供了一种将实例迁移到云中的方法，包括将实例以映像形式传送到云；将实例调整为云标准；以及将实例注册到云管理系统中。在某些情形下，由云供应方法的变体来执行注册，在该变体中，以选取传送的实例来代替选取目录映像。在某些实施例中，云管理系统包括运行支持系统和业务支持系统。在某些实施例中，云标准包括一个或多个安全标准、基础架构标准、补丁管理标准和基础架构管理工具标准。
[0116] 此外，在一个或多个实施例中，通过工作流引擎中定义的工作流来进行调整。在某些情形下，通过特殊的工具（例如补丁管理工具）在工作流中进行一次或多次调整。
[0117] 在某些实施例中，在传送步骤之前，对实例进行分析以确定它是否适合云和给定的迁移方法，且以后仅考虑合适的实例。此外，在某些实施例中，在传输之前、传输之后、不同的调整之间、调整之后以及迁移之后的一个或多个时间进行测试，并且如果一次或多次测试失败则进行修复和/或回退。在某些情形下，在一次或多次迁移决策（即在本段的前面提到的是否适合云）和/或测试及回退决策中将多个实例当成整体。
[0118] 此外，一个或多个实施例包括发现、失败的实际处理、开始和结束改变窗口和实际的停机时间、调整和注册的详细交错以及/或切换步骤。
[0119] 现在将定义这里使用的特定术语：
[0120] IaaS云：基础架构即服务是云的普通术语，主要为其用户提供虚拟机（VM），而不是还提供VM上的软件（被称为PaaS，平台即服务）或提供软件而不访问VM（被称为软件即服务）或业务过程（BPaaS）。
[0121] 这里给出了IaaS云的以下细分：
[0122] HIaaS云：硬件基础架构即服务（HIaaS）云提供基本虚拟机作为服务。它还可以提供操作系统（OS）甚至软件，但典型地不会为OS或软件提供支持（例如，可以从美国华盛顿州西雅图的亚马逊网络服务有限责任公司获得的亚马逊弹性计算云（Amazon EC2））。
[0123] MIaaS：托管基础架构即服务云提供全服务的虚拟机。服务例如可以包括OS补丁和对OS的安全性和合规性的支持（例如，可以从美国纽约州Armonk的国际商业机器公司获得的云环境IBM SmartCloud Enterprise+，也被称为IBM SCE+）。
[0124] 实例：操作系统实例以及在该操作系统上运行的所有软件。它可以是物理的（即直接在服务器上运行）或虚拟的（即已经在管理程序上运行）。
[0125] 源实例：迁移之前在源端运行的实例。
[0126] 映像：实例的文件表示。
[0127] 目录映像：云目录中的映像，如果在云中从头开始而不是通过快速迁移来创建新实例，则该映像被使用。
[0128] 供应：这是订购IaaS中的VM实例的标准方法—用户从目录订购VM，且相应的实际映像被实例化为运行的实例。
[0129] 重新安装迁移：从MIaaS云的角度来看，将应用移动到该云的标准方式是首先提供目录映像，然后在其中重新安装必要的软件组件、源代码、配置和数据。但是，这典型地是非常耗时和昂贵的过程。
[0130] 基于映像的迁移：基于映像的迁移使用客户实例来将应用迁移到云。在经典的虚拟化中，基于映像的迁移是一个标准（P2V）且可以非常快。但是，由于从源实例直接产生的映像不能实现MIaaS云的管理部分，迄今为止，基于映像的迁移对于MIaaS云还不可行。
[0131] 快速迁移到MIaaS云：根据一个或多个实施例的基于映像的迁移的一个扩展，其可以在MIaaS云中处理基于映像的迁移的挑战。
[0132] 现在参考图8，关于快速迁移，技术人员将理解，在服务器802上典型地有很多事物；例如，中间件或其他现成软件（MW）804、806；基础架构软件（“Infra”）808，例如监控和供应代理；自定义代码810；以及/或脚本812，例如用于备份、调度清理任务、数据传送等。当然，服务器包括硬件820和操作系统（OS）822（典型地具有注册表和用户（为了避免混乱没有单独编号））。如824所示，当前的服务器可以是具有OS、数据和软件的简单物理服务器，或者已经通过合适的管理程序被虚拟化。中间件例如804、806典型地具有配置814、数据816（例如数据库）、代码818（例如SQL脚本），且通常与其他脚本（例如数据库管理员脚本）关联。这些中的大多数不需要位于标准的位置。我们发现，典型地很难自动找到与运行实例（甚至是非常普通的标准软件例如web服务器和数据库的运行实例）相关的一切。
[0133] 在一个或多个实施例中，根据本发明的方面的快速迁移被认为特别适合于仅基础架构的迁移以及未改变的主OS版本呢，即，目标是到达MIaaS云但不想做出其他主要改变的时候。如802’所示，当“相同”的服务器被移到云中时，它现在在云硬件830上运行，并使用管理程序832。除此之外，存在有限的改变：
[0134] ·操作系统的小更新（现在是OS’822’）——即，不同的驱动器、云提供者用户ID、IP地址
[0135] ·略微不同的基础架构软件（云管理工具—现在是Infra’808’）
[0136] 一个或多个实施例利用了下列见解：更新少数改变的事物，而不是单独选取所有未改变的事物并具有忘记某些事物的风险，这是有利的。现在参考图9，OS822；MW804（包括其配置814）、806；基础架构808、代码810、脚本812、代码818和数据816被放在一起，移动到云中，且然后对OS822’和infra’808’进行小的更改。有利地，在该方法中，如果有任何事物在更改中无法工作，这很可能只是云服务提供者一侧的基础架构管理（因为它是最新添加的），而不是应用（其基本保持未改动）。当然，这已首先假设应用事实上可被虚拟化。当然技术人员将理解，给定这里的描述，需要特别关心例如服务器的新资源附加地支持云管理代理。
[0137] 图10示出了替代的方法（重新安装/重构平台），其不使用上述快速迁移技术。这是MIaaS提供者典型地期望其用户去做的，但在时间和金钱方面通常是不可行的。在该图中，在从云目录为实例提供与原来的OS808类似的OS’808’并且刚刚安装了现成软件之后，基本上所有事物被逐个移动。沿着这些路线存在某些当前可用的工具，但其仅可用于可能的现成软件的小的子集，但几乎没有可用的工具来移动额外的事物，例如脚本、代码等，甚至也没有可用的工具来只是列出所有事物以用于后续的传送。在安装之后移动“其他的一切”也决不是容易的选项—在文件系统以及OS数据结构（例如特别是WINDOWS上的注册表）两者中，OS、应用和配置/数据/自定义代码是高度关联的。
[0138] 现在考虑快速迁移（即在图4-7和9所述的新技术，即图4的步骤406和408，或者图5的元素556、558、570）中的交错的调整和注册的核心选项。仅通过示例而不是限制，特别考虑若干个核心选项，以将导入的实例的注册流程添加到MIaaS云：
[0139] 第一选项：针对最紧密相关的目录映像（分析和计划阶段524已决定实例将被调整以模拟该映像）来运行供应流程。然后用从目录映像产生的实例交换导入的实例，在该导入实例上已经进行了大多数调整（例如额外的补丁、安全合规性调整）。这可以针对挂起的映像在映像文件级别上执行。例如，如果提供的实例具有某种身份（例如IP地址），且由于MIaaS管理需要它但无法事先知道它，从而现在需要将其传送到导入的实例，则可能需要在供应后对导入的实例进行某些调整。注意到这样的交换以及交换后的调整不能由未更改的MIaaS云的用户来执行；它需要特别的授权，并且为了足够高效和安全，自动化工具被添加到MIaaS管理系统。
[0140] 第二选项（见图11）：更改供应流程，从而它仍然执行大部分注册工作，但在某些点上选取导入的实例的映像而不是目录映像。如果供应流程对映像执行实时动作（例如代理安装），这些也可被重用（而不是在注册流程之前的调整中执行）。如果可能，保留供应流程和新注册流程的公共部分，作为实际的公共组件（公共的子程序、子工作流等）。
[0141] 现在参考图11，这里描述了MIaaS云环境（IBM SCE+是非限制的例子）中的示例性供应流程。在步骤1101，用户访问客户门户和服务目录1110，这是MIaaS的BSS（568、696）的一部分。在一个或多个实施例中，“采用”或“导入”是目录1110中新的服务类型（与被设计为没有新的快速迁移方法的MIaaS云相比），且可用于特定的角色。在某些情形下，该方面可以通过对MIaaS云中现有的用户接口（UI）进行相对较小的改变来实现。合适的参数可以被传送给下面描述的供应过程。如图所示，服务请求可以涉及服务目录；请求的接收、请求的完成以及对虚拟机供应状态的更新。在某些情形下，在使用时示出服务器资源使用状态。
[0142] 在步骤1102，用供应引擎1112来执行供应。MIaaS供应可以包括从门户1110接收请求；使用映像来创建实例；创建虚拟服务器，其包括供应资源需求，例如CPU、存储器、盘、主机名、IP地址和/或子网；安装用于管理的代理、配置代理、连接到虚拟局域网（VLAN）；以及/或服务器验证。针对导入映像的注册作为对该供应流程的调整，一个或多个实施例在步骤1102的“使用映像来创建实例”的子步骤中选取导入的映像而不是目录映像。因此，与图5相关，该子步骤变成在生产区域中从导入的实例创建实例558。如果着陆区域从生产区域物理分离，这实际上涉及将调整的实例554从着陆区域复制到生产区域。如果着陆区域是虚拟的，甚至可以将实例保持在原处，但现在将其地址（名称、指针）提供给供应流程。
[0143] 在快速迁移方法的一个或多个实例中，在创建虚拟服务器期间，如在导入的实例或步骤524的计划中那样创建精确的CPU、存储器和盘（由于云可能不具有和导入的映像完全一样大小的资源，典型地将选择下一个较大的足够的大小）。某些实施例使用双宿（dual-homed）主机的实例，其具有云服务提供者的内部IP地址（用于MIaaS的云管理系统对实例的访问）以及面向客户的客户地址；这典型地不同于导入实例的老的IP地址，且由此该实例上的地址必须被更改为云管理系统所提供的面向客户的地址。
[0144] 需要注意，诸如“必须”或“应该”等单词论述了示例性实施例中强制性的项目，但在其他实施例中可以是可选的。对权利要求不会有任何限制，除非在其中如此陈述。
[0145] 在某些情形下，针对代理的安装和/或配置，如果MIaaS云为了相同的目的而使用不同的代理或工具，提供新的流程来处理之前的代理，例如性能监控代理或备份代理。具体的非限制的例子包括可以从美国加州Sunnyvale的赛门铁克公司获得的Altiris产品以及可以从美国德州休斯顿的NetIQ公司获得的产品。处理这样的代理可以包括例如卸载或者将权限从管理员权限降低为用户权限、或者工具中的策略改变。但是，作为替代，甚至可以在启动供应流程之前执行该流程，作为着陆区域中的调整。
[0146] 在步骤1103中，创建虚拟服务器。在图11的非限制的例子中，这可以使用用于INTERL技术的虚拟化管理器1116（例如，利用如1120所示的（美国加州Palo Alto的VMware公司的）VMware ESX VM）或使用用于POWER技术的虚拟化管理器1118（例如，利用如1120所示的IBM PowerVM逻辑分区（LPAR）；美国纽约州Armonk的国际商业机器公司）来执行。在任一情形下，可以使用合适的存储，例如存储区域网络（SAN）存储1114。在其他实施例中可以使用其他类型的技术。该步骤可以包括从供应引擎1112获取请求；分配合适的计算资源，例如CPU、RAM、盘空间等；复制映像；将映像放置于物理服务器上；启动操作系统和中间件；以及/或应用IP和主机名。在采用该流程以用于快速迁移中的注册的某些实施例中，另一步骤包括为测试准备自定义的访问。在没有迁移的MIaaS供应中，不需要该测试，因为这是标准的目录实例，但在这里，正在处理导入的调整的实例，且执行用户接受测试560是合适的。
[0147] 在步骤1104，在供应引擎1112的帮助下执行服务器验证。这可以涉及例如检查管理代理的正确安装和配置；安全扫描（例如针对端口、密码策略等）；检查用户ID的有效性；运行健康检查；将服务器信息记录到主数据库中；以及/或向合适的管理工具（例如可以从美国纽约州Armonk的国际商业机器公司获得的IBM Service Delivery Manager（SDM））报告。
[0148] 一个或多个实施例有利地使用调整工作流中的典型更改的自动化，从而这些测试（例如安全扫描）典型地不会失败—事实上，MIaaS云的这些验证步骤可被看做是在迁移至该MIaaS云时必须哪些调整的基本规范。
[0149] 步骤1105包括更多地在BSS层上的最终验证，这与步骤1104中的OSS层验证相反。这可以包括例如验证报告的SDM检查；确认请求；同意VM（即实例）发布给客户；云服务提供者将客户用户添加到服务器（如果还不存在）；以及/或向客户提供服务器接入。在某些实施例中，在迁移时将更早地提供访问以用于测试，如步骤1103所述。
[0150] 现在将提供关于可在一个或多个实施例中执行的若干步骤的示例性的非限制的细节。
[0151] 发现（步骤518）
[0152] 在某些实施例中，针对第一次运行—在第一变换计划之前，标准工具（例如可以从美国纽约州Armonk的国际商业机器公司获得的IBM Tivoli Application Dependency Discovery Manager（TADDM）、IBM Galapagos工具等）可以在生产系统上在实际迁移之前很好地运行。关于IBM Galapagos工具，例如见Galapagos:model-driven discovery of end-to-end application-storage relationships in distributed systems,IBM Journal of Research and Development archive,Volume52Issue4,July2008,Pages367-377以及Nikolai Joukov,Birgit Pfitzmann,HariGovind V.Ramasamy,Murthy V.Devarakonda:Application-Storage Discovery;SYSTOR2010,Haifa,May2010。在某些情形下，为了易于安装到客户环境402中，这些工具可被预先安装在设备（appliance）（小物理服务器）上。该过程统一了这些工具、客户输入以及从特定的可用客户库的加载。在至少某些情形下，云服务提供者可以请求额外的访问来完成实例特别是虚拟实例522的文件系统副本（但是在该过程中没有什么依赖于此）。
[0153] 在某些实施例中，针对第二次运行，以每一波的方式来执行相同的过程。即，在迁移的（例如）几周前，有针对每一波的此后的再次发现。可以使用相同的工具，其通常具有额外的选项和插件来获得更多的细节。在该第二次发现518之后，在一个或多个非限制的例子中，针对代码和配置来执行更改冻结，从而后续地步骤可以信赖来自发现的信息是当前的。
[0154] 分析和计划（步骤524）
[0155] 该阶段决定业务应用是否能够被迁移到一个或多个MIaaS云环境（SCE+是非限制的例子）以及使用哪种迁移方法。假设这与组织可能具有的（用于与MIaaS不同的其他类型的迁移和IT变换的）一般迁移计划工具（例如IBM Migration Factory）进行集成。在该工具中，到MIaaS的迁移应共享信息，例如用于不可虚拟化的软件、软件-OS兼容性、以及非云迁移的升级成本。这些例如可作为位于计划设备下面的数据库中的静态表来获得。决定什么工作负载进入到至MIaaS的快速迁移路径的一个重要标准是它们已经具有正确的主OS版本。例如，如果MIaaS云中的映像目录仅包含以Windows2003、2008和Red Hat Enterprise Linux（RHEL）5.6作为操作系统版本的映像，计划可以决定仅针对已经具有这三种操作系统中的一种或者至多额外的RHEL5.1到5.5（从而在调整时需要很小的升级）的源实例520或522来使用到该MIaaS云的快速迁移。如果在具有这些操作系统中的一种的实例上存在不可虚拟化软件或者其他排除标准（特殊硬件，可能是集群），该实例仍然需要进入不同的目标环境，或者首先被显蓍地修复（步骤526）。在某些情形下，调节过的工作负载未被迁移，但这不是要限制权利要求的范围，除非其中显式地说明。在某些情形下，该方面是通过扩展静态表和发现来执行的，以最小化潜在的问题；尽管给定这里的内容，技术人员将理解，可以使用对物理到虚拟技术的可能性进行分析的被适当地调整的标准分析技术来实现该方面。
[0156] 在一个或多个实施例中，该阶段还包括对源实例的补丁状态与MIaaS云的标准的兼容性进行分析；这专用于到MIaaS云的迁移。
[0157] 在一个或多个实施例中，该阶段还包括选择映像大小。在至少某些情形下，简单地保持大小，除非需要增加它以符合在调整期间必须安装的新代理。如果MIaaS云仅允许特定的固定映像大小（关于CPU、存储器、盘存储等），可能需要在以后将映像大小调整为下一个更大的合适的大小；但是，这不应是排除性的标准。
[0158] 在一个或多个实施例中，该阶段还包括波计划，即，将一起迁移的服务器分组。这例如可以使用标准的迁移工具来执行（例如在上述美国专利申请公开20110213883和20120109844中公开了该方面）；使用依赖性、位置、子网等；可选地，可以在该阶段尝试释放硬件等。需要注意在一般情况下，不能确保没有跨波依赖性—某些环境过于互连。
[0159] 在至少某些情形下，在该阶段应计划安全区域并且还应计划特定的云池（即，对云提供的实例进行分组）。参考下面关于图14对请求GUI的讨论。
[0160] 基线测试和备份（步骤528）
[0161] 在基线测试中，客户（或者迁移组）执行他们还会在迁移后应用的所有测试，以确保现有的系统通过所有那些测试。在一个或多个实施例中，实际的测试与用户接受测试（UAT）中的相同。这可以涉及例如写入数据库等的某些UAT测试，从而它们无法在生产服务器（例如生产区域574）上执行；来自客户环境的测试服务器然后可被用于基线测试，尽管那里的实际的工作负载部署会比生产配置更简单。
[0162] 在至少某些情形下，由客户来进行备份，且客户验证它起作用，因为实例捕获会导致问题。在某些情形下，云服务提供者不会在客户一侧进行备份。
[0163] 在某些情形下，客户可以在该阶段执行额外的步骤。例如，启用以下讨论的捕获过程，特别地，存在其他事情需要客户来做。
[0164] ·确保对其自己的开发者存在更改冻结；
[0165] ·给予迁移组（可以是内部的、来自云服务器提供者或其他方的）对要迁移的实例的根权限；
[0166] ·给予迁移组用于迁移的现实的更改窗口，因为物理到虚拟（P2V）被视为更改，即使是它在后台运行的情形下。
[0167] 实例捕获
[0168] 可以针对该步骤来使用多个变体。参考图12。将展示非限制的例子，所有例子都可有效地用于到虚拟化环境的任意传送：
[0169] ·如果客户环境402中的源实例520仍然是物理的，如图536所示将涉及P2V操作（物理到虚拟）。存在用于此的标准工具，例如，上述PlateSpin工具，以及可以从上述VMware公司获得的VMConverter工具。
[0170] ·如果存在多个驱动器，可以由相同或不同的工具来处理。数据驱动器传送例如可以比启动驱动器传送更早开始，并用再同步工具例如IBM Softek TDMF软件来执行，以用较短的更改窗口来适应大量数据。
[0171] ·如果需要P2V操作，它可以是本地的（即，在客户环境402中首先创建虚拟机或映像），之后是传输，或者它可以和传送集成，即，新的虚拟机或映像文件在目标即“着陆区域”572中立刻存在。
[0172] 在一个或多个实施例中，客户面临的重要方面包括：
[0173] ·迁移组需要获得映像的根/管理员权限
[0174] ·如果非启动卷存在并通过如上所述的再同步工具来传送，该工具必须被事先安装
[0175] ·更改窗口最迟应在这里开始
[0176] ·应用典型地在P2V时间期间关闭
[0177] ·在所有传输都是通过WAN514的情形下，应该存在“开始区域”，在此捕获的映像等待传输（至少针对大映像，小映像例如可直接通过PlateSpin工具来传输）。
[0178] 实例捕获可以包括合适的关闭过程。在某些实施例中，在潜在的P2V步骤之前，企业应用（也被称为工作负载）被关闭（如果在备份期间还没有这么做）。这意味着从用户的角度来关闭它们—在多组件的工作负载下，这并不意味这关闭所有组件；例如，可以仅禁用前端web服务器。在捕获步骤中甚至没有任何软件组件运行会更安全（冷P2V），但在事物运行时用给定的工具这样做是可能的（热P2V）。在一个或多个实施例中，应用所有者限定什么被关闭，且优选地执行该关闭，因为迁移组被分配了基础架构级别的任务，对此可能没有全面地理解。
[0179] 例如，实例捕获可以包括用于物理服务器的P2V步骤。对于已经虚拟化的服务器，特别是在VMware上，该步骤需要的很少。在一个或多个实施例中，在P2V结束时，不再允许对源进行更改（如果在备份期间还没有禁止更改），因为它们不会再被传送到目标。即，典型地，现在整个源实例被关闭以确保该目的。如果实例已经被虚拟化，在要传输的映像完成之前、或者在集成的传输中、至少在该传输中的最终再同步之前关闭该实例。
[0180] 如果捕获步骤与传输步骤分离，将为捕获的实例提供“开始区域”，即与传输技术接近的用于它们的存储空间。
[0181] 传输到云服务提供者（包括数据）
[0182] 数据传送可以通过网络或物理介质来执行，这依赖于网络带宽和物理距离。在某些情形下，这可以使用再同步工具（一个例子是IBM Softek的TDMF）来执行，特别是针对大映像或非启动驱动器。工具例如TDMF应被事先安装，且如果存在大数据集作为非启动驱动器，后台数据传送可比P2V更早开始。如果确定启动驱动器不包含普通“数据”，至少在某些情形下，可以仅对该驱动器进行更改冻结，即，仅同步其他驱动器。当然应给予客户可接受性足够的关心。
[0183] 到着陆区域应该有足够的带宽，典型地比到MIaaS云的标准WAN连接大得多，因为在照常运行阶段711中需要。在某些情形下，可以使用特殊的光线路。可以将WAN优化器加到该光线路（例如可以从美国加州旧金山的Riverbed Technology获得的WAN优化器）。在至少某些实施例中，大小设定应用于最大波负载而不是平均。另一个选项是使用物理存储介质，例如高密度SATA（串行ATA（SATA或者串行AT附件）盘阵列并通过信使或类似方式来传输。通过使用再同步工具将数据复制到它们，在此之后可以通过网络来再同步。
[0184] 着陆区域
[0185] 一个或多个实施例使用“着陆区域”，即与特定实例的最终云位置相同的数据中心中的环境，并且具有相同的硬件和管理程序（例如，对于VMware ESX VM是相同的ESX版本），该导入的实例可以在其中运行。在某些情形下，对于初始的传输，如果针对映像文件来单独执行，所需的只是足够的存储空间，如对于任何传输那样。但是，最迟在第一次功能测试时，用于导入的实例的运行时环境应已可用。在一个或多个实施例中，每个数据中心至少有一个着陆区域，因为一旦实例被传送到云服务提供者，不会使用进一步的WAN传送。可能存在甚至更多的着陆区域，特别是如果数据中心包含多个物理分离或分别管理的生产区域；于是每个生产区域可以有一个着陆区域。
[0186] 需要被复制的客户的任何安全分区可以虚拟地执行，即通过云服务提供者的VLAN和防火墙来执行，但除非客户也在生产区域中需要特定安全区域的物理分离（在云中不常见），实例都可以在相同的硬件上着陆，受到相同的管理软件的控制。
[0187] 如上所讨论的，整个着陆区域可以从（相应的）生产区域物理或虚拟地分离。在一个或多个实施例中，确切的位置和地址是相关的考虑。在虚拟分离的情形下，优选地将每个实例导入到物理上接近其在注册之后将停留的位置，从而不需要额外的复制。例如，如果生产区域的子结构分为若干个单元，其中，例如，每个单元被VMware vCenter Server或TSAM（可以从美国纽约州Armonk的国际商业机器公司获得的IBM 服务自动化管理器软件），且着陆区域甚至在这样的单元中都是虚拟的，在从着陆区域传送到生产区域时，实例可以保持在相同的物理服务器和存储上。例如，仍然属于着陆区域的实例可以具有“容许”标记从而TSAM知道它们在那儿并且还未在生产区域的意义上被管理。但是，如果为了额外的安全性和更低的复杂性，着陆区域位于生产区域以外的其他单元中，则需要实际的复制，并且主要在生产区域中执行的注册流程必须被给予实例在着陆区域中的地址以及从该地址复制的权限（例如通过在防火墙中开启特殊的端口）。
[0188] 功能测试
[0189] 在传输到云服务提供者之后，应当进行测试来验证P2V和传输正常地工作了。为此，可以使用在非云的P2V变换中使用的标准方法，因为到目前为止还没有专用于MIaaS的调整。最小测试是实例至少能够启动。在某些情形下，该测试可限制在OS、存储等；在其他实施例中，它可被扩展到软件或甚至整个业务应用仍然工作。在某些情形下，可以存在从关闭的时间开始在运行的事物的列表。在某些情形下，迁移组提供自动重启的能力。另一方面，在某些情形下，这是由客户来处理的。该测试典型地与完全的基线测试不同。
[0190] 在调整之前/期间备份实例/建立实例快照
[0191] 直接在传输到云服务提供者之后，并且可选地在执行测试的任何步骤之间，可以（用VMware快照技术）进行备份以实现更容易的修复。但是，特别是对于成熟的过程，人们可以决定不做这些中间的备份，以便在大多数一般正确的情形下节省时间。在涉及人工决定的步骤之前/之后，备份特别有用，而自动化步骤可以容易地从第一个备份开始重做。
[0192] 修复550
[0193] 在至少某些情形下，这主要是人工步骤。如果出现了错误，典型地需要调试。如果遇到了太多困难，需要从当前的一波即本周末（或其他相关时段）的迁移中去除该实例或可能整个业务应用。还需要记录这种情形，从而未来可以在发现518和分析及计划528的阶段捕捉到这种情形。
[0194] 在云服务提供者的VMware ESX虚拟机等上面的实例
[0195] 此时，使用刚刚通过功能测试的运行实例开始调整流程。
[0196] 采用和调整子流程556
[0197] 在至少某些情形下，通过对如上参考图11讨论的供应流程的小的修改来执行采用（在这里也可互换地被称为注册）和调整。对于更一般的视图，应参考图13集中在特定于迁移的步骤上（图11示出了“非迁移”步骤并在下文中讨论特定的迁移步骤）。在步骤1302中，确定是否需要或想要任何采用前调整，即在任何注册步骤之前且与之分离地执行的调整，即涉及MIaaS云BSS和OSS568的步骤。该确定可根据需要参考作为分析和计划步骤1306的输出的决策文档等。在步骤1304，以来自分析和计划步骤1306的合适的实例参数（以及云区域）来开始采用流程。在步骤1308，门户流程传递（pass through）“采用”参数，即表示需要执行流程变体的参数，在该流程变体中导入实例被注册。（该流程修改可以在作为MIaaS门户的基础的系统中执行，例如，在可以从美国纽约州Armonk的国际商业机器公司获得的IBM Tivoli服务请求管理器（TSRM）软件中执行）。在步骤1310中，发生供应，并选取导入的实例，并且调用任何新的调整子流程（例如可以在TSAM中执行）。在步骤1312中，创建虚拟服务器。（如果实例保持相同，即如果如上所述着陆区域完全是虚拟的，则不需要这么做）。（这可以通过MIaaS云例内部例如在TSAM中的普通实例创建来执行）。在步骤1314中，执行MIaaS云的服务器验证（假设MIaaS云具有该验证并且不完全依赖于之前的步骤，从而成功而不用测试）；优选地没有更改，但在该点上，期望迁移的实例会比从目录映像提供的实例出现更多的问题，因此可以保留更多的用于修复的时间。
[0198] 在步骤1316中，通过向客户提供合适的密钥来为客户测试访问准备实例。在步骤1318中，如果需要，验证请求（即该流程的初始输入）的满足；在一个或多个实施例中，这可以通过缩短和自动化的过程来执行，在所述实施例中，与这是对MIaaS云门户的客户请求的普通情形相比，这仅是更大的迁移流程中的子流程。
[0199] 所示子流程对应于步骤556。
[0200] 在任何这些子流程之间会出现备份/快照和测试（相邻的总体步骤）；甚至是在它们内部，特别是在单独的调整之后的供应流程1310中，也会这样。
[0201] 以实例参数1304来开始采用流程
[0202] 在非限制的例子中，门户在TSRM中执行，并包括图形用户界面（GUI）和REST API（应用程序接口）。在一个或多个实施例中，通过REST API来开始被认为是合适的，因为从分析和计划步骤524的结果所有参数应是清楚的。这些参数可以位于数据库或另一定义良好的库中，从而可以由软件检索。而在图5中，在客户环境402中示出了分析和计划组件，其中出现被发现的数据，在某个时刻，用于调整步骤556的数据的相关部分应被传输到MIaaS云环境410，特别是其云管理区域680（在图5中忽略了该箭头以避免混乱）。传送代理682和传送核心组件690可以将其作为传输映像之外的附加任务来承担。但是，在某些情形下，可能需要通过GUI来初始地开始以更容易地对活动进行跟踪。
[0203] 在一个或多个实施例中，与该子步骤相关的分析和计划步骤524的结果应包括实例数据、分区计划等，从而正确的参数可被容易地输入到RESTAPI或由人操作者输入到GUI中。
[0204] 需要为着陆区域中的实例提供命名/位置方案，从而在此时，可以输入与哪个实例将被注册相关的信息。在一个或多个实施例中，在该名称下，VMware vCenter服务器知道所讨论的实例。在一个或多个实施例中，用实例的实际值来对GUI输入（大小、OS）进行自动检查是有用的。
[0205] 图14示出了来自MIaaS门户GUI门户设计自服务中心1402的示例性“Create Server”（创建服务器）弹出窗口1404。迁移服务器被分组为一个项目（project），且如果每个迁移请求可以包含多于一个实例（在该GUI中被称为映像），则提供“Configuration Set”（配置集）选项。给予用户选项来填上他或她想要使用的映像（image）的名称，或者点击放大镜来查看可用映像的列表。在一个或多个实施例中，VM大小信息应该是映像的元数据的一部分，并可能具有对它进行修改的选项。“Migrate Server”（迁移服务器）按钮开始实际的注册流程。门户现在可以执行特定的活动，例如在存储中记录开始的流程，以及允许从GUI或REST API查询其状态。
[0206] 门户流程—传递“采用”参数1308
[0207] 典型地，门户是与供应引擎1112分离的软件组件1110（特别地，是BSS的一部分），所述供应引擎是执行实际注册的组件（通常是工作流引擎并且是OSS的一部分）。因此，门户将注册请求传送到供应引擎。与在这两个组件之间传送的普通供应请求相比，被迁移的实例的“注册”或“导入”的选择以及该实例的位置/名称被传递，即，这些是该API中的该请求的新参数。
[0208] 供应流程—实例选取步骤1310
[0209] 在一个或多个实施例中，基于着陆区域中的合适的命名/位置方案以及供应引擎1112（例如TSAM），选取是清楚的，该供应引擎获取从门户1110（例如TSRM）采用的实例的名称/位置。在非限制的例子中，底层的VMware vCenter服务器中的实例的名称可被使用。该名称可能不是全局唯一的，但如果使用主机名，应该是可接受的，所述主机名可以假设在其他方面已经都是不同的。
[0210] 在着陆区域被物理分离的实施例中，可以使用特定的防火墙设置以及复制过程来执行实际的选取（这和从MIaaS映像库获取映像略有不同）。
[0211] 供应流程—调整概述1310
[0212] 现在回到图15，在1502，注意迁移之后但在调整之前的客户实例，即，直接在传输538之后的着陆区域中的云管理程序554上的实例，并且在1504，在迁移和调整之后的客户系统（被分解为客户部分1506和云服务器提供者部分1508），即，如它将在558处的生产区域中成为的那样。针对应用/中间件层1510，在该级别典型地计划做很少或不做更改（特别是因为在该例子中考虑仅迁移到MIaaS云而不是PaaS云），除了由某些基本OS配置方面例如IP地址的潜在更改带来的某些配置更改。在一个或多个实施例中，在该流程中不涉及应用，因为P2V典型地工作良好并且该流程可以用标准的P2V技术来执行。针对应用/中间件管理层
1512，在该级别典型地计划做很少或不做更改，除了与安全方面的或者由某些基本OS配置方面例如IP地址的潜在改变带来的某些配置更改。
1512，在该级别典型地计划做很少或不做更改，除了与安全方面的或者由某些基本OS配置方面例如IP地址的潜在改变带来的某些配置更改。
[0213] 针对OS管理层1514，该流程包括移除不再需要的客户管理套件组件以及对那些需要的进行策略调整；以及安装云服务提供者的标准管理套件和云服务提供者的云管理工具（关于后者，至少在某些情形下，在之前的方面实现代理，且中央工具已经存在）。在某些情形下，通过标准的供应流程来执行安装。移除和策略调整是重要的任务。
[0214] 关于方面1512、1514应注意，某些工具对于OS和App/MW层来说是公共的。
[0215] 针对OS层1516，在一个或多个实施例中，根据云服务提供者接受基本OS的需要来安装OS补丁的最小集合（在替代的实施例中，这可被实现为在其他方面为BAU云管理中的单独流程）。在某些情形下，执行“开放端口”检查。在一个或多个实施例中，在基本操作系统级别不需要更改，除了所需的OS配置更新例如IP地址。
[0216] 处理代理的选项
[0217] 在一个或多个实施例中，针对每种代理类型确定的重要选项包括：
[0218] ·可以忽略特定的代理？（最容易的流程）
[0219] ·必须保留某些代理？在非限制的例子中，可能存在确定的态度来保持AD（可以从美国华盛顿州Redmond的微软公司获得的活动目录认证产品）和Altiris（用于应用）。在一个或多个实施例中，用于应用管理的一切应当保持，并可能具有更改。
[0220] ·应该使某些代理无效？这意味着将它们关闭，但不是卸载它们。这是在代理看来不再需要、但根据给定的信息这还不是太清楚从而卸载有风险的时候的选择。
[0221] ·某些代理可以/必须被完全卸载？在某些情形下，这可以是合适的，以整理映像，或者因为代理需要资源（例如NetIQ的监控需要很多CPU）。在一个或多个实施例中，完全的卸载从来不是强制的，因为客户在这些服务器上可能具有各种类型的事物，并且云服务提供者对此进行判断。
[0222] ·代理典型地不允许具有根/管理员权限。在此时，应确定必须保留的那些是否可以运行而没有根/管理员权限；并且它们需要哪些更明确的权限。一个例子是仅用于补丁应用的Altiris。
[0223] 在某些实施例中，云服务提供者可以询问客户如何使用这些工具、客户具有什么策略、工具在哪里安装、等等。
[0224] 还应注意，云服务提供者计划的任何更改将需要大量的新发现努力—至少如果客户的安装和其他软件的安装一样可变和非标准化。
[0225] 小版本、修订包和安全补丁更新
[0226] 值得注意的是，可以从美国纽约州Armonk的国际商业机器公司获得的BigFix工具，现在被称为IBM Tivoli端点管理器，被认为是用于安全补丁的特别有用的工具；但是，其他实施例可以使用其他工具。
[0227] 其他组件中的地址更改
[0228] 在非限制的例子中，进行下列地址选择：
[0229] ·映像保留其DNS名称，即在切换期间，客户将更改用于他们的域的DNS条目（这比改变DNS名称要更容易得多，DNS名称可在应用/中间件层1510及其管理1512的很多组件中使用）。
[0230] ·实例在新的虚拟NIC（网络接口控制器）上获得两个新的IP地址，以启用MIaaS云的管理和备份任务，而不会干扰客户IP地址和（虚拟）NIC上的普通流量。
[0231] ·来自客户环境的IP地址被替换为MIaaS云生产区域的子网中的地址；这是应该在以上DNS条目中输入的。
[0232] 因此，在一个或多个实施例中，不需要改变对迁移的实例进行寻址的其他服务器和客户端，假设所述其他服务器或客户端使用DNS名称（而不是直接使用IP地址）；这逐渐变得常见。
[0233] 在某些情形下，在想要降低成本时，迁移组无法容易地确定客户是否使用IP地址来寻址。在这样的情形下，向客户提出要求以确保不会是这种情形，这是合适的。如果该要求被违反，在用户接受测试560中会出现问题，且修复会将实例或整个工作负载返回给客户。该问题独立于迁移路径或目标，特别是迁移至MIaaS云的事实。
[0234] 创建虚拟服务器1312
[0235] 在一个或多个实施例中，如果可以仅保持实例并且至多通过虚拟交换机或防火墙更改来将它置于不同的VLAN中，则不需要在此时创建任何服务器。否则，虚拟服务器创建和在MIaaS云的标准供应中一样来工作。
[0236] 为客户测试访问（密钥）准备实例
[0237] 在采用和调整流程的该时刻，需要在该实例自身完成的所有重要的事情都已被执行，并给予客户用于测试映像的访问。在该阶段，大多数客户ID仍然在实例或者相应的活动目录（AD）中。由于代理权限降低而改变的那些客户ID典型地应该已被设置。在某些情形下，云服务提供者会需要分发密钥，如果映像是基于密钥来访问的。在一个或多个实施例中，这和在本文其他处描述的用于目录映像的供应流程中一样地工作。
[0238] 服务器验证1104
[0239] 这样的认证可以不相对于目录映像的供应流程更改。在一个或多个实施例中，在该时刻的失败被认为在客户实例的情形下比在云服务提供者目录映像的情形下更显著可能地出现。至少在某些情形中，云服务提供者可以提供合适的修复。
[0240] 优选地尽可能多地自动执行该认证以及测试失败时的合适的修复。但更好的是，每当可以执行自动化测试和修复，在调整步骤中采取这些方面是可取的，即使为了合规或审计的原因而在服务认证阶段重复它们。
[0241] 请求认证1105
[0242] 在迁移的场景中，在事先已知每个周末（或者其他时间段）会发生什么时，该方面优选地被保持较短并且大部分自动化。但在UAT之后来自客户的最终许可能仍需要手工输入。
[0243] 此时，在采用和调整的细节之后（步骤556以及如图558所示的实例随后传送到生产区域中），可以恢复图5的整体快速迁移流程。现在进行用户接受测试（UAT）560（典型地不仅是一个实例的，而是该实例以及可能其他实例支持的业务应用的）。如果测试失败，应和客户一起进行人工决策，并考虑下列方面：
[0244] ·问题可能是能在云生产区域574中局部解决的小问题（例如DNS或防火墙未被正确地启动）
[0245] ·可能已知问题是调整失败—特定的调整可被跳过，例如特殊的安全补丁。如果单独的操作（例如尝试安装安全补丁）没有安全的回滚，云服务提供者可以回滚到之前存储的实例。如果在该调整中有人工决策，云服务提供者在某些情形下可以再次尝试不同的决策。
[0246] ·在某些情形下，如果不知道问题是调整失败，或者无法在更改窗口内修复问题，或者变化超过特定的阈值（例如，多于（例如）五个安全补丁不能被应用），则取消该实例（以及可能整个业务应用）的迁移。典型地基于备份532来重启客户实例520或522。
[0247] 切换并采用新实例
[0248] 如果UAT通过，客户开始使用云中的一个业务应用或其他迁移单元的实例。在如以上例子中那样做出寻址选择时，客户的DNS在此时改变；这可以包括改变反向DNS条目—可能作为标准过程的一部分。在某些情形下，更改窗口可以在这里结束。如果客户有特定的报警，例如web入口页上的“应用关闭”，现在可以将它们去掉。如果需要，可以提供合适的客户训练。
[0249] 值得重复的是，一个或多个实施例提供可跟踪和/或回滚能力的优势。此外，在这方面，可跟踪是很重要的优势，并且托管环境清楚地记录对映像执行的每个步骤且特别是调整，这非常有用。调整引擎以及TSAM/TSRM具有为完全透明/更改受控的迁移创建实例特有的日志的能力。关于回滚能力，调整引擎以逐步的模式来操作，且提供如果出现错误则回滚特定调整的能力。该能力与快照一起创建了相对安全的环境来执行所述的迁移/调整步骤。
[0250] 重述
[0251] 给定到目前为止的讨论，可以理解，一般来说，根据本发明的方面的示例性方法包括将外部实例684从客户环境402传送到目标基础架构即服务云环境410作为映像的步骤。该步骤例如可以通过组件690可选地通过与代理682交互来执行。另一步骤406包括将外部实例调整为基础架构即服务云环境的标准以获得调整的实例。该步骤例如可以通过组件
692来执行。又一步骤408包括将调整的实例注册到基础架构即服务云环境的管理系统中（一般是410；在一个或多个实施例中特别是696、698）。
692来执行。又一步骤408包括将调整的实例注册到基础架构即服务云环境的管理系统中（一般是410；在一个或多个实施例中特别是696、698）。
[0252] 一般来说，调整可以包括在外部实例运行时调整该外部实例，或者调整外部实例作为上述映像。
[0253] 在某些情形下，注册包括针对基础架构即服务云环境的标准目录映像（选择与外部映像类似的标准目录映像）来运行（例如如图11所示的）供应流程的至少一部分；以及用外部实例的映像交换标准目录映像。通常，该交换可在供应流程中或者在供应流程之后执行；在供应流程中执行时，这被称为在供应流程中选取外部实例的映像，而不是交换。此外，“在供应流程之后”交换应被理解为包括在步骤1102之后（且可选地在步骤1103的大部分或全部之后，但是在1104之前）。
[0254] 此外，在这方面，考虑三种方式来进行。回顾图11示出了针对目录映像的供应流程。在某些情形下，通过供应流程来进行直到几乎最后，如步骤1101-1103那样，以获得供应的实例；然后抛弃该供应的实例并将它替换为正被迁移的实例（这被称为交换）。在某些实施例中，目录映像从未被真的置于服务器上。在目录映像将被复制的时点，选取实例并使剩余的工作流程在迁移的实例上运行，从而在结束时需要做更少的工作（图13步骤1310）。在一个或多个实施例中，这一时点是在步骤1102的子步骤“创建虚拟机”中。步骤1103详细说明了该创建。在虚拟机创建中，这一时点是在“复制映像”的子步骤中—在这方面，被复制的是导入实例的映像而不是目录映像。
[0255] 正如所述，在一个或多个实施例中，基础架构即服务云环境是托管基础架构即服务云环境。于是，在这种情形下，传送包括报送至托管基础架构即服务云环境；调整包括调整至托管基础架构即服务云环境的标准；并且注册到管理系统包括注册到托管基础架构即服务云环境的管理系统。
[0256] 正如其他处所述，在调整步骤中，在某些情形下，标准包括安全标准、基础架构标准、补丁管理标准、以及基础架构管理系统标准（例如工具如696、698的标准）中的一个或多个。
[0257] 在某些情形下，额外的步骤524包括分析外部实例传送到目标基础架构即服务云环境的适合性；在该情形下，传送是响应于分析产生肯定的结果进行的。
[0258] 正如所述，在某些情形下，在分析步骤中多个外部实例被当做一个整体。
[0259] 在某些情形下，额外的步骤包括执行测试（例如参考判定框404、406、408）；一般来说，这种测试例如可以在传输之前、在传输之后、在两次调整之间、在调整之后以及在迁移之后执行。另一步骤包括在测试失败（框404、406、408的“不成功”分支）时执行修复和放弃中的至少一个。如其他处所述，在某些情形下，在测试步骤中多个外部实例被当做一个整体。
[0260] 在某些情形下，测试包括传送步骤之前的基线测试528，以及注册步骤之后的用户接受测试560。用户接受测试具有至少一个测试例。基线测试验证外部实例初始通过用户接受测试的至少一个测试例。
[0261] 在另一方面，装置包括存储器（例如RAM30、高速缓存32）；以及至少一个处理器16，其耦合到存储器且可操作地执行或促进上述方法步骤中的任一个、某些或全部。可选地，装置还包括多个单独的软件模块42,。每个单独的模块在计算机可读存储介质中实现，并且单独的软件模块包括传送核心组件模块、调整组件模块、以及注册组件模块；如本文其他处所讨论的。快照管理系统模块可选地包括图10中的子组件中的一个、某些或全部。
[0262] 在某些情形下，传送核心组件模块从客户环境中的传送代理获取外部实例，并将外部实例定位在基础架构即服务云环境的云着陆区域中。在某些实施例中，至少一个处理器可操作地将调整的实例实例化到基础机构即服务云环境的云生产区域中。
[0263] 在另一方面，在某些情形下，基础架构即服务云环境包括云着陆区域、云生产区域和云管理区域。在至少某些这样的情形下，至少一个处理器可操作地在云管理区域的控制下将外部实例传送到云着陆区域中；该至少一个处理器可操作地在云管理区域的控制下对云着陆区域中的外部实例进行调整；该至少一个处理器还可操作地将调整的实例实例化到云生产区域中；并且管理系统形成云管理区域的至少一部分。
[0264] 在某些情形下，云生产区域包括第一类型的云生产区域计算机硬件以及在所述第一类型的所述云生产区域计算机硬件上运行的第一类型的云生产区域管理程序；并且云着陆区域包括第一类型的云着陆区域计算机硬件和在所述第一类型的云着陆区域计算机硬件上运行的第一类型的云着陆区域管理程序。对在所述云着陆区域中管理的实例比在所述云生产区域中管理的实例施加更少的标准，并且所述云生产区域通过物理和逻辑技术中的至少一种从所述云生产区域分离，以避免所述云着陆区域影响所述云生产区域的安全性。换种方式来说，云着陆区域是和云生产区域中的相同类型的一组计算机硬件（例如服务器、存储装置等）和管理程序，但对其中管理的实例有更少的标准，并且从云生产区域物理并/或逻辑地分离，从而不会影响云生产区域的安全性。
[0265] 用于云迁移的管理基础架构分析
[0266] 一个或多个实施例有利地提供了用于云迁移的管理基础架构分析的技术。在目前的迁移分析技术中，特别在是其自动化部分中，焦点在于关键中间件例如应用服务器或数据库。云计算范式的的一个重要的优势在于简化了管理，这主要来自标准化基础架构软件和标准管理过程。一个或多个实施例有利地将自动化迁移分析扩展到这些管理方面。
[0267] 在基础架构即服务（IaaS）云中，提供给消费者的能力是供应处理、存储、网络和其他基本计算资源，其中，消费者能够部署和运行任意软件，其可以包括操作系统和应用。消费者不会管理或控制底层的云基础架构，但对操作系统、存储、部署的应用具有控制，以及对选择的网络组件（例如主机防火墙）的有限控制。硬件基础架构即服务（HIaaS）云提供基本虚拟机作为服务。它还可以提供操作系统（OS）甚至软件，但典型地不会提供对OS或软件的支持。
[0268] 另一方面，托管基础架构即服务（MIaaS）云提供了全服务的虚拟机。服务例如可以包括OS补丁以及对OS的安全性和合规的支持。MIaaS的一个重要方面是通过下列方式来简化管理：标准化到产生实例的目录映像的特定集合、在部署期间将这些实例自动关联到管理工具、以及/或不会给予客户OS级别的管理权限，从而实例上的操作系统保持为云管理员配置它们的样子。
[0269] 至今为止（在云计算范式的出现之前），不需要分析与基础架构标准的兼容性或者与变换到它关联的成本。云计算机范式的一个方面涉及通过基础架构标准化增强的效率。移到云计算还反映了一种趋势，其中，信息技术（IT）运行成本已经超过IT投资成本。为了获得对云计算资源的投资的巨大好处，一个或多个实施例从分析开始有利地促进现有环境迁移到这种标准化基础架构管理系统和过程。
[0270] 参考在本文其他处定义的IaaS云、HIaaS云、MIaaS云、实例、源实例、映像、目录映像、供应、重新安装迁移、基于映像的迁移、以及快速迁移到MIaaS云的定义。
[0271] 现在参考图16，并注意云描述16300；16100处所示的对要迁移的源系统的发现和分析（示例性源系统本身在图17中示出）；以及基础架构比较引擎16200来执行两者之间的比较（也被称为分析、映射和/或匹配）。云描述16300包括云基础架构软件标准和/或配置（“配置”）16310、16320。其中还包括云基础架构管理的应用级别的描述16330；例如，云提供的服务级别协议（SLA），或者非功能需求，其可被设置为应用接口（API）的一部分。可选地，描述16300还包括云基础架构管理过程16340。
[0272] 针对要迁移的源系统的发现和分析16100，步骤16100包括发现源基础架构客户端和服务器；步骤16120包括发现源基础架构配置和/或日志；并且步骤16130包括（例如通过推导来）获取源基础架构管理的应用级别描述。可选的，过程16100还包括步骤16140，即针对源的基础架构管理过程的发现和/或学习。
[0273] 过程16200包括源和目标云之间的比较。步骤16210包括源和云软件之间的匹配，可选地考虑变换成本，并且基于云基础架构软件标准16310和来自步骤16110的发现的源基础架构客户端和/或服务器。在一个或多个实施例中，该匹配过程涉及查找冲突，如本文其他处描述的。
[0274] ·源基础架构管理组件管理至少一个对象，至少一个强制目标基础架构管理组件将在目标云基础架构中管理该对象。
[0275] ·源基础架构管理组件使用至少一个资源，至少一个强制目标基础架构管理组件将在目标云计算架构中使用该资源。
[0276] ·客户端上的强制目标基础架构组件的当前缺失
[0277] ·不同版本的强制目标基础架构组件的存在
[0278] ·具有不同配置的强制基础架构组件的存在
[0279] 在步骤16220中，基于云基础架构配置标准16320和在步骤16120发现的源基础架构配置和/或日志来映射基础架构配置。在步骤16230，映射来自（16330的）云和（16130的）源的基础架构管理的应用级别描述（例如，如本文其他处讨论的非功能需求的描述）。在可选的步骤16240，映射来自（16340的）云和（16140的）源的基础架构管理过程。
[0280] 再一次，在一个或多个实施例中，比较和/或分析16200步骤可以涉及检查冲突。
[0281] 参考步骤16340、16140和16240，实际管理过程的比较是可选的。特别地，如果执行例如到现有云的根本迁移，则典型地只有应用级别的描述需要被映射。关于步骤16120，在一个或多个实施例中，基础架构配置被发现，以映射到目标云中可能不同的软件（仅通过非限制的例子，与美国加州Pala Alto的惠普公司的产品相关的HP事件过滤器可被用于源环境，并且可被映射到可从美国纽约州Armonk的国际商业机器公司获得的可在目标环境中使用的IBM Tivoli Monitoring（ITM）事件过滤器）。关于步骤16130，可以从详细的发现（例如高可用性配置、计划停机时间和补丁管理设置）来导出通常由人工探访得到的若干个源方面。即使仍然通过人工探访来获取，如果结果是固定格式的，仍可以在步骤16230中考虑自动化分析。关于步骤16230，典型地必须达到或超过当前基础架构的应用级别描述，除非业务所有者明确同意更低的级别。
[0282] 在替代的方法中，不是具有已给出的云描述，导出源环境的最合适的云描述可以是接洽（engagement）的一部分，例如，当整体目标是为企业构建合适的私有云时。
[0283] 作为回顾和提供额外的细节，在执行任何IT迁移、变换、现代化等之前，可取的是分析要保留的组件和要使用的新组建之间的兼容性。这可以包括例如选择保留什么和改变什么，以及对要进行的更改进行分析以实现兼容性。
[0284] 目前的迁移分析，特别是以定义良好的方法或甚至自动化的方式来执行的部分，集中在操作系统级别的兼容性，且有时集中在关键中间件例如应用服务器或数据库的兼容性。即，它们分析操作系统版本是否仍将在新的硬件上运行，或者数据库版本仍将在更新和相关的操作系统版本上运行。
[0285] 随着云特别是托管基础架构即服务（MIaaS）云的出现，目前的迁移分析是不够的，因为这些云还规定了基础架构管理工具和过程，以及服务器的特定标准，其允许基础架构管理以标准的方式来运行。
[0286] 一个或多个实施例有利地提供了一种用于基础架构管理方面主要是用于云迁移的自动化迁移分析的系统和方法。
[0287] 一个或多个实施例有利地提供了一种用于基础架构管理分析的系统化和/或自动化方法。
[0288] 分析基础架构管理迁移不同于分析中间件兼容性，因为重要的问题是源基础架构管理软件是否与云（特别是MIaaS）中的标准基础架构管理软件相冲突，并且需要被移除或修改（不同于源基础架构管理软件是否会在云操作系统上运行，这是在对中间件兼容性进行分析时需要分析的）。此外，与基础架构管理标准相关的其他设置需要被分析，例如假定的最小补丁级别。
[0289] 在MIaaS云中，迁移意味着需要基础架构分析。一个或多个实施例有利地提供了对所需的基础架构更改进行系统分析、并将它们用于本文其他处描述的“快速迁移”过程的能力。
[0290] 现在参考图19，在某些情况中，示例性方法在两个阶段中执行。在第一阶段1902，要分析的元素特别是来自源系统的源基础架构客户端和服务器可被聚集并与客户（对源系统负责的所有者或有关方）一起讨论。例如，云服务提供者可以向用户表明需要卸载客户的所有“Vendor-X-patching系统”。在第二阶段1904，该决定被用于单独的源系统，且如果在第一阶段不可能有一般的决定，其可能被改进。
[0291] 在一个或多个实施例中，相信检测冲突是可取的，所述冲突与第一阶段中的冲突管理相关。除非所有潜在基础架构软件的全面列表可用（如果编号为1901的阶段0已经可以很好地填充数据库1908并且客户的源环境中的所有软件已经在该数据库中，则会是这种情形），在此时分析整个软件列表以查看是否有这样的冲突，这是合适的。随着时间流逝，冲突和非冲突软件的上述数据库1909可以被发展。
[0292] 在某些情况中，可以通过下列方式来进行源基础架构软件16110的发现：执行对要迁移的实际机器的发现，所述实际的机器包括该源基础架构软件的客户端（例如资产管理代理）；检测该源基础架构软件的服务器（例如中央资产管理服务器）；以及/或通过部署的基础架构工具的调查表。
[0293] 于是，一个或多个实施例有利地提供了一种用于云迁移的管理基础架构分析的方法，包括：发现源基础架构中的基础架构组件；以及分析发现的基础架构组件与目标基础架构中的强制基础架构组件的冲突。
[0294] 在某些情形下，基础架构组件包括一个或多个基础架构客户端、基础架构服务器、基础架构配置和基础架构过程。
[0295] 在某些实施例中，冲突包括源基础架构组件管理强制目标基础架构组件会管理的相同的对象。
[0296] 在某些情形下，冲突包括源基础架构组件使用与强制目标基础架构组件所使用的相同的资源特别是端口。
[0297] 冲突的非限制示例包括下列的一种或多种：在客户端上当前缺少强制目标基础架构组件、存在不同版本的强制目标基础架构组件、以及存在具有可能不同配置的强制目标基础架构组件。
[0298] 在某些实施例中，分析步骤的结果包括以下的一个或多个推荐：卸载基础架构组件、安装基础架构组件、修改基础架构组件的配置、从迁移中排除具有特定组件的服务器、或者与客户进一步讨论基础架构组件。此外在这方面，后两个结果特别会在以下情况下出现：源基础架构组件处于冲突中，但很可能还被用于管理不在云控制下的对象，例如，迁移到MIaaS云时的中间件。
[0299] 在某些情形下，分析步骤分两个阶段执行；第一聚集阶段，其中，将所有发现的基础架构组件聚集并给予它们一般的推荐，以及第二每实例阶段，其中，推荐被应用于单个源系统并且在一般推荐未明确时被改善。
[0300] 在至少某些实施例中，分析步骤可以包括配置比较和/或过程比较。
[0301] 关于配置比较步骤16220，在某些情形下，对配置进行比较并对更改做出决策，这是可取的。如果基础架构软件被用于管理操作系统（OS）方面和应用方面两者，这尤其可取。例如，源服务器上的补丁软件可被设置以对OS以及数据库和web服务器打补丁。如果该源服务器被迁移至MIaaS云，则OS级别补丁需要被关闭以有利于云补丁软件，而数据库和web服务器补丁需要保持。另一方面，在其他情形下，源软件可被卸载，但服务器所有者会希望保留特定的策略，例如备份频率或监控事件的类型。
[0302] 现在考虑如图17和18所示的客户仪表盘1707的方面。MIaaS迁移可能出现的相关对齐问题是集成到整个客户仪表盘中。例如，客户可以具有“CIO（首席信息官）仪表盘”，其给出了应用和服务器的状态的概览。在将某些服务器迁移到MIaaS之后，客户可能需要保持这种仪表盘，既因为仪表盘还显示应用，并且/或者因为不是所有服务器都被迁移，但客户想要对迁移和未迁移的服务器的联合概览。在这些情形下，应提供从MIaaS软件的报告特征到客户仪表盘的适配器。在图18中通过将仪表盘1707也连接到云提供的编号为1806的目标管理程序2来表示该方面。
[0303] 现在将提供关于OS版本、补丁和安全性的相关观察。MIaaS云典型地规定的另一基础架构方面是精确的OS版本。对于OS，典型地适于决定容忍什么级别的偏差，以及在迁移之前什么可以自动更新。例如，可以决定是否容忍小版本偏差（例如v5.2而不是5.3），并且在小版本之间通常存在自动更新工具。考虑非版本OS类型，例如发布版（release）或版次（editions），也是合适的。
[0304] 在某些情形下可能需要添加补丁。但是，如果发现具有在先版本（back-level）补丁的源服务器，不太可能存在针对某些较新补丁的应用问题。理想地，事先应当努力尝试从应用所有者发现这一点。在补丁升级之后典型地应该进行仔细的应用测试。
[0305] 关于其他安全设置，有很多好的用于安全性的实践，例如不启用特定的服务和对特定OS文件的访问权限。应使源服务器符合这种需求。理想地，应用不要求相对于该最佳实践的现有偏差（例如，应用不应要求操作系统管理员密码仅6个字符长），但这也应当和应用所有者事先讨论。
[0306] 在一个或多个实施例中，至少有两种重要的方法来决定针对操作系统设置等特别是安全相关的设置来改变什么：
[0307] ·与来自目录的干净云映像进行比较。在某些情形下，该方法可能有问题，因为在典型的操作系统中，应用级别和OS级别设置无法被干净地分离。例如，如果源映像在端口上具有服务而目录映像在该端口上不具有，典型地需要验证这是否是有用的应用服务。
[0308] ·与安全验证机制进行比较，如果云具有这样的机制的话，例如服务激活检查。典型地必须实现在这里验证的设置。但是，云中的这种测试可能不是完整的，因为云可能依赖于其目录映像的干净。
[0309] 于是，在某些情形下，在上述两个阶段之前，可以存在一般的云迁移分析阶段，其中，决定那些安全设置是强制的。图19中编号为1901的阶段0描述了针对管理软件的一般云迁移分析；与其中描述的类似的方案也可被用于执行针对OS设置的一般云迁移分析。
[0310] 应继续参考图16，且现在还应参考图17。图17示出了示例性源环境1702，发现和分析可在其中执行。环境1702包括具有编号为1701的管理程序1的服务器1703。环境1702还包括具有管理程序1706的服务器1704，该管理程序与数据存储1708中的日志和/或配置相接口。物理上，数据存储1708可以或可以不和管理程序1706在相同的虚拟或物理服务器上。即，配置1708还可以在服务器1704内部；但是，对于大的管理程序，配置数据库1708确实可以在别的地方（即在服务器1704外部）。
[0311] 简便起见，图17中示出了两个管理程序；在典型的场景下，将存在长列表。管理程序1701、1706可以对应于例如“备份管理”和“合规管理”。
[0312] 环境1702（在该例子中）还包括两个实例1709、1716。这些是与以本文别处讨论的快速迁移方法来迁移的那些实例类似的实例，即，它们可以是物理或虚拟的。服务器1703、1704原则上也可以是虚拟的，且它们中的一些可被迁移，从而在一种观点看它们也是实例。
但是，一个或多个实施例解决了这样的情形，其中云（在图18的与管理区域1899中）具有其自己的管理程序，从而服务器1703、1704未被迁移。
但是，一个或多个实施例解决了这样的情形，其中云（在图18的与管理区域1899中）具有其自己的管理程序，从而服务器1703、1704未被迁移。
[0313] 环境1702包括管理程序1701、1706管理的一个或多个客户端1710、1713、1732。这些客户端例如可以位于实例1709、1716上，并且就它们与管理程序1701、1706的关系而言可以是客户端，而实例1709、1716还可以用作服务器，一个或多个应用1712、1714、1718、1720在其上运行。实例1709被管理程序1701、1706这两者管理，而实例1716仅被管理程序1706管理。这表明了每实例分析的合意性。
[0314] 实例1709具有OS设置1711且实例1716具有OS设置1717。客户端1710具有配置文件1715；客户端1713具有配置文件1731；并且客户端1732具有配置文件1733。
[0315] 在示出示例性目标（云）环境1802的图18中，假设编号为1701的管理程序1被保留（且由此其服务器以普通方式迁移到云生产区域中—见实例1803），而程序2被交换为云中（特别是在云管理区域1899中的服务器1804上）的相应程序1806。程序1806以和程序1706使用日志和配置1708类似的方式来利用日志和配置1808。
[0316] 图18还示出了略微改变（安全性、补丁等）的OS设置；这是用与图17中的设置1711、1717不同的编号1811、1817来示出的。实例1809与图17中的实例1709即实例1709的迁移版本类似；它包括具有配置1715的未更改的客户端1710，其由编号为1701的保留的管理程序1来管理。它还包括编号为1813的客户端，其具有配置1831、并且由编号1806的程序2来管理。
实例1816与图17中的实例1716类似；它包括编号为1832的客户端2，其具有配置1833、并且由编号为1806的程序2来管理。应用1712、1714、1718、1720现在在目标环境1802中运行。
实例1816与图17中的实例1716类似；它包括编号为1832的客户端2，其具有配置1833、并且由编号为1806的程序2来管理。应用1712、1714、1718、1720现在在目标环境1802中运行。
[0317] 在某些情形下，代替保留程序1，或者作为程序3，相同的管理程序还可能已经在云管理区域中存在。于是相应的客户端可被保留，并且问题变成了“配置”是否还保持相同或者被更改到用于该“配置”的云标准。
[0318] 图19示出了用于云迁移的管理基础架构分析中的示例性阶段。基本上存在编号为1901的准备阶段0，后面是两阶段的分析过程，包括编号为1902的阶段1和编号为1904的阶段2。在编号为1901的阶段0，在1905，仅基于云基础架构标准，进行抽象决策（例如，没有其他OS补丁管理软件可以运行“）。在1907，将抽象决策应用于某些众所周知的基础架构软件包。结果是管理客户端（版本）以及针对它们的一般决策的（至少部分）数据库1908；如下所解释的，数据库1908此后可被更新。
[0319] 在编号为1902的阶段1，在1911，在每个实例上发现源基础架构客户端和服务器。在步骤1912，聚集发现的版本。在步骤1913，对每个管理客户端版本制定一个一般计划（匹配步骤210的一部分，但不是对每个源实例）。步骤1913获得来自步骤1905、1912和数据库
1908的输入，并且也用其输出来更新数据库1908。步骤1913产生计划1914；可以理解，计划
1914是说明性且非限制的。
1908的输入，并且也用其输出来更新数据库1908。步骤1913产生计划1914；可以理解，计划
1914是说明性且非限制的。
[0320] 在编号为1904的阶段2，进行每实例的决策。在可选的步骤1916中，如果在以后执行阶段2，在给定的实例（例如包含在示例性计划1914中提到的管理客户端1、2、5的实例）上重新发现基础架构客户端。如果未执行重新发现，这种知识仍可以从步骤1911得到。在步骤1917，将计划应用于这些实例。在非限制的例子中，决定卸载客户端1，保留客户端2。步骤
1917由此获得来自可选步骤1916（或者来自步骤1911）和来自计划1914的输入。在其中计划
194表明“需要每实例决策”的步骤1918中，执行进一步的分析来决定（在非限制的例子中，针对客户端5来决定）。在可选的步骤1919中，进行到基础架构配置映射（如在步骤220那样）。在该例子中，这可能针对客户端2和5来执行。
1917由此获得来自可选步骤1916（或者来自步骤1911）和来自计划1914的输入。在其中计划
194表明“需要每实例决策”的步骤1918中，执行进一步的分析来决定（在非限制的例子中，针对客户端5来决定）。在可选的步骤1919中，进行到基础架构配置映射（如在步骤220那样）。在该例子中，这可能针对客户端2和5来执行。
[0321] 图20示出了用于关于冲突的决策的可能的用户接口，特别是用于阶段0（步骤1907）或阶段1（步骤1913），其中进行用于特定管理软件类型的一般推荐。在2002，查询在“Middleware Name”（中间件名称）字段输入的管理软件是否与云SCE+版本1.5中的任何软件冲突。在2004示出了响应：在该情形下，确实存在冲突，并且给出了冲突类型的解释。在另一用法中，可以（在视图2002的最底下的输入字段中）输入特定的软件所运行的端口，以检查端口冲突。
[0322] 下列SQL代码片段是可用于阶段2（步骤1917）中的决策的代码的简化版本。假设在源实例中安装的软件（管理软件和应用）被汇聚在表“MIDDLEWARE_INSTALL_MASTER”中，此外，假设组件1908被实现为数据库表“MW_MANAGEMENT_LOOPUP”，其中为简单起见，假设具有任何冲突的一切都被卸载，并且具有已知冲突的软件准确地汇集在在该表中。要做出的适当的决策是，基于中间件是否出现在第二张表中，是否针对前一张表中的每一行来卸载。下列查询这么做，并假设决策进入前一张表的“FUNCTION”一列。
[0323]
[0324] 图21通过非限制的例子示出了用于（HOST_NAME一列给出的）实例的小子集的可能结果。
[0325] 给定到此为止的讨论，可以理解，一般来说，根据本发明的方面的示例性方法包括步骤16100，其在具有源管理基础架构的源计算系统1702中发现至少一个源基础架构管理组件（下面给出了例子）。该步骤例如可以使用具有合适的修改的合适的发现工具来执行。特别地，已知的发现工具覆盖基础架构软件。但是，在发现软件中需要针对每软件的模块时，现有的包中的焦点可能在于中间件（数据库、web服务器等）上从而应当添加基础架构软件的新模块。此外，合适的是将工具的报告特征扩展为包含基础架构软件，并且针对表征基础架构软件的特定报告，从而步骤16110具有使得步骤16210和/或16120变得容易的输出。
给定这里的教导，技术人员将能够对现有的发现工具包进行合适的更改以实现一个或多个实施例。
给定这里的教导，技术人员将能够对现有的发现工具包进行合适的更改以实现一个或多个实施例。
[0326] 另一步骤包括获取具有目标管理基础架构（例如层64）的目标云基础架构的描述16300。该描述包括至少一个强制目标基础架构管理组件。例如通过使用合适的数据库程序来查询数据库中存储的描述61300，可以执行该步骤；非限制的例子包括可从美国纽约州Armonk的国际商业机器公司获得的IBM DB2软件，以及可以从美国加州Santa Clara的甲骨文公司获得的ORACLE软件。也可以通过查询云门户来进行；如果可能，通过编程接口，否则通过一个或多个用户界面。如果这些选项都不可用，可以从云服务提供者手动获取它。如果这也是不可能的，另一选项包括从云目录供应映像，以及在该映像上执行发现以查看其上安装了什么基础架构软件。该基础架构软件可能是云标准。
[0327] 到目前位置，假设需要迁移到具有给定的标准的给定的云。在某些情形下，在多种云之间仍存在选择；于是可以给出多个描述，并且步骤16210可以额外地查找最佳匹配的云。在另一方面，目标可以是为给定的源环境构建私有云；于是，合适的云基础架构软件标准可以在步骤16210中从对发现的源基础架构的分析导出。例如，如果发现80%的源服务器用监控软件X来监控，且20%用其他监控产品来监控，则监控软件X可被选择为用于新的私有云的标准，且只有剩余的20%的服务器上需要监控软件更改。
[0328] 另一步骤包括分析至少一个源基础架构管理组件来决定是否存在与至少一个强制目标基础架构管理组件的至少一个冲突。该步骤例如可以使用基础架构比较引擎16200来执行；参考本文别处的框16210的描述。
[0329] 在发现步骤中，至少一个源基础架构管理组件可以包括例如至少一个源基础架构管理客户端1710、1713、1732；至少一个源基础架构管理服务器（具有程序1706的1704）（可以在步骤16110中发现客户端和服务器）；至少一个源基础架构管理配置（例如，在数据存储1708、1715、1731和/或1733中）；以及/或者至少一个源基础架构管理日志（例如在数据存储
1708中）（可以在步骤16120中发现配置和日志）。上述所有元素典型地都会存在，但它们可能不会都被发现。例如，日志可能不会被发现。在至少某些实施例中，当焦点是安装/卸载时，发现客户端足够了；并且对于“阶段1”分析，发现管理程序足够了。
1708中）（可以在步骤16120中发现配置和日志）。上述所有元素典型地都会存在，但它们可能不会都被发现。例如，日志可能不会被发现。在至少某些实施例中，当焦点是安装/卸载时，发现客户端足够了；并且对于“阶段1”分析，发现管理程序足够了。
[0330] 在某些情形下，另一步骤16130包括获取源管理基础架构的非功能需求的描述（例如，使用上述发现工具）（在这里还被称为应用级别描述）。
[0331] 在某些情形下，在获取步骤中，目标云基础架构的描述包括云基础架构软件标准16310、云基础架构软件配置16320、以及/或目标管理架构的应用级别描述16330（即对管理基础架构的非功能需求的描述）。这些典型地是由当前考虑的实例所支持的企业应用来给出的。这些例如可以包括SLA或非功能需求，但SLA也可被当做是非功能需求。其他例子包括更改窗口、保持最新（up-to-dateness）策略（例如用于补丁或问题监控中的）、审计需求等。
这些中的很多典型地将被手动输入。应确保以固定的格式来这么做，以允许步骤16230中的自动比较。作为非限制的例子，如果云仅仅每4周提供特定的补丁，但企业应用具有每周需要这样的补丁的合规需求，则这样的企业应用不能在该特定的云上运行。
这些中的很多典型地将被手动输入。应确保以固定的格式来这么做，以允许步骤16230中的自动比较。作为非限制的例子，如果云仅仅每4周提供特定的补丁，但企业应用具有每周需要这样的补丁的合规需求，则这样的企业应用不能在该特定的云上运行。
[0332] 在如前一段落提到的情形下，分析步骤包括将云基础架构软件标准与至少一个源基础架构管理客户端和至少一个源基础架构管理服务器进行匹配，如在16210；将源管理基础架构的非功能需求的描述与目标管理基础架构的非功能需求的描述进行映射，如在16230；以及将云基础架构软件配置与至少一个源基础架构管理配置和至少一个源基础架构管理日志进行映射，如在16220。
[0333] 如从框16210到框16220以及从框16230到框16220的箭头所示，在某些情形下，在16220的云基础架构软件配置与至少一个源基础架构管理配置和至少一个源基础架构管理日志的映射至少部分基于在16210的云基础架构软件标准与至少一个源基础架构管理客户端和至少一个源基础架构管理服务器的映射，以及在16230的源管理基础架构的非功能需求的描述与目标管理基础架构的非功能需求的描述的映射。
[0334] 在某些实施例中，在发现步骤中，至少一个源基础架构管理组件还包括至少一个源基础架构管理过程，如16140所示；在获取步骤中，目标云基础架构的描述还包括至少一个目标基础架构管理过程16340；并且，如16240所示，分析还包括将至少一个源基础架构管理过程与至少一个目标基础架构管理过程进行映射。
[0335] 如从框16230到框16240的箭头所示，在某些情形下，在16240的至少一个源基础架构管理过程与至少一个目标基础架构管理过程的映射至少部分基于16230的源管理基础架构的非功能需求的描述与目标管理基础架构的非功能需求的描述的映射。
[0336] 在某些情形下，在分析步骤中，至少一个冲突包括至少一个源基础架构管理组件管理至少一个对象，且至少一个强制目标基础架构管理组件将在目标云基础架构中管理该对象。
[0337] 在某些实施例中，在分析步骤中，至少一个冲突包括至少一个源基础架构管理组件使用至少一个资源（例如端口），且至少一个强制目标基础架构管理组件将在目标云基础架构中使用该资源。
[0338] 在某些情形下，在分析步骤中，至少一个冲突包括下列中的一个或多个：在客户端上目前缺少强制目标基础架构组件、存在不同版本的强制目标基础架构组件、以及存在具有可能不同配置的强制目标基础架构组件。
[0339] 考虑在客户端上目前缺少强制目标基础架构组件。例如，如果云在所有实例上需要版本6.1的事件监控代理“ABC”（即，ABC是如1813的强制组件），并且源实例1709不包含任何版本的ABC，决定将是安装ABC。考虑不同版本的强制目标基础架构组件的存在。例如，如果源实例1709已经包含版本4.5或6.0的ABC，但云需要6.1，则会需要升级（如果是6.0则可能很容易）或卸载并重新安装（如果是4.5即非常老时可能会需要）。
[0340] 进一步考虑具有可能不同配置的强制目标基础架构组件的存在。如果已经存在版本6.1的ABC，或者存在6.0并且其具有到6.1的升级特征，它可以具有本地配置来表示它监控什么事件。在从云目录映像供应的实例上，可以存在ABC6.1的不同配置，其监控不同的事件集合。一种解决方案是用云标准配置来覆盖源配置。在该例子中，另一解决方案是结合两个配置从而事件的两个集合的并集被监控。如果相应的中心云管理程序，例如“ABCServer”（对应于1706），在出现意外事件时能容忍，这是可能的。如果ABCServer是处理这些事件的唯一工具，它仍然可以是无用的，但如果它将事件转发到客户仪表盘1707，它可以传递这些意外的事件。如果例如事件监控系统被用于监控来自应用1712的事件（例如该应用的崩溃和重启）和OS级别事件两者，这会有帮助。应用1712保持在客户的控制下，并且客户仍然想要在仪表盘1707中看到这些事件。
[0341] 在某些情形下，分析步骤包括以下的一个或多个：(i)推荐源基础架构组件的卸载；(ii)推荐目标基础架构组件的安装；(iii)推荐基础架构组件的修改配置；(iv)推荐从迁移中排除具有给定源基础架构组件的源环境中的服务器；以及/或(v)与客户进一步讨论给定的基础架构组件。特别是如果源基础架构组件处于冲突中但是相同的源基础架构组件可能被用于管理不在云控制下的对象，例如迁移到MIaaS云时的中间件（对应于应用1712、1714等），会出现后两个结果（排除(iv)/进一步讨论(v)）。关于可能性(i)-(iii)，提到的基础架构组件在迁移之前可以位于源环境中，可以在快速迁移期间和/或传输之后被调整，等等。关于可能性(iii)，相同的事物可在任一侧会开始—如果存在相同软件的源配置和标准目标配置，典型地会进行调整，并且某种折衷是合适的。关于(i)，可以决定不想要除了ABC以外的事件监控软件，并且除了ABC以外的任何软件可以被卸载。
[0342] 值得注意的是，“进一步讨论”选项（v）可以涉及人工代理。但是，自动引擎将需要输出该选项作为推荐。例如，如果在90%的情形下可以进行自动决策，但在10%的情形下不能，则已经很值得使用该引擎。但是，该引擎在剩下的10%情形下无法简单地猜测，它必须承认它不知道。在某些实施例中，这些问题以结构化的格式在界面上弹出来以回答它们，从而自动化可以从这里继续进行。如果需要几个人来决定，则可以提供协作工具。
[0343] 在某些情形下，发现包括在源计算系统中发现多个源基础架构管理组件；并且分析包括：初始聚集所有多个源基础架构管理组件；针对聚集的多个源基础架构管理组件来做出一般推荐；在每实例的基础上应用推荐；以及在一般推荐不确定的情形下改善某些应用的推荐。见例如图19和所附文字。
[0344] 在某些情形下，只在源计算系统中的至少一个物理机1709、1716上进行该发现，并且在其上至少一个物理机是软件1710、1713或1732，该软件是至少一个源基础架构管理组件的客户端。另一方面，在某些情形下，在源计算系统中的至少一个物理机上进行该发现，并且该至少一个物理机是服务器1704，至少一个源基础架构管理组件在其上运行。也可以使用问卷调查。
[0345] 在某些情形下，额外的步骤包括提供一种包含单独的软件模块的系统；每个单独的软件模块在非易失性计算机可读存储介质中实现。所述单独的软件模块包括发现工具模块来进行发现16100、描述模块来保持和访问描述16300（见获取描述16300的上述讨论）、以及基础架构比较引擎模块来实现引擎16200并进行分析。描述模块的例子包括合适的数据库软件来查询数据库中存储的描述16300；云门户查询代码（如果可能，通过编程接口来查询，否则通过一个或多个用户界面来查询）；或者代码，其供应来自云目录的映像，并在该映像上执行发现，以查看其上安装了什么基础架构软件。该基础架构软件很可能是云标准。
[0346] 发现工具的非限制例子包括可以从美国纽约州Armonk的国际商业机器公司获得的IBM Tivoli应用依赖性发现管理器（TADDM），IBM Galapagos工具等。关于IBM Galapagos工具，例如见：Galapagos:model-driven discovery of end-to-end application-storage relationships in distributed systems,IBM Journal of Research and Development archive,Volume52Issue4,July2008,Pages367-377。在某些情形下，关于发现工具，至少一部分（例如脚本或代理）典型地在源环境1702中运行，而另一部分在目标环境的专用服务器上运行。但是，整个发现工具可以在目标环境的专用服务器上运行，该目标环境具有与源环境1702的一个或多个连接。在某些情形下，整个发现工具可以在环境1702中运行。引擎16200和具有描述16300的数据库典型地将位于目标环境中（例如图3）。它们还可以位于单独的分析环境中，例如在执行分析的团队的服务器上。如上所讨论，现有的工具可被调整以实现本发明的方面。
[0347] 使用快照来降低迁移到标准虚拟化环境的风险
[0348] 硬件基础架构即服务云（HIaaS云）提供了基本虚拟机作为服务。它还可以提供操作系统和应用；但是，典型地不会给虚拟机（VM）上安装的任何软件提供支持。非限制的例子是可以从美国华盛顿州西雅图的亚马逊Web服务有限公司获得亚马逊弹性计算云（Amazon EC2）。托管基础架构及服务云（MIaaS云）提供了全服务虚拟机。服务合同包括为底层的虚拟机提供软件服务。这些服务包括用于提供的软件基础架构的软件升级、补丁支持、合规支持、许可管理等。非限制的例子是从美国纽约州Armonk的国际商业机器公司获得的IBM SmartCloud Enterprise+，也被称为IBM SCE+。基于映像的迁移将客户映像用于应用到云的迁移。该过程最小化昂贵的应用重新安装。云标准是将在云中运行和管理的客户映像需要满足的需求的最小集合。
[0349] 从信息技术（IT）管理的角度来看，激进地实施（例如操作系统（OS）、中间件和/或应用层的）标准化的宿主环境（云是非限制的例子）可以带来明显的管理成本节省。但是，将客户系统（被称为源系统）迁移到这样的标准化环境需要对源系统的软件栈进行更改以符合该标准。这些更改可能带来破坏源系统的高风险，使得它不可使用。
[0350] 近年来，公司已经不断采用虚拟化来实现硬件整合。一个或多个实施例解决迁移到标准化的虚拟化环境。这种标准化的虚拟化环境的一个例子是基础架构即服务（IaaS）云。在这里的一个或多个实施例中，云环境被用作标准化的虚拟化环境的非限制例子。但是，可以理解，一个或多个实施例可广泛用于一般标准化虚拟化环境，其可以暴露或可以不暴露和IaaS云相同类型的API。
[0351] 一个或多个实施例有利地提供了一种系统，其通过使用快照在迁移期间的关键时刻系统地捕获系统状态，来降低迁移的风险。此外，一个或多个实例提供了一种系统，其支持两种类型的快照：短期快照（STS）和长期快照（LTS），每种快照针对特定的使用场景来优化。此外，一个或多个实施例提供了一种方法，其通过短期快照和长期快照的组合来平衡“取快照”的各种需求（资源利用、性能影响、长期保存等）。另外，一个或多个实例提供了一种系统，其支持回滚到任何类型的快照。此外，一个或多个实施例提供了一种系统，自动提供对在迁移过程中被应用到源系统的准确更改的审计。可以在两种粒度下查看更改：文件级别和产品级别。两种信息级别可用于长期快照：文件系统（包括关于每个文件的元数据信息，例如文件名、所有者、权限、修改日期、以及可选的文件内容的散列）；以及系统中包含的产品（软件包）。
[0352] 为了避免疑问，这里使用的“快照”包括长期快照和短期快照两者；但是，“取快照”的过程是指短期快照的创建，而长期快照的创建被称为检入（check in）。
[0353] 以下是被称为“diffs”的文件级别和产品级别更改的非限制示例：
[0354]
[0355]
[0356] 有利地，一个或多个实施例通过在迁移期间的关键时刻提供被迁移的系统的“时间胶囊”来降低迁移的风险，从而在失败时系统可被回滚到“已知的良好状态”。客户还将知道在其系统被载入云之前在迁移期间对系统应用了何种更改。降低的风险带来了改进的接洽成功率、减少的应用停机时间、以及由于减少了失败时的调试时间而降低的迁移成本。
[0357] 值得注意的是，虚拟机（VM）快照和回滚是现代管理程序中可用的一般机制，其已被用于多种场景，例如系统调试和/或系统安全性。在一个或多个实施例中，“短期快照”基本上等同于VM快照；但是，使用场景不同（降低了迁移的风险）。此外，一个或多个实施例使用新颖的长期快照以及新颖的两种类型的快照的组合。
[0358] 还值得注意，传统的备份工具被用于备份系统以及之后将系统恢复到备份之前的状态。在一个或多个实施例中，长期快照被存储为映像库中的映像对象；现有的备份系统处理文件系统的概念，而映像是文件系统的超集。映像还包括虚拟机的方面，例如中央处理单元（CPU）、存储器配置等。映像库提供版本化和分析能力。
[0359] 现在参考图22，一个或多个实施例通过使用映像库有利地降低了迁移风险。这里，“快照”动作产生了短期快照，于是2216-2228是短期快照。“检入”到映像库2202的动作产生了长期快照2206、2208、2210。在一个或多个实例中，捕获关键时刻的状态，以形成映像版本链（例如，版本零2204、版本一2206、版本二2208、以及版本“n”2210）。在系统故障的情形下，一个或多个实施例反回至“最后已知的良好状态”。一个或多个实例追溯地“自我检查”（introspect）映像版本（检查过去时刻的系统的内容）。一个或多个实例在文件级别对任何一对版本“比较差异”（即进行比较以识别差异），以理解它们之间进行的更改。此外就此而言，作为自我检查方面的一部分，一个或多个实施例重构较早的状态。例如，当映像被检入到映像库时，内容（元信息）被解析和存储在映像库中，且产生的数据结构随后可被检查。在短期的情形下（例如VMware中的短期快照），可以执行回滚过程。
[0360] 仍然参考图22，过程从原始映像2212开始（在物理到虚拟（“P2V”）转换之后）。在2204，该原始映像被导入到映像库2202作为版本零。在2230开始原始映像的实例。在2246进行第一次调整，从实例2230转变为实例2234。对每个增量更改，即实例2232和实例2234的更改，取快照2216、2218（实例2230仅是P2V之后的原始映像的实例化，因此不需要快照，尽管在需要时可以取快照）。快照是短期性质的。在完成第一次调整2246之后，快照2218被检入到（长期）映像库作为2206处的版本一。在2248进行第二次调整，从实例2234转变为实例
2240。对每个增量更改，即实例2236、2238、2240的更改，取快照2220、2222、2224。在完成第二次调整之后，快照2224被检入到映像库作为2208处的版本二。在2250进一步调整，从实例
2240转变为实例2244。对每个增量更改，即实例2242、2244的更改，取快照2226、2228。在完成第三次调整2250之后，快照2228被检入到映像库作为2210处的版本“n”。如省略符号所示，可以进行想要的任何次数的调整。时间沿着轴从左到右增加。再次，从2232-2244到
2216-2228的箭头表示短期取快照过程，且从2218、2224、2228到2206、2208、2210的箭头表示长期检入过程。
2240。对每个增量更改，即实例2236、2238、2240的更改，取快照2220、2222、2224。在完成第二次调整之后，快照2224被检入到映像库作为2208处的版本二。在2250进一步调整，从实例
2240转变为实例2244。对每个增量更改，即实例2242、2244的更改，取快照2226、2228。在完成第三次调整2250之后，快照2228被检入到映像库作为2210处的版本“n”。如省略符号所示，可以进行想要的任何次数的调整。时间沿着轴从左到右增加。再次，从2232-2244到
2216-2228的箭头表示短期取快照过程，且从2218、2224、2228到2206、2208、2210的箭头表示长期检入过程。
[0361] 元素2230-2244表示不同时刻的相同运行实例。如在2216-2228处对每个小更改取快照；但是，只有完成重要的调整2246、2248、2250才会触发长期快照2206、2208、2210的检入。长期快照和短期快照的频率因此不同。
[0362] 短期快照相对生存期较短（例如迁移窗口的持续时间，这典型地从几小时到一个周末），并包含存储器状态。短期快照被用于临时调试的目的，且典型地旨在调试完成后丢弃。短期快照更频繁地出现，由此需要更快（几秒量级）的操作。现代管理程序可以支持短期快照；VMware是非限制的例子（VMware软件可以从美国加州Palo Alto的VMware公司获得）。但是，每个快照创建了快照链中的新节点。在现代管理程序中的快照的几乎所有实现中，使用写时复制技术，其中，在只读的父之上创建写时复制的子，从而允许非常快速的创建操作（没有数据复制）。后续的写操作仅针对子，而读操作针对子和父两者。当针对相同的VM来创建多个快照时，形成快照链，其中，每个快照都是链中的节点。于是读操作的性能依赖于链的长度，因为管理程序可能必须遍历该快照链一直到头，以取回被请求的数据。
[0363] 在至少某些实例中，长链导致性能降低和不稳定，且由此不适合生产系统。在一个或多个实施例中，虚拟机实例2232-2244的短期快照2216-2228被频繁获取，并且被存储在管理程序中作为虚拟机映像。长期快照2204-2210被不太频繁地获取（例如在开始状态2212和在调整2246、2248、2250之后），并被检入作为映像库2202中的映像（2204）、2206、2208、2210。长期快照类似长期备份，但在几个方面不同。
[0364] 特别地，关于长期快照，在某些实例中，在迁移很久之后（例如处于稳态中）可能出现问题；在这种情形下，仍然需要反回至“最后已知的良好状态”。客户将需要（例如用于审计和/或合规的目的的）调整之前的原始映像的快照。使用映像库2202在该情形下更为合适。一个或多个实施例由此在映像库中存储映像作为长期保存的持久化（persistent）数据。此外，映像库提供了对存储的长期映像的版本化和分析能力。但是，映像库中的长期快照典型地操作更为低效（几十分钟的量级）。
[0365] 现在参考图23和24，在一个或多个实例中，快照管理系统2340（简便起见，在图中用“快照获取器”来标记）管理短期快照2346和长期快照2344两者（快照管理系统还发起如下所述的回滚）。在一个或多个非限制的示例性实施例中，短期快照2346是VMware快照（VM实例的VM映像），其位于VMware数据中心2342中的操作库2468中，而长期快照2344被检入到虚拟映像库2202的参考库2456中。如这里所使用的，操作库被定义为管理程序存储对应于运行、挂起和/或停止的VM实例的映像文件的存储位置。快照管理系统2340创建并删除VMware数据中心2342中的VM实例2470形式的短期快照。实例的映像在需要时向操作库2468检入或从其检出。VMware数据中心被用于短期快照在生产环境2452中的回滚。在需要长期快照时，操作库中的映像被检入到分析环境2450中的参考库2456中。索引器2458将参考库2456中的映像编制索引，且可选地也将操作库2468和/或VM实例2470中的映像编制索引，以创建知识库2460。引擎2462使用该知识库来进行分析。
[0366] 此外就此而言，快照管理系统2340（频繁）创建执行的虚拟机实例2470的短期快照（快照管理系统2340还时而删除短期快照）。短期快照作为在管理程序上执行的虚拟机实例2470的虚拟机映像存储在库2468中。当需要创建长期快照时（例如在调整之前），快照管理系统2340使得库2468中相应的一个虚拟机映像被放置到参考库2456中。另一方面，如图25所示，在需要回滚时，快照管理系统2340从参考库2456中检出映像作为模板，并将它放置到操作库2468中（如2572所示），然后重新配置模板以匹配现有的VM实例并基于该模板来实例化新的虚拟机2573，该VM映像2573与要回滚的现有VM实例进行交换。
[0367] 为了避免疑问，“检入”是指将某事物置于虚拟映像库中，且“检出”是指从虚拟映像库中取出某事物（具有版本控制）；这些术语不是针对VMware数据存储来使用的，因为在该上下文中VMware没有版本控制并且发生的仅是简单的文件拷贝操作。在一个或多个实施例中，长期和短期映像都是由调整触发的。对调整中的每个增量步骤取短期快照，而仅在重要的调整过程的开始和结束时取长期快照，跳过中间的所有增量调整。这在图22中示出。在其他实施例可使用其他方法。
[0368] 注意到图24中的VIL与图23中的映像库2202相同；并且图23和24中的操作库2468例如可以是VMware数据存储。
[0369] 图25于是示出了示例性回滚至特定的长期快照。在步骤1中，基于其长期快照标识符（LTS ID），映像2576在映像库2202中被定位。在步骤2中，映像被检出，作为操作库2468中的模板2572。在步骤3中，该模板被重新配置以匹配现有的VM实例2574，并且新的VM2573被实例化。在步骤4中，用新的VM2573来交换现有的虚拟机实例2574。
[0370] 再一次，作为总结，在一个或多个实施例中，回滚到长期快照涉及下列步骤：
[0371] 1.给定长期快照ID来定位库中的映像
[0372] 2.从库中检出映像到操作库，作为映像模板
[0373] 3.重新配置模板以匹配现有的VM实例并实例化新的VM
[0374] 4.将与新创建的VM实例关联的映像文件与现有的VM的映像文件进行交换[0375] 图26示出了对迁移期间映像的确切更改进行计算的方法的流程图。在步骤2602中，定位原始客户映像（例如2204）的长期映像。在步骤2604中，定位在所有调整完成之后（例如2210）的长期快照。在步骤2606中，在文件和/或产品级别计算两个版本之间的差异（见上面的例子）；然后，在步骤2608中，返回结果。
[0376] 图27示出了示例性过程流。如2702所示，以选择性的检入来对初始状态取快照（根据具体情况，图27中在取快照或检入旁边的星号表示选择性快照或选择性检入）。再一次，取快照创建了短期快照，而检入创建了长期快照。在2704中，进行第一次调整（例如图22中的调整2222）。在决策块2706中（，手动和/或计算机辅助地）确定第一次调整是否成功。如果不是，在步骤2708选择性取快照和选择性检入，并在步骤2710回滚到前一配置，在步骤2712进行任何所需的手动修复。然后，如果需要，可再次尝试进行第一次调整。另一方面，如果第一次调整成功，如2714所示，以选择性的检入来对更新的状态取快照。然后在步骤2716进行第二次调整（例如在图22中的调整2226）。在决策块2718中，确定第二次调整是否成功。如果不是，在步骤2720选择性地取快照和选择性地检入，并在步骤2722中回滚到前一配置，在步骤2724进行任何需要的手动修复。然后，如果需要，可再次尝试进行第二次调整。另一方面，如果第二次调整成功，处理可以继续；例如，以进一步更新状态的快照和选择性检入来继续，后面是任何其他调整（未示出）。
[0377] 一个或多个实施例由此有利地提供了一种系统，其通过使用短期和长期快照的组合来系统地捕获系统状态并支持回滚到任何快照，来降低迁移的风险。一个或多个实例提供了一种方法，其用于启动短期和长期快照并将它们进行分离，以及基于虚拟映像库（基于VIL）的长期快照。如图25所示，一个或多个实施例提供了一种回滚到长期快照的方法。一个或多个实施例允许在产品和/或文件级别对长期快照进行比较。此外，如图26所示，一个或多个实例提供了一种方法，其用于计算在迁移过程中对定制映像所做的产品级别和文件级别更改，其输出可用作审计记录提供给需要该记录的客户。此外，如图27所示，一个或多个实施例提供了一种过程，其将快照和回滚与VM上的每个有风险的操作（例如调整2222、2226、2230）相集成。
[0378] 值得注意的是，尽管检查点的概念已经存在很长时间，它主要被用于周期性的保存长期运行的系统的状态，从而如果系统发生故障它可以从最后的检查点恢复计算而不是从零开始（与一个或多个实施例中被用于云迁移不同）。
[0379] 给定到目前为止的讨论，可以理解，一般而言，根据本发明的方面的示例性方法包括下列步骤：在从源系统迁移到标准化虚拟环境的过程中，对在管理程序2342上执行的源系统的虚拟机实例2470取快照，作为在管理程序的操作库2468中的虚拟机映像。操作库中的虚拟机映像是短期快照2216-2228。该步骤例如可以通过快照管理系统2340向管理程序（VMware是后者的非限制示例）调用或发出命令来执行。该方法还包括在迁移过程中时而创建源系统的长期快照2344。通过将这些虚拟机映像中的给定虚拟机映像从管理程序操作库检入到映像库2202作为映像对象（例如在参考库2456中），长期快照被创建。该步骤例如可以通过快照管理系统2340向虚拟映像库2202调用或发出命令来执行。
[0380] 此外针对取快照的步骤，取快照机制本身典型地由已知的管理程序提供。但是，在一个或多个实施例中，快照管理系统2340发出命令到或调用管理程序。即，现有的管理程序本身具有取快照的能力，但是在一个或多个实施例中，提供了新的代码段，即快照管理系统2340。参考图28中的示例性细节，系统2340具有逻辑来确定何时发出命令。在一个或多个实施例中，快照管理系统2340具有数据结构或映射表等，其可以将给定的VMID映射为长期快照。系统2340还具有逻辑从而在被请求回滚到长期快照时，系统2340将从映射知道将从映像库中获取长期映像的哪个版本，检出和交换，如图25所示。快照管理系统2340由此是基于外部输入来执行图23和25中的逻辑的软件。如图23所示，输入包括取长期快照的命令、取短期快照的命令或者回滚到之前状态的命令。API管理器2802验证输入命令的参数，并创建和连接到任何需要的服务。协调器2804根据需要将命令分解为一系列命令，其可被相关的管理程序和虚拟映像库（在该非限制的例子中分别是VMware vCenter和IBM VIL）理解。协调器2804还协调命令执行并获取和处理结果和错误。
[0381] 对于取短期快照，在进行适当的检查和转换为对象之后，协调器2804调用VMware程序API2806或其他VMware适配器。对于取长期快照，虚拟映像库查询执行器2808被用于映像库2202交互，如图25所示。VMDK交换适配器2810建立并执行VMDK交换命令以实现图25中所示的交换过程。
[0382] 于是，通过在快照管理系统2340控制下的VIL2202执行创建长期快照的步骤。一个合适的虚拟映像库是可以从美国纽约州Armonk的国际商业机器公司获得的IBM SmartCard供应虚拟映像库。
[0383] 可以理解，云例如MIaaS云或其他云是标准化虚拟环境的非限制示例。
[0384] 在某些情形下，时而创建长期快照包括在迁移过程期间的重要调整（例如图22中的2222、2226和2230）之前创建长期快照。
[0385] 如图25中最佳所示的某些情形还包括启动回滚。这可以通过下列方式来执行：
[0386] ·如步骤1所示，在映像库2202中定位映像对象2576中的给定映像对象；
[0387] ·如步骤2所示，从映像库中检出映像对象中的给定映像对象作为模板2572；
[0388] ·将模板2572放置到管理程序操作库2468中；以及
[0389] ·如步骤3和4以及位置2573、2574所示，将来自管理程序操作库的模板实例化为管理程序中的回滚虚拟机实例（其中，它替换有问题从而需要回滚到前一状态的现有VM实例2574）。
[0390] 正如指出的，在一个或多个实施例中，这样的回滚可以在迁移之后的稳定状态条件期间开始。
[0391] 如图26所示，在某些情形下，可以通过步骤2602所示的在映像库中定位映像对象中的第一给定映像对象来确定在迁移期间进行的更改。映像对象中的第一给定映像对象对应于与源系统的原始客户映像（例如2204）关联的一个长期快照。如步骤2604所示，确定更改的另一步骤包括在映像库中定位映像对象的中的第二给定映像对象。映像对象中的第二给定映像对象对应于与源系统的在完成重要的调整之后的客户映像（例如2210）关联的一个长期快照。在步骤2606中，计算映像对象中的第一和第二给定映像对象之间的差异（例如使用引擎2462—在某些情形下，可以使用上述IBM SmartCloud供应虚拟映像库中的“差异”特征）。另一步骤包括向人类操作者展示差异（例如，通过合适的图形用户界面（GUI）在显示器24等上面显示该差异）。计算的差异可以是例如文件级别的差异和/或产品级别的差异）。
[0392] 在某些情形下，另一步骤可以包括将版本号分配给如图22所示的每个长期快照；即V.1,V.2,…,V.n。结果是映像的版本链，每个对应于进行的重要调整；从而有效地提供了源控制系统。
[0393] 另一方面，装置包括存储器（例如RAM30、高速缓存32）；以及至少一个处理器16，其耦合到存储器且可操作地执行或以其他方式促进上述方法步骤中的任一个、某些或全部。可选地，装置还包括多个单独的软件模块42。每个单独的软件模块在计算机可读存储介质上实现，并且单独的软件模块包括如本文别处讨论的快照管理系统模块、管理程序模块和虚拟映像库模块。快照管理系统模块可选地包括图28中的子组件中的一个、某些或全部。
[0394] 替换虚拟机盘
[0395] 虚拟机（VM）是和物理机类似地执行程序的计算机的软件实现。虚拟机可以具有与之关联的一块或多块虚拟盘。一个或多个实施例通过提供以下的一种或多种技术有利地促进了云计算的增长：
[0396] o将与源虚拟机（映像或实例）关联的一块或多块盘迁移到目标虚拟机的技术；
[0397] o使用虚拟盘的不同集合来恢复虚拟机的技术；以及/或
[0398] o能完成迁移和/或恢复而不用改变与虚拟机关联的唯一ID的技术。
[0399] 有利地，一个或多个实施例提供了技术，其用另一虚拟机或其映像的盘来替换与现有虚拟机关联的盘，而不影响虚拟机的功能或身份。确实，一个或多个实施例提供了支持用和另一虚拟机或映像关联的盘来替换与虚拟机关联的盘的能力的技术；确定虚拟机配置及其盘的兼容性的技术；以及/或确保产生的虚拟机在盘被替换后继续工作的技术。
[0400] 此外，在这方面，并且现在参考图34，在至少某些实施例中，共存在如下所列的四种状态。“映像”是离线/休眠/静态的，如虚拟机的“映像”那样。实例是正在运行的虚拟机或被注册为能够在虚拟机中运行，如映像的“实例”那样。如图34所示，“虚拟机映像”或“映像”或“虚拟机模板”3402包括至少包含操作系统的虚拟盘3406、以及虚拟硬件建议3408例如CPU、存储器和/或盘。“虚拟机”或“实例”或“映像的实例”3404包括3406和3408，以及CPU、存储器和/或盘的虚拟硬件分配3410，以及虚拟机运行时3412的管理程序。上述四个状态包括：
[0401] 1.独立于管理程序而存在的映像（即文件系统中的文件）—虚拟机映像[0402] 2.注册到管理程序的映像（即模板或克隆源）—虚拟机映像
[0403] 3.注册到管理程序但没有运行的虚拟机（即关闭的虚拟机）—虚拟机
[0404] 4.注册到管理程序并且在运行的虚拟机（即开启的虚拟机）—虚拟机
[0405] 目标的替换可以从这些源状态中的任一个出现。因此，在最一般的情形下，源可以但不是必须是如（1）和（2）那样的“映像格式”，或者它可以如（3）或（4）那样来直接传输。
[0406] 此外，一个或多个实施例提供了一种系统化方法，其使得云能够采用现有的服务器，而不需要将应用迁移到纯粹新的云实例；以及/或者一种规则系统，其捕获源和目标虚拟机的哪些属性应被保留以维持虚拟机功能，并且对于父管理程序和/或云来说不可检测。
[0407] 在至少某些情形下，虚拟机可被替换，而不使外部元素例如云管理栈知道。该能力允许对虚拟机进行大量更改（例如，替换所有盘的内容）而不让管理程序或依赖的管理栈意识到该更改。例如，可以使用一个或多个实施例将外部虚拟机迁移到托管云中，由此使得云能够导入现有的虚拟机。此外，可以使用一个或多个实施例将虚拟机恢复到前一状态。
[0408] 现在注意图29的系统图。注意源虚拟机2901，其具有一块或多块盘，例如编号为2906的盘1和编号为2908的盘2。盘2906、2908、2910、2912都是虚拟盘。将结合例如图36来进一步讨论虚拟盘。系统还包括虚拟机盘替换器，例如映像替换器2902，其根据合并规则2914来操作。需要用盘2906、2908来替换目标VM2903上的盘1和盘2，2910、2920。盘2910、2912还表示迁移之后的状态；即，在迁移之前，盘12910和盘22912处于原始状态，而在迁移之后，它们分别被有效地替换为盘2906、2908。目标虚拟机2903由管理程序2904管理，且整体目标云环境由云管理软件2905来管理。
[0409] 现在还参考图30，云管理程序3001（和管理程序2904一样）是由想要的目标云管理的管理程序；假设在管理程序3001中运行的所有实例都是由云来管理的。注意到在图29中，源被示出为在云管理程序外部，而在图30中，源和目标两者都位于相同的管理程序中。这些场景不同，但两者都是有效和可能的。客户映像被导入到云环境，并且是图30所示的技术中的源3002；云映像3003是目标。如其他地方所示，并非总是需要源的映像。源3002在虚拟机3004上实现。虚拟盘描述符3006是描述虚拟盘3008的属性的元文件，所述虚拟盘是存储盘内容的实际块分配。
[0410] 云采用器3010实现这里根据合并规则2914所描述的一种或多种技术。图30中的合并规则2914和图29中的合并规则2914一样。元素3010和元素2902一样；元素3004和元素2901一样；元素3005和元素2903一样。盘3008包括2906、2908中的一个。盘3009包括盘2910、
2912中的一个。注意到图36提供了虚拟盘描述符与虚拟盘盘区与虚拟盘的关系的额外细节。合并规则2914提供了关于源虚拟盘描述符、目标虚拟盘描述符和过程的那些属性被包含在最终的目标盘描述符3007中的特定规则。合并规则确保了产生的虚拟机3005执行，并且云管理层和管理程序3001无法注意到差异。虚拟盘3009是实际的块分配，其中，盘内容被存储在新的虚拟机3005中。
2912中的一个。注意到图36提供了虚拟盘描述符与虚拟盘盘区与虚拟盘的关系的额外细节。合并规则2914提供了关于源虚拟盘描述符、目标虚拟盘描述符和过程的那些属性被包含在最终的目标盘描述符3007中的特定规则。合并规则确保了产生的虚拟机3005执行，并且云管理层和管理程序3001无法注意到差异。虚拟盘3009是实际的块分配，其中，盘内容被存储在新的虚拟机3005中。
[0411] 继续关注图29和30，还考虑图31，其示出了用源虚拟机2901、3004中的盘来替换VM2903、3005中的盘集合的过程。在步骤3101中，识别接收云实例2903、3003。在一个或多个实施例中，目标是处于关闭状态的虚拟机（实例）。在步骤3102中，识别客户源2901、3002。在步骤3103中，将VM2901、3004的虚拟资源与VM2903、3005的进行比较。在步骤3104中，确定资源是否是兼容的；如果不是，在3105拒绝所提议的替换，且然后在3111结束过程。
[0412] 现在应参考图35和36。注意VM映像3502。在管理程序中，典型地存在整体VM描述（文件）3504，其阐述了虚拟机的所有虚拟硬件特征。在某些情形下，如图35所示，关于虚拟盘3604的所有相关盘信息被包含在该单个主文件中。在其他情形下，如图36所示，主文件3604引用其他文件（描述符）3610、3612，其包括一块或多块虚拟盘3614、3616、3618的细节。
[0413] 图36由此是虚拟机映像或实例的例子，其在VM资源描述符和实际的虚拟盘之间具有一个级别的间接性。虚拟盘描述符包含关于一个或多个支持盘的元信息。该例子将向虚拟机操作系统展示两块盘，但是由三个单独的虚拟盘文件来实现。
[0414] 现在回到图31，如果虚拟资源是兼容的，如判定框3104的是分支所示，在步骤3106中将源虚拟资源描述符3112（例如虚拟盘描述符3006）和目标虚拟资源描述符3113（例如虚拟盘描述符3007）进行合并。此外，就此而言，元素3007和3113表示替换发生之前的目标盘描述符。在合并和替换之后，元素3007变成更新的版本，这是源和目标的参数的组合。步骤3108的一部分包括写入新的目标盘描述符3007的步骤。见图32。
[0415] 在判定框3107中，确定步骤3106中的虚拟资源描述符的合并是否成功；如果不是，过程在3111结束。另一方面，如果步骤3106中的虚拟资源描述符的合并确实成功，进行到步骤3108并如图33中的3303所示替换虚拟盘。在判定框3109中，确定源VM是否具有更多的盘；如果是，根据需要来重复步骤3106-3109；如果不是，在步骤3110中更新整体资源描述符。步骤3110是可选的，并且取决于所操作的VM是否使用图35或图36的方法。处理在3111结束。
[0416] 此外，针对图35和36，实现可以不同，这在于所有虚拟机资源信息（包括盘）可被存储在如图35所示的单个文件中，或者它可被分隔为如图36所示的很多文件。该方法依赖于管理程序，并和组件的解耦级别相关（即，对于具有虚拟盘描述符的例子，在整体虚拟机定义中存在链接到那些描述符的引用，于是描述符中有与底层的盘的实际特征相关的更多信息）。当使用图36的方法时，步骤3110是合适的。
[0417] 图32展示了合并步骤3106的示例性细节。在步骤3203中，访问源描述符3112。在步骤3204中，访问目标描述符3113。在步骤3205中，检验属性。在判定框3206中，基于合并规则2912至少确定所讨论的属性对于源来说是否是关键的。
[0418] 就此而言，合并规则2912特定于目标管理程序（非限制的例子包括可从美国加州的Palo Alto的VMware公司获得的VMware虚拟化软件）、KVM软件（用于基于内核的虚拟机）（可从美国北卡罗莱纳州的Raleigh的RedHat公司获得）、Xen软件（可以从美国佛罗里达州Ft.Lauderdale的Citrix Systems公司获得），等等）。在步骤3205和判定框3206中，在检查源和目标环境两者的属性时，进行若干确定。以下关于图37来进一步讨论步骤3206-708。针对源属性，例如可以确定源的属性A必须持久以确保虚拟机在目标云中继续运行。这种源属性的例子包括虚拟盘输入输出（IO）控制器、块大小、块数量等。在步骤3207中，该信息被写入到“新”的目标描述符（这是源和目标参数/值的组合）—见下面的图37的讨论。针对目标属性，例如可以确定目标的属性B必须持久以确保云成功地采用虚拟机（管理程序或云都不会注意到差异）。这种目标属性的例子包括虚拟盘唯一标识符。在步骤3208中，该信息被写入到新合并的描述符中。处理然后进行到步骤3210。
[0419] 在判定框3210中，检查是否存在额外的属性；如果是，循环回到步骤3205并重复过程，直到所有属性都已被检查。如果不存在更多的属性，则过程在步骤3211结束，且流程进行到图31中的步骤3107。
[0420] 现在考虑图37，源虚拟机描述符3751包括值分别为A、B、C和D的参数1-4。目标虚拟机描述符3753包括值分别为X、Y和Z的参数1-3。如3755所示，步骤3206中的逻辑针对源和目标描述符中的每个参数即参数1-4被应用。在步骤3206中，目标参数起决定作用，除非需要源参数来保持功能或兼容性。于是，默认地，所有目标参数被保留在更新的目标虚拟机描述符3757中，但只有需要的源参数才被保留。在图37的例子中，参数1、3和4的源参数值是必要的，而参数2的“Y”的目标值被默认保留，因为不需要该源参数来保持身份或功能。需要注意，假设目标参数都是兼容的，因为它们是现有虚拟机的初始值，该虚拟机被认为工作，并且被管理程序/管理层适当地知道。
[0421] 于是，一个或多个实施例提供了一种支持用与另一虚拟机或映像关联的盘来替换与虚拟机关联的盘的能力的系统和方法；一种确定虚拟机配置及其盘的兼容性的方法；以及/或者一种确保产生的虚拟机在盘被替换后继续工作的方法。
[0422] 现在参考图33的系统图，一个或多个实施例考虑不在托管云中的现有物理或虚拟服务器3301；相反，服务器3301位于现有源环境3350中。服务器3301具有现有的盘3351。如3302所示，服务器3301被转换为映像3352。该管理程序兼容的映像然后被传输到目标云
3354。在云采用过程3303中，执行云提供的映像与客户映像的合并和替换。在某些情形下，可以由迁移工程师3353来促进该过程。云不会注意到对在其控制下运行的虚拟机（这里是编号为3365的VM7）的任何重要更改，如3304所示。
3354。在云采用过程3303中，执行云提供的映像与客户映像的合并和替换。在某些情形下，可以由迁移工程师3353来促进该过程。云不会注意到对在其控制下运行的虚拟机（这里是编号为3365的VM7）的任何重要更改，如3304所示。
[0423] 目标云3354包括管理层3355（在至少某些情形下，它与如上所述的层64类似）。云用户3367与管理层3355交互。管理层3355管理包含一个或多个管理程序例如3356、3357、3358的云环境3354的硬件和软件。管理程序转而管理一个或多个虚拟机3366；在图33的例子中，编号为3356的管理程序1管理编号为3359-3361的VM1-3；编号为3357的管理程序2管理编号为3362的VM4；并且编号为3358的管理程序3管理编号为3363-3365的VM5-7。
[0424] 于是，一个或多个实施例提供了一种允许非云供应的映像被云采用并且和任何其他云供应的实例一样对待的方法；一种定义如何将现有物理或虚拟服务器移动到云中而不需要正式支持的过程；一种支持合并虚拟机描述符以及/或用源映像盘来替换目标映像盘的系统；以及/或一种合并虚拟资源描述符的方法。该后一方法可以包括例如从源和目标映像取回虚拟资源描述符；比较每个虚拟资源描述符的属性；以及/或将两个描述符合并为第三描述符，其和目标虚拟机配置、目标管理程序、目标虚拟机操作系统和目标云兼容。
[0425] 一个或多个实施例由此提供了用与源虚拟机关联的一块或多块盘来替换与目标虚拟机关联的相同数量的虚拟盘的能力。该能力能够将虚拟机或虚拟机映像迁移到现有虚拟机定义中。例如，这在云或托管云的场景下是相关的，在这样的场景中，在更高级别上管理虚拟机的身份和特征（即，以便跟踪容量、许可等）。如果身份改变，管理层将失去对系统的跟踪。另一场景通过允许由先前捕获的虚拟盘的集合替换虚拟机的当前盘集合，来允许将虚拟机恢复到先前的状态。另一种可能性允许通过简单地替换虚拟盘内容而不是每次创建全新的容器来重用虚拟机“容器”。
[0426] 给定到目前为止的讨论，可以理解，一般而言，根据本发明的方面的示例性方法包括步骤3106，其将描述和目标虚拟化环境中的现有目标虚拟机2903、3005关联的至少一块虚拟盘2910、2912、3009的至少一个目标虚拟盘描述符3007、3113与描述和源关联的至少一块虚拟盘3352的至少一块源虚拟盘描述符3006、3112进行合并。执行该合并，以获得至少一个合并的虚拟盘描述符（也用3007来表示；即元素3007表示合并之前以及合并之后的描述符，在该合并时刻它具有某些源参数）。至少一个合并的虚拟盘描述符与目标虚拟化环境兼容。在某些情形下，可以使用如下结合图39所述的在至少一个硬件处理器上执行的交换模块3901的“MergeDiskMetaData”（合并盘元数据）子模块3913来执行步骤3106。另一步骤3108包括根据合并的多个虚拟资源描述符用和源关联的至少一块虚拟盘来替换和目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘。在某些情形下，可以使用如下结合图39所述的在至少一个硬件处理器上执行的交换模块3901的“PutDisk”（放置盘）子模块
3915来执行步骤3108。
3915来执行步骤3108。
[0427] 此外，就此而言，在图39中，注意交换模块3901。准备子模块3902确保源和目标VM处于其中它们可以被操作的状态（映像对实例）。分别针对源和目标通过prepSource（准备源）子模块3902和prepTarget（准备目标）子模块3905来执行任何所需的准备。CheckCompatibility（检查兼容性）子模块3907确保源和目标是兼容的。SwapDisk（交换盘）子模块3909和replaceDisk（替换盘）子模块3911包括控制逻辑来通过分配给子模块3913和
3915的任务来实现图31中的循环；即步骤3106和3108。
3915的任务来实现图31中的循环；即步骤3106和3108。
[0428] TransformDisk（变换盘）子模块3917解决了源和目标规范不匹配的问题；它变换实际的虚拟盘以使其不可区分。一个例子是源和目标虚拟盘大小不同。这典型地将不会影响管理程序，但可导致未来操作例如“扩展盘”的问题。updateVMSpec（更新VM规范）子模块3919执行与图36类型的配置相关的操作步骤3110。管理程序适配模块3930在管理程序
3932、3933、3934所暴露给API3931的每个函数中进行合并；即，复制文件、移动文件、获取描述符和更新描述符的能力。与3933、3944相关的省略号是指3932中说明的“操作执行”。
3932、3933、3934所暴露给API3931的每个函数中进行合并；即，复制文件、移动文件、获取描述符和更新描述符的能力。与3933、3944相关的省略号是指3932中说明的“操作执行”。
[0429] 此外关于准备框3902，参考图38。准备功能获取并访问源映像3802、源物理机3804或源虚拟机3806，并将它们带入可以执行替换操作的状态。源映像3802可以在管理程序下被简单地部署到VM，如3812所示。源物理机3804可以在没有管理程序的情形下被转换为VM，如3808所示，或在有管理程序的情形下被转换为VM，如3810所示。源VM3806也可以被转换为VM，如在3810处一样。在每种情形下，流程根据情况进行到3814的目标VM盘替换。
[0430] 图38和39中的模块/子模块可以用多种语言来编写。Perl是非限制的例子。
[0431] 在某些情形下，目标虚拟化环境是目标云环境。一个或多个实施例被认为对于云特别有用，因为云对于身份改变很敏感。
[0432] 一个或多个实施例由此执行虚拟盘的替换，其由关于这些虚拟盘的元数据的合并所支持。
[0433] 在某些情形下，源是目标云环境外部的客户源，并且替换包括将与源关联的至少一块盘迁移到与现有目标虚拟机关联的至少一块盘，例如如图33所示。
[0434] 在至少某些实施例中，额外的步骤3103包括将和现有目标虚拟机关联的至少一块盘的虚拟资源与和目标云环境之外的客户源关联的至少一块盘进行比较。在该情形下，响应于如判定块3104的“是”分支所示的虚拟资源的比较表明其兼容性而进行合并。
[0435] 在至少某些实施例中，额外的步骤3107包括检查合并步骤的成功。在这样的情形下，响应于如判定块3107的“是”分支所示检查表明合并步骤成功而进行替换。
[0436] 针对判定块3104中的判定，一个或多个实施例利用数据仓库3199，其跟踪已知的兼容性。这些兼容性例如将在源和目标之间比较IO适配器等，以确定源操作系统是否能够与目标适配器（如果不同）一起工作。在某些实施例中，还进行检查，以确保盘数量匹配（即，可能无法将具有两块盘的源合并到具有一块盘的目标中）。总体上，数据库3199的内容例如可以从与虚拟机/映像中包含的操作系统和软件两者关联的技术限制以及管理程序级别的任何兼容性问题（即，最大盘大小、最大盘数量、等）来挖掘。
[0437] 类似的方法可被用于开发数据存储（在图中忽略以避免混乱），框3107中的判定可以基于该数据存储。
[0438] 如判定块3109所示，在某些情形下，针对一块和多块额外的源虚拟盘来重复合并和替换步骤。该整体流程可以在与源映像/虚拟机关联的每块虚拟盘上运行。判定块3104的检查是在进行更改之前的可行/不可行。3106、3108过程是盘元数据的实际更新和盘替换。
[0439] 在至少某些情形下，额外的步骤3110包括更新总体实例描述符。再一次地，步骤3110是可选的并且依赖于正在被操作的VM是否使用图35或图36的方法。
[0440] 在某些情形下，如3205所示，合并步骤3106包括检查与至少一个源虚拟盘描述符关联的至少一个源属性并检查与至少一个目标虚拟盘描述符关联的至少一个目标属性。另一步骤3206包括将多个合并规则2912应用到至少一个源属性和至少一个目标属性，以获得至少一个合并的虚拟盘描述符。合并规则在至少一个合并的虚拟盘描述符中持久化确保虚拟机在目标云中继续运行所需的源属性以及目标云成功采用虚拟机所需的目标属性。此外，就此而言，在一个或多个实施例中，存在用于源、合并之前的目标以及合并之后的目标的描述符。源和目标合并以创建更新的目标。目标虚拟机继续正常运行，就像被替换到其中的虚拟盘的运行时一样。
[0441] 在应用步骤3206中使用的合并规则的非限制的例子包括持久化与源关联的至少一块虚拟盘的虚拟盘输入-输出控制器；持久化与源关联的至少一块虚拟盘的块大小和块数量；以及持久化与现有目标虚拟机关联的至少一块虚拟盘的虚拟盘唯一标识符。
[0442] 在某些情形下，源盘映像已经可用。同时，如上所讨论的，目标云的替换可以从任一源状态(1)-(4)发生，并且在最一般的情形下，源可以但不必是“映像”格式。在某些情形下，如3302所示，额外的步骤包括转换源实例以获得源盘映像3352。
[0443] 在至少某些情形下，目标虚拟机2903、3005具有目标虚拟机配置；目标虚拟机2903、3005被容纳在目标管理程序2904、3001上（作为其来宾）；并且目标虚拟机2903、3005可选地具有目标操作系统。在合并步骤3106中，与目标虚拟化环境的兼容性至少包括与目标虚拟机配置和目标管理程序的兼容性。可选地，与目标虚拟化环境的兼容性还包括与目标操作系统的兼容性。
[0444] 针对在某些情形下没有操作系统的目标虚拟机，一个例子是PXE启动系统或从CD/DVD启动的系统；所述系统可以替换其所有盘而不影响“操作系统”。
[0445] 除了迁移应用，在某些情形下，源2901是备份源；并且替换包括使用与备份源关联的至少一个盘映像来恢复与现有目标虚拟机关联的至少一块盘（例如2910或2912）。
[0446] 如在其他地方所述的，在一个或多个实施例中，没有对VM2903、3005、3365的功能和身份进行更改，并且/或该过程对于父管理程序3358和云管理3355来说不可检测。需要注意，管理程序典型地具有虚拟机的唯一标识符的概念，该唯一标识符在虚拟化环境中不重复。技术人员将从例如VMware和KVM（即基于内核的虚拟机，一种用于包含虚拟化扩展的x86硬件上的Linux的完全虚拟化解决方案）熟悉唯一标识符的概念。VMware虚拟机UUID（由虚拟机描述符文件—a.vmx中称为uuid.bios的字段来支持）是唯一标识符的非限制的例子。在一个或多个实施例中，管理程序或管理栈中存储的任何类型的唯一标识符或相关数据保持一致和不变。被替换的目标盘的操作/行为等同于具有源盘的原始运行时的操作/行为。
由此，在某些情形下，在用与源关联的至少一块虚拟盘来替换与目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘时，在替换之前和之后保持现有目标虚拟机的唯一标识符。
由此，在某些情形下，在用与源关联的至少一块虚拟盘来替换与目标虚拟化环境中的现有目标虚拟机关联的至少一块虚拟盘时，在替换之前和之后保持现有目标虚拟机的唯一标识符。
[0447] 在另一方面，装置包括存储器（例如RAM30、高速缓存32）；以及至少一个处理器16，其耦合到存储器，并操作地执行或以其他方式促进上述方法步骤中的一个、某些或全部。可选地，装置还包括多个单独的软件模块42。每个单独的软件模块在计算机可读存储介质上实现，并且单独的软件模块包括MergeDiskMetaData模块和PutDisk模块；如本文别的地方所讨论的。
[0448] 对托管基础架构即服务云标准的调整
[0449] 硬件基础架构即服务云（HIaaS云）提供了基本虚拟机作为服务。它还可以提供操作系统和应用。但是，典型地不会为虚拟机（VM）上安装的任何软件提供支持。非限制的例子是可从美国华盛顿州西雅图的亚马逊网络服务有限公司获得的亚马逊弹性计算云（Amazon EC2）。托管基础架构即服务云（MIaaS云）提供了全服务虚拟机。服务合同包括为底层的虚拟机提供软件服务。这些服务包括用于所提供的软件基础架构的软件升级、补丁支持、对合规的支持、许可管理等。非限制的例子是可从美国纽约州Armonk的国际商业机器公司获得的IBM SmartCloud En-terprise+（也被称为IBM SCE+）云环境。基于映像的迁移使用客户映像，用于将应用迁移到云中。该过程最小化了昂贵的应用重新安装。云标准是客户映像在云中运行和管理需要满足的需求的最小集合。
[0450] 一个或多个实施例有利地提供了一种系统和方法，用于对MIaaS云标准进行快速、可靠且降低成本的调整。一个或多个实施例获取任意的客户实例并执行一组更改，从而MIaaS管理层可以管理客户应用，完全像它管理从其自己的黄金正式版（golden master）（从中大规模产生副本的参考模型）创建的应用那样。一个或多个实施例提供了一种过程，该过程是快速的（标准的端到端标准化期间很小（例如<4小时））；表现了降低的成本（迁移工程师花费的时间量很小（例如<30分钟）；并且可靠（来自该过程的映像是标准的，具有高可靠性并满足所有客户偏好）。此外，一个或多个实施例提供了两个步骤的过程，其中，客户和云工程师制定灵活的符合客户偏好和云标准的标准化计划，并且其中，自动化框架根据规则以可靠的方式来执行计划。
[0451] 在一个或多个实施例中，规则可被用于对各种类型映像的调整方法进行统一编码；映像调整被用于标准；并且/或者一般的协调框架被用于处理多种类型的调整动作。
[0452] 目前，针对标准化到MIaaS环境的迁移的尝试，需要注意，MIaaS交付模型依赖于具有满足所有服务要求的预制的虚拟机映像。目前，用于基于映像的迁移的标准化是手动的，并忍受耗时、昂贵和不可靠的问题。目前的技术是耗时的，因为需要大量的长时间运行步骤。目前的技术是昂贵的，因为所有步骤都是手动执行的。此外，目前的技术不可靠；此外，就此而言，由于源实例不同，迁移工程师需要手动识别将在每个源实例上执行的合适的步骤集合。结果是必须的步骤可能被漏掉；不想要的步骤可能被执行并破坏实例；并且/或者很多决策不是技术的，并且需要和客户进行协商。即，迁移工程师可能不适合即时做决定。
[0453] 一个或多个实施例有利地提供了快速的标准化方法。一个或多个实施例定义了一般框架，如图40所示，其中，可以注入标准化计划。注意调整框架4002；支持工具4004，其包括单独的工具4020、4022、4024；以及调整区域4006。调整计划4018可以包含多种调整动作。每种类型的调整动态由其协调器4012、4014、4016来协调；协调器在调整指导器（choreographer）4008的控制下操作。新的动作可被加到现有的计划，从而允许计划可扩展。调整动作还可以包括离线调整，这不需要实例在运行。
[0454] 可以在调整计划4018中注册新的协调器4012、4014、4016和动作（例如，使用合适的计划管理器4010）。每个协调器4012、4014、4016可以与虚拟机4030、4032、4034（在线）、映像库4028（离线）、虚拟化管理器4026、或者任何其他支持工具（例如，可以从美国纽约Armonk的国际商业机器公司获得的IBM Endpoint Manager（TEM）服务器、IBM Tivoli Provisioning Manager；可以从美国加州Palo Alto的VMware公司获得的VMware vCloud Director）进行交互。
[0455] 一个或多个实施例提供了一种利用离线调整的快速标准化系统和方法。离线调整是可被应用于虚拟机映像的文件系统补丁。调整将对映像进行更改，以满足云标准（例如，按照安全外壳（SSH）服务）。离线调整可被并行应用，并且不会耗尽所有计算资源，由此能够进行快速调整。离线调整包括不需要激活VM的简单的文件系统复制或其他操作。这比安装/配置步骤的实际执行花费少得多的时间（再一次地，使得能够进行快速调整）。离线调整可被应用，而不用启动映像并且不需要到映像的网络访问。这有利地解决了鸡和蛋的问题，其中，访问云中的VM需要配置（由此移除了手动步骤）。
[0456] 图41的流程图示出了样本离线调整的流程。流程图开始于4102。在判定框4014中，例如确定是否存在cygwin/ssh服务。在这方面，Cygwin是用于微软Windows的类似Unix的环境和命令行接口。Cygwin提供基于Windows的应用、数据和其他系统资源与类似Unix环境的应用、软件工具和数据的本机集成。由此有可能从Cygwin环境启动Windows应用，以及在Windows操作上下文中使用Cygwin工具和应用。
[0457] 在该例子中，如框4104的“是”分支所示，如果cygwin/ssh服务已经存在，不要进一步的处理，从而转到结束和4106。另一方面，如果cygwin/ssh服务还不存在，如框4014的“否”分支所示，在步骤4108中，关闭虚拟机并安装虚拟机。在步骤4110中，将cygwin清单（manifest）复制到映像上。在步骤4112中，将需要的公开密钥复制到映像上。在步骤4114中，更新注册表以在实例的第一次启动时运行脚本。在步骤4116中，卸载虚拟机并启动虚拟机。在步骤4118中，启用ssh服务的脚本现在自动执行；转到结束步骤4106。需要强调，图41仅是展示在一个或多个实施例中可如何执行离线调整的一个特定的详细示例。此外，就此而言，正如指出的，离线调整是可被用于虚拟机映像的文件系统补丁；实现cygwin/ssh服务由此是可以在一个或多个实施例中执行的多种离线调整的非限制的特定例子。
[0458] 现在参考图42和43。一个或多个实施例通过自动化调整引擎4302来提供降低成本的标准化。一个或多个实施例包括调整协调器4304和/或4310。协调器4304和/或4310定义了一组阶段，其中，依赖的阶段仅在其之前的所有阶段都已经执行之后才会执行。每个阶段中的步骤被封装为脚本。脚本可以在调整引擎4302上、在目标虚拟机上或者在任何其他管理工具（例如，与vCenter（VMware vCenter Server提供了用于管理虚拟基础架构的集中和可扩展的平台，并且可以从美国加州Palo Alto的VMware公司获得）或TEM集成）上运行。在一个或多个实施例中，为所有类型的映像（例如，Windows、Linux、AIX）提供单个用户接口4302。此外，就此而言，在示例性实施例中，元素4302是调整门户和主指导器4008，其决定单独的协调器4012、4014、4016将被调用的顺序。调整引擎是所有组件的总和。门户是元素
4302中的可选实体，因为可以使用可编程API来直接调用指导器。总之，在非限制的例子中，元素4302等同于指导器加上可选的门户。在一个或多个实施例中，多个映像可被并行调整（这降低了每个被标准化的映像所花费的时间量）。
4302中的可选实体，因为可以使用可编程API来直接调用指导器。总之，在非限制的例子中，元素4302等同于指导器加上可选的门户。在一个或多个实施例中，多个映像可被并行调整（这降低了每个被标准化的映像所花费的时间量）。
[0459] 一个或多个实施例提供了可靠的标准化。一个或多个实施例提供了采用条件和动作的灵活的规则框架。条件提供了处理不同类型的源映像的灵活性。条件和动作具有相关的脚本。在至少某些情形下，这涉及两个步骤的过程。客户准许用于其数据中心的有效规则集，并用所述规则来引导调整指导器4304和/或4310（另见4012-4016）。工具允许迁移工程师根据规则来执行标准化。日志被维护，以在此后的任何时间对标准化过程进行审计。此外，在一个或多个实施例中，使用快照以允许在标准化失败时回滚到映像的可靠版本。在某些实施例中，使用至少两个步骤的过程；但是，在特定情形下，使用多个步骤的过程。客户可以定义一组迁移规则，且迁移工程师可以提供某些规则无法执行的反馈，由此可以存在迭代的往返。
[0460] 下面是可以在上述可靠标准化过程中使用的示例性说明性规则集合：
[0461] ·如果（Cygwin未被安装）则（安装Cygwin）
[0462] ·如果（ITM（可以从美国纽约州Armonk的国际商业机器公司获得的IBM Tivoli Monitoring软件）存在）则（卸载ITM）
[0463] ·如果（真）则（插入ssh密钥）
[0464] ·如果（赛门铁克杀毒软件不存在）则（安装赛门铁克杀毒软件）
[0465] ·如果（密码过期时间=90天）则（设置密码过期时间=180天）
[0466] ·如果（补丁X不存在）则（部署补丁X）（补丁X在这里表示任何需要的补丁；非限制的例子可以是例如微软补丁MS08-067）
[0467] ·如果（TEM代理未被注册）则（注册TEM代理）
[0468] 现在参考图42。在4202，安装导入的映像。在步骤4224，执行访问启用；例如：
[0469] 1.添加用于Windows的Cygwin SSHD（OpenSSH=sshd）；
[0470] 2.添加SSH密钥；
[0471] 3.在第一次启动时对所有网络接口设置IP地址和默认网关；
[0472] 4.设置名称服务器条目；以及
[0473] 5.取快照
[0474] 在任何失败的情形下，如4204所示，修复错误、回滚并重试。一旦所有步骤都成功，不管是在第一次尝试还是后续重试时，如4206所示，启动VM。然后执行代理卸载过程4226；例如：
[0475] 1.卸载TEM代理
[0476] 2.卸载EMC Networker（可以从美国马萨诸塞州Hopkinton的EMC公司获得）[0477] 3.卸载TSM客户端（可以从美国纽约州Armonk的国际商业机器公司获得的IBM Tivoli Storage Manager（TSM）软件）
[0478] 4.卸载TSCM代理（可以从美国纽约州Armonk的国际商业机器公司获得的IBM Tivoli Security Compliance Manager（TSCM）软件）
[0479] 5.卸载TAD4D代理（可以从美国纽约州Armonk的国际商业机器公司获得的IBM Tivoli Asset Discovery for Distributed）
[0480] 6.卸载ITM代理（可以从美国纽约州Armonk的国际商业机器公司获得的IBM Tivoli Monitoring软件）
[0481] 7.取快照
[0482] 在任何失败的情形下，如4208所示，修复错误、回滚并重试。一旦所有步骤都成功，不管是在第一次尝试还是后续的重试时，如4210所示，转到代理安装过程4228；例如：
[0483] 1.安装TEM
[0484] 2.设置域名系统（DNS）缓存手册
[0485] 在任何失败的情形下，如4212所示，修复错误、回滚和重试。一旦所有步骤成功，不管是在第一次尝试还是后续的重试时，如4214所示，转到打补丁过程4230；例如：
[0486] 1.打补丁到基线
[0487] 2.取快照
[0488] 在任何失败的情形下，如4216所示，修复错误、回滚和重试。一旦所有步骤成功，不管是在第一次尝试还是后续的重试时，如4218所示，转到合规过程4232；例如：
[0489] 1.设置最小密码长度
[0490] 2.设置密码历史计数
[0491] 3.设置最大密码时限
[0492] 4.设置最小密码时限
[0493] 5.设置密码复杂度
[0494] 6.取快照
[0495] 在任何失败的情形下，如4220所示，修复错误、回滚和重试。一旦所有步骤成功，不管是在第一次尝试还是后续的重试时，如4222所示，转到装载过程。
[0496] 图43示出了示例性标准化架构。所包含的是调整引擎4302（其可作为图形用户界面或GUI或一组API被提供给主指导器）；以及分别是在线和离线调整协调器4304、4310（两者都是组件的形式）。其他组件包括调整数据库4306、调整计划维护模块4308、访问管理器4312、合规管理器4316、备份管理器4318、脚本执行管理器4320和补丁管理器4322。引擎
4302调用在线和离线调整协调器3404、4310。这些转而查询调整数据库4306，这是使用调整计划维护模块4308来维护的。迁移组和客户协商使用调整计划维护组件来事先创建调整计划。计划包括引导调整过程的所有规则。
4302调用在线和离线调整协调器3404、4310。这些转而查询调整数据库4306，这是使用调整计划维护模块4308来维护的。迁移组和客户协商使用调整计划维护组件来事先创建调整计划。计划包括引导调整过程的所有规则。
[0497] 离线调整协调器4310使用访问管理器4312来提供所需的访问和接口。
[0498] 在线调整协调器4304调用合规管理器4316、备份管理器4318和脚本执行管理器4320。合规管理器4316也调用脚本执行管理器4320。在线调整协调器4304使用补丁管理器
4322。
4322。
[0499] 现在应关注图44-46，其示出了调整阶段中的示例性详细步骤。每个步骤在“泳道”中示出，泳道表示在示例性实施例中什么模块或实例执行特定的步骤。请注意图44所示的过程不需要但为了说明的目的而包含元素4402、4408（云门户）和4410。迁移组4404捕获迁移组执行的所有活动。这包括通过使用调整GUI或调用调整API以及手动步骤来检查成功或失败而执行的活动。测试和故障排除VM步骤4432、4442表示图44的例子中的手动过程。剩余步骤典型地是自动的并且涉及在门户上点击按钮或调用API。实体包括TSAM（可以从美国纽约州Armonk的国际商业机器公司获得的IBM Service Automation Manager软件）管理员4402、迁移组4404、VMware vSphere虚拟化管理器4406、门户4408、TSAM4410和备份库4412。处理开始于4420。在步骤4422，执行冒烟测试（即，在更改检入到产品的源树（source tree）之前验证代码更改的过程）。在步骤4424中，备份所讨论的VM；在步骤4426中，将VM检入到备份库中。在步骤4428中，管理程序提供VM。在步骤4430中，配置VM。步骤4430与图42中的步骤4224类似。在步骤4432中，对VM进行测试和故障排查。在步骤4434中，备份已被配置和测试的VM；在步骤4436中，将VM检入到备份库中。在步骤4428中，管理程序提供已被配置和测试的VM；在步骤4440中，移除不合适的软件和/或代理。步骤4440与图42中的步骤4226类似。在步骤4442中，对移除了不合适的软件和/或代理的更新的VM进行测试和故障排查。处理在4444继续。
[0500] 在图45中，处理开始于点4446（其等同于点4444）。在步骤4448中，对移除了不合适的软件和/或代理的更新的VM进行备份；在步骤4450，将VM检入到备份库。在步骤4452中，管理程序提供移除了不合适的软件和/或代理的更新的VM；在步骤4454中，安装合适的代理。步骤4454类似于图42中的步骤4228。在步骤4456中，对安装了合适代理的更新的VM进行测试和故障排查。在步骤4458中，对安装了合适代理的更新的VM进行备份；在步骤4460,中，将VM检入到备份库。在步骤4462，管理程序提供安装了合适代理的更新的VM；在步骤4464中安装补丁。步骤4464类似于图42中的步骤4230。
[0501] 在步骤4466中，对安装了补丁的更新的VM进行测试和故障排查。在判定框4468中，确定测试是否成功；如果是，在4470，转到图46的流程；如果不是，在4472，修复错误、回滚并重试，如图42的4216所示。在图46中，处理开始于点4474（其等同于点4470）。在步骤4476中，对安装了补丁的更新的VM进行备份；在步骤4478中，将VM检入到备份库中。在步骤4480中，管理程序提供安装了补丁的更新的VM；在步骤4482中确保合规。步骤4482类似于图42中的步骤4232。在步骤4484中，对合规检查之后的VM进行测试和故障排查。在判定块4486，确定测试是否成功；如果是，在4488，转到装载；如果不是，在4490，修复错误、回滚并重试，如图42的4220所示。一般来说，在错误的情况下，回滚到流程中的任何备份步骤是可能的。
[0502] 图47示出了示例性架构，以帮助技术人员理解相关上下文中的示例性系统。进行一次或多次调整4702以标准化任意客户实例。在尝试调整之前，优选地在合适的映像库例如IBM Tivoli映像库4718中放置快照。这例如可以使用IBM Tivoli映像库在端口9443上使用超文本传输协议（HTTP）来执行。可以参考范围数据库4704以访问关于VM和应用的数据，并确定VM的状态。这例如可以使用Java数据库连接（JDBC）来执行。要调整的映像被安装在网络文件系统（NFS）存储4706中。任何需要的VM动作由云vCenter4710来执行，并由vCenter驱动器4712来控制；这导致云4708中的VM的创建和/或修改，所述VM转而被安装在NFS存储4706中。
[0503] IBM Endpoint Manager（TEM）服务器4716可被用于迁移的目的；例如可以通过传输控制协议（tcp）来与该服务器进行通信。TEM控制对云托管环境4714的VM补丁，调整的VM位于该环境中；可以通过http或用户报文协议（udp）来通信。TEM4716通过http在端口80上与因特网4720进行通信。
[0504] 一个或多个实施例由此提供一种调整映像的系统和方法，从而它们满足托管环境4714的映像标准并且可以使用标准过程和工具来管理。在一个或多个实施例中，这种系统包括一个或多个调整类型协调器4012、4014、4016，其处理特定类型的调整；调整计划4018，其捕获所有调整；以及调整计划维护组件4010。
[0505] 协调器的非限制的例子包括访问启用协调器4224，以确保所有源映像可以被相关管理实体（包括其他协调器）访问；卸载协调器4226，以卸载不想要的软件；安装协调器4228，以安装需要的软件；补丁协调器4230，以确保补丁标准化；以及合规协调器4232，以确保符合一个或多个云标准。例如，不同的实施例可以包括额外的协调器、更少的协调器、或正好刚描述的协调器。
[0506] 托管环境4714可以是例如MIaaS云（例如IBM SCE+）。
[0507] 协调器可以在文件系统虚拟机映像上（例如在映像库4028中）或者在VM实例4030、4032、4034上运行。
[0508] 在某些情形下，每个协调器执行的动作是由规则引擎来确定的。此外，就此而言，规则引擎在图中未显式示出以避免混乱；但是，在一个或多个实施例中，规则评估引擎在每个协调器中隐含地实现，其需要评估每个条件并且仅在条件满足时执行动作。在某些情形下，这种规则引擎包括一组条件-动作对（例如，如果（Cygwin未被安装）则（安装Cygwin）等等，如以上所讨论的）；在这样的情形下，仅在条件满足时才执行动作。在某些情形下，新规则可被注入到规则引擎以扩展工具来处理新类型的客户映像；例如，可以由调整计划维护组件例如计划管理器4010来注入这种规则，该组件允许规则的创建、编辑和/或删除。
[0509] 在至少某些情形下，可以通过更改调整计划4018和/或更改协调器4012-416或4224-632的顺序对整体调整流程进行微调。
[0510] 要点重述
[0511] 给定到目前为止的讨论，可以理解，一般而言，根据本发明的方面的示例性方法包括将任意客户实例（一般来说一个或多个这样的实例）从客户环境传送到目标基础架构即服务云环境（4714；图3）作为（一般来说一个或多个）传送的映像。“传送”应被一般地理解为包含基础架构即服务云环境的提供者的动作和/或客户的动作。该步骤例如可以由传送核心组件（例如目标基础架构即服务云环境中的模块42，其被配置为从客户环境获取任意客户实例）来执行。另一步骤包括制定映像调整计划4018，其捕获呈现符合目标基础架构即服务云环境的标准的传送的映像所需要的至少一个调整。“制定”应被一般地理解为包含仅由机器执行的动作（例如存储人工输入的指令，其对计划进行编码）或者由机器和人工两者执行的动作。该步骤例如可以由调整计划维护组件4010来执行。另一步骤包括执行映像调整计划以调整传送的映像，以获取符合目标基础架构及服务云环境标准的调整的映像。该步骤可以由协调组件例如指导器4008以及一个或多个协调器4012-4016来执行。另一步骤包括将调整的映像装载到基础架构即服务云环境作为其标准映像（一般来说，一个或多个标准映像）。“标准”表示该映像于是以好像其从系统自己的“黄金正式版”产生一样的方式来运行。该步骤例如可以由云管理层64来执行。
[0512] 在某些情形下，传送的映像是在作为基础架构即服务云环境（例如4030、4032、4034）中的实例运行时在线调整的。在这种情形下，执行步骤包括用自动化框架来执行映像调整计划，该框架包括与基础架构即服务云环境中的实例交互的至少一个在线协调器
4304。
4304。
[0513] 在某些情形下，传送的映像在基础架构即服务云环境的文件系统4028中离线调整。在这种情形下，执行步骤包括用自动化框架来执行映像调整计划，该框架包括与基础架构即服务云环境的文件系统中的传送的映像交互4310的至少一个离线协调器。
[0514] 在某些情形下，执行步骤包括用自动化框架来执行映像调整计划，该框架包括与基础架构即服务云环境的虚拟化管理器4026（和/或支持工具4004）交互的至少一个协调器。
[0515] 在至少某些实施例中，基础架构即服务云环境包括具有管理层64的托管基础架构即服务云环境。在这种情形下，在至少某些实例中，另一步骤包括用管理层和从托管基础架构即服务云环境应用黄金正式版创建的至少一个应用（即从和托管基础架构及服务云环境关联的黄金正式版创建的应用；并不表示它在某种程度上是整个云环境的黄金正式版）一起来管理标准映像。
[0516] 在某些实施例中，用自动化框架来执行映像调整计划，该自动化框架包括至少一个访问启用协调器4224，其确保调整的映像可被目标基础架构即服务云环境的管理层访问；代理卸载协调器4226，其从传送的映像卸载不想要的软件；代理安装协调器4228，其将需要的软件安装到传送的映像；补丁协调器4230，其确保调整的映像上已安装目标基础架构即服务云环境的标准所需的补丁；以及合规协调器4232，其确保调整的映像符合目标基础架构即服务云环境的标准。
[0517] 在某些情形下，执行步骤包括，通过以下方式用自动化框架来执行映像调整计划：使用访问启用协调器4224以确保调整的映像可被目标基础架构即服务云环境的管理层访问；使用代理卸载协调器4226从传送的映像卸载不想要的软件；使用代理安装协调器4228将需要的软件安装到传送的映像；使用补丁协调器4230来确保调整的映像上已安装目标基础架构即服务云环境的标准所需的补丁；以及使用合规协调器4232来确保调整的映像符合目标基础架构即服务云环境的标准。
[0518] 在某些情形下，调整计划4018包括对不同类型的映像的调整方法进行统一编码的规则。优选地但是可选地，协调框架是通用的并且可以处理多种类型的调整动作。在至少某些情形下，调整协调器定义了一组阶段，每个阶段中的步骤被封装在脚本中。这种脚本可以在调整引擎中运行并且可针对VM4030-4034、管理工具4020-4024等。某些技术并行地调整多个映像。在某些情形下，调整协调器是用规则来引导的。协调器的动作是由规则引擎（一组条件/动作对）来确定的；可以由调整计划维护组件4010来注入新的规则。可以通过更改计划和/或更改协调器顺序来更改调整流程。可以通过将新的动作和/或协调器添加和/或注册到现有计划来扩展该框架。
[0519] 在另一方面，示例性装置包括存储器（例如RAM28、高速缓存32）；至少一个处理器16，其耦合到存储器；以及非易失性计算机可读存储介质34，其以非易失的方式实现多个单独的软件模块42。多个单独的软件模块转而包括调整计划维护组件模块4010，其包含的指令在被载入到存储器时，将至少一个处理器配置为制定映像调整计划4018，该计划捕获呈现符合目标基础架构即服务云环境标准的传送的映像所需的至少一个调整。传送的映像包括来自客户环境的任意客户实例。还包括调整协调模块（例如4008和4012-4016），其包含的指令在被载入到存储器时，将至少一个处理器配置为执行映像调整计划来调整传送的映像，以获得符合目标基础架构即服务云环境的调整映像；以及云管理模块64，其包含的指令在被载入到存储器时，将至少一个处理器配置为将调整的映像装载到基础架构即服务云环境作为其标准映像。
[0520] 在某些情形下，调整协调模块包含指令，在被载入到存储器时，所述指令将至少一个处理器配置为在作为如4030-4034所示的基础架构即服务云环境中的实例运行时在线调整传送的映像。在某些情形下，调整协调模块包含指令，在被载入到存储器时，所述指令将至少一个处理器配置为在基础架构即服务云环境的文件系统4028中离线调整传送的映像。
[0521] 在某些实施例中，调整协调模块包括指令，在被载入到存储器时，所述指令将至少一个处理器配置为与基础架构即服务云环境的虚拟化管理器4026交互。在某些实施例中，调整协调模块包含指令，在被载入到存储器时，所述指令将至少一个处理器配置为与基础架构即服务云环境的支持工具4020-4024交互。
[0522] 在至少某些情形下，基础架构即服务云环境包括具有管理层64的托管基础架构即服务云环境4714。管理层例如可以和从托管基础架构即服务云环境应用黄金正式版创建的至少一个应用一起来管理标准映像。
[0523] 在某些实施例中，调整协调模块包括调整指导器4008和下列中的至少一个：访问启用协调器4224，其确保调整的映像可被目标基础架构即服务云环境的管理层访问；代理卸载协调器4226，其从传送的映像卸载不想要的软件；代理安装协调器4228，其将需要的软件安装到传送的映像；补丁协调器4230，其确保调整的映像已在其上安装目标基础架构即服务云环境的标准所需的补丁；以及合规协调器4232，其确保调整的映像符合基础架构即服务云环境的标准。
[0524] 在某些情形下，调整协调模块包括调整指导器4008；访问启用协调器4224，其确保调整的映像可被目标基础架构即服务云环境的管理层访问；代理卸载协调器4226，其从传送的映像卸载不想要的软件；代理安装协调器4228，其将需要的软件安装到传送的映像；补丁协调器4230，其确保调整的映像上已安装目标基础架构即服务云环境的标准所需的补丁；以及合规协调器4232，其确保调整的映像符合目标基础架构即服务云环境的标准。
[0525] 示例性系统和制造品的细节
[0526] 所属技术领域的技术人员知道，本发明可以实现为系统、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：可以是完全的硬件、也可以是完全的软件（包括固件、驻留软件、微代码等），还可以是硬件和软件结合的形式，本文一般称为“电路”、“模块”或“系统”。而且，本发明还可以实现为在一个或多个计算机可读介质中的计算机程序产品的形式，该计算机可读介质中包含计算机可读的程序代码。
[0527] 本发明的一个或多个实施例或其组件可被实施为包括存储器和耦合到存储器且可操作以执行示例性方法步骤的至少一个处理器的装置。
[0528] 一个或多个实施例可利用运行在通用计算机或工作站上的软件。参考图1，这样的实施可利用例如处理器16、存储器28、以及到显示器24和外部装置14（诸如键盘、指点装置等）的输入/输出接口22。术语“处理器”在此被使用时旨在包括任何处理装置，诸如例如包括CPU（中央处理单元）和/或其他形式的处理电路的装置。而且，术语“处理器”可指多于一个的单个处理器。术语“存储器”旨在包括与处理器或CPU关联的存储器，诸如例如RAM（随机存取存储器）30、ROM（只读存储器）、固定存储器装置（例如硬驱动器34）、可移动存储装置（例如软盘）、闪存存储器等。此外，短语“输入/输出接口”在此被使用时旨在包括到以下装置的接口，例如用于将数据输入到处理单元的一个或多个装制（例如鼠标），以及提供与处理单元有关的结果的一个或多个装置（例如打印机）。处理器16、存储器28和输入/输出接口22可被互连，例如经由作为数据处理单元12的一部分的总线18。例如经由总线18的合适的互连包括也可被提供给网络接口20，诸如网卡，其可被提供以与计算机网络相接口，以及到介质接口，诸如软盘或CD-ROM驱动器，其可被提供以与合适的介质相接口。
[0529] 因此，如在此描述的，包括指令或代码以执行本发明的方法的计算机软件可被存储在一个或多个相关的存储装置（例如ROM、固定或可移动存储器）中，以及当准备被利用时，被部分或全部加载（例如到RAM）以及被CPU实施。这样的软件可包括但不限于固件、驻留软件、微代码等。
[0530] 适用于存储和/或执行程序代码的数据处理系统将包括通过系统总线18直接或间接耦合到存储元件28的至少一个处理器16。存储元件可包括在程序代码的实际实施期间使用的本地存储器、大容量存储器和高速缓存存储器32，其提供至少一些程序代码的临时存储以便降低在实施期间代码必须从大容量存储器中被检索的次数。
[0531] 输入/输出或I/O装置（包括但不限于键盘、显示器、指点装置等）可直接或通过介于其间的I/O控制器而耦合到系统。
[0532] 网络适配器20也可被耦合到系统以使得数据处理系统通过介于其间的私有或公共网络变得与其他数据处理系统或远程打印机或存储装置耦合。调制解调器、网络调制解调器和以太网卡仅是当前可用的网络适配器的若干类型。
[0533] 如在此包括权利要求书中使用的，“服务器”包括运行服务器程序的物理数据处理系统（例如图1示出的系统12）。将理解，这样的物理服务器可以包括或不包括显示器和键盘。
[0534] 如所注意的，本发明的方面可采取实施在一个或多个计算机可读介质上的计算机程序产品的形式，其上实施有计算机可读程序代码。一个或多个计算机可读介质的任何组合可被使用。计算机可读介质可以是计算机可读信号介质，或计算机可读存储介质。计算机可读存储介质可以是例如但不限于电的、磁的、光的、电磁的、红外的或半导体系统、装置或设备，或前述装置的任何合适组合。计算机可读存储介质的更具体的例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式计算机软盘、硬盘、随机存取存储器（RAM）、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任何合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
[0535] 计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任何合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
[0536] 计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任何合适的组合。
[0537] 可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如”C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任何种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机（例如利用因特网服务提供商来通过因特网连接）。但是一个或多个实施例在云或虚拟机环境的上下文中是特别显著的。可参考图1-3和相应文字。
[0538] 参考根据本发明实施例的流程描述和/或方法、装置（系统）的框图以及计算机程序产品描述了本发明的方面。将理解流程图和/或框图中的每个框以及流程图和/或框图中的框的组合，可被计算机程序指令实施。这些计算机程序指令可被提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器以产生机器，这样经由计算机或其他可编程数据处理装置的处理器执行的指令创建用于实施在流程图和/或框图的一个或多个框中指定的功能/动作的装置。
[0539] 这些计算机程序指令也可被存储在计算机可读介质中，其可指示计算机、其他可编程数据处理装置或其他装置以特定方式起作用，这样存储在计算机刻度介质中的指令产生制造品，其包括用于实施在流程图和/或框图的一个或多个框中执行的功能/行为的指令。
[0540] 计算机程序指令也可被加载到计算机、其他可编程数据处理装置或其他装置上，使得一系列可操作步骤在计算机、其他可编程装置或其他装置上产生计算机实施的过程，这样在计算机或其他可编程装置上执行的指令提供用于实施流程图和/或框图中的一个或多个框中执行的功能/行为的过程。
[0541] 附图中的流程图和框图示出了根据本发明的各个实施例的系统、方法和计算机程序产品的可能实施的结构、功能和操作。就这点而言，流程图或框图中的每个框可表示模块、段或代码的一部分，其包括一个或多个可执行指令用于实施指定的逻辑功能。也应当注意，在一些可替换实施例中，在框中提到的功能可不按图中标出的顺序发生。例如，连续示出的两个框可实际上被基本上同时执行，或框有时候以相反顺序被执行，这取决于涉及的功能。也应当注意框图和/或流程描述中的每个框，以及框图和/或流程描述中的框结合，可被执行指定功能或行为的基于硬件的专用系统或专用硬件和计算机指令的组合实施。
[0542] 需要注意，这里描述的任何方法可以包括额外的步骤，其提供一种包含在计算机可读存储介质上实现的单独的软件模块的系统；所述模块可以包括例如框图中示出和/或这里描述的任何或所有合适的元件；作为示例而不是限制，图3和29-39中的任何一个、某些或全部模块/框以及/或子模块/子框42，例如交换模块3901和管理程序适配模块3930。然后可以使用如上所述在一个或多个硬件处理器例如16上执行的系统的单独的软件模块和/或子模块来执行方法步骤。在权利要求中子模块在某些情形下可被简单地称为模块。此外，计算机程序产品可以包括计算机可读存储介质，其具有的代码适于执行这里描述的一个或多个方法步骤，包括提供具有独立的软件模块的系统。
[0543] 在任何情况下，应当理解在此示出的组件可以各种形式的硬件、软件或其组合实施；例如，专用集成电路（ASICS）、功能电路、具有相关存储器的一个或多个适当编程的通用数字计算机等。考虑到在此提供的本发明的教义，本领域普通技术人员将能设想到本发明的组件的其他实施。
[0544] 在此使用的术语仅是为了描述特定实施例，且不旨在限制本发明。如在此使用的，单数形式“一”、“一个”、“该”也旨在包括复数形式，除非上下文另有清楚说明。将进一步理解术语“包含”和/或“包括”，当用在本说明书中时，指示存在所提到的特点、整数、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其他特点、整数、步骤、操作、元件、组建和/或其组合。
[0545] 权利要求书中的所有装置或步骤加功能元件的对应结构、材料、行为或等价物旨在包括用于与特别要求保护的其他元件执行所述功能的任何结构、材料或行为。为了说明和描述的目的已展示本发明的说明书但不旨在是穷举或将本发明限制在所公开的形式。许多修改和变化对于本领域普通技术人员是明显的，而不脱离本发明的范围和精神。实施例被选择和描述以最好地解释本发明的原理和实际应用，并使得本领域普通技术人员能理解本发明的具有适于所考虑的特定使用的各种修改的各种实施例。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 基于CDN和MEC的车联网移动性管理方法 | 2020-05-08 | 598 |
| 节能调度方法及装置、计算机可存储介质 | 2020-05-12 | 9 |
| 服务器、存储系统及相关方法 | 2020-05-08 | 186 |
| 云中使用专用金属部署的情况下的复制 | 2020-05-08 | 800 |
| 在多云计算环境中迁移工作负载 | 2020-05-08 | 376 |
| 一种虚拟机热迁移的控制方法、控制装置及控制设备 | 2020-05-11 | 192 |
| 一种云数据中心虚拟机的管控方法、系统及设备 | 2020-05-11 | 852 |
| 一种基于VMI的内核数据监控方法及监控系统 | 2020-05-12 | 494 |
| 一种虚拟机迁移方法和装置 | 2020-05-08 | 903 |
| 物理机调度方法及装置、计算机可存储介质 | 2020-05-12 | 20 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
虚拟机迁移热门专利
QQ群二维码
意见反馈
意见反馈