CN115390996B - Virtual machine migration method and device, computing equipment and storage medium - Google Patents
Virtual machine migration method and device, computing equipment and storage medium Download PDFInfo
- Publication number
- CN115390996B CN115390996B CN202211331634.6A CN202211331634A CN115390996B CN 115390996 B CN115390996 B CN 115390996B CN 202211331634 A CN202211331634 A CN 202211331634A CN 115390996 B CN115390996 B CN 115390996B
- Authority
- CN
- China
- Prior art keywords
- disk
- virtual machine
- file
- virtual
- format
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 230000005012 migration Effects 0.000 title claims abstract description 79
- 238000013508 migration Methods 0.000 title claims abstract description 79
- 238000000034 method Methods 0.000 title claims abstract description 66
- 238000005192 partition Methods 0.000 claims description 38
- 238000006243 chemical reaction Methods 0.000 claims description 9
- 230000008569 process Effects 0.000 abstract description 11
- 230000006870 function Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 7
- 238000004891 communication Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 241000282326 Felis catus Species 0.000 description 1
- 101100217298 Mus musculus Aspm gene Proteins 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000013496 data integrity verification Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
Abstract
The application discloses a virtual machine migration method and device, a computing device and a storage medium, wherein the method comprises the following steps: analyzing a virtual machine file derived by a source end to determine a virtual machine attribute, wherein the virtual machine file comprises a virtual disk file; converting the virtual disk file into an identifiable format of a target end and identifying the virtual disk file as a disk; identifying a disk format of the disk to determine a boot disk; and creating a virtual machine at the target end based on the starting disk and the virtual machine attribute so as to complete migration of the virtual machine. In this way, during the migration process of the virtual machine, each disk does not need to be mounted respectively to try whether the migration can be started normally or not and completed, and the adaptability of the migration method from the VMware platform to the open source KVM platform is improved.
Description
Technical Field
The application belongs to the technical field of cloud computing, and particularly relates to a virtual machine migration method and device, and computing equipment and a machine-readable storage medium applying the virtual machine migration method.
Background
Virtual machine migration refers to migrating a virtual machine from one computing resource or storage location to another computing resource or storage location. VMware is a common virtualization platform at present, and one requirement exists for migrating a virtual machine from the VMware platform to an open source KVM platform, so how to provide a virtual machine migration method with wider adaptability so as to meet the requirements of different scenes in the migration process becomes a problem to be solved urgently.
The information disclosed in this background section is only for enhancement of understanding of the general background of the application and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person of ordinary skill in the art.
Disclosure of Invention
The purpose of the present application is to provide a virtual machine migration method, which is used for solving the problem that the current method for migrating a virtual machine from a VMware platform to an open source KVM platform is more limited.
In order to achieve the above object, the present application provides a virtual machine migration method, including:
analyzing a virtual machine file derived by a source end to determine a virtual machine attribute, wherein the virtual machine file comprises a virtual disk file;
converting the virtual disk file into an identifiable format of a target end and identifying the virtual disk file as a disk;
identifying a disk format of the disk to determine a boot disk;
and creating a virtual machine at a target end based on the starting disk and the virtual machine attribute so as to complete migration of the virtual machine.
In one embodiment, the virtual machine file includes a virtual machine metadata file;
analyzing the virtual machine file of the importing target end to determine the attribute of the virtual machine, specifically comprising:
and analyzing the virtual machine metadata file in the virtual machine file to determine at least one of disk capacity, network card name, operating system type, CPU core number, core number of each physical CPU and memory size of the virtual machine.
In one embodiment, the converting the virtual disk file into the recognizable format of the target end and recognizing the virtual disk file as a disk specifically includes:
converting the virtual disk file into an identifiable format of the target end;
and mounting the converted virtual disk file to a system of a target end so as to identify the virtual disk file as a disk.
In one embodiment, identifying a disk format of the disk to determine a boot disk specifically includes:
when the disc format of the disc is inquired to be an MBR format, reading data of bytes at preset positions in the disc;
and determining whether the magnetic disk is a starting disk or not based on whether target data is included in the data of the preset position bytes.
In one embodiment, the determining the boot disk based on the disk format of the disk specifically includes:
identifying a file system type on the disk when the disk format of the disk is the GPT format, wherein the file system type comprises NTFS and non-NTFS;
and inquiring whether the disk comprises a boot mark or not based on the file system type calling instruction so as to determine whether the disk is a starting disk or not.
In an embodiment, when the disk format of the disk is queried to be the GPT format, the method further includes:
and checking whether the disk comprises a startup partition to determine whether the disk is a startup disk.
In an embodiment, creating a virtual machine at a target end based on the boot disk and the virtual machine attribute specifically includes:
judging whether the virtual machine is a Linux system or not based on the virtual machine attribute; if so, the first and second data are not identical,
judging whether the disk symbol of the disk in the partition file of the starting disk is UUID; if not, the method comprises the steps of,
and modifying the disk identifier of the disk in the partition file of the starting disk into a UUID so as to finish the system of the starting disk mounted to the target end.
In an embodiment, after creating a virtual machine at the target end based on the boot disk and the virtual machine attribute, the method further includes:
analyzing whether a virtual machine kernel is provided with a virtio driver or not; if not, the method comprises the steps of,
invoking an IDE driver to start the virtual machine so as to install a virtio driver in the virtual machine kernel.
The application also provides a virtual machine migration device, which comprises:
the analyzing module is used for analyzing the virtual machine file exported by the source end to determine the attribute of the virtual machine, wherein the virtual machine file comprises a virtual disk file;
the conversion module is used for converting the virtual disk file into an identifiable format of a target end and identifying the virtual disk file as a disk;
the identification module is used for identifying the disk format of the disk so as to determine a starting disk;
and the migration module is used for creating a virtual machine at the target end based on the starting disk and the virtual machine attribute so as to complete the migration of the virtual machine.
The present application also provides a computing device comprising:
at least one processor; and
a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the virtual machine migration method as described above.
The present application also provides a machine-readable storage medium storing executable instructions that, when executed, cause the machine to perform a virtual machine migration method as described above.
Compared with the prior art, according to the virtual machine migration method, the virtual machine attribute is determined by analyzing the virtual machine file exported by the source end, and the disk format of the corresponding disk is identified based on the virtual disk file in the virtual machine file, so that a specific starting disk is determined; therefore, in the migration process of the virtual machine, each disk does not need to be mounted respectively to try whether the migration can be started normally or not and completed, and the adaptability of a migration method from the VMware platform to the open source KVM platform is improved.
In another aspect, a method for determining a specific boot disk based on a disk format of a main stream disk is provided, so that wide adaptability of a virtual machine migration method is further ensured.
In another aspect, in a state that the virtual machine is not started, whether a suitable driver (for example, a virtio driver) is installed in the kernel of the virtual machine or not and whether a partition file under the linux system can correctly guide the system to start or not can be judged, so that the efficiency and the reliability of the migration service of the virtual machine are improved.
Drawings
FIG. 1 is a schematic diagram of the architecture of a VM service;
FIG. 2 is a layout architecture diagram of a VM resource pool;
FIG. 3 is a schematic view of an application scenario of a virtual machine migration method according to an embodiment of the present application;
FIG. 4 is a flow chart of a virtual machine migration method according to an embodiment of the present application;
FIG. 5 is a flow chart of a virtual machine migration method according to an embodiment of the present application, wherein the flow chart is used for determining whether a current disk is a boot disk based on a disk format;
FIG. 6 is a flow chart of a virtual machine migration method according to an embodiment of the present application, wherein the flow chart is used for determining whether a current disk is a boot disk based on a boot partition;
FIG. 7 is a flow chart of a virtual machine migration method according to another embodiment of the present application, wherein the determination of whether a current disk is a boot disk is based on a boot partition;
FIG. 8 is a flow chart of a virtual machine migration method according to another embodiment of the present application, wherein the determination of whether a current disk is a boot disk is based on a boot partition;
FIG. 9 is a block diagram of a virtual machine migration apparatus according to one embodiment of the present application;
FIG. 10 is a hardware architecture diagram of a computing device according to an embodiment of the present application.
Detailed Description
The present application will be described in detail with reference to the embodiments shown in the drawings. The embodiments are not intended to be limiting and structural, methodological, or functional changes made by those of ordinary skill in the art in light of the embodiments are intended to be included within the scope of the present application.
Referring to fig. 1, a Virtual Machine (VM) service may be a service that virtualizes a Virtual Machine resource pool on a plurality of physical hosts through a virtualization technology to provide a user with a VM for use as needed. A VM is a virtual computer that is modeled, i.e., a computer that is logically.
With reference to fig. 2, the virtual machine service may be implemented as follows: an operating system is installed on the hardware resources of each of the plurality of physical hosts, and a virtualization software-Hypervisor (Hypervisor), e.g., VMware, KVM, xen, virtual Box, etc., is installed on top of the operating system, thereby building a VM resource pool on top of the plurality of physical hosts. In addition, the Hypervisor may partition resources from the virtual machine resource pool to generate virtual machines, providing virtual machines for users to use on demand. In order to better manage the virtual machine, a cloud management platform (for example, openstack) may be additionally provided to manage the virtual machine.
The virtual machine resource pool occupied by the virtual machine service is constructed on the basis of a plurality of physical hosts. The cloud platform may isolate resources from the virtual machine resource pool according to the needs of the user to provide the virtual machine for use by the user. Thus, the resources actually occupied by the virtual machine may be any one or more of the plurality of physical hosts.
Migration of virtual machines between different platforms requires the aid of software tools. Taking virt-V2V as an example, the virtual machine on the external virtualization platform can be converted to a running KVM platform, and the virtual machine of Windows and Linux on VMware, xen running Hyper-V and other virtual machine management programs can be read and converted into a plurality of modes of libvirt, openStack, oVirt management of KVM, red cap virtualization (RHV) and the like. However, virt-v2v currently only supports AMD 64 and Intel 64 architectures, also known as x86_64, v2v conversion does not support all other architectures including IBM Z, IBM POWER, and 64-bit ARM, etc.; moreover, virt-v2v requires operating system versions, and the migrated virtual machines and physical machines currently only support part of the operating system.
For at least the above reasons, it is desirable to provide a virtual machine migration method by which a virtual machine on a VMware platform can be migrated to a KVM platform quickly and smoothly, and without concern about which version the virtual machine on the VMware is, what operating system version the KVM platform of the migration target is; and, the method can support various architectures such as x86 platform, IBM Z, IBM POWER, and 64-bit ARM.
Referring to fig. 3, in an exemplary application scenario of the virtual machine migration method of the present application, the virtual machine includes a virtual machine, a source physical machine (source end), a server, and a target physical machine (target end). The server performs network communication with the virtual machine, the source physical machine and the target physical machine respectively.
It should be noted that the physical machine provides hardware conditions for the operation of the virtual machine. The source physical machine is the physical machine on which the virtual machine is currently running. The target physical machine is the physical machine to which the virtual machine is to be migrated. The server is used for realizing various processes in the migration process.
The functions of a server may be implemented by a server or a cluster of servers. When the functions of a server are commonly implemented by multiple server clusters, different servers may be used to implement different functions in the server. For example, the parsing of the virtual machine file and the conversion of the virtual disk file may be implemented by different servers. The embodiments of the present application are only for explaining virtual machine migration methods in principle, and are therefore collectively described as servers.
Referring to fig. 4, a specific embodiment of the virtual machine migration method of the present application is described. In this embodiment, the method includes:
s11, analyzing the virtual machine file exported by the source end to determine the virtual machine attribute.
The virtual machine to be migrated at the source end can be exported by calling a management platform (vcenter/EXSI) of VMware, and further the exported virtual machine file is obtained. The virtual machine files may include virtual disk files, virtual machine BIOS or EFI configuration files, virtual machine metadata files, file integrity check files, and the like. Wherein, the virtual disk file can be a vmdk format file and one or more virtual disk files can be provided; the virtual machine BIOS or EFI configuration file may be nvram format file; the virtual machine metadata file may be a ovf format file; the file integrity check file may be an mf format file.
In this embodiment, by parsing the virtual machine metadata file in the virtual machine file, a specific virtual machine attribute may be determined. The virtual machine attributes herein may include at least one of disk capacity, network card name, operating system type, CPU core number, core number per physical CPU, BIOS mode, and memory size.
An exemplary list of virtual machine attributes is shown in table (1).
Watch (1)
S12, converting the virtual disk file into an identifiable format of a target end, and identifying the virtual disk file as a disk.
In this embodiment, before the format conversion of the virtual disk file is performed, the data integrity verification may also be performed on the virtual disk file. Specifically, the integrity of the virtual disk file may be verified by checking the SHA values (e.g., SHA 256) of the virtual disk file and the virtual machine metadata file stored in the file integrity check file.
SHA stands for secure hash algorithm, a set of cryptographic hash functions published by the National Institute of Standards and Technology (NIST), including SHA-0, sha1, SHA2, and other versions. In general, SHA1 is a 160-bit hash function, similar to the MD5 algorithm. SHA2 refers to two families of similar hash functions with different chunk sizes, one of which is SHA256, SHA256 hashes can be generated for any string or input value using a hash generator tool. Therefore, the file integrity check file in this embodiment may correspond to different SHA types according to the version difference under the specific scenario.
The virtual machine files, including virtual disk files, may be stored on the physical disk device in the form of files. For a virtual disk file, if the virtual disk file is designated as a single file when a virtual machine is newly built, the system only creates a vmdk format file, wherein the file comprises the partition information of the virtual machine disk and all data of the virtual machine disk; as data is written to the virtual disk, the virtual disk file will become larger, but only this one virtual disk file is always present. If one virtual disk file is designated to be created separately for each set capacity (for example, 2 GB) when a virtual machine is newly created, the total size of the virtual disk determines the number of virtual disk files; the system creates a < vmname >. Vmdk file and a plurality of < vmname > -s# #. Vmdk files (s# # is the disk file number), wherein the < vmname >. Vmdk files only comprise disk partition information, and the plurality of < vmname > -s# # # vmdk files store disk data information; as data is written to a virtual disk file, the virtual disk file will become larger until the file size is 2GB, and then new data will be written to the other numbered disk files.
It should be noted that, the disks mentioned in the embodiments of the present application may correspond to the virtual disk files herein, respectively. For example, the virtual machine file includes 5 virtual disk files (vmdk format files), and then the virtual machine is represented as corresponding to 5 disks. And, whether the number of disks is variable with the capacity of the disks does not correlate.
Since VMware virtual machines default to disk files in vmdk format, which cannot be recognized by KVM, it is necessary to convert the virtual disk files into a format recognizable by KVM, such as qcow2 or raw format. And then, the converted virtual disk file is mounted to a system of the target end so as to be identified as a disk.
The converted virtual disk file can be regarded as a virtual machine mirror image, and can be divided into two modes according to different data storage modes: full mirror Mode (Flat Mode) and sparse Mode (SparseMode). The full mirror mode (e.g., raw format) holds all bytes of data in virtual disk, which also includes data that is invalid to the user. Sparse mode (e.g., qcow2 format) only holds data that is valid for the user and file system, only occupies the necessary storage space, and image files of this mode may not use contiguous physical disk space when storing data.
Illustratively, converting the virtual disk file to qcow2 format may be accomplished by invoking the following commands:
qemu-img convert -O qcow2 CentOS7.vmdk /var/lib/libvirt/images/CentOS7.qcow2.
with reference to fig. 5, when the converted virtual disk file is mounted to the system of the target end, the method may be implemented by calling Qemu-nbd (Qemu Network Block Device ), which may mount the Qemu virtual machine image on Linux. nbd can use the disk space of a remote host as a block device and mount to the system in an nbd fashion, and can operate the mounted identified disk like a local storage block device, which is directly connected locally, like via SCSI or SATA lines, at the sense level.
Exemplarily, the invoking of the Qemu-nbd mount virtual machine disk file may be accomplished by invoking the following commands:
# modprobe nbd max_part=16
# qemu-nbd --connect=/dev/nbd4 vm-258-disk-0.qcow2.
the first row command may load the nbd module, and the second row command may map the virtual machine disk file to the local.
In some alternative embodiments, the converted virtual machine disk file may also be mounted to the target system through loop, and identified as a disk.
Also exemplary, mounting a virtual machine disk file through a loop may be accomplished by invoking the following commands:
# 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.
the first row command is used for mounting the virtual machine file, and the other row commands are used for identifying the partition.
S13, identifying the disk format of the disk to determine the starting disk.
The disk format of a disk may be queried by invoking the following commands:
# fdisk -lu /dev/nbd4.
the specific disk format can be determined according to the difference of the obtained Disklabel types. When the Disklabel type is 'dos', the disk format of the representing queried disk is MBR; when Disklabel type is "GPT", the disk format representing the queried disk is GPT.
The MBR (Master Boot Record ), also called master boot sector, is the first sector that must be read when accessing a disk after power-on, and its three-dimensional address on the disk is (cylinder, head, sector) = (0, 1). This sector contains installed operating system information and is used to boot the system with a small piece of code. For example, windows is installed, and its start-up information is placed in this code, so that Windows cannot be started up normally if the MBR information is damaged or deleted by mistake. MBR in Linux systems will typically be a GRUB (GRand Unified Bootloader, multiple boot manager) loader. In a typical MBR boot process, the BIOS system is first started-the BIOS loads the MBR-the MBR, and finally Windows is restarted.
GPT (GUID Partition Table), globally unique identifying a disk partition table, is another more advanced and novel way of organizing disks, which uses UEFI to boot. Originally for better compatibility, more compatibility was used extensively later because of its larger support memory (MBR partitions support 2T disks at most). GPT no longer has the notion of partitioning (there could theoretically be an infinite number of partitions), and all disks are stored in a piece of information.
With continued reference to fig. 5, according to the different disk formats of the queried disk, the embodiment of the present application determines the boot disk in different manners.
(1) The disk format of the queried disk is MBR format
In this case, it is possible to read data of a preset position byte in the disk and determine whether the disk is a startup disk based on whether target data is included in the data of the preset position byte.
For example, the first 512 bytes of data in the disk may be read, and if aa55 appears therein, this represents that the disk is a boot disk.
The above data may be read by calling the following commands, for example:
# hexdump -n 512 /dev/nbd4.
(2) the disk format of the queried disk is GPT format
In this case, the file system type on the disk may be further identified, and whether the disk includes a boot flag may be queried based on the file system type call instruction to determine whether the disk is a boot disk.
In this embodiment, attention is paid to whether the file system type is NTFS, that is, the result of identifying the file system type on the disk includes both NTFS and non-NTFS types. Under the file system types of the two classifications, different commands can be called to inquire whether the disk comprises a boot mark or not; if a boot flag is included, the disk may be determined to be a boot disk.
Illustratively, the following commands may be invoked to identify the file system type on disk:
# lsblk -f /dev/nbd1.
the following commands may be invoked to query whether an NTFS type disk includes a boot flag:
# parted -l.
and, the following commands may be invoked to query whether a disk of a non-NTFS type includes a boot flag:
# fdisk -lu /dev/nbd3.
in some cases, when the format of the disk is the GPT format, the disk may not be able to be queried to include the boot tag by the command described above. The embodiment proposes that whether the disk is a boot disk can be further confirmed by checking whether the disk has a boot partition.
Specifically, if the operating system is linux, checking whether a/boot partition exists; if the operating system is Windows, then see if there is/Windows/Boot.
For linux, the boot partition is a kernel of the operating system and a file used in the booting process, and is generally a region required to be divided by an earlier version, and the size of the partition is about 100MB, but in some current versions, separate division of the partition may not be required. similarly,/Windows/Boot is the partition used to Boot Windows, which typically contains the Boot files for the operating system under the root directory of the partition. It can be seen that, particularly in the linux system, whether the disk is a boot disk in the system with different versions can be more reliably identified in the above manner.
In different embodiments of the present application, the above step of determining whether the disk is started may be to adjust the disk specifically according to the characteristics of different application scenarios.
With reference to fig. 6, in an embodiment, after a disk format of a disk is queried to be in GPT format, if a boot flag is not queried, then whether there is a boot partition on the disk may be checked.
In another embodiment, referring to fig. 7, after a disk format of one disk is queried to be a GPT format, if a boot tag is not queried, then a next disk format may be queried, and whether the next disk includes the boot tag may be queried until all the disks are queried. If the boot disk is still not determined, whether the boot partition exists in the queried disk in the GPT format can be checked one by one.
In another embodiment, referring to fig. 8, after a disk is queried to be in GPT format, whether there is a boot partition can be directly checked.
S14, creating a virtual machine at a target end based on the starting disk and the virtual machine attribute so as to complete migration of the virtual machine.
In this process, it is first determined whether the virtual machine is a linux system based on the virtual machine attribute (operating system type). If the system is a linux system, whether the starting disk mounted on the target end system can guide the starting of the system can be further judged.
Illustratively, in a conventional operating system boot flow, it includes: detect BIOS-detect MBR-load the GRUB of the boot disk (system disk) -load the partition according to partition file/etc/fstab-mount the partition-boot service. After the disk is mounted, the mounting information is written into the partition file of the/etc/fstab, otherwise, the disk still needs to be mounted again when being started next time. When the system is started, the content in the/etc/fstab can be actively read, and the disk is mounted according to the configuration in the system.
In some version systems fstab will be defined by default as drive/dev/sda. In a scenario with multiple hard disk slots, the relative position of the hard disk may change, and the use of the/dev/sda to mount the disk may cause errors in reading the fstab file during startup due to the sequential change of the disk, so that the server cannot be restarted normally. For example, if the KVM uses the virtual-blk drive, sda becomes vda after the virtual machine is started, which results in failure to mount the partition. It can be seen that the system is forcibly started by directly using the mounted boot disk, and the possibility that the virtual machine migration is unsuccessful due to the start failure still exists.
In order to cope with the above challenges, in this embodiment, when the boot disk is mounted to the system of the target, it is further determined whether the disk identifier of the disk in the partition file of the boot disk is a UUID (Universally Unique Identifier, universal unique identifier), and if not, the disk identifier of the disk in the partition file of the boot disk is modified to be a UUID, so as to complete the system of the boot disk mounted to the target.
In one exemplary method for configuring a disk drive as a UUID, a blkid command may be invoked to view currently existing block device information, and a cat/etc/fstab command may be invoked to view block device information configured in a current/etc/fstab file; subsequently, it is checked whether the blkid command result matches the information in the/etc/fstab file, and then the unmatched configuration items are repaired in the/etc/fstab file.
In addition, the UUID may also be queried by invoking various commands or various paths, such as, for example, an lsblk command, a by-UUID path, a hwinfo command, a udevidm command, a tune2fs command, a dump 2fs command, etc., which will not be described in detail herein.
For the VMware platform, the default driver is a scsi driver, and the initiation cannot be directly performed by the scsi driver under the KVM platform. Therefore, after the boot disk is mounted to the system of the target side, it is also necessary to consider whether or not it can correctly boot the system after mounting. In particular, it is desirable to be able to complete the above-described determination process without the need to start the virtual machine.
In this embodiment, it is proposed that the virtual machine system can be correctly booted based on the virtio driver, otherwise, a corresponding operation is required, so that the virtio driver is installed in the virtual machine after migration. Correspondingly, whether the virtual machine kernel is provided with a virtio driver or not can be analyzed first; if yes, the virtual machine can be considered to be started normally, and the virtual machine can be started by directly calling a virtio driver; if not, the IDE driver may be invoked to launch the virtual machine to install the virtio driver in the virtual machine kernel.
The kernel is the most basic part of the operating system, is the first layer of software expansion based on hardware, provides the most basic functions of the operating system, and is also the basis for the operation of the operating system. The kernel may be responsible for managing the processes, memory, device drivers, files, and network systems of the system, determining the performance and stability of the system. In this embodiment, the virtual machine kernel may refer to a portion of the Guest OS kernel for managing a virtual machine.
In the above embodiment, the virtualization technology has been described that an operating system is installed on a physical host, and then Hypervisor virtualization software is installed on the operating system, so that several partitions can be virtualized on the physical host, and different operating systems can be installed respectively. The operating system installed on the physical Host is the Host OS, and the corresponding operating system installed on the virtual partition is the Guest OS.
In this embodiment, determining whether the virtual driver is installed in the kernel of the virtual machine may be based on different virtual machine operating system deployments. Specifically, if the virtual machine operating system is linux, it may directly parse whether the virtual io driver is loaded in the kernel configuration file config. If the virtual machine operating System is Windows, it can check if Windows\System32\drivers\has a file at the beginning of vio.
In one embodiment, the virtio driver may be any one of a virtio-blk driver and a virtio-scsi driver.
In the related art, virtio-blk is used as a paravirtualized driver, and can be applied to virtualized platforms such as XEN or KVM. Taking a virtualized platform of qemu-kvm architecture as an example, a virtual io-blk driver installed in a virtual machine is also called a front end (virtual io-blk front), and a qemu program for a virtual PCI device is called a back end (virtual io-blk back), and front and back end coordination is required to complete data transmission inside and outside the virtual machine.
The virtio-scsi is the basis for an alternative storage implementation of the KVM Virtualization storage stack that replaces the virtio-blk and improves its functionality. The virtio-SCSI has the advantage that it can handle hundreds of devices, whereas virtio-blk can only handle about 30 devices and deplete the PCI slot. virtio-SCSI improves storage scalability, allows multiple storage devices to be accessed through a single controller, and supports reuse of SCSI stacks of the guest operating system.
It should be noted that, in the above embodiment, it is described that whether the virtual machine can be started normally is determined by determining whether the virtual machine kernel is provided with the virtual io driver; and when the virtual machine kernel is not provided with the virtual io driver, the IDE driver can be temporarily called to start the virtual machine. In such an embodiment, before the determination process, a virtual machine may be created at the target end based on the virtual machine attribute, where if a virtual driver is already installed in the virtual machine kernel, it may be considered that the virtual machine has completed the migration service; if the virtual driver is not installed in the kernel of the virtual machine, the node which is installed after the virtual machine is started and the virtual driver is completed can be used as a completion node of the migration service of the virtual machine. Of course, the identification of the virtual machine migration service completion node should not be considered as limiting the features or scope included in the virtual machine migration method of the present application, but merely for the sake of more clearly describing the above embodiments.
Referring to fig. 9, a specific embodiment of the virtual machine migration apparatus of the present application is described. In the present embodiment, the virtual machine migration apparatus includes an analysis module 21, a conversion module 22, an identification module 23, and a migration module 24.
The parsing module 21 is configured to parse a virtual machine file derived from the source end to determine a virtual machine attribute, where the virtual machine file includes a virtual disk file; the conversion module 22 is configured to convert the virtual disk file into an identifiable format of the target end, and identify the virtual disk file as a disk; the identifying module 23 is configured to identify a disk format of the disk, so as to determine a startup disk; the migration module 24 is configured to create a virtual machine at the target end based on the boot disk and the virtual machine attribute, so as to complete migration of the virtual machine.
In one embodiment, the virtual machine file includes a virtual machine metadata file; the parsing module 21 is specifically configured to parse the virtual machine metadata file in the virtual machine file to determine at least one of a disk capacity, a network card name, an operating system type, a CPU core number, a core number of each physical CPU, a BIOS mode, and a memory size of the virtual machine.
In one embodiment, the conversion module 22 is specifically configured to convert the virtual disk file into an identifiable format of the target; and a system for mounting the converted virtual disk file to the target end so as to identify the virtual disk file as a disk.
In one embodiment, the identification module 23 is specifically configured to read data of a preset position byte in the disk when the disk format of the disk is the MBR format; and determining whether the disk is a startup disk based on whether target data is included in the data of the preset position byte.
In one embodiment, the identifying module 23 is specifically configured to identify a file system type on the disk when the disk format of the disk is queried to be in the GPT format, where the file system type includes NTFS and non-NTFS; and querying whether the disk comprises a boot flag based on the file system type call instruction to determine whether the disk is a boot disk.
In one embodiment, the identification module 23 is further configured to, when it is not queried that the disk includes a boot tag, check whether the disk includes a boot partition to determine whether the disk is a boot disk.
In one embodiment, the migration module 24 is specifically configured to determine whether the virtual machine is a Linux system based on the attribute of the virtual machine; if yes, judging whether the disk symbol of the disk in the partition file of the starting disk is UUID; if not, modifying the disk identifier of the disk in the partition file of the starting disk into UUID to finish the system of the starting disk mounted to the target end.
In one embodiment, the migration module 24 is further configured to analyze whether the virtual machine kernel is provided with a virtio driver after creating the virtual machine at the target end based on the boot disk and the virtual machine attribute; if not, invoking the IDE driver to start the virtual machine so as to install the virtio driver in the kernel of the virtual machine.
The virtual machine migration method according to the embodiment of the present specification is described above with reference to fig. 1 to 8. The details mentioned in the description of the method embodiment above are equally applicable to the virtual machine migration apparatus of the embodiment of the present specification. The above virtual machine migration apparatus may be implemented in hardware, or may be implemented in software, or a combination of hardware and software.
In one embodiment, the virtual machine migration apparatus provided in the present application may be implemented as a computer program, where the computer program may run on a computing device as shown in fig. 10, and a nonvolatile storage medium of the computing device may store respective program modules that make up the virtual machine migration apparatus, for example, the parsing module 21, the converting module 22, the identifying module 23, and the migration module 24 shown in fig. 9. The computer program comprising the program modules is configured to cause the computer device to perform the steps in the virtual machine migration method of the embodiments of the present application described in the present specification. For example, the computing device may parse the source-side derived virtual machine file to determine the virtual machine attribute through a parsing module 21 in the virtual machine migration apparatus as shown in fig. 9, where the virtual machine file includes a virtual disk file; converting the virtual disk file into an identifiable format of a target end through a conversion module 22, and identifying the virtual disk file as a disk; identifying a disk format of the disk by an identification module 23 to determine a boot disk; and creating a virtual machine at a target end based on the starting disk and the virtual machine attribute through a migration module 24 so as to complete the migration of the virtual machine.
Fig. 10 shows a hardware configuration diagram of a computing device according to an embodiment of the present specification. As shown in fig. 10, computing device 30 may include at least one processor 31, memory 32 (e.g., non-volatile memory), memory 33, and communication interface 34, and at least one processor 31, memory 32, memory 303, and communication interface 34 are connected together via an internal bus 35. The at least one processor 31 executes at least one computer readable instruction stored or encoded in the memory 32.
It should be appreciated that the computer-executable instructions stored in the memory 32, when executed, cause the at least one processor 31 to perform the various operations and functions described above in connection with fig. 1-8 in various embodiments of the present description.
In embodiments of the present description, computing device 30 may include, but is not limited to: personal computers, server computers, workstations, desktop computers, laptop computers, notebook computers, mobile computing devices, smart phones, tablet computers, cellular phones, personal Digital Assistants (PDAs), handsets, messaging devices, wearable computing devices, consumer electronic devices, and the like.
According to one embodiment, a program product, such as a machine-readable medium, is provided. The machine-readable medium may have instructions (i.e., elements described above implemented in software) that, when executed by a machine, cause the machine to perform the various operations and functions described above in connection with fig. 1-8 in various embodiments of the specification. In particular, a system or apparatus provided with a readable storage medium having stored thereon software program code implementing the functions of any of the above embodiments may be provided, and a computer or processor of the system or apparatus may be caused to read out and execute instructions stored in the readable storage medium.
In this case, the program code itself read from the readable medium may implement the functions of any of the above embodiments, and thus the machine-readable code and the readable storage medium storing the machine-readable code form part of the present specification.
Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-R, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs), magnetic tapes, nonvolatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer or cloud by a communications network.
It will be appreciated by those skilled in the art that various changes and modifications can be made to the embodiments disclosed above without departing from the spirit of the invention. Accordingly, the scope of protection of this specification should be limited by the attached claims.
It should be noted that not all the steps and units in the above flowcharts and the system configuration diagrams are necessary, and some steps or units may be omitted according to actual needs. The order of execution of the steps is not fixed and may be determined as desired. The apparatus structures described in the above embodiments may be physical structures or logical structures, that is, some units may be implemented by the same physical client, or some units may be implemented by multiple physical clients, or may be implemented jointly by some components in multiple independent devices.
In the above embodiments, the hardware units or modules may be implemented mechanically or electrically. For example, a hardware unit, module or processor may include permanently dedicated circuitry or logic (e.g., a dedicated processor, FPGA or ASIC) to perform the corresponding operations. The hardware unit or processor may also include programmable logic or circuitry (e.g., a general purpose processor or other programmable processor) that may be temporarily configured by software to perform the corresponding operations. The particular implementation (mechanical, or dedicated permanent, or temporarily set) may be determined based on cost and time considerations.
The detailed description set forth above in connection with the appended drawings describes exemplary embodiments, but does not represent all embodiments that may be implemented or fall within the scope of the claims. The term "exemplary" used throughout this specification means "serving as an example, instance, or illustration," and does not mean "preferred" or "advantageous over other embodiments. The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described embodiments.
The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (11)
1. A virtual machine migration method, the method comprising:
analyzing a virtual machine file derived by a source end to determine a virtual machine attribute, wherein the virtual machine file comprises a virtual disk file;
converting the virtual disk file into an identifiable format of a target end and identifying the virtual disk file as a disk;
inquiring and judging the disk format of the disk to determine a starting disk;
and creating a virtual machine at a target end based on the starting disk and the virtual machine attribute so as to complete migration of the virtual machine.
2. The virtual machine migration method of claim 1, wherein the virtual machine file comprises a virtual machine metadata file;
analyzing the virtual machine file of the importing target end to determine the attribute of the virtual machine, specifically comprising:
and analyzing the virtual machine metadata file in the virtual machine file to determine at least one of disk capacity, network card name, operating system type, CPU core number, core number of each physical CPU, BIOS mode and memory size of the virtual machine.
3. The virtual machine migration method according to claim 1, wherein the converting the virtual disk file into the recognizable format of the target end and recognizing the virtual disk file as a disk specifically includes:
converting the virtual disk file into an identifiable format of the target end;
and mounting the converted virtual disk file to a system of a target end so as to identify the virtual disk file as a disk.
4. The virtual machine migration method of claim 1, wherein querying and judging a disk format of the disk to determine a boot disk specifically comprises:
when the disc format of the disc is inquired to be an MBR format, reading data of bytes at preset positions in the disc;
and determining whether the magnetic disk is a starting disk or not based on whether target data is included in the data of the preset position bytes.
5. The virtual machine migration method of claim 1, wherein querying and judging a disk format of the disk, determining to start the disk, specifically comprises:
identifying a file system type on the disk when the disk format of the disk is the GPT format, wherein the file system type comprises NTFS and non-NTFS;
and inquiring whether the disk comprises a boot mark or not based on the file system type calling instruction so as to determine whether the disk is a starting disk or not.
6. The virtual machine migration method of claim 5, wherein when the disk is queried that the disk does not include a boot tag and the disk format of the disk is a GPT format, the method further comprises:
and checking whether the disk comprises a startup partition to determine whether the disk is a startup disk.
7. The virtual machine migration method according to claim 1, wherein creating a virtual machine at a target end based on the boot disk and the virtual machine attribute specifically includes:
judging whether the virtual machine is a Linux system or not based on the virtual machine attribute; if so, the first and second data are not identical,
judging whether the disk symbol of the disk in the partition file of the starting disk is UUID; if not, the method comprises the steps of,
and modifying the disk identifier of the disk in the partition file of the starting disk into a UUID so as to finish the system of the starting disk mounted to the target end.
8. The virtual machine migration method of claim 1, wherein after creating a virtual machine at a target end based on the boot disk and the virtual machine attribute, the method further comprises:
analyzing whether a virtual machine kernel is provided with a virtio driver or not; if not, the method comprises the steps of,
invoking an IDE driver to start the virtual machine so as to install a virtio driver in the virtual machine kernel.
9. A virtual machine migration apparatus, characterized in that the virtual machine migration apparatus comprises:
the analyzing module is used for analyzing the virtual machine file exported by the source end to determine the attribute of the virtual machine, wherein the virtual machine file comprises a virtual disk file;
the conversion module is used for converting the virtual disk file into an identifiable format of a target end and identifying the virtual disk file as a disk;
the identification module is used for inquiring and judging the disk format of the disk so as to determine the starting disk;
and the migration module is used for creating a virtual machine at the target end based on the starting disk and the virtual machine attribute so as to complete the migration of the virtual machine.
10. A computing device, comprising:
at least one processor; and
a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform the virtual machine migration method of any one of claims 1-8.
11. A machine readable storage medium storing executable instructions that when executed cause the machine to perform the virtual machine migration method of any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211331634.6A CN115390996B (en) | 2022-10-28 | 2022-10-28 | Virtual machine migration method and device, computing equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211331634.6A CN115390996B (en) | 2022-10-28 | 2022-10-28 | Virtual machine migration method and device, computing equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115390996A CN115390996A (en) | 2022-11-25 |
| CN115390996B true CN115390996B (en) | 2024-02-02 |
Family
ID=84115130
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211331634.6A Active CN115390996B (en) | 2022-10-28 | 2022-10-28 | Virtual machine migration method and device, computing equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115390996B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116301593B (en) * | 2023-02-09 | 2024-02-02 | 安超云软件有限公司 | Method and application for cross-cluster and cross-storage copy block data under cloud platform |
| CN116737324B (en) * | 2023-08-14 | 2023-11-03 | 无锡沐创集成电路设计有限公司 | Hot migration method, device, equipment and medium of hardware Virtio-net equipment |
| CN117112072B (en) * | 2023-10-25 | 2023-12-22 | 成都云祺科技有限公司 | Cross-platform virtual machine drive replacement method, system and storage medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106201653A (en) * | 2016-06-30 | 2016-12-07 | 国云科技股份有限公司 | A kind of method that vmware virtual machine turns kvm virtual machine |
| CN109522088A (en) * | 2018-09-30 | 2019-03-26 | 华为技术有限公司 | A kind of virtual machine migration method and device |
| CN113515344A (en) * | 2021-05-17 | 2021-10-19 | 中国工商银行股份有限公司 | Method and device for automatically migrating virtual machine across technical platforms |
| US11163614B1 (en) * | 2019-01-26 | 2021-11-02 | Evolute, Inc. | Systems and methods for migrating virtual machines to containers |
| CN113687837A (en) * | 2021-08-17 | 2021-11-23 | 锐捷网络股份有限公司 | Starting mode conversion method and system and virtual machine operation method |
| CN113835644A (en) * | 2021-11-26 | 2021-12-24 | 深圳市科力锐科技有限公司 | Complete machine migration method, device, equipment and storage medium |
-
2022
- 2022-10-28 CN CN202211331634.6A patent/CN115390996B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106201653A (en) * | 2016-06-30 | 2016-12-07 | 国云科技股份有限公司 | A kind of method that vmware virtual machine turns kvm virtual machine |
| CN109522088A (en) * | 2018-09-30 | 2019-03-26 | 华为技术有限公司 | A kind of virtual machine migration method and device |
| US11163614B1 (en) * | 2019-01-26 | 2021-11-02 | Evolute, Inc. | Systems and methods for migrating virtual machines to containers |
| CN113515344A (en) * | 2021-05-17 | 2021-10-19 | 中国工商银行股份有限公司 | Method and device for automatically migrating virtual machine across technical platforms |
| CN113687837A (en) * | 2021-08-17 | 2021-11-23 | 锐捷网络股份有限公司 | Starting mode conversion method and system and virtual machine operation method |
| CN113835644A (en) * | 2021-11-26 | 2021-12-24 | 深圳市科力锐科技有限公司 | Complete machine migration method, device, equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115390996A (en) | 2022-11-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN115390996B (en) | Virtual machine migration method and device, computing equipment and storage medium | |
| US10261800B2 (en) | Intelligent boot device selection and recovery | |
| US10073703B2 (en) | Booting an operating system of a system using a read ahead technique | |
| US10481984B1 (en) | Backup of virtual machines from storage snapshot | |
| JP5404783B2 (en) | System and method for booting a bootable virtual storage appliance on a virtualization server platform | |
| US8370835B2 (en) | Method for dynamically generating a configuration for a virtual machine with a virtual hard disk in an external storage device | |
| US9158561B2 (en) | Systems and methods for modifying an operating system for a virtual machine | |
| US8555017B2 (en) | In-place physical to virtual (P2V) migration of an existing operating system during installation of a new operating system | |
| CN111492347A (en) | System and method for updating containers | |
| KR20140018316A (en) | Virtual disk storage techniques | |
| US10664598B1 (en) | Firmware security patch deployment | |
| US20200341744A1 (en) | Fragmented firmware storage system and method therefor | |
| US10185573B2 (en) | Caching based operating system installation | |
| US11861349B2 (en) | Modular firmware updates in an information handling system | |
| CN114756290A (en) | Operating system installation method, device and readable storage medium | |
| US11418555B1 (en) | Systems and methods for streaming an application via object storage | |
| US11249767B2 (en) | Boot assist zero overhead flash extended file system | |
| US8612737B2 (en) | System and method for supporting multiple hardware platforms with a single disk image | |
| US10552376B1 (en) | Accessing files stored in a firmware volume from a pre-boot application | |
| US20230350755A1 (en) | Coordinated operating system rollback | |
| US20240036896A1 (en) | Generating installation images based upon dpu-specific capabilities | |
| US20220156052A1 (en) | Software packaging device and method for performing binary analysis, and recording medium on which program for performing the same is recorded | |
| CN117707431A (en) | BIOS-based software RAID data reading method and device | |
| CN115857968A (en) | Operating system installation method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |