一种在aarch64架构下openstack虚拟机支持qxl显卡的方法及装置

技术领域

本申请涉及云计算技术领域，尤其涉及一种在aarch64架构下openstack虚拟机支持qxl显卡的方法及装置。

背景技术

云桌面又称桌面虚拟化、云电脑，是替代传统电脑的一种新模式，采用云桌面后，用户无需再购买电脑主机，主机所包含的CPU、内存、硬盘、网卡等组件全部在后端的服务器中虚拟出来。例如，企业员工的办公桌面统一布署于服务器上并集合存储个体数据，而后经过网络将个体桌面体系迅速交付给员工，员工可以经过各种差异类别的终端设备如瘦客户机、笔记本、手机及平板等随时随地接入办公，从而提升员工的工作效率。

但是，目前创建的桌面虚拟机，虚拟机内部显卡只支持vga和virtio，这两种显卡类型的虚拟机的体验较差，使用过程中存在卡顿、视频抖动、丢帧的问题，不能满足市场需求。

发明内容

为克服现有技术中的不足，本申请提供一种在aarch64架构下openstack虚拟机支持qxl显卡的方法、装置、电子设备及存储介质，能够修改openstack的相关源码，使虚拟机支持qxl显卡驱动，提升桌面虚拟机的操作体验。

第一方面，本申请提供一种在aarch64架构下openstack虚拟机支持qxl显卡的方法，所述方法包括以下步骤：

基于OpenStack云计算服务创建虚拟机；

在基于OpenStack云计算服务创建虚拟机的过程中，根据系统环境设置相应的虚拟机显卡类型；其中，若所述系统环境下的CPU为aarch64架构，通过修改源码的方式将所述虚拟机显卡类型设置为qxl；

将设置的所述虚拟机显卡类型的参数传递至QEMU-KVM程序，以生成支持对应虚拟机显卡类型的虚拟机。

在一种可能的实施方式中，所述基于OpenStack云计算服务创建虚拟机，包括以下步骤：

配置待创建虚拟机的虚拟机参数；

基于OpenStack云计算服务将所述虚拟机参数生成对应的元数据；

将生成的所述虚拟机参数对应的元数据进行汇总，并发送至Libvirt程序；

基于所述Libvirt程序将每个所述元数据对应的所述虚拟机参数写入到待创建的虚拟机的xml定义文件中。

在一种可能的实施方式中，通过实例类型Flavor设置待创建的虚拟机的虚拟机参数；所述虚拟机参数包括CPU线程数、USB支持和音频设备支持中的一种或多种。

在一种可能的实施方式中，在基于所述Libvirt程序将每个所述元数据对应的所述虚拟机参数写入到待创建的虚拟机的xml定义文件中的过程中，根据系统环境设置相应的虚拟机显卡类型。

在一种可能的实施方式中，所述根据系统环境设置相应的虚拟机显卡类型，包括以下步骤：

查看所述Libvirt程序的drvier.py源码，并获取系统的CPU架构参数；

根据不同的虚拟化类型和CPU架构设置相应的虚拟机显卡类型；其中，若虚拟化类型为parallels，设置虚拟机显卡类型为vga；若CPU架构为ppc，设置虚拟机显卡类型为vga；若CPU架构为aarch64，设置虚拟机显卡类型为qxl；

将所述虚拟机显卡类型对应的虚拟机参数一并写入到待创建的虚拟机的xml定义文件。

在一种可能的实施方式中，QEMU-KVM程序根据所述xml定义文件生成对应的虚拟机。

在一种可能的实施方式中，所述方法还包括以下步骤：

通过virsh dump命令查看创建的虚拟机对应的xml定义文件，以验证创建的虚拟机是否支持qxl显卡。

第二方面，本申请提供一种在aarch64架构下openstack虚拟机支持qxl显卡的装置，所述装置包括：

创建模块，用于基于OpenStack云计算服务创建虚拟机；

