虚拟化处理系统、方法、装置及设备

技术领域

本申请涉及云计算技术领域，具体涉及虚拟化处理系统，虚拟化处理方法及装置，以及电子设备。

背景技术

云计算向不同领域的客户提供多样化的云服务,也就是将IT资源按需分配给需要的租户，当一个用户对其占用的资源不再使用时资源自动释放，可供其他用户使用，这样资源得以最大化利用，并且可以按需扩展，及时满足使用需求。

虚拟化技术是云操作系统的关键技术之一，可使得一台硬件设备被虚拟成多个具备独立功能的虚拟设备，以便同时供多个用户使用。虚拟化是通过虚拟机监视器(VirtualMachine Monitor，简称VMM，又称为hypervisor或者虚拟化组件)实现的，虚拟机监视器是虚拟化技术的核心，服务器虚拟化需要评估、选择和部署hypervisor，主流的hypervisor包括开源的Xen和KVM等虚拟化技术架构。随着虚拟化技术的发展，在各种虚拟化技术架构的研发期间，都伴随着几个虚拟化技术痛点问题的克服。虚拟化痛点问题包括：由于虚拟化组件都部署在宿主机上，和用户虚拟机共用资源，这样容易对用户虚拟机造成干扰和波动，如导致中央处理器(CPU)计算特性损失、资源争抢、IO性能瓶颈等。目前，主要通过将虚拟机监视器下沉到虚拟机管控板卡(如阿里研发的MOC卡)，克服上述问题，使得宿主机资源能够被用户虚拟机有效利用。

然而，在实现本发明过程中，发明人发现上述技术方案在所有管控都下沉之后，势必会造成虚拟机管控板卡负担沉重，不仅网络虚拟化、存储虚拟化下沉，且各种弹性计算服务ECS相关的管控(如服务质量Qos限流管控，日志管控，状态监控等)也都下沉，这在虚拟机管控板卡硬件资源一定的情况下至少存在如下问题：当ECS应用负载冲高时(如分享简短实时信息的社交网络平台的突发热搜场景)，管控任务消耗的板卡资源受应用负载影响急剧增大，虚拟机管控板卡无法有效做到管控资源动态伸缩，从而导致虚拟化速度慢，发生IO延迟、网络延迟等问题。

发明内容

本申请提供虚拟化处理系统，以解决现有技术存在的在ECS应用负载访问量过大时虚拟机管控板卡无法确保管控资源动态伸缩，从而影响虚拟化速度的问题。本申请另外提供虚拟化处理方法和装置，及电子设备。

本申请提供一种虚拟化处理系统，包括：

虚拟化基础架构，部署在虚拟机管控板卡侧，用于构建虚拟化系统，以管理用户虚拟机；

管控虚拟机，部署在宿主机侧，用于对用户虚拟机使用宿主机资源进行管控。

可选的，还包括：

管控虚拟机处理装置，部署在虚拟机管控板卡侧，用于构建所述管控虚拟机，并确定所述管控板卡的资源使用状况数据；若板卡资源使用状况数据不满足板卡管控条件，则将所述管控虚拟机部署在宿主机侧，以使用宿主机资源进行管控。

可选的，所述处理装置，还用于若板卡资源使用状况数据满足板卡管控条件，则将所述管控虚拟机部署在所述管控板卡侧，以使用板卡资源进行管控。

可选的，所述应用级管控包括多个管控任务，不同管控任务对应不同管控虚拟机；

所述处理装置，还用于通过管控虚拟机部署策略，将部分管控虚拟机部署在宿主机侧，部分管控虚拟机部署在所述管控板卡侧。

可选的，所述处理装置，还用于若用户虚拟机的应用负载导致板卡资源使用状况数据不满足板卡管控条件，则将所述管控虚拟机从所述管控板卡侧切换部署至宿主机侧。

可选的，所述宿主机侧包括：应用负载不会导致板卡资源使用状况数据不满足板卡管控条件的用户虚拟机。

可选的，所述板卡管控条件包括：板卡资源使用状况数据小于或者等于数据阈值。

可选的，板卡资源包括：定制硬件资源，处理器资源,内存资源，网络资源；

