libvirt 0.9 C语言应用开发指南

需积分: 14 125 浏览量更新于2024-07-15 1 收藏 629KB PDF 举报

"libvirt C语言应用开发指南，2020年9月版，增加了2020-04-07前的4个提交，旨在帮助开发者使用libvirt进行应用开发。" 在《libvirt0.9 Application Development Guide》这本书中，作者团队包括Daniel Berrange、Chris Lalancette、Laine Stump、Daniel Veillard以及多位贡献者，他们提供了关于利用libvirt进行应用开发的详尽指导。这本书适用于希望使用libvirt库构建虚拟化管理应用程序的开发人员。 libvirt是一个开源项目，提供了一组API、ABI和CLI工具，用于跨多种虚拟化平台（如KVM、Xen、VMware等）进行统一的管理和编程。C语言是libvirt的主要开发语言，因此该指南专注于C语言的开发实践。书中首先介绍了文档的约定，包括typographic conventions（排版规范）、pull-quote conventions（引述段落规范）以及notes和warnings（提示和警告）。这些约定帮助读者更好地理解和遵循文档结构。在介绍部分，作者概述了libvirt的基本功能和目标，并提供了一个术语表，以便读者对相关技术术语有清晰的理解。接着，书中详细阐述了libvirt的架构，包括其设计目标、主要组件和工作原理。这部分内容对于理解libvirt如何与各种虚拟化技术交互至关重要。在深入探讨libvirt API之前，通常会讨论如何安装libvirt库，配置开发环境，并展示如何创建基本的libvirt连接。书中可能会涵盖以下知识点： 1. 如何配置和编译libvirt库，以及如何在开发环境中设置相应的头文件和库路径。 2. libvirt API的使用，包括初始化连接、查询和管理虚拟机、网络、存储池等资源。 3. 安全性方面，如认证机制、权限控制和隔离策略。 4. 异常处理和错误报告，如何正确捕获和处理libvirt API调用可能返回的错误。 5. 示例代码和最佳实践，展示如何有效地使用libvirt进行实际开发。 6. libvirt的事件系统，如何监听和响应虚拟化环境的变化。 7. 性能监控和调试技巧，帮助开发者优化应用性能和解决潜在问题。此外，书中还可能涉及libvirt的高级特性，如热迁移、快照管理、虚拟硬件配置，以及如何与其他虚拟化管理工具（如QEMU、XenServer等）集成。《libvirt0.9 Application Development Guide》是libvirt C语言应用开发者的宝贵资源，它不仅提供了全面的技术指南，还包含了丰富的示例和实践经验，有助于开发者快速上手并高效地利用libvirt开发虚拟化管理软件。

Chapter 2. Architecture Draft

configuration. A transient guest can be turned into a persistent guest while it is running by defining a

configuration for it.

Refer to Chapter 4, Guest Domains for further information about using guest domain objects.

2.1.3. Virtual networks

A virtual network provides a method for connecting the network devices of one or more guest domains

within a single host. The virtual network can either:

• Remain isolated to the host; or

• Allow routing of traffic off-node via the active network interfaces of the host OS. This includes the

option to apply NAT to IPv4 traffic.

A virtual network is represented by the virNetworkPtr object and has two unique identifiers:

Unique identifiers

• name: short string, unique amongst all virtual network on a single host, both running and inactive.

For maximum portability between hypervisors, applications should only use the characters a-

Z,0-9,-,_ in names.

• UUID: 16 unsigned bytes, guaranteed to be unique amongst all virtual networks on any host. RFC

4122 defines the format for UUIDs and provides a recommended algorithm for generating UUIDs

with guaranteed uniqueness.

A virtual network may be transient or persistent. A transient virtual network can only be managed while

it it is running on the host. When taken offline, all traces of it will disappear. A persistent virtual network

has its configuration maintained in a data store on the host, in an implementation defined format. Thus

when a persistent network is brought offline, it is still possible to manage its inactive config. A transient

network can be turned into a persistent network on the fly by defining a configuration for it.

After installation of libvirt, every host will get a single virtual network instance called 'default', which

provides DHCP services to guests and allows NAT'd IP connectivity to the host's interfaces. This

service is of most use to hosts with intermittent network connectivity. For example, laptops using

wireless networking.

Refer to Chapter 6, Virtual Networks for further information about using virtual network objects.

2.1.4. Storage pools

The storage pool object provides a mechanism for managing all types of storage on a host, such as

