CN115390996A - 虚拟机迁移方法和装置、计算设备和存储介质 - Google Patents

Abstract

本申请公开了一种虚拟机迁移方法和装置、计算设备和存储介质，该方法包括：解析源端导出的虚拟机文件以确定虚拟机属性，其中，该虚拟机文件包括虚拟磁盘文件；将虚拟磁盘文件转化为目标端的可识别格式，并识别为磁盘；识别磁盘的磁盘格式，以确定启动盘；基于启动盘和虚拟机属性在目标端创建虚拟机，以完成虚拟机的迁移。这样，虚拟机迁移过程中，不必分别挂载各个磁盘以尝试是否能够正常启以并完成迁移，提高了从VMware平台迁移到开源的KVM平台的迁移方法的适应性。

Description

虚拟机迁移方法和装置、计算设备和存储介质

技术领域

本申请属于云计算技术领域，具体涉及一种虚拟机迁移方法和装置、以及应用该虚拟机迁移方法的计算设备和机器可读存储介质。

背景技术

虚拟机迁移是指将虚拟机从一个计算资源或存储位置迁移到另一个计算资源或存储位置。VMware是目前常见的虚拟化平台，存在的一个需求是将虚拟机从VMware平台迁移到开源的KVM平台，而如何提供一种适应性较广的虚拟机迁移方法，以满足上述迁移过程中不同场景的需求，成为了一个亟待解决的问题。

公开于该背景技术部分的信息仅仅旨在增加对本申请的总体背景的理解，而不应当被视为承认或以任何形式暗示该信息构成已为本领域一般技术人员所公知的现有技术。

发明内容

本申请的目的在于提供一种虚拟机迁移方法，其用于解决当前将虚拟机从VMware平台迁移到开源的KVM平台的方法限制较多的问题。

为实现上述目的，本申请提供了一种虚拟机迁移方法，所述方法包括：

解析源端导出的虚拟机文件以确定虚拟机属性，其中，所述虚拟机文件包括虚拟磁盘文件；

将所述虚拟磁盘文件转化为目标端的可识别格式，并识别为磁盘；

识别所述磁盘的磁盘格式，以确定启动盘；

基于所述启动盘和所述虚拟机属性在目标端创建虚拟机，以完成所述虚拟机的迁移。

一实施例中，所述虚拟机文件包括虚拟机元数据文件；

解析导入目标端的虚拟机文件以确定虚拟机属性，具体包括：

解析所述虚拟机文件中的虚拟机元数据文件，以确定虚拟机的磁盘容量、网卡名称、操作***类型、CPU核数、每个物理CPU的核数、以及内存大小中的至少一个。

一实施例中，将所述虚拟磁盘文件转化为所述目标端的可识别格式，并识别为磁盘，具体包括：

将所述虚拟磁盘文件转化为所述目标端的可识别格式；

将转化后的所述虚拟磁盘文件挂载至目标端的***，以将其识别为磁盘。

一实施例中，识别所述磁盘的磁盘格式，以确定启动盘，具体包括：

查询到所述磁盘的磁盘格式为MBR格式时，读取所述磁盘中预设位置字节的数据；

基于所述预设位置字节的数据中是否包括目标数据，确定所述磁盘是否为启动盘。

一实施例中，基于所述磁盘的磁盘格式，确定启动盘，具体包括：

查询到所述磁盘的磁盘格式为GPT格式时，识别所述磁盘上的文件***类型，其中，所述文件***类型包括NTFS和非NTFS；

基于所述文件***类型调用指令查询所述磁盘是否包括boot标记，以确定所述磁盘是否为启动盘。

一实施例中，在查询到所述磁盘的磁盘格式为GPT格式时，所述方法还包括：

查看所述磁盘是否包括启动分区，以确定所述磁盘是否为启动盘。

一实施例中，基于所述启动盘和所述虚拟机属性在目标端创建虚拟机，具体包括：

基于所述虚拟机属性判断虚拟机是否为Linux***；若是，

判断所述启动盘的分区文件中磁盘的盘符是否为UUID；若否，

将所述启动盘的分区文件中磁盘的盘符修改为UUID，以完成所述启动盘挂载至目标端的***。

一实施例中，基于所述启动盘和所述虚拟机属性在目标端创建虚拟机后，所述方法还包括：

解析虚拟机内核是否安装有virtio驱动；若否，

调用IDE驱动启动所述虚拟机，以在所述虚拟机内核中安装virtio驱动。

本申请还提供一种虚拟机迁移装置，所述虚拟机迁移装置包括：

