CN107562518B

CN107562518B - Video card ROM extraction and collection system and method based on KVM virtualization technology

Info

Publication number: CN107562518B
Application number: CN201710745163.6A
Authority: CN
Inventors: 沈东立; 李皓霖; 洪鑫; 邵羽
Original assignee: Hangzhou Cloudolize Technology Co ltd
Current assignee: Hangzhou Cloudolize Technology Co ltd
Priority date: 2017-08-26
Filing date: 2017-08-26
Publication date: 2020-12-18
Anticipated expiration: 2037-08-26
Also published as: CN107562518A

Abstract

The invention relates to the technical field of computer virtualization, in particular to a system and a method for extracting and collecting a display card ROM (read only memory) based on a KVM (keyboard, video and mouse) virtualization technology for a direct display card. A video card ROM extraction and collection system based on a KVM virtualization technology comprises a host machine, a local server and a cloud server which are sequentially connected. The invention greatly reduces the complexity of rom extraction, so that common users can use the technology, the rom of the display card agrees to collect and store, and the usability of the kvm single display card is ensured when no centralized display is output.

Description

Video card ROM extraction and collection system and method based on KVM virtualization technology

Technical Field

The invention relates to the technical field of computer virtualization, in particular to a system and a method for extracting and collecting a display card ROM (read only memory) based on a KVM (keyboard, video and mouse) virtualization technology for a direct display card.

Background

At present, with the development of computer hardware, people are increasingly pressing for the maximum utilization of hardware resources. From the proposal of the virtual machine concept in the sixth and seventies of the last century to the current increasing maturity of virtualization technology, a favorable solution is provided for the realization of the requirements of people.

The KVM must rely on hardware virtualization technology provided by CPU, and x86 hardware platform represented by Intel and AMD has also introduced many virtualization related hardware features in recent years, including original basic VT support and EPT \ VPID of CPU, VT-d and SR-IOV of I/O device, and latest APIC-v and Shadow VMCS. As x86 hardware matures to support virtualization technology, the virtualization efficiency of KVM on the latest hardware platform is greatly improved.

In addition to the mature virtualization technology in terms of hardware, KVM is gaining favor as a Linux kernel virtual machine from a large number of Linux software developers. Undoubtedly, Red Hat company is the biggest strength in KVM development, and many Red Hat engineers become core development members in KVM, QEMU, libvirt and other open-source communities. In addition to Red Hat, there are many well known companies that have many software developers that contribute their code to KVM, such as IBM, Intel, Novell, AMD, Siemens, huachen, etc. In addition to developers of these large companies, hundreds of small companies and individual independent developers are actively in the KVM open source community to develop code or perform testing work for KVM.

Under the common conditions of virtualization support in hardware aspect and function development and performance optimization in software aspect, the KVM virtualization technology has abundant functions and excellent performance. Moreover, the upper-layer application software and cloud computing platforms (such as libvirt, Ovirt, Virt-Manager, OpenStack, etc.) of KVM virtualization are also becoming mature. Therefore, KVM has become a very good choice for individuals and businesses to do system virtualization or the underlying virtualization of cloud platform construction.

The kvm virtual machine based on the intel vt technology is a full virtualization scheme adopting hardware-assisted virtualization, and is integrated into each main release version of a kernel in a module form after the Linux kernel version 2.6.20. The KVM virtual machine can directly output an output picture of a graphics card to a screen by combining with vfio of QEMU in the Linux system, so that the graphics card is directly connected, but when the graphics card is used as a preferred output item of a motherboard (that is, motherboard information output when the computer is started is under the graphics card), especially for some motherboards without integrated graphics card output, the graphics card for outputting the motherboard information cannot be used for the display card connection of the virtual machine, because in this case, after the graphics card is directly connected to the virtual machine, the graphics card cannot output the content of the virtual machine when the virtual machine is started. Thereby rendering the virtual machine unusable. However, when the display card is in the preferred display output, the display card through realized by the method cannot directly output the output picture of the display card to the screen under the condition that no display card rom file exists. The solution to this problem is to extract a rom (a file of the graphics card bios, hereinafter referred to as a graphics card rom) of the graphics card, and mount the rom file under the graphics card. This process is usually manually performed by kvm system engineers, and the rom of each unused display card is also different, which results in technical difficulties for some common kvm virtual machine users.

