CN117992182A

CN117992182A - Virtual cloud host starting method and device, processing equipment and storage medium

Info

Publication number: CN117992182A
Application number: CN202410108140.4A
Authority: CN
Inventors: 杨云鹏; 邱春武
Original assignee: Sina Technology China Co Ltd
Current assignee: Sina Technology China Co Ltd
Priority date: 2024-01-25
Filing date: 2024-01-25
Publication date: 2024-05-07

Abstract

The embodiment of the disclosure discloses a method, a device, processing equipment and a storage medium for starting a virtual cloud host. The method comprises the following steps: acquiring first information of a started first virtual cloud host, wherein the first information comprises attribute information associated with using equipment, and the equipment and the first virtual cloud host are communicated directly; generating a template of the device based on the first information, wherein the template is used for guiding the starting of the virtual cloud host; and starting a second virtual cloud host based on the template, so that the equipment and the started second virtual cloud host can be communicated. Therefore, the second virtual cloud host can be started based on the generated template, compared with a starting mode based on the BIOS or bootloader, the direct connection between the second virtual cloud host and the equipment can be realized quickly, the process is simpler, the starting of the virtual cloud host can be realized quickly, and the requirements of cloud service can be responded quickly.

Description

Virtual cloud host starting method and device, processing equipment and storage medium

Technical Field

The disclosure relates to the field of cloud technologies, and in particular, to a method, a device, processing equipment and a storage medium for starting a virtual cloud host.

Background

In cloud scenarios, tens of thousands of services are often required to be started on a second level, with the need for computing power for fast response traffic. The start-up of a virtual cloud host is a complex process that includes multiple processes of basic input output system (BIOS, base Input Output System) or unified extensible firmware interface (UEFI, unified Extensible FIRMWARE INTERFACE) stage hardware power-on self test (POST, power On Self Test), initializing some basic hardware settings, bootloader, kernel start-up, etc., which can lead to slow system start-up.

Disclosure of Invention

In view of this, the embodiments of the present disclosure disclose a method, an apparatus, a processing device, and a storage medium for starting a virtual cloud host, so as to at least achieve fast starting of the virtual cloud host.

According to a first aspect of an embodiment of the present disclosure, there is provided a method for starting up a virtual cloud host, the method including:

Acquiring first information of a started first virtual cloud host, wherein the first information comprises attribute information associated with using equipment, and the equipment and the first virtual cloud host are communicated directly;

generating a template of the device based on the first information, wherein the template is used for guiding the starting of the virtual cloud host;

and starting a second virtual cloud host based on the template, so that the equipment is communicated with the started second virtual cloud host.

In some embodiments, the method further comprises:

And in response to the updating of the first information, updating the template based on the updated first information.

In some embodiments of the present invention, in some embodiments,

The template of the generating device based on the first information includes:

Generating a template of the equipment based on the attribute information contained in the first information and a preset reference template corresponding to the equipment;

Wherein the reference template comprises a mapping relationship between device attributes and feature links for connecting to the device.

In some embodiments, the first information is register information of the device.

In some embodiments, the method further comprises:

performing a predetermined operation with respect to the template, the predetermined operation including at least one of:

Creating a template instance;

deleting the template;

Updating the template;

managing a lifecycle of the template.

In some embodiments, before performing the predetermined operation on the template, the method further comprises:

And receiving second information sent by the cloud platform, wherein the second information is used for indicating the execution of the preset operation on the template.

In some embodiments, prior to launching the second virtual cloud host based on the template, the method further comprises:

Generating the second virtual cloud host in response to a request for generating a virtual cloud host; metadata is injected into the template, the metadata including data for the second virtual cloud host to access an entry of the device after the second virtual cloud host is booted.

In some embodiments, the starting a second virtual cloud host based on the template includes:

determining an entry for the second virtual cloud host to access the device based on metadata in the template; and starting the direct connection between the second virtual cloud host and the equipment based on the entrance.

In some embodiments, before starting the second virtual cloud host, the method further comprises:

establishing a mapping relation between the storage space of the template and the memory allocated for the second virtual cloud host;

and in the process of starting the second virtual cloud host, the second virtual cloud host acquires the data of the template in the storage space based on the mapping relation.

According to a second aspect of an embodiment of the present disclosure, there is provided a device for starting a virtual cloud host, the device including:

An acquisition module configured to: acquiring first information of a started first virtual cloud host, wherein the first information comprises attribute information associated with using equipment, and the equipment and the first virtual cloud host are communicated directly;

