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

5星 · 超过95%的资源需积分: 12 193 浏览量更新于2024-07-19 收藏 818KB PDF 举报

《Libvirt应用开发指南：使用Python》本指南是一份详尽的文档，专为那些希望利用Python与Libvirt交互并进行应用开发的人设计。Libvirt是一个开源的虚拟机管理工具库，它提供了对各种虚拟化技术（如KVM、QEMU等）的统一访问接口。版本1.1的Libvirt Application Development Guide Using Python（Python版Libvirt应用开发手册）由多个贡献者共同编写，包括W. David Ashley、Daniel Berrange、Chris Lalancette、Laine Stump、Daniel Veillard、Dani Coulson、David Jorm和Scott Radvan。这份文档涵盖了如何通过Python语言有效地与libvirt进行通信，包括但不限于创建、管理和配置虚拟机实例，监控资源使用情况，以及执行常见的虚拟化操作。它不仅介绍了libvirt的基本概念和API，还提供了实用的示例代码和详细步骤，帮助开发者理解如何在实际项目中集成libvirt的功能。该版指南旨在作为开发人员的参考手册，它强调了Python接口的易用性和灵活性，使得开发者能够更轻松地利用libvirt的强大功能来构建和管理云端环境。版权方面，文本和插图遵循Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA) 许可协议，这意味着用户可以根据协议条款自由地分享、修改和重新发布文档内容，但必须保持原有作者的署名和同样宽松的授权条件。阅读此指南，读者将学到如何： 1. 安装和配置libvirt Python绑定 2. 创建、启动和停止虚拟机实例 3. 管理网络、存储和资源分配 4. 实现自动化脚本和工具，提高运维效率 5. 部署和迁移虚拟机 6. 监控虚拟机性能和事件 7. 应用安全性和权限管理无论你是经验丰富的开发者还是刚入门的新手，这份文档都是深入理解和使用libvirt与Python进行集成开发的重要资源。通过跟随指南中的指导，你将能够构建出高效、灵活且兼容广泛的虚拟化解决方案。

Chapter 2. Architecture Draft

A guest domain may be transient or persistent. A transient guest domain can only be managed while

it is running on the host. Once it is powered off, all trace of it will disappear. A persistent guest domain

has its configuration maintained in a data store on the host by the hypervisor, in an implementation

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.

Draft Storage volumes

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

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.

Chapter 2. Architecture Draft

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.

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:///

Draft Remote management

• 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

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

Chapter 2. Architecture Draft

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.

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.

剩余129页未读，继续阅读

「已注销」

粉丝: 0
资源: 3

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

libvirt application开发指南 python

libvirt_Application_Development_Guide

Version-1.1-Libvirt_Application_Development_Guide_Using_Python-en-US

libvirt-python官方文档

Windows python安装libvirt

centos8安装libvirt-python

E: 无法定位软件包 libvirt-python

no module named libvirt

python esxi-libvirt

python36-libvirt rpm下载

最新资源