CN110209464A - 虚拟机的纳管方法、存储介质及管理平台 - Google Patents

Abstract

本发明实施例公开了一种虚拟机的纳管方法、存储介质及管理平台，属于计算机技术领域。该方法用于接入有虚拟平台的管理平台中，管理平台包括客户端、虚拟机创建接口和计算组件，包括：客户端生成虚拟机创建请求，虚拟机创建请求中携带有指示虚拟平台创建的虚拟机的元数据；客户端将虚拟机创建请求发送给虚拟机创建接口；虚拟机创建接口接收虚拟机创建请求；虚拟机创建接口在管理平台中注入元数据；根据元数据对应的虚拟机的类型，计算组件对元数据对应的虚拟机执行对应的纳管操作，虚拟机的类型用于指示虚拟机为已创建的虚拟机或待创建的虚拟机。本发明实施例可以扩大管理平台纳管的虚拟机的类型。

Description

虚拟机的纳管方法、存储介质及管理平台

技术领域

本发明实施例涉及计算机技术领域，特别涉及一种虚拟机的纳管方法、存储介质及管理平台。

背景技术

过去用户大多数Vmware vSphere(虚拟化平台，简称Vmware)来创建和管理虚拟机，从而将应用程序和操作系统从底层硬件中分离出来，以简化操作。然而，随着云技术的发展，基于云技术的Openstack(开放堆栈)正被越来越多的用户了解和使用，如何在将Vmware接入Openstack后，利用Openstack纳管Vmware的虚拟机成为了人们关注的热点。

在利用Openstack纳管Vmware的虚拟机时，Openstack只能纳管指示Vmware创建的虚拟机，纳管的虚拟机的类型较少。

发明内容

本发明实施例提供了一种虚拟机的纳管方法、存储介质及管理平台，用于解决Openstack只能纳管待创建的虚拟机，纳管的虚拟机的类型较少的问题。所述技术方案如下：

一方面，提供了一种虚拟机的纳管方法，用于接入有虚拟平台的管理平台中，所述管理平台包括客户端、虚拟机创建接口和计算组件，所述方法包括：

所述客户端生成虚拟机创建请求，所述虚拟机创建请求中携带有指示所述虚拟平台创建的虚拟机的元数据；

所述客户端将所述虚拟机创建请求发送给所述虚拟机创建接口；

所述虚拟机创建接口接收所述虚拟机创建请求；

所述虚拟机创建接口在所述管理平台中注入所述元数据；

根据所述元数据对应的虚拟机的类型，所述计算组件对所述元数据对应的虚拟机执行对应的纳管操作，所述虚拟机的类型用于指示所述虚拟机为已创建的虚拟机或待创建的虚拟机。

一方面，提供了一种管理平台，所述管理平台包括：客户端、虚拟机创建接口和计算组件；

所述客户端，用于生成虚拟机创建请求，所述虚拟机创建请求中携带有指示所述虚拟平台创建的虚拟机的元数据；

所述客户端，还用于将所述虚拟机创建请求发送给所述虚拟机创建接口；

所述虚拟机创建接口，用于接收所述虚拟机创建请求；

所述虚拟机创建接口，还用于在所述管理平台中注入所述元数据；

所述计算组件，用于根据所述元数据对应的虚拟机的类型，对所述元数据对应的虚拟机执行对应的纳管操作，所述虚拟机的类型用于指示所述虚拟机为已创建的虚拟机或待创建的虚拟机。

一方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上所述的虚拟机的纳管方法。

一方面，提供了一种管理平台，所述管理平台包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如上所述的虚拟机的纳管方法。

本发明实施例提供的技术方案的有益效果至少包括：

在获取到携带有元数据的虚拟机创建请求后，可以根据虚拟机的类型纳管已创建的虚拟机和待创建的虚拟机，即，虚拟平台既可以纳管待创建的虚拟机，也可以纳管已创建的虚拟机，解决了管理平台只能待创建的虚拟机，纳管的虚拟机的类型较少的问题，从而扩大了管理平台纳管的虚拟机的类型。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据部分示例性实施例示出的一种虚拟平台系统的结构示意图；

图2是本发明一个实施例提供的虚拟机的纳管方法的方法流程图；

图3是本发明另一实施例提供的虚拟机的纳管方法的方法流程图；

图4是本发明另一实施例提供的虚拟机的纳管方法的方法流程图；

图5是本发明另一实施例提供的各个模块之间的运行顺序的示意图；

图6是本发明另一实施例提供的虚拟机的纳管方法的方法流程图；

图7是本发明一个实施例提供的管理平台的结构框图；

图8是本发明再一实施例提供的服务器的结构框图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

请参考图1，其示出了本发明实施例提供的一种虚拟平台系统的结构示意图。该虚拟平台系统包括虚拟平台110、管理平台120和云自助门户130，且虚拟平台110接入管理平台120。其中，云自助门户130是用户操作管理平台120的操作入口。

