The 10th China Cloud Computing Standards and Applications Conference was grandly held in Beijing from December 29 to 30, 2020, hosted by the China Electronics Standardization Institute (hereinafter referred to as the Electronics Standards Institute) and undertaken by the China Open Source Cloud Alliance, Mulan Open Source Community, National Cloud Computing Standard Working Group, and the Key Laboratory of Cloud Computing Standards and Applications of the Ministry of Industry and Information Technology. This conference focused on the theme of “Standards Gather Strength, Open Source Wins Together”.

Today, my sharing mainly includes several aspects: the What, Why, and How of the openEuler virtualization technology StratoVirt, as well as future technology roadmap.
First, let me introduce StratoVirt. The name is derived from Stratosphere, which is the Earth’s stratosphere. As we know, airplanes fly in the stratosphere, which is the most stable and secure layer, also protecting our Earth. Therefore, the meaning of this name is to provide a lightweight protective layer for the stable operation of openEuler’s business. StratoVirt adopts a unified architecture that supports three scenarios: virtual machines, containers, and Serverless. Its main features are lightweight, low noise, and soft-hard collaboration. Our vision is to provide lightweight, flexible, secure, and comprehensive protection capabilities.
StratoVirt includes six major features: we support both lightweight and standardized scenarios. Lightweight features include strong security, lightweight low noise, and rapid scalability, while standardization includes soft-hard collaboration, high scalability, and heterogeneous enhancement. Strong security is achieved because we use Rust language and support Seccomp, greatly enhancing StratoVirt’s security; lightweight low noise means that under a minimalist device model, the startup time of a single virtual machine is less than 50 milliseconds, with memory consumption less than 4MB, supporting Serverless loads; rapid scalability enables millisecond-level device scaling capabilities. If a long-term business requires strong scalability, our solution is the most suitable; soft-hard collaboration supports X86 and Kunpeng-V; high scalability recognizes that lightweight and standardized demands are different, and the device model is extensible, allowing layers of addition based on needs, supporting complex device specifications like PCI. Currently, we are also working on supporting standardized products; heterogeneous enhancement addresses the high computing power demands of AI. We not only support hardware passthrough solutions but can also integrate deep software-defined capabilities to achieve more flexible heterogeneous allocation.
Why do we need StratoVirt? I would like to elaborate from three dimensions: When it comes to virtualization, one cannot ignore the virtualization software QEMU. It has 1.5 million lines of code, including a lot of outdated historical code and support for old devices, but some of it is very redundant for current lightweight or standardized scenarios. Currently, QEMU still has a large number of CVEs each year, with the highest being 91 CVEs in 2016, many of which are related to security vulnerabilities concerning memory, such as Overflow, Memory Corruption, etc. Now we are also looking for a path of redemption, so we choose to write virtualization components in Rust to enhance system security.
Another dimension is resource isolation. The currently widely used lightweight scenario is Docker technology, which, despite its speed, has the drawback of poor security isolation. For example, if multiple containers are started, and different businesses run in each container, if one business hangs the kernel, all containers and businesses on the host will hang, which is unacceptable for public cloud scenarios as it affects other customers’ businesses. Naturally, one can think about whether it is possible to create a solution that is both lightweight and fast, yet has good isolation. Hence, we have the current MicroOM, which has small startup and memory consumption while also providing strong isolation like virtual machines. Currently, the industry uses K8S + Docker + kata + qemu + container, where containers run business within virtual machines. In openEuler, the corresponding software stack is ISula interfacing with KATA, using StratoVirt to create virtual machines. StratoVirt is a new, fast virtualization software with good isolation.
The evolution direction of virtualization software in the industry is that writing virtualization software with Rust is something that various vendors are pursuing, and we are certainly not the first. In 2017, Google wrote a virtualization software called CrosVM in Rust, but it has not been widely adopted so far. The most successful is Amazon’s FireCracker, which does not support standard virtualization scenarios. Subsequently, Amazon encapsulated common components, such as the reference and control of KVM, into a Rust library, creating an open-source project community called RustVMM. Everyone can base their custom virtualization software on the public library of RustVMM according to their business characteristics. Of course, Intel is also working on Cloud-HyperVisor, which can be compared later. Currently, from the entire industry perspective, writing lightweight, fast, and strong isolation virtualization software using Rust is a trend for the future.
Let’s look at the architecture design of StratoVirt. Compared to FireCracker, it occupies the same position, borrowing KVM hardware-assisted virtualization capabilities below. As everyone knows, KVM utilizes the resources of the native system, just like other kernel components using system resources. Thus, we directly leverage the KVM module for CPU and memory simulation. Above, we support Docker/isula for container scenarios, applying Libvirt/OpenStack to standardized scenarios. At the top, we provide a unified interface of Machine Manager interfacing with Isula and LibVirt. The key components are the Device Model, which is responsible for all device simulation. Next is the Address Space, which manages the memory of virtual machines. The memory presented to customers is managed by the Address Space. Finally, the Boot Loader performs some rapid startup actions, allowing StratoVirt to have a shorter startup time. The architecture of StratoVirt is modular and flexibly configurable. As seen in the diagram, the hardware requirements for lightweight scenarios are very simple, so we do not need to implement a lot of redundant and complex devices like standard virtual machines. We can define different motherboard types for virtual machines based on different scenarios. For lightweight applications, we can define a Micro Machine Board, which includes a bus, CPU, flat memory, and virtio device to support lightweight applications. However, for standardized applications, we can also define a regular Machine Board with CPU, memory, and virtio devices, as well as a PCI system to support standardized application scenarios. The advantage is that we can customize the required motherboard and other hardware according to business demands. Next, I will briefly introduce several core submodules of StratoVirt and two main features.
First, let’s look at the top-level directory of StratoVirt, which mainly includes four parts: Address Space is for address space simulation, used to manage the memory addresses provided to virtual machines; Boot Loader is the memory boot program, used to achieve fast loading and startup; Device Model is for simulating various devices, characterized by extensibility, combinability, and high flexibility; finally, Machine Manager provides a management interface for virtual machines, compatible with QMP commands, and can interface with Isula and Libvirt.
As mentioned earlier, lightweight scenarios have low hardware requirements, so let’s briefly introduce the lightweight virtual machine model. In lightweight scenarios, only some basic formats or data related to computing tasks are needed, and we have greatly simplified the virtual machine model. As seen in the diagram, we have implemented an MMIO bus; the rest consists of memory and CPU, forming a lightweight virtual machine model. Now let’s talk about StratoVirt’s three subsystems: CPU subsystem, memory subsystem, and IO subsystem.
For StratoVirt, the CPU subsystem is quite simple; we use KVM hardware-assisted virtualization capabilities, implementing virtual CPU hardware acceleration based on the interfaces exposed by KVM. Of course, during the implementation process, to support multiple architectures, we can hide architectural differences through CPU architecture. The specific implementation for X86 is within the specific architecture; this is the definition of the CPU object. If you are interested, you can read the StratoVirt code, which is now open-source and contains a lot of reverse indexing. The benefit is that when expanding devices inside the virtual machine, the CPU can access this object.
Let’s introduce our memory subsystem, Address Space. All virtual machine memory is managed here, through the Root Region managing all memory spaces. The memory space management of StratoVirt resembles this structure, providing a segment of address space, with each segment forming a tree structure, allowing us to define different priorities for each Region. Later, based on priority, we can present a flat view, as in standardized scenarios where we may need to support stacked memory. Of course, in lightweight scenarios, only flat memory support is needed. We have also added a variable called Listener in the Address Space, which can listen for changes in the address space and perform various tasks related to memory.
The StratoVirt IO subsystem also uses the VirtIO protocol. Those who have worked with virtualization software know that the VirtIO protocol is quite efficient. We have implemented the MMIO mainline, all of which connect through the VirtIO-MMIO mainline, such as VirtIO-rng and VirtIO-net. Now let’s explain the processing flow. First, the application of the virtual machine will call the system call interface, which will invoke the kernel within the GuestOS. Through the system call, it writes this IO. When the IO is written to the virtual machine device, StratoVirt has a resident process that monitors memory. Since all memory in the virtual machine is requested by StratoVirt for use, it will monitor the memory. If it finds IO dispatched to this memory, it will extract the IO from the memory, and then through the system call IO Submit, it will dispatch the IO to the specific location of the device. When the device writes the IO to the specified location, it will send an interrupt, notifying the kernel, which will then find the specific virtual machine and notify it through a virtual interrupt that the IO has been completed, after which the virtual machine will handle this interrupt and pass it to the user space of the virtual machine. This is the entire process of StratoVirt handling IO. Let’s introduce two features of StratoVirt:
Fast cold startup: The startup process for traditional virtual machines and physical machines includes four steps: the BIOS phase, which completes various hardware information detection and initialization of various tables; the GRUB phase, which presents a bootable kernel to the user, implementing a user-defined boot process; the Setup phase, which enters BIOS, obtains the e820 table, copies it to Boot Param, and finally enters protected mode; and finally, the kernel startup phase, which boots the kernel, mounts channels, and loads drivers. The first three phases take at least 100 milliseconds, which is relatively high for lightweight scenarios. Therefore, we have optimized the startup process by specifying hardware-related parts of StratoVirt. The BIOS and GRUB phases are directly skipped, and the initialization of the protected mode in the Setup phase is implemented within the boot loader, ultimately achieving a fast cold startup of less than 50 milliseconds.
Rapid CPU scaling: During testing, we found that if we hot-plug CPUs like traditional virtual machines, the latency is relatively high, possibly in the hundreds of milliseconds or seconds. Therefore, when implementing rapid CPU scaling, we took a clever approach. As everyone knows, if CPUs are present but not online, the operating system cannot see them. If we perform the action of bringing the CPU online, it can be done very quickly. When we start the virtual machine, we set two parameters: one is MaxCPU, which indicates how many CPUs the virtual machine fully supports. The other is how many CPUs are needed, which specifies how many CPUs are configured for the virtual machine. When starting the virtual machine, we insert all the required CPUs, but at startup, we only bring online the CPUs that are needed, while the others are kept offline. When the business within the virtual machine changes and requires an increase in computing resources, we can notify StratoVirt through a command. This command can be sent to the internal virtual machine, bringing the virtual machine CPU online and achieving rapid CPU scaling capability. The above describes how StratoVirt operates, and now let’s discuss the roadmap for StratoVirt.
StratoVirt has been open-sourced as of September 30 this year through the openEuler 20.09 version, which is hosted on the Gitee platform. Currently, this version supports lightweight virtualization. In March next year, the 21.03 version will enhance lightweight solutions, optimize IO performance, and support rapid memory scaling. By September 30 next year, we will support standard virtualization solutions, including features under virtualization scenarios, such as virtual machine migration, rapid hot startup, snapshots, etc. Therefore, by September next year, we will achieve virtualization software with the same functionality.
A brief advertisement: Our code is available on the homepage of the openEuler community website, where you can click to directly enter the StratoVirt repository, which includes detailed introductions on how to compile, how to use it, and some introductions to StratoVirt.
This is the QR code for the openEuler WeChat group. If you are interested, please scan to join, and we can communicate at any time.
For video live playback, please click “Read the original text”