a generation module configured to: generating a template of the device based on the first information, wherein the template is used for guiding the starting of the virtual cloud host;

A startup module configured to: and starting a second virtual cloud host based on the template so as to enable the equipment to be communicated with the started second virtual cloud host.

According to a third aspect of embodiments of the present disclosure, there is provided a processing apparatus comprising:

a memory for storing an executable program;

and a processor, configured to implement a method according to any one of the embodiments of the present disclosure when executing the executable program stored in the memory.

According to a fourth aspect of embodiments of the present disclosure, there is provided a computer storage medium storing an executable program which, when executed by a processor, implements a method according to any one of the embodiments of the present disclosure.

In the embodiment of the disclosure, first information of a started first virtual cloud host is obtained, the first information comprises attribute information associated with using equipment, and the equipment and the first virtual cloud host are communicated. In this way, attribute information of the first virtual cloud host that is in direct communication with the device, the attribute information being associated with the use device, may be obtained. And generating a template of the equipment based on the first information, wherein the template is used for guiding the starting of the virtual cloud host. In this way, templates for devices generated based on the attribute information can be obtained. And starting a second virtual cloud host based on the template, so that the equipment is communicated with the started second virtual cloud host. Therefore, the second virtual cloud host can be started based on the generated template, compared with a starting mode based on the BIOS or bootloader, the direct connection between the second virtual cloud host and the equipment can be realized quickly, the process is simpler, the starting of the virtual cloud host can be realized quickly, and the requirements of cloud service can be responded quickly.

Drawings

Fig. 1 is a flow chart illustrating a startup method according to an exemplary embodiment.

Fig. 2 is a flow chart illustrating a startup method according to an exemplary embodiment.

Fig. 3 is a flowchart illustrating a method for booting a virtual cloud host according to an exemplary embodiment.

Fig. 4 is a schematic view of a structure according to an exemplary embodiment.

Fig. 5 is a schematic diagram of a cloud platform system, according to an example embodiment.

FIG. 6 is a schematic diagram of a virtual operating system, according to an example embodiment.

Fig. 7 is a flowchart illustrating a method for booting a virtual cloud host according to an exemplary embodiment.

Fig. 8 is a schematic diagram of a starting device of a virtual cloud host according to an exemplary embodiment.

Detailed Description

The present invention will be further described in detail with reference to the accompanying drawings, for the purpose of making the objects, technical solutions and advantages of the present invention more apparent, and the described embodiments should not be construed as limiting the present invention, and all other embodiments obtained by those skilled in the art without making any inventive effort are within the scope of the present invention.

In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is to be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments and can be combined with one another without conflict.

In the following description, the terms "first", "second", "third" and the like are merely used to distinguish similar objects and do not represent a particular ordering of the objects, it being understood that the "first", "second", "third" may be interchanged with a particular order or sequence, as permitted, to enable embodiments of the invention described herein to be practiced otherwise than as illustrated or described herein.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to be limiting of the invention.

For a better understanding of the embodiments of the present disclosure, the following describes a scenario in the related art by way of exemplary embodiments:

In some embodiments, after the start-up process of the Linux system is simplified, the start-up process may be divided into 4 stages:

Stage 1: the hardware loading the basic input/output system (BIOS, base Input Output System) performs a self-test; a bootable device is obtained according to the setting.

Stage 2: reading and executing a boot loader (namely programs such as grub 2) of a master boot record (MBR, master Boot Record)/unified extensible firmware interface (UEFI, unified Extensible FIRMWARE INTERFACE) in a starting device;

Stage 3: the kernel is loaded according to the boot settings. kernel will start to detect hardware and load drivers;

stage 4: after the hardware driver is successful, the kernel will actively invoke the initialize init process, e.g., systemd for more processes.

It should be noted that this startup procedure is relatively complex, especially in a scenario where there are relatively many hardware devices. For example, the occupied memory is relatively large, requiring all memory space to be initialized to 0; the pass-through of the physical device generally requires that an Input/output memory management unit (IOMMU, input/Output Memory Management Unit) be mapped to the memory space of the virtual cloud host, and the address of this memory space needs to be fixed during the allocation phase.

In some embodiments, in cloud scenarios, it is often necessary to start tens of thousands of services in seconds, and quickly respond to the requirement of the computing power of the service, the start-up of the virtual cloud host is a complex process, which includes multiple processes of power-on self-test in BIOS or UEFI phase, initializing some basic hardware settings, bootloader, kernel start-up, etc., resulting in slow system start-up.