解析模块，用于解析源端导出的虚拟机文件以确定虚拟机属性，其中，所述虚拟机文件包括虚拟磁盘文件；

转化模块，用于将所述虚拟磁盘文件转化为目标端的可识别格式，并识别为磁盘；

识别模块，用于识别所述磁盘的磁盘格式，以确定启动盘；

迁移模块，用于基于所述启动盘和所述虚拟机属性在目标端创建虚拟机，以完成所述虚拟机的迁移。

本申请还提供一种计算设备，包括：

至少一个处理器；以及

存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如上所述的虚拟机迁移方法。

本申请还提供一种机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的虚拟机迁移方法。

与现有技术相比，根据本申请的虚拟机迁移方法，通过解析源端导出的虚拟机文件确定虚拟机属性，并以虚拟机文件中的虚拟磁盘文件为基础，识别对应磁盘的磁盘格式，从而确定具体的启动盘；由此，虚拟机迁移过程中，不必分别挂载各个磁盘以尝试是否能够正常启以并完成迁移，提高了从VMware平台迁移到开源的KVM平台的迁移方法的适应性。

在另一个方面，提出了可以基于主流磁盘的磁盘格式，确定具体启动盘的方法，进一步保障了虚拟机迁移方法的广泛适应性。

在另一个方面，可以在虚拟机未启动的状态下，判断虚拟机内核是否安装了合适的驱动（例如virtio驱动），以及判断linux***下分区文件是否能够正确引导***启动，提高了虚拟机迁移业务的效率和可靠性。

附图说明

图1是VM服务的结构示意图；

图2是VM资源池的布局架构图；

图3是根据本申请一实施例虚拟机迁移方法的应用场景示意图；

图4是根据本申请一实施例虚拟机迁移方法的流程图；

图5是根据本申请一实施例虚拟机迁移方法中，基于磁盘格式确定当前磁盘是否为启动盘的流程逻辑图；

图6是根据本申请一实施例虚拟机迁移方法中，基于启动分区确定当前磁盘是否为启动盘的流程逻辑图；

图7是根据本申请又一实施例虚拟机迁移方法中，基于启动分区确定当前磁盘是否为启动盘的流程逻辑图；

图8是根据本申请又一实施例虚拟机迁移方法中，基于启动分区确定当前磁盘是否为启动盘的流程逻辑图；

图9是根据本申请一实施例虚拟机迁移装置的模块图；

图10是根据本申请一实施例计算设备的硬件结构图。

具体实施方式

以下将结合附图所示的各实施方式对本申请进行详细描述。但该等实施方式并不限制本申请，本领域的普通技术人员根据该等实施方式所做出的结构、方法、或功能上的变换均包含在本申请的保护范围内。

参图1，虚拟机（Virtual Machine，VM）服务可以是通过虚拟化技术在多个物理主机上虚拟出虚拟机资源池以为用户按需提供VM进行使用的服务。VM是模拟出来的一台虚拟的计算机，也即逻辑上的一台计算机。

配合参图2，虚拟机服务可以是这样实现的：在多台物理主机中的每台物理主机的硬件资源上安装操作***，并在操作***之上安装虚拟化软件—超级监督者（Hypervisor），例如，VMware、KVM、Xen、Virtual Box等等，从而在上述多台物理主机的基础之上构建VM资源池。另外，Hypervisor可以从虚拟机资源池中分割资源以生成虚拟机，从而为用户按需提供虚拟机进行使用。为了更好地对虚拟机进行管理，还可以另外设置云管理平台（例如，openstack）对虚拟机进行管理。

虚拟机服务占用的虚拟机资源池是在多台物理主机的基础上构建的。云平台可以根据用户的需要从虚拟机资源池中隔离出资源以提供虚拟机给用户使用。因此，虚拟机实际占用的资源可以是多台物理主机中任意一台或者多台的资源。

虚拟机在不同平台之间的迁移需要借助软件工具。以virt-v2v为例，其可以将外部的虚拟化平台上的虚拟机转化到可以运行的KVM平台上，它可以读取在VMware、Xen运行Hyper-V和其它虚拟机管理程序上的 Windows和Linux的虚拟机，并将其转换为KVM的libvirt、OpenStack、oVirt管理、红帽虚拟化（RHV）等几种方式。但是，virt-v2v 目前仅支持 AMD 64 和 Intel 64 架构，也称为 x86_64，v2v 转换不支持所有其它架构，包括 IBMZ、IBM POWER以及64位ARM等；并且，virt-v2v对操作***版本有要求，迁移的虚拟机和物理机目前仅支持部分操作***。