China Electronics Standardization Institute (referred to as “Electronics Standards Institute” or “Electronics Fourth Institute”), established in 1963, is a public welfare and comprehensive research institution directly under the Ministry of Industry and Information Technology, engaged in standardization in the field of electronic information technology. The Electronics Standards Institute focuses on electronic information technology standardization work, providing professional support for government policy research, industry management, and strategic decision-making through standard research, testing, measurement, certification, and information services, and providing standardized technical services to society. The Electronics Standards Institute undertakes the domestic technical coordination of 55 IEC, ISO/IEC JTC1 TC/SC and the secretariat work of 17 national standardization technical committees, establishing cooperative relationships with multiple international standardization organizations and well-known foreign institutions, playing an important role in the promotion of standards application, industrial advancement, and international exchange and cooperation.

The National Cloud Computing Standard Working Group was established in September 2012, with its secretariat based at the China Electronics Standardization Institute. The working group aims to coordinate and mobilize resources from the government, enterprises, universities, research institutions, users, and intermediary organizations in the industry, academia, and research to promote standardization in the field of cloud computing in China, responsible for the formulation and revision of national standards and industry standards in the cloud computing field, covering basic, technical, product, evaluation, service, and system standards, corresponding to the international standardization work of ISO/IEC JTC1/SC38 on cloud computing and distributed platforms. So far, it has organized the domestic industry, academia, research, and application sectors to formulate and release 27 national cloud computing standards, 1 industry standard, and 6 group standards.
The China Open Source Cloud Alliance (COSCL) was established in August 2012, under the guidance of the Information Technology Development Department of the Ministry of Industry and Information Technology, based at the China Electronics Standardization Institute, currently with over 200 member units from the open source ecosystem in China, including industry, academia, research, and application. As the designated open source organization for the national key R&D program “Cloud Computing and Big Data Open Source Community Ecosystem” project, COSCL aims to gather industrial capabilities with standardization at its core, leveraging its role as an open-source think tank.

The “Mulan Open Source Community” was established in August 2019 as one of the results of the national key R&D program’s key special project “Cloud Computing and Big Data Open Source Community Ecosystem”. It aims to promote communication in the open-source field among industry, academia, research, and application, drive the open-source transformation of national scientific and technological innovation results, strengthen communication between enterprises, scientific research units, and industry users, promote the implementation of open-source results, and provide neutral hosting for various open-source projects, ensuring the continuous development of open-source projects without being affected by third-party influences, thus creating and improving the open-source community ecosystem in a more open manner.
Related Readings
Jiang Dayong – Innovation Value of Full Industry Chain Shared Operating Systems
Wang Yongxia – Standardization Practices of Internet Enterprises in Cloud Computing
Liu Junwei – New Thoughts on Cloud Computing Development
Zhu Guoyun – Exploration and Practice of In-Memory Databases in the Cloud Era
Cong Peiyong – Building a Cloud Foundation for New Digital Infrastructure