local disk, logical volume group, iSCSI target, FibreChannel HBA and local/network file system. A pool

refers to a quantity storage that is able to be allocated to form individual volumes. A storage pool is

represented by the virStoragePoolPtr object and has a pair of unique identifiers.

Unique identifiers

• name: short string, unique amongst all storage pools on a single host, both running and inactive.

For maximum portability between hypervisors applications should only rely on being able to use the

characters a-Z,0-9,-,_ in names.

• UUID: 16 unsigned bytes, guaranteed to be unique amongst all storage pools on any host. RFC

4122 defines the format for UUIDs and provides a recommended algorithm for generating UUIDs

with guaranteed uniqueness.

A storage pool may be transient, or persistent. A transient storage pool can only be managed while

it is running on the host and, when powered off, all trace of it will disappear (the underlying physical

Draft Storage volumes

storage still exists of course !). A persistent storage pool has its configuration maintained in a data

store on the host by the hypervisor, in an implementation defined format. Thus when a persistent

storage pool is deactivated, it is still possible to manage its inactive config. A transient pool can be

turned into a persistent pool on the fly by defining a configuration for it.

Refer to Chapter 5, Storage Pools for further information about using storage pool objects.

2.1.5. Storage volumes

The storage volume object provides management of an allocated block of storage within a pool,

be it a disk partition, logical volume, SCSI/iSCSI LUN, or a file within a local/network file system.

Once allocated, a volume can be used to provide disks to one (or more) virtual domains. A volume is

represented by the virStorageVolPtr object, and has three identifiers

Unique identifiers

• name: short string, unique amongst all storage volumes within a storage pool. For maximum

portability between implementations applications should only rely on being able to use the

characters a-Z,0-9,-,_ in names. The name is not guaranteed to be stable across reboots, or

between hosts, even if the storage pool is shared between hosts.

• Key: a opaque string, of arbitrary printable characters, intended to uniquely identify the volume

within the pool. The key is intended to be stable across reboots, and between hosts.

• Path: a file system path referring to the volume. The path is unique amongst all storage volumes on

a single host. If the storage pool is configured with a suitable target path, the volume path may be

stable across reboots, and between hosts.

Refer to Section 5.7, “Volume overview” for further information about using storage volume objects

2.1.6. Host devices

Host devices provide a view to the hardware devices available on the host machine. This covers

both the physical USB or PCI devices and logical devices these provide, such as a NIC, disk, disk

controller, sound card, etc. Devices can be arranged to form a tree structure allowing relationships

to be identified. A host device is represented by the virNodeDevPtr object, and has one general

identifier, though specific device types may have their own unique identifiers.

Unique identifiers

• name: short string, unique amongst all devices on the host. The naming scheme is determined by

the host operating system. The name is not guaranteed to be stable across reboots.

Physical devices can be detached from the host OS drivers, which implicitly removes all associated

logical devices, and then assigned to a guest domain. Physical device information is also useful when

working with the storage and networking APIs to determine what resources are available to configure.

Refer to Chapter 8, Host Devices for further information about using host device objects.

2.2. Driver model

The libvirt library exposes a guaranteed stable API & ABI which is decoupled from any particular

virtualization technology. In addition many of the APIs have associated XML schemata which are

considered part of the stable ABI guarantee. Internally, there are multiple of implementations of the

public ABI, each targeting a different virtualization technology. Each implementation is referred to as

a driver. When obtaining a instance of the virConnectPtr object, the application developer can

provide a URI to determine which hypervisor driver is activated.

Chapter 2. Architecture Draft

No two virtualization technologies have exactly the same functionality. The libvirt goal is not to restrict

applications to a lowest common denominator, since this would result in an unacceptably limited API.

Instead libvirt attempts to define a representation of concepts and configuration that is hypervisor

agnostic, and adaptable to allow future extensions. Thus, if two hypervisors implement a comparable

feature, libvirt provides a uniform control mechanism or configuration format for that feature.

If a libvirt driver does not implement a particular API, then it will return a VIR_ERR_NO_SUPPORT

error code enabling this to be detected. There is also an API to allow applications to the query certain

capabilities of a hypervisor, such as the type of guest ABIs that are supported.

Internally a libvirt driver will attempt to utilize whatever management channels are available for the

virtualization technology in question. For some drivers this may require libvirt to run directly on the host

being managed, talking to a local hypervisor, while others may be able to communicate remotely over

an RPC service. For drivers which have no native remote communication capability, libvirt provides a