Disclosure of Invention

The invention aims to provide a video card ROM extraction and collection system for a through video card based on a KVM virtualization technology, so as to realize convenient calling and unified collection of video cards ROM.

In order to solve the technical problem, the invention provides a graphics card ROM extraction and collection system based on a KVM virtualization technology.

The video card ROM extraction and collection system based on the KVM virtualization technology comprises a host machine, a local server and a cloud server which are sequentially connected,

the host machine can send a rom obtaining request to the local server, obtain the rom from the local server, or extract the local rom of the host machine and upload the rom to the local server;

the local server and the cloud server are both stored with a video card rom, and the rom can be transmitted mutually.

Wherein,

when a host computer is started, sending a request for acquiring rom to a local server;

when the needed rom exists in the local server, the server returns the rom to the host machine;

if the rom does not exist in the local server, the local server sends a request to the cloud server to acquire the rom;

if the rom exists in the cloud service, a request for acquiring the cloud rom is sent to a cloud server, the cloud server issues the rom file to a local server through file stream transmission, then the rom file is verified through the md5 value, whether the rom file is successfully received is confirmed, if the rom file is successfully received, the rom file is continuously transmitted to a host through the file stream, and whether the rom file is successfully transmitted is judged through md5 verification. If the download is successful, outputting a prompt that the host successfully downloads the rom, and if the download is failed, outputting a failure log and recording the failure log to a database;

if the rom does not exist in the cloud server or the connection with the cloud server cannot be established, the host machine is informed to extract the rom locally;

uploading the rom to a local server after the extraction is successful;

uploading the data to a cloud server by a local server for storage so as to facilitate later calling;

and after receiving the rom file, the cloud server stores the rom file in the cloud.

Preferably, the local server and the cloud server are classified, collected and stored according to different display cards rom.

In addition, the invention provides a method for acquiring and uploading rom of a through display card in KVM virtualization, which mainly comprises the following steps:

1) when a host computer is started, a rom is obtained from a local server;

2) if the host computer in the step 1) fails to acquire the rom from the local server, the local server acquires the rom from the cloud server;

3) if the local server in the step 2) fails to acquire the rom from the cloud server; the local server cloud server informs the host machine of locally extracting rom;

4) and 3) uploading the rom extracted in the step 3) to a local server and a cloud server in sequence for storage.

The method specifically comprises the following steps:

(1) when a host computer is started, sending a request for acquiring rom to a local server;

(2) when the needed rom exists in the local server, the server returns the rom to the host machine;

(3) if the rom does not exist in the local server, the local server sends a request to the cloud server to acquire the rom;

(4) if the rom exists in the cloud service, a request for acquiring the cloud rom is sent to a cloud server, the cloud server issues the rom file to a local server through file stream transmission, then the rom file is verified through an md5 value, whether successful receiving is achieved is confirmed, if successful receiving is achieved, the rom file is continuously transmitted to a host through file stream, and whether successful transmission is achieved is judged through md5 verification. If the download is successful, outputting a prompt that the host successfully downloads the rom, and if the download is failed, outputting a failure log and recording the failure log to a database;

(5) if the rom does not exist in the cloud server or the connection with the cloud server cannot be established, the host machine is informed to extract the rom locally;

(6) after the rom is successfully extracted, the rom is uploaded to a local server, and after the local server receives the rom file, the rom file is stored in the local server;

(7) the local server uploads the rom file to the cloud server for storage, and the cloud server stores the rom file in the cloud after receiving the rom file so as to facilitate later calling. And after receiving the rom file, the cloud server stores the rom file in the cloud, so that the collection function is realized.

The invention writes a kvm virtual machine display card rom automatic extraction script, and the content is a detailed explanation of the script, and meanwhile, in consideration of the limitation of rom extraction (when a display card is occupied by mainboard output, rom extraction cannot be carried out), a common rom library is set at a cloud end and comprises a folder for storing rom files and a database table for recording rom information, wherein the database table comprises the file name of rom and the md5 value of rom, different display cards rom in the market are classified, collected and stored, and when local rom cannot be automatically extracted, rom can be automatically downloaded from the cloud end. The complexity of rom extraction is greatly reduced, so that a common user can use the technology, the rom of the display card agrees to collect and store, and the usability of the kvm single display card is ensured when no centralized display is output.

Host deployment process:

and packing the mikuwake script on the host machine by using the pyinstteller, setting the script to boot and self-start, packing the system, and putting the packed system into a guide file to guide the host machine to boot.

Deployment process of the local server:

mysql is installed, username root password is set to dtx60pp, port 3306, localhost has access

Executing in the database:

CREATE TABLE gpurom(id varchar(40),md5varchar(255),PRIMARY KEY(id))；

CREATE TABLE`ocloudlog`(`time`varchar(30)CHARACTER SET latin1COLLATE latin1_swedish_ci NULL DEFAULT NULL,`event`varchar(20)CHARACTER SET latin1 COLLATE latin1_swedish_ci NULL DEFAULT NULL,`brief`varchar(255)CHARACTER SET latin1COLLATE latin1_swedish_ci NULL DEFAULT NULL)；

the pymysql module of python3 was installed, recommended for pip loading. pip3install pymysql

Py script, such as fileServer, is opened with pythong3

python3fileServer.py

The script needs root authority, and the Rom file default storage position/root/Rom/romPath/need to be established

Deployment process of the cloud server:

Executing in the database:

CREATE TABLE romlist(id varchar(40),md5sum varchar(255),PRIMARY KEY(id))；

Opening scripts with native ip parameters, e.g.

./romserver 18.18.233.250

Script version is looked up with/romserver-v

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art are briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings while paying creative efforts.

FIG. 1 is the number of verdor, product and subsystem of the present invention obviously clamped on the kvm virtualization host machine

FIG. 2 is a simplified schematic diagram of the present invention

FIG. 3 is a host flow chart

FIG. 4 is a flow chart of a local server

FIG. 5 is a flow chart of a cloud server

Detailed Description

In order to make the technical solutions of the present invention better understood, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

A video card ROM extraction and collection system based on a KVM virtualization technology comprises a host machine, a local server and a cloud server which are sequentially connected, wherein,

uploading the rom to a local server after the extraction is successful;

The method specifically comprises the following steps:

when a host computer is started, firstly, the display card information is obtained through a script, and then a request for obtaining rom is sent to a local server through the display card information. This information includes: the number of independent display cards, and the vendor, product and subSystem numbers of each display card. And waits for the local server's return value.

The local server receives a message requesting a video card rom file from a host, matches the corresponding video card rom file in a database of the local server through video card vendor, product and subSystem numbers contained in the message, finds a storage path of the corresponding video card rom file if matching is successful, and returns the video card rom file and the md5 value to the host, after the host receives the message, the host checks the md5 value once to ensure consistency of the file before and after sending, and after the check is passed, the rom value is used, and the file transmission mode used at this time is transmission through the file stream of socket. And after successful transmission, logs are recorded. If an exception occurs, the server stops file transmission and records the exception log.

The method comprises the steps that a local server receives a message of requesting a video card rom file from a host, the video card vendor, product and subSystem serial numbers contained in the message are used for matching the corresponding video card rom file in a database of the local server, if matching fails, connection with a cloud terminal is tried first, security verification is carried out before connection, if verification fails, reconnection is tried for 5 times, connection with the cloud terminal server fails for 5 times, a rom obtaining request is sent to the cloud terminal server, the rom file is tried to be obtained from the cloud terminal server, and the request message contains the video card vendor, product and subSystem serial numbers. And waits for the return value of the cloud server.

The cloud server receives a message requesting a video card rom file from a local server, matches a corresponding video card rom file in a database of a cloud-end server through a video card vendor, a product and a subSystem number contained in the message, finds a corresponding video card rom file storage path if matching is successful, returns the video card rom file and an md5 value corresponding to the file to the local server, performs md5 verification once after the local server receives the rom file to ensure consistency of the file before and after transmission, records the rom file and the md5 in the database after verification, transmits the rom file to a host through file streaming, verifies through the md5, and judges whether transmission is successful or not. And if the data is successful, outputting a prompt that the host successfully downloads the rom, and if the data is failed, outputting a failure log and recording the failure log to a database. As described above, the file transfer method used here is to transfer the file stream of the socket. And after successful transmission, logs are recorded. If an exception occurs, the server will stop the file transmission and record the exception log.

The cloud server receives a message requesting a video card rom file from the local server, matches the corresponding video card rom file in a database of the cloud server through the video card vendor, product and subSystem numbers contained in the message, returns a message that the cloud server does not have the rom to the local server if the matching fails, forwards the message to the host computer by the local server, and executes local extraction of the rom script after the host computer receives the message.

And if the connection between the local server and the cloud server fails, returning a message of the connection failure with the cloud server to the host, and executing the local extraction rom script after the host receives the message.

The steps of the script include:

each of the different brands of graphics cards has a deviceID and a subsystem ID, viewed by the lspci-nnk command, as shown in FIG. 1, 10de:1c03 is the deviceID of the graphics card, and 7377:0000 is the subsystem ID of the graphics card

Each graphics card also has a bootVga value, which passes under the linux system

And viewing by a cat/sys/bus/pci/device/0000: xx: xx.x/boot _ vga command, wherein if the return value is 1, the display card is bootVga, and the rom of the display card cannot be automatically extracted, and otherwise, the rom of the display card can be extracted.

The automatic extraction of rom script, getrom.sh, requires 3 input parameters:

● display card PCI number, e.g. 0000:01:00.0

● the graphics card corresponds to a virtual machine number, example 1

● the device unique ID of the display card, 10de 1401:7377:0000

● Exampexample/getRom.sh 0000:01: 00.0110 de:1401:7377:0000

The script mainly comprises the following components:

1. virtual machine with automatic switch binding the display card

2. Run "echo 1>/sys/bus/pci/device/xxxx: xx: xx.xx/rom"

3. Run "cat/sys/bus/pci/device/xxxx: xx.x/rom >

root/rom/deviceID, subsystem System ID. dump "and the storage path of rom file is/root/rom

4. Run "echo 0>/sys/bus/pci/device/xxxx: xx: xx.xx/rom"

5. Binding the video card to the VFIO by the run/boot/config/VFIO-bind xxxx: xx.x script

After the host receives the return value of the local server, if the return value is that the cloud server does not have the needed rom, the rom file and the md5 value of the file are uploaded to the local server after the rom is extracted locally, and if the return value is that the connection with the cloud server fails, the rom is not uploaded after the rom is extracted locally.

After receiving the rom file and the md5 value uploaded by the host, the local server checks the md5 value, stores the rom file locally after the check is passed, records the rom file in a database, and uploads the md5 value and the received rom file to the cloud server.

After the cloud server receives the rom file and the md5 value uploaded by the local server, the md5 value is verified, and after the verification is passed, the rom is stored locally and recorded in the database. If the acceptance is successful, the system records a log, and if the acceptance is failed, the system records a failure log.

Storing a python script for starting up execution on a host machine or under a boot path, adding a starting command of the script in an/etc/rc.d/rc.local starting file to realize starting up, and creating a configuration file of a virtual machine under a/boot/config folder for creating and starting the virtual machine.

And creating a table of the display card rom in a database on the local server, creating a folder of a corresponding path to store the display card rom, and starting a server script in a background by using screen.

And a romlist table is created in a database of the cloud server, a rom storage path is created, and a server script is started in a background by using screen.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims.

Claims

1. Video card ROM draws collection system based on KVM virtualization technology its characterized in that: comprises a host machine, a local server and a cloud server which are connected in sequence,