In order to solve the problem of the start-up speed, the following embodiments are provided:

In some embodiments, the loading and initialization process of bootloader, kernel is simplified. Typically a bootloader includes many functions that are only necessary for booting. Bootloader is compiled with fewer functions. And to optimize the desired function. The bootloader is tuned to obtain the fastest performance. The scenes usually used in the embedded device are not suitable for the cloud computing scene, and the cloud computing scene is more of the booting and initializing of the virtual device.

In some embodiments, the secure container is containerized. The container is a sand box technology and mainly aims to isolate an application from the outside when the application runs in the container; and to facilitate the transfer of this sandbox to other host machines. Essentially, it is a special process. Resources, files, devices, states, and configurations are partitioned into a separate space by namespaces (Namespace), control groups (Control groups), and root-slicing (chroot) techniques, etc. The process where the container is not booted is the so-called "out-of-box" service deployment.

In some embodiments, the complexity of the BIOS or bootloader does not allow business users to easily customize their boot scripts, fix problems, build their runtime environment, and flush the firmware with their keys, while waiting for vendor updates. The BIOS or bootloader lets the system start-up from a few minutes to tens of seconds after optimization, which is an order of magnitude different from the ideal few seconds for business. And bootloader is related to the architecture of a central processing unit (CPU, central Processing Unit), the bootloader of a chip (ARM, advanced RISC Machines) CPU with simplified instructions and the bootloader of an X86_64CPU are not universal, and the bootloader is poor in portability and is a serious burden for operation and maintenance personnel.

In some embodiments, the initialization time of the network card, graphics processor (GPU, graphics Processing Unit), NVMe (Non-Volatile Memory express Non-volatile memory host controller interface specification for short) pass-through device is relatively long, and complex procedures such as memory pre-allocation and IOMMU mapping are required, so that various types of problems easily occur.

In some embodiments, containerized deployments are more lightweight, with quick deployment initiation, often considered one of the core advantages of the container. This is not always the case, however, where the time for the local image to instantiate into a container is very short, i.e. "warm boot"; the cold start under the condition of no mirror image in the local area can be realized by downloading the mirror image from the mirror image warehouse and decompressing the mirror image, so that the container can be pulled up, and the cold start is greatly influenced by the performance of a network and a disk and takes a few minutes; large-scale batch cold starts may even result in Registry failing to respond due to network congestion. And the container needs to be updated and adapted, and the number of Virtual devices (VF) and the density of the container are not matched in a Single Root I/OVirtualization (SR-IOV) scene, so that ideal service density cannot be provided. Even though the newer secure container technology is also facing the problem of device pass-through, while secure containers remain a great advantage over boot time, secure containers like kata typically have weak support for external peripheral component interconnect standards (PCI, PERIPHERAL COMPONENT INTERCONNECT) and are difficult to accommodate for various types of pass-through devices, especially some devices also require custom drivers.

In some embodiments, through the memory mapping of the virtualized device, the BIOS and bootloader stages are bypassed, and through the deployment of large-scale high-performance cloud hosts in a batched mode, various types of cloud hosts are compatible, the expandability supported by different devices is provided, and ARM and X86_64 system architectures are compatible.

In some embodiments, please refer to fig. 1, which shows a schematic diagram of a cloud host start-up in the related art; referring to fig. 2, a schematic diagram of cloud host startup in the present disclosure is shown.

As shown in fig. 3, an embodiment of the present disclosure provides a method for starting a virtual cloud host, where the method includes:

Step S31, acquiring first information of a started first virtual cloud host, wherein the first information comprises attribute information associated with a using device, and the device is communicated with the first virtual cloud host;

step S32, generating a template of the equipment based on the first information;

And step S33, starting a second virtual cloud host based on the guidance of the template, so that the equipment and the started second virtual cloud host are communicated.

The embodiment of the disclosure may be applied to a module, an apparatus and a device for implementing a virtual cloud host, for example, may be in a terminal or may be in a server, which is not limited herein, and it is noted that the module may be a functional module.

In some embodiments, the virtual cloud hosts to which the present disclosure relates may be Kernel-based built-in virtual machines (KVM, kernel-based Virtual Machine).