所述数据阈值包括：定制硬件资源阈值，处理器资源阈值，内存资源阈值，网络资源阈值。

可选的，部署在宿主机侧的管控虚拟机通过前后端驱动vHost方式与用户虚拟机通信；

部署在宿主机侧的管控虚拟机通过直通vifo方式与部署在虚拟机管控板卡侧的第一虚拟机监视器通信。

可选的，所述部署在宿主机侧的管控虚拟机通过前后端驱动vHost方式与用户虚拟机通信，包括：

将前端驱动部署在用户虚拟机侧，将后端驱动部署在管控虚拟机侧。

可选的，通过控制组群的方式，对部署在宿主机侧的管控虚拟机和用户虚拟机使用的宿主机资源进行隔离。

可选的，还包括：

所述虚拟化基础架构包括：弹性计算服务ECS管控装置，第一虚拟机监视器，存储客户端，网络客户端，定制硬件资源；

所述ECS管控装置，用于接收ECS服务请求，调用第一虚拟机监视器；

所述第一虚拟机监视器，用于执行设备模拟处理，以及通过定制硬件资源与宿主机通信，通过存储客户端和网络客户端与远端通信；

所述第一虚拟机监视器通过所述存储客户端与部署在云存储设备的存储主控端通信，以便于执行云存储虚拟化处理；

所述第一虚拟机监视器通过所述网络客户端与对方通信；

所述管控虚拟机通过所述定制硬件资源与第一虚拟机监视器通信。

可选的，还包括：

第二虚拟机监视器，部署在宿主机侧，用于管控虚拟机与用户虚拟机的虚拟化模拟。

可选的，还包括：

所述对用户虚拟机使用宿主机资源进行管控，包括：

对用户虚拟机执行服务质量QoS限流管控；

对用户虚拟机执行日志管理；

对用户虚拟机执行状态监控。

可选的，所述管控板卡包括基于现场可编程逻辑门阵列FPGA芯片的管控板卡。

本申请还提供一种虚拟化处理装置，包括：

管控虚拟机构建单元，用于构建管控虚拟机，所述管控虚拟机用于对用户虚拟机使用宿主机资源进行管控；

板卡资源使用状况确定单元，用于确定虚拟机管控板卡的资源使用状况数据；

管控虚拟机部署单元，用于若板卡资源使用状况数据不满足板卡管控条件，则将所述管控虚拟机部署在宿主机上，以使用宿主机资源进行管控。

本申请还提供一种虚拟化处理方法，包括：

构建管控虚拟机，所述管控虚拟机用于对用户虚拟机使用宿主机资源进行管控；

确定虚拟机管控板卡的资源使用状况数据；

若板卡资源使用状况数据不满足板卡管控条件，则将所述管控虚拟机部署在宿主机上，以使用宿主机资源进行管控。

可选的，还包括：

若板卡资源使用状况数据满足板卡管控条件，则将所述管控虚拟机部署在所述管控板卡上，以使用管控板卡资源进行管控。

可选的，部署在宿主机侧的管控虚拟机通过前后端驱动vHost方式与用户虚拟机通信；

部署在宿主机侧的管控虚拟机通过直通vifo方式与部署在所述管控板卡侧的虚拟机监视器通信。

可选的，通过控制组群的方式，对所述管控虚拟机和所述用户虚拟机使用的宿主机资源进行隔离。

本申请还提供一种电子设备，包括：

处理器和存储器；

存储器，用于存储实现根据上述方法的程序，该设备通电并通过所述处理器运行该方法的程序。

本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各种方法。

本申请还提供一种包括指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各种方法。

与现有技术相比，本申请具有以下优点：

本申请实施例提供的虚拟化处理系统，包括虚拟化基础架构和管控虚拟机。其中，虚拟化基础架构部署在虚拟机管控板卡侧，用于构建虚拟化系统，以管理用户虚拟机；管控虚拟机部署在宿主机侧，用于对用户虚拟机使用宿主机资源进行管控。该系统采用基于虚拟节点的管控方式，至少可达到以下有益效果：