虚拟平台110和管理平台120可以通过多台服务器或服务器集群来实现。

在一种应用场景中，虚拟平台是Vmware，管理平台是Openstack。其中，Vmware是Vmware vSphere的简称，Vmware vSphere是业界领先且可靠的虚拟化平台，可以将应用程序和操作系统从底层硬件中分离出来，从而简化了操作。Openstack是一个开源的云计算管理平台，覆盖了网络、虚拟化、操作系统、服务器等各个方面。

以虚拟平台110是Vmware为例，则从结构的角度来说，Vmware至少包括Vcenter(集群管理工具)、Cluster(集群)和Shared Datastore(共享数据库)。其中，Cluster是至少一台ESX(Vmware宿主机)组成的集群，且每台ESX中创建有至少一个虚拟机(图1中未示出)。请参考图1，其示出了Vmware中各组件之间的连接关系，需要说明的是，图1中以Vmware包括3个Cluster，每个Cluster包括3个ESX进行举例说明，在实际实现时，不限定Cluster和ESX的数量。

以管理平台120是Openstack为例，则从结构的角度来说，Openstack至少包括客户端(图中未示出)、Nova(计算)组件、Glance(镜像)组件、Cinder(云硬盘)组件、Neutron(网络)组件、LibvirtDriver(驱动)、VmwareVCDriver(驱动)和KVM(Openstack宿主机)资源池，图1示出了Openstack中各组件之间的连接关系。下面对Openstack中的各个组件进行介绍。

客户端用于将用户的请求转换为HTTP(HyperText Transfer Protocol，超文本传输协议)请求。

Nova组件至少包括Nove api(Application Interface，应用接口)服务、Scheduler(调度)服务、Computer(计算)服务和Nove DB(数据库)。Nove api服务用于根据HTTP请求进行资源配额和参数检查，并将虚拟机的元数据注入Nove DB中；Scheduler服务用于读取Nove DB的内容，从可用的资源池(KVM资源池或Vmware中的ESX资源池)中选择最合适的节点，调用该节点的Computer服务来创建虚拟机；Computer服务用于与Neutron组件交互以为虚拟机分配网络、与Glance组件交互以下载镜像、与Cinder组件交互以部署存储类型，再调用驱动(LibvirtDriver或VCDriver)来创建虚拟机，并通过与资源池(KVM资源池或ESX资源池)的交互来运行虚拟机并管理虚拟机的生命周期。

Glance组件至少包括Glance api服务和Glance DB，Glance api服务用于接收客户端的HTTP请求，通过与Glance DB的交互完成镜像的存储与获取。

Cinder组件至少包括Cinder api服务和Cinder DB，Cinder api服务用于接收客户端的HTTP请求，通过与Cinder DB的交互完成存储后端的存储类型的部署。

Neutron组件至少包括Neutron api服务和Neutron DB，Neutron api服务用于接收客户端的HTTP请求，通过与Neutron DB的交互完成网络的创建。

需要说明的是，图1中以各个api位于对应的组件内进行举例说明的，实际上，也可以将各个api看成是各个组件对外的接口，将各个api设置于对应的组件外，此处不作赘述。

在Vmware接入Openstack后，Openstack可以通过VCDriver来调用Vcenter，通过Vcenter来管理Vmware。

从资源的角度来说，Vmware的资源池至少包括网络资源池、存储资源池和计算资源池，在Vmware接入Openstack后，Openstack可以纳管Vmware的资源池，从而实现资源池的互通。其中，对Vmware的资源池的纳管过程为：Openstack读取Vmware的网络结构的信息，根据该信息在Openstack创建相同的网络，该过程即为纳管网络资源池的过程；Openstack将Cinder的存储后端配置为Vmware的存储类型，该过程即为纳管存储资源池的过程；Openstack再纳管Vmware的虚拟机，该过程即为纳管计算资源池的过程。下文着重对Openstack纳管Vmware的虚拟机的流程进行介绍。

需要说明的是，Openstack纳管Vmware的虚拟机是指：Openstack可以对Vmware中的虚拟机进行生命周期管理、网络管理、存储管理、统一门户和认证管理等等，从而实现Openstack和Vmware的资源池的互通，真正实现了异构云的统一管理。

通俗来说，在Openstack纳管Vmware中的虚拟机之后，可以通过Openstack对Vmware中的虚拟机进行开机、关机、重启、重装、VNC(Virtual Network Computing，虚拟网络控制台)等等操作。

由于Openstack只能对待创建的虚拟机进行纳管，而不能纳管已创建的虚拟机，使得Openstack纳管的虚拟机的类型较少。而本实施例中，Openstack不仅可以纳管待创建的虚拟机，还可以纳管已创建的虚拟机。