In some embodiments, the method for starting the virtual cloud host in the present disclosure may be applied to a device pass-through scenario of at least one of the following: single Root I/O virtualization (SRIOV, single Root I/O Virtualization), nonvolatile high speed transmission bus (NVMe, non-Volatile Memory express), and virtual image processing units (vGPU, virtual Graphics Processing Unit). It should be noted that device direct connection refers to a use manner in which a physical device on a host is directly presented to a virtual machine, and the virtual machine can directly access a device resource. The virtual machine can obtain good I/O performance by using a device through mode.

In some embodiments, the first virtual cloud host may be an original cloud host that has been currently created. Illustratively, it may be the current host in a kubernates cluster.

In some embodiments, the device communicates directly with the first virtual cloud host. Illustratively, the first virtual cloud host is in direct communication with at least one device. It is of course also understood that the first virtual cloud host is directly connected to the hardware resource of the at least one device, which is not limited herein.

It should be noted that, the precondition of the direct connection between the device and the first virtual cloud host is that the first virtual cloud host has the capability of direct connection with the device, that is, the first virtual cloud host supports direct connection between the device and the first virtual cloud host.

In some embodiments, the first information comprises attribute information associated with the usage device. The attribute information may be characteristic information of the device, for example, resource information and parameter information of the device, and the like. The attribute information may be, for example, register information of the device, for example, configuration space (Configuration Space) information of the PCI.

In some embodiments, all FWCFGFILES (firmware profile) data may be available via the agreed data item FILE fwcfg FILE DIR. The structure is a directory containing all the attributes of a class of devices. In some embodiments, the directory may be expanded according to actual hardware type requirements.

In some embodiments, the device may be a fw_cfg (firmware configured) device. The fw_cfg device is represented using FWCFGSTATE (firmware configuration state) structures in which there is a two-dimensional array entries member to hold data. The first dimension of entries has two elements representing architecture-related data and generic data, respectively.

In some embodiments, nevis _fw based on the fw_cfg extension may be a management device of the template.

In some embodiments, devices of the first virtual cloud host are accessed through nevis _fw application program interfaces (APIs, application Programming Interface), and a dump_device operation is used to obtain a device tree (DEVICE TREE) and corresponding device attribute information for the first virtual cloud host.

In some embodiments, first information of a started first virtual cloud host is obtained, wherein the first information comprises attribute information associated with a device in use, and the device and the first virtual cloud host are communicated through. And generating a template of the equipment based on the first information, wherein the template is used for guiding the starting of the virtual cloud host. And in response to the updating of the first information, updating the template based on the updated first information. And starting a second virtual cloud host based on the template, so that the equipment is communicated with the started second virtual cloud host.

In some embodiments, first information of a started first virtual cloud host is obtained, wherein the first information comprises attribute information associated with a device in use, and the device and the first virtual cloud host are communicated through. Establishing a mapping relation between the characteristic links in the reference template and the attribute information; obtaining a template of the equipment based on the reference template; the template is used for guiding the starting of the virtual cloud host. And starting a second virtual cloud host based on the template, so that the equipment is communicated with the started second virtual cloud host.

In some embodiments, first information of a started first virtual cloud host is obtained, wherein the first information comprises attribute information associated with a device in use, and the device and the first virtual cloud host are communicated through. Generating a template of the equipment based on the attribute information contained in the first information and a preset reference template corresponding to the equipment; wherein the reference template comprises a mapping relationship between device attributes and a feature link, the feature link being for connection to the device; the template is used for guiding the starting of the virtual cloud host. And starting a second virtual cloud host based on the template, so that the equipment is communicated with the started second virtual cloud host.

In some embodiments, the device attribute information may be stored in a corresponding linked list (corresponding to the reference template).

In some embodiments, please refer to fig. 4, the fwcfgcentry type is linked into FWCFGSTATE devices.

In some embodiments, the attribute information (e.g., pciconfiguration space) of different virtual cloud hosts is mostly the same, and only a part of different indexes need to be emptied of clear_entry_data and used as placeholders, so that the virtual cloud hosts can be started for use quickly.

In some embodiments, first information of a started first virtual cloud host is obtained, wherein the first information comprises attribute information associated with a device in use, and the device and the first virtual cloud host are communicated through. And generating a template of the equipment based on the first information, wherein the template is used for guiding the starting of the virtual cloud host. Performing a predetermined operation with respect to the template, the predetermined operation including at least one of: creating a template instance; deleting the template; updating the template; managing a lifecycle of the template. And starting a second virtual cloud host based on the template, so that the equipment and the started second virtual cloud host can be communicated.