至少基于以上原因，本申请期望提供一种虚拟机迁移方法，通过该方法可以快速平滑地将VMware平台上的虚拟机迁移至KVM平台上，并且不用关注VMware上的虚拟机是哪个版本、迁移目标的KVM平台是什么操作***版本；并且，该方法能够支持x86平台、IBM Z、IBM POWER、以及64位ARM等多种架构。

参图3，在本申请虚拟机迁移方法的一个示范性的应用场景中，包括虚拟机、源物理机（源端）、服务器和目标物理机（目标端）。服务器分别和虚拟机、源物理机以及目标物理机进行网络通信。

需要说明的是，物理机为虚拟机的运行提供硬件条件。源物理机是虚拟机当前所运行于的物理机。目标物理机是虚拟机将要迁移至的物理机。服务器用于实现迁移过程中各种处理。

服务器的功能可以由一个服务器或多个服务器集群来实现。当服务器的功能由多个服务器集群来共同实现时，不同的服务器可以用于实现服务器中不同的功能。例如，可以将虚拟机文件的解析和虚拟磁盘文件的转化分别通过不同的服务器来实现。本申请实施例仅为了从原理上说明虚拟机迁移方法，故以服务器进行统一表述。

参图4，介绍本申请虚拟机迁移方法的一具体实施例。在本实施例中，该方法包括：

S11、解析源端导出的虚拟机文件以确定虚拟机属性。

示范性地，可以通过调用VMware的管理平台（vcenter/EXSI）将源端需要迁移的虚拟机导出，进而得到导出的虚拟机文件。虚拟机文件可以包括虚拟磁盘文件、虚拟机 BIOS或 EFI 配置文件、虚拟机元数据文件、以及文件完整性校验文件等。其中，虚拟磁盘文件可以是vmdk格式文件，并可以有一个或多个；虚拟机 BIOS 或 EFI 配置文件可以是nvram格式文件；虚拟机元数据文件可以是ovf格式文件；文件完整性校验文件可以是mf格式文件。

本实施例中，通过解析虚拟机文件中的虚拟机元数据文件，可以确定具体的虚拟机属性。这里的虚拟机属性可以包括磁盘容量、网卡名称、操作***类型、CPU核数、每个物理CPU的核数、BIOS模式、以及内存大小中的至少一个。

示范性的一个虚拟机属性列表如表①所示。

表①

S12、将所述虚拟磁盘文件转化为目标端的可识别格式，并识别为磁盘。

本实施例中，在对虚拟磁盘文件进行格式转化前，还可以先对该虚拟磁盘文件进行数据完整性校验。具体地，可以通过文件完整性校验文件中保存的虚拟磁盘文件和虚拟机元数据文件的SHA值（例如SHA256），校验虚拟磁盘文件的完整性。

SHA代表安全哈希算法，是由美国国家标准技术研究院（NIST）发布的一组加密哈希函数，包括SHA-0，SHA1和SHA2等各种版本。总体而言，SHA 1是一个160位哈希函数，类似于MD5算法。SHA2指的是两个具有不同块大小的相似哈希函数的族，其中之一是SHA256，可以使用哈希生成器工具为任何字符串或输入值生成SHA256哈希。因此，本实施例中的文件完整性校验文件可以根据具体场景下版本的不同，对应不同的SHA类型。

包括虚拟磁盘文件在内的虚拟机文件可以是以文件的形式储存在物理磁盘设备上。对于虚拟磁盘文件而言，如果在新建虚拟机时指定虚拟磁盘文件为单独一个文件时，***将只创建一个vmdk格式文件，该文件包括了虚拟机磁盘分区信息，以及虚拟机磁盘的所有数据；随着数据写入虚拟磁盘，虚拟磁盘文件将变大，但始终只有这一个虚拟磁盘文件。而如果在新建虚拟机时指定为每设定容量（例如2GB）单独创建一个虚拟磁盘文件的话，虚拟磁盘总大小就决定了虚拟磁盘文件的数量；***将创建一个<vmname>.vmdk文件和多个<vmname>-s###.vmdk文件（s###为磁盘文件编号），其中<vmname>.vmdk文件只包括磁盘分区信息，多个<vmname>-s###.vmdk文件存储磁盘数据信息；随着数据写入某个虚拟磁盘文件，该虚拟磁盘文件将变大，直到文件大小为2GB， 然后新的数据将写入到其它编号的磁盘文件中。

