A detailed explanation of Xen virtualization Fundamentals

I. Overview of Xen

Xen is an open source project developed by the Cambridge University Computer Laboratory. is a software layer that runs directly on the computer hardware to replace the operating system, which can run multiple guest operating systems (guest OS) concurrently on the computer hardware. has been greatly promoted in the open source community.

Xen supports x86, X86-64, Itanium (Itanium), Power pc, and ARM processors, so Xen can run on a large number of compute devices, and Xen currently supports Linux, NetBSD, FreeBSD, Solaris, Windows and other commonly used operating systems run on their hypervisor as guest operating systems.

Ii. Xen Virtualization Type

Xen's virtualization of virtual machines is divided into two major categories, semi-virtualized (paravirtualization) and full virtualization (Hardware virtualmachine).

1, semi-virtualized

Semi-virtualized (paravirtualization) Some of the information called "Hyper-virtualization", or PV, is a Xen-led virtualization technology. This technology allows the virtual machine operating system to perceive that it is running on the Xen hypervisor instead of running directly on the hardware, while also identifying other guest VMs running in the same environment.

A semi-virtualized operating system running on Xen Hypervisor, in order to invoke the hypervisor (Xen Hypervisor), to selectively modify the operating system, but does not need to modify applications running on the operating system. Because Xen needs to modify the operating system kernel, you cannot have the current Linux kernel run directly in the Xen hypervisor unless it has been ported to the Xen architecture. However, if the current system can use the new Linux kernel that has been ported to the Xen architecture, you can run the existing system without modification.

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M02/78/3E/wKiom1Z4wHeRyg0YAADxLwu77E4551.jpg "title=" Qq20151222111536.jpg "alt=" Wkiom1z4wheryg0yaadxlwu77e4551.jpg "/>

2. Full Virtualization

Full Virtualization (Hardware virtual machine), also known as "hardware Virtualization", referred to as HVM, refers to the virtual machines running in the virtual environment always feel that they are directly running on the hardware, and do not perceive the same hardware environment running other virtual machine virtual technology.

A fully virtualized virtual machine running in Xen hypervisor is running an operating system that is a standard operating system, that is, without any modifications to the operating system version. Special hardware equipment is also required.

Note that virtual Windows virtual machines on Xen must take full virtualization technology.

Third, Xen basic components

• Xen Hypervisor: running directly on the hardware is the interface between the Xen guest operating system and the hardware resource (for example:). By classifying the guest operating system and hardware, the Xen management system allows the client operating system to be secure and run independently on the same hardware environment.

• Domain 0: A guest operating system that runs on top of the Xen hypervisor and has privileges to directly access hardware and manage other guest operating systems.

• Domainu: a normal guest operating system or business operating system running on top of the Xen hypervisor, with no direct access to hardware resources such as memory, hard disks, etc., but can exist in multiple independent parallel.

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M01/78/3D/wKioL1Z4wP6zG5XZAABoXq8aIq0613.png "title=" 173512 _x9ce_812550.png "alt=" Wkiol1z4wp6zg5xzaaboxq8aiq0613.png "/>

1. Xen Hypervisor

Xen hypervisor is the basic software layer that runs directly between hardware and all operating systems. It is responsible for CPU scheduling and memory allocation for different kinds of virtual machines (different operating systems) running on hardware devices. Xen hypervisor is not just a hardware abstraction interface for virtual machines, but also controls the execution of virtual machines, allowing them to share a common processing environment.

Xen Hypervisor is not responsible for processing such as networks, external storage devices, video, or other general-purpose I/O processing.

2. Domain 0

Domain 0 is a modified Linux kernel, a unique virtual machine running on top of Xen hypervisor, with the privilege of accessing physical I/O resources and interacting with other virtual machines running on top of Xen hypervisor. All Xen virtual environments need to run domain 0 before they can run other virtual clients.

Domain 0 is the role of administrator in Xen, which manages other virtual clients.

There are two drivers in domain 0 that support requests for access to networks and hard disks by other guest VMs. These two drivers are the network backend Driver and the block backend Driver respectively.

Network backend driver communicates directly with the local networking hardware to handle all virtual machine requests from the domain U client for the network. Based on the request from Domain U, block backend driver communicates directly with the local storage device and then reads and writes the data to the storage device.

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/78/3D/wKioL1Z4wT6iTgTuAAAmA44a1gc429.png "title=" 174255 _orwa_812550.png "alt=" Wkiol1z4wt6itgtuaaama44a1gc429.png "/>

3. Domain U

Domain u customer virtual machine does not have direct access to physical hardware. All semi-virtualized guest virtual machines running on Xen hypervisor (referred to as Domain U PV Guests) are modified Linux-based operating systems, Solaris, FreeBSD, and other Unix-based operating systems. All fully virtualized guest virtual machines (referred to as Domain U HVM Guests) are standard Windows and any other unmodified operating system.