In some embodiments, first information of a started first virtual cloud host is obtained, wherein the first information comprises attribute information associated with a device in use, and the device and the first virtual cloud host are communicated through. And generating a template of the equipment based on the first information, wherein the template is used for guiding the starting of the virtual cloud host. And receiving second information sent by the cloud platform, wherein the second information is used for indicating the execution of the preset operation on the template. Performing the predetermined operation with respect to the template, the predetermined operation including at least one of: creating a template instance; deleting the template; updating the template; managing a lifecycle of the template. And starting a second virtual cloud host based on the template, so that the equipment and the started second virtual cloud host can be communicated.

In some embodiments, first information of a started first virtual cloud host is obtained, wherein the first information comprises attribute information associated with a device in use, and the device and the first virtual cloud host are communicated through. And generating a template of the equipment based on the first information, wherein the template is used for guiding the starting of the virtual cloud host. A second virtual cloud host is generated. Starting the second virtual cloud host based on the template; and the equipment and the started second virtual cloud host can be communicated directly.

In some embodiments, first information of a first virtual cloud host is obtained, the first information including attribute information associated with a device in use, the device being in direct communication with the first virtual cloud host. And generating a template of the equipment based on the first information, wherein the template is used for guiding the starting of the virtual cloud host. A second virtual cloud host is generated. In response to generating the second virtual cloud host, metadata is injected into the template, the metadata including data for the second virtual cloud host to access an entry of the device after the second virtual cloud host is booted. Starting the second virtual cloud host based on the template; and the equipment and the started second virtual cloud host can be communicated directly.

In some embodiments, first information of a first virtual cloud host is obtained, the first information including attribute information associated with a device in use, the device being in direct communication with the first virtual cloud host. And generating a template of the equipment based on the first information, wherein the template is used for guiding the starting of the virtual cloud host. Generating the second virtual cloud host in response to a request for generating a virtual cloud host; metadata is injected into the template, the metadata including data for the second virtual cloud host to access an entry of the device after the second virtual cloud host is booted. Starting the second virtual cloud host based on the template; and the equipment and the started second virtual cloud host can be communicated directly.

In some embodiments, metadata such as a contracted number, a character string, etc. may be directly added to the entries, and may be accessed through a contracted index. Illustratively, the function fw_cfg_init1 uses some agreed indexes, e.g., FW_CFG_SIGNATURE is a tag string, FW_CFG_UUID is a virtual machine UUID. These contracted indexes may allow nevis _fw driver to conveniently read these data.

In some embodiments, metadata may be custom data, i.e., data that requires a name to be provided for access, requiring more complex processing, such data may be referred to as a file. Some fields in FWCFGSTATE structures are dedicated to handling the addition of files. Wherein members of type FWCFGFILES, named files, are used to save files in fw_cfg. The count member of FWCFGFILES represents the size of the file item, and f represents all file items, of type FWCFGFILE. The size in FWCFGFILE represents the file size, select represents its index in the entries of FWCFGSTATE, and name represents the file name.

In some embodiments, the initialization data type, data format, size, offset information stored by the fw_cfg NVRAM device may be set by itself, as long as nevis _fw Driver and nevis _ FW METADATA are unified, and the unified data is such that the cloud host can use the initialization data and interact with the fw_cfg device when starting.

In some embodiments, virtual machines may be created in batches through a cloud platform, corresponding hypervisors (referred to as virtual monitors) allocate corresponding virtual machine resources, in particular hardware resources, and then the allocated resources are transferred to a dynamic running module through an API, and the dynamic running module calls nevis _fwset_entry_data to set data (data) of each virtual machine corresponding to each hardware type entry (entry).

In some embodiments, first information of a started first virtual cloud host is obtained, wherein the first information comprises attribute information associated with a device in use, and the device and the first virtual cloud host are communicated through. And generating a template of the equipment based on the first information, wherein the template is used for guiding the starting of the virtual cloud host. Generating the second virtual cloud host in response to a request for generating a virtual cloud host; metadata is injected into the template, the metadata including data for the second virtual cloud host to access an entry of the device after the second virtual cloud host is booted. Determining an entry for the second virtual cloud host to access the device based on metadata in the template; starting a direct connection between the second virtual cloud host and the equipment based on the entrance; and the equipment and the started second virtual cloud host can be communicated directly.