需要说明的是，在本申请各实施例中提及的磁盘可以是分别地与这里的虚拟磁盘文件对应。例如，虚拟机文件中包括了5个虚拟磁盘文件（vmdk格式文件），则代表该虚拟机对应有5个磁盘。并且，磁盘的数量与磁盘的容量大小是否可变并不产生关联。

由于VMware虚拟机默认是vmdk格式的磁盘文件，而KVM无法识别该格式，因此需要将虚拟磁盘文件转换为KVM能识别的格式，例如qcow2或raw格式。随后，再将转化后的虚拟磁盘文件挂载至目标端的***，以将其识别为磁盘。

转化后的虚拟磁盘文件可以视为虚拟机镜像，按照数据存储方式的不同，可以分为两种模式：全镜像模式（Flat Mode）和稀疏模式（SparseMode）。全镜像模式（例如raw格式）保存了虚拟磁盘中的所有字节数据，其中也包括对用户而言无效的数据。稀疏模式（例如qcow2格式）只保存对用户和文件***有效的数据，只占用必要的存储空间，这种模式的镜像文件在存放数据时使用的可能不是连续的物理磁盘空间。

示范性地，以将虚拟磁盘文件转化为qcow2格式为例，可以是通过调用以下的命令完成：

qemu-img convert -O qcow2 CentOS7.vmdk /var/lib/libvirt/images/CentOS7.qcow2.

配合参图5，在将转化后的虚拟磁盘文件挂载至目标端的***时，可以是通过调用Qemu-nbd（Qemu Network Block Device，Qemu网络块设备）实施，其可以将qemu虚拟机镜像挂载到Linux上。nbd可以将一个远程主机的磁盘空间，当作一个块设备来使用，并且，以nbd方式挂载到***，可以像操作本地存储块设备一样操作挂载后识别的磁盘，在感知层面，该磁盘在本地类似通过SCSI或者SATA线被直接连接。

示范性地，调用Qemu-nbd挂载虚拟机磁盘文件可以是通过调用以下的命令完成：

# modprobe nbd max_part=16

# qemu-nbd --connect=/dev/nbd4 vm-258-disk-0.qcow2.

其中，上述的第一行命令可以加载nbd模块，第二行命令可以将虚拟机磁盘文件映射到本地。

一些替换的实施例中，也可以通过loop将转化后的虚拟机磁盘文件挂载至目标端的***，并同样识别为磁盘。

同样示范性地，通过loop挂载虚拟机磁盘文件可以是通过调用以下的命令完成：

# losetup /dev/loop18 CentOS7.9-X86_64.RAW

#kpartx -l CentOS7.9-X86_64.RAW

loop18p1 : 0 409600 /dev/loop18 2048

loop18p2 : 0 16365568 /dev/loop18 411648.

其中，上述第一行命令用于挂载虚拟机文件，其余行命令用于识别分区。

S13、识别所述磁盘的磁盘格式，以确定启动盘。

示范性地，磁盘的磁盘格式可以通过调用以下的命令查询：

# fdisk -lu /dev/nbd4.

根据得到的Disklabel type的不同，可以确定具体的磁盘格式。其中，当Disklabel type为“dos”时，代表查询到磁盘的磁盘格式为MBR；当Disklabel type为“gpt”时，代表查询到磁盘的磁盘格式为GPT。

MBR（Master Boot Record，主引导记录），又叫做主引导扇区，是开机后访问磁盘时所必须要读取的首个扇区，它在磁盘上的三维地址为（柱面，磁头，扇区）＝（0，0，1）。这个扇区包含了已安装的操作******信息，并用一小段代码来启动***。例如，安装了Windows，其启动信息就放在这一段代码中，如果MBR的信息损坏或误删就不能正常启动Windows。Linux***中MBR通常会是GRUB（GRand Unified Bootloader，多重启动管理器）加载器。一个典型的MBR启动过程中，会先启动BIOS***—BIOS加载MBR—MBR最后再启动Windows。

GPT（GUID Partition Table，全局唯一标识磁盘分区表）是另外一种更加先进新颖的磁盘组织方式，其使用UEFI启动。最初是为了更好的兼容性，后来因为其更大的支持内存（MBR分区最多支持2T的磁盘），更多的兼容而被广泛使用。GPT不再有分区的概念（理论可以有无限多的分区），所有磁盘都在一段信息中存储。

继续配合参图5，根据查询到的磁盘的磁盘格式的不同，本申请实施例通过不同的方式确定启动盘。

①查询到磁盘的磁盘格式为MBR格式

