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

需积分: 50 160 浏览量更新于2024-07-15 收藏 913KB PDF 举报

"libvirt应用开发指南 Python版" 《Libvirt Application Development Guide Using Python》是针对使用Python进行libvirt应用开发的一本详细指南。该书由多位作者共同编写，包括W. David Ashley、Daniel Berrange、Chris Lalancette等，旨在帮助开发者了解并熟练运用libvirt库与Python进行虚拟化应用的开发。书中涵盖了libvirt API的基本概念、使用方法以及最佳实践，适用于初学者和有经验的开发者。 libvirt是一个开源项目，提供了一个API、库和工具，用于管理和控制虚拟化平台，如KVM、Xen、QEMU等。通过libvirt，开发者可以编写跨平台的应用程序，这些程序能够透明地操作多种虚拟化技术。Python作为流行的编程语言，有着丰富的库支持，使得libvirt在Python中的应用变得容易且高效。在本书中，读者将学习到： 1. **Libvirt基础知识**：理解libvirt的核心概念，包括域（Domain）、网络、存储池和卷（Volume）等虚拟化组件的管理。 2. **Python绑定**：探索libvirt的Python绑定，如何导入和初始化库，以及如何创建安全的连接到libvirt服务器。 3. **虚拟机管理**：创建、启动、停止、迁移和销毁虚拟机，以及监控它们的状态和性能。 4. **网络配置**：学习如何配置虚拟网络，包括桥接、NAT和路由等网络模式。 5. **存储管理**：理解和操作虚拟机的存储，包括创建、删除和挂载存储池和卷。 6. **安全性和权限**：掌握libvirt的安全模型，包括ACL（访问控制列表）设置和身份验证。 7. **事件和回调**：利用libvirt的事件机制来实时响应虚拟化环境的变化。 8. **最佳实践**：获取编写高效、可维护的libvirt应用的技巧和建议。此外，书中还包含了文档约定和类型排版的规范，帮助读者更好地理解和遵循书中的示例代码。由于这本书是草案版本，可能包含未完成或更新的内容，但依然提供了丰富的资源和指导，对于任何希望在Python环境中构建libvirt应用的人来说，都是宝贵的参考资料。这本书是libvirt Python开发者的重要资源，它不仅介绍了libvirt API的使用，还提供了实际应用的上下文和案例，使读者能够深入理解libvirt的潜力，并利用其功能构建强大的虚拟化解决方案。无论你是对虚拟化感兴趣的学生，还是正在寻找提升虚拟化管理工具的工程师，这本书都将为你提供宝贵的知识和实践指导。

Chapter 2. Architecture Draft

defined format. Thus when a persistent guest is powered off, it is still possible to manage its inactive

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 an instance of the virNetwork class 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 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 an instance of the virStoragePool class 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.

Draft Storage volumes

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

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 an instance of the virStorageVol class, 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 an instance of the virNodeDev class, 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.

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 virConnect class, 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.

Chapter 2. Architecture Draft

Table 2.1. Transports

Transport Description

tls A TCP socket running the TLS protocol on the

wire. This is the default data transport if none is

explicitly requested, and uses a TCP connection

on port 16514. At minimum it is necessary to

configure the server with a x509 certificate

authority and issue it a server certificate. The

libvirtd server can, optionally, be configured

to require clients to present x509 certificates as a

means of authentication.

tcp A TCP socket without the TLS protocol on

the wire. This data transport should not be

used on untrusted networks, unless the SASL

authentication service has been enabled

and configured with a plug-in that provides

encryption. The TCP connection is made on port

16509.

unix A local only data transport, allowing users to

connect to a libvirtd daemon running as a

different user account. As it is only accessible

on the local machine, it is unencrypted. The

standard socket names are /var/run/

libvirt/libvirt-sock for full management

capabilities and /var/run/libvirt/

libvirt-sock-ro for a socket restricted to

read only operations.

ssh The RPC data is tunneled over an SSH

connection to the remote machine. It requires

Netcat (nc) is installed on the remote machine

and that libvirtd is running with the UNIX domain

socket enabled. It is recommended that SSH

be configured to not require password prompts

to the client application. For example, if using

SSH public key authentication it is recommended

an ssh-agent by run to cache key credentials.

GSSAPI is another useful authentication mode

for the SSH transport allowing use of a pre-

initialized Keberos credential cache.

ext Any external program that can make a

connection to the remote machine by means

that are outside the scope of libvirt. If none of

the built-in data transports are satisfactory, this

allows an application to provide a helper program

to proxy RPC data over a custom channel.

2.3.3. Authentication schemes

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

of authentication schemes on its data transports, with industry standard encryption and authentication

capabilities. The choice of authentication scheme is configured by the administrator in the /etc/

libvirt/libvirtd.conf file.

剩余137页未读，继续阅读

LavaFlow

粉丝: 0
资源: 4

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

libvirt-test-API

libvirt application开发指南C语言

Libvirt Application Development Guide Using Python

Python开发Libvirt应用指南（1.1版）

Version-1.1-Libvirt_Application_Development_Guide_Using_Python-en-US

libvirt_Application_Development_Guide

申威平台libvirt使用指南

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

libvirt 0.9 C语言应用开发指南

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

最新资源