In some embodiments, first information of a started first virtual cloud host is obtained, wherein the first information comprises attribute information associated with a device in use, and the device and the first virtual cloud host are communicated through. And generating a template of the equipment based on the first information, wherein the template is used for guiding the starting of the virtual cloud host. Generating the second virtual cloud host in response to a request for generating a virtual cloud host; metadata is injected into the template, the metadata including data for the second virtual cloud host to access an entry of the device after the second virtual cloud host is booted. Establishing a mapping relation between the storage space of the template and the memory allocated for the second virtual cloud host; and the second virtual cloud host acquires the data of the template in the storage space based on the mapping relation in the process of starting the second virtual cloud host. Determining an entry for the second virtual cloud host to access the device based on metadata in the template; starting the second virtual cloud host based on the entrance; and the equipment is communicated with the started second virtual cloud host.

In some embodiments, nevis _fw Driver obtains ENTRY DATA from nevis _fw NVRAM and writes to nevis _fw Memory.

In some embodiments, the Memory of the fw_cfg NVRAM may be mapped to nevis _fw Memory, so that the boot rate of the virtual cloud host is higher, and the final effect ensures that kernel of the cloud host can directly access configuration information of the device, because the address space (ADDRESSSPACE) of the template and metadata mapped to the virtual machine is fixed, and Memory space and initialization data do not need to be allocated at the time of booting, and kernel can implement delayed initialization (lazy initialization), thereby accelerating the booting of the cloud host.

It should be noted that, as those skilled in the art may understand, the methods provided in the embodiments of the present disclosure may be performed alone or together with some methods in the embodiments of the present disclosure or some methods in the related art.

For a better understanding of the embodiments of the present disclosure, the following further describes the technical solution of the present disclosure by means of an exemplary embodiment:

Referring to fig. 5, the solution of the present disclosure may be applied to a cloud system, which may include modules of at least one of:

An original virtual cloud host module (corresponding to a first virtual cloud host) 51; the module of the original virtual cloud host can generate a template of the device. The template mainly includes register information of the device, for example, configuration Space of PCI;

A device template module 52; wherein the device template module may be for: managing a lifecycle of the template; generating a template through the information of the original virtual cloud host; creating template examples, deleting templates, updating templates, and the like;

A dynamic operation module 53; the dynamic operation module is used for generating final information of the equipment through the template and can be injected into the corresponding virtual cloud host. This process may be associated with the lifecycle of the virtual cloud host;

an external API interface 54; the cloud platform can manage the generation of the templates and the equipment of the equipment through the external API interface, so that the cloud platform is integrated with the cloud platform, a stronger starting speed of a virtual cloud host is provided for the cloud platform, and the service quality (QoS, quality of Service) of the cloud platform is improved.

In some embodiments, the template may be a simple firmware device, which can be used to guide a specific type of cloud host, and replace a standard BIOS or bootloader, so as to improve the efficiency of deploying cloud hosts and quickly provide service support capability of cloud hosts when the cloud hosts are deployed in a large scale. Because the process of device scanning is bypassed while supporting various types of hardware devices, including SRIOV passthrogh devices.

In some embodiments, please refer to fig. 6, nevis _fw extended based on firmware configuration fw_cfg is a management device of the device template, and is stored in the form of firmware in a memory area MemoryRegion of a kernel module qemu (which is a kind of open source simulator and virtual machine supervisor (Virtual Machine Monitor, VMM)) or kvm.

For example 1, please refer to fig. 7, a method for starting up a virtual cloud host is provided, the method comprising:

Step S71, generating a template of the equipment;

in one embodiment, all FWCFGFILES data is available via the agreed data item of FILE fw_cfg_file_dir, and the structure acts as a directory containing all the attributes of a class of devices and can be extended according to the actual hardware type requirements.

In one embodiment, the fw_cfg device is represented using FWCFGSTATE structures, where there is one two-dimensional array entries member to hold the data. The first dimension of entries has two elements representing architecture-related data and generic data, respectively.

In one embodiment, the device of the original virtual machine is accessed through nevis _fw API, DEVICE TREE and corresponding device attributes of the virtual machine are obtained using dump_device operation and stored in a corresponding linked list, such as type FWCFGENTRY in FIG. 4, and linked into FWCFGSTATE devices; most types of pciconfiguration space of different virtual machines are the same, and only part of different indexes need to be emptied of clear_entry_data and used as placeholders so as to quickly start the use of the virtual cloud host.