请参考图2，其示出了本发明一个实施例提供的虚拟机的纳管方法的方法流程图，该虚拟机的纳管方法可以应用于管理平台中，该管理平台包括客户端、虚拟机创建接口和计算组件。当管理平台是图1所示的Openstack时，客户端可以是图1中未示出的Openstack的客户端，虚拟机创建接口可以是Nova api，计算组件可以是Nova组件，该虚拟机的纳管方法，包括：

步骤201，客户端生成虚拟机创建请求，该虚拟机创建请求中携带有指示虚拟平台创建的虚拟机的元数据。

在管理平台纳管虚拟平台的虚拟机之前，需要虚拟平台先创建虚拟机。其中，虚拟平台创建虚拟机有两种方式，第一种方式是根据管理平台的指示创建虚拟机，此时，用户登录管理平台，管理平台的客户端中显示有虚拟平台的计算资源池(例如ESX资源池)和管理平台的计算资源池(例如KVM资源池)的选项，当用户选择虚拟平台的计算资源池时，确定管理平台指示虚拟平台创建虚拟机，客户端生成虚拟机创建请求，根据该虚拟机创建请求指示虚拟平台创建虚拟机。第二种方式是不根据管理平台的指示创建虚拟机，即不是根据管理平台的指示创建的，而是用户直接登录虚拟平台，并在虚拟平台上进行操作，虚拟平台根据用户的操作自行创建的虚拟机。

对应于上述两种创建方式，管理平台纳管的虚拟机包括两种，第一种是通过上述第一种方式创建的虚拟机，也即，虚拟平台中待创建的虚拟机；第二种是通过上述第二种方式创建的虚拟机，也即，虚拟平台中已创建的虚拟机，该虚拟机也被称为存量虚拟机。无论纳管的是虚拟平台中待创建的虚拟机还是已创建的虚拟机，管理平台都会调用客户端，由客户端生成虚拟机创建请求，根据虚拟机创建请求来纳管虚拟机。其中，虚拟机创建请求的生成过程详见步骤301-304或步骤401-402中的描述。

元数据用于标识虚拟机，包括虚拟机名称(vm_name)、虚拟机机型(vm_flavor)、虚拟机标准镜像(vm_glance_uuid)、虚拟机网络标识(vm_net_uuid)和虚拟机因特网地址(vm_ipv4)中的至少一种。当然，元数据还可以包括其他内容，本实施例不作限定。

步骤202，客户端将虚拟机创建请求发送给虚拟机创建接口。

无论纳管的是虚拟平台中待创建的虚拟机还是已创建的虚拟机，客户端都会将虚拟机创建请求发送给虚拟机创建接口，由虚拟机创建接口进行后续处理。

步骤203，虚拟机创建接口接收虚拟机创建请求。

步骤204，虚拟机创建接口在管理平台中注入元数据。

虚拟机创建接口将虚拟机创建请求中的元数据注入管理平台的数据库中，本实施例不对数据库的类型作限定。当虚拟机创建接口接收到多个虚拟机创建请求时，可以将元数据批量注入管理平台的数据库中。

步骤205，根据元数据对应的虚拟机的类型，计算组件对元数据对应的虚拟机执行对应的纳管操作，虚拟机的类型用于指示虚拟机为已创建的虚拟机或待创建的虚拟机。

由于管理平台纳管的可能是待创建的虚拟机，也可能是已创建的虚拟机，而管理平台对这两种虚拟机的纳管操作不同，所以，管理平台需要先确定纳管的虚拟机的类型，确定过程详见步骤308-310中的描述。当虚拟机是已创建的虚拟机时，纳管操作详见步骤311中的描述；当虚拟机是待创建的虚拟机时，纳管操作详见步骤408中的描述。

在确定了虚拟机类型后，计算组件纳管虚拟机。

本实施例中，由于原生的虚拟机创建接口原来是用于纳管待创建的虚拟机时调用的接口，而本实施例中可以通过虚拟机创建接口纳管已创建的虚拟机和待创建的虚拟机，即，在纳管已创建的虚拟机时复用虚拟机创建接口，可以避免重新开发纳管已创建的虚拟机的接口时，该接口与虚拟机创建接口的代码重复的问题，从而简化了代码。

需要说明的是，在将虚拟平台接入管理平台时，管理平台会进行初始化，在初始化时执行本实施例提供的方法来纳管虚拟平台中已创建的虚拟机。在初始化完成后，用户可能还会直接在虚拟平台中创建虚拟机，所以，管理平台还需要定期同步虚拟平台中已创建的虚拟机的信息，并将该信息与自身已经纳管的虚拟机的信息进行比较，从而确定虚拟平台中已创建且未被纳管的虚拟机，再执行本实施例提供的方法来纳管这些已创建的虚拟机，以保证虚拟平台中的虚拟机都被管理平台纳管。