the local server and the cloud server are both stored with a display card rom and can transmit the rom with each other;

wherein,

if the rom exists in the cloud server, sending a request for acquiring the cloud rom to the cloud server, issuing the rom file to the local server by the cloud server through file stream transmission, checking through an md5 value, determining whether the rom file is successfully received, if the rom file is successfully received, continuing to transmit the rom file to the host through the file stream, checking through an md5 value, and judging whether the rom file is successfully transmitted; if the download is successful, outputting a prompt that the host successfully downloads the rom, and if the download is failed, outputting a failure log and recording the failure log to a database;

uploading the rom to a local server after the extraction is successful;

2. The graphics card ROM extraction collection system based on KVM virtualization technology of claim 1, wherein: the rom acquires a request and calls display card information of a script to match, wherein the display card information comprises: the number of independent display cards, and the vendor, product and subSystem numbers of each display card.

3. The graphics card ROM extraction collection system based on KVM virtualization technology of claim 1, wherein: and transmitting the md5 value during the transmission of the rom file, and performing consistency check through the md5 value after transmission.

4. The graphics card ROM extraction collection system based on KVM virtualization technology of claim 1, wherein: and the local server and the cloud server are classified, collected and stored according to different display cards rom.

5. The graphics card ROM extraction collection system based on KVM virtualization technology of claim 1, wherein: the host machine and the local server are 1 or more.

6. The graphics card ROM extraction collection system based on KVM virtualization technology of claim 1, wherein: the host machine locally extracts rom scripts, and the script steps include:

each of the different brands of graphics cards has a deviceID and a subsystem ID, viewed by lspci-nnk command, 10de:1c03 is the deviceID of the graphics card, and 7377:0000 is the subsystem ID of the graphics card

Viewing by cat/sys/bus/pci/device/0000: xx: xx.x/boot _ vga command, if the return value is 1, the display card is bootVga, and the rom of the display card cannot be automatically extracted, otherwise, the rom can be extracted;

the automatic extraction of rom script, getrom.sh, requires 3 input parameters:

1) display card PCI number

2) The display card corresponds to the virtual machine number

3) The device unique ID of the graphics card.

7. The graphics card ROM extraction collection system based on KVM virtualization technology of claim 1, wherein: the script mainly comprises the following steps:

1. virtual machine with automatic switch binding the display card

2. Run "echo 1>/sys/bus/pci/device/xxxx: xx: xx.xx/rom"

3. The operation is 'cat/sys/bus/pci/device/xxxx: xx: xx.x/rom >/root/rom/device ID: subsystemID.dump' and the storage path of the rom file is/root/rom

4. Run "echo 0>/sys/bus/pci/device/xxxx: xx: xx.xx/rom"

5. And binding the video card to the VFIO by a running/boot/config/VFIO-bind xxxx: xx.

8. A video card ROM extraction and collection method based on a KVM virtualization technology is characterized by comprising the following steps: the method comprises the following steps:

1) when a host computer is started, a rom is obtained from a local server;

3) if the local server in the step 2) fails to acquire the rom from the cloud server; the cloud server informs the host machine of extracting rom locally;

4) and 3) uploading the rom extracted in the step 3) to a local server in sequence, wherein the local server needs to store the rom so that hosts on the same local server can share the rom and the cloud server can store the rom.

9. A video card ROM extraction and collection method based on a KVM virtualization technology is characterized by comprising the following steps: the method specifically comprises the following steps:

(4) if the rom exists in the cloud service, sending a request for acquiring the cloud rom to a cloud server, issuing a rom file to a local server by the cloud server through file stream transmission, checking through an md5 value, determining whether the rom file is successfully received, if the rom file is successfully received, continuing to transmit the rom file to a host through a file stream, checking through an md5 value, and judging whether the rom file is successfully transmitted; if the download is successful, outputting a prompt that the host successfully downloads the rom, and if the download is failed, outputting a failure log and recording the failure log to a database;

(7) and the local server uploads the rom file to the cloud server for storage, and the cloud server stores the rom file in the cloud after receiving the rom file.