From: Dave Allan
-This page describes the backends for the storage management capabilities in
-libvirt.
-Storage Management
+ A storage pool is a quantity of storage set aside by an + administrator, often a dedicated storage administrator, for use + by virtual machines. Storage pools are divided into storage + volumes either by the storage administrator or the system + administrator, and the volumes are assigned to VMs as block + devices. +
++ For example, the storage administrator responsible for an NFS + server creates a share to store virtual machines' data. The + system administrator defines a pool on the virtualization host + with the details of the share + (e.g. nfs.example.com:/path/to/share should be mounted on + /vm_data). When the pool is started, libvirt mounts the share + on the specified directory, just as if the system administrator + logged in and executed 'mount nfs.example.com:/path/to/share + /vmdata'. If the pool is configured to autostart, libvirt + ensures that the NFS share is mounted on the directory specified + when libvirt is started. +
++ Once the pool is started, the files in the NFS share are + reported as volumes, and the storage volumes' paths may be + queried using the libvirt APIs. The volumes' paths can then be + copied into the section of a VM's XML definition describing the + source storage for the VM's block devices. In the case of NFS, + an application using the libvirt APIs can create and delete + volumes in the pool (files in the NFS share) up to the limit of + the size of the pool (the storage capacity of the share). Not + all pool types support creating and deleting volumes. Stopping + the pool (somewhat unfortunately referred to by virsh and the + API as "pool-destroy") undoes the start operation, in this case, + unmounting the NFS share. The data on the share is not modified + by the destroy operation, despite the name. See man virsh for + more details. +
++ A second example is an iSCSI pool. A storage administrator + provisions an iSCSI target to present a set of LUNs to the host + running the VMs. When libvirt is configured to manage that + iSCSI target as a pool, libvirt will ensure that the host logs + into the iSCSI target and libvirt can then report the available + LUNs as storage volumes. The volumes' paths can be queried and + used in VM's XML definitions as in the NFS example. In this + case, the LUNs are defined on the iSCSI server, and libvirt + cannot create and delete volumes. +
++ Storage pools and volumes are not required for the proper + operation of VMs. Pools and volumes provide a way for libvirt + to ensure that a particular piece of storage will be available + for a VM, but some administrators will prefer to manage their + own storage and VMs will operate properly without any pools or + volumes defined. On systems that do not use pools, system + administrators must ensure the availability of the VMs' storage + using whatever tools they prefer, for example, adding the NFS + share to the host's fstab so that the share is mounted at boot + time. +
++ If at this point the value of pools and volumes over traditional + system administration tools is unclear, note that one of the + features of libvirt is its remote protocol, so it's possible to + manage all aspects of a virtual machine's lifecycle as well as + the configuration of the resources required by the VM. These + operations can be performed on a remote host entirely within the + libvirt API. In other words, a management application using + libvirt can enable a user to perform all the required tasks for + configuring the host for a VM: allocating resources, running the + VM, shutting it down and deallocating the resources, without + requiring shell access or any other control channel. +
++ Libvirt supports the following storage pool types: +