综上所述，本发明实施例提供的虚拟机的纳管方法，在获取到携带有元数据的虚拟机创建请求后，可以根据虚拟机的类型纳管已创建的虚拟机和待创建的虚拟机，即，虚拟平台既可以纳管待创建的虚拟机，也可以纳管已创建的虚拟机，解决了管理平台只能待创建的虚拟机，纳管的虚拟机的类型较少的问题，从而扩大了管理平台纳管的虚拟机的类型。

由于原生的虚拟机创建接口原来是用于纳管待创建的虚拟机时调用的接口，而本实施例中可以通过虚拟机创建接口纳管已创建的虚拟机和待创建的虚拟机，即，在纳管已创建的虚拟机时复用虚拟机创建接口，可以避免重新开发纳管已创建的虚拟机的接口时，该接口与虚拟机创建接口的代码重复的问题，从而简化了代码。

请参考图3，其示出了本发明另一实施例提供的虚拟机的纳管方法的方法流程图，该虚拟机的纳管方法可以应用于管理平台中，该管理平台包括客户端、虚拟机创建接口、计算组件和驱动组件。当管理平台是图1所示的Openstack时，客户端可以是图1中未示出的Openstack的客户端，虚拟机创建接口可以是Nova api，计算组件可以是Nova组件，驱动组件可以是VCDriver，该虚拟机的纳管方法描述的是管理平台纳管已创建的虚拟机的流程，包括：

步骤301，驱动组件获取虚拟平台已创建的虚拟机的元数据。

其中，元数据的内容详见步骤201中的描述，此处不作赘述。

当虚拟平台是Vmware、管理平台是Openstack时，可以在VCDriver的基础上新增收集模块，该收集模块用于收集Vmware中已创建的虚拟机的元数据。例如，收集模块可以调用某些接口来收集元数据，本实施例不对元数据的收集方式作限定。

步骤302，驱动组件将元数据由虚拟平台支持的格式转换为管理平台支持的格式。

由于虚拟平台和管理平台存储的元数据的格式不同，为了便于管理平台识别元数据，驱动组件还需要对元数据的格式进行转换，即，将元数据由虚拟平台支持的格式转换为管理平台支持的格式，并对格式转换后的元数据进行存储，以实现标准化存储。

本实施例中，可以利用收集模块对元数据进行格式转换，以实现标准化存储。

步骤303，驱动组件将格式转换后的元数据发送给客户端。

这里的客户端用于生成虚拟机创建请求。

步骤304，客户端生成携带有格式转换后的元数据的虚拟机创建请求。

针对每条元数据，客户端可以生成一个携带有该元数据的虚拟机创建请求，这里的虚拟机创建请求实际用于触发管理平台来纳管已创建的虚拟机。

管理平台可以执行步骤301-304来生成虚拟机创建请求。

步骤305，客户端将虚拟机创建请求发送给管理平台中的虚拟机创建接口。

步骤306，虚拟机创建接口接收虚拟机创建请求。

步骤307，虚拟机创建接口在管理平台中注入元数据。

虚拟机创建接口在管理平台中注入元数据的内容详见步骤204中的描述，此处不作赘述。

当虚拟平台是Vmware、管理平台是Openstack时，可以设置批量注入脚本，该批量注入脚本即为Nova api中的注入模块，Nova api向Openstack的数据库中批量注入元数据。

步骤308，虚拟机创建接口向驱动组件发送查询请求。

查询请求用于查询虚拟平台中是否已存在元数据对应的虚拟机。

步骤309，驱动组件根据查询请求查询虚拟平台中是否已存在元数据对应的虚拟机。

其中，驱动组件根据查询请求查询虚拟平台中是否已存在元数据对应的虚拟机，包括：

驱动组件根据查询请求，查询虚拟平台中是否存在与虚拟机创建请求中携带的元数据相同的元数据；

当虚拟平台中存在与虚拟机创建请求中携带的元数据相同的元数据时，驱动组件确定元数据对应的虚拟机为已创建的虚拟机；

当虚拟平台中不存在与虚拟机创建请求中携带的元数据相同的元数据时，驱动组件确定元数据对应的虚拟机为待创建的虚拟机。

本实施例中，驱动组件可以获取虚拟平台的数据库中的元数据和管理平台的数据库中的元数据，再通过判断这两个元数据中的全部或部分数据是否相同来确定这两个元数据是否相同。比如，可以认为具有相同的虚拟机名称的两个元数据相同，或者，可以认为具有相同的uuid(Universally Unique Identifier，唯一识别码)的两个元数据相同，或者，可以认为具有相同的虚拟机名称、相同的uuid的了两个元数据相同等等，本实施例不作限定。