1)使得把管控封装在管控虚拟机里，既可部署在宿主机侧，也能部署在管控板卡侧，这样当用户虚拟机访问量冲高导致管控板卡资源不够时，能动态在宿主机侧启动一个或多个虚拟管控节点，该节点可分担管控板卡的一部分管控任务，利用宿主机资源进行虚拟机管控；因此，可以持续确保管控资源动态伸缩；

2)使得利用宿主机资源进行管控，可提升管控任务的可扩展性；

3)由于宿主机侧执行的管控都运行在管控虚拟机中，并没有将管控组件直接运行在宿主机上，这样可避免管控组件和用户虚拟机共用资源，做到管控组件与用户虚拟机隔离，控制宿主机执行管控对用户虚拟机的干扰，使得管控虚拟机与用户虚拟机间实现更高粒度的资源隔离和更高的安全性。

4)使得虚拟机管控板卡只需满足虚拟机基本架构需求即可，这样可实现板卡硬件资源配置最小化，有效降低MOC卡成本。

附图说明

图1本申请提供的虚拟化处理系统的实施例的结构示意图；

图2本申请提供的虚拟化处理系统的实施例的应用场景示意图；

图3本申请提供的虚拟化处理系统的实施例的具体结构示意图；

图4本申请提供的虚拟化处理系统的实施例的管控虚拟机部署在宿主机侧的架构示意图；

图5本申请提供的虚拟化处理装置的实施例的结构示意图；

图6本申请提供的虚拟化处理方法的实施例的流程示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请中，提供虚拟化处理系统、方法和装置，及电子设备。在下面的实施例中逐一对各种方案进行详细说明。

第一实施例

请参考图1，其为本申请的虚拟化处理系统的实施例的结构示意图。在本实施例中，所述系统包括：虚拟机基础架构1，管控虚拟机2。

所述虚拟机基础架构1，部署在虚拟机管控板卡侧，用于构建虚拟化系统，以管理用户虚拟机。所述管控虚拟机2，部署在宿主机侧，用于对用户虚拟机使用宿主机资源进行管控。

所述宿主机，是指云计算节点(简称CN)的主机。在宿主机上可运行多个用户虚拟机，用户虚拟机可弹性使用宿主机资源。所述宿主机资源，可包括计算资源、存储资源、网络资源等。

所述虚拟机管控板卡，可采用包括系统级芯片SOC的板卡。在所述虚拟机管控板卡上，可安装操作系统OS，上面可进行用户虚拟机VM存储和网络的转发，后端可连接云盘(如盘古集群)，也可运行各种管控任务。在本实施例中，采用基于PCI-E接口的智能SOC板卡作为虚拟机管控板卡，如基于现场可编程逻辑门阵列FPGA芯片的管控板卡，如MOC卡。由于FPGA芯片成本较高，因此在这种情况下更加具有管控资源动态伸缩的需求。此外，如果采用基于现场可编程逻辑门阵列FPGA芯片的管控板卡，在应用本申请实施例提供的系统后，可有效降低管控板卡的硬件成本。

所述虚拟机基础架构1属于现有技术范畴，其构建了虚拟化系统，可管理用户虚拟机，如初始化用户虚拟机等。所述用户虚拟机，又可称为虚拟主机；所述宿主机资源包括：计算资源，存储资源，网络资源。用户购买云服务后，所述虚拟化基础架构为该用户配置用户虚拟机，用户可在其虚拟机上部署应用系统，如分享简短实时信息的社交网络平台，还可安装数据库管理系统(虚拟数据库管理系统)，也可部署内容分发网络(虚拟内容分发网络)，等等。

本申请实施例提供的系统可用在裸金属场景下，裸金属云也被称为裸机云，可同时拥有物理机级别的性能和云的弹性。裸金属架构就是直接在硬件上面安装虚拟化软件，再在其上安装操作系统和应用，依赖虚拟层内核和服务器控制台进行管理。

在裸金属场景下，现有技术将所有管控任务都下沉到虚拟机管控板卡上，不仅网络虚拟化、存储虚拟化下沉，且各种弹性计算服务ECS相关的管控任务也都下沉。由于执行ECS相关的管控任务所消耗的设备资源受应用负载影响较大，因此这种将所有管控任务都下沉到虚拟机管控板卡的方式势必会造成虚拟机管控板卡负担沉重。例如，当ECS应用负载冲高时(如分享简短实时信息的社交网络平台的突发热搜场景)，虚拟机管控板卡无法有效做到管控资源动态伸缩。

