WO2025256256A1 - 镜像文件的导入方法、装置、设备、存储介质及产品 - Google Patents

镜像文件的导入方法、装置、设备、存储介质及产品

Info

Publication number
WO2025256256A1
WO2025256256A1 PCT/CN2025/088856 CN2025088856W WO2025256256A1 WO 2025256256 A1 WO2025256256 A1 WO 2025256256A1 CN 2025088856 W CN2025088856 W CN 2025088856W WO 2025256256 A1 WO2025256256 A1 WO 2025256256A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual machine
storage resource
image file
electronic device
storage
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.)
Pending
Application number
PCT/CN2025/088856
Other languages
English (en)
French (fr)
Inventor
苟陇辉
李力
曾君亮
孙自翔
唐千
向阳胜
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology (Shenzhen) Co Ltd
Original Assignee
Tencent Technology (Shenzhen) Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Tencent Technology (Shenzhen) Co Ltd filed Critical Tencent Technology (Shenzhen) Co Ltd
Publication of WO2025256256A1 publication Critical patent/WO2025256256A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/63—Image based installation; Cloning; Build to order
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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/45583—Memory management, e.g. access or allocation

Definitions

  • This application relates to the field of computer technology, specifically to a method, apparatus, device, storage medium, and product for importing image files.
  • Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to achieve data computation, storage, processing, and sharing.
  • WAN wide area network
  • LAN local area network
  • Cloud technology is often combined with virtual machine (VM) technology, enabling the simulation of a complete computer system through software, creating multiple independent and completely isolated computer environments on the same physical server.
  • VM virtual machine
  • users can typically customize virtual machine images, which are stored in image files using the International Organization for Standardization (ISO) format.
  • ISO International Organization for Standardization
  • hypervisor virtualization systems based on kernel-based virtual machines (KVM) and Quick EMUlator only support image files in formats such as qcow2, raw, and vhd, and do not directly support ISO format image files. This necessitates format conversion operations for users, making image file import cumbersome and inefficient.
  • KVM kernel-based virtual machines
  • Quick EMUlator only support image files in formats such as qcow2, raw, and vhd, and do not directly support ISO format image files. This necessitates format conversion operations for users, making image file import cumbersome and inefficient.
  • This application provides a method, apparatus, device, storage medium, and product for importing image files. It enables the import of image files in a specific format without performing format conversion, making the import operation simpler and improving the import efficiency of image files to a certain extent.
  • embodiments of this application provide a method for importing an image file, executed by a second electronic device, comprising:
  • the request to import the first image file into the first virtual machine is obtained.
  • the import request carries the identification information of the first virtual machine and the storage path information of the first image file.
  • a mount request is sent to the first electronic device, which instructs the first electronic device to download the first image file to the first storage resource based on the storage path information, and mount the first storage resource to the first virtual machine so that the first image file can be loaded and run by the first virtual machine.
  • embodiments of this application provide a method for importing an image file, executed by a first electronic device, including:
  • the first image file is downloaded to the first storage resource indicated by the storage resource identifier based on the storage path information, and the first storage resource is mounted to the first virtual machine;
  • the first image file is loaded and run by the first virtual machine, and the operating system carried in the first image file is installed in the second storage resource inside the first virtual machine.
  • the mount request is sent by the second electronic device to the first electronic device after the second electronic device responds to the import request to import the first image file into the first virtual machine, obtains the first storage resource matching the first image file based on the storage path information, mounts the first storage resource to the first electronic device running the first virtual machine.
  • embodiments of this application provide an apparatus for importing image files, including:
  • the acquisition unit is configured to acquire an import request that requests the import of a first image file into a first virtual machine, the import request carrying identification information of the first virtual machine and storage path information of the first image file; acquire a first storage resource matching the first image file based on the storage path information, and mount the first storage resource onto a first electronic device running the first virtual machine; and
  • the sending unit is configured to send a mount request to the first electronic device, the mount request being configured to instruct the first electronic device to download the first image file to the first storage resource based on the storage path information, and mount the first storage resource to the first virtual machine, so as to load and run the first image file through the first virtual machine.
  • embodiments of this application provide an apparatus for importing image files, including:
  • the receiving unit is configured to receive a mounting request from the second electronic device, wherein the mounting request carries the identification information of the first virtual machine, the storage resource identifier corresponding to the first storage resource, and the storage path information of the first image file;
  • the download unit is configured to, in response to the mount request, download the first image file to the first storage resource indicated by the storage resource identifier based on the storage path information, and mount the first storage resource to the first virtual machine;
  • the loading unit is used to load and run the first image file through the first virtual machine, and install the operating system carried in the first image file into the second storage resource inside the first virtual machine;
  • the mount request is sent by the second electronic device to the first electronic device after the second electronic device responds to the import request to import the first image file into the first virtual machine, obtains the first storage resource matching the first image file based on the storage path information, mounts the first storage resource to the first electronic device running the first virtual machine.
  • embodiments of this application provide an electronic device, which includes one or more processors; and a memory for storing one or more computer programs, which, when executed by the one or more processors, cause the electronic device to implement the image file import method of the first aspect or the second aspect described above.
  • embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the image file import method described in the first or second aspect.
  • embodiments of this application provide a computer program product, which includes a computer program or computer instructions.
  • the computer program or computer instructions When executed by a processor, they implement the image file import method as described in the first aspect or the second aspect.
  • Figure 1 is a schematic diagram of the architecture of an image file import system provided in an embodiment of this application.
  • FIG. 3 is a schematic diagram of a console user interface provided in an embodiment of this application.
  • Figure 4 is a schematic diagram of a user interface for inputting system information of an image file according to an embodiment of this application;
  • Figure 5 is a timing diagram illustrating the execution of the access layer module in the second electronic device provided in the embodiments of this application;
  • Figure 6 is a timing diagram of the mounting process performed by the first electronic device according to an embodiment of this application.
  • Figure 7 is a schematic diagram of a user interface for installing an operating system carried by a first image file according to an embodiment of this application;
  • Figure 8 is a schematic diagram of a user interface for loading a driver that carries a fourth storage resource, according to an embodiment of this application.
  • Figure 9 is a schematic diagram of an architecture for importing an image file into a first virtual machine according to an embodiment of this application.
  • Figure 10 is another flowchart illustrating a method for importing an image file according to an embodiment of this application.
  • Figure 11 is another timing diagram of the execution of an access layer module in a second electronic device provided in an embodiment of this application.
  • Figure 12 is a timing diagram of the first electronic device performing the unloading process according to an embodiment of this application.
  • Figure 13 is a schematic diagram of another architecture for importing an image file into a first virtual machine according to an embodiment of this application;
  • Figure 14 is a timing diagram illustrating the import of an image file into a first virtual machine according to an embodiment of this application.
  • Figure 15 is a schematic diagram of the structure of an image file import device provided in an embodiment of this application.
  • Figure 16 is a schematic diagram of another image file import device provided in an embodiment of this application.
  • Figure 17 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.
  • module refers to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof.
  • a processor or multiple processors or memory
  • each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.
  • this application provides a method for importing image files.
  • the device can download image files of a specific format to the mounted storage resources.
  • the storage resources can be mounted onto a running virtual machine, which then loads and runs the image file from the mounted storage resources.
  • this automated product-level solution can import image files of a specific format without format conversion or the use of third-party tools or platforms.
  • This makes importing image files more convenient, improves the import capability and efficiency of specific format image files, and particularly enhances the import capability and efficiency of ISO format image files in cloud environments. This facilitates the management and deployment of virtualized environments and, to some extent, meets the diverse needs of users of private clouds.
  • the image file import method proposed in this application involves cloud technology, cloud computing, cloud storage, and other technologies, wherein:
  • Cloud technology refers to a managed technology that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to achieve data computing, storage, processing, and sharing.
  • Cloud technology is a collective term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies applied to the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.
  • Cloud computing is a computing model that distributes computing tasks across a large pool of computers, enabling various application systems to access computing power, storage space, and information services as needed.
  • the network providing these resources is called the “cloud.” From the user's perspective, resources in the “cloud” appear infinitely scalable, readily available, on-demand, and expandable, with payment based on usage.
  • a cloud resource pool (referred to as a cloud platform) is established, generally known as an Infrastructure as a Service (IaaS) platform.
  • IaaS Infrastructure as a Service
  • the cloud resource pool mainly includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.
  • PaaS Platform as a Service
  • SaaS Software as a Service
  • PaaS is the platform on which software runs, such as databases and web containers.
  • SaaS refers to various types of business software, such as web portals and bulk SMS senders.
  • SaaS and PaaS are upper layers compared to IaaS.
  • Cloud storage is a new concept that extends and develops from the concept of cloud computing.
  • a distributed cloud storage system (hereinafter referred to as a storage system) refers to a storage system that uses cluster applications, grid technology and distributed storage file systems to bring together a large number of storage devices of various types in the network (storage devices are also called storage nodes) to work together through application software or application interfaces to provide data storage and business access functions to the outside world.
  • Logical volumes are created. During the creation of a logical volume, physical storage space is allocated to each logical volume. This physical storage space may consist of a single storage device or the disks of several storage devices. Clients store data on a logical volume, which means storing the data on the file system.
  • the file system divides the data into many parts, each part being an object. Each object contains not only the data but also additional information such as data identifiers.
  • the file system writes each object to the physical storage space of that logical volume, and it records the storage location information of each object. Therefore, when a client requests access to data, the file system can allow the client to access the data based on the storage location information of each object.
  • a storage system allocates physical storage space to a logical volume is as follows: the physical storage space is pre-divided into stripes according to the capacity estimate of the objects stored in the logical volume (this estimate often has a large margin relative to the actual capacity of the objects to be stored) and the grouping of Redundant Array of Independent Disks (RAID).
  • RAID Redundant Array of Independent Disks
  • FIG. 1 is a schematic diagram of the architecture of an image file import system provided in this application.
  • the image file import system includes a console device 101, a virtual machine platform device 102, and a virtual machine host device 103.
  • the console device 101 can be directly or indirectly connected to the virtual machine platform device 102 via wired or wireless means, and the virtual machine platform device 102 can also be directly or indirectly connected to the virtual machine host device 103 via wired or wireless means.
  • the number and form of the devices shown in Figure 1 are for illustrative purposes only and do not constitute a limitation on the embodiments of this application.
  • Figure 1 illustrates and explains the virtual machine host device 103 as an example of multiple devices.
  • the virtual machine platform device 102 and the virtual machine host device 103 can be the same electronic device.
  • a host device refers to an electronic device that runs virtual machines.
  • a virtual machine platform device 102 is connected to multiple virtual machine host devices 103, where the virtual machine host devices 103 are electronic devices that run virtual machines and can be called host devices.
  • the console device 101, the virtual machine platform device 102, and the virtual machine host device 103 are all electronic devices.
  • the console device 101 can be a terminal device, which may include, but is not limited to: smartphones (such as Android phones, iOS phones, etc.), tablet computers, portable personal computers, mobile internet devices (MIDs), intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, wearable devices, etc. This application embodiment does not limit this.
  • the console device 101, the virtual machine platform device 102, and the virtual machine host device 103 can be servers.
  • Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.
  • cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.
  • CDNs content delivery networks
  • Console device 101 can be an electronic device running a console program, which can be a platform for managing computing resources in cloud computing.
  • Console device 101 can display a user interface including information about various virtual machines, as shown in Figure 1. This user interface can include information such as virtual machine identifier, system architecture, and running status.
  • the user can select a first virtual machine (e.g., virtual machine A) as the virtual machine to import the image file through this user interface, and enter the storage path information of the desired image file format.
  • This triggers console device 101 to generate an import request to import the first image file into the first virtual machine based on the identifier information of the first virtual machine and the storage path information of the first image file.
  • console device 101 can send this import request to virtual machine platform device 102.
  • the virtual machine platform device 102 can receive an import request from the console device 101 to import the first image file into the first virtual machine.
  • This import request carries the identification information of the first virtual machine, such as virtual machine A mentioned above, and the storage path information of the first image file.
  • the virtual machine indicated by this identification information can run on the virtual machine host device 103.
  • the virtual machine platform device 102 can obtain a first storage resource matching the first image file based on the storage path information and mount the first storage resource to the virtual machine host device 103.
  • the virtual machine platform device 102 can further generate a mount request based on the identification information of the first virtual machine, the storage resource identifier corresponding to the first storage resource, and the storage path information of the first image file, and send the mount request to the virtual machine host device 103.
  • the virtual machine host device 103 can receive the mount request and, in response, download the first image file to the first storage resource indicated by the storage resource identifier based on the storage path information, and mount the first storage resource to the first virtual machine. Furthermore, the virtual machine host device 103 can load and run the first image file stored in the first storage resource through the virtual machine, installing the operating system carried in the first image file into the second storage resource inside the virtual machine. This completes the import of a specific format image file without format conversion or the use of third-party tools or platforms.
  • the identification information of the first image file, the first virtual machine, the storage resource identifier corresponding to the first storage resource, and the storage path information of the first image file can all be stored in the blockchain. This prevents the first image file, the identification information of the first virtual machine, the storage resource identifier corresponding to the first storage resource, and the storage path information of the first image file from being tampered with.
  • Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, it is a decentralized database, a chain of data blocks linked using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block.
  • Figure 2 is a flowchart illustrating an image file import method provided in this embodiment of the application.
  • This image file import method can be implemented through the interaction of a first electronic device and a second electronic device.
  • the first electronic device can be the virtual machine host device 103 shown in Figure 1
  • the second electronic device can be the virtual machine platform device 102 shown in Figure 1.
  • the image file import method can include the following steps S201-S205, wherein:
  • the second electronic device obtains an import request to import the first image file into the first virtual machine.
  • the import request carries the identification information of the first virtual machine and the storage path information of the first image file.
  • an image file also known as a virtual machine image file
  • This series of files can be, for example, an operating system, for users to download and use.
  • the first image file can refer to the disk image file used by the virtual machine, which carries the operating system required by the virtual machine and is typically used by users to create and manage virtual machine instances.
  • the first image file can also carry applications and data required by the virtual machine, which can be customized by the user.
  • the format of the first image file is a specific format because it is obtained by the user custom-installing the operating system on an image file of a specific format.
  • a specific format can be understood as a format not directly supported by the hypervisor virtualization systems of KVM and QEMU, such as qcow2, raw, vhd, etc., and this specific format can be, for example, ISO format.
  • the image file is in ISO format and is used by a virtual machine to install an operating system
  • the image file can also be called an ISO image, an ISO image operating system, a virtual machine image, etc. It is understood that although the names are different, they have the same meaning.
  • a user can upload the first image file to a pre-configured storage resource and obtain the storage path information returned by that resource.
  • the storage path information can be a Uniform Resource Locator (URL) link (i.e., a download link) provided by the object storage service.
  • the user can upload the first image file to a cloud object storage bucket, a container provided by the cloud computing service for storing and retrieving cloud data objects.
  • This bucket provides a web service interface based on Hypertext Transfer Protocol (HTTP)/Hypertext Transfer Protocol Secure (HTTPS).
  • HTTP Hypertext Transfer Protocol
  • HTTPS Hypertext Transfer Protocol Secure
  • users can also upload the first image file to an image storage repository and obtain the storage path information, i.e., the download link, returned by the image storage repository.
  • This image storage repository also known as an image file storage repository or image repository, can be used to store multiple image files. Users can store the first image file in a private image space to ensure the security of their private image.
  • the import request which imports the first image file into the first virtual machine, can be initiated by a user on a console device.
  • the import of the first image file is completed through the control of the console device, using an already created virtual machine.
  • This console device can be a device running a console program (referred to as the console).
  • the console is a platform provided by cloud environments (cloud technologies) for managing cloud computing resources, and it can provide a user interface similar to a web page or application. Users can interact with the provided user interface through the console device to create, configure, and manage virtual machines. Furthermore, users can also obtain the running status of each created virtual machine through this user interface.
  • FIG 3 is a schematic diagram of a console user interface provided in an embodiment of this application.
  • This user interface can be called a virtual machine management page.
  • the user interface can include information about multiple created virtual machines. For example, it can include user-operable controls such as refresh, create/register virtual machine, shut down, and suspend controls.
  • the virtual machine information can include the virtual machine's identification information, such as virtual machine A-virtual machine F; the virtual machine's system architecture, such as x86_64, arm64, etc.; the operating system running the virtual machine, such as CentOS, Linux, Kylin, Windows, etc.; the virtual machine's used space, such as 32GB, etc.; the electronic device identifier running the virtual machine, where the electronic device running the virtual machine can be called the host machine, and the electronic device identifier running the virtual machine can be, for example, host machine A-host machine D, etc.; and the running status of each virtual machine, such as mounting, mounted, executing xx task, shut down, etc.
  • the virtual machine's identification information such as virtual machine A-virtual machine F
  • the virtual machine's system architecture such as x86_64, arm64, etc.
  • the operating system running the virtual machine such as CentOS, Linux, Kylin, Windows, etc.
  • the virtual machine's used space such as 32GB, etc.
  • the user interface can also include controls for operating the created virtual machines, such as virtual machines A-virtual machine F, such as mount and unmount controls. It is understandable that mounting refers to attaching storage resources to a virtual machine, and unmounting refers to unloading the storage resources that are mounted on the virtual machine.
  • users can trigger an image file import request by targeting a mount control corresponding to a specific virtual machine. For example, if a user clicks the mount control corresponding to virtual machine D, the virtual machine indicated by virtual machine D becomes the first virtual machine.
  • the console device can output a user interface with multiple input controls. These controls allow the user to input system information of the image file to be imported; this system information can also be referred to as the parameter information of the ISO image.
  • the user's selection of a virtual machine on the virtual machine management page can be understood as a visual operation for mounting an image file to a virtual machine, specifically a visual operation for mounting an ISO format image file to a virtual machine.
  • Figure 4 is a schematic diagram of a user interface for inputting system information of an image file according to an embodiment of this application.
  • the user interface may include multiple input boxes and selection boxes, which serve as input controls for the user to input system information of the image file.
  • the system information of the image file may specifically include the identification information of the virtual machine, such as the virtual machine ID, for example, the virtual machine D selected by the user above.
  • the system information may also include the storage path information of the image file, such as the image file download link.
  • the system information may also include the system type corresponding to the image file, such as the image file system type, for example, CentOS, Kylin, etc.
  • the system information may also include the system architecture corresponding to the image file, such as the image file system architecture, such as x86_64, arm64, etc.
  • the system information may also include the system version corresponding to the image file, such as the image file system version, for example, 7.0, 10.0, etc.
  • the input syntax for the system information of the image file can be found in Table 1:
  • the console device triggers the console device to generate an import request to import the first image file into the first virtual machine based on the system information of the first image file to be imported.
  • the console device can then send this import request to an electronic device (the second electronic device) providing cloud computing management services in the cloud environment.
  • This import request can carry the identification information of the first virtual machine and the system information of the first image file.
  • the second electronic device can then receive the import request from the console device to import the first image file into the first virtual machine, and obtain the identification information of the first virtual machine and the system information of the first image file from the import request. This enables the transmission of system information, including the storage path information of the first image file.
  • the second electronic device can then store the system information of the first image file in a database for subsequent processing.
  • the second electronic device is an electronic device that provides cloud computing management services in a cloud environment.
  • This second electronic device may include an access layer module, which can run configured programs and provide an Application Programming Interface (API) for a console device to call.
  • the program code involved in the program and API runs on the second electronic device. That is, the console device can call the API provided by the access layer module in the second electronic device to select a virtual machine for importing the image file in a visual operation on the console device, and send an import request to the second electronic device to import the first image file into the first virtual machine.
  • the second electronic device can obtain the import request to import the first image file into the first virtual machine based on the HTTP service provided by the API.
  • This import request can be called a mount ISO image request
  • the API can be called a mount ISO image API
  • the system information of the image file carried in the import request can be called the parameters of the mount ISO image API.
  • the access layer module refers to the module in the second electronic device that runs the configuration program and provides the application programming interface (API) for the console device to call.
  • API application programming interface
  • the program code involved in this module runs on the second electronic device and is used to interact with the console device and complete operations such as parameter pass-through.
  • the second electronic device obtains the first storage resource that matches the first image file based on the storage path information, and mounts the first storage resource onto the first electronic device running the first virtual machine.
  • the first mirror file is the disk image file used by the virtual machine. It contains the operating system required by the virtual machine and is typically used by users to create and manage virtual machine instances. It is in a specific format (such as ISO), a format not directly supported by the hypervisor virtualization systems of KVM and QEMU. This first mirror file can also contain applications and data required by the virtual machine, which can be customized by the user.
  • the first storage resource can be a storage resource provided by a cloud computing service, such as a cloud disk provided by a cloud computing service, or a disk that can be used to store data, etc.
  • a cloud disk can refer to a cloud disk that matches the file size of the first image file.
  • the file size of the first image file is the same as the size of the first storage resource, or the file size of the first image file is slightly smaller than the size of the first storage resource (for example, the file size of the first image file is 80%-95% of the size of the first storage resource). That is, the size of the first storage resource depends on the size of the first image file (ISO format image file) to reduce resource waste while storing the first image file.
  • Mounting refers to the process by which an operating system makes computer files and directories on storage resources (such as hard drives, cloud drives, etc.) accessible to users through the file system of an electronic device.
  • storage resources such as hard drives, cloud drives, etc.
  • mounting typically means assigning a drive letter to a disk partition (including virtualized disk partitions).
  • mounting typically means attaching a storage device from an electronic device to an existing directory. Mounting a first storage resource to a first electronic device running a first virtual machine can be understood as connecting an external storage resource to the first electronic device; the file system of the first electronic device can then recognize this first storage resource and access the data stored within it.
  • the second electronic device can determine the file size of the first image file based on storage path information. It is understood that, since the storage path information of the first image file is a download link via HTTP, certain features of the HTTP protocol, such as HTTP HEAD requests, allow the second electronic device to obtain metadata about the first image file, including its file size, without downloading the first image file itself.
  • the second electronic device can allocate storage resources matching the size of the first image file from a preset storage resource, thus obtaining the first storage resource.
  • the preset storage resource can be the total storage resources provided by a cloud computing service; the storage resource matching the size of the first image file can be obtained from the preset storage resource.
  • the preset storage resource refers to the total storage resources provided by the cloud computing service, from which the second electronic device can allocate the first storage resource matching the size of the first image file.
  • the second electronic device may include a scheduling layer module.
  • This scheduling layer module can run a configured program, and the program code involved in this program also runs on the second electronic device.
  • This program can be used to call the API provided by the cloud disk service to create (request) storage resources and obtain the first storage resource.
  • the cloud disk service can be understood as providing a program that allocates storage resources from preset storage resources and can provide APIs for the scheduling layer to call.
  • the scheduling layer module and the access layer module can be referred to as the control modules in the second electronic device.
  • the scheduling layer module can communicate with the access layer module through a configured interface.
  • the access layer module After the access layer module receives an import request (i.e., an ISO image mount request) sent from the console device to import the first image file into the first virtual machine, the access layer module can transmit the import request (ISO image mount request) to the scheduling layer module. Then, in response to the import request, the scheduling layer module can obtain the file size of the first image file based on the storage path information carried in the import request, and, according to the file size of the first image file, call the API provided by the cloud disk service to create (request) storage resources matching the file size of the first image file, thus obtaining the first storage resource.
  • an import request i.e., an ISO image mount request
  • the scheduling layer module can obtain the file size of the first image file based on the storage path information carried in the import request, and, according to the file size of the first image file, call the API provided by the cloud disk service to create (request) storage resources matching the file size of the first image file, thus obtaining the first storage resource.
  • the scheduling layer module can mount the acquired first storage resource onto the electronic device running the first virtual machine.
  • the scheduling layer module can obtain the correspondence between virtual machine identification information and electronic device identification information, and then determine the target identification information corresponding to the representation information based on the correspondence and the identification information of the first virtual machine. That is, the scheduling layer module can obtain a correspondence table between each virtual machine and the electronic device running each virtual machine, and then query the ID of the electronic device where the first virtual machine is located based on the virtual machine ID of the first virtual machine, that is, the host machine ID where the first virtual machine is located. After the scheduling layer module finds the ID of the electronic device where the first virtual machine is located, it can mount the first storage resource onto the first electronic device indicated by the target identification information.
  • the target identification information refers to the identification information used to indicate the first electronic device running the first virtual machine, determined by the scheduling layer module based on the correspondence between virtual machine identification information and electronic device identification information, and the identification information of the first virtual machine.
  • the scheduling layer module can also maintain a database to store the running status of each virtual machine.
  • the running status of a virtual machine can be, for example, "mounting,” “mounted,” “executing task xx,” “shutdown,” etc.
  • This database can include the identification information of each virtual machine and its corresponding running status.
  • the scheduling layer module can interact in real time with the electronic devices (each host machine) running each virtual machine. After the host machine obtains the status of the running virtual machine, it can transmit it to the scheduling layer module, so that the scheduling layer module updates the status of each virtual machine stored in the database. It can be understood that, in the user interface displayed on the console device as shown in Figure 3, the data source for the running status of virtual machines A through F can be the running status of each virtual machine stored in the database maintained by this scheduling layer module.
  • the access layer module in the second electronic device can first obtain the current running state of the first virtual machine based on the identification information. Specifically, the access layer module can query the running state corresponding to the identification information in the database maintained by the scheduling layer module to obtain the current running state of the first virtual machine. Then, the access layer module can compare the current running state of the first virtual machine with the running states in a preset set of running states. If the current running state of the first virtual machine matches a running state in the preset set, the access layer module can obtain the system architecture information corresponding to the first virtual machine for further processing. In other words, the access layer module can only perform further verification if it verifies that the current running state of the first virtual machine matches a running state in the preset set of running states.
  • the preset running state set refers to a collection of running states, including shutdown and running tasks. Only virtual machines in these states can import image files. Virtual machines outside this set may encounter import errors due to running subtasks. This is because only virtual machines in shutdown or running states can import image files. Virtual machines in other states may be running subtasks, which can easily lead to import errors. Therefore, if the first virtual machine is found to be outside the preset running state set, it is determined that the first virtual machine cannot import the image file.
  • the access layer module can trigger an output to the user interface displayed on the console device to inform the user that the first virtual machine cannot import the image file, instructing the user to select another virtual machine for importing the image file.
  • the access layer module can obtain the system architecture information corresponding to the first virtual machine.
  • This system architecture information can be the system architecture information configured when the first virtual machine was created.
  • the configuration information of each virtual machine can also be stored in a database.
  • the access layer module can retrieve the configuration information of the first virtual machine from the database using its identifier.
  • This configuration information can include the system architecture information corresponding to the first virtual machine, such as x86_64 or arm64.
  • the access layer module can obtain the system information of the first image file carried in the import request. This system information includes the system architecture information corresponding to the first image file.
  • the first storage resource can be mounted onto the first electronic device, that is, the first storage resource is mounted onto the first electronic device through the scheduling layer module.
  • the access layer module can determine that the first virtual machine cannot import the image file.
  • the access layer module can also trigger the output of a prompt message in the user interface displayed on the console device, indicating to the user that the first virtual machine cannot import the image file, thus instructing the user to select another virtual machine as the virtual machine to import the image file.
  • the access layer module can send the import request to the scheduling layer module through the scheduling layer module, so that the scheduling layer module can obtain the first storage resource matching the first image file based on the storage path information, and mount the first storage resource to the first electronic device running the first virtual machine.
  • the access layer module after the access layer module receives an import request to import the first image file into the first virtual machine, it can transmit the import request to the scheduling layer module. This allows the scheduling layer module to obtain the first storage resource matching the first image file based on the storage path information of the first image file. Then, if the access layer module verifies that the running state of the first virtual machine is in the preset running state set and the system architecture information corresponding to the first virtual machine is the same as the system architecture information corresponding to the first image file, it can send an instruction to the scheduling layer module to instruct the scheduling layer module to mount the obtained first storage resource onto the first electronic device of the first virtual machine.
  • the access layer module in the second electronic device can update the running status of the first virtual machine to "mounting" after triggering the mounting of the first storage resource onto the first electronic device running the first virtual machine via the scheduling layer module.
  • This running status indicates that the first virtual machine is importing an ISO format image file.
  • the access layer module can update the running status of the first virtual machine in a database storing the running status of each virtual machine through the scheduling layer module. For example, it can update the running status corresponding to the identification information of the first virtual machine from "shutdown" to "mounting".
  • the access layer module can receive an import request to import a first image file into a first virtual machine.
  • This import request can carry system information corresponding to the first image file and identification information of the first virtual machine.
  • the access layer module can then obtain the current running state of the first virtual machine based on its identification information and verify whether the current running state is within a preset running state set, such as checking whether the first virtual machine is in a powered-off or running state.
  • the access layer module can obtain the system architecture information corresponding to the first virtual machine and verify whether the system architecture information corresponding to the first virtual machine is the same as the system architecture information corresponding to the first image file, i.e., checking whether the system architecture corresponding to the first virtual machine is consistent with the system architecture corresponding to the first image file. If the check result is still yes, the access layer module can update the running state of the first virtual machine to "mounting" and transmit the identifier of the first virtual machine and the system information of the first image file to the scheduling layer module.
  • the process ends and the access layer module does not perform further processing.
  • the process by which the access layer module transmits the identifier of the first virtual machine and the system information of the first image file to the scheduling layer module can be called the parameter pass-through process, in order to call the scheduling layer module for further processing, such as acquiring the first storage resource and mounting the first storage resource onto the first electronic device.
  • the second electronic device sends a mount request to the first electronic device.
  • the mount request is used to instruct the first electronic device to download the first image file to the first storage resource based on the storage path information, and mount the first storage resource to the first virtual machine so that the first image file can be loaded and run through the first virtual machine.
  • the second electronic device after the second electronic device mounts the first storage resource onto the first electronic device running the first virtual machine, it can send a mount request to the first electronic device.
  • the first electronic device can receive the mount request from the second electronic device.
  • This mount request can instruct the first electronic device to download the first image file to the first storage resource based on storage path information, and then mount the first storage resource containing the downloaded first image file onto the first virtual machine, so that the first virtual machine can load and run the first image file.
  • a mount request is a request sent by the second electronic device to the first electronic device after mounting the first storage resource onto the first electronic device running the first virtual machine.
  • the request instructs the first electronic device to download the first image file to the first storage resource based on the storage path information, and to mount the first storage resource with the downloaded first image file onto the first virtual machine so that the first image file can be loaded and run by the first virtual machine.
  • the request carries the identification information of the first virtual machine, the storage resource identifier corresponding to the first storage resource, and the storage path information of the first image file.
  • the mount request may carry the identification information of the first virtual machine, the storage resource identifier corresponding to the first storage resource, and the storage path information of the first image file.
  • the identification information of the first virtual machine is used to indicate a specific virtual machine running in the first electronic device, so that the virtual machine can be processed subsequently, such as mounting the first storage resource.
  • the first electronic device can check whether the first storage resource has been mounted based on the storage resource identifier corresponding to the first storage resource.
  • the first electronic device can obtain the first image file based on the storage path information of the first image file.
  • the first electronic device downloads the first image file to the first storage resource indicated by the storage resource identifier based on the storage path information, and mounts the first storage resource to the first virtual machine.
  • the first electronic device can download the first image file based on the storage path. For example, the first electronic device can download the first image file from the image storage repository based on a download link provided by the image storage repository. Furthermore, the first electronic device can identify one or more storage resources mounted on it, such as disks or cloud disks. The first electronic device can then determine whether it has identified the first storage resource obtained by the second electronic device (including the scheduling layer module) based on the storage resource identifier. If it has identified the first storage resource, it stores the downloaded first image file in that first storage resource. Specifically, the command executed by the first electronic device to download the first image file to the first storage resource based on the storage path information can be:
  • Linux command wget -o /path/to/cloud_disk (storage path information, download link)
  • wget can be used to download files from the network, and /path/to/cloud_disk is used to indicate that the first downloaded image file should be saved to a directory (such as cloud disk cloud_disk).
  • the storage path information is the URL corresponding to the first image file, such as the download link provided by the image storage repository, for example, http://example.com/path/to/iso_file.iso.
  • mounting storage resources means enabling the virtual machine to access and operate additional storage resources.
  • Mounting the first storage resource to the first virtual machine can be understood as using an external storage resource (the first storage resource), such as a cloud disk obtained by the second electronic device, as an additional storage resource that the first virtual machine can access and operate.
  • the first virtual machine can perform read and write operations on the data in the mounted external storage resource.
  • the first electronic device can shut down the first virtual machine.
  • the first electronic device runs libvirt, a virtualization software used to manage virtual machines.
  • libvirt is a platform including an API library that provides a unified interface and function calls.
  • the first electronic device can call the APIs in libvirt to perform various virtual machine management operations, such as shutdown and startup.
  • the first electronic device can shut down the first virtual machine by calling the APIs in libvirt.
  • its configuration file can be obtained.
  • the first electronic device can also obtain the configuration file of the first virtual machine while it is shut down by calling the APIs in libvirt.
  • This configuration file can be in Extensible Markup Language (XML) format.
  • XML Extensible Markup Language
  • the configuration file for the first virtual machine includes its storage resource information, which can be understood as information about one or more storage resources that the first virtual machine can access and operate.
  • the storage resource information obtained by the first electronic device includes the storage resource identifier corresponding to the second storage resource and the startup order corresponding to the second storage resource.
  • the second storage resource is the internal storage resource of the first virtual machine, which can be understood as the system disk inside the first virtual machine. This second storage resource can be used to store the data and programs of the operating system running on the first virtual machine.
  • the storage resource identifier of the second storage resource is identification information used to indicate the second storage resource
  • the startup order corresponding to the second storage resource refers to the order in which the data loaded and run by the first virtual machine is stored in the storage resources when the first virtual machine switches from a shutdown state to a power-on state, that is, when the first virtual machine starts.
  • the first electronic device can modify the configuration file to mount the first storage resource onto the first virtual machine. Since the configuration file is in XML format, modifying the configuration file can also be referred to as modifying the virtual machine's XML, modifying the virtual machine's XML, etc. Specifically, the first electronic device can add a storage resource identifier corresponding to the first storage resource to the storage resource information included in the configuration file, set the boot order of the first storage resource to be first, and modify the boot order of the second storage resource to be after the first. In other words, adding the storage resource identifier corresponding to the first storage resource to the configuration file allows the first virtual machine to mount the first storage resource. Adjusting the boot data of the first storage resource allows the first virtual machine to prioritize booting based on the first storage resource with the first boot order, that is, the first virtual machine prioritizes loading and running the first image file stored in the first storage resource when booting.
  • the syntax for modifying the configuration file of the first virtual machine can be found in Table 2, which includes the specific modification items for modifying the XML format configuration file of the first virtual machine:
  • the ⁇ devices> ⁇ tag is used to define the configuration of the storage resources of the first virtual machine.
  • ⁇ shareable/> ⁇ indicates that this second storage resource can be shared by multiple virtual machines.
  • PCI Peripheral Component Interconnect
  • IDE Integrated Device Electronics
  • ⁇ readonly/> ⁇ indicates that this first storage resource will be mounted to this first virtual machine in read-only mode.
  • the first electronic device can add a disk under the ⁇ devices ⁇ tag in the configuration file of the first virtual machine.
  • the path of this device, ⁇ source dev ⁇ is the path of the first storage resource containing the first image file, i.e., the path of the cloud disk containing the ISO format image file.
  • the first electronic device can specify the boot order of this first storage resource as 1, meaning that the first virtual machine will be booted using the first image file from this first storage resource.
  • the first electronic device modifies the virtual machine XML to mount the first image file on the first virtual machine and to prioritize loading and running the first image file from the first storage resource during the first virtual machine's startup.
  • the first electronic device mounts the first storage resource onto the first virtual machine, it can perform a boot process on the first virtual machine. Specifically, the first electronic device can perform a boot process on the first virtual machine by calling the API in libvirt. During the boot process of the first virtual machine, the first electronic device can perform a boot process on the first storage resource, which is configured as the first boot resource in the configuration file, so as to load and run the first image file through the first virtual machine.
  • Figure 6 is a timing diagram of the mounting process performed by the first electronic device according to the embodiment of this application.
  • the first electronic device can receive a mounting request from the second electronic device.
  • the mounting request carries the identification information of the first virtual machine, the storage path information of the first image file, and the storage resource identifier corresponding to the first storage resource.
  • the first electronic device can identify the storage resource and compare the storage resource identifier corresponding to each storage resource with the storage resource identifier corresponding to the first storage resource. This allows it to check whether the first storage resource obtained by the scheduling layer module in the second electronic device has been mounted to the first electronic device.
  • the first electronic device can download the first image file to the first storage resource indicated by the storage resource identifier according to the storage path information of the first image file.
  • Figure 6 is illustrated and explained with the example of the first image file being stored in the image file storage warehouse. The first electronic device can download the first image file from the image file storage warehouse to the first storage resource based on the download link.
  • the first electronic device can shut down the first virtual machine, such as by calling the libvirt API to control the shutdown of the first virtual machine. While the first virtual machine is shut down, it can obtain the configuration file of the first virtual machine, also by calling the libvirt API. After obtaining the configuration file, the first electronic device can modify it by adding a storage resource identifier corresponding to the first storage resource to mount the first storage resource onto the first virtual machine, and modifying the startup order of each storage resource, such as changing the startup order of the first storage resource to the first position, and changing the startup order of the second storage resource inside the first virtual machine to after the first position, such as the 9th position.
  • the first electronic device can boot the first virtual machine, such as by calling the libvirt API to control the boot of the first virtual machine, so that the first virtual machine boots up using the first storage resource with the first boot order, i.e., the first image file is loaded and run by the first virtual machine at startup.
  • the first virtual machine boots up based on the first storage resource, which is the first in the boot order.
  • This boot process can be described as the first virtual machine loading and running a first image file.
  • the first image file contains the operating system to be installed on the first virtual machine, as well as an installer for that operating system.
  • Running the first image file can be described as running the installer to install the operating system.
  • Installing the operating system contained in the first image file into the second storage resource within the first virtual machine refers to installing the operating system contained in an ISO format image file into the storage resource within the first virtual machine, thus completing the import of the ISO format image file.
  • a user interface can be output by the first virtual machine based on the first image file.
  • This user interface is a user interface provided by the installer carried in the first image file.
  • the user interface may include installation controls for the operating system.
  • the user can trigger an installation operation by using the installation controls in the user interface.
  • the first electronic device can install the operating system carried in the first image file into the second storage resource through the first virtual machine. That is, the installer of the operating system based on the first image file installs the operating system into the system disk inside the first virtual machine.
  • Figure 7 is a schematic diagram of a user interface for installing an operating system carried by a first image file according to an embodiment of this application.
  • the user interface may include operating system settings, such as the language, time and currency format, keyboard, and input method of the operating system.
  • the installation operation can be triggered by the "Next Page" control to install the Windows system carried by the first image file into the second storage resource through the first virtual machine.
  • CentOS 7 the user interface may include operating system settings, such as the language of the operating system.
  • the installation operation can be triggered by the "Continue" control to install the CentOS 7 system carried by the first image file into the second storage resource through the first virtual machine.
  • the user interface output by the first virtual machine based on the first image file may also include a login control. Users can enter fields such as username and password through the login control to log in to the first virtual machine. After logging in to the first virtual machine, the user interface shown in Figure 7 can be output by the first virtual machine to complete the visual installation of the operating system carried in the ISO format image file.
  • Virtio is typically used for I/O communication between virtual machines and the host machine (e.g., the first virtual machine and the first electronic device).
  • Virtio is a semi-virtualization device driver; the virtual machine must have the Virtio driver installed to recognize the storage resources (disks) it mounts. This can be understood as seeing C drives, D drives, etc., in a computer's file management system.
  • an image file carrying a specific operating system does not include the Virtio driver, then when the first virtual machine tries to install the operating system from the first image file onto a second storage resource, it cannot recognize the second storage resource within the first virtual machine; that is, it cannot recognize the system disk of the first virtual machine, and therefore cannot install the operating system onto the second storage resource.
  • Virtio driver is a semi-virtualization device driver used in cloud environments for I/O communication between virtual machines and the host machine. Virtual machines must install this driver to recognize the mounted storage resources, such as C drive and D drive, in the computer's file management system. However, this driver is not included when generating image files of certain operating systems.
  • the first electronic device determines that the operating system carried in the first image file is a specific operating system (e.g., Windows 10, Windows 11, Linux, etc.), and the Windows ISO image file does not include the Virtio driver, then the first electronic device can attach an additional storage resource to the first virtual machine.
  • the first virtual machine's configuration file including storage resource information, will further add a storage resource identifier corresponding to a fourth storage resource.
  • This fourth storage resource carries (integrates) a driver, namely the Virtio driver.
  • the fourth storage resource is an additional storage resource attached to the first virtual machine when the operating system carried in the first image file is determined to be a specific operating system (e.g., Windows 10, Windows 11, Linux, etc.).
  • This storage resource carries (integrates) the driver, the Virtio driver, which enables the first virtual machine to recognize the internal second storage resource when installing a specific operating system, thereby installing the operating system into the second storage resource.
  • ⁇ readonly/> ⁇ indicates that the fourth storage resource is mounted to this first virtual machine in read-only mode.
  • the first electronic device can load and run the driver in the fourth storage resource through the first virtual machine. Based on the driver recognizing the second storage resource (i.e., the system disk) inside the first virtual machine, it can continue to install the operating system, that is, install the operating system carried in the first image file, such as the Windows operating system, into the second storage resource.
  • the second storage resource i.e., the system disk
  • FIG 8 is a schematic diagram of a user interface for loading a driver hosted on a fourth storage resource according to an embodiment of this application.
  • the first virtual machine cannot recognize the second storage resource, so the installation location of the operating system is empty. Therefore, the user can input a trigger operation on the "Load Driver” control to load and run the driver through the first virtual machine.
  • the file directory included in the folder can be displayed. This file directory may include the fourth storage resource, such as "CD drive (F:) config-2" as shown in Figure 8. Then, the driver (Virtio driver) in the fourth storage resource can be loaded and run, such as the drivers with file names "Win10_2016_2019” and “Win8_8.1_2012_2012R2".
  • the first electronic device loads and runs the driver in the fourth storage resource through the first virtual machine. After running the driver as shown in Figure 8, the first virtual machine can recognize the second storage resource. Then, the first electronic device can output the user interface as shown in Figure 7 through the first virtual machine to install the operating system carried in the first image file into the second storage resource.
  • FIG 9 is a schematic diagram of an architecture for importing an image file into a first virtual machine according to an embodiment of this application. As shown in Figure 9, the explanation is from top to bottom. Users can visualize the operation of importing an image file into the first virtual machine through the user interface provided by the console device. Users can also input the storage path information (such as a download link) of the image file they want to import.
  • the console device can generate an import request for the image file based on the identifier information of the first virtual machine selected by the user and the storage path information of the image file, and send the import request to the first electronic device.
  • the first electronic device includes two control modules: an access layer module and a scheduling layer module.
  • the access layer module in the first electronic device can obtain the import request and call the scheduling layer module to obtain the first storage resource. Specifically, the access layer module can verify the running status of the first virtual machine and the system architecture information corresponding to the first virtual machine. After successful verification, the access layer module can call the scheduling layer module to mount the first storage resource onto the first electronic device running the first virtual machine.
  • the scheduling layer module can send a mount request to the first electronic device.
  • the first electronic device can download the image file to the first storage resource, for example, by downloading the image file from a download link in an image file storage repository.
  • the first electronic device can mount the first storage resource to the first virtual machine. Specifically, it can modify the configuration file of the first virtual machine and load and run the image file through the first virtual machine. This allows the operating system contained in the image file to be installed in the second storage resource within the first virtual machine, thereby importing the image file into the first virtual machine.
  • a standardized, product-level solution is proposed to address the problem of needing to convert image files before importing specific format image files, especially for virtual machines in cloud environments.
  • This solution provides a productized process for uniformly managing the import of ISO format image files into cloud environments, thereby improving both the capability and efficiency of importing ISO format image files.
  • the image file import method provided in this application can mitigate these risks by mounting storage resources and loading drivers, thus enabling the import of ISO format image files carrying different types of operating systems into virtual machines.
  • the second electronic device can obtain an import request to import a first image file into a first virtual machine.
  • This import request carries the identification information of the first virtual machine and the storage path information of the first image file. Based on the storage path information, it obtains a first storage resource matching the first image file and mounts the first storage resource onto the first electronic device running the first virtual machine.
  • a mount request is sent to the first electronic device, instructing it to download the first image file to the first storage resource based on the storage path information and mount the first storage resource onto the first virtual machine, so that the first image file can be loaded and run by the first virtual machine.
  • the image file of that specific format can be loaded and run by the virtual machine, thus achieving the import of the image file.
  • This eliminates the cumbersome step of format conversion of the image file, making the image file import process simpler and improving the import capability and efficiency of image files of specific formats. It also brings convenience to the management and deployment of virtualization environments to a certain extent.
  • Figure 10 is a schematic flowchart of another method for importing an image file according to an embodiment of this application.
  • This method for importing an image file can be implemented by the interaction of a first electronic device and a second electronic device.
  • the first electronic device can be the virtual machine host device 103 shown in Figure 1
  • the second electronic device can be the virtual machine platform device 102 shown in Figure 1.
  • the method for importing the image file can include the following steps S1001-S1004, wherein:
  • the second electronic device obtains a first unattachment request carrying the identification information of the first virtual machine.
  • the first unmount request refers to a request generated by the console device based on the user's input of an unmount operation for the first virtual machine and the identification information of the first virtual machine, and sent to the second electronic device. It can also be called a request to unmount an ISO image.
  • the scheduling layer module of the second electronic device can communicate in real time with the electronic device hosting each virtual machine, such as the first electronic device hosting the first virtual machine, to obtain the running status of each virtual machine and update the running status of the virtual machines to the maintained database. For example, after the first electronic device loads and runs the first image file of the first storage resource through the first virtual machine, it can determine that the running status of the first virtual machine is mounted, and then send the identification information and running status (mounted) of the first virtual machine to the second electronic device. After receiving the identification information and running status sent by the first electronic device, the scheduling layer module in the second electronic device can update the running status of the first virtual machine stored in the database from mounted to mounted.
  • the user interface displayed on the console device can update the running status of the first virtual machine to "mounted".
  • the user can trigger the operation by inputting an unmount operation for the first virtual machine, as shown in Figure 3 with the unmount control corresponding to virtual machine D whose running status has been updated to "mounted".
  • the console device can generate a first unmount request based on the identification information of the first virtual machine, such as virtual machine D, and send this first unmount request carrying the identification information of the first virtual machine to the second electronic device.
  • the second electronic device can then obtain the first unmount request carrying this identification information.
  • the console device can call the API provided by the access layer module in the second electronic device to perform a visual operation on the console device to unmount the virtual machine storing the storage resource, i.e., select a virtual machine to access the storage resource storing the ISO format image file, which can be called unmounting the ISO image disk.
  • the console device then sends the first unmount request to the second electronic device.
  • the second electronic device can obtain the first unmount request based on the HTTP service provided by the API. This first unmount request can also be called a request to unmount the ISO image.
  • the second electronic device sends a second unblocking request to the first electronic device, carrying identification information and the storage resource identifier corresponding to the first storage resource.
  • the second unmount request refers to the request generated by the access layer module in the second electronic device after obtaining the first unmount request, based on the identification information of the first virtual machine and the storage resource identifier corresponding to the first storage resource. It is used to instruct the first electronic device to determine that the first virtual machine has mounted the first storage resource based on the identification information and the storage resource identifier, and to unmount the first storage resource.
  • the access layer module in the second electronic device can determine whether the running status of the first virtual machine is mounted, that is, whether the first electronic device has loaded and run the first image file in the first storage resource through the first virtual machine. If so, a second unmount request can be generated based on the identification information of the first virtual machine and the storage resource identifier corresponding to the first storage resource. Specifically, the access layer module can query the database maintained by the scheduling layer module to see if the current running status of the first virtual machine is mounted, based on the identification information of the first virtual machine. If it is mounted, the access layer module can determine whether the first electronic device has loaded and run the first image file in the first storage resource through the first virtual machine and can generate the second unmount request.
  • the access layer module can transmit the second unmount request, carrying identification information and the storage resource identifier corresponding to the first storage resource, to the scheduling layer module. This allows the identification information and other parameters to be transparently transmitted to the scheduling layer module.
  • the scheduling layer module can send the second unmount request, carrying the identification information of the first virtual machine and the storage resource identifier corresponding to the first storage resource, to the first electronic device.
  • the second electronic device can receive the second unmount request carrying the identification information of the first virtual machine and the storage resource identifier corresponding to the first storage resource.
  • This second unmount request can be used to instruct the first electronic device to determine, based on the identification information and the storage resource identifier, that the first virtual machine has mounted the first storage resource, and to unmount the first storage resource.
  • the access layer module is mainly used to provide callable APIs for the console device, primarily for interaction with the console device and parameter pass-through.
  • the scheduling layer module is mainly used to interact with the electronic device running the virtual machine (such as the first electronic device) and complete parameter pass-through.
  • the access layer module does not directly interact with the electronic device running the virtual machine. Therefore, after the access layer module generates the second unattachment request, it can transmit the second unattachment request to the scheduling layer module.
  • the scheduling layer module based on the identification information of the first virtual machine, determines the first electronic device running the first virtual machine and then sends the second unattachment request to the first electronic device.
  • Figure 11 is another timing diagram illustrating the execution of an access layer module in a second electronic device according to an embodiment of this application.
  • the access layer module can receive a first unmount request carrying the identification information of a first virtual machine.
  • the access layer module can then check whether the current running state of the first virtual machine is mounted. Specifically, the access layer module can query the status of the first virtual machine in the database based on the identification information to perform the check. If the check result is yes, the access layer module can generate a second unmount request based on the identification information of the first virtual machine and the storage resource identifier corresponding to the first storage resource, and transmit the second unmount request to the scheduling layer module in the second electronic device to complete parameter pass-through.
  • the scheduling layer module can be invoked to send the second unmount request to the first electronic device running the first virtual machine. If the check result is no, i.e., the current running state of the first virtual machine is not mounted, the process ends, and the access layer module does not perform further processing.
  • the first electronic device determines that the first virtual machine has mounted the first storage resource based on the identification information and the storage resource identifier corresponding to the first storage resource.
  • the first electronic device in response to the second unmount request (unmount request), can determine the first virtual machine based on the identification information, and then determine that the first virtual machine has mounted the first storage resource based on the storage resource identifier corresponding to the first storage resource. Specifically, the first electronic device can obtain the configuration file of the first virtual machine, which may include storage resource identifiers corresponding to each storage resource mounted by the first virtual machine. The first electronic device can then determine whether the first virtual machine has mounted the first storage resource based on the storage resource identifier corresponding to the first storage resource and the storage resource identifiers corresponding to each storage resource in the configuration file. Furthermore, if the first electronic device determines that the first virtual machine has mounted the first storage resource, it can unmount the first storage resource.
  • the first electronic device can first shut down the first virtual machine, possibly by calling an API in libvirt. Then, while the first virtual machine is shut down, the first electronic device can obtain its configuration file. The configuration file can also be obtained while the first virtual machine is shut down by calling an API in libvirt.
  • the configuration file may include storage resource information for the first virtual machine, including storage resource identifiers corresponding to the first and second storage resources. The first electronic device can then determine whether the configuration file includes the storage resource identifier corresponding to the first storage resource. If it does, it determines that the first virtual machine has mounted the first storage resource, and can then unmount the first storage resource.
  • the first electronic device unmounts the first storage resource.
  • Unmounting also known as unloading or unmounting, is the opposite of mounting. It refers to separating a mounted storage resource from the operating system's file system so that it can no longer be accessed. It is a process of stopping access to storage data.
  • the first electronic device unmounts the first storage resource, it separates the mounted first storage resource from the storage resources accessible to the first virtual machine, so that the first virtual machine can no longer access the first storage resource.
  • unmounting can also be called unmount/dismount, unloading, etc.
  • Unmounting as opposed to mounting, refers to separating a mounted storage resource from the operating system's file system, thus preventing it from being accessed; it is a process of stopping access to storage data.
  • the first electronic device unmounting the first storage resource can mean separating the mounted first storage resource from the storage resources accessible by the first virtual machine, so that the first virtual machine no longer accesses the first storage resource.
  • the first electronic device in response to the second unmount request (unmount request), can directly unmount the first storage resource without needing to determine whether the first virtual machine has mounted the first storage resource. This is because the access layer module of the second electronic device has already checked that the first virtual machine is in a mounted state, so it can directly unmount the mounted first storage resource.
  • the first electronic device in response to the second unmount request (unmount request), may first determine that the first virtual machine has mounted the first storage resource based on the identification information of the first virtual machine and the storage resource identification corresponding to the first storage resource, and then unmount the first storage resource.
  • the first electronic device regardless of whether the first electronic device needs to first determine that the first virtual machine has mounted the first storage resource, it must first shut down the first virtual machine, such as by calling the API in libvirt. While the first virtual machine is shut down, the first electronic device can call the API in libvirt to obtain the configuration file of the first virtual machine.
  • This configuration file includes the storage resource information of the first virtual machine, including the storage resource identifier corresponding to the first storage resource, the storage resource identifier corresponding to the second storage resource, and the startup order corresponding to the first and second storage resources, respectively. See Table 2 or Table 3 for details on the storage resource information.
  • the first electronic device can modify the configuration file to unmount the first storage resource. Specifically, the first electronic device can delete the storage resource identifier corresponding to the first storage resource from the storage resource information included in the configuration file and restore the boot order corresponding to the second storage resource. That is, the storage resource identifier corresponding to the first storage resource, which was previously added to the storage resource information in response to the mount request, is deleted to unmount the storage resource that was additionally mounted when importing the image file. Since the first electronic device sets the boot order corresponding to the first storage resource to the first position in response to the mount request, and sets the boot order corresponding to the second storage resource to after the first position, after unmounting the first storage resource, the original boot order in the second storage resource can be restored. For example, the boot order of the second storage resource can be restored to the first position, that is, the first virtual machine can be restored to boot based on the second storage resource (system disk) with the first boot order.
  • the first electronic device can delete the storage resource identifier corresponding to the first storage resource, that is, the previously added ⁇ disk> tag, and restore the boot order of the second storage resource, that is, the boot order mentioned above is restored to 1.
  • the first electronic device can send the current running status of the first virtual machine to the scheduling layer module of the second electronic device, for example, the unmounted status.
  • the scheduling layer module in the second electronic device can then update the running status of the first virtual machine in the database.
  • the scheduling layer module can then call the API provided by the cloud disk service to initiate a request to return the first storage resource, such as a request to return the cloud disk, to destroy the previously acquired first storage resource by calling the API provided by the cloud disk service. Destroying the first storage resource can be understood as merging it with preset storage resources for subsequent storage resource allocation.
  • the first virtual machine mounts the first storage resource, it can load and run the first image file from the first storage resource at startup, installing the operating system carried by the first image file onto the second storage resource within the first virtual machine.
  • the image file has been imported into the first virtual machine, and the user can execute corresponding cloud computing tasks within it.
  • the first electronic device can generate a second image file from the first virtual machine.
  • This second image file is in a format directly supported by KVM and QEMU hypervisor virtualization systems, such as qcow2, raw, and vhd.
  • the system information corresponding to the generated second image file includes information such as system architecture and system version, which constitutes the image metadata of the first virtual machine.
  • This metadata can be system information input by the user for the first image file, ensuring that the system information in the generated second image file is consistent with that of the first image file.
  • the second image file is a file generated by the first electronic device based on the operating system installed in the second storage resource inside the first virtual machine through the first virtual machine.
  • Its format is a format that can be directly supported by the hypervisor virtualization system of KVM and QEMU, such as qcow2, raw, vhd, etc.
  • the corresponding system information includes information such as system architecture and system version, which is the image metadata of the first virtual machine and is consistent with the system information of the first image file.
  • the first electronic device generates a second image file based on the operating system installed in the second storage resource within the first virtual machine.
  • This can be understood as the first electronic device creating a backup of the first virtual machine, saving its state to a file, thus obtaining the second image file.
  • This first virtual machine can be the second image file generated using the image creation capabilities provided by cloud computing services in a cloud environment, such as through tools provided by the cloud computing service or by calling corresponding APIs.
  • this second image file can be stored in a storage service provided by the cloud computing service, such as an image storage repository, so that a virtual machine with the same configuration can be deployed when needed.
  • the first storage resource mounted on the first virtual machine needs to be unmounted. This is because if the first storage resource is not unmounted, the state of the first virtual machine may become abnormal.
  • the user can also install other applications on the first virtual machine based on the operating system hosted on the first image file, so as to include the installed applications in the generated second image file.
  • the second electronic device can obtain an installation request on a second virtual machine according to a second image file.
  • This installation request may carry identification information for the second virtual machine, which can be any virtual machine other than the first virtual machine; it can be a newly created virtual machine or an existing virtual machine. This identification information can be used to indicate the second virtual machine.
  • the first and second image files have different formats. For example, if the first image file is in ISO format, while the second image file is in a format directly supported by KVM and QEMU hypervisor virtualization systems, such as qcow2, raw, or vhd, this determines that the first and second image files have different formats.
  • An installation request refers to a request obtained by the second electronic device to install the second image file on the second virtual machine.
  • the request carries the identification information of the second virtual machine, which can be any virtual machine other than the first virtual machine.
  • the first image file and the second image file have different formats.
  • the third storage resource is the storage resource inside the second virtual machine, used to store the second image file downloaded by the second electronic device in response to the installation request, so that the second virtual machine can load and run the second image file, making the second virtual machine have the same configuration as the first virtual machine that imported the first image file.
  • a user can initiate a request to install a second image file on a second virtual machine via a console device.
  • the console device After receiving the user's operation, the console device generates an installation request carrying the identification information of the second virtual machine and sends it to the second electronic device.
  • the second electronic device After receiving the installation request, the second electronic device determines the target virtual machine based on the identification information of the second virtual machine and downloads the second image file to the third storage resource inside the second virtual machine according to the storage path information of the second image file.
  • Figure 12 is a timing diagram of the first electronic device performing the unmounting process according to an embodiment of this application.
  • the first electronic device can receive an unmounting request (second unmounting request) from the second electronic device. Further, the first electronic device can shut down the first virtual machine, such as by calling the API in libvirt to control the shutdown of the first virtual machine. While the first virtual machine is shut down, the first electronic device obtains its configuration file, such as by calling the API in libvirt to obtain the configuration file. It can then determine whether the configuration file was successfully obtained.
  • the first electronic device can modify the configuration file, deleting the storage resource identifier corresponding to the first storage resource from the storage resource information included in the configuration file to unmount the first storage resource and restore the startup order corresponding to the second storage resource.
  • the first electronic device can boot the first virtual machine, such as by calling the API in libvirt to control the boot of the first virtual machine, so that the first virtual machine can boot using the second storage resource, which is the first in the startup order. If obtaining the configuration file fails, the process ends, and the first electronic device does not perform any further processing.
  • Figure 13 is a schematic diagram of another architecture for importing an image file into a first virtual machine according to an embodiment of this application. As shown in Figure 13, the explanation is from top to bottom.
  • the user can use the user interface provided by the console device to visually unmount the first storage resource from the first virtual machine whose running state is mounted.
  • the console device can generate a first unmount request based on the identification information of the first virtual machine selected by the user and the storage resource identifier corresponding to the first storage resource, and send the first unmount request to the first electronic device.
  • the access layer module in the first electronic device can obtain the first unmount request, and then generate a second unmount request based on the identification information of the first virtual machine and the storage resource identifier corresponding to the first storage resource, and send the second unmount request to the first electronic device by calling the scheduling layer module.
  • the first electronic device responds to the unmount request and unmounts the first storage resource, that is, unmounts the first storage resource storing the first image file in ISO format.
  • the first electronic device can delete the storage resource identifier corresponding to the first storage resource in the configuration file of the first virtual machine and restore the boot order corresponding to the second storage resource, so that the first virtual machine can boot preferentially based on the internal second storage resource (system disk).
  • the first electronic device can update the running status of the first virtual machine and send the current running status of the first virtual machine to the scheduling layer module of the second electronic device.
  • the scheduling layer module can call the API provided by the cloud disk service to return the first storage resource.
  • Figure 14 is a timing diagram of importing an image file into a first virtual machine according to an embodiment of this application.
  • the main processes involved in the image file import method are: mounting a first storage resource on the first virtual machine, installing an operating system on the first virtual machine, unmounting the first storage resource on the first virtual machine, and generating an image file on the first virtual machine.
  • the user selects a virtual machine as the first virtual machine in the console device.
  • the system architecture information corresponding to the first virtual machine is the same as the system architecture information corresponding to the image file to be imported.
  • the first storage resource is mounted on the first virtual machine.
  • the first storage resource can be mounted on the first electronic device where the first virtual machine is located before mounting the first storage resource on the first virtual machine.
  • the first electronic device can download the ISO format image file to the first storage resource, and then the image file in the first storage resource can be loaded and run by the first virtual machine at startup.
  • the user can log in through the user interface provided by the first virtual machine and install the operating system onto the second storage resource within the first virtual machine.
  • the first storage resource is unmounted from the first virtual machine, allowing the virtual machine to load and run its internal second storage resource upon startup.
  • an image file is generated from the first virtual machine, creating an image file in a format supported by the virtualization system, such as a format supported by QEMU, so that the image file generated by the first virtual machine can be used further in the future.
  • the second electronic device can obtain an import request to import a first image file into a first virtual machine.
  • This import request carries the identification information of the first virtual machine and the storage path information of the first image file. Based on the storage path information, it obtains a first storage resource matching the first image file and mounts the first storage resource onto the first electronic device running the first virtual machine.
  • a mount request is sent to the first electronic device, instructing it to download the first image file to the first storage resource based on the storage path information and mount the first storage resource onto the first virtual machine, so that the first image file can be loaded and run by the first virtual machine.
  • the image file of that specific format can be loaded and run by the virtual machine, thus achieving the import of the image file.
  • This eliminates the cumbersome step of format conversion of the image file, making the image file import process simpler and improving the import capability and efficiency of image files of specific formats. It also brings convenience to the management and deployment of virtualization environments to a certain extent.
  • FIG 15 is a schematic diagram of an image file import device provided in an embodiment of this application.
  • This image file import device 150 can be used to execute the corresponding steps in the image file import methods shown in Figures 2 and 10.
  • the image file import device 150 includes the following units:
  • the acquisition unit 1501 is used to acquire an import request that requests the first image file to be imported into the first virtual machine.
  • the import request carries the identification information of the first virtual machine and the storage path information of the first image file. Based on the storage path information, it acquires the first storage resource that matches the first image file and mounts the first storage resource to the first electronic device running the first virtual machine.
  • the sending unit 1502 is used to send a mounting request to the first electronic device.
  • the mounting request is used to instruct the first electronic device to download the first image file to the first storage resource based on the storage path information, and to mount the first storage resource to the first virtual machine so that the first image file can be loaded and run by the first virtual machine.
  • the import request also carries system architecture information corresponding to the first image file;
  • the acquisition unit 1501 is used to mount the first storage resource onto the first electronic device running the first virtual machine, specifically for:
  • the running state is one of the running states in the preset running state set, obtain the system architecture information corresponding to the first virtual machine;
  • the first storage resource is mounted onto the first electronic device.
  • the acquisition unit 1501 is used to acquire the first storage resource matching the first image file based on the storage path information, specifically for:
  • the file size of the first image file is determined based on the storage path information
  • storage resources matching the size of the first image file are allocated from the preset storage resources to obtain the first storage resource.
  • the acquisition unit 1501 is used to mount the first storage resource to the first electronic device running the first virtual machine, specifically for:
  • the first storage resource is mounted onto the first electronic device indicated by the target identification information.
  • the acquisition unit 1501 is also used to acquire a first unhooking request carrying identification information
  • the sending unit 1502 is further configured to send a second unmounting request carrying identification information and a storage resource identifier corresponding to the first storage resource to the first electronic device.
  • the second unmounting request is used to instruct the first electronic device to determine that the first virtual machine has mounted the first storage resource based on the identification information and the storage resource identifier, and to unmount the first storage resource.
  • the acquisition unit 1501 is further configured to acquire an installation request on the second virtual machine according to the second image file, wherein the installation request carries the identification information of the second virtual machine and the first image file and the second image file have different formats.
  • Download unit 1503 is used to download the second image file to the third storage resource inside the second virtual machine in response to the installation request, so as to load and run the second image file through the second virtual machine;
  • the first virtual machine contains an operating system mounted on a first image file in its second storage resource.
  • the second image file is generated by the first electronic device based on the operating system through the first virtual machine.
  • the second virtual machine is any virtual machine other than the first virtual machine.
  • the steps involved in the methods shown in FIG2 and FIG10 can be executed by various units in the image file import device shown in FIG15.
  • steps S201-S202 shown in FIG2 are executed by the acquisition unit 1501 shown in FIG15
  • step S203 is executed by the sending unit 1502 shown in FIG15.
  • step S1001 shown in FIG10 is executed by the acquisition unit 1501 shown in FIG15
  • step S1002 is executed by the sending unit 1502 shown in FIG15.
  • the units in the image file import device 150 shown in FIG. 15 can be individually or entirely merged into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This can achieve the same operation without affecting the technical effect of the embodiment of this application.
  • the above units are based on logical function division.
  • the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit.
  • the image file import device 150 may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented by multiple units working together.
  • the image file import method of the embodiment of this application can be constructed by running a computer program (including program code) capable of executing the steps involved in the corresponding methods shown in FIG. 2 and FIG. 10 on a general-purpose computing device including processing elements and storage elements such as a central processing unit (CPU), random access storage medium (RAM), and read-only storage medium (ROM).
  • Computer programs can be recorded on, for example, a computer-readable storage medium, and loaded onto the virtual machine platform device 102 of the import system of the image file shown in FIG1 via the computer-readable storage medium, and run therein.
  • FIG 16 is a schematic diagram of another image file import device provided in an embodiment of this application.
  • This image file import device 160 can be used to execute the corresponding steps in the image file import methods shown in Figures 2 and 10.
  • the image file import device 160 includes the following units:
  • the receiving unit 1601 is used to receive a mounting request from the second electronic device.
  • the mounting request carries the identification information of the first virtual machine, the storage resource identifier corresponding to the first storage resource, and the storage path information of the first image file.
  • Download unit 1602 is used to respond to a mount request by downloading the first image file to the first storage resource indicated by the storage resource identifier based on the storage path information, and mount the first storage resource to the first virtual machine;
  • the loading unit 1603 is used to load and run the first image file through the first virtual machine, and install the operating system carried in the first image file into the second storage resource inside the first virtual machine;
  • the mount request is sent by the second electronic device to the first electronic device after responding to the import request that requests the first image file to be imported into the first virtual machine, obtaining the first storage resource that matches the first image file based on the storage path information, and mounting the first storage resource onto the first electronic device running the first virtual machine.
  • the download unit 1602 is used to mount the first storage resource onto the first virtual machine, specifically for:
  • the configuration file includes the storage resource information of the first virtual machine.
  • the storage resource information includes the storage resource identifier corresponding to the second storage resource and the startup order corresponding to the second storage resource.
  • the image file import device 160 further includes:
  • Adding unit 1604 is used to add a storage resource identifier corresponding to the fourth storage resource in the storage resource information when the operating system carried in the first image file is a specific operating system.
  • the fourth storage resource carries a driver.
  • Loading unit 1603 is used to load and run the first image file through the first virtual machine, and install the operating system carried in the first image file into the second storage resource inside the first virtual machine, specifically for:
  • the first virtual machine loads and runs the driver in the fourth storage resource so that, based on the driver's recognition of the second storage resource, the operating system carried in the first image file can be installed in the second storage resource.
  • the loading unit 1603 is used to load and run the first image file through the first virtual machine, and install the operating system carried in the first image file into the second storage resource inside the first virtual machine, specifically for:
  • the first virtual machine is booted up based on the first storage resource, which is the first in the boot order.
  • the user interface is output based on the first image file using the first virtual machine
  • the operating system carried in the first image file is installed in the second storage resource via the first virtual machine.
  • the receiving unit 1601 is further configured to receive a de-hanging request carrying identification information and the storage resource identifier corresponding to the first storage resource;
  • the determining unit 1605 is used to determine, in response to the unmounting request, that the first virtual machine has mounted the first storage resource based on the identification information and the storage resource identifier corresponding to the first storage resource;
  • the unmounting unit 1606 is used to unmount the first storage resource.
  • the unmounting unit 1606 is used to unmount the first storage resource, specifically for:
  • the configuration file includes the storage resource information of the first virtual machine.
  • the storage resource information includes the storage resource identifier corresponding to the first storage resource, the storage resource identifier corresponding to the second storage resource, and the startup order corresponding to the first storage resource and the second storage resource respectively.
  • step S204 shown in FIG2 is executed by the download unit 1602 shown in FIG16
  • step S205 is executed by the loading unit 1603 shown in FIG16
  • step S1003 shown in FIG10 is executed by the determining unit 1605 shown in FIG16
  • step S1004 is executed by the unloading unit 1606 shown in FIG16.
  • the units in the image file import device 160 shown in FIG. 16 can be individually or entirely merged into one or more other units, or some of the units can be further divided into multiple functionally smaller units. This can achieve the same operation without affecting the technical effect of the embodiment of this application.
  • the above units are based on logical function division.
  • the function of one unit can also be implemented by multiple units, or the function of multiple units can be implemented by one unit.
  • the image file import device 160 may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented by multiple units working together.
  • 16 and the image file import method of the embodiment of this application can be constructed by running a computer program (including program code) capable of executing the steps involved in the corresponding methods shown in FIG. 2 and FIG. 10 on a general-purpose computing device including processing elements and storage elements such as a central processing unit (CPU), random access storage medium (RAM), and read-only storage medium (ROM).
  • Computer programs can be recorded on, for example, a computer-readable storage medium, and loaded onto the virtual machine host device 103 of the import system of the image file shown in FIG1 via the computer-readable storage medium, and run therein.
  • the electronic device 170 may include at least a processor 1701, an input device 1702, an output device 1703, and a memory 1704.
  • the processor 1701, input device 1702, output device 1703, and memory 1704 within the electronic device 170 may be connected via a bus or other means.
  • the aforementioned memory 1704 is a memory device in the electronic device 170, used to store programs and data. It is understood that the memory 1704 here can include the built-in storage medium of the image file import device, or it can include an extended storage medium supported by the electronic device 170.
  • the memory 1704 provides storage space that stores the operating system of the electronic device 170.
  • the computer program (including program code) is also stored in this storage space.
  • the computer storage medium here can be a high-speed RAM memory; optionally, it can also be at least one computer storage medium located remotely from the aforementioned processor, which can be called a Central Processing Unit (CPU), the core and control center of the image file import device, used to run the computer program stored in the aforementioned memory 1704.
  • CPU Central Processing Unit
  • the processor 1701 can load and execute a computer program stored in the memory 1704 to implement the corresponding steps of the method in the above-described embodiment of the image file import method; specifically, the processor 1701 loads and executes the computer program stored in the memory 1704 for:
  • the request to import the first image file into the first virtual machine is obtained.
  • the import request carries the identification information of the first virtual machine and the storage path information of the first image file.
  • a mount request is sent to the first electronic device.
  • the mount request is used to instruct the first electronic device to download the first image file to the first storage resource based on the storage path information, and mount the first storage resource to the first virtual machine so that the first image file can be loaded and run by the first virtual machine.
  • the import request also carries system architecture information corresponding to the first image file; the processor 1701 loads and executes the computer program stored in the memory 1704 to mount the first storage resource onto the first electronic device running the first virtual machine, specifically for:
  • the running state is one of the running states in the preset running state set, obtain the system architecture information corresponding to the first virtual machine;
  • the first storage resource is mounted onto the first electronic device.
  • processor 1701 loads and executes a computer program stored in memory 1704 to obtain a first storage resource matching the first image file based on storage path information, specifically for:
  • the file size of the first image file is determined based on the storage path information
  • storage resources matching the size of the first image file are allocated from the preset storage resources to obtain the first storage resource.
  • processor 1701 loads and executes a computer program stored in memory 1704 to mount the first storage resource onto a first electronic device running the first virtual machine, specifically for:
  • the first storage resource is mounted onto the first electronic device indicated by the target identification information.
  • processor 1701 loads and executes a computer program stored in memory 1704, and is also used for:
  • the second unmount request is used to instruct the first electronic device to determine that the first virtual machine has mounted the first storage resource based on the identification information and the storage resource identifier, and to unmount the first storage resource.
  • processor 1701 loads and executes a computer program stored in memory 1704, and is also used for:
  • the request is to install the second image file on the second virtual machine.
  • the installation request carries the identification information of the second virtual machine.
  • the first image file and the second image file have different formats.
  • the second image file is downloaded to the third storage resource inside the second virtual machine so that the second image file can be loaded and run by the second virtual machine;
  • the first virtual machine contains an operating system mounted on a first image file in its second storage resource.
  • the second image file is generated by the first electronic device based on the operating system through the first virtual machine.
  • the second virtual machine is any virtual machine other than the first virtual machine.
  • the processor 1701 can load and execute the computer program stored in the memory 1704 to implement the corresponding steps in the above-described embodiment of the method for importing another image file; specifically, the processor 1701 loads and executes the computer program stored in the memory 1704 for:
  • the mount request carries the identification information of the first virtual machine, the storage resource identifier corresponding to the first storage resource, and the storage path information of the first image file.
  • the first image file is downloaded to the first storage resource indicated by the storage resource identifier based on the storage path information, and the first storage resource is mounted to the first virtual machine;
  • the first image file is loaded and run by the first virtual machine, and the operating system carried in the first image file is installed in the second storage resource inside the first virtual machine.
  • the mount request is sent by the second electronic device to the first electronic device after responding to the import request that requests the first image file to be imported into the first virtual machine, obtaining the first storage resource that matches the first image file based on the storage path information, and mounting the first storage resource onto the first electronic device running the first virtual machine.
  • processor 1701 loads and executes a computer program stored in memory 1704 to mount the first storage resource onto the first virtual machine, specifically for:
  • the configuration file includes the storage resource information of the first virtual machine.
  • the storage resource information includes the storage resource identifier corresponding to the second storage resource and the startup order corresponding to the second storage resource.
  • processor 1701 loads and executes a computer program stored in memory 1704, and is also used for:
  • the fourth storage resource carries the driver.
  • the process involves loading and running a first image file using a first virtual machine, and installing the operating system contained in the first image file into a second storage resource within the first virtual machine, including:
  • the first virtual machine loads and runs the driver in the fourth storage resource so that, based on the driver's recognition of the second storage resource, the operating system carried in the first image file can be installed in the second storage resource.
  • processor 1701 loads and executes a computer program stored in memory 1704, used to load and run a first image file via a first virtual machine, and install the operating system carried in the first image file into a second storage resource inside the first virtual machine, specifically for:
  • the first virtual machine is booted up based on the first storage resource, which is the first in the boot order.
  • the user interface is output based on the first image file using the first virtual machine
  • the operating system carried in the first image file is installed in the second storage resource via the first virtual machine.
  • processor 1701 loads and executes a computer program stored in memory 1704, and is also used for:
  • processor 1701 loads and executes a computer program stored in memory 1704 to unmount the first storage resource, specifically for:
  • the configuration file includes the storage resource information of the first virtual machine.
  • the storage resource information includes the storage resource identifier corresponding to the first storage resource, the storage resource identifier corresponding to the second storage resource, and the startup order corresponding to the first storage resource and the second storage resource respectively.
  • the processor 1701 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • the general-purpose processor may be a microprocessor or any conventional processor.
  • This application provides a computer-readable storage medium storing a computer program, which includes program instructions.
  • program instructions When the program instructions are executed by a processor, they can perform the steps described in all the above embodiments.
  • This application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium.
  • the computer instructions When executed by the processor of a computer device, they perform the methods described in all the above embodiments.
  • the program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods.
  • the storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.
  • this application provides a method, apparatus, device, storage medium, and computer program product for importing image files. It obtains an import request from a second electronic device to import a first image file into a first virtual machine. This request carries the first virtual machine's identifier information and the first image file's storage path information. Based on the storage path information, it obtains a matching first storage resource and mounts it onto the first electronic device running the first virtual machine. Then, it sends a mount request to the first electronic device, instructing it to download the first image file to the first storage resource and mount it onto the first virtual machine. The first virtual machine then loads and runs the first image file. This eliminates the cumbersome step of converting the image file's format, simplifies the import process, improves the import capability and efficiency of image files in specific formats, and brings convenience to the management and deployment of virtualized environments.
  • the second electronic device obtains the current running status of the first virtual machine based on the identification information. If the running status is in the preset running status set, it obtains the system architecture information corresponding to the first virtual machine. Only when the system architecture information corresponding to the first virtual machine and the first image file is the same, the first storage resource is mounted on the first electronic device. This ensures that the virtual machine can load and run the image file normally, avoids import anomalies due to mismatch in status or architecture, and improves the success rate and stability of the import.
  • the second electronic device determines the file size of the first image file based on the storage path information, and allocates the matching storage resource from the preset storage resources according to the size as the first storage resource. This can accurately match resources, reduce resource waste, and improve resource utilization.
  • the second electronic device When the first storage resource is mounted onto the first electronic device running the first virtual machine, the second electronic device obtains the correspondence between the virtual machine identification information and the electronic device identification information. Based on this relationship and the identification information, it determines the target identification information and then mounts the first storage resource onto the first electronic device indicated by the target identification information.
  • This accurate mounting method ensures the accuracy of storage resource mounting, avoids mismounting, and improves the reliability of system operation.
  • the second electronic device After obtaining the first unmount request carrying the identification information, the second electronic device sends a second unmount request carrying the identification information and the storage resource identifier corresponding to the first storage resource to the first electronic device, instructing the first electronic device to determine that the first virtual machine has mounted the first storage resource and to unmount it, so that the system can flexibly manage the mounting and unmounting of storage resources, improve the resource availability, and facilitate other subsequent operations.
  • the second electronic device When a request is made to install the second image file on the second virtual machine, and the request carries the second virtual machine's identification information, and the first and second image files have different formats, the second electronic device responds to the request and downloads the second image file to the third storage resource inside the second virtual machine. The second virtual machine then loads and runs the second image file. Since the operating system carried by the first image file is already installed inside the first virtual machine, and the second image file is generated by the first electronic device through the first virtual machine based on that operating system, the second virtual machine has the same configuration as the first virtual machine. This enables the function of batch producing virtual machines based on the second image file, improving the consistency of virtual machine configuration and deployment efficiency.
  • the first electronic device When the first electronic device executes the image file import method, it receives a mount request from the second electronic device. This request carries the first virtual machine identifier information, the storage resource identifier corresponding to the first storage resource, and the storage path information of the first image file. In response to the request, the first image file is downloaded to the first storage resource and mounted on the first virtual machine based on the storage path information. The first virtual machine loads and runs the first image file and installs the operating system contained therein in the second storage resource inside the first virtual machine, thus completing the image file import. This process does not require format conversion, which improves the import efficiency.
  • the first electronic device When mounting the first storage resource onto the first virtual machine, the first electronic device obtains its configuration file while the first virtual machine is powered off.
  • This file contains storage resource information such as the storage resource identifier and startup order corresponding to the second storage resource. Then, the storage resource identifier corresponding to the first storage resource is added to the storage resource information, the startup order of the first storage resource is set to first, and the startup order of the second storage resource is modified to be after the first.
  • This precise modification of the configuration file it is ensured that the image file in the first storage resource is loaded and run first when the first virtual machine starts, thus ensuring the orderliness and accuracy of the import process.
  • the first electronic device When the operating system carried in the first image file is a specific operating system, the first electronic device adds the storage resource identifier corresponding to the fourth storage resource to the storage resource information.
  • the fourth storage resource carries the driver.
  • the driver in the fourth storage resource is loaded and run by the first virtual machine.
  • the operating system carried in the first image file is installed in the second storage resource. This solves the problem that the storage resource cannot be identified due to the lack of a driver for a specific operating system and enhances the system's compatibility with image files of different operating systems.
  • the first electronic device performs a boot process based on the first storage resource with the first boot order through the first virtual machine, outputs a user interface based on the first image file, responds to the installation operation received based on the user interface, and installs the operating system on the second storage resource.
  • This realizes a visual operation for operating system installation, which is convenient for users to install and improves the user experience.
  • the first electronic device After receiving the unmounting request carrying identification information and the storage resource identifier corresponding to the first storage resource, the first electronic device responds to the request, determines that the first virtual machine has mounted the first storage resource based on the identification information and the storage resource identifier, and then unmounts the first storage resource, so that the system can release the used storage resources in a timely manner and improve the resource recycling rate.
  • the first electronic device When unmounting the first storage resource, the first electronic device obtains its configuration file while the first virtual machine is powered off.
  • This file contains storage resource information such as the storage resource identifiers and startup order corresponding to the first and second storage resources.
  • the storage resource identifier corresponding to the first storage resource is deleted from the storage resource information, and the startup order corresponding to the second storage resource is restored.
  • the unmounting operation is completed accurately, and the first virtual machine is restored to the initial storage resource configuration state, ensuring the stability and repeatability of the system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种镜像文件的导入方法，由第二电子设备执行，包括：获取请求将第一镜像文件导入第一虚拟机的导入请求，导入请求携带第一虚拟机的标识信息，以及第一镜像文件的存储路径信息(S201)；基于存储路径信息获取与第一镜像文件匹配的第一存储资源，并将第一存储资源挂载到运行第一虚拟机的第一电子设备上(S202)；及向第一电子设备发送挂载请求，挂载请求用于指示第一电子设备基于存储路径信息将第一镜像文件下载到第一存储资源中，并将第一存储资源挂载到第一虚拟机上，以通过第一虚拟机加载并运行第一镜像文件(S203)。