当虚拟平台是Vmware、管理平台是Openstack时，可以在VCDriver的基础上新增路由模块，该路由模块用于调用虚拟机创建接口来查询虚拟平台中是否已存在该元数据对应的虚拟机。

步骤310，当虚拟平台中已存在元数据对应的虚拟机时，驱动组件确定元数据对应的虚拟机为已创建的虚拟机，向计算组件反馈创建成功的结果。

由于虚拟平台中已存在该元数据对应的虚拟机，所以，驱动组件可以进行伪创建，伪创建是指仅在管理平台的数据库中注入元数据，而不创建虚拟机，即，并不真正地实例化虚拟机。

在确定虚拟平台中已存在元数据对应的虚拟机时，驱动组件获取虚拟机的状态，并向计算组件反馈虚拟机的状态和创建成功的结果。其中，虚拟机的状态包括开关机状态等等，本实施例不作限定。

当虚拟平台是Vmware、管理平台是Openstack时，可以利用VCDriver原生的反馈模块获取虚拟机的状态和创建成功的结果，向Nova组件反馈虚拟机的状态和创建成功的结果。

步骤311，计算组件根据注入的元数据对虚拟平台已创建的虚拟机进行纳管。

在伪创建后，计算组件根据注入的元数据对虚拟平台已创建的虚拟机进行纳管。

需要说明的是，在将虚拟平台接入管理平台时，管理平台会进行初始化，在初始化时执行本实施例提供的方法来纳管虚拟平台中已创建的虚拟机。在初始化完成后，用户可能还会直接在虚拟平台中创建虚拟机，所以，管理平台还需要定期同步虚拟平台中已创建的虚拟机的信息，并将该信息与自身已经纳管的虚拟机的信息进行比较，从而确定虚拟平台中已创建且未被纳管的虚拟机，再执行本实施例提供的方法来纳管这些已创建的虚拟机，以保证虚拟平台中的虚拟机都被管理平台纳管。

综上所述，本发明实施例提供的虚拟机的纳管方法，在获取到携带有元数据的虚拟机创建请求后，可以根据虚拟机的类型纳管已创建的虚拟机和待创建的虚拟机，即，虚拟平台既可以纳管待创建的虚拟机，也可以纳管已创建的虚拟机，解决了管理平台只能待创建的虚拟机，纳管的虚拟机的类型较少的问题，从而扩大了管理平台纳管的虚拟机的类型。

由于原生的虚拟机创建接口原来是用于纳管待创建的虚拟机时调用的接口，而本实施例中可以通过虚拟机创建接口纳管已创建的虚拟机和待创建的虚拟机，即，在纳管已创建的虚拟机时复用虚拟机创建接口，可以避免重新开发纳管已创建的虚拟机的接口时，该接口与虚拟机创建接口的代码重复的问题，从而简化了代码。

请参考图4，其示出了本发明另一实施例提供的虚拟机的纳管方法的方法流程图，该虚拟机的纳管方法可以应用于管理平台中，该管理平台包括客户端、虚拟机创建接口、计算组件和驱动组件。当管理平台是图1所示的Openstack时，客户端可以是图1中未示出的Openstack的客户端，虚拟机创建接口可以是Nova api，计算组件可以是Nova组件，该虚拟机的纳管方法描述的是管理平台纳管待创建的虚拟机的流程，包括：

步骤401，客户端根据用户的操作，生成虚拟平台待创建的虚拟机的元数据。

在用户选择了虚拟平台的计算资源池之后，客户端会显示创建虚拟机的一些选项，用户可以对这些选项进行操作，客户端根据这些操作生成虚拟机的元数据。其中，元数据的内容详见步骤201中的描述，此处不作赘述。

步骤402，客户端生成携带有该元数据的虚拟机创建请求。

针对每条元数据，客户端可以生成一个携带有该元数据的虚拟机创建请求，这里的虚拟机创建请求实际用于触发虚拟平台创建虚拟机，并纳管该虚拟机。

客户端可以执行步骤401-402来生成虚拟机创建请求。

步骤403，客户端将虚拟机创建请求发送给管理平台中的虚拟机创建接口。

步骤404，虚拟机创建接口接收虚拟机创建请求。

步骤405，虚拟机创建接口在管理平台中注入元数据。

步骤406，虚拟机创建接口向驱动组件发送查询请求。

步骤407，驱动组件根据查询请求查询虚拟平台中是否已存在元数据对应的虚拟机。

其中，步骤403-407的内容详见步骤305-309的描述，此处不作赘述。

步骤408，当虚拟平台中不存在元数据对应的虚拟机时，驱动组件确定元数据对应的虚拟机为待创建的虚拟机，指示虚拟平台根据元数据创建虚拟机，向计算组件反馈创建成功的结果计算组件根据注入的元数据对虚拟机进行纳管。