请参考图2，其为本申请的虚拟化处理系统的实施例的应用场景图。在本实施例中，云计算平台包括多个计算节点(服务器，简称CN)CN

此外，由于宿主机侧执行的管控都运行在管控虚拟机中，并没有将管控组件直接运行在宿主机上，这样可避免管控组件和用户虚拟机共用资源，做到管控组件与用户虚拟机隔离，控制宿主机执行管控对用户虚拟机的干扰，使得虚拟机监视器与用户虚拟机间实现更高粒度的资源隔离和更高的安全性，同时也方便各管控组件的动态伸缩，如热迁移、热升级、热插拔等高级特性的应用。

请参考图3，其为本申请的虚拟化处理系统的实施例的具体结构示意图。在本实施例中，所述虚拟化基础架构可包括如下与虚拟化相关的组件：弹性计算服务ECS管控装置，第一虚拟机监视器，存储客户端(存储client)，网络客户端，定制硬件资源。

其中，所述ECS管控装置可用于接收ECS服务请求，如接收用户通过网页下发的ECS服务命令，可初始化用户虚拟机，并调用第一虚拟机监视器，如输入/输出多端口转发器IOHub，以将远端云盘加进来。所述第一虚拟机监视器，用于执行设备模拟处理，可包括存储虚拟化和网络虚拟化。所述第一虚拟机监视器，可通过定制硬件资源与宿主机通信，通过存储客户端和网络客户端与远端通信。所述第一虚拟机监视器，具体可通过所述存储客户端与部署在云存储设备(如云盘)的存储主控端(存储master)通信，以便于执行云存储虚拟化处理。所述第一虚拟机监视器，还可通过所述网络客户端与对方通信。上述虚拟化基础架构中的各种组件及其功能属于现有技术，因此此处不再赘述。

由图3可见，本申请实施例提供的系统在管控板卡侧还可包括：定制硬件资源，部署在宿主机侧的管控虚拟机可通过所述定制硬件资源与第一虚拟机监视器通信。在本实施例中，定制硬件资源为一个fpga芯片(专用集成电路)，用于与宿主机交互，管控虚拟机与MOC交互，MOC与远端云盘连接。

此外，还可在宿主机侧包括：第二虚拟机监视器(如KVM、qemu等)，第二虚拟机监视器用于管控虚拟机与用户虚拟机的虚拟化模拟，如设备模拟，cpu模拟、内存模拟等。由于第二虚拟机监视器属于现有技术，因此此处不再赘述。

所述系统通过管控虚拟机对用户虚拟机使用宿主机资源进行管控，包括但不限于ECS相关管控。执行ECS相关管控所消耗的设备资源通常受ECS应用负载的影响较大，且该类管控任务可根据应用需求增加或者减少。

具体实施时，所述系统通过管控虚拟机对用户虚拟机使用宿主机资源进行管控，可包括以下管控的一项或者多项：对用户虚拟机执行服务质量QoS限流管控；对用户虚拟机执行日志管理；对用户虚拟机执行状态监控。此外，也可以根据应用需求设计其它管控任务。由于ECS相关的管控任务属于现有技术，因此此处不再赘述。

由图3可见，部署在宿主机侧的管控虚拟机可通过前后端驱动vHost方式与用户虚拟机通信；部署在宿主机侧的管控虚拟机可使用定制硬件资源通过直通vifo方式与管控板卡(如第一虚拟机监视器)通信。vHost是virtio的一种后端实现方案，virtio是一种半虚拟化的实现方案，需要虚拟机端和宿主机端都提供驱动才能完成通信，通常virtio宿主机端的驱动是实现在用户空间的qemu中，而vhost是实现在内核中，是内核的一个模块vhost-net.ko。具体实施时，部署在宿主机侧的管控虚拟机也可通过virtio方式与用户虚拟机通信。