设置模块，用于在基于OpenStack云计算服务创建虚拟机的过程中，根据系统环境设置相应的虚拟机显卡类型；其中，若所述系统环境下的CPU为aarch64架构，通过修改源码的方式将所述虚拟机显卡类型设置为qxl；

生成模块，用于将设置的所述虚拟机显卡类型的参数传递至QEMU-KVM程序，以生成支持对应虚拟机显卡类型的虚拟机。

第三方面，本申请提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如第一方面任一所述的在aarch64架构下openstack虚拟机支持qxl显卡的方法的步骤。

第四方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如第一方面任一所述的在aarch64架构下openstack虚拟机支持qxl显卡的方法的步骤。

本实施例提供的一种在aarch64架构下openstack虚拟机支持qxl显卡的方法、装置、电子设备及存储介质，基于OpenStack云计算服务创建虚拟机；在基于OpenStack云计算服务创建虚拟机的过程中，根据系统环境设置相应的虚拟机显卡类型；其中，若所述系统环境下的CPU为aarch64架构，通过修改源码的方式将所述虚拟机显卡类型设置为qxl；将设置的所述虚拟机显卡类型的参数传递至QEMU-KVM程序，以生成支持对应虚拟机显卡类型的虚拟机。从而使得虚拟桌面能够支持qxl显卡，相比virtio显卡，桌面中的基础操作更加流畅，窗口在播放视频的情况下画面改善尤为明显，画面丢帧、卡顿和撕裂的情况显著减少，提升用户体验感。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请一实施例所述在aarch64架构下openstack虚拟机支持qxl显卡的方法的流程图；

图2示出了本申请一实施例所述基于OpenStack云计算服务创建虚拟机的流程图；

图3示出了本申请一实施例所述根据系统环境设置相应的虚拟机显卡类型的流程图；

图4示出了本申请一实施例所述获取系统CPU架构的代码示意图；

图5示出了本申请一实施例所述根据系统环境设置相应的虚拟机显卡类型的代码示意图；

图6示出了本申请一实施例所述将所述虚拟机显卡类型对应的虚拟机参数一并写入到待创建的虚拟机的xml定义文件的代码示意图；

图7示出了本申请一实施例所述查看创建的虚拟机对应的xml定义文件的代码示意图；

图8示出了本申请一实施例所述虚拟机分辨率调节装置的结构示意图；

图9示出了本申请一实施例所述电子设备的结构框图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

当前大环境下，软硬件的国产化是一个大的趋势。云桌面项目在国产服务器和国产操作系统中部署，其中国产服务器CPU架构为aarch64。而在此基础上创建的桌面虚拟机，虚拟机内部显卡只支持vga和virtio，存在卡顿、视频抖动、丢帧的问题。基于此，本申请提供一种在aarch64架构下openstack虚拟机支持qxl显卡的方法、装置、电子设备及存储介质，能够修改openstack的相关源码，使虚拟机支持qxl显卡驱动，提升桌面虚拟机的操作体验。

在一实施例中，参见说明书附图1，本申请提供的一种在aarch64架构下openstack虚拟机支持qxl显卡的方法，包括以下步骤：

S1、基于OpenStack云计算服务创建虚拟机；

S2、在基于OpenStack云计算服务创建虚拟机的过程中，根据系统环境设置相应的虚拟机显卡类型；其中，若所述系统环境下的CPU为aarch64架构，通过修改源码的方式将所述虚拟机显卡类型设置为qxl；

S3、将设置的所述虚拟机显卡类型的参数传递至QEMU-KVM程序，以生成支持对应虚拟机显卡类型的虚拟机。

在本申请实施例中，所述在aarch64架构下openstack虚拟机支持qxl显卡的方法可以运行于终端设备或者是服务器；其中，终端设备可以为本地应用软件，当在aarch64架构下openstack虚拟机支持qxl显卡的方法运行于服务器时，该在aarch64架构下openstack虚拟机支持qxl显卡的方法则可以基于云交互系统来实现与执行，其中，云交互系统至少包括服务器和客户端设备(也即应用软件)。具体的，以应用于服务器为例，当在aarch64架构下openstack虚拟机支持qxl显卡的方法运行于服务器时，能够修改openstack的相关源码，使虚拟机支持qxl显卡驱动。