由于虚拟平台中不存在元数据对应的虚拟机，所以，驱动组件可以指示虚拟平台进行真创建，真创建是指不仅在管理平台的数据库中注入元数据，还真正地实例化虚拟机。此时，驱动组件调用虚拟平台中的虚拟机创建接口，并将虚拟机创建请求发送给虚拟平台中的虚拟机创建接口，虚拟平台中的虚拟机创建接口根据该虚拟机创建请求，在虚拟平台中创建虚拟机。真创建后，计算组件根据注入的元数据对该创建的虚拟机进行纳管。

当虚拟平台是Vmware、管理平台是Openstack时，Nova api可以向VCDriver中原生的执行模块发送虚拟机创建请求，执行模块调用Vmware中的Vcenter api，并将虚拟机创建请求转发给Vcenter api，Vcenter api根据虚拟机创建请求在Vmware中创建虚拟机。

驱动组件还可以获取创建的结果，当创建的结果是虚拟平台成功创建虚拟机时，可以向计算组件反馈虚拟机的状态和创建成功的结果。

当虚拟平台是Vmware、管理平台是Openstack时，可以利用VCDriver原生的反馈模块获取虚拟机的状态和创建成功的结果，向Nova组件反馈虚拟机的状态和创建成功的结果。

步骤409，当虚拟平台创建虚拟机失败时，计算组件删除在管理平台中注入的元数据。

计算组件还可以获取创建的结果，当创建的结果是虚拟平台创建虚拟机失败时，计算组件会删除在管理平台的数据库中注入的元数据，以节省存储空间。

当虚拟平台是Vmware、管理平台是Openstack时，可以利用VCDriver原生的反馈模块获取虚拟机创建失败的结果，向Nova组件反馈创建失败的结果，再利用Nova组件中的回收模块删除在管理平台的数据库中注入的元数据。可选的，反馈模块还可以对一些超时的操作请求进行删除，并终止超时的操作请求的处理，还可以释放超时存储的结果，以保证管理平台的强壮性。

请参考图5，其以管理平台包括应用系统、收集模块、注入模块、路由模块、执行模块、反馈模块、回收模块和Openstack数据库为例，对各个模块之间的先后运行顺序进行了说明。

综上所述，本发明实施例提供的虚拟机的纳管方法，由于原生的虚拟机创建接口原来是用于纳管待创建的虚拟机时调用的接口，而本实施例中可以通过虚拟机创建接口纳管已创建的虚拟机和待创建的虚拟机，即，在纳管已创建的虚拟机时复用虚拟机创建接口，可以避免重新开发纳管已创建的虚拟机的接口时，该接口与虚拟机创建接口的代码重复的问题，从而简化了代码。

需要说明的是，图3所述的实施例介绍的是管理平台纳管已创建的虚拟机的流程，图4所述的实施例介绍的是管理平台纳管待创建的虚拟机的流程，在实际实现时，还可以对这两个实施例进行合并，请参考图6，其示出了合并后的实施例的流程。

以虚拟平台是Vmware，管理平台是Openstack为例，则Openstack中的VCDriver收集Vmware中已创建的虚拟机的元数据，将元数据进行格式转换后发送给客户端；客户端生成携带有元数据的虚拟机创建请求，将该虚拟机创建请求发送给Nova api；Nova api根据虚拟机创建请求将元数据注入Openstack数据库，向VCDriver发送查询请求；VCDriver基于Vmware数据库中存储的元数据，检测Vmware中是否已存在与该元数据对应的虚拟机；当Vmware中已存在与该元数据对应的虚拟机时，向Nova组件反馈创建成功的结果；Nova组件根据Openstack中的元数据纳管该虚拟机；当Vmware中不存在与该元数据对应的虚拟机时，VCDriver指示Vmware根据元数据创建虚拟机；当创建成功时，向Nova组件反馈创建成功的结果；Nova组件根据Openstack中的元数据纳管该虚拟机；当创建失败时，向Nova组件发送创建失败的结果；Nova组件清除Openstack数据库中注入的该元数据。

请参考图7，其示出了本发明一个实施例提供的管理平台的结构框图，该管理平台，包括：客户端710、虚拟机创建接口720和计算组件730；

客户端710，用于生成虚拟机创建请求，虚拟机创建请求中携带有指示虚拟平台创建的虚拟机的元数据；

客户端710，还用于将虚拟机创建请求发送给管理平台中的虚拟机创建接口；

虚拟机创建接口720，用于接收虚拟机创建请求；

虚拟机创建接口720，还用于在管理平台中注入元数据；

计算组件730，用于根据元数据对应的虚拟机的类型，对元数据对应的虚拟机执行对应的纳管操作，虚拟机的类型用于指示虚拟机为已创建的虚拟机或待创建的虚拟机。

可选的，该管理平台还包括：驱动组件；

虚拟机创建接口720，还用于向驱动组件发送查询请求；