在本实施例中，所述部署在宿主机侧的管控虚拟机通过前后端驱动vHost方式与用户虚拟机通信，可采用如下方式实现：将前端驱动部署在用户虚拟机侧，将后端驱动部署在管控虚拟机侧。具体实施时，前端驱动可由客户机(用户虚拟机)实现，后端驱动可由qemu、内核(vhost)、或用户态(vhost-user)实现。

针对图3，其处理流程为：1、用户vm以vhost方式访问vda设备，用户vm里有vda的前端驱动；2、后端驱动最终落到管控vm的vdb里，vdb是cn上的vdc以直通vfio方式给管控vm的；管控vm的io采用用户态驱动，如spdk的方式接受并下发io；3、vdc来自moc上的iohub和tdc把盘古云盘虚拟化后通过定制硬件呈现给cn；4、即vda与vdb为vhost方式，vdb与vdc为vfio方式，vdc与云盘为定制硬件方式；5、宿主机与虚拟机管控板卡处在一台服务器上。

请参考图4，其为本申请的虚拟化处理系统的实施例的管控虚拟机部署在宿主机侧的架构示意图。在本实施例中，管控虚拟机通过vHost技术，实现与宿主机上的用户虚拟机和第二虚拟机监视器通信。所述管控虚拟机可包括：用户态驱动，设备虚拟化接口，数据输入接口，控制接口。管控板卡侧可实现一个简单的设备模拟功能(即实现第一虚拟机监视器)，如通过输入输出集线器(iohub)对接云盘(如盘古云盘)，并通过fpga对宿主机侧以virtio设备展示，并通过存储客户端连接远端云盘。管控虚拟机把该virtio设备直通到用户虚拟机里，即图中的直通dev。用户虚拟机看到的硬盘vda经过kvm、vhost等路径接入管控虚拟机进行管理，并最终由驱动程序(如SPDK)把用户的数据发到云盘。

在本实施例中，初始化流程如下所述。所述第一虚拟机监视器可接收宿主机发送的启动用户虚拟机指令；所述第一虚拟机监视器将所述指令发送至所述管控虚拟机；所述管控虚拟机通过部署在所述管控板卡上的输入输出集线器，创建用户虚拟机对接的云存储器；所述第一虚拟机监视器将与用户虚拟机对应的设备虚拟化接口发送至宿主机；所述宿主机将设备虚拟化接口发送至所述管控虚拟机；所述管控虚拟机将设备虚拟化接口对接用户态驱动；启动用户虚拟机，通过所述虚拟机监视器将用户虚拟机的gpa到hpa信息发送至所述控制接口；所述控制接口构建gpa到hpa信息的映射关系；所述管控虚拟机通过共享内存方式访问用户虚拟机的内存；通过所述控制接口和与用户虚拟机对应的qemu初始化vda接口。

在本实施例中，数据输入输出流程如下所述。所述用户虚拟机将输入/输出数据发送至第一虚拟机监视器，所述第一虚拟机监视器将所述输入/输出数据发送至所述数据输入接口，所述用户态驱动通过所述设备虚拟化接口将所述输入/输出数据发送至用户虚拟机对接的云存储器。

在一个示例中，通过控制组群的方式，对部署在宿主机侧的管控虚拟机和用户虚拟机使用的宿主机资源进行隔离。所述第一虚拟机监视器对所述管控虚拟机和所述用户虚拟机使用的宿主机资源进行隔离。具体实施时，可通过控制组群(如cgroup)等方式，对所述管控虚拟机和所述用户虚拟机使用的宿主机资源进行隔离。采用这样处理方式，可避免管控虚拟机和用户虚拟机共用资源，控制通过计算节点执行管控时对用户虚拟机的干扰；因此可以有效提升安全性。

在一个示例中，本申请实施例提供的系统始终将管控虚拟机部署在宿主机侧，始终使用宿主机资源执行管控。采用这种处理方式，使得虚拟机管控板卡只需满足虚拟化基本架构的资源需求即可，这样可实现板卡硬件资源配置最小化，有效降低MOC卡成本。