在这种情况下，可以读取磁盘中预设位置字节的数据，并基于该预设位置字节的数据中是否包括目标数据，确定该磁盘是否为启动盘。

例如，可以读取磁盘中前512个字节的数据，如果其中出现aa55，则代表该磁盘就是启动盘。

示范性地，可以通过调用以下命令读取上述数据：

# hexdump -n 512 /dev/nbd4.

②查询到磁盘的磁盘格式为GPT格式

在这种情况下，可以进一步识别磁盘上的文件***类型，并基于文件***类型调用指令查询磁盘是否包括boot标记，从而确定该磁盘是否为启动盘。

本实施例中，关注文件***类型是否为NTFS，也即，识别磁盘上的文件***类型的结果包括NTFS和非NTFS两类。在这两分类的文件***类型下，可以调用不同的命令查询磁盘是否包括boot标记；如果包括boot标记，可以确定该磁盘为启动盘。

示范性地，可以调用以下命令识别磁盘上的文件***类型：

# lsblk -f /dev/nbd1.

可以调用以下命令查询NTFS类型的磁盘是否包括boot标记：

# parted -l.

以及，可以调用以下命令查询非NTFS类型的磁盘是否包括boot标记：

# fdisk -lu /dev/nbd3.

在一些情况下，当磁盘的格式为GPT格式时，通过上述的命令可能并未能够查询到该磁盘包括boot标记。本实施例提出可以进一步地通过查看该磁盘是否有启动分区，以确认该磁盘是否为启动盘。

具体地，如果是操作***为linux，则查看是否有/boot分区；如果操作***为windows，则查看是否有/Windows/Boot。

对于linux而言，/boot分区就是操作***的内核及在引导过程中使用的文件，一般是较早的版本要求划分的一个区，大小为100MB左右，但现在的一些版本中可以不需要对这个分区进行单独划分。类似地，/Windows/Boot则是用于启动windows的分区，通常该分区的根目录下，包含操作***的启动文件。可以看出，特别是在linux***中，可以通过上述的方式，更为可靠地识别不同版本***下磁盘是否为启动盘。

在本申请不同的实施例中，以上确定磁盘是否启动盘的步骤可以是根据不同应用场景的特点，针对性地进行调整。

配合参图6，一实施例中，在查询到一个磁盘的磁盘格式为GPT格式后，并未查询到其中包括boot标记，则可以接着查看该磁盘上是否有启动分区。

配合参图7，又一实施例中，在查询到一个磁盘的磁盘格式为GPT格式后，并未查询到其中包括boot标记，则可以接着查询下一个磁盘的格式，并查询该下一个磁盘中是否包括boot标记，直至所有的磁盘查询完毕。至此，若仍然未确定启动盘，则可以在查询到的GPT格式的磁盘中，逐个查看其中是否有启动分区。

配合参图8，又一实施例中，在查询到一个磁盘的格式为GPT格式后，也可以直接查看其中是否有启动分区。

S14、基于所述启动盘和所述虚拟机属性在目标端创建虚拟机，以完成所述虚拟机的迁移。

在此过程中，首先基于虚拟机属性（操作***类型）判断虚拟机是否为linux***。如果是linux***，则可以进一步判断挂载在目标端***的启动盘是否能够引导***的启动。

示范性地，在一个常规的操作***的启动流程中，包括：检测BIOS—检测MBR—加载启动盘（***盘）的GRUB—根据分区文件/etc/fstab加载分区—挂载分区—启动服务。磁盘被挂载之后会将挂载信息写入/etc/fstab这个分区文件中，否则下次开机启动时仍然需要重新挂载。***启动时会主动读取/etc/fstab中的内容，根据其中的配置挂载磁盘。

在一些版本***中，fstab默认会定义为盘符/dev/sda。在有多个硬盘插槽的场景中，其中硬盘的相对位置可能会发生变化，而利用/dev/sda挂载磁盘，可能会由于磁盘顺序变化导致启动时读取fstab文件发生错误，从而无法正常重启服务器。例如，若KVM使用vitio-blk驱动，虚拟机启动后sda会变为vda，进而导致挂载分区的失败。可以看出，直接利用挂载的启动盘强行启动***，仍然存在启动失败导致虚拟机迁移不成功的可能。

为了应对以上挑战，本实施例中，在将启动盘挂载至目标端的***时，会进一步判断启动盘的分区文件中磁盘的盘符是否为UUID（Universally Unique Identifier，通用唯一识别码），若否，则将该启动盘的分区文件中磁盘的盘符修改为UUID，以完成启动盘挂载至目标端的***。