驱动组件，用于根据查询请求查询虚拟平台中是否已存在元数据对应的虚拟机；

驱动组件，还用于在虚拟平台中已存在元数据对应的虚拟机时，确定元数据对应的虚拟机为已创建的虚拟机；

驱动组件，还用于向计算组件反馈创建成功的结果；

计算组件730，还用于根据注入的元数据对虚拟平台已创建的虚拟机进行纳管。

可选的，驱动组件，还用于在虚拟平台中不存在元数据对应的虚拟机时，确定元数据对应的虚拟机为待创建的虚拟机；

驱动组件，还用于指示虚拟平台根据元数据创建虚拟机；

驱动组件，还用于向计算组件反馈创建成功的结果；

计算组件730，还用于根据注入的元数据对虚拟机进行纳管。

可选的，计算组件730，还用于在虚拟平台创建虚拟机失败时，删除在管理平台中注入的元数据。

可选的，驱动组件，还用于：

根据查询请求，查询虚拟平台中是否存在与虚拟机创建请求中携带的元数据相同的元数据；

当虚拟平台中存在与虚拟机创建请求中携带的元数据相同的元数据时，确定元数据对应的虚拟机为已创建的虚拟机；

当虚拟平台中不存在与虚拟机创建请求中携带的元数据相同的元数据时，确定元数据对应的虚拟机为待创建的虚拟机。

可选的，驱动组件，还用于在客户端710生成虚拟机创建请求之前，获取虚拟平台已存在的虚拟机的元数据；

驱动组件，还用于将元数据由虚拟平台支持的格式转换为管理平台支持的格式；

驱动组件，还用于将格式转换后的元数据发送给客户端710；

客户端710，还用于生成携带有格式转换后的元数据的虚拟机创建请求。

可选的，元数据包括虚拟机名称、虚拟机机型、虚拟机标准镜像、虚拟机网络标识和虚拟机因特网地址中的至少一种。

综上所述，本发明实施例提供的管理平台，在获取到携带有元数据的虚拟机创建请求后，可以根据虚拟机的类型纳管已创建的虚拟机和待创建的虚拟机，即，虚拟平台既可以纳管待创建的虚拟机，也可以纳管已创建的虚拟机，解决了管理平台只能待创建的虚拟机，纳管的虚拟机的类型较少的问题，从而扩大了管理平台纳管的虚拟机的类型。

由于原生的虚拟机创建接口原来是用于纳管待创建的虚拟机时调用的接口，而本实施例中可以通过虚拟机创建接口纳管已创建的虚拟机和待创建的虚拟机，即，在纳管已创建的虚拟机时复用虚拟机创建接口，可以避免重新开发纳管已创建的虚拟机的接口时，该接口与虚拟机创建接口的代码重复的问题，从而简化了代码。

请参考图8，其示出了本发明一个实施例提供的服务器的结构框图。所述服务器800包括中央处理单元(CPU)801、包括随机存取存储器(RAM)802和只读存储器(ROM)803的系统存储器804，以及连接系统存储器804和中央处理单元801的系统总线805。所述服务器800还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(I/O系统)806，和用于存储操作系统813、应用程序814和其他程序模块815的大容量存储设备807。

所述基本输入/输出系统806包括有用于显示信息的显示器808和用于用户输入信息的诸如鼠标、键盘之类的输入设备809。其中所述显示器808和输入设备809都通过连接到系统总线805的输入输出控制器810连接到中央处理单元801。所述基本输入/输出系统806还可以包括输入输出控制器810以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器810还提供输出到显示屏、打印机或其他类型的输出设备。

所述大容量存储设备807通过连接到系统总线805的大容量存储控制器(未示出)连接到中央处理单元801。所述大容量存储设备807及其相关联的计算机可读介质为服务器800提供非易失性存储。也就是说，所述大容量存储设备807可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。

不失一般性，所述计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、EPROM、EEPROM、闪存或其他固态存储其技术，CD-ROM、DVD或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的系统存储器804和大容量存储设备807可以统称为存储器。

根据本发明的各种实施例，所述服务器800还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器800可以通过连接在所述系统总线805上的网络接口单元811连接到网络812，或者说，也可以使用网络接口单元811来连接到其他类型的网络或远程计算机系统(未示出)。

所述存储器还包括一个或者一个以上的程序，所述一个或者一个以上程序存储于存储器中，所述一个或者一个以上程序用于执行上述虚拟机的纳管方法。

本发明一个实施例提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上所述的虚拟机的纳管方法。

本发明一个实施例提供了一种管理平台，所述管理平台包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如上所述的虚拟机的纳管方法。

需要说明的是：上述实施例提供的管理平台在进行虚拟机的纳管时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将管理平台的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的管理平台与虚拟机的纳管方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述并不用以限制本发明实施例，凡在本发明实施例的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明实施例的保护范围之内。