generic secure RPC service. This is discussed in detail later in this chapter.

Hypervisor drivers

• Xen: The open source Xen hypervisor providing paravirtualized and fully virtualized machines.

A single system driver runs in the Dom0 host talking directly to a combination of the hypervisor,

xenstored and xend. Example local URI scheme xen:///.

• QEMU: Any open source QEMU based virtualization technology, including KVM. A single privileged

system driver runs in the host managing QEMU processes. Each unprivileged user account also

has a private instance of the driver. Example privileged URI scheme qemu:///system. Example

unprivileged URI scheme qemu:///session

• UML: The User Mode Linux kernel, a pure paravirtualization technology. A single privileged system

driver runs in the host managing UML processes. Each unprivileged user account also has a private

instance of the driver. Example privileged URI scheme uml:///system. Example unprivileged URI

scheme uml:///session

• OpenVZ: The OpenVZ container based virtualization technology, using a modified Linux host

kernel. A single privileged system driver runs in the host talking to the OpenVZ tools. Example

privileged URI scheme openvz:///system

• LXC: The native Linux container based virtualization technology, available with Linux kernels since

2.6.25. A single privileged system driver runs in the host talking to the kernel. Example privileged

URI scheme lxc:///

• Remote: Generic secure RPC service talking to a libvirtd daemon. Encryption and

authentication using a choice of TLS, x509 certificates, SASL (GSSAPI/Kerberos) and SSH

tunneling. URIs follow the scheme of the desired driver, but with a hostname filled in, and a data

transport name appended to the URI scheme. Example URI to talk to Xen over a TLS channel xen

+tls://somehostname/. Example URI to talk to QEMU over a SASL channel qemu+tcp:///

somehost/system

• Test: A mock driver, providing a virtual in-memory hypervisor covering all the libvirt APIs. Facilities

testing of applications using libvirt, by allowing automated tests to run which exercise libvirt APIs

without needing to deal with a real hypervisor Example default URI scheme test:///default.

Example customized URI scheme test:///path/to/driver/config.xml

Draft Remote management

Figure 2.1. libvirt driver architecture

2.3. Remote management

While many virtualization technologies provide a remote management capability, libvirt does not

assume this and provides a dedicated driver allowing for remote management of any libvirt hypervisor

driver. The driver has a variety of data transports providing considerable security for the data

communication. The driver is designed such that there is 100% functional equivalence whether talking

to the libvirt driver locally, or via the RPC service.

In addition to the native RPC service included in libvirt, there are a number of alternatives for remote

management that will not be discussed in this document. The libvirt-qpid project provides an

agent for the QPid messaging service, exposing all libvirt managed objects and operations over the

message bus. This keeps a fairly close, near 1-to-1, mapping to the C API in libvirt. The libvirt-

CIM project provides a CIM agent, that maps the libvirt object model onto the DMTF virtualization

schema.

2.3.1. Basic usage

The server end of the RPC service is provided by the libvirtd daemon, which must be run on the

host to be managed. In an default deployment this daemon will only be listening for connection on a

local UNIX domain socket. This only allows for a libvirt client to use the SSH tunnel data transport.

With suitable configuration of x509 certificates, or SASL credentials, the libvirtd daemon can be

told to listen on a TCP socket for direct, non-tunneled client connections.

As can be seen from earlier example libvirt driver URIs, then hostname field in the URI is always

left empty for local libvirt connections. To make use of the libvirt RPC driver, only two changes are

required to the local URI. At least a hostname must be specified, at which point libvirt will attempt

to use the direct TLS data transport. An alternative data transport can be requested by appending

its name to the URI scheme. The URIs formats will be described in detail later in this document

Section 3.2.2, “Remote URIs”

2.3.2. Data Transports

To cope with the wide variety of deployment environments, the libvirt RPC service supports a number

of data transports, all of which can be configured with industry standard encryption and authentication

capabilities.

剩余93页未读，继续阅读

LavaFlow

粉丝: 0
资源: 4

libvirt 0.9 C语言应用开发指南

libvirt application开发指南 python

Libvirt Application Development Guide Using Python

使用Python进行libvirt应用开发实战指南

libvirt_Application_Development_Guide

申威平台libvirt使用指南

Version-1.1-Libvirt_Application_Development_Guide_Using_Python-en-US

Libvirt网络

libvirt源码

申威平台libvirt虚拟机配置指南

libvirt 0.7.5应用开发指南：Linux虚拟机管理权威教程

最新资源