一个示范性的配置盘符为UUID的方法中，可以调用blkid命令查看当前存在的块设备信息，以及调用cat /etc/fstab命令查看当前/etc/fstab文件中已配置的块设备信息；随后，检查blkid命令结果与/etc/fstab文件中的信息是否匹配，然后在/etc/fstab文件中修复不匹配的配置项。

此外，UUID还可以通过调用多种命令或多种路径进行查询，例如lsblk 命令、by-uuid 路径、hwinfo 命令、udevadm 命令、tune2fs 命令、dumpe2fs 命令等，在此不再赘述。

对于VMware平台而言，其默认驱动为scsi驱动，在KVM平台下无法直接用scsi驱动进行启动。因此，在将启动盘挂载至目标端的***后，还需要考虑挂载后其是否能够正确地引导***。特别是，期望能够在不需要启动虚拟机的情况下，完成上述的判断过程。

本实施例中，提出认为基于virtio驱动可以正确地引导虚拟机***启动，反之，则需要相应的操作，使得virtio驱动安装在迁移后虚拟机中。对应地，可以首先解析虚拟机内核是否安装有virtio驱动；如果有，则认为虚拟机可以正常启动，并可以直接调用virtio驱动启动虚拟机；如果没有，则可以调用IDE驱动启动虚拟机，以在虚拟机内核中安装virtio驱动。

内核是操作***最基本的部分，是基于硬件的第一层软件扩充，提供操作***的最基本的功能，也是操作***工作的基础。内核可以负责管理***的进程、内存、设备驱动程序、文件和网络***，决定着***的性能和稳定性。本实施例中，虚拟机内核可以是指Guest OS内核中用于对虚拟机进行管理的部分。

在以上的实施例中，已经介绍了虚拟化技术就是在物理主机上安装操作***，然后在这个操作***上安装Hypervisor虚拟化软件，这样就可以在物理机上虚拟化出若干分区，可以分别安装不同的操作***。其中，在这个物理主机上安装的操作***即为Host OS，对应的安装在虚拟分区上的操作***即为Guest OS。

本实施例中，判断虚拟机内核中是否安装了virtio驱动可以是基于不同的虚拟机操作***展开。具体地，如果虚拟机操作***为linux，则可以直接解析内核配置文件config中是否加载了virtio驱动。如果虚拟机操作***为windows，则可以查看\Windows\System32\drivers\是否存在vio开头的文件。

一实施例中，virtio驱动可以是包括virtio-blk驱动和virtio-scsi驱动中的任意一种。

在相关技术中，virtio-blk作为一种半虚拟化驱动，可应用于在XEN或KVM等虚拟化平台。以qemu-kvm架构的虚拟化平台为例，在虚拟机中安装的virtio-blk驱动也被称为前端(virtio-blk frontend)，而用于虚拟PCI设备的qemu程序被称为后端(virtio-blkbackend)，需要前后端配合来完成虚拟机内外的数据传输。

virtio-scsi是替代virtio-blk并改进其功能的KVM Virtualization存储堆栈的替代存储实现的基础。virtio-SCSI的优势在于它能够处理数百个设备，而virtio-blk只能处理大约30个设备并耗尽PCI插槽。virtio-scsi提高了存储可扩展性，允许通过单个控制器访问多个存储设备，并支持重用客户操作***的SCSI堆栈。

需要说明的是，在以上的实施例中，介绍了通过判断虚拟机内核中是否安装virtio驱动判断虚拟机是否能够正常启动；并且，在虚拟机内核中未安装virtio驱动时，提出可以先临时调用IDE驱动启动虚拟机。在这样的实施例中，可以是在该判断过程之前，基于虚拟机属性在目标端创建虚拟机，此时，若虚拟机内核中已经安装了virtio驱动，则可以视为虚拟机已经完成迁移业务；而若虚拟机内核中未安装virtio驱动，则可以将虚拟机启动后并完成virtio驱动安装的节点，作为虚拟机迁移业务的完成节点。当然，虚拟机迁移业务完成节点的认定不应当视为对本申请虚拟机迁移方法所包括的特征或范围限制，而仅仅是为了更清楚地描述以上的实施例。

参图9，介绍本申请虚拟机迁移装置的一具体实施方式。在本实施方式中，该虚拟机迁移装置包括解析模块21、转化模块22、识别模块23、以及迁移模块24。