Description

镜像文件的导入方法、装置、设备、存储介质及产品
相关申请
本申请要求2024年06月15日申请的，申请号为202410773546.4，名称为“镜像文件的导入方法、装置、设备、存储介质及产品”的中国专利申请的优先权，在此将其全文引入作为参考。
技术领域
本申请涉及计算机技术领域，具体涉及一种镜像文件的导入方法、装置、设备、存储介质及产品。
背景技术
随着计算机技术的发展，云技术因其动态扩展、高效管理以及安全可靠等特点，逐渐被广泛应用于各个领域。其中，云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。云技术通常与虚拟机(Virtual Machine)技术结合，能够通过软件模拟完整计算机系统，在同一台物理服务器上创建多个相互独立、完全隔离的计算机环境。
虚拟机技术的关键在于虚拟机镜像，它是虚拟机启动和运行的基础。为了满足用户的多样化需求，用户通常可以自定义虚拟机镜像，这些自定义镜像是以国际标准化组织(International Organization for Standardization，ISO)格式存储在镜像文件中的。而在基于内核的虚拟机(Kernel-based Virtual Machine，KVM)和快速模拟器(Quick EMUlator)的hypervisor虚拟化系统中，仅支持qcow2、raw、vhd等格式的镜像文件，不直接支持ISO格式的镜像文件，导致用户需要进行格式转换操作，使得镜像文件的导入较为繁琐，导入效率低。
发明内容
本申请实施例提供了一种镜像文件的导入方法、装置、设备、存储介质和产品，可以在不对镜像文件进行格式转换操作的前提下，实现特定格式镜像文件的导入，使得导入操作更为简便，也在一定程度上提高了镜像文件的导入效率。
第一方面，本申请实施例提供了一种镜像文件的导入方法，由第二电子设备执行，包括：
获取请求将第一镜像文件导入第一虚拟机的导入请求，所述导入请求携带第一虚拟机的标识信息，以及所述第一镜像文件的存储路径信息；
基于所述存储路径信息获取与所述第一镜像文件匹配的第一存储资源，并将所述第一存储资源挂载到运行所述第一虚拟机的第一电子设备上；及
向所述第一电子设备发送挂载请求，所述挂载请求用于指示所述第一电子设备基于所述存储路径信息将所述第一镜像文件下载到所述第一存储资源中，并将所述第一存储资源挂载到所述第一虚拟机上，以通过所述第一虚拟机加载并运行所述第一镜像文件。
第二方面，本申请实施例提供了一种镜像文件的导入方法，由第一电子设备执行，包括：
接收来自第二电子设备的挂载请求，所述挂载请求携带第一虚拟机的标识信息、第一存储资源对应的存储资源标识和第一镜像文件的存储路径信息；
响应于所述挂载请求，基于所述存储路径信息将所述第一镜像文件下载到所述存储资源标识指示的所述第一存储资源中，并将所述第一存储资源挂载到所述第一虚拟机上；及
通过所述第一虚拟机加载并运行所述第一镜像文件，将所述第一镜像文件中承载的操作系统安装在所述第一虚拟机内部的第二存储资源中；
其中，所述挂载请求是所述第二电子设备响应于请求将所述第一镜像文件导入第一虚拟机的导入请求，基于所述存储路径信息获取与第一镜像文件匹配的所述第一存储资源，并将所述第一存储资源挂载到运行所述第一虚拟机的第一电子设备上之后，向所述第一电子设备发送的。
第三方面，本申请实施例提供了一种镜像文件的导入装置，包括：
获取单元，用于获取请求将第一镜像文件导入第一虚拟机的导入请求，所述导入请求携带第一虚拟机的标识信息，以及所述第一镜像文件的存储路径信息；基于所述存储路径信息获取与所述第一镜像文件匹配的第一存储资源，并将所述第一存储资源挂载到运行所述第一虚拟机的第一电子设备上；及
发送单元，用于向所述第一电子设备发送挂载请求，所述挂载请求用于指示所述第一电子设备基于所述存储路径信息将所述第一镜像文件下载到所述第一存储资源中，并将所述第一存储资源挂载到所述第一虚拟机上，以通过所述第一虚拟机加载并运行所述第一镜像文件。
第四方面，本申请实施例提供了一种镜像文件的导入装置，包括：
接收单元，用于接收来自第二电子设备的挂载请求，所述挂载请求携带第一虚拟机的标识信息、第一存储资源对应的存储资源标识和第一镜像文件的存储路径信息；
下载单元，用于响应于所述挂载请求，基于所述存储路径信息将所述第一镜像文件下载到所述存储资源标识指示的所述第一存储资源中，并将所述第一存储资源挂载到所述第一虚拟机上；及
加载单元，用于通过所述第一虚拟机加载并运行所述第一镜像文件，将所述第一镜像文件中承载的操作系统安装在所述第一虚拟机内部的第二存储资源中；
其中，所述挂载请求是所述第二电子设备响应于请求将所述第一镜像文件导入第一虚拟机的导入请求，基于所述存储路径信息获取与第一镜像文件匹配的所述第一存储资源，并将所述第一存储资源挂载到运行所述第一虚拟机的第一电子设备上之后，向所述第一电子设备发送的。
第五方面，本申请实施例提供了一种电子设备，该电子设备包括一个或多个处理器；存储器，用于存储一个或多个计算机程序，当所述一个或多个计算机程序被所述一个或多个处理器执行时，使得所述电子设备实现上述第一方面，或者第二方面的镜像文件的导入方法。
第六方面，本申请实施例提供了一种计算机可读存储介质，上述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面，或者第二方面的镜像文件的导入方法。
第七方面，本申请实施例提供一种计算机程序产品，上述计算机程序产品包括计算机程序或计算机指令，上述计算机程序或计算机指令被处理器执行时实现如第一方面，或者第二方面的镜像文件的导入方法。
本申请的一个或多个实施例的细节在下面的附图和描述中提出。本申请的其它特征、目的和优点将从说明书、附图以及权利要求书变得明显。
附图说明
为了更清楚地说明本申请实施例或传统技术中的技术方案，下面将对实施例或传统技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据公开的附图获得其他的附图。
图1是本申请实施例提供的一种镜像文件的导入系统的架构示意图；
图2是本申请实施例提供的一种镜像文件的导入方法的流程示意图；
图3是本申请实施例提供的一种控制台的用户界面的示意图；
图4是本申请实施例提供的一种输入镜像文件的系统信息的用户界面的示意图；
图5是本申请实施例提供的第二电子设备中接入层模块执行的时序示意图；
图6是本申请实施例提供的第一电子设备执行挂载过程的时序示意图；
图7是本申请实施例提供的一种安装第一镜像文件承载的操作系统的用户界面的示意图；
图8是本申请实施例提供的一种加载第四存储资源承载的驱动程序的用户界面的示意图；
图9为本申请实施例提供的一种将镜像文件导入第一虚拟机的架构示意图；
图10是本申请实施例提供了一种镜像文件的导入方法的另一流程示意图；
图11是本申请实施例提供的一种第二电子设备中接入层模块执行的另一时序示意图；
图12是本申请实施例提供的第一电子设备执行解挂过程的时序示意图；
图13为本申请实施例提供的一种将镜像文件导入第一虚拟机的另一架构示意图；
图14是本申请实施例提供的一种镜像文件导入第一虚拟机的时序示意图；
图15是本申请实施例提供的一种镜像文件的导入装置的结构示意图；
图16是本申请实施例提供的另一种镜像文件的导入装置的结构示意图；
图17是本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请实施例中，术语“模块”或“单元”是指有预定功能的计算机程序或计算机程序的一部分，并与其他相关部分一起工作以实现预定目标，并且可以通过使用软件、硬件(如处理电路或存储器)或其组合来全部或部分实现。同样的，一个处理器(或多个处理器或存储器)可以用来实现一个或多个模块或单元。此外，每个模块或单元都可以是包含该模块或单元功能的整体模块或单元的一部分。
需要说明的是：在本文中提及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
在对虚拟机进行镜像文件的导入过程中发现：为了满足不同用户的多样化需求，用户通常可以自定义虚拟机镜像，即在特定格式的镜像文件上进行自定义安装操作系统，从而得到自定义的虚拟机镜像，例如安装有麒麟操作系统的镜像Kylin.iso，安装有统信操作系统的镜像UOS.iso。由于这些自定义的镜像是在特定格式的镜像文件上安装操作系统得到的，因此得到的镜像文件的格式也为特定格式的，即ISO格式。而在KVM和QEMU的hypervisor虚拟化系统中，仅支持qcow2、raw、vhd等格式的镜像文件，不能直接支持ISO格式的镜像文件，导致用户要对ISO格式的镜像文件进行额外的格式转换操作，例如借助第三方工具或者平台(如VirtualBox)安装操作系统，再将ISO格式的镜像文件转换为QEMU支持格式的镜像文件，如qcow2、raw、vhd等格式的镜像文件，才能将其导入虚拟机，无法直接在云计算服务提供的控制台中直接完成ISO格式的镜像文件的导入，使得镜像文件的导入流程较为繁琐，导入的效率低。
基于此，本申请实施例提供了一种镜像文件的导入方法，可以通过将存储资源挂载到电子设备上，使得电子设备可以下载特定格式的镜像文件到所挂载的存储资源中，并进一步可以将该存储资源挂载到所运行的虚拟机上，进而通过虚拟机加载并运行所挂载的存储资源中的镜像文件。由此，基于该自动化实现的产品级方案，可以在不需要进行格式转换操作，且不借助第三方工具或平台的情况下，完成特定格式的镜像文件的导入，使得镜像文件的导入更为方便，有利于提升特定格式的镜像文件的导入能力和效率，特别是提高云环境中ISO格式的镜像文件的导入能力和效率，能够为虚拟化环境的管理和部署带来了便利，也能在一定程度上满足使用私有云的用户的多样化的用户需求。
本申请实施例提出的镜像文件的导入方法涉及云技术、云计算以及云存储、等技术，其中：
云技术(Cloud technology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。
云技术(Cloud technology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将成为重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。
云计算(Cloud Computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。
作为云计算的基础能力提供商，会建立云计算资源池(简称云平台)，一般称为基础设施即服务(Infrastructure as a Service，IaaS)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。
按照逻辑功能划分,在IaaS层上可以部署平台即服务(Platform as a Service，PaaS)层，PaaS层之上再部署软件即服务(Software as a Service，SaaS)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的业务软件，如web门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。
云存储(Cloud Storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。
目前，存储系统的存储方法为：创建逻辑卷，在创建逻辑卷时，就为每个逻辑卷分配物理存储空间，该物理存储空间可能是某个存储设备或者某几个存储设备的磁盘组成。客户端在某一逻辑卷上存储数据，也就是将数据存储在文件系统上，文件系统将数据分成许多部分，每一部分是一个对象，对象不仅包含数据而且还包含数据标识等额外的信息，文件系统将每个对象分别写入该逻辑卷的物理存储空间，且文件系统会记录每个对象的存储位置信息，从而当客户端请求访问数据时，文件系统能够根据每个对象的存储位置信息让客户端对数据进行访问。
存储系统为逻辑卷分配物理存储空间的过程，具体为：按照对存储于逻辑卷的对象的容量估量(该估量往往相对于实际要存储的对象的容量有很大余量)和独立冗余磁盘阵列(Redundant Array of Independent Disk，RAID)的组别，预先将物理存储空间划分成分条，一个逻辑卷可以理解为一个分条，从而为逻辑卷分配了物理存储空间。
基于上述描述，本申请实施例提供了一种镜像文件的导入方案，可以在不借助第三方工具，不需要格式转换操作的前提下导入特定格式的镜像文件。请参阅图1，图1是本申请实施例提供的一种镜像文件的导入系统的架构示意图，如图1所示，该镜像文件的导入系统包括控制台设备101、虚拟机平台设备102以及虚拟机母机设备103。其中，控制台设备101可以与虚拟机平台设备102通过有线或无线的方式进行直接或者间接的连接，虚拟机平台设备102也可以和虚拟机母机设备103通过有线或无线的方式进行直接或者间接的连接。需要说明的是，图1所示的设备数量和形态用于举例，并不构成对本申请实施例的限定。图1以虚拟机母机设备103为多个设备为例进行绘制和讲解。在一些实施例中，虚拟机平台设备102可以和虚拟机母机设备103为同一电子设备。母机设备，是指运行虚拟机的电子设备，如虚拟机平台设备102与多个虚拟机母机设备103连接，其中虚拟机母机设备103为运行虚拟机的电子设备，可称为母机。
其中，控制台设备101、虚拟机平台设备102以及虚拟机母机设备103均为电子设备。控制台设备101具体可以是终端设备，终端设备可以包括但不限于：智能手机(如Android手机、IOS手机等)、平板电脑、便携式个人计算机、移动互联网设备(Mobile Internet Devices，MID)、智能语音交互设备、智能家电、车载终端、飞行器、可穿戴设备等，本申请实施例对此不做限定；控制台设备101、虚拟机平台设备102以及虚拟机母机设备103具体可以是服务器，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器，本申请实施例对此不做限定。
本申请提供的镜像文件的导入方法的大致流程如下：
控制台设备101可以是运行控制台程序的电子设备，该控制台程序可以是用于管理云计算的计算资源的平台。该控制台设备101可以显示包括各个虚拟机的信息的用户界面，例如图1所示，该用户界面可以包括虚拟机标识、系统架构和运行状态等信息。用户可以通过该用户界面选择一个第一虚拟机作为导入镜像文件的虚拟机，如虚拟机A，并输入想要导入的特定格式的镜像文件的存储路径信息，以触发控制台设备101根据该第一虚拟机的标识信息、第一镜像文件的存储路径信息生成请求将第一镜像文件导入第一虚拟机的导入请求。进而，该控制台设备101可以将该请求将第一镜像文件导入第一虚拟机的导入请求发送至虚拟机平台设备102。
虚拟机平台设备102可以获取来自控制台设备101发送的请求将第一镜像文件导入第一虚拟机的导入请求，该导入请求携带第一虚拟机的标识信息，如上述虚拟机A，以及该第一镜像文件的存储路径信息，该标识信息所指示的虚拟机可以运行在虚拟机母机设备103上。进而，虚拟机平台设备102可以基于存储路径信息获取与第一镜像文件匹配的第一存储资源，并将该第一存储资源挂载到虚拟机母机设备103上。该虚拟机平台设备102可以进一步根据第一虚拟机的标识信息、第一存储资源对应的存储资源标识，以及第一镜像文件的存储路径信息生成挂载请求，并向虚拟机母机设备103发送挂载请求。
虚拟机母机设备103可以接收该挂载请求，响应于该挂载请求，基于存储路径信息将第一镜像文件下载到存储资源标识所指示的第一存储资源中，并将第一存储资源挂载到第一虚拟机上。进而，该虚拟机母机设备103可以通过虚拟机加载并运行存储在第一存储资源中存储的第一镜像文件，将第一镜像文件中承载的操作系统安装到该虚拟机内部的第二存储资源中，从而在不进行格式转换操作，且不借助第三方工具和平台的基础上完成了特定格式镜像文件的导入。
在一个实现方式中，上述第一镜像文件、第一虚拟机的标识信息、第一存储资源对应的存储资源标识、第一镜像文件的存储路径信息均可以保存在区块链中，可以防止第一镜像文件、第一虚拟机的标识信息、第一存储资源对应的存储资源标识、第一镜像文件的存储路径信息被篡改。其中，区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式，其本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。
可以理解的是，本申请实施例描述的镜像文件的导入系统是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
基于上述镜像文件的导入系统，请参阅图2，图2是本申请实施例提供了一种镜像文件的导入方法的流程示意图，该镜像文件的导入方法可由第一电子设备和第二电子设备交互实现。其中，第一电子可以是图1所示的虚拟机母机设备103，第二电子设备可以是图1所示的虚拟机平台设备102，该镜像文件的导入方法可以包括以下步骤S201-S205，其中：
S201、第二电子设备获取请求将第一镜像文件导入第一虚拟机的导入请求，导入请求携带第一虚拟机的标识信息，以及第一镜像文件的存储路径信息。
在本申请实施例中，镜像文件也可以称为映像文件，是一种将特定的一系列文件按照一定的格式制作成单一的文件，该一系列文件例如可以是一个操作系统等，以便用户下载和使用。第一镜像文件可以是指虚拟机所使用的磁盘映像文件，其承载有虚拟机所需的操作系统，通常用于用户创建和管理虚拟机实例。可选地，该第一镜像文件还可以承载虚拟机所需的应用程序和数据等，具体可由用户自定义配置。其中，该第一镜像文件的格式为特定格式，这是由于该第一镜像文件是用户在特定格式的镜像文件上自定义安装操作系统得到的。特定格式可以理解为KVM和QEMU的hypervisor虚拟化系统中不直接支持的格式，例如qcow2、raw、vhd等格式，该特定格式例如可以是ISO格式。
需要说明的是，由于镜像文件为ISO格式，且该镜像文件是被虚拟机用来安装操作系统的，因此，在本申请实施例中，镜像文件也可以称为ISO镜像、ISO镜像操作系统、虚拟机镜像等，可以理解的是，虽然名词的称谓不同，但是其所代表的含义相同。
其中，请求将第一镜像文件导入第一虚拟机的导入请求是指将ISO格式的第一镜像文件导入KVM和QEMU的hypervisor虚拟化系统的请求，该导入请求具体可以是指将第一镜像文件导入虚拟机中，即虚拟机运行并加载该第一镜像文件，可以安装该第一镜像文件中承载的操作系统。具体地，该导入请求携带第一虚拟机的标识信息，以及第一镜像文件的存储路径信息。其中，第一虚拟机是指用于安装第一镜像文件所承载的操作系统的虚拟机，为已创建的多个虚拟机中的任一个虚拟机。第一虚拟机的标识信息可以是该第一虚拟机的虚拟机标识(Identification，ID)，为用于指示某一个虚拟机的信息。第一镜像文件的存储路径信息例如可以是该第一镜像文件的下载链接，基于该存储路径信息电子设备可以获取到该第一镜像文件。
在一种可能的实现方式中，用户可以将第一镜像文件上传至预配置的存储资源中，得到该存储资源返回的存储路径信息。在云计算服务中，存储路径信息可以选择为对象存储服务提供的统一资源定位系统(Uniform Resource Locator，URL)链接(即下载链接)。用户可以将第一镜像文件上传至云上对象存储桶(Object Storage Bucket)中，该云上对象存储桶为云计算服务提供的用于存储和检索云数据对象的容器，其可提供基于超文本传输协议(Hypertext Transfer Protocol，HTTP)/超文本传输安全协议(Hypertext Transfer Protocol Secure，HTTPS)的网页服务接口。也就是说，用户可以将第一镜像文件上传到云上对象存储桶中，该云上对象存储桶可以生成一个可基于HTTP的下载链接，该链接即为该第一镜像文件的存储路径信息。
可选地，用户也可以将该第一镜像文件上传至镜像存储仓库中，得到镜像存储仓库返回的存储路径信息，即下载链接。其中，镜像存储仓库也可以称为镜像文件存储仓库、镜像仓库等，可以用于存储多个镜像文件，用户可以将第一镜像文件存储在私有的镜像空间中，以确保私有镜像的安全性。
其中，该请求将第一镜像文件导入第一虚拟机的导入请求可以是用户在控制台设备发起的，通过控制台设备的控制，借助一个已创建的虚拟机来完成第一镜像文件的导入。其中，该控制台设备可以是运行控制台程序(简称为控制台)的设备，控制台为云环境(云技术)提供的一种用于管理云计算的资源的平台，该平台可以提供类似网页或者应用程序的用户界面。用户可以通过控制台设备与所提供的用户界面进行交互，基于该用户界面进行创建、配置和管理虚拟机，并且基于该用户界面，用户还可以获取到已创建的各个虚拟机的运行状态。
请一并参阅图3，图3是本申请实施例提供的一种控制台的用户界面的示意图，该用户界面可以称为虚拟机管理页面，如图3所示，该用户界面可以包括多个已创建的虚拟机的信息，例如具体可以包括用户可以操作的控件，如刷新、创建/注册虚拟机、关机、挂起等控件。虚拟机的信息可以包括虚拟机的标识信息，如虚拟机A-虚拟机F；虚拟机的系统架构，如x86_64、arm64等；虚拟机运行的操作系统，如Centos、Linux、Kylin、Windows等；虚拟机的已用空间，如32GB等；运行虚拟机的电子设备标识，其中，运行虚拟机的电子设备可以称为母机，则运行虚拟机的电子设备标识例如可以是母机A-母机D等；各个虚拟机的运行状态，如挂载中、已挂载、执行xx任务、关机等。该用户界面还可以包括针对已创建的虚拟机，如虚拟机A-虚拟机F所指示的虚拟机进行操作的控件，如挂载、解挂控件。可以理解的是，挂载可以是指在虚拟机上挂载存储资源，解挂为将挂载在虚拟机上的存储资源进行卸载。
具体地，用户可以通过针对某一个虚拟机对应挂载控件触发镜像文件导入请求，例如，用户针对虚拟机D对应的挂载控件输入触发操作，如点击操作，则该虚拟机D所指示的虚拟机为第一虚拟机。进而，控制台设备响应于该触发操作，可以输出一个包括多个输入控件的用户界面，这些输入控件可以用于用户输入想要导入的镜像文件的系统信息，该镜像文件的系统信息也可以称为ISO镜像的参数信息。其中，用户在虚拟机管理页面中选择虚拟机的操作可以理解为用户可视化操作方式一个虚拟机挂载镜像文件，即可视化操作方式一个虚拟机挂载ISO格式的镜像文件。
请一并参阅图4，图4是本申请实施例提供的一种输入镜像文件的系统信息的用户界面的示意图，如图4所示，该用户界面可以包括多个输入框和选择框，该输入框和选择框作为输入控件可以用于用户输入镜像文件的系统信息。该镜像文件的系统信息可以具体包括虚拟机的标识信息，如虚拟机ID，例如上述用户选择的虚拟机D。该系统信息也可以包括镜像文件的存储路径信息，如镜像文件下载链接。该系统信息还可以包括镜像文件对应的系统类型，如镜像文件系统类型，例如可以是Centos、Kylin等。该系统信息还可以包括镜像文件对应的系统架构，如镜像文件系统架构，如x86_64、arm64等。该系统信息还可以包括镜像文件对应的系统版本等，如镜像文件系统版本，例如可以是7.0、10.0等。具体地，该镜像文件的系统信息的输入语法可以参见表1所示：
表1
进一步地，在用户基于用户界面中提供的输入控件输入镜像文件的系统信息之后，可以通过如图4所示的“确定”控件触发控制台设备可以根据想要导入的第一镜像文件的系统信息生成请求将第一镜像文件导入第一虚拟机的导入请求。进而控制台设备可以向云环境中提供云计算管理服务的电子设备(第二电子设备)发送该导入请求，该导入请求可以携带该第一虚拟机的标识信息，以及第一镜像文件的系统信息。进而，第二电子设备可以获取来自控制台设备的请求将第一镜像文件导入第一虚拟机的导入请求，并从该导入请求中获取第一虚拟机的标识信息和第一镜像文件的系统信息，以实现包括第一镜像文件的存储路径信息等系统信息的传递，进而第二电子设备可以将该第一镜像文件的系统信息存储在数据库中，以便后续处理。
在一种可能的实现方式中，第二电子设备为云环境中提供云计算管理服务的电子设备，该第二电子设备可以包括接入层模块，该接入层模块可以运行配置的程序，也可以提供应用程序编程接口(Application Programming Interface，API)给控制台设备调用，该程序和API所涉及的程序代码运行在第二电子设备上。也就是说，控制台设备可以调用该第二电子设备中的接入层模块提供的API在控制台设备上以可视化操作方式选择用于导入镜像文件的虚拟机，并向第二电子设备发送该请求将第一镜像文件导入第一虚拟机的导入请求。第二电子设备可以基于该API提供的HTTP服务，获取请求将第一镜像文件导入第一虚拟机的导入请求。其中，该导入请求可以称为挂载ISO镜像请求，该API可以称为挂载ISO镜像API，导入请求所携带的镜像文件的系统信息可以称为挂载ISO镜像API的参数。
接入层模块，是指第二电子设备中运行配置程序、提供应用程序编程接口(API)给控制台设备调用的模块，该模块所涉及的程序代码运行在第二电子设备上，用于与控制台设备进行交互、完成参数透传等操作。
S202、第二电子设备基于存储路径信息获取与第一镜像文件匹配的第一存储资源，并将第一存储资源挂载到运行第一虚拟机的第一电子设备上。
第一镜像文件(The first mirror file)，是指虚拟机所使用的磁盘映像文件，其承载有虚拟机所需的操作系统，通常用于用户创建和管理虚拟机实例，格式为特定格式(如ISO格式)，该特定格式是KVM和QEMU的hypervisor虚拟化系统中不直接支持的格式。该第一镜像文件还可承载虚拟机所需的应用程序和数据等，具体可由用户自定义配置。
在本申请实施例中，第一存储资源可以是云计算服务提供的存储资源，如云计算服务提供的云盘，也可以例如是可以用于存储数据的磁盘等，本申请对此不做限定。本申请实施例以云盘为例进行讲解，与第一镜像文件匹配的第一存储资源可以是指与该第一镜像文件的文件大小匹配的云盘，例如第一镜像文件的文件大小与第一存储资源的大小相同，或者第一镜像文件的文件大小略小于第一存储资源的大小(例如第一镜像文件的文件大小为第一存储资源大小的80％-95％)，即第一存储资源的大小取决于该第一镜像文件(ISO格式的镜像文件)的大小，以在存储第一镜像文件的同时减少资源的浪费。
其中，挂载(Mounting)是指操作系统使存储资源(如硬盘、云盘等)上的计算机文件和目录可供用户通过电子设备的文件系统访问的过程。例如，在windows操作系统中：挂载通常是指给磁盘分区(包括被虚拟出来的磁盘分区)分配一个盘符。在Linux操作系统中：挂载通常是指将一个电子设备上的存储设备挂接到一个已存在的目录上。将第一存储资源挂载到运行第一虚拟机的第一电子设备上，可以理解为通过第一电子设备上连接了一个外部的存储资源，通过第一电子设备的文件系统可以识别到该第一存储资源，并访问该第一存储资源内存储的数据。
在一种可能的实现方式中，第二电子设备可以基于存储路径信息确定第一镜像文件的文件大小，可以理解的是，由于第一镜像文件的存储路径信息为一个可基于HTTP的下载链接，基于HTTP协议中的某些特性，如HTTP HEAD请求，可以允许第二电子设备在不下载第一镜像文件的情况下，获取关于该第一镜像文件的元信息，该元信息中包括该第一镜像文件的文件大小。在第二电子设备获取到第一镜像文件的文件大小之后，可以根据第一镜像文件的文件大小从预设存储资源中划分出与第一镜像文件大小匹配的存储资源，得到第一存储资源。其中，预设存储资源可以是云计算服务提供的存储资源总和，根据第一镜像文件大小可以从预设存储资源中获取第一镜像文件大小匹配的存储资源。预设存储资源，是指云计算服务提供的存储资源总和，第二电子设备可根据第一镜像文件大小从中划分出与第一镜像文件匹配的第一存储资源。
具体地，第二电子设备中可以包括调度层模块，该调度层模块可以运行配置的程序，该程序所涉及的程序代码也运行在第二电子设备上，该程序可以用于调用云硬盘服务提供的API创建(申请)存储资源，得到第一存储资源。该云硬盘服务可以理解为提供从预设存储资源中划分存储资源的程序，可以提供API给调度层调用。其中，调度层模块和接入层模块可以称为第二电子设备中的控制模块，调度层模块可以与接入层模块通过配置的接口进行通信。在接入层模块获取到来自控制台设备发送的请求将第一镜像文件导入第一虚拟机的导入请求(即挂载ISO镜像请求)后，接入层模块可以将该导入请求(挂载ISO镜像请求)传输至调度层模块。进而，该调度层模块响应于该导入请求，可以基于导入请求携带的存储路径信息获取第一镜像文件的文件大小，并根据该第一镜像文件的文件大小调用云硬盘服务提供的API创建(申请)与第一镜像文件的文件大小匹配的存储资源，得到第一存储资源。
进一步地，该调度层模块可以将获取到的第一存储资源挂载到运行第一虚拟机的电子设备上。具体地，调度层模块可以获取虚拟机标识信息与电子设备标识信息之间的对应关系，进而根据该对应关系和第一虚拟机的标识信息，确定该表示信息对应的目标标识信息。也就是说，调度层模块可以获取各个虚拟机与运行各个虚拟机的电子设备之间的对应关系表，进而可以根据第一虚拟机的虚拟机ID查询到该第一虚拟机所在的电子设备ID，即该第一虚拟机所在的母机ID。在调度层模块查询到第一虚拟机所在的电子设备ID后，可以将该第一存储资源挂载到该目标标识信息所指示的第一电子设备上。目标标识信息，是指调度层模块根据虚拟机标识信息与电子设备标识信息之间的对应关系，以及第一虚拟机的标识信息所确定的，用于指示运行第一虚拟机的第一电子设备的标识信息。
其中，调度层模块还可以维护一个用于存储各个虚拟机的运行状态的数据库，虚拟机的运行状态例如可以是挂载中、已挂载、执行xx任务、关机等等，该数据库中可以包括各个虚拟机的标识信息与其对应的运行状态。调度层模块可以通过与运行各个虚拟机所在的电子设备(各个母机)进行实时的交互，由各个母机获取所运行的虚拟机的状态后，可以传输至调度层模块，以使调度层模块更新数据库中存储的各个虚拟机的状态。可以理解的是，在控制台设备显示的如图3所示的用户界面中，虚拟机A-虚拟机F的运行状态的数据来源可以是该调度层模块维护的数据库中存储的各个虚拟机的运行状态。
在一种可能的实现方式中，第二电子设备在将第一存储资源挂载到运行第一虚拟机的第一电子设备上的过程中，可以通过第二电子设备中的接入层模块先根据标识信息获取第一虚拟机当前的运行状态，该接入层模块具体可以通过在调度层模块维护的数据库中查询该标识信息对应的运行状态，得到该第一虚拟机当前的运行状态。进而，该接入层模块可以基于第一虚拟机当前的运行状态与预设运行状态集合中的运行状态进行比对，在第一虚拟机当前的运行状态为预设运行状态集合中的运行状态的情况下，接入层模块可以获取第一虚拟机对应的系统架构信息，以进行进一步的处理。也就是说，接入层模块仅在校验出第一虚拟机当前的运行状态为预设运行状态集合中的某一个运行状态的情况下，才可以进行进一步的校验。
其中，预设运行状态集合，是指包含关机状态、执行xx任务状态(运行中状态)等运行状态的集合，只有处于该集合中运行状态的虚拟机才可以导入镜像文件，处于集合以外运行状态的虚拟机可能因运行子任务而出现导入异常。这是由于只有处于关机状态或者运行中状态的虚拟机才可以导入镜像文件，处于其他运行状态的虚拟机可以存在运行子任务的情况，容易出现导入异常，所以在校验出第一虚拟机处于预设运行状态集合以外的运行状态时，确定该第一虚拟机无法进行镜像文件的导入。可选地，接入层模块可以触发可以在控制台设备显示的用户界面中输出用于提示用户该第一虚拟机无法导入镜像文件的提示信息，以指示用户可以再次选择一个虚拟机作为导入镜像文件的虚拟机。
进一步地，在接入层模块判断出第一虚拟机当前的运行状态为预设运行状态集合中的运行状态的情况下，接入层模块可以获取第一虚拟机对应的系统架构信息，第一虚拟机对应的系统架构信息可以是创建该第一虚拟机所配置的系统架构信息。其中，各个虚拟机的配置信息也可以存储在数据库中，接入层模块可以通过第一虚拟机的标识信息在数据库中查询得到该第一虚拟机的配置信息，该配置信息中可以包括第一虚拟机对应的系统架构信息，如x86_64、arm64等。进而，接入层模块可以获取该导入请求中携带的第一镜像文件的系统信息，该系统信息包括第一镜像文件对应的系统架构信息，并校验第一虚拟机对应的系统架构信息与第一镜像文件对应的系统架构信息是否一致，在校验出第一虚拟机对应的系统架构信息与第一镜像文件对应的系统架构信息相同的情况下，可以将第一存储资源挂载到第一电子设备上，也即是通过调度层模块将第一存储资源挂载到第一电子设备上。
可以理解的是，在第一虚拟机对应的系统架构信息与第一镜像文件对应的系统架构信息不相同的情况下，虚拟机无法加载并运行第一镜像文件，即虚拟机无法基于该第一镜像文件从关机状态启动。由此，接入层模块可以确定该第一虚拟机无法进行镜像文件的导入。可选地，接入层模块也可以触发在控制台设备显示的用户界面中输出用于提示用户该第一虚拟机无法导入镜像文件的提示信息，以指示用户可以再次选择一个虚拟机作为导入镜像文件的虚拟机。
在一种实现方式中，在第一虚拟机对应的系统架构信息与第一镜像文件对应的系统架构信息相同的情况下，接入层模块可以向调度层模块通过调度层模块发送该导入请求，以使调度层模块基于存储路径信息获取与第一镜像文件匹配的第一存储资源，并将第一存储资源挂载到运行第一虚拟机的第一电子设备上。
在另一种实现方式中，在接入层模块接收到请求将第一镜像文件导入第一虚拟机的导入请求后，可以将该导入请求传输至调度层模块，以使调度层模块基于第一镜像文件的存储路径信息获取与第一镜像文件匹配的第一存储资源，进而在接入层模块校验出第一虚拟机的运行状态为预设运行状态集合中的运行状态，且第一虚拟机对应的系统架构信息与第一镜像文件对应的系统架构信息相同的情况下，可以向调度层模块发送指示信息，用于指示调度层模块将获取到的第一存储资源挂载到第一虚拟机的第一电子设备上。
其中，该第二电子设备中的接入层模块可以在触发通过调度层模块将第一存储资源挂载到运行第一虚拟机的第一电子设备上之后，更新该第一虚拟机的运行状态为挂载中，该运行状态用于指示该第一虚拟机在导入ISO格式的镜像文件。具体地，接入层模块可以通过调度层模块在存储有各个虚拟机的运行状态的数据库中更新该第一虚拟机对应的运行状态，例如将该第一虚拟机的标识信息对应的运行状态从关机状态更新为挂载中。可以理解的是，由于控制台设备所显示的用户界面中的各个虚拟机的运行状态的数据源为该数据库，因此在该数据库中的数据发生更新后，控制台设备所显示的用户界面也会一并发生更新，即用户界面中该第一虚拟机对应的运行状态也会更新为挂载中。
请一并参阅图5，图5是本申请实施例提供的第二电子设备中接入层模块执行的时序示意图，该接入层模块可以接收请求将第一镜像文件导入第一虚拟机的导入请求，该导入请求可以携带第一镜像文件对应的系统信息，以及第一虚拟机的标识信息，进而该接入层模块可以根据第一虚拟机的标识信息获取第一虚拟机当前的运行状态，并校验该第一虚拟机当前的运行状态是否为预设运行状态集合中的运行状态，如检查该第一虚拟机是否处于关机状态或者运行中状态。若得到的检查结果为是，则该接入层模块可以获取第一虚拟机对应的系统架构信息，并校验第一虚拟机对应的系统架构信息是否与第一镜像文件对应的系统架构信息相同，即检查该第一虚拟机对应的系统架构是否与第一镜像文件对应的系统架构一致，若检查结果仍为是，则该接入层模块可以更新第一虚拟机的运行状态为挂载中，并将该第一虚拟机的标识、第一镜像文件的系统信息传输至调度层模块。
其中，在接入层模块得到的检查结果为否，如检查出该第一虚拟机当前的运行状态不处于关机状态或者运行中状态，或者检查出该第一虚拟机对应的系统架构不与第一镜像文件对应的系统架构一致，则流程结束，接入层模块不进行进一步地处理。接入层模块将第一虚拟机的标识、第一镜像文件的系统信息传输至调度层模块的过程可以称为完成参数透传的过程，以调用该调度层模块进行进一步处理，如获取第一存储资源，并将第一存储资源挂载到第一电子设备上的处理。
S203、第二电子设备向第一电子设备发送挂载请求，挂载请求用于指示第一电子设备基于存储路径信息将第一镜像文件下载到第一存储资源中，并将第一存储资源挂载到第一虚拟机上，以通过第一虚拟机加载并运行第一镜像文件。
在本申请实施例中，第二电子设备在将第一存储资源挂载到运行第一虚拟机的第一电子设备上之后，可以向第一电子设备发送挂载请求，相应的，第一电子设备可以接收来自第二电子设备的挂载请求。该挂载请求可以用于指示第一电子设备基于存储路径信息将第一镜像文件下载到第一存储资源中，并将下载有第一镜像文件的第一存储资源挂载到第一虚拟机上，以通过第一虚拟机加载并运行第一镜像文件。
挂载请求，是指第二电子设备在将第一存储资源挂载到运行第一虚拟机的第一电子设备上之后，向第一电子设备发送的请求，用于指示第一电子设备基于存储路径信息将第一镜像文件下载到第一存储资源中，并将下载有第一镜像文件的第一存储资源挂载到第一虚拟机上，以通过第一虚拟机加载并运行第一镜像文件，该请求携带第一虚拟机的标识信息、第一存储资源对应的存储资源标识，以及第一镜像文件的存储路径信息。
其中，该挂载请求可以携带第一虚拟机的标识信息、第一存储资源对应的存储资源标识，以及第一镜像文件的存储路径信息。具体地，该第一虚拟机的标识信息用于指示第一电子设备中运行的某一个虚拟机，以便后续对该虚拟机进行处理，如挂载第一存储资源。第一电子设备可以基于第一存储资源对应的存储资源标识检查是否已挂载该第一存储资源。第一电子设备可以基于第一镜像文件的存储路径信息获取到该第一镜像文件。
S204、响应于挂载请求，第一电子设备基于存储路径信息将第一镜像文件下载到存储资源标识指示的第一存储资源中，并将第一存储资源挂载到第一虚拟机上。
在本申请实施例中，由于用户将第一镜像文件上传到云上对象存储桶中，或者上传到镜像存储仓库中，得到用于下载该第一镜像文件的存储路径信息，因此，第一电子设备可以基于存储路径下载第一镜像文件，例如，第一电子设备可以基于镜像存储仓库提供的下载链接从镜像存储仓库中下载该第一镜像文件。进而，第一电子设备可以识别到挂载在第一电子设备上的一个或多个存储资源，如磁盘、云盘等，则第一电子设备可以根据存储资源标识确定是否识别到第二电子设备(包括的调度层模块)获取到的第一存储资源，在确定识别到该第一存储资源的情况下，将下载的第一镜像文件存储在该第一存储资源中。其中，第一电子设备基于存储路径信息将第一镜像文件下载到第一存储资源中所执行的命令具体可以是：
Linux命令：wget-o/path/to/cloud_disk存储路径信息(下载链接)
在该命令中，wget可以用于从网络上下载文件，/path/to/cloud_disk用于指示将下载的第一镜像文件保存到某个目录中(如云盘cloud_disk)，存储路径信息为第一镜像文件对应的URL，如镜像存储仓库提供的下载链接，例如可以是http://example.com/path/to/iso_file.iso。
需要说明的是，在虚拟机环境中，挂载存储资源是指让虚拟机可以访问和操作额外的存储资源，将第一存储资源挂载到第一虚拟机上可以理解为将一个外部的存储资源(第一存储资源)，如第二电子设备获取到的云盘，作为第一虚拟机可以访问和操作的额外存储资源，第一虚拟机可以对所挂载的外部存储资源中的数据进行读写操作。
具体地，第一虚拟机所在的第一电子设备在将第一存储资源挂载到第一虚拟机上的过程中，第一电子设备可以对该第一虚拟机进行关机处理。需要说明的是，第一电子设备上运行有用于管理虚拟机的虚拟化软件libvirt，其是一个包括API库的平台，用于提供统一的接口和函数调用，第一电子设备可以调用该libvirt中的API可以用于执行各种虚拟机的管理操作，如关机、开机等。也就是说，该第一电子设备可以通过调用libvirt中的API对第一虚拟机进行关机处理。进而，在第一虚拟机处于关机状态的情况下，获取第一虚拟机的配置文件，具体地，该第一电子设备也可以通过调用libvirt中的API在第一虚拟机处于关机状态的情况下，获取第一虚拟机的配置文件，该配置文件可以是可扩展标记语言(eXtensible Markup Language，XML)格式的。
其中，该第一虚拟机的配置文件包括第一虚拟机的存储资源信息，存储资源信息可以理解为第一虚拟机可以访问和操作的一个或多个存储资源的信息。例如，第一电子设备获取到的存储资源信息包括第二存储资源对应的存储资源标识以及第二存储资源对应的启动顺序。其中，第二存储资源为第一虚拟机内部的存储资源，可以理解为第一虚拟机内部的系统磁盘，该第二存储资源可以用于存储第一虚拟机所运行的操作系统的数据和程序。第二存储资源的存储资源标识为用于指示该第二存储资源的标识信息，第二存储资源对应的启动顺序是指该第一虚拟机在从关机状态切换至开机状态时，也即是该第一虚拟机启动时，加载并运行的数据存储在的存储资源的顺序。
进一步地，第一电子设备可以修改配置文件，以实现将第一存储资源挂载到第一虚拟机上，由于该配置文件为XML格式，修改配置文件也可以称为修改虚拟机XML、修改虚拟机的XML等。具体地，第一电子设备可以在配置文件包括的存储资源信息中添加第一存储资源对应的存储资源标识，并将第一存储资源对应的启动顺序设置为第一位，且将第二存储资源对应的启动顺序修改为在第一位之后。也就是说，将第一存储资源对应的存储资源标识添加在配置文件中，可以使得该第一虚拟机挂载上该第一存储资源。调整该第一存储资源的启动数据，可以使得该第一虚拟机优先基于启动顺序为第一位的第一存储资源进行开机处理，即该第一虚拟机在开机时优先加载并运行存储在第一存储资源中的第一镜像文件。
具体地，对该第一虚拟机的配置文件进行修改的语法可以参见表2所示，表2包括针对第一虚拟机的XML格式的配置文件进行具体修改的修改项：
表2
在表2中，<devices>标签用于定义第一虚拟机的存储资源的配置部分，对于第一虚拟机内部的第二存储资源来说，即第一虚拟机内部的第二存储资源，<disk type＝'block'device＝'disk'>描述了一个磁盘，也即是本申请实施例中的第二存储资源，type＝'block'表示这是一个块设备，device＝'disk'表示它是一个硬盘。<driver name＝'qemu'type＝'raw'cache＝'none'io＝'native'iothread＝'1'/>描述了磁盘的驱动设置，name＝'qemu'表示是QEMU模拟的磁盘，type＝'raw'表示磁盘文件是原始格式(未分区或未格式化的)，cache＝'none'表示不使用磁盘缓存，io＝'native'表示使用原生的输入输出(Input/Output，I/O)方式，iothread＝'1'表示磁盘I/O操作在一个单独的线程上执行。<source dev＝'/dev/disk/第一虚拟机的第二存储资源'/>描述了磁盘的来源，即第二存储资源的来源，其中，“/dev/disk/第一虚拟机的第二存储资源”是第二存储资源的来源的示例路径。<target dev＝'vda'bus＝'virtio'/>定义了第一虚拟机中看到的磁盘设备。dev＝'vda'是第一虚拟机中的设备名，bus＝'virtio'表示使用virtio总线类型。<shareable/>表示该第二存储资源可以被多个虚拟机共享。<boot order＝'9'/>定义了第二存储资源在第一虚拟机启动时的顺序。order＝'9'表示第二存储资源是排在第九位启动。<address type＝'pci'domain＝'0x0000'bus＝'0x00'slot＝'0x06'function＝'0x0'/>定义了在外设部件互连标准(Peripheral Component Interconnect，PCI)总线上的地址。
对于第一虚拟机新挂载的第一存储资源来说，在该<devices>标签下，<disk type＝'block'device＝'cdrom'>描述一个新的磁盘设备，即第一存储资源，是一个光驱(cdrom)。<driver name＝'qemu'type＝'raw'/>描述了磁盘的驱动设置，name＝'qemu'表示是QEMU模拟的磁盘，type＝'raw'表示磁盘文件是原始格式，需要说明的是，光驱通常不需要特别进行缓存或者I/O设置。<source dev＝'/dev/disk/云盘id'/>定义了光驱的来源，即“/dev/disk/云盘id”为第一存储资源的来源的示例路径。<target dev＝'hdc'bus＝'ide'/>表示在该第一虚拟机中，第一存储资源被命名为hdc，并使用集成设备电路(Integrated Device Electronics，IDE)总线。<readonly/>表示该第一存储资源将以只读方式挂载到该第一虚拟机上。<boot order＝'1'/>表示第一存储资源在第一虚拟机启动时的顺序为第一位。<address type＝'drive'controller＝'0'bus＝'1'target＝'0'unit＝'0'/>定义了在IDE总线上的地址。最后，</devices>结束设备配置部分。
也就是说，第一电子设备可以通过在第一虚拟机的配置文件中的devices标签下新增一块disk，该设备路径source dev即为存储有第一镜像文件的第一存储资源的路径，即下载有ISO格式的镜像文件的云盘的路径。并且，第一电子设备可以指定该第一存储资源的boot order为1，即优先采用该第一存储资源中的第一镜像文件启动该第一虚拟机，从而第一电子设备完成修改虚拟机XML，以在第一虚拟机上挂载第一镜像文件，并修改第一虚拟机启动时优先加载并运行第一存储资源中的第一镜像文件。
进一步地，在第一电子设备将第一存储资源挂载到第一虚拟机上之后，可以对该第一虚拟机进行开机处理。具体地，该第一电子设备可以通过调用libvirt中的API对第一虚拟机进行开机处理，在第一虚拟机启动的过程中，第一电子设备可以通过第一虚拟机基于配置文件中配置的启动顺序为第一位的第一存储资源进行开机处理，以通过第一虚拟机加载并运行第一镜像文件。
请一并参阅图6，图6是本申请实施例提供的第一电子设备执行挂载过程的时序示意图，如图6所示，第一电子设备可以接收来自第二电子设备的挂载请求，该挂载请求携带第一虚拟机的标识信息，第一镜像文件的存储路径信息以及第一存储资源对应的存储资源标识，第一电子设备可以识别存储资源，并将各个存储资源对应的存储资源标识与第一存储资源对应的存储资源标识进行比对，从而可以检查第二电子设备中的调度层模块获取的第一存储资源是否已挂载到第一电子设备上，若检查结果为是，则第一电子设备可以根据第一镜像文件的存储路径信息将第一镜像文件下载到存储资源标识所指示的第一存储资源中，图6中以第一镜像文件存储在镜像文件存储仓库中为例进行绘制和讲解，第一电子设备可以基于下载链接从镜像文件存储仓库中将第一镜像文件下载到第一存储资源中。
进一步地，第一电子设备可以对第一虚拟机进行关机处理，如调用libvirt中的API控制第一虚拟机关机，并在第一虚拟机处于关机状态的情况下，获取第一虚拟机的配置文件，如调用libvirt中的API获取该配置文件。在获取到配置文件之后，第一电子设备可以修改该配置文件，在该配置文件中添加第一存储资源对应的存储资源标识，以将该第一存储资源挂载到第一虚拟机上，并修改各个存储资源对应的启动顺序，如修改第一存储资源对应的启动顺序为第一位，且修改第一虚拟机内部的第二存储资源对应的启动顺序为在第一位之后，如第9位。在修改完成之后，第一电子设备可以对第一虚拟机进行开机处理，如调用libvirt中的API控制第一虚拟机开机，以通过第一虚拟机在基于启动顺序为第一位的第一存储资源进行开机处理，即通过第一虚拟机在启动时加载并运行第一镜像文件。
其中，在检查结果为否，即检查出第二电子设备中的调度层模块获取的第一存储资源并未挂载到第一电子设备上的情况下，则流程结束，第一电子设备不进行进一步地处理。
S205、通过第一虚拟机加载并运行第一镜像文件，将第一镜像文件中承载的操作系统安装在第一虚拟机内部的第二存储资源中。
在本申请实施例中，在第一电子设备通过调用libvirt中的API对第一虚拟机进行开机处理后，通过第一虚拟机基于启动顺序为第一位的第一存储资源进行开机处理，通过第一虚拟机基于第一存储资源进行开机处理的过程可以是通过第一虚拟机加载并运行第一镜像文件的过程。其中，该第一镜像文件中承载有第一虚拟机需安装的操作系统，也有安装该操作系统的安装程序，第一虚拟机运行该第一镜像文件可以是运行该安装程序，对该操作系统进行安装处理。将第一镜像文件中承载的操作系统安装在第一虚拟机内部的第二存储资源中，是指将ISO格式的镜像文件中承载的操作系统安装在第一虚拟机内部的存储资源中，从而完成ISO格式的镜像文件的导入。
在一种可能的实现方式中，在第一虚拟机基于第一镜像文件成功开机之后，可以通过第一虚拟机基于第一镜像文件输出用户界面，该用户界面为第一镜像文件中承载的安装程序提供的用户界面，该用户界面中可以包括针对操作系统的安装控件，用户可以针对用户界面中的安装控件触发安装操作，响应于基于用户界面接收到的安装操作，第一电子设备可以通过第一虚拟机将第一镜像文件中承载的操作系统安装在第二存储资源中，即基于第一镜像文件中该操作系统的安装程序安装该操作系统至第一虚拟机内部的系统磁盘中。
请一并参阅图7，图7是本申请实施例提供的一种安装第一镜像文件承载的操作系统的用户界面的示意图，如图7上方所示，以安装的操作系统为Windows系统为例，用户界面中可以包括操作系统设置，例如该操作系统的语言、时间和货币格式，以及键盘和输入方法。在用户进行具体的设置之后，可以通过“下一页”控件触发安装操作，以通过第一虚拟机将第一镜像文件中承载的Windows系统安装在第二存储资源中。如图7下方所示，以安装的操作系统为Centos7为例，用户界面中可以包括操作系统设置，例如该操作系统的语言。在用户进行具体的设置之后，可以通过“继续”控件触发安装操作，以通过第一虚拟机将第一镜像文件中承载的Centos7系统安装在第二存储资源中。
可选地，通过第一虚拟机基于第一镜像文件输出的用户界面中还可以包括登陆控件，用户可以基于登陆控件输入用户名、密码等字段，以登陆至该第一虚拟机，在登陆至该第一虚拟机后，可以如图7所示的用户界面通过第一虚拟机输出如图7所示的用户界面，完成对ISO格式的镜像文件中承载的操作系统的可视化安装。
需要说明的是，在云环境中，一般采用Virtio作为虚拟机和母机(如第一虚拟机和第一电子设备)之间的IO通信方式，Virtio是一个半虚拟化设备驱动，虚拟机中必须安装Virtio驱动才能识别到虚拟机所挂载的存储资源(磁盘)，可以理解为在电脑的文件管理系统中查看到C盘、D盘等。然而，承载特定的操作系统的镜像文件中不自带Virtio驱动，则通过第一虚拟机在将第一镜像文件中承载的操作系统安装在第二存储资源中时，无法识别到第一虚拟机内部的第二存储资源，即无法识别到第一虚拟机的系统磁盘，也就无法将操作系统安装至第二存储资源中。
Virtio驱动，是一种半虚拟化设备驱动，在云环境中作为虚拟机和母机之间的IO通信方式，虚拟机必须安装该驱动才能识别到所挂载的存储资源，如在电脑文件管理系统中查看到C盘、D盘等，但某些特定操作系统的镜像文件生成时不自带该驱动。
由此，第一电子设备可以在确定第一镜像文件中承载的操作系统为特定操作系统的情况下，特定操作系统例如可以是Windows10系统、Windows11系统、Linux系统等，Windows ISO镜像文件在生成时，不自带Virtio驱动。则第一电子设备可以给该第一虚拟机再挂载一个存储资源，即在第一虚拟机的配置文件包括存储资源信息中，进一步添加第四存储资源对应的存储资源标识，该第四存储资源中承载有(集成有)驱动程序，即Virtio驱动的驱动程序。其中，第四存储资源，是在确定第一镜像文件中承载的操作系统为特定操作系统(如Windows10系统、Windows11系统、Linux系统等)时，给第一虚拟机额外挂载的存储资源，例如可以是云盘、只读光盘(CD-ROM)或其他磁盘设备。该存储资源中承载有(集成有)驱动程序，即Virtio驱动的驱动程序，用于使第一虚拟机在安装特定操作系统时能够识别到内部的第二存储资源，从而将操作系统安装至第二存储资源中。
具体地，对该第一虚拟机的配置文件进行修改的语法可以参见表3所示：

表3
在表3中，第一虚拟机内部的第二存储资源的部分和第一虚拟机新挂载的第一存储资源的定义可以参见表2中对应的描述，此处不再赘述。对于新增加的第四存储资源来说，<disk type＝'block'device＝'cdrom'>描述一个新的磁盘设备，即第四存储资源，是一个光驱(cdrom)。<driver name＝'qemu'type＝'raw'/>描述了磁盘的驱动设置，name＝'qemu'表示是QEMU模拟的磁盘，type＝'raw'表示磁盘文件是原始格式，<source file＝'/tmp/virtio.config'/>描述了第四存储资源中的文件路径，即包含virtio驱动的文件存储路径信息。<target dev＝'hdd'bus＝'ide'/>表示在该第一虚拟机中，第四存储资源被命名为hdd，并使用IDE总线。<readonly/>表示第四存储资源是以只读方式挂载到该第一虚拟机上的。<address type＝'drive'controller＝'0'bus＝'1'target＝'0'unit＝'1'/>定义了在IDE总线上的地址。
由此，第一电子设备在通过第一虚拟机加载并运行第一镜像文件，将第一镜像文件中承载的操作系统安装在第一虚拟机内部的第二存储资源中的过程中，可以通过第一虚拟机加载并运行第四存储资源中的驱动程序，以在基于驱动程序识别到第一虚拟机内部的第二存储资源(即系统盘)的情况下，继续安装操作系统，即将第一镜像文件中承载的操作系统，如windows操作系统，安装在第二存储资源中。
请一并参阅图8，图8是本申请实施例提供的一种加载第四存储资源承载的驱动程序的用户界面的示意图，如图8上方所示，在该用户界面中，第一虚拟机无法识别到第二存储资源，因此操作系统的安装位置为空，因此，用户可以通过针对“加载驱动程序”控件输入触发操作，以通过第一虚拟机加载并运行驱动程序。如图8下方所示，响应于用户针对“加载驱动程序”控件输入的触发操作，可以显示文件夹中包括的文件目录，该文件目录可以包括第四存储资源，如图8所示的“CD驱动器(F:)config-2”，进而可以加载并运行第四存储资源中的驱动程序(Virtio驱动)，如文件名为“Win10_2016_2019”和“Win8_8.1_2012_2012R2”的驱动程序。
可以理解的是，第一电子设备通过第一虚拟机加载并运行第四存储资源中的驱动程序，如运行如图8所示的驱动程序后，第一虚拟机可以识别到第二存储资源，进而，第一电子设备可通过第一虚拟机输出如图7所示的用户界面，将第一镜像文件中承载的操作系统安装至第二存储资源中。
请一并参阅图9，图9为本申请实施例提供的一种将镜像文件导入第一虚拟机的架构示意图，如图9所示，以从上到下的顺序进行讲解，用户可以通过控制台设备提供的用户界面，可视化操作方式第一虚拟机用于导入镜像文件，并且，用户还可以输入想要导入的镜像文件的存储路径信息(如下载链接)，控制台设备可以基于用户选择的第一虚拟机的标识信息，以及该镜像文件的存储路径信息生成针对镜像文件的导入请求，并将该导入请求发送至第一电子设备。第一电子设备中包括两个控制模块，分别为接入层模块和调度层模块，第一电子设备中的接入层模块可以获取该导入请求，调用调度层模块获取第一存储资源。其中，接入层模块可以对第一虚拟机的运行状态和第一虚拟机对应的系统架构信息进行校验，在校验通过后，接入层模块可以调用调度层模块将第一存储资源挂载到运行该第一虚拟机的第一电子设备上。
进一步地，该调度层模块可以向第一电子设备发送挂载请求，第一电子设备响应于该挂载请求，可以将镜像文件下载到第一存储资源中，例如可以从镜像文件存储仓库中基于镜像文件的下载链接将镜像文件下载到第一存储资源中。进而，第一电子设备可以将第一存储资源挂载到第一虚拟机，具体可以修改第一虚拟机的配置文件，进而并通过第一虚拟机加载并运行该镜像文件，以通过第一虚拟机将镜像文件中承载的操作系统安装在第一虚拟机内部的第二存储资源中，从而将镜像文件导入该第一虚拟机中。
由此，基于本申请实施例，可以针对需要对镜像文件进行格式转换操作后，才能将特定格式镜像文件的导入的问题，特别是在云环境中虚拟机的特定格式的镜像文件的导入问题，提出了一种标准化、产品级别的解决方案，即一套产品化的流程，可以将云环境中导入ISO格式的镜像文件的流程统一管理起来，在一定程度上可以提升在云环境中导入ISO格式的镜像文件的能力，也提高了云环境中导入ISO格式的镜像文件的效率。并且，在针对该方案中可能存在的风险，例如针对特定操作系统无法识别磁盘设备的风险，本申请提供的镜像文件的导入方法也可以通过挂载存储资源加载驱动程序的方式屏蔽该方案存在的风险，以实现承载不同种类的操作系统的ISO格式的镜像文件均能导入虚拟机。
在本申请中的一些实施例所提供的技术方案中，第二电子设备可以获取请求将第一镜像文件导入第一虚拟机的导入请求，该导入请求携带第一虚拟机的标识信息，以及第一镜像文件的存储路径信息，进而基于存储路径信息获取与第一镜像文件匹配的第一存储资源，并将第一存储资源挂载到运行第一虚拟机的第一电子设备上；向第一电子设备发送挂载请求，挂载请求用于指示第一电子设备基于存储路径信息将第一镜像文件下载到第一存储资源中，并将第一存储资源挂载到第一虚拟机上，以通过第一虚拟机加载并运行第一镜像文件。由此可见，通过运行虚拟机的电子设备将存储有特定格式镜像文件的存储资源挂载在虚拟机上，即可通过虚拟机加载并运行该特定格式的镜像文件，实现镜像文件的导入，从而可以省略对镜像文件进行格式转换的繁琐步骤，使得镜像文件的导入流程更为简便，有利于提升特定格式镜像文件的导入能力和导入效率，在一定程度上也能为虚拟化环境的管理和部署带来了便利。
请参阅图10，图10是本申请实施例提供了一种镜像文件的导入方法的另一流程示意图，该镜像文件的导入方法可由第一电子设备和第二电子设备交互实现。其中，第一电子可以是图1所示的虚拟机母机设备103，第二电子设备可以是图1所示的虚拟机平台设备102，该镜像文件的导入方法可以包括以下步骤S1001-S1004，其中：
S1001、第二电子设备获取携带第一虚拟机的标识信息的第一解挂请求。
第一解挂请求，是指控制台设备基于用户针对第一虚拟机输入的解挂操作，基于该第一虚拟机的标识信息生成的请求，并将其发送至第二电子设备，也可称为解挂ISO镜像的请求。
在本申请实施例中，第二电子设备包括的调度层模块可以实时与承载各个虚拟机的电子设备，如承载第一虚拟机的第一电子设备进行通信，获取各个虚拟机的运行状态，并将虚拟机的运行状态更新至所维护的数据库中。例如，在第一电子设备通过第一虚拟机加载并运行第一存储资源的第一镜像文件之后，可以确定该第一虚拟机的运行状态为已挂载，则可以将该第一虚拟机的标识信息和运行状态(已挂载)发送至该第二电子设备。该第二电子设备中的调度层模块在接收到第一电子设备发送的标识信息和运行状态后，可以将数据库中存储的该第一虚拟机的运行状态从挂载中更新为已挂载。
进一步地，控制台设备中所显示的用户界面中可以将该第一虚拟机的运行状态更新为已挂载状态。在用户基于控制台设备所显示的用户界面中查看到该第一虚拟机的运行状态为已挂载的情况下，用户可以通过针对第一虚拟机输入解挂操作，如图3中运行状态已更新为已挂载的虚拟机D对应的解挂控件输入触发操作。进而该控制台设备可以基于该第一虚拟机的标识信息，如虚拟机D，生成第一解挂请求，并将该携带第一虚拟机的标识信息的第一解挂请求发送至第二电子设备，从而第二电子设备可以获取携带该标识信息的第一解挂请求。也即是，控制台设备可以调用该第二电子设备中的接入层模块提供的API在控制台设备上可视化操作方式用于解挂存储资源的虚拟机，即选择一个虚拟机接触存储有ISO格式的镜像文件的存储资源，可以称为解除ISO镜像盘。并向第二电子设备发送该第一解挂请求。第二电子设备可以基于该API提供的HTTP服务，获取该第一解挂请求。其中，该第一解挂请求也可以称为解挂ISO镜像的请求。
S1002、第二电子设备向第一电子设备发送携带标识信息和第一存储资源对应的存储资源标识的第二解挂请求。
第二解挂请求，是指第二电子设备中的接入层模块在获取到第一解挂请求后，基于第一虚拟机的标识信息以及第一存储资源对应的存储资源标识生成的请求，用于指示第一电子设备基于标识信息和存储资源标识确定第一虚拟机已挂载第一存储资源，并对第一存储资源进行解挂载。
在本申请实施例中，第二电子设备中的接入层模块在获取到该第一解挂请求后，可以确定该第一虚拟机的运行状态是否为已挂载，即确定第一电子设备是否已经通过该第一虚拟机加载并运行第一存储资源中的第一镜像文件。在确定是的情况下，可以基于第一虚拟机的标识信息以及第一存储资源对应的存储资源标识生成第二解挂请求。其中，接入层模块可以根据第一虚拟机的标识信息在调度层模块所维护的数据库中查询该第一虚拟机当前的运行状态是否为已挂载状态，若为已挂载状态，则该接入层模块可以确定第一电子设备是否已经通过该第一虚拟机加载并运行第一存储资源中的第一镜像文件，可以生成该第二解挂请求。
进一步地，接入层模块在生成了第二解挂请求后，可以将携带标识信息和第一存储资源对应的存储资源标识的第二解挂请求传输至调度层模块，以将标识信息等参数透传至调度层模块，在调度层模块接收到该第二解挂请求后，可以将该携带有第一虚拟机的标识信息和第一存储资源对应的存储资源标识的第二解挂请求发送至第一电子设备。相应的，第二电子设备可以接收携带第一虚拟机的标识信息和第一存储资源对应的存储资源标识的第二解挂请求。该第二解挂请求可以用于指示第一电子设备基于标识信息和存储资源标识确定第一虚拟机已挂载第一存储资源，并对第一存储资源进行解挂载。
需要说明的是，在第二电子设备中，接入层模块主要用于为控制台设备提供可调用的API，主要用于与控制台设备进行交互，完成参数透传，调度层模块主要用于与运行虚拟机的电子设备(如第一电子设备)进行交互，完成参数透传。接入层模块并不直接与运行有虚拟机的电子设备进行交互。因此，在接入层模块生成第二解挂请求后，可以将第二解挂请求传输至调度层模块，通过调度层模块基于第一虚拟机的标识信息确定运行第一虚拟机的第一电子设备后，将该第二解挂请求发送至第一电子设备。
请一并参阅图11，图11是本申请实施例提供的一种第二电子设备中接入层模块执行的另一时序示意图，如图11所示，该接入层模块可以接收携带第一虚拟机的标识信息的第一解挂请求。进而该接入层模块可以检查该第一虚拟机当前的运行状态是否为已挂载状态，接入层模块具体可以基于标识信息在数据库中查询该第一虚拟机的状态以进行检查。若得到的检查结果为是，则接入层模块可以基于第一虚拟机的标识信息和第一存储资源对应的存储资源标识生成第二解挂请求，并将第二解挂请求传输至第二电子设备中的调度层模块，以完成参数透传，进一步可以调用该调度层模块将第二解挂请求发送至运行第一虚拟机的第一电子设备。其中，若得到的检查结果为否时，即第一虚拟机当前的运行状态不为已挂载状态，则流程结束，接入层模块不进行进一步地处理。
S1003、响应于第二解挂请求，第一电子设备基于标识信息和第一存储资源对应的存储资源标识，确定第一虚拟机已挂载第一存储资源。
在本申请实施例中，第一电子设备响应于该第二解挂请求(解挂请求)，可以根据标识信息确定第一虚拟机，进而根据第一存储资源对应的存储资源标识，确定第一虚拟机已挂载第一存储资源。其中，第一电子设备可以获取该第一虚拟机的配置文件，该配置文件中可以包括第一虚拟机挂载的各个存储资源分别对应的存储资源标识，则第一电子设备可以根据第一存储资源对应的存储资源标识和配置文件中各个存储资源分别对应的存储资源标识，确定第一虚拟机是否已挂载第一存储资源。进而，在第一电子设备确定第一虚拟机已挂载第一存储资源的情况下，可以对该第一存储资源进行解挂载。
具体地，第一电子设备可以先对该第一虚拟机进行关机处理，具体可以是通过调用libvirt中的API对第一虚拟机进行关机处理，进而，在第一虚拟机处于关机状态的情况下，获取第一虚拟机的配置文件，该第一电子设备也可以通过调用libvirt中的API在第一虚拟机处于关机状态的情况下，获取第一虚拟机的配置文件。在配置文件中可以包括第一虚拟机的存储资源信息，该存储资源信息包括第一存储资源对应的存储资源标识、第二存储资源对应的存储资源标识。进而，第一电子设备可以确定配置文件中是否包括第一存储资源对应的存储资源标识，若包括，则确定第一虚拟机已挂载第一存储资源，进一步可以对该第一存储资源进行解挂载。
S1004、第一电子设备对第一存储资源进行解挂载。
解挂载，也可称为解挂、卸载等，与挂载对应，是指从操作系统的文件系统上分离一个已挂载的存储资源，从而使其不再被访问，是一个停止访问存储数据的过程，第一电子设备对第一存储资源进行解挂载即从第一虚拟机可访问的存储资源中分离出已挂载的第一存储资源，使第一虚拟机不再访问该第一存储资源。
在本申请实施例中，解挂载也可以称为解挂(Unmount/Dismount)、卸载等，解挂载与挂载对应，可以是指从操作系统的文件系统上分离一个已挂载的存储资源，从而使其不再被访问，是一个停止访问存储数据的过程。第一电子设备对第一存储资源进行解挂载可以是指从第一虚拟机可访问的存储资源中分离出已挂载的第一存储资源，第一虚拟机不再访问该第一存储资源。
在一种可能的实现方式中，第一电子设备响应于该第二解挂请求(解挂请求)，可以无需确定该第一虚拟机已挂载该第一存储资源，而是直接对第一存储资源进行解挂载。这是由于第二电子设备的接入层模块已经检查第一虚拟机的运行状态为已挂载状态，所以可以直接对已挂载的第一存储资源进行解挂载。
在另一种可能的实现方式中，第一电子设备响应于该第二解挂请求(解挂请求)，可以先基于第一虚拟机的标识信息和第一存储资源对应的存储资源标识，确定第一虚拟机已挂载第一存储资源之后，再对第一存储资源进行解挂载。
具体地，不管第一电子设备是否需要先确定第一虚拟机已挂载第一存储资源，均需要先对该第一虚拟机进行关机处理，如调用libvirt中的API对第一虚拟机进行关机处理。在第一虚拟机处于关机状态的情况下，第一电子设备可以调用libvirt中的API获取第一虚拟机的配置文件。该配置文件包括第一虚拟机的存储资源信息，该存储资源信息包括第一存储资源对应的存储资源标识、第二存储资源对应的存储资源标识，以及第一存储资源和第二存储资源分别对应的启动顺序，具体可以参见表2或者表3所示的存储资源信息。
进一步地，第一电子设备可以修改配置文件，以实现对第一存储资源进行解挂载，具体地，第一电子设备可以在配置文件包括的存储资源信息中删除第一存储资源对应的存储资源标识，并恢复第二存储资源对应的启动顺序。也就是说，将之前响应于挂载请求添加到存储资源信息中的第一存储资源对应的存储资源标识进行删除，以解挂导入镜像文件时额外挂载的存储资源。由于第一电子设备响应于挂载请求将该第一存储资源对应的启动顺序设置为第一位，并将第二存储资源对应的启动顺序设置在第一位之后，则在解挂载该第一存储资源之后，可以恢复该第二存储资源中原有的启动顺序，例如将第二存储资源的启动顺序恢复为第一位，即恢复该第一虚拟机优先基于启动顺序为第一位的第二存储资源(系统盘)进行开机处理。
具体地，对该第一虚拟机的配置文件进行修改的语法可以参见表4所示：
表4
表4中，<devices>标签具体的语法的含义可以参见表2-表3对应的描述，此处不再赘述，需要说明的是，相较于表2，第一电子设备可以删除该第一存储资源对应的存储资源标识，即之前新增的的<disk>标签，并恢复第二存储资源的启动顺序，也即是上述boot order还原为1。
进一步地，在第一电子设备对第一存储资源进行解挂载之后，可以将第一虚拟机当前的运行状态发送至第二电子设备的调度层模块，例如可以是已解挂状态。进而第二电子设备中的调度层模块可以在数据库中更新该第一虚拟机对应的运行状态。调度层模块进而可以调用云硬盘服务提供的API发起退还第一存储资源的请求，例如发起退还云盘的请求，以通过调用云硬盘服务提供的API销毁之前获取的第一存储资源。所谓销毁第一存储资源可以理解为将该第一存储资源与预设存储资源进行合并，以便后续进行存储资源的划分。
可以理解的是，当第一虚拟机在挂载第一存储资源之后，可以在启动时加载并运行第一存储资源中的第一镜像文件，以将第一镜像文件中承载的操作系统安装在该第一虚拟机中的第二存储资源中。此时，该镜像文件已导入该第一虚拟机，用户可以通过在该第一虚拟机执行相应的云计算任务。而为了进一步使得其他虚拟机可以导入该第一镜像文件所承载的操作系统，第一电子设备可以通过第一虚拟机生成第二镜像文件，该第二镜像文件的格式为KVM和QEMU的hypervisor虚拟化系统可以直接支持的格式，如qcow2、raw、vhd等格式。而生成的第二镜像文件对应的系统信息包括的诸如系统架构、系统版本等信息，为该第一虚拟机的镜像元信息，可以是用户针对第一镜像文件输入的系统信息，使得生成的第二镜像文件的系统信息与第一镜像文件的系统信息一致。
第二镜像文件，是第一电子设备通过第一虚拟机基于安装在第一虚拟机内部第二存储资源中的操作系统生成的文件，其格式为KVM和QEMU的hypervisor虚拟化系统可以直接支持的格式，如qcow2、raw、vhd等格式，对应的系统信息包括的诸如系统架构、系统版本等信息，为该第一虚拟机的镜像元信息，与第一镜像文件的系统信息一致。
其中，第一电子设备通过第一虚拟机基于安装在第一虚拟机内部的第二存储资源中的操作系统生成第二镜像文件，可以理解为第一电子设备通过第一虚拟机制作对当前第一虚拟机做一个备份，将第一虚拟机的状态保存到一个文件中，即得到第二镜像文件。该第一虚拟机可以是基于云环境中云计算服务提供的制作镜像的能力生成的第二镜像文件，例如通过云计算服务提供的工具或者调用对应的API生成的。进而，该第二镜像文件可以保存在云计算服务提供的存储服务中，例如镜像存储仓库等，以便在需要时能够部署相同配置的虚拟机。
需要说明的是，在第一电子设备通过第一虚拟机生成第二镜像文件之前，需要对第一虚拟机上挂载的第一存储资源进行解挂，这是由于若是未解挂该第一存储资源，该第一虚拟机的状态可能出现异常。可选地，用户还可以在基于安装第一镜像文件所承载的操作系统的第一虚拟机中安装其他应用程序，以在生成的第二镜像文件中包括安装的应用程序。
具体地，第二电子设备可以获取请求在第二虚拟机上按照第二镜像文件的安装请求，该安装请求可以携带第二虚拟机的标识信息，该第二虚拟机为除第一虚拟机以外的任一虚拟机，可以为新创建的虚拟机，也可以为已创建的虚拟机。该第二虚拟机的标识信息可以用于指示该第二虚拟机。第一镜像文件和第二镜像文件格式不同，例如，若第一镜像文件为ISO格式，而第二镜像文件为KVM和QEMU的hypervisor虚拟化系统可直接支持的格式，如qcow2、raw、vhd等格式，以此确定第一镜像文件和第二镜像文件格式不同。
安装请求，是指第二电子设备获取的请求在第二虚拟机上按照第二镜像文件的请求，该请求携带第二虚拟机的标识信息，第二虚拟机为除第一虚拟机以外的任一虚拟机，第一镜像文件和第二镜像文件格式不同。
进而，响应于该安装请求，第二电子设备可以将第二镜像文件下载至第二虚拟机内部的第三存储资源中，也就是为该第二虚拟机配置该第二镜像文件，进而可以通过该第二虚拟机加载并运行第二镜像文件，即可以使得运行该第二虚拟机的电子设备通过该第二虚拟机启动时加载并运行第三存储资源中的第二镜像文件，从而使得该第二虚拟机与导入第一镜像文件的第一虚拟机具有相同的配置。由此，基于第二镜像文件可以批量生产虚拟机。
第三存储资源，是第二虚拟机内部的存储资源，用于存储第二电子设备响应安装请求而下载的第二镜像文件，以便第二虚拟机加载并运行该第二镜像文件，使第二虚拟机与导入第一镜像文件的第一虚拟机具有相同的配置。
例如，用户可通过控制台设备发起在第二虚拟机上安装第二镜像文件的请求，控制台设备接收到用户操作后，生成携带第二虚拟机标识信息的安装请求，并将其发送至第二电子设备。第二电子设备获取该安装请求后，根据第二虚拟机的标识信息确定目标虚拟机，并依据第二镜像文件的存储路径信息，将第二镜像文件下载至第二虚拟机内部的第三存储资源中。
请一并参阅图12，图12是本申请实施例提供的第一电子设备执行解挂过程的时序示意图，如图12所示，第一电子设备可以接收来自第二电子设备的解挂请求(第二解挂请求)。进一步地，第一电子设备可以对第一虚拟机进行关机处理，如调用libvirt中的API控制第一虚拟机关机，并在第一虚拟机处于关机状态的情况下，获取第一虚拟机的配置文件，如调用libvirt中的API获取该配置文件。进而可以判断是否成功获取配置文件，若成功获取到配置文件，则第一电子设备可以修改该配置文件，在配置文件包括的存储资源信息中删除第一存储资源对应的存储资源标识，以解挂该第一存储资源，并还原第二存储资源对应的启动顺序。在修改完成之后，第一电子设备可以对第一虚拟机进行开机处理，如调用libvirt中的API控制第一虚拟机开机，以通过第一虚拟机在基于启动顺序为第一位的第二存储资源进行开机处理。其中，在获取配置文件失败的情况下，流程结束，第一电子设备不进行进一步地处理。
请一并参阅图13，图13为本申请实施例提供的一种将镜像文件导入第一虚拟机的另一架构示意图，如图13所示，以从上到下的顺序进行讲解，用户可以通过控制台设备提供的用户界面，可视化操作方式运行状态为已挂载状态的第一虚拟机解挂第一存储资源。控制台设备可以基于用户选择的第一虚拟机的标识信息，以及该第一存储资源对应的存储资源标识生成第一解挂请求，并将该第一解挂请求发送至第一电子设备。第一电子设备中的接入层模块可以获取该第一解挂请求，进而根据第一虚拟机的标识信息和第一存储资源对应的存储资源标识生成第二解挂请求，并通过调用调度层模块向第一电子设备发送该第二解挂请求。第一电子设备响应于该解挂请求，解挂该第一存储资源，也即是解挂存储有ISO格式的第一镜像文件的第一存储资源。
具体地，第一电子设备可以在第一虚拟机的配置文件中删除该第一存储资源对应的存储资源标识，并还原第二存储资源对应的启动顺序，使该第一虚拟机优先基于内部的第二存储资源(系统盘)启动。在第一电子设备解挂第一存储资源之后，可以更新第一虚拟机的运行状态，并将第一虚拟机当前的运行状态发送至第二电子设备的调度层模块，进而该调度层模块可以调用云硬盘服务提供的API退还该第一存储资源。
请一并参阅图14，图14是本申请实施例提供的一种镜像文件导入第一虚拟机的时序示意图，如图14所示，该镜像文件的导入方法主要涉及的流程有：第一虚拟机挂载第一存储资源、第一虚拟机安装操作系统、第一虚拟机解挂载第一存储资源、第一虚拟机生成镜像文件。具体地，用户在控制台设备中选择一个虚拟机作为第一虚拟机，该第一虚拟机对应的系统架构信息与所要导入的镜像文件对应的系统架构信息相同。进而通过第一虚拟机挂载第一存储资源，通过获取额外的存储资源(第一存储资源)，并给第一虚拟机额外挂载该第一存储资源，在将第一存储资源挂载到第一虚拟机上之前，可以将该第一存储资源挂载到第一虚拟机所在的第一电子设备上，第一电子设备可以把ISO格式的镜像文件下载到第一存储资源中，进而可以通过第一虚拟机在启动时加载并运行第一存储资源中的镜像文件。
进而，通过第一虚拟机安装镜像文件承载的操作系统，用户可以在第一虚拟机提供的用户界面中登陆，并安装操作系统至第一虚拟机内部的第二存储资源中。在安装完成之后，通过第一虚拟机解挂第一存储资源，即解除给第一虚拟机额外挂载的第一存储资源，使虚拟机在启动时加载并运行其内部的第二存储资源。最后，通过第一虚拟机生成镜像文件，也即是通过第一虚拟机生成镜像文件，制作虚拟化系统支持格式的镜像文件，如QEMU支持的格式的镜像文件，以便于后续可以进一步使用第一虚拟机生成的镜像文件。由此，基于本申请所提出的一种针对ISO格式的镜像文件导入云环境的虚拟机的完整方案，用户可以在云计算服务提供的控制台上进行白屏操作，方便快捷地导入特定格式(ISO格式)的镜像文件，即可将ISO格式镜像导入为QEMU支持的镜像。
在本申请中的一些实施例所提供的技术方案中，第二电子设备可以获取请求将第一镜像文件导入第一虚拟机的导入请求，该导入请求携带第一虚拟机的标识信息，以及第一镜像文件的存储路径信息，进而基于存储路径信息获取与第一镜像文件匹配的第一存储资源，并将第一存储资源挂载到运行第一虚拟机的第一电子设备上；向第一电子设备发送挂载请求，挂载请求用于指示第一电子设备基于存储路径信息将第一镜像文件下载到第一存储资源中，并将第一存储资源挂载到第一虚拟机上，以通过第一虚拟机加载并运行第一镜像文件。由此可见，通过运行虚拟机的电子设备将存储有特定格式镜像文件的存储资源挂载在虚拟机上，即可通过虚拟机加载并运行该特定格式的镜像文件，实现镜像文件的导入，从而可以省略对镜像文件进行格式转换的繁琐步骤，使得镜像文件的导入流程更为简便，有利于提升特定格式镜像文件的导入能力和导入效率，在一定程度上也能为虚拟化环境的管理和部署带来了便利。
上述详细阐述了本申请实施例的方法，为了便于更好地实施本申请实施例的上述方案，相应地，下面提供了本申请实施例的装置。
请参阅图15，图15是本申请实施例提供的一种镜像文件的导入装置的结构示意图，该镜像文件的导入装置150可以用于执行图2和图10所示的镜像文件的导入方法中的相应步骤。该镜像文件的导入装置150包括如下单元：
获取单元1501，用于获取请求将第一镜像文件导入第一虚拟机的导入请求，导入请求携带第一虚拟机的标识信息，以及第一镜像文件的存储路径信息；基于存储路径信息获取与第一镜像文件匹配的第一存储资源，并将第一存储资源挂载到运行第一虚拟机的第一电子设备上；
发送单元1502，用于向第一电子设备发送挂载请求，挂载请求用于指示第一电子设备基于存储路径信息将第一镜像文件下载到第一存储资源中，并将第一存储资源挂载到第一虚拟机上，以通过第一虚拟机加载并运行第一镜像文件。
在一种可能的实现方式中，导入请求还携带第一镜像文件对应的系统架构信息；获取单元1501，用于将第一存储资源挂载到运行第一虚拟机的第一电子设备上，具体用于：
根据标识信息获取第一虚拟机当前的运行状态；
在运行状态为预设运行状态集合中的运行状态的情况下，获取第一虚拟机对应的系统架构信息；
在第一虚拟机对应的系统架构信息与第一镜像文件对应的系统架构信息相同的情况下，将第一存储资源挂载到第一电子设备上。
在一种可能的实现方式中，获取单元1501，用于基于存储路径信息获取与第一镜像文件匹配的第一存储资源，具体用于：
基于存储路径信息确定第一镜像文件的文件大小；
根据第一镜像文件的文件大小从预设存储资源中划分出与第一镜像文件大小匹配的存储资源，得到第一存储资源。
在一种可能的实现方式中，获取单元1501，用于将第一存储资源挂载到运行第一虚拟机的第一电子设备上，具体用于：
获取虚拟机标识信息与电子设备标识信息之间的对应关系；
根据对应关系和标识信息，确定标识信息对应的目标标识信息；
将第一存储资源挂载到目标标识信息所指示的第一电子设备上。
在一种可能的实现方式中，获取单元1501，还用于获取携带标识信息的第一解挂请求；
发送单元1502，还用于向第一电子设备发送携带标识信息和第一存储资源对应的存储资源标识的第二解挂请求，第二解挂请求用于指示第一电子设备基于标识信息和存储资源标识确定第一虚拟机已挂载第一存储资源，并对第一存储资源进行解挂载。
在一种可能的实现方式中，获取单元1501，还用于获取请求在第二虚拟机上按照第二镜像文件的安装请求，安装请求携带第二虚拟机的标识信息，第一镜像文件和第二镜像文件的格式不同；
下载单元1503，用于响应于安装请求，将第二镜像文件下载至第二虚拟机内部的第三存储资源中，以通过第二虚拟机加载并运行第二镜像文件；
其中，第一虚拟机内部的第二存储资源中安装有第一镜像文件承载的操作系统，第二镜像文件是第一电子设备通过第一虚拟机基于操作系统生成的，第二虚拟机为除第一虚拟机以外的任一虚拟机。
根据本申请的一个实施例，图2和图10所示的方法所涉及的步骤可以是由图15所示的镜像文件的导入装置中的各个单元执行的。例如，图2所示的步骤S201-S202由图15所示的获取单元1501来执行，步骤S203由图15所示的发送单元1502来执行。再例如，图10所示的步骤S1001由图15所示的获取单元1501来执行，步骤S1002由图15所示的发送单元1502来执行。
根据本申请的一个实施例，图15所示的镜像文件的导入装置150中的各个单元可以分别或全部合并为一个或若干个另外的单元来构成，或者其中的某个(些)单元还可以再拆分为功能上更小的多个单元来构成，这可以实现同样的操作，而不影响本申请的实施例的技术效果的实现。上述单元是基于逻辑功能划分的，在实际应用中，一个单元的功能也可以由多个单元来实现，或者多个单元的功能由一个单元实现。在本申请的其它实施例中，该镜像文件的导入装置150也可以包括其它单元，在实际应用中，这些功能也可以由其它单元协助实现，并且可以由多个单元协作实现。根据本申请的另一个实施例，可以通过在包括例如中央处理单元(CPU)、随机存取存储介质(RAM)、只读存储介质(ROM)等处理元件和存储元件的通用计算机的通用计算设备上运行能够执行如图2和图10中所示的相应方法所涉及的各步骤的计算机程序(包括程序代码)，来构造如图15中所示的镜像文件的导入装置150，以及来实现本申请实施例的镜像文件的导入方法。计算机程序可以记载于例如计算机可读存储介质上，并通过计算机可读存储介质装载于图1所示镜像文件的导入系统的虚拟机平台设备102中，并在其中运行。
请参阅图16，图16是本申请实施例提供的另一种镜像文件的导入装置的结构示意图，该镜像文件的导入装置160可以用于执行图2和图10所示的镜像文件的导入方法中的相应步骤。该镜像文件的导入装置160包括如下单元：
接收单元1601，用于接收来自第二电子设备的挂载请求，挂载请求携带第一虚拟机的标识信息、第一存储资源对应的存储资源标识和第一镜像文件的存储路径信息；
下载单元1602，用于响应于挂载请求，基于存储路径信息将第一镜像文件下载到存储资源标识指示的第一存储资源中，并将第一存储资源挂载到第一虚拟机上；
加载单元1603，用于通过第一虚拟机加载并运行第一镜像文件，将第一镜像文件中承载的操作系统安装在第一虚拟机内部的第二存储资源中；
其中，挂载请求是第二电子设备响应于请求将第一镜像文件导入第一虚拟机的导入请求，基于存储路径信息获取与第一镜像文件匹配的第一存储资源，并将第一存储资源挂载到运行第一虚拟机的第一电子设备上之后，向第一电子设备发送的。
在一种可能的实现方式中，下载单元1602，用于将第一存储资源挂载到第一虚拟机上，具体用于：
在第一虚拟机处于关机状态的情况下，获取第一虚拟机的配置文件，配置文件包括第一虚拟机的存储资源信息，存储资源信息包括第二存储资源对应的存储资源标识以及第二存储资源对应的启动顺序；
在存储资源信息中添加第一存储资源对应的存储资源标识，并将第一存储资源对应的启动顺序设置为第一位，且将第二存储资源对应的启动顺序修改为在第一位之后。
在一种可能的实现方式中，镜像文件的导入装置160还包括：
添加单元1604，用于在第一镜像文件中承载的操作系统为特定操作系统的情况下，在存储资源信息中添加第四存储资源对应的存储资源标识，第四存储资源中承载有驱动程序；
加载单元1603，用于通过第一虚拟机加载并运行第一镜像文件，将第一镜像文件中承载的操作系统安装在第一虚拟机内部的第二存储资源中，具体用于：
通过第一虚拟机加载并运行第四存储资源中的驱动程序，以在基于驱动程序识别到第二存储资源的情况下，将第一镜像文件中承载的操作系统安装在第二存储资源中。
在一种可能的实现方式中，加载单元1603，用于通过第一虚拟机加载并运行第一镜像文件，将第一镜像文件中承载的操作系统安装在第一虚拟机内部的第二存储资源中，具体用于：
通过第一虚拟机基于启动顺序为第一位的第一存储资源进行开机处理；
通过第一虚拟机基于第一镜像文件输出用户界面；
响应于基于用户界面接收到的安装操作，通过第一虚拟机将第一镜像文件中承载的操作系统安装在第二存储资源中。
在一种可能的实现方式中，接收单元1601，还用于接收携带标识信息和第一存储资源对应的存储资源标识的解挂请求；
确定单元1605，用于响应于解挂请求，基于标识信息和第一存储资源对应的存储资源标识，确定第一虚拟机已挂载第一存储资源；
解挂单元1606，用于对第一存储资源进行解挂载。
在一种可能的实现方式中，解挂单元1606，用于对第一存储资源进行解挂载，具体用于：
在第一虚拟机处于关机状态的情况下，获取第一虚拟机的配置文件，配置文件包括第一虚拟机的存储资源信息，存储资源信息包括第一存储资源对应的存储资源标识、第二存储资源对应的存储资源标识，以及第一存储资源和第二存储资源分别对应的启动顺序；
在存储资源信息中删除第一存储资源对应的存储资源标识，并还原第二存储资源对应的启动顺序。
根据本申请的一个实施例，图2和图10所示的方法所涉及的步骤可以是由图16所示的镜像文件的导入装置中的各个单元执行的。例如，图2所示的步骤S204由图16所示的下载单元1602来执行，步骤S205由图16所示的加载单元1603来执行。再例如，图10所示的步骤S1003由图16所示的确定单元1605来执行，步骤S1004由图16所示的解挂单元1606来执行。
根据本申请的一个实施例，图16所示的镜像文件的导入装置160中的各个单元可以分别或全部合并为一个或若干个另外的单元来构成，或者其中的某个(些)单元还可以再拆分为功能上更小的多个单元来构成，这可以实现同样的操作，而不影响本申请的实施例的技术效果的实现。上述单元是基于逻辑功能划分的，在实际应用中，一个单元的功能也可以由多个单元来实现，或者多个单元的功能由一个单元实现。在本申请的其它实施例中，该镜像文件的导入装置160也可以包括其它单元，在实际应用中，这些功能也可以由其它单元协助实现，并且可以由多个单元协作实现。根据本申请的另一个实施例，可以通过在包括例如中央处理单元(CPU)、随机存取存储介质(RAM)、只读存储介质(ROM)等处理元件和存储元件的通用计算机的通用计算设备上运行能够执行如图2和图10中所示的相应方法所涉及的各步骤的计算机程序(包括程序代码)，来构造如图16中所示的镜像文件的导入装置160，以及来实现本申请实施例的镜像文件的导入方法。计算机程序可以记载于例如计算机可读存储介质上，并通过计算机可读存储介质装载于图1所示镜像文件的导入系统的虚拟机母机设备103中，并在其中运行。
基于上述镜像文件的导入方法实施例的描述，本申请实施例还公开一种镜像文件的导入设备，请参阅图17，该电子设备170至少可包括处理器1701、输入设备1702、输出设备1703以及存储器1704。其中，电子设备170内的处理器1701、输入设备1702、输出设备1703以及存储器1704可通过总线或其他方式连接。
上述存储器1704是电子设备170中的记忆设备，用于存放程序和数据。可以理解的是，此处的存储器1704既可以包括镜像文件的导入设备的内置存储介质，当然也可以包括电子设备170支持的扩展存储介质。存储器1704提供存储空间，该存储空间存储了电子设备170的操作系统。并且，在该存储空间中还存放计算机程序(包括程序代码)。需要说明的是，此处的计算机存储介质可以是高速RAM存储器；可选的，还可以是至少一个远离前述处理器的计算机存储介质、上述处理器可以称为中央处理单元(Central Processing Unit，CPU)，是镜像文件的导入设备的核心以及控制中心，用于运行上述存储器1704中存储的计算机程序。
在一种实施方式中，可由处理器1701加载并执行存储器1704中存放的计算机程序，以实现上述有关镜像文件的导入方法实施例中的方法的相应步骤；具体的，上述处理器1701加载并执行存储器1704中存放的计算机程序，用于：
获取请求将第一镜像文件导入第一虚拟机的导入请求，导入请求携带第一虚拟机的标识信息，以及第一镜像文件的存储路径信息；
基于存储路径信息获取与第一镜像文件匹配的第一存储资源，并将第一存储资源挂载到运行第一虚拟机的第一电子设备上；
向第一电子设备发送挂载请求，挂载请求用于指示第一电子设备基于存储路径信息将第一镜像文件下载到第一存储资源中，并将第一存储资源挂载到第一虚拟机上，以通过第一虚拟机加载并运行第一镜像文件。
在一种可能的实现方式中，导入请求还携带第一镜像文件对应的系统架构信息；处理器1701加载并执行存储器1704中存放的计算机程序，用于将第一存储资源挂载到运行第一虚拟机的第一电子设备上，具体用于：
根据标识信息获取第一虚拟机当前的运行状态；
在运行状态为预设运行状态集合中的运行状态的情况下，获取第一虚拟机对应的系统架构信息；
在第一虚拟机对应的系统架构信息与第一镜像文件对应的系统架构信息相同的情况下，将第一存储资源挂载到第一电子设备上。
在一种可能的实现方式中，处理器1701加载并执行存储器1704中存放的计算机程序，用于基于存储路径信息获取与第一镜像文件匹配的第一存储资源，具体用于：
基于存储路径信息确定第一镜像文件的文件大小；
根据第一镜像文件的文件大小从预设存储资源中划分出与第一镜像文件大小匹配的存储资源，得到第一存储资源。
在一种可能的实现方式中，处理器1701加载并执行存储器1704中存放的计算机程序，用于将第一存储资源挂载到运行第一虚拟机的第一电子设备上，具体用于：
获取虚拟机标识信息与电子设备标识信息之间的对应关系；
根据对应关系和标识信息，确定标识信息对应的目标标识信息；
将第一存储资源挂载到目标标识信息所指示的第一电子设备上。
在一种可能的实现方式中，处理器1701加载并执行存储器1704中存放的计算机程序，还用于：
获取携带标识信息的第一解挂请求；
向第一电子设备发送携带标识信息和第一存储资源对应的存储资源标识的第二解挂请求，第二解挂请求用于指示第一电子设备基于标识信息和存储资源标识确定第一虚拟机已挂载第一存储资源，并对第一存储资源进行解挂载。
在一种可能的实现方式中，处理器1701加载并执行存储器1704中存放的计算机程序，还用于：
获取请求在第二虚拟机上按照第二镜像文件的安装请求，安装请求携带第二虚拟机的标识信息，第一镜像文件和第二镜像文件的格式不同；
响应于安装请求，将第二镜像文件下载至第二虚拟机内部的第三存储资源中，以通过第二虚拟机加载并运行第二镜像文件；
其中，第一虚拟机内部的第二存储资源中安装有第一镜像文件承载的操作系统，第二镜像文件是第一电子设备通过第一虚拟机基于操作系统生成的，第二虚拟机为除第一虚拟机以外的任一虚拟机。
在一种可能的实现方式中，可由处理器1701加载并执行存储器1704中存放的计算机程序，以实现上述有关另一种镜像文件的导入方法实施例中的相应步骤；具体的，上述处理器1701加载并执行存储器1704中存放的计算机程序，用于：
接收来自第二电子设备的挂载请求，挂载请求携带第一虚拟机的标识信息、第一存储资源对应的存储资源标识和第一镜像文件的存储路径信息；
响应于挂载请求，基于存储路径信息将第一镜像文件下载到存储资源标识指示的第一存储资源中，并将第一存储资源挂载到第一虚拟机上；
通过第一虚拟机加载并运行第一镜像文件，将第一镜像文件中承载的操作系统安装在第一虚拟机内部的第二存储资源中；
其中，挂载请求是第二电子设备响应于请求将第一镜像文件导入第一虚拟机的导入请求，基于存储路径信息获取与第一镜像文件匹配的第一存储资源，并将第一存储资源挂载到运行第一虚拟机的第一电子设备上之后，向第一电子设备发送的。
在一种可能的实现方式中，处理器1701加载并执行存储器1704中存放的计算机程序，用于将第一存储资源挂载到第一虚拟机上，具体用于：
在第一虚拟机处于关机状态的情况下，获取第一虚拟机的配置文件，配置文件包括第一虚拟机的存储资源信息，存储资源信息包括第二存储资源对应的存储资源标识以及第二存储资源对应的启动顺序；
在存储资源信息中添加第一存储资源对应的存储资源标识，并将第一存储资源对应的启动顺序设置为第一位，且将第二存储资源对应的启动顺序修改为在第一位之后。
在一种可能的实现方式中，处理器1701加载并执行存储器1704中存放的计算机程序，还用于：
在第一镜像文件中承载的操作系统为特定操作系统的情况下，在存储资源信息中添加第四存储资源对应的存储资源标识，第四存储资源中承载有驱动程序；
通过第一虚拟机加载并运行第一镜像文件，将第一镜像文件中承载的操作系统安装在第一虚拟机内部的第二存储资源中，包括：
通过第一虚拟机加载并运行第四存储资源中的驱动程序，以在基于驱动程序识别到第二存储资源的情况下，将第一镜像文件中承载的操作系统安装在第二存储资源中。
在一种可能的实现方式中，处理器1701加载并执行存储器1704中存放的计算机程序，用于通过第一虚拟机加载并运行第一镜像文件，将第一镜像文件中承载的操作系统安装在第一虚拟机内部的第二存储资源中，具体用于：
通过第一虚拟机基于启动顺序为第一位的第一存储资源进行开机处理；
通过第一虚拟机基于第一镜像文件输出用户界面；
响应于基于用户界面接收到的安装操作，通过第一虚拟机将第一镜像文件中承载的操作系统安装在第二存储资源中。
在一种可能的实现方式中，处理器1701加载并执行存储器1704中存放的计算机程序，还用于：
接收携带标识信息和第一存储资源对应的存储资源标识的解挂请求；
响应于解挂请求，基于标识信息和第一存储资源对应的存储资源标识，确定第一虚拟机已挂载第一存储资源；
对第一存储资源进行解挂载。
在一种可能的实现方式中，处理器1701加载并执行存储器1704中存放的计算机程序，用于对第一存储资源进行解挂载，具体用于：
在第一虚拟机处于关机状态的情况下，获取第一虚拟机的配置文件，配置文件包括第一虚拟机的存储资源信息，存储资源信息包括第一存储资源对应的存储资源标识、第二存储资源对应的存储资源标识，以及第一存储资源和第二存储资源分别对应的启动顺序；
在存储资源信息中删除第一存储资源对应的存储资源标识，并还原第二存储资源对应的启动顺序。
应当理解，在本申请实施例中，所称处理器1701可以是中央处理单元(Central Processing Unit，CPU)，该处理器1701还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
本申请实施例中提供一种计算机可读存储介质，上述计算机可读存储介质存储有计算机程序，上述计算机程序包括程序指令，上述程序指令被处理器执行时，可执行上述所有实施例中所执行的步骤。
本申请实施例还提供一种计算机程序产品或计算机程序，计算机程序产品或计算机程序包括计算机指令，计算机指令存储在计算机可读存储介质中，计算机指令被计算机设备的处理器执行时，执行上述所有实施例中的方法。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。
综上所述，本申请提供一种镜像文件的导入方法、装置、设备、存储介质和计算机程序产品，通过第二电子设备获取请求将第一镜像文件导入第一虚拟机的导入请求，该请求携带第一虚拟机标识信息与第一镜像文件存储路径信息，基于存储路径信息获取匹配的第一存储资源并挂载到运行第一虚拟机的第一电子设备上，再向第一电子设备发送挂载请求，指示其将第一镜像文件下载到第一存储资源并挂载到第一虚拟机，通过第一虚拟机加载运行第一镜像文件，如此省略了对镜像文件进行格式转换的繁琐步骤，简化了导入流程，提升了特定格式镜像文件的导入能力和效率，为虚拟化环境的管理和部署带来便利。
进一步地，在导入请求还携带第一镜像文件对应的系统架构信息时，第二电子设备根据标识信息获取第一虚拟机当前运行状态，若运行状态在预设运行状态集合中，获取第一虚拟机对应的系统架构信息，当第一虚拟机与第一镜像文件对应的系统架构信息相同时，才将第一存储资源挂载到第一电子设备上，这样可确保虚拟机能够正常加载运行镜像文件，避免因状态或架构不匹配导致导入异常，提高导入的成功率和稳定性。
在获取与第一镜像文件匹配的第一存储资源方面，第二电子设备基于存储路径信息确定第一镜像文件的文件大小，根据该大小从预设存储资源中划分出匹配的存储资源作为第一存储资源，如此能精准匹配资源，减少资源浪费，提高资源利用率。
将第一存储资源挂载到运行第一虚拟机的第一电子设备上时，第二电子设备获取虚拟机标识信息与电子设备标识信息之间的对应关系，依据此关系和标识信息确定目标标识信息，进而将第一存储资源挂载到目标标识信息所指示的第一电子设备上，这种准确的挂载方式，保障了存储资源挂载的准确性，避免误挂载，提高了系统运行的可靠性。
在获取携带标识信息的第一解挂请求后，第二电子设备向第一电子设备发送携带标识信息和第一存储资源对应的存储资源标识的第二解挂请求，指示第一电子设备确定第一虚拟机已挂载第一存储资源并进行解挂载，使得系统能够灵活管理存储资源的挂载与解挂载，提高资源的可调配性，便于后续其他操作。
当获取请求在第二虚拟机上按照第二镜像文件的安装请求，且该请求携带第二虚拟机标识信息，第一、二镜像文件格式不同时，第二电子设备响应请求，将第二镜像文件下载至第二虚拟机内部的第三存储资源中，通过第二虚拟机加载运行第二镜像文件，由于第一虚拟机内部已安装第一镜像文件承载的操作系统，且第二镜像文件由第一电子设备通过第一虚拟机基于该操作系统生成，这使得第二虚拟机与第一虚拟机具有相同配置，实现了基于第二镜像文件批量生产虚拟机的功能，提高了虚拟机配置的一致性和部署效率。
第一电子设备执行镜像文件导入方法时，接收来自第二电子设备的挂载请求，该请求携带第一虚拟机标识信息、第一存储资源对应的存储资源标识和第一镜像文件的存储路径信息，响应请求，基于存储路径信息将第一镜像文件下载到第一存储资源并挂载到第一虚拟机上，通过第一虚拟机加载运行第一镜像文件并将其中承载的操作系统安装在第一虚拟机内部的第二存储资源中，完成镜像文件导入，此过程无需格式转换，提高了导入效率。
在将第一存储资源挂载到第一虚拟机上时，第一电子设备在第一虚拟机处于关机状态下，获取其配置文件，该文件包含第二存储资源对应的存储资源标识及启动顺序等存储资源信息，然后在存储资源信息中添加第一存储资源对应的存储资源标识，将第一存储资源启动顺序设为第一位，同时修改第二存储资源启动顺序在第一位之后，通过这种对配置文件的精确修改，确保第一虚拟机启动时优先加载运行第一存储资源中的镜像文件，保障了导入过程的有序性和准确性。
当第一镜像文件中承载的操作系统为特定操作系统时，第一电子设备在存储资源信息中添加第四存储资源对应的存储资源标识，该第四存储资源承载有驱动程序，通过第一虚拟机加载运行第四存储资源中的驱动程序，在识别到第二存储资源的情况下，将第一镜像文件中承载的操作系统安装在第二存储资源中，解决了特定操作系统因缺少驱动无法识别存储资源的问题，增强了系统对不同操作系统镜像文件的兼容性。
通过第一虚拟机加载运行第一镜像文件并将操作系统安装在第二存储资源中的过程中，第一电子设备通过第一虚拟机基于启动顺序为第一位的第一存储资源进行开机处理，基于第一镜像文件输出用户界面，响应基于用户界面接收到的安装操作，将操作系统安装在第二存储资源中，实现了操作系统安装的可视化操作，方便用户进行安装，提升了用户体验。
第一电子设备接收携带标识信息和第一存储资源对应的存储资源标识的解挂请求后，响应请求，基于标识信息和存储资源标识确定第一虚拟机已挂载第一存储资源，然后对第一存储资源进行解挂载，使系统能够及时释放已使用的存储资源，提高资源的循环利用率。
在对第一存储资源进行解挂载时，第一电子设备在第一虚拟机处于关机状态下，获取其配置文件，该文件包含第一、二存储资源对应的存储资源标识及启动顺序等存储资源信息，在存储资源信息中删除第一存储资源对应的存储资源标识，并还原第二存储资源对应的启动顺序，准确地完成解挂载操作，使第一虚拟机恢复到初始存储资源配置状态，保障系统的稳定性和可重复性操作。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (17)

  1. 一种镜像文件的导入方法，由第二电子设备执行，包括：
    获取请求将第一镜像文件导入第一虚拟机的导入请求，所述导入请求携带第一虚拟机的标识信息，以及所述第一镜像文件的存储路径信息；
    基于所述存储路径信息获取与所述第一镜像文件匹配的第一存储资源，并将所述第一存储资源挂载到运行所述第一虚拟机的第一电子设备上；及
    向所述第一电子设备发送挂载请求，所述挂载请求用于指示所述第一电子设备基于所述存储路径信息将所述第一镜像文件下载到所述第一存储资源中，并将所述第一存储资源挂载到所述第一虚拟机上，以通过所述第一虚拟机加载并运行所述第一镜像文件。
  2. 根据权利要求1所述的方法，所述导入请求还携带所述第一镜像文件对应的系统架构信息；所述将所述第一存储资源挂载到运行所述第一虚拟机的第一电子设备上，包括：
    根据所述标识信息获取所述第一虚拟机当前的运行状态；
    在所述运行状态为预设运行状态集合中的运行状态的情况下，获取所述第一虚拟机对应的系统架构信息；
    在所述第一虚拟机对应的系统架构信息与所述第一镜像文件对应的系统架构信息相同的情况下，将所述第一存储资源挂载到所述第一电子设备上。
  3. 根据权利要求1或2所述的方法，所述基于所述存储路径信息获取与所述第一镜像文件匹配的第一存储资源，包括：
    基于所述存储路径信息确定所述第一镜像文件的文件大小；
    根据所述第一镜像文件的文件大小从预设存储资源中划分出与所述第一镜像文件大小匹配的存储资源，得到所述第一存储资源。
  4. 根据权利要求1至3任一项所述的方法，所述将所述第一存储资源挂载到运行所述第一虚拟机的第一电子设备上，包括：
    获取虚拟机标识信息与电子设备标识信息之间的对应关系；
    根据所述对应关系和所述标识信息，确定所述标识信息对应的目标标识信息；
    将所述第一存储资源挂载到所述目标标识信息所指示的第一电子设备上。
  5. 根据权利要求1至4任一项所述的方法，所述方法还包括：
    获取携带所述标识信息的第一解挂请求；
    向所述第一电子设备发送携带所述标识信息和所述第一存储资源对应的存储资源标识的第二解挂请求，所述第二解挂请求用于指示所述第一电子设备基于所述标识信息和所述存储资源标识确定所述第一虚拟机已挂载所述第一存储资源，并对所述第一存储资源进行解挂载。
  6. 根据权利要求1-5任一项所述的方法，所述方法还包括：
    获取请求在第二虚拟机上按照第二镜像文件的安装请求，所述安装请求携带第二虚拟机的标识信息，所述第一镜像文件和所述第二镜像文件的格式不同；
    响应于所述安装请求，将所述第二镜像文件下载至所述第二虚拟机内部的第三存储资源中，以通过所述第二虚拟机加载并运行所述第二镜像文件；
    其中，所述第一虚拟机内部的第二存储资源中安装有第一镜像文件承载的操作系统，所述第二镜像文件是所述第一电子设备通过所述第一虚拟机基于所述操作系统生成的，所述第二虚拟机为除所述第一虚拟机以外的任一虚拟机。
  7. 一种镜像文件的导入方法，由第一电子设备执行，包括：
    接收来自第二电子设备的挂载请求，所述挂载请求携带第一虚拟机的标识信息、第一存储资源对应的存储资源标识和第一镜像文件的存储路径信息；
    响应于所述挂载请求，基于所述存储路径信息将所述第一镜像文件下载到所述存储资源标识指示的所述第一存储资源中，并将所述第一存储资源挂载到所述第一虚拟机上；及
    通过所述第一虚拟机加载并运行所述第一镜像文件，将所述第一镜像文件中承载的操作系统安装在所述第一虚拟机内部的第二存储资源中；
    其中，所述挂载请求是所述第二电子设备响应于请求将所述第一镜像文件导入第一虚拟机的导入请求，基于所述存储路径信息获取与第一镜像文件匹配的所述第一存储资源，并将所述第一存储资源挂载到运行所述第一虚拟机的第一电子设备上之后，向所述第一电子设备发送的。
  8. 根据权利要求7所述的方法，所述将所述第一存储资源挂载到所述第一虚拟机上，包括：
    在所述第一虚拟机处于关机状态的情况下，获取所述第一虚拟机的配置文件，所述配置文件包括所述第一虚拟机的存储资源信息，所述存储资源信息包括所述第二存储资源对应的存储资源标识以及所述第二存储资源对应的启动顺序；
    在所述存储资源信息中添加所述第一存储资源对应的存储资源标识，并将所述第一存储资源对应的启动顺序设置为第一位，且将所述第二存储资源对应的启动顺序修改为在所述第一位之后。
  9. 根据权利要求8所述的方法，所述方法还包括：
    在所述第一镜像文件中承载的操作系统为特定操作系统的情况下，在所述存储资源信息中添加第四存储资源对应的存储资源标识，所述第四存储资源中承载有驱动程序；
    所述通过所述第一虚拟机加载并运行所述第一镜像文件，将所述第一镜像文件中承载的操作系统安装在所述第一虚拟机内部的第二存储资源中，包括：
    通过所述第一虚拟机加载并运行所述第四存储资源中的驱动程序，以在基于所述驱动程序识别到所述第二存储资源的情况下，将所述第一镜像文件中承载的操作系统安装在所述第二存储资源中。
  10. 根据权利要求8或9所述的方法，所述通过所述第一虚拟机加载并运行所述第一镜像文件，将所述第一镜像文件中承载的操作系统安装在所述第一虚拟机内部的第二存储资源中，包括：
    通过所述第一虚拟机基于启动顺序为所述第一位的所述第一存储资源进行开机处理；
    通过所述第一虚拟机基于所述第一镜像文件输出用户界面；
    响应于基于所述用户界面接收到的安装操作，通过所述第一虚拟机将所述第一镜像文件中承载的操作系统安装在所述第二存储资源中。
  11. 根据权利要求7-10任一项所述的方法，所述方法还包括：
    接收携带所述标识信息和所述第一存储资源对应的存储资源标识的解挂请求；
    响应于所述解挂请求，基于所述标识信息和所述第一存储资源对应的存储资源标识，确定所述第一虚拟机已挂载所述第一存储资源；
    对所述第一存储资源进行解挂载。
  12. 根据权利要求11所述的方法，所述对所述第一存储资源进行解挂载，包括：
    在所述第一虚拟机处于关机状态的情况下，获取所述第一虚拟机的配置文件，所述配置文件包括所述第一虚拟机的存储资源信息，所述存储资源信息包括所述第一存储资源对应的存储资源标识、所述第二存储资源对应的存储资源标识，以及所述第一存储资源和所述第二存储资源分别对应的启动顺序；
    在所述存储资源信息中删除所述第一存储资源对应的存储资源标识，并还原所述第二存储资源对应的启动顺序。
  13. 一种镜像文件的导入装置，包括：
    获取单元，用于获取请求将第一镜像文件导入第一虚拟机的导入请求，所述导入请求携带第一虚拟机的标识信息，以及所述第一镜像文件的存储路径信息；基于所述存储路径信息获取与所述第一镜像文件匹配的第一存储资源，并将所述第一存储资源挂载到运行所述第一虚拟机的第一电子设备上；及
    发送单元，用于向所述第一电子设备发送挂载请求，所述挂载请求用于指示所述第一电子设备基于所述存储路径信息将所述第一镜像文件下载到所述第一存储资源中，并将所述第一存储资源挂载到所述第一虚拟机上，以通过所述第一虚拟机加载并运行所述第一镜像文件。
  14. 一种镜像文件的导入装置，包括：
    接收单元，用于接收来自第二电子设备的挂载请求，所述挂载请求携带第一虚拟机的标识信息、第一存储资源对应的存储资源标识和第一镜像文件的存储路径信息；
    下载单元，用于响应于所述挂载请求，基于所述存储路径信息将所述第一镜像文件下载到所述存储资源标识指示的所述第一存储资源中，并将所述第一存储资源挂载到所述第一虚拟机上；及
    加载单元，用于通过所述第一虚拟机加载并运行所述第一镜像文件，将所述第一镜像文件中承载的操作系统安装在所述第一虚拟机内部的第二存储资源中；
    其中，所述挂载请求是所述第二电子设备响应于请求将所述第一镜像文件导入第一虚拟机的导入请求，基于所述存储路径信息获取与第一镜像文件匹配的所述第一存储资源，并将所述第一存储资源挂载到运行所述第一虚拟机的第一电子设备上之后，向所述第一电子设备发送的。
  15. 一种电子设备，包括：
    一个或多个处理器；
    存储器，用于存储一个或多个计算机程序，当所述一个或多个计算机程序被所述一个或多个处理器执行时，使得所述电子设备实现权利要求1-12中任一项所述的镜像文件的导入方法。
  16. 一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-12中任一项所述的镜像文件的导入方法。
  17. 一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序存储在计算机可读存储介质中，电子设备的处理器从所述计算机可读存储介质读取并执行所述计算机程序，使得所述电子设备执行权利要求1-12中任一项所述的镜像文件的导入方法。
PCT/CN2025/088856 2024-06-15 2025-04-14 镜像文件的导入方法、装置、设备、存储介质及产品 Pending WO2025256256A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410773546.4 2024-06-15
CN202410773546.4A CN118860425A (zh) 2024-06-15 2024-06-15 镜像文件的导入方法、装置、设备、存储介质及产品

Publications (1)

Publication Number Publication Date
WO2025256256A1 true WO2025256256A1 (zh) 2025-12-18

Family

ID=93163676

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2025/088856 Pending WO2025256256A1 (zh) 2024-06-15 2025-04-14 镜像文件的导入方法、装置、设备、存储介质及产品

Country Status (2)

Country Link
CN (1) CN118860425A (zh)
WO (1) WO2025256256A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118860425A (zh) * 2024-06-15 2024-10-29 腾讯云计算（北京）有限责任公司 镜像文件的导入方法、装置、设备、存储介质及产品
CN120723380B (zh) * 2025-06-24 2026-05-22 广州鼎甲计算机科技有限公司 虚拟化平台的恢复方法、装置、计算机设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108121590A (zh) * 2017-11-29 2018-06-05 杭州九略智能科技有限公司 Esxi虚拟机自动部署安装系统的方法及装置
US20210216360A1 (en) * 2018-09-30 2021-07-15 Huawei Technologies Co., Ltd. Virtual machine migration method and apparatus
CN114443229A (zh) * 2022-01-29 2022-05-06 苏州浪潮智能科技有限公司 一种镜像文件的挂载方法、装置、电子设备及存储介质
CN116661951A (zh) * 2023-06-02 2023-08-29 北京首都在线科技股份有限公司 镜像文件处理方法、装置、电子设备及存储介质
CN117591247A (zh) * 2024-01-18 2024-02-23 腾讯科技（深圳）有限公司 云环境虚拟机的修复方法、装置及电子设备
CN118860425A (zh) * 2024-06-15 2024-10-29 腾讯云计算（北京）有限责任公司 镜像文件的导入方法、装置、设备、存储介质及产品

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115774701B (zh) * 2022-12-01 2023-11-28 北京首都在线科技股份有限公司 数据共享方法、装置、电子设备及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108121590A (zh) * 2017-11-29 2018-06-05 杭州九略智能科技有限公司 Esxi虚拟机自动部署安装系统的方法及装置
US20210216360A1 (en) * 2018-09-30 2021-07-15 Huawei Technologies Co., Ltd. Virtual machine migration method and apparatus
CN114443229A (zh) * 2022-01-29 2022-05-06 苏州浪潮智能科技有限公司 一种镜像文件的挂载方法、装置、电子设备及存储介质
CN116661951A (zh) * 2023-06-02 2023-08-29 北京首都在线科技股份有限公司 镜像文件处理方法、装置、电子设备及存储介质
CN117591247A (zh) * 2024-01-18 2024-02-23 腾讯科技（深圳）有限公司 云环境虚拟机的修复方法、装置及电子设备
CN118860425A (zh) * 2024-06-15 2024-10-29 腾讯云计算（北京）有限责任公司 镜像文件的导入方法、装置、设备、存储介质及产品

Also Published As

Publication number Publication date
CN118860425A (zh) 2024-10-29

Similar Documents

Publication Publication Date Title
US11334396B2 (en) Host specific containerized application configuration generation
JP7275171B2 (ja) オンデマンドネットワークコード実行システムにおけるオペレーティングシステムカスタマイゼーション
US11513809B2 (en) Kernel-integrated instance-specific operational resources with virtualization
US11093148B1 (en) Accelerated volumes
US20210133002A1 (en) Using scripts to bootstrap applications with metadata from a template
US10838745B2 (en) Loading dependency library files from a shared library repository in an application runtime environment
CN110908753B (zh) 一种智能融合的云桌面服务器、客户端及系统
US9667496B2 (en) Configuration updates across peer storage systems
US10649679B2 (en) Containerized application extensions in distributed storage systems
US9846586B2 (en) Creating a virtual machine and cloud server
US10891569B1 (en) Dynamic task discovery for workflow tasks
US20170322934A1 (en) Software version control without affecting a deployed container
US11172024B2 (en) Co-location of storage buckets with containerized applications
CN102402446A (zh) 应用软件的安装方法和应用软件的安装装置
WO2015000378A1 (en) Method to optimize provisioning time with dynamically generated virtual disk contents
US10684895B1 (en) Systems and methods for managing containerized applications in a flexible appliance platform
CN118860425A (zh) 镜像文件的导入方法、装置、设备、存储介质及产品
CN117112122A (zh) 一种集群部署方法和装置
US9298487B2 (en) Managing virtual machine images in a distributed computing environment
US12524256B2 (en) Generating installation images based upon DPU-specific capabilities
CN115129417A (zh) 基于Kubernetes平台的虚拟机创建方法、装置及存储介质
US11561787B2 (en) Application invocation on specified operating system version
US9229753B2 (en) Autonomic customization of properties of a virtual appliance in a computer system
CN115016862A (zh) 基于Kubernetes集群的软件启动方法、装置、服务器及存储介质
CN119621163B (zh) 服务部署方法、系统、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25820936

Country of ref document: EP

Kind code of ref document: A1