Whether you are semi-virtualized domain u or fully virtualized domain U, as a customer virtual machine system, domain u runs parallel on the Xen hypervisor, and they are independent of each other, each Domain u has its own virtual resources that can operate (such as: memory, disks, etc.). and allows a single domain u to restart and shut down operations without affecting other domain U.

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M02/78/3E/wKiom1Z4wU2xJVPyAAF8T1xvdn4339.png "title=" 174329 _xgje_812550.png "alt=" Wkiom1z4wu2xjvpyaaf8t1xvdn4339.png "/>

Iv. basic architecture and operating principles of Xen

1. Xen Architecture

The Xen VMM (Xen hyperviso) is located between the operating system and the hardware and is responsible for providing virtualized hardware resources to the operating system cores running in the upper layer, managing and allocating these resources, and ensuring isolation between the upper-level virtual machines (called domain domains). Xen uses mixed mode, thus setting up a privileged domain to assist Xen in managing other domains and providing virtual resource services, which are called Domain 0, while the remaining domains are called domain U.

Xen provides an abstraction layer to domain that contains APIs for management and virtual hardware. Domain 0 contains real device drivers (native device drivers), direct access to physical hardware, interacts with the management API provided by Xen, and manages the Xen virtual machine environment through management tools in user mode.

After Xen2.0, the separation device drive mode is introduced. This mode establishes a front-end (front end) device in each user domain, and a backend (back end) device is established in the privileged domain (DOM0). All user domain operating systems send requests to the front-end device like normal devices, while the front-end device sends these requests and the identity information of the user domain to the back-end devices in the privileged domain through the IO request descriptor (IO Descripror ring) and device channel. This system handles the control of information transfer and data transfer separately.

In the Xen architecture design, the backend-set-run privileged domain is given a unique name---the isolation device domain (isolation, IDD), and in the actual design, IDD is in DOM0. All real hardware access is initiated by the back-end device of the privileged domain calling the local device driver (native device drive). The design of the front-end device is very simple, only need to complete the data forwarding operation, because they are not real device drivers, so there is no request scheduling operation. Back-end devices running in IDD can take advantage of the existing device drivers of Linux to complete hardware access, requiring only the bridging function of the IO request---to complete the distribution and loopback of tasks.

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/78/3E/wKiom1Z4wYPxU1DHAACPO3xExWY839.jpg "title=" 174720 _arag_812550.jpg "alt=" Wkiom1z4wypxu1dhaacpo3xexwy839.jpg "/>

2. Operating mechanism of different virtual technology

Semi-virtualized technologies:

Virtual machine operating systems with semi-virtualized technology recognize that they run on Xen hypervisor rather than directly on the hardware, and can also identify other virtual machine systems that run on the same machine. and the operating system needs to be modified accordingly.

The semi-virtualized client (Domain U PV Guests) contains two drivers for operating networks and disks, the PV network Driver and the PV Block Driver.

The PV Network driver is responsible for providing Web access to domain U. The PV Block driver is responsible for providing disk operation functionality to domain U.

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/78/3D/wKioL1Z4wc2S6QZ-AAAliJ3RmVs057.png "title=" Semi-virtualized client "alt=" Wkiol1z4wc2s6qz-aaalij3rmvs057.png "/>

Full Virtualization Technology:

A fully virtualized client (Domain U HVM Guests) runs a standard version of the operating system, so there is no semi-virtualized driver (PV Driver) in its operating system, but there is a special daemon in Domain 0 for each fully virtualized client. Called: QEMU-DM,QEMU-DM helps full virtualized clients (Domain U HVM Guest) gain access to networks and disks.

A fully virtualized client must be initialized in the same way as in a normal hardware environment, so a special software Xen virtual firmware needs to be added to simulate the BIOS required for operating system startup.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M00/78/3E/wKiom1Z4wefAyuEWAAAuL82zxWo823.png "title=" Fully virtualized client "alt=" Wkiom1z4wefayuewaaaul82zxwo823.png "/>

3. Domain Management and control

The open source community classifies a series of Linux elf programs into two categories: management and control. These services support the management and control operations of the entire virtual environment and exist in domain 0 virtual machines.

The direct service is described in detail below.

Note: In order to clearly describe the running process of Xen, the sprite program is described outside of domain 0 when drawing, but in fact all the daemon programs are in domain 0.

3.1, Xend

The Xend Wizard thread is a Python application that acts as a system administrator for the Xen environment. It uses the Libxenctrl class library to make requests to Xen hypervisor.

All requests processed by the xend are sent over by the XM tool using the XML RPC interface.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/78/3E/wKiom1Z4wjHzzfRHAABSRVC52Uw181.png "title=" 180202 _ttfe_812550.png "alt=" Wkiom1z4wjhzzfrhaabsrvc52uw181.png "/>

3.2. Xm

A command-line tool that is used to pass user input through the XML RPC interface to Xend.

3.3, xenstored

The xenstored daemon is used to maintain registration information, including memory and event channels that are connected between domain 0 and all other domain U. Domain 0 Virtual machines Use these registration information to establish a device channel with other virtual machines in the system, that is, to help domain u virtual machines access hardware resources.