解析模块21用于解析源端导出的虚拟机文件以确定虚拟机属性，其中，虚拟机文件包括虚拟磁盘文件；转化模块22用于将虚拟磁盘文件转化为目标端的可识别格式，并识别为磁盘；识别模块23用于识别磁盘的磁盘格式，以确定启动盘；迁移模块24用于基于启动盘和虚拟机属性在目标端创建虚拟机，以完成虚拟机的迁移。

一实施例中，虚拟机文件包括虚拟机元数据文件；解析模块21具体用于解析虚拟机文件中的虚拟机元数据文件，以确定虚拟机的磁盘容量、网卡名称、操作***类型、CPU核数、每个物理CPU的核数、BIOS模式、以及内存大小中的至少一个。

一实施例中，转化模块22具体用于将虚拟磁盘文件转化为目标端的可识别格式；以及将转化后的虚拟磁盘文件挂载至目标端的***，以将其识别为磁盘。

一实施例中，识别模块23具体用于查询到磁盘的磁盘格式为MBR格式时，读取磁盘中预设位置字节的数据；以及基于预设位置字节的数据中是否包括目标数据，确定磁盘是否为启动盘。

一实施例中，识别模块23具体用于查询到磁盘的磁盘格式为GPT格式时，识别磁盘上的文件***类型，其中，文件***类型包括NTFS和非NTFS；以及基于文件***类型调用指令查询磁盘是否包括boot标记，以确定磁盘是否为启动盘。

一实施例中，识别模块23还用于在未查询到磁盘包括boot标记时，查看磁盘是否包括启动分区，以确定磁盘是否为启动盘。

一实施例中，迁移模块24具体用于基于虚拟机属性判断虚拟机是否为Linux***；若是，判断启动盘的分区文件中磁盘的盘符是否为UUID；若否，将启动盘的分区文件中磁盘的盘符修改为UUID，以完成启动盘挂载至目标端的***。

一实施例中，迁移模块24还用于在基于启动盘和虚拟机属性在目标端创建虚拟机后，解析虚拟机内核是否安装有virtio驱动；若否，调用IDE驱动启动虚拟机，以在虚拟机内核中安装virtio驱动。

如上参照图1到图8，对根据本说明书实施例虚拟机迁移方法进行了描述。在以上对方法实施例的描述中所提及的细节，同样适用于本说明书实施例的虚拟机迁移装置。上面的虚拟机迁移装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。

在一个实施例中，本申请提供的虚拟机迁移装置可以实现为一种计算机程序的形式，计算机程序可在如图10所示的计算设备上运行，计算设备的非易失性存储介质可存储组成该虚拟机迁移装置的各个程序模块，比如，图9所示的解析模块21、转化模块22、识别模块23以及迁移模块24。各个程序模块所组成的计算机程序用于使该计算机设备执行本说明书中描述的本申请各个实施例的虚拟机迁移方法中的步骤。例如，计算设备可以通过如图9所示的虚拟机迁移装置中的解析模块21解析源端导出的虚拟机文件以确定虚拟机属性，其中，所述虚拟机文件包括虚拟磁盘文件；通过转化模块22将所述虚拟磁盘文件转化为目标端的可识别格式，并识别为磁盘；通过识别模块23识别所述磁盘的磁盘格式，以确定启动盘；通过迁移模块24基于所述启动盘和所述虚拟机属性在目标端创建虚拟机，以完成所述虚拟机的迁移。

图10示出了根据本说明书的实施例的计算设备的硬件结构图。如图10所示，计算设备30可以包括至少一个处理器31、存储器32(例如非易失性存储器)、内存33和通信接口34，并且至少一个处理器31、存储器32、内存303和通信接口34经由内部总线35连接在一起。至少一个处理器31执行在存储器32中存储或编码的至少一个计算机可读指令。

应该理解，在存储器32中存储的计算机可执行指令当执行时使得至少一个处理器31进行本说明书的各个实施例中以上结合图1-8描述的各种操作和功能。

在本说明书的实施例中，计算设备30可以包括但不限于：个人计算机、服务器计算机、工作站、桌面型计算机、膝上型计算机、笔记本计算机、移动计算设备、智能电话、平板计算机、蜂窝电话、个人数字助理(PDA)、手持装置、消息收发设备、可佩戴计算设备、消费电子设备等等。

根据一个实施例，提供了一种比如机器可读介质的程序产品。机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本说明书的各个实施例中以上结合图1-8描述的各种操作和功能。具体地，可以提供配有可读存储介质的***或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该***或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。

在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本说明书的一部分。

可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。

本领域技术人员应当理解，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种变形和修改。因此，本说明书的保护范围应当由所附的权利要求书来限定。

