Shulou(Shulou.com)05/31 Report--

This article shows you how to analyze the Libvirt virtual library, which is concise and easy to understand, which will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

When it comes to scaling out computing, such as cloud computing, libvirt is probably one of the most important libraries you've never heard of. Libvirt provides a hypervisor-agnostic API to securely manage guest operating systems running on hosts. Libvirt itself is not a tool, it is an API that can build tools to manage guest operating systems. Libvirt itself is built on an abstract concept. It provides a common API for common functions implemented by supported hypervisors. Libvirt was originally a management API designed specifically for Xen and was later extended to support multiple hypervisors.

Basic architecture

Join the green group on My developerWorks

Discuss topics and share resources on energy, efficiency and the environment on the GReen IT Report Space and Green Computing Group on My developerWorks.

Let's first discuss libvirt from the perspective of a use case model, and then delve deeper into its architecture and purpose. Libvirt exists as a set of API and is intended for use by management applications (see figure 1). Libvirt communicates with each valid hypervisor through a hypervisor-specific mechanism to complete the API request. Later in the article, I will explore how to implement this function through QEMU.

Figure 1. Libvirt comparison and use case model

The figure also shows a comparison of the terms used by libvirt. These terms are important because they are used when naming API. The two fundamental differences are that libvirt refers to physical hosts as nodes and future guest operating systems as domains. It is important to note here that libvirt (and its applications) runs in the host Linux operating system (domain 0).

Control mode

With libvirt, we have two different modes of control. The first is shown in figure 1, where the management application and the domain are on the same node. In this example, the management application works through libvirt to control the local domain. Another form of control arises when the management application and the domain are on different nodes. In this example, remote communication is required (see figure 2). This mode uses a special daemon called libvirtd that runs on remote nodes. The program starts automatically when libvirt is installed on a new node, and the local hypervisor is automatically identified and drivers installed for it (discussed later). The management application connects from the local libvirt to the remote libvirtd through a common protocol. For QEMU, the protocol ends at the QEMU monitor. QEMU includes a monitoring console that allows you to check the running guest operating system and control parts of the virtual machine (VM).

Figure 2. Use libvirtd to control the remote hypervisor

Hypervisor support

To support the scalability of various hypervisors, libvirt implements a driver-based architecture that allows a general API to provide services to a large number of potential hypervisors in a generic manner. This means that some professional features of some hypervisors are not visible in API. In addition, some hypervisors may not be able to implement all API functions and are therefore defined as unsupported within a particular driver. Figure 3 shows the hierarchy of libvirt API and related drivers. It is also important to note that libvirtd provides a way to access the local domain from a remote application.

Figure 3. Driver-based libvirt architecture

At the time of this writing, libvirt implements drivers for the hypervisors listed in Table 1. As new hypervisors emerge in the open source community, other drivers will no doubt be available.

Table 1. Hypervisors supported by libvirt

Hypervisor describes Xen for IA-32 IA-64 and PowerPC 970Architecture Hypervisor QEMU platform Emulator Kernel-based Virtual Machine (KVM) Linux platform Emulator Linux Containers (LXC) Linux (lightweight) Container for operating system Virtualization OpenVZ operating system level Virtualization based on Linux Kernel VirtualBoxx86 Virtualization Hypervisor User Mode Linux for various architectures Linux platform Emulator Test for pseudo Hypervisor Test drive Storage storage pool drive (local disk Network disk, iSCSI volume) libvirt and virtual shell

Now that I've introduced some of the architecture of libvirt, let's take a look at some examples of how to virtualize API using libvirt. First, we introduce an application called virsh (Virtual shell), which is built on top of libvirt. The shell allows multiple libvirt functions to be used interactively (based on shell). In this section, I demonstrated some VM operations using virsh.

The first step is to define the domain profile (as shown in listing 1 below). This code specifies all the options required to define the domain-from the hypervisor (emulator) to the resources used by the domain and peripheral configurations (such as networks). Note that this is a simple configuration, and the attributes that libvirt really supports are more diverse. For example, you can specify the BIOS and host bootstrap, the resources to be used by the domain, and the devices to be used-from floppy disks and CD-ROM to USB and PCI devices.

The domain profile defines some basic metadata to be used by the QEMU domain, including the domain name, maximum memory, initial available memory (current), and the number of virtual processors available for the domain. You don't need to assign Universally Unique Idenifier (UUID) yourself, but let libvirt assign it. You need to define the type of machine to emulate for the platform-in this case, a 686 processor that is fully virtualized (hvm). You need to define the location of the emulator for the domain (in case you need to support multiple emulators of the same type) and the virtual disk. Note here to specify VM, which is the ReactOS operating system that exists in Virtual Machine Disk (VMDK) format. Finally, specify the default network settings and use the graphics-oriented Virtual Network Computing (VNC).

Listing 1. Domain profile

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

fourteen

fifteen

sixteen

seventeen

eighteen

nineteen

twenty

twenty-one

twenty-two

ReactOS-on-QEMU

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.