参见说明书附图2，在步骤S1中，所述基于OpenStack云计算服务创建虚拟机，包括以下步骤：

S101、配置待创建虚拟机的虚拟机参数；

S102、基于OpenStack云计算服务将所述虚拟机参数生成对应的元数据；

S103、将生成的所述虚拟机参数对应的元数据进行汇总，并发送至Libvirt程序；

S104、基于所述Libvirt程序将每个所述元数据对应的所述虚拟机参数写入到待创建的虚拟机的xml定义文件中。

具体的，在一实施例中，在步骤S101-步骤S104中，首先通过实例类型Flavor设置虚拟机(实例)的基础属性，在本申请中将所述基础属性称之为虚拟机配置参数，例如CPU线程数与USB、音频设备等硬件支持；在确定目标实例的基础属性以及自定义属性后，可以在OpenStack云计算服务中为这些属性配置对应的元数据，其中，元数据可以理解为为虚拟机提供硬件设备支持或其他配置的参数数据；随后，OpenStack云计算服务整合虚拟机元数据，并将整合后的元数据发送给Libvirt程序进行处理，将每一个元数据对应的设备硬件参数写入到虚拟机的xml定义文件中。其中，所述xml定义文件可指虚拟机的定义文件，用于定义虚拟机的属性，例如：内核、磁盘、网卡等，是创建虚拟机所必需的XML定义文件。

其中，所述OpenStack云计算服务是一个开源的云计算管理平台项目，为私有云和公有云提供可扩展的弹性的云计算服务，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台；所述虚拟机管理程序libvirt提供了一个方便的方式来管理虚拟机和其他虚拟化功能的软件的集合，是用于管理虚拟化平台的开源的API，后台程序和管理工具。

关键的，在本申请中，在基于所述Libvirt程序将每个所述元数据对应的所述虚拟机参数写入到待创建的虚拟机的xml定义文件中的过程中，根据系统环境设置相应的虚拟机显卡类型。具体的，参见说明书附图3，所述根据系统环境设置相应的虚拟机显卡类型，包括以下步骤：

S201、查看所述Libvirt程序的drvier.py源码，并获取系统的CPU架构参数；

S202、根据不同的虚拟化类型和CPU架构设置相应的虚拟机显卡类型；其中，若虚拟化类型为parallels，设置虚拟机显卡类型为vga；若CPU架构为ppc，设置虚拟机显卡类型为vga；若CPU架构为aarch64，设置虚拟机显卡类型为qxl；

S203、将所述虚拟机显卡类型对应的虚拟机参数一并写入到待创建的虚拟机的xml定义文件。

具体的，在一实施例中，在步骤S201-步骤S203中，首先程序会去获取系统的CPU架构，根据传入的虚拟机所属的系统镜像信息，提取镜像对应的CPU架构参数(hw_architecture)，其中，获取系统CPU架构的代码可以参见说明书附图4，在此不做赘述。

在获取到系统的CPU架构参数之后，就根据不同的虚拟化类型和CPU架构设置相应的虚拟机显卡类型，具体的，当CPU架构为aarch64，设置虚拟机显卡类型为qxl，而在虚拟化类型为parallels或者CPU架构为ppc时，设置虚拟机显卡类型为vga。其中，根据系统环境设置相应的虚拟机显卡类型的代码可以参见说明书附图5，在此不做赘述。其中，所述aarch64是一种CPU架构，是公版64位ARMv8以后所有的64位ARM架构，是当前国内市场中惯用的CPU架构；所述qxl是一种VGA兼容的半虚拟显卡，最适合安装在虚拟机中的guest驱动程序。而之所以这样修改源码，是由于目前在CPU架构为aarch64、虚拟机显卡类型为vga时，根据用户体验得到的结果是在使用桌面虚拟机的过程中经常出现卡顿、视频抖动、丢帧的问题，所以才在CPU架构为aarch64时，将相对应的虚拟机显卡类型修改为qxl，在CPU架构为aarch64与虚拟机显卡类型为qxl两者搭配的情况下，提升桌面虚拟机的操作体验，以降低画面丢帧、卡顿和撕裂的情况。