需要说明的是，上述各流程和各***结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理客户实现，或者，有些单元可能分由多个物理客户实现，或者，可以由多个独立设备中的某些部件共同实现。

以上各实施例中，硬件单元或模块可以通过机械方式或电气方式实现。例如，一个硬件单元、模块或处理器可以包括永久性专用的电路或逻辑(如专门的处理器，FPGA或ASIC)来完成相应操作。硬件单元或处理器还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体的实现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。

上面结合附图阐述的具体实施方式描述了示例性实施例，但并不表示可以实现的或者落入权利要求书的保护范围的所有实施例。在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。

本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所对应的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (11)

1.一种虚拟机迁移方法，其特征在于，所述方法包括：

解析源端导出的虚拟机文件以确定虚拟机属性，其中，所述虚拟机文件包括虚拟磁盘文件；

将所述虚拟磁盘文件转化为目标端的可识别格式，并识别为磁盘；

识别所述磁盘的磁盘格式，以确定启动盘；

基于所述启动盘和所述虚拟机属性在目标端创建虚拟机，以完成所述虚拟机的迁移。

2.根据权利要求1所述的虚拟机迁移方法，其特征在于，所述虚拟机文件包括虚拟机元数据文件；

解析导入目标端的虚拟机文件以确定虚拟机属性，具体包括：

解析所述虚拟机文件中的虚拟机元数据文件，以确定虚拟机的磁盘容量、网卡名称、操作***类型、CPU核数、每个物理CPU的核数、BIOS模式、以及内存大小中的至少一个。

3.根据权利要求1所述的虚拟机迁移方法，其特征在于，将所述虚拟磁盘文件转化为所述目标端的可识别格式，并识别为磁盘，具体包括：

将所述虚拟磁盘文件转化为所述目标端的可识别格式；

将转化后的所述虚拟磁盘文件挂载至目标端的***，以将其识别为磁盘。

4.根据权利要求1所述的虚拟机迁移方法，其特征在于，识别所述磁盘的磁盘格式，以确定启动盘，具体包括：

查询到所述磁盘的磁盘格式为MBR格式时，读取所述磁盘中预设位置字节的数据；

基于所述预设位置字节的数据中是否包括目标数据，确定所述磁盘是否为启动盘。

5.根据权利要求1所述的虚拟机迁移方法，其特征在于，基于所述磁盘的磁盘格式，确定启动盘，具体包括：

查询到所述磁盘的磁盘格式为GPT格式时，识别所述磁盘上的文件***类型，其中，所述文件***类型包括NTFS和非NTFS；

基于所述文件***类型调用指令查询所述磁盘是否包括boot标记，以确定所述磁盘是否为启动盘。

6.根据权利要求5所述的虚拟机迁移方法，其特征在于，在查询到所述磁盘的磁盘格式为GPT格式时，所述方法还包括：

查看所述磁盘是否包括启动分区，以确定所述磁盘是否为启动盘。

7.根据权利要求1所述的虚拟机迁移方法，其特征在于，基于所述启动盘和所述虚拟机属性在目标端创建虚拟机，具体包括：

基于所述虚拟机属性判断虚拟机是否为Linux***；若是，

判断所述启动盘的分区文件中磁盘的盘符是否为UUID；若否，

将所述启动盘的分区文件中磁盘的盘符修改为UUID，以完成所述启动盘挂载至目标端的***。

8.根据权利要求1所述的虚拟机迁移方法，其特征在于，基于所述启动盘和所述虚拟机属性在目标端创建虚拟机后，所述方法还包括：

解析虚拟机内核是否安装有virtio驱动；若否，

调用IDE驱动启动所述虚拟机，以在所述虚拟机内核中安装virtio驱动。

9.一种虚拟机迁移装置，其特征在于，所述虚拟机迁移装置包括：

解析模块，用于解析源端导出的虚拟机文件以确定虚拟机属性，其中，所述虚拟机文件包括虚拟磁盘文件；

转化模块，用于将所述虚拟磁盘文件转化为目标端的可识别格式，并识别为磁盘；

识别模块，用于识别所述磁盘的磁盘格式，以确定启动盘；

迁移模块，用于基于所述启动盘和所述虚拟机属性在目标端创建虚拟机，以完成所述虚拟机的迁移。

10.一种计算设备，包括：

至少一个处理器；以及

存储器，所述存储器存储指令，当所述指令被所述至少一个处理器执行时，使得所述至少一个处理器执行如权利要求1至8中任一所述的虚拟机迁移方法。

11.一种机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如权利要求1至8中任一所述的虚拟机迁移方法。

Images