Draft Storage volumes
5
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.