在根据不同的虚拟化类型和CPU架构设置相应的虚拟机显卡类型之后，将相应的设置参数以及其他虚拟机参数一并转换成XML定义文件，其中，可以通过libvirt程序调用的conf_to_xml函数进行转换。其中，将所述虚拟机显卡类型对应的虚拟机参数一并写入到待创建的虚拟机的xml定义文件的代码可以参见说明书附图6，在此不做赘述。

最后，在步骤S3中，当libvirt程序将对应虚拟机参数的元数据转为对应的xml定义文件之后，会驱动QEMU-KVM根据所述xml定义文件生成对应的虚拟机。所述QEMU-KVM是KVM与QEMU的结合，KVM负责CPU虚拟化以及内存虚拟化，QEMU模拟其它IO设备。其中，KVM是一种开源的系统虚拟机模块。由于在创建虚拟机的过程中，修改了源码，即将CPU为aarch64架构时，设置虚拟机显卡类型为qxl，所以最终创建的虚拟机是可以支持QXL显卡驱动的，从而使得桌面虚拟机的基础操作更加流畅，窗口在播放视频的情况下画面改善尤为明显，画面丢帧、卡顿和撕裂的情况显著减少，达到提升用户体验感的目的。

进一步的，为了验证最终创建的虚拟机是否真正的支持QXL显卡驱动，可以通过virsh dump命令查看虚拟机对应的xml定义文件，即可看到在video标签下的qxl的显卡配置，若type＝qxl，即说明所创建的虚拟机是支持QXL显卡驱动的，若type＝vga或者type＝virtio，则说明所创建的虚拟机是不支持QXL显卡驱动的。其中，查看创建的虚拟机对应的xml定义文件的代码可以参见说明书附图7，在此不做赘述。

可见，本申请提供的一种在aarch64架构下openstack虚拟机支持qxl显卡的方法，Openstack在创建虚拟机时，会根据系统环境去设置相应的虚拟机显卡类型，其中通过修改源码的方式，先去获取系统CPU架构，当CPU为aarch64架构时，设置虚拟机显卡类型为qxl，随后将类型参数传递给底层的QEMU程序，达到虚拟机支持QXL显卡驱动的目的。从而降低桌面虚拟机在使用过程中存在的卡顿、视频抖动、丢帧问题，提升用户体验感。

基于同一发明构思，本申请实施例中还提供了一种虚拟机分辨率调节装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述一种在aarch64架构下openstack虚拟机支持qxl显卡的方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

如说明书附图8所示，本申请实施例提供的一种在aarch64架构下openstack虚拟机支持qxl显卡的装置，所述装置包括：

创建模块801，用于基于OpenStack云计算服务创建虚拟机；

设置模块802，用于在基于OpenStack云计算服务创建虚拟机的过程中，根据系统环境设置相应的虚拟机显卡类型；其中，若所述系统环境下的CPU为aarch64架构，通过修改源码的方式将所述虚拟机显卡类型设置为qxl；

生成模块803，用于将设置的所述虚拟机显卡类型的参数传递至QEMU-KVM程序，以生成支持对应虚拟机显卡类型的虚拟机。

在一实施例中，所述创建模块801基于OpenStack云计算服务创建虚拟机，包括：

配置待创建虚拟机的虚拟机参数；

基于OpenStack云计算服务将所述虚拟机参数生成对应的元数据；

将生成的所述虚拟机参数对应的元数据进行汇总，并发送至Libvirt程序；