Claims (10)

1.一种虚拟机的纳管方法，其特征在于，用于接入有虚拟平台的管理平台中，所述管理平台包括客户端、虚拟机创建接口和计算组件，所述方法包括：

所述客户端生成虚拟机创建请求，所述虚拟机创建请求中携带有指示所述虚拟平台创建的虚拟机的元数据；

所述客户端将所述虚拟机创建请求发送给所述虚拟机创建接口；

所述虚拟机创建接口接收所述虚拟机创建请求；

所述虚拟机创建接口在所述管理平台中注入所述元数据；

根据所述元数据对应的虚拟机的类型，所述计算组件对所述元数据对应的虚拟机执行对应的纳管操作，所述虚拟机的类型用于指示所述虚拟机为已创建的虚拟机或待创建的虚拟机。

2.根据权利要求1所述的方法，其特征在于，所述管理平台还包括驱动组件，所述方法还包括：

所述虚拟机创建接口向所述驱动组件发送查询请求；

所述驱动组件根据所述查询请求查询所述虚拟平台中是否已存在所述元数据对应的虚拟机；

当所述虚拟平台中已存在所述元数据对应的虚拟机时，所述驱动组件确定所述元数据对应的虚拟机为已创建的虚拟机；

所述驱动组件向所述计算组件反馈创建成功的结果；

所述根据所述元数据对应的虚拟机的类型，所述计算组件对所述元数据对应的虚拟机执行对应的纳管操作，包括：所述计算组件根据注入的所述元数据对所述虚拟平台已创建的所述虚拟机进行纳管。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

当所述虚拟平台中不存在所述元数据对应的虚拟机时，所述驱动组件确定所述元数据对应的虚拟机为待创建的虚拟机；

所述驱动组件指示所述虚拟平台根据所述元数据创建所述虚拟机；

所述驱动组件向所述计算组件反馈创建成功的结果；

所述根据所述元数据对应的虚拟机的类型，所述计算组件对所述元数据对应的虚拟机执行对应的纳管操作，包括：所述计算组件根据注入的所述元数据对所述虚拟机进行纳管。

4.根据权利要求3所述的方法，其特征在于，在所述驱动组件指示所述虚拟平台根据所述元数据创建所述虚拟机之后，所述方法还包括：

当所述虚拟平台创建所述虚拟机失败时，所述计算组件删除在所述管理平台中注入的所述元数据。

5.根据权利要求2所述的方法，其特征在于，所述驱动组件根据所述查询请求所述虚拟机创建接口查询所述虚拟平台中是否已存在所述元数据对应的虚拟机，包括：

所述驱动组件根据所述查询请求，查询所述虚拟平台中是否存在与所述虚拟机创建请求中携带的元数据相同的元数据；

当所述虚拟平台中存在与所述虚拟机创建请求中携带的元数据相同的元数据时，所述驱动组件确定所述元数据对应的虚拟机为已创建的虚拟机；

当所述虚拟平台中不存在与所述虚拟机创建请求中携带的元数据相同的元数据时，所述驱动组件确定所述元数据对应的虚拟机为待创建的虚拟机。

6.根据权利要求2或5所述的方法，其特征在于，在所述客户端生成虚拟机创建请求之前，所述方法还包括：

所述驱动组件获取所述虚拟平台已创建的虚拟机的元数据；

所述驱动组件将所述元数据由所述虚拟平台支持的格式转换为所述管理平台支持的格式；

所述驱动组件将格式转换后的所述元数据发送给所述客户端；

所述客户端生成虚拟机创建请求，包括：所述客户端生成携带有格式转换后的所述元数据的所述虚拟机创建请求。

7.根据权利要求1所述的方法，其特征在于，所述元数据包括虚拟机名称、虚拟机机型、虚拟机标准镜像、虚拟机网络标识和虚拟机因特网地址中的至少一种。

8.一种管理平台，其特征在于，所述管理平台包括：客户端、虚拟机创建接口和计算组件；

所述客户端，用于生成虚拟机创建请求，所述虚拟机创建请求中携带有指示所述虚拟平台创建的虚拟机的元数据；

所述客户端，还用于将所述虚拟机创建请求发送给所述虚拟机创建接口；

所述虚拟机创建接口，用于接收所述虚拟机创建请求；

所述虚拟机创建接口，还用于在所述管理平台中注入所述元数据；

所述计算组件，用于根据所述元数据对应的虚拟机的类型，对所述元数据对应的虚拟机执行对应的纳管操作，所述虚拟机的类型用于指示所述虚拟机为已创建的虚拟机或待创建的虚拟机。

9.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至7任一项所述的虚拟机的纳管方法。

10.一种管理平台，其特征在于，所述虚拟平台包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如权利要求1至7任一项所述的虚拟机的纳管方法。