Step S72, managing templates and metadata;

In one embodiment, simple data such as contracted numbers, character strings and the like can be directly added to the entries and can be accessed through contracted indexes. The function fw_cfg_init1 uses some agreed indexes, for example, the FW_CFG_SIGNATURE item is a tag string, and the FW_CFG_UUID item stores a virtual machine UUID. These contracted indexes may allow nevis _fw driver to conveniently read these data.

In one embodiment, for other data, typically custom data, i.e., data that needs to be provided with a name to access, more complex processing is required, such data being referred to as a file. Some fields in FWCFGSTATE structure are dedicated to handling the addition of files, where members of type FWCFGFILES, named files, are used to save files in fw_cfg. The count member of FWCFGFILES represents the size of the file item, and f represents all file items, of type FWCFGFILE. The size in FWCFGFILE represents the file size, select represents its index in the entries of FWCFGSTATE, and name represents the file name.

In one embodiment, the initialization data type, data format, size, offset information stored by the fw_cfg NVRAM device may be set by itself, as long as nevis _fw Driver and nevis _ FW METADATA are unified, and the unified data is such that the cloud host can use the initialization data and interact with the fw_cfg device when starting.

Step S73, injecting metadata into the templates, and generating virtual machines in batches;

And the operation and maintenance personnel create virtual machines in batches through the cloud platform, the corresponding Hypervisor allocates corresponding virtual machine resources, particularly hardware resources, the allocated resources are transmitted to the dynamic operation module through the API, and the dynamic operation module calls nevis _fw set_entry_data to set the data of each hardware type entry of each virtual.

And S74, restoring the state of the restore related equipment in the virtual cloud host, and starting operation.

In one embodiment, nevis _fw Driver obtains ENTRY DATA from nevis _fw NVRAM and writes it to nevis _fw Memory, and in a more general way, the Memory of fw_cfg NVRAM can be mapped to nevis _fw Memory, so that the starting rate of the virtual cloud host is higher, the final effect ensures that kernel of the cloud host can directly access configuration information of the device, because ADDRESSSPACE mapped to the virtual machine by the template and metadata is fixed, memory space is not allocated at the time of starting, initializing data is not necessary, and kernel can implement lazy initialization, thereby accelerating the starting of the cloud host.

In the embodiment of the disclosure, on one hand, the starting up of the virtual cloud host is accelerated, and the resource requirement of the service is responded quickly. Because the BIOS or bootloader stage does not exist, and the initialization of kernel data is not needed in the starting stage, especially the scan, initialize operation of the hardware device is not needed, the virtual machine can read the injected metadata in the starting stage, so that the starting of the system can be accelerated.

In the second aspect, virtual cloud hosts can be created in batches, so that the concurrency of service resource application is improved. In addition, because the booting stage of the virtual cloud host is shortened and the key lazy initializaiton is added, the resources allocated and used in the starting stage of the virtual cloud host are greatly reduced, and under the same resource condition, the scheme can support more cloud hosts to be simultaneously and concurrently started and provide the resources required by the service faster.

In a third aspect nevis _fw is simple to use and standardized. Since nevis _fw is used as an expansion device of fw_cfg, only the related data types need to be expanded, and the read-write drive corresponding to the expansion fw_cfg is only needed, and the modification on the cloud platform and the service is small, so that the implementation is easy, the user does not feel any sense, and the existence of nevis _fw cannot be felt.

As shown in fig. 8, in an embodiment of the present disclosure, there is provided a device for starting a virtual cloud host, where the device includes:

an acquisition module 81 configured to: acquiring first information of a started first virtual cloud host, wherein the first information comprises attribute information associated with using equipment, and the equipment and the first virtual cloud host are communicated directly;

a generation module 82 configured to: generating a template of the device based on the first information, wherein the template is used for guiding the starting of the virtual cloud host;

A start module 83 block configured to: and starting a second virtual cloud host based on the template, so that the equipment is communicated with the started second virtual cloud host.

The disclosed embodiments provide a processing apparatus including:

a memory for storing an executable program;