基于所述Libvirt程序将每个所述元数据对应的所述虚拟机参数写入到待创建的虚拟机的xml定义文件中。

在一实施例中，所述创建模块801通过实例类型Flavor设置待创建的虚拟机的虚拟机参数；所述虚拟机参数包括CPU线程数、USB支持和音频设备支持中的一种或多种。

在一实施例中，所述设置模块802在基于所述Libvirt程序将每个所述元数据对应的所述虚拟机参数写入到待创建的虚拟机的xml定义文件中的过程中，根据系统环境设置相应的虚拟机显卡类型。

在一实施例中，所述设置模块802根据系统环境设置相应的虚拟机显卡类型，包括：

查看所述Libvirt程序的drvier.py源码，并获取系统的CPU架构参数；

根据不同的虚拟化类型和CPU架构设置相应的虚拟机显卡类型；其中，若虚拟化类型为parallels，设置虚拟机显卡类型为vga；若CPU架构为ppc，设置虚拟机显卡类型为vga；若CPU架构为aarch64，设置虚拟机显卡类型为qxl；

将所述虚拟机显卡类型对应的虚拟机参数一并写入到待创建的虚拟机的xml定义文件。

在一实施例中，所述生成模块803通过驱动QEMU-KVM程序根据所述xml定义文件生成对应的虚拟机。

在一实施例中，所述装置还包括：

验证模块，用于通过virsh dump命令查看创建的虚拟机对应的xml定义文件，以验证创建的虚拟机是否支持qxl显卡。

本申请提供的一种在aarch64架构下openstack虚拟机支持qxl显卡的装置，通过创建模块基于OpenStack云计算服务创建虚拟机；通过设置模块在基于OpenStack云计算服务创建虚拟机的过程中，根据系统环境设置相应的虚拟机显卡类型；其中，若所述系统环境下的CPU为aarch64架构，通过修改源码的方式将所述虚拟机显卡类型设置为qxl；通过生成模块将设置的所述虚拟机显卡类型的参数传递至QEMU-KVM程序，以生成支持对应虚拟机显卡类型的虚拟机。从而使得虚拟桌面能够支持qxl显卡，相比virtio显卡，桌面中的基础操作更加流畅，窗口在播放视频的情况下画面改善尤为明显，画面丢帧、卡顿和撕裂的情况显著减少，提升用户体验感。

基于本发明的同一构思，说明书附图9所示，本申请实施例提供的一种电子设备900的结构，该电子设备900包括：至少一个处理器901，至少一个网络接口904或者其他用户接口903，存储器905，至少一个通信总线902。通信总线902用于实现这些组件之间的连接通信。该电子设备900可选的包含用户接口903，包括显示器(例如，触摸屏、LCD、CRT、全息成像(Holographic)或者投影(Projector)等)，键盘或者点击设备(例如，鼠标，轨迹球(trackball)，触感板或者触摸屏等)。

存储器905可以包括只读存储器和随机存取存储器，并向处理器901提供指令和数据。存储器905的一部分还可以包括非易失性随机存取存储器(NVRAM)。

在一些实施方式中，存储器905存储了如下的元素，可执行模块或者数据结构，或者他们的子集，或者他们的扩展集：

操作系统9051，包含各种系统程序，用于实现各种基础业务以及处理基于硬件的任务；

应用程序模块9052，包含各种应用程序，例如桌面(launcher)、媒体播放器(MediaPlayer)、浏览器(Browser)等，用于实现各种应用业务。

在本申请实施例中，通过调用存储器905存储的程序或指令，处理器901用于执行如一种在aarch64架构下openstack虚拟机支持qxl显卡的方法中的步骤，能够修改openstack的相关源码，使虚拟机支持qxl显卡驱动，提升桌面虚拟机的操作体验。

本申请还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如在aarch64架构下openstack虚拟机支持qxl显卡的方法中的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述在aarch64架构下openstack虚拟机支持qxl显卡的方法。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请提供的实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围。都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。