在另一个示例中，本申请实施例提供的系统在虚拟机管控板卡侧还部署管控虚拟机处理装置。所述管控虚拟机处理装置，用于构建所述管控虚拟机，并确定所述管控板卡的资源使用状况数据；若板卡资源使用状况数据不满足板卡管控条件，则将所述管控虚拟机部署在宿主机侧，以使用宿主机资源进行管控。采用这种方式使得能够根据板卡资源使用情况，动态在宿主机侧启动管控虚拟机，管控虚拟机作为虚拟管控节点，可继续对用户虚拟机执行管控处理，这样就可以持续确保管控资源动态伸缩，如热迁移、热升级、热插拔等高级特性的应用。

具体实施时，可在所述ECS管控装置内包括所述处理装置，也可将所述处理装置作为所述ECS管控装置的同层次装置。本申请提供的系统，不对所述处理装置的位置进行限定。

所述板卡管控条件包括但不限于：板卡资源使用状况数据小于或者等于数据阈值。所述板卡资源包括：定制硬件资源，处理器资源，内存资源，网络资源；相应的，所述数据阈值包括但不限于：定制硬件资源阈值，处理器资源阈值，内存资源阈值，网络资源阈值。

由图2可见，管控虚拟机也可部署在虚拟机管控板卡侧，虚线部分表示管控虚拟机未部署在该设备上，实现部分表示管控虚拟机部署在该设备上。在本实施例中，所述处理装置，还可用于若板卡资源使用状况数据满足板卡管控条件，则将所述管控虚拟机部署在所述管控板卡侧，以使用板卡资源进行管控。采用这种方式使得如果板卡资源使用状况数据满足板卡管控条件，则将所有应用级管控对应的管控虚拟机都部署至管控板卡侧，这样管控更加纯净，可有效提升管控可控性。

在一个示例中，所述应用级管控包括多个管控任务，不同管控任务对应不同管控虚拟机；所述处理装置，还用于通过管控虚拟机部署策略，将部分管控虚拟机部署在宿主机侧，部分管控虚拟机部署在所述管控板卡侧。这样，既能充分使用管控板卡的资源进行管控，又能满足应用负载过大时的管控资源动态伸缩需求，实现细粒度的管控资源动态伸缩管理；因此，可以有效兼顾管控稳定性、及降低对用户虚拟机影响这两个方面的效果。

所述管控虚拟机部署策略，可根据应用需求确定。例如，可根据不同应用级管控任务消耗的设备资源数据，将资源消耗较少的管控任务对应的管控虚拟机部署在虚拟机管控板卡侧，将资源消耗较多的管控任务对应的管控虚拟机部署在宿主机侧，等等。

在一个示例中，所述处理装置还用于若用户虚拟机的应用负载导致板卡资源使用状况数据不满足板卡管控条件，则将所述管控虚拟机从所述管控板卡侧切换部署至宿主机侧。例如，当用户虚拟机上的应用负载冲高(如微博突发热搜场景)时，部署在管控板卡侧的管控虚拟机将消耗更多的设备资源，如果管控板卡资源不够用，则动态将所述管控虚拟机从所述管控板卡侧切换部署至宿主机侧，这样可确保管控稳定性。

具体实施时，将所述管控虚拟机从所述管控板卡侧切换部署至宿主机侧，可采用重新部署的方式，也可采用热部署的方式。

具体实施方式时，所述处理装置还用于获取应用负载数据；根据应用负载数据，判断应用负载是否会导致板卡资源使用状况数据不满足板卡管控条件；若判断结果为否，则将所述管控虚拟机从所述管控板卡侧切换部署至宿主机侧。

在一个示例中，所述宿主机侧可包括：应用负载不会导致板卡资源使用状况数据不满足板卡管控条件的用户虚拟机，如边缘计算等场景。在这种情况下，可将所有管控任务对应的管控虚拟机部署在管控板卡侧。

本申请实施例提供的虚拟化处理系统，包括虚拟化基础架构和管控虚拟机。其中，虚拟化基础架构部署在虚拟机管控板卡侧，用于构建虚拟化系统，以管理用户虚拟机；管控虚拟机部署在宿主机侧，用于对用户虚拟机使用宿主机资源进行管控。该系统采用基于虚拟节点的管控方式，至少可达到以下有益效果：