It will be appreciated that the memory can be either volatile memory or nonvolatile memory, and can include both volatile and nonvolatile memory. Wherein the nonvolatile Memory may be Read Only Memory (ROM), programmable Read Only Memory (PROM, programmable Read-Only Memory), erasable programmable Read Only Memory (EPROM, erasable Programmable Read-Only Memory), electrically erasable programmable Read Only Memory (EEPROM, ELECTRICALLY ERASABLE PROGRAMMABLE READ-Only Memory), magnetic random access Memory (FRAM, ferromagnetic random access Memory), flash Memory (Flash Memory), magnetic surface Memory, optical disk, or compact disk-Only Memory (CD-ROM, compact Disc Read-Only Memory); the magnetic surface memory may be a disk memory or a tape memory. The volatile memory may be random access memory (RAM, random Access Memory) which acts as external cache memory. By way of example, and not limitation, many forms of RAM are available, such as static random access memory (SRAM, static Random Access Memory), synchronous static random access memory (SSRAM, synchronous Static Random Access Memory), dynamic random access memory (DRAM, dynamic Random Access Memory), synchronous dynamic random access memory (SDRAM, synchronous Dynamic Random Access Memory), double data rate synchronous dynamic random access memory (ddr SDRAM, double Data Rate Synchronous Dynamic Random Access Memory), enhanced synchronous dynamic random access memory (ESDRAM, enhanced Synchronous Dynamic Random Access Memory), synchronous link dynamic random access memory (SLDRAM, syncLink Dynamic Random Access Memory), direct memory bus random access memory (DRRAM, direct Rambus Random Access Memory). The memory described by embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.

The method disclosed by the application can be applied to the processor or realized by the processor. The processor may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the method of speech conversion may be performed by integrated logic circuitry in hardware in a processor or by instructions in the form of software. The Processor may be a general purpose Processor, a digital signal Processor (DSP, digital Signal Processor), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. The processor may implement or perform the methods, steps, and logic blocks disclosed in the present application. The general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed by the application can be directly embodied as the execution of the hardware decoding processor or the combined execution of the hardware and software modules in the decoding processor. The software module may be located in a storage medium, where the storage medium is located, and where the processor reads information in the storage medium, and in combination with its hardware, performs the steps of the method for speech conversion provided by the embodiments of the application.

The present application also provides a computer storage medium storing an executable program which, when executed by a processor, implements a method according to any one of the embodiments of the present disclosure. In particular, the computer readable storage medium may be a computer program, for example, comprising a memory storing a computer program executable by a processor of a processing device for performing the steps of the method according to the embodiments of the present application. The computer readable storage medium may be ROM, PROM, EPROM, EEPROM, flash Memory, magnetic surface Memory, optical disk, or CD-ROM.

The foregoing is merely illustrative of the present invention, and the present invention is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present invention. Therefore, the protection scope of the invention is subject to the protection scope of the claims.

Claims

1. A method for starting a virtual cloud host, the method comprising:

2. The method according to claim 1, wherein the method further comprises:

3. The method of claim 1, wherein the generating a template for a device based on the first information comprises:

Generating a template of the equipment based on the attribute information contained in the first information and a preset reference template corresponding to the equipment; wherein the reference template comprises a mapping relationship between device attributes and feature links for connecting to the device.

4. A method according to any one of claims 1 to 3, wherein the first information is register information of the device.

5. The method according to claim 1, wherein the method further comprises:

performing a predetermined operation on the template, the predetermined operation including at least one of:

Creating a template instance;

deleting the template;

Updating the template;

managing a lifecycle of the template.

6. The method of claim 5, wherein prior to performing the predetermined operation on the template, the method further comprises:

7. The method of claim 1, wherein prior to launching a second virtual cloud host based on the template, the method further comprises:

Generating the second virtual cloud host in response to a request for generating a virtual cloud host;

metadata is injected into the template, the metadata including data for the second virtual cloud host to access an entry of the device after the second virtual cloud host is booted.

8. The method of claim 7, wherein the launching a second virtual cloud host based on the template comprises:

determining, based on metadata in the template, an entry for the second virtual cloud host to access the device;

and starting the direct connection between the second virtual cloud host and the equipment based on the entrance.

9. The method of claim 1, wherein prior to booting the second virtual cloud host, the method further comprises:

10. A device for starting a virtual cloud host, the device comprising:

A startup module configured to: and starting a second virtual cloud host based on the template, so that the equipment is communicated with the started second virtual cloud host.

11. A processing apparatus, characterized in that the processing apparatus comprises:

a memory for storing an executable program;

a processor for implementing the method according to any one of claims 1 to 9 when executing an executable program stored in said memory.

12. A computer storage medium storing an executable program which, when executed by a processor, implements the method of any one of claims 1 to 9.