3.4, Libxenctrl

Libxenctrl is a C program class library that lets Xend have the ability to interact with Xen hypervisor through domain 0. A special driver, called Privcmd, exists in domain 0, which sends the request to hypervisor.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/78/3D/wKioL1Z4wnuzrejgAABLmVHhTDU722.png "title=" 180240 _twf5_812550.png "alt=" Wkiol1z4wnuzrejgaablmvhhtdu722.png "/>

3.5, QEMU-DM

In a Xen environment, each fully virtualized virtual machine needs to have its own qemu daemon. QEMU-DM handles all of the network and disk requests and operations that a fully virtualized client can allow to perform in a Xen environment. The QEMU program must exist outside of hypervisor and require access to the network and I/O, so the QEMU-DM must exist in domain 0 (see the description of domain 0 in the previous section).

In future versions of Xen, a new tool, STUB-DM, will provide a range of services that are available to all fully virtualized clients to replace the logic needed to generate a qemu on each virtual machine.

3.6. Xen Virtual Firmware

Xen Virtual firmware is a virtualized BIOS system that is embedded in all fully virtualized clients to ensure that all guest operating systems receive a standard set of boot instructions and provide a standard software-compatible environment during normal startup operations.

4. domain 0 and domain u communication in a semi-virtualized environment

As described in the previous chapters, Xen hypervisor is not responsible for processing network and disk requests, so the semi-virtualized client (domain U PV) must communicate with Xen hypervisor through domain 0 to complete network and disk operation requests. The following is an example of how domain 0 interacts with domain u PV, using a semi-virtualized client (Domain u PV) to write data to a local disk.

PV Block driver for a semi-virtualized client (Domain U PV) receives a request to write data to a local disk, and then writes data from local memory shared with Domain 0 to the local disk via Xen hypervisor. There is an event channel between domain 0 and para-virtualized domain u, which allows them to communicate through asynchronous interrupts that exist within the Xen hypervisor. Domain 0 will receive a system interrupt from the Xen hypervisor and trigger the block backend driver in domain 0 to access the Local system content and read the appropriate block of data from the shared memory with the semi-virtualized client. Data read from shared memory is then written to the local disk in the specified location.

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/78/3D/wKioL1Z4wsKh1bwxAABA-0P34sE313.png "title=" 180327 _aabb_812550.png "alt=" Wkiol1z4wskh1bwxaaba-0p34se313.png "/>

The event channels shown in are directly connected to domain 0 and domain U PV for a clear and simple description of how the system works. In fact, the event channel runs in Xen hypervisor and registers a specific system outage in xenstored to allow domain 0 and domain U PV to share information quickly through local memory.

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/78/3E/wKiom1Z4ws2gm2qPAADIPI_kfCE037.png "title=" 180350 _fa5p_812550.png "alt=" Wkiom1z4ws2gm2qpaadipi_kfce037.png "/>

V. Xen's network Architecture

1, Xen support three kinds of network operation mode

Bridge mode

Xend start-up process:

1) Create a virtual bridge xenbr0.

2) Stop the physical NIC Eth0.

3) The MAC address and IP address of the physical NIC Eth0 are copied to the virtual NIC Veth0.

4) Physical NIC Eth0 renamed to Peth0.

5) Veth0 renamed to Eth0.

6) Peth0 MAC address Change (FE:FF:FF:FF:FF:FF), ARP function is turned off.

7) Connect Peth0, vif0.0 to bridge XENBR0

8) Start Peth0, vif0.0, xenbr0

Process when Domain U starts:

1) vif<domainid>.0 connected to Xenbr0

2) Start vif<domainid>.0

Route mode

Xend the process at startup:

1) Turn on domain 0 IP Forward.

Process when Domain U starts:

1) Create vif<domainid>.0, the IP address of Dom U eth0 is copied to vif<domainid>.

2) Start vif<domainid>.0.

3) Add static routes to the Domu configuration file that point to the virtual interface vif.0 assigned IP address.

Nat Mode

NAT mode uses the virtual LAN Virbr0

2. Xen Domain U Guests send packet processing flow

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/78/3E/wKiom1Z4w_Wxj5afAADIPI_kfCE950.png "title=" 180350 _fa5p_812550.png "alt=" Wkiom1z4w_wxj5afaadipi_kfce950.png "/>

3. The relationship between the virtual network card and the physical network card in Xen

With a Xen-installed Linux machine, you can see the following types of NIC (Network interface Devices) in DOM 0:

(X, y are numbers)

Pethy

Ethy

Xenbry

Virbry

VIFX.Y (x is domaiid,y indicates that the virtual network card is the domain's first virtual network card)

Vethy (usually does not exist after the xend boot is complete)

This article is from the "Little Water Drop" blog, please make sure to keep this source http://wangzan18.blog.51cto.com/8021085/1727106

A detailed explanation of Xen virtualization Fundamentals