1)使得把管控封装在管控虚拟机里，既可部署在宿主机侧，也能部署在管控板卡侧，这样当用户虚拟机访问量冲高导致管控板卡资源不够时，能动态在宿主机侧启动一个或多个虚拟管控节点，该节点可分担管控板卡的一部分管控任务，利用宿主机资源进行虚拟机管控；因此，可以持续确保管控资源动态伸缩；

2)使得利用宿主机资源进行管控，可提升管控任务的可扩展性；

3)由于宿主机侧执行的管控都运行在管控虚拟机中，并没有将管控组件直接运行在宿主机上，这样可避免管控组件和用户虚拟机共用资源，做到管控组件与用户虚拟机隔离，控制宿主机执行管控对用户虚拟机的干扰，使得管控虚拟机与用户虚拟机间实现更高粒度的资源隔离和更高的安全性。

4)使得虚拟机管控板卡只需满足虚拟机基本架构需求即可，这样可实现板卡硬件资源配置最小化，有效降低MOC卡成本。

第二实施例

请参考图5，其为本申请的虚拟化处理装置的实施例的结构示意图。本实施例提供的虚拟化处理装置可部署在虚拟机管控板卡上，可包括：管控虚拟机构建单元501，资源使用状况确定单元502，以及管控虚拟机部署切换单元503。

其中，管控虚拟机构建单元501用于构建管控虚拟机，所述管控虚拟机用于对用户虚拟机使用宿主机资源进行管控；资源使用状况确定单元502，用于确定虚拟机管控板的资源使用状况数据；管控虚拟机部署切换单元503，用于若板资源使用状况数据不满足设备管控条件，则将所述管控虚拟机部署在宿主机上，以使用宿主机资源进行管控。

从上述实施例可见，本申请实施例提供的虚拟化处理装置，通过构建管控虚拟机，所述管控虚拟机用于对用户虚拟机使用宿主机资源进行管控；确定虚拟机管控板卡的资源使用状况数据；若板卡资源使用状况数据不满足板卡管控条件，则将所述管控虚拟机部署在宿主机上，以使用宿主机资源进行管控。采用这种基于虚拟节点的管控方式，使得把管控都封装在管控虚拟机里，既可部署在服务器侧，也能部署在管控板卡侧，这样当用户虚拟机访问量冲高导致管控板卡资源不够时，能动态在宿主机侧启动一个虚拟管控节点，该节点可分担管控板卡的一部分任务；因此，可以持续确保管控资源动态伸缩。同时，由于宿主机侧执行的管控都运行在管控虚拟机中，并没有将管控组件直接运行在宿主机上，这样可避免管控组件和用户虚拟机共用资源，做到管控组件与用户虚拟机隔离，控制服务器执行管控对用户虚拟机的干扰，使得虚拟机监视器与用户虚拟机间实现更高粒度的资源隔离和更高的安全性。

第三实施例

在上述的实施例中，提供了一种虚拟化处理系统，与之相对应的，本申请还提供一种虚拟化处理方法。所述方法的执行主体包括但不限于虚拟机管控板卡，也可以是能够实现所述方法的任意设备。该方法是与上述系统的实施例相对应。由于方法实施例基本相似于系统实施例，所以描述得比较简单，相关之处参见系统实施例的部分说明即可。下述描述的方法实施例仅仅是示意性的。

请参考图6，其为本申请的虚拟化处理装置的实施例的流程示意图。本申请提供一种虚拟化处理方法，包括：

步骤S601：构建管控虚拟机，所述管控虚拟机用于对用户虚拟机使用宿主机资源进行管控。

步骤S603：确定虚拟机管控板卡的资源使用状况数据。

步骤S605：若板卡资源使用状况数据不满足板卡管控条件，则将所述管控虚拟机部署在宿主机上，以使用宿主机资源进行管控。

所述板卡管控条件包括但不限于：板卡资源使用状况数据小于或者等于数据阈值。所述板卡资源包括：定制硬件资源，处理器资源，内存资源，网络资源；相应的，所述数据阈值包括但不限于：定制硬件资源阈值，处理器资源阈值，内存资源阈值，网络资源阈值。

具体实施时，虚拟机管控板卡可通过运行的操作系统初始化管控虚拟机，并在宿主机侧起管控虚拟机。

在一个示例中，所述方法还可包括如下步骤：若板卡资源使用状况数据满足板卡管控条件，则将所述管控虚拟机部署在所述管控板卡上，以使用管控板卡资源进行管控。

在一个示例中，部署在宿主机侧的管控虚拟机通过前后端驱动vHost方式与用户虚拟机通信；部署在宿主机侧的管控虚拟机通过直通vifo方式与部署在所述管控板卡侧的虚拟机监视器通信。

在本实施例中，虚拟机管控板卡侧可只实现一个简单的设备模拟功能，即iohub对接盘古云盘，并对宿主机侧以virtio设备展示，管控虚拟机把该virtio设备直通到VM里，即图中的直通dev。用户虚拟机看到的vda经过kvm、vhost等路径接入管控虚拟机进行管理，并最终由driver(如SPDK)把用户的数据发到云盘。

具体实施时，用户虚拟机初始化流程可采用如下所述的处理过程。虚拟机管控板卡侧收到起用户虚拟机命令，并将该命令下发给管控虚拟机；管控虚拟机可用iohub创建用户虚拟机对应的盘古云盘，并直通到管控虚拟机里，以直通dev(虚拟机管控板卡侧以virtio设上报给宿主机，宿主机再以virtio设备直通给管控虚拟机)方式呈现，并对接SPDK用户态驱动(作为后端)，SPDK输入端来自数据dev，输出端为直通dev。起用户虚拟机，并可将用户虚拟机的user_vm_gpa到hpa信息通过第二虚拟机监视器(如kvm)给到管控虚拟机的控制dev，控制dev进行管控虚拟机的manager_vm_gpa到hpa的映射建立，通过共享内存的方式使得管控虚拟机后续在io操作时能访问到用户虚拟机的内存，即管控虚拟机里的gpa可以对应到用户虚拟机里的gpa。通过控制dev和用户虚拟机对应的qemu进行vda设备(基于virtio设备)相关的初始化，至此用户虚拟机启动完毕。

具体实施时，用户虚拟机的IO流程可采用如下所述的处理过程。用户虚拟机下发IO数据，前端为基于virtio设备，经过kvm后，对接的后端为定制化的vhost，但vhost并不做实际处理，只是将信息封装后再次交给kvm，由kvm转发给数据dev进行真正的后端处理；数据dev(基于vring的dev)收到信息后走vhost-user方式进行处理，对接SPDK驱动(作为前端)；SPDK驱动通过用户态驱动下发，由于是直通设备，因此不会经过CN侧处理，而直接下发到云盘。

在一个示例中，通过控制组群的方式，对所述管控虚拟机和所述用户虚拟机使用的宿主机资源进行隔离。

从上述实施例可见，本申请实施例提供的虚拟化处理方法，通过构建管控虚拟机，所述管控虚拟机用于对用户虚拟机使用宿主机资源进行管控；确定虚拟机管控板卡的资源使用状况数据；若板卡资源使用状况数据不满足板卡管控条件，则将所述管控虚拟机部署在宿主机上，以使用宿主机资源进行管控。采用这种基于虚拟节点的管控方式，使得把管控都封装在管控虚拟机里，既可部署在服务器侧，也能部署在管控板卡侧，这样当用户虚拟机访问量冲高导致管控板卡资源不够时，能动态在宿主机侧启动一个虚拟管控节点，该节点可分担管控板卡的一部分任务；因此，可以持续确保管控资源动态伸缩。同时，由于宿主机侧执行的管控都运行在管控虚拟机中，并没有将管控组件直接运行在宿主机上，这样可避免管控组件和用户虚拟机共用资源，做到管控组件与用户虚拟机隔离，控制服务器执行管控对用户虚拟机的干扰，使得虚拟机监视器与用户虚拟机间实现更高粒度的资源隔离和更高的安全性。

第四实施例

在上述的实施例中，提供了虚拟化处理方法，与之相对应的，本申请还提供一种电子设备。该装置是与上述方法的实施例相对应。由于设备实施例基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的设备实施例仅仅是示意性的。

本实施例的一种电子设备，该电子设备包括：处理器和存储器；存储器，用于存储实现根据上述任一项方法的程序，该设备通电并通过所述处理器运行该方法的程序。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。