Este contenido no está disponible en el idioma seleccionado.
Chapter 12. Storage Pools
This chapter includes instructions on creating storage pools of assorted types. 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 often divided into storage volumes either by the storage administrator or the system administrator, and the volumes are assigned to guest virtual machines as block devices.
Example 12.1. NFS storage pool
Suppose a storage administrator responsible for an NFS server creates a share to store guest virtual machines' data. The system administrator defines a pool on the host physical machine with the details of the share (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 starts, the files that the NFS share, are reported as volumes, and the storage volumes' paths are then queried using the libvirt APIs. The volumes' paths can then be copied into the section of a guest virtual machine's XML definition file describing the source storage for the guest virtual machine's block devices. With NFS, applications using the libvirt APIs can create and delete volumes in the pool (files within the NFS share) up to the limit of the size of the pool (the maximum storage capacity of the share). Not all pool types support creating and deleting volumes. Stopping the pool negates the start operation, in this case, unmounts the NFS share. The data on the share is not modified by the destroy operation, despite the name. See man virsh for more details.
Note
Storage pools and volumes are not required for the proper operation of guest virtual machines. Pools and volumes provide a way for libvirt to ensure that a particular piece of storage will be available for a guest virtual machine, but some administrators will prefer to manage their own storage and guest virtual machines will operate properly without any pools or volumes defined. On systems that do not use pools, system administrators must ensure the availability of the guest virtual machines' storage using whatever tools they prefer, for example, adding the NFS share to the host physical machine's fstab so that the share is mounted at boot time.
Warning
When creating storage pools on a guest, make sure to follow security considerations. This information is discussed in more detail in the Red Hat Enterprise Linux Virtualization Security Guide which can be found at https://access.redhat.com/site/documentation/.
12.1. Disk-based Storage Pools
This section covers creating disk based storage devices for guest virtual machines.
Warning
Guests should not be given write access to whole disks or block devices (for example,
/dev/sdb). Use partitions (for example, /dev/sdb1) or LVM volumes.
If you pass an entire block device to the guest, the guest will likely partition it or create its own LVM groups on it. This can cause the host physical machine to detect these partitions or LVM groups and cause errors.
12.1.1. Creating a Disk-based Storage Pool Using virsh
This procedure creates a new storage pool using a disk device with the
virsh command.
Warning
Dedicating a disk to a storage pool will reformat and erase all data presently stored on the disk device. It is strongly recommended to back up the storage device before commencing with the following procedure.
Create a GPT disk label on the disk
The disk must be relabeled with a GUID Partition Table (GPT) disk label. GPT disk labels allow for creating a large numbers of partitions, up to 128 partitions, on each device. GPT partition tables can store partition data for far more partitions than the MS-DOS partition table.# parted /dev/sdb GNU Parted 2.1 Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mklabel New disk label type? gpt (parted) quit Information: You may need to update /etc/fstab. #
Create the storage pool configuration file
Create a temporary XML text file containing the storage pool information required for the new device.The file must be in the format shown below, and contain the following fields:- <name>guest_images_disk</name>
- The
nameparameter determines the name of the storage pool. This example uses the name guest_images_disk in the example below. - <device path='/dev/sdb'/>
- The
deviceparameter with thepathattribute specifies the device path of the storage device. This example uses the device /dev/sdb. - <target> <path>/dev</path></target>
- The file system
targetparameter with thepathsub-parameter determines the location on the host physical machine file system to attach volumes created with this storage pool.For example, sdb1, sdb2, sdb3. Using /dev/, as in the example below, means volumes created from this storage pool can be accessed as /dev/sdb1, /dev/sdb2, /dev/sdb3. - <format type='gpt'/>
- The
formatparameter specifies the partition table type. This example uses the gpt in the example below, to match the GPT disk label type created in the previous step.
Create the XML file for the storage pool device with a text editor.Example 12.2. Disk based storage device storage pool
<pool type='disk'> <name>guest_images_disk</name> <source> <device path='/dev/sdb'/> <format type='gpt'/> </source> <target> <path>/dev</path> </target> </pool>Attach the device
Add the storage pool definition using thevirsh pool-definecommand with the XML configuration file created in the previous step.# virsh pool-define ~/guest_images_disk.xml Pool guest_images_disk defined from /root/guest_images_disk.xml # virsh pool-list --all Name State Autostart ----------------------------------------- default active yes guest_images_disk inactive no
Start the storage pool
Start the storage pool with thevirsh pool-startcommand. Verify the pool is started with thevirsh pool-list --allcommand.# virsh pool-start guest_images_disk Pool guest_images_disk started # virsh pool-list --all Name State Autostart ----------------------------------------- default active yes guest_images_disk active no
Turn on autostart
Turn onautostartfor the storage pool. Autostart configures thelibvirtdservice to start the storage pool when the service starts.# virsh pool-autostart guest_images_disk Pool guest_images_disk marked as autostarted # virsh pool-list --all Name State Autostart ----------------------------------------- default active yes guest_images_disk active yes
Verify the storage pool configuration
Verify the storage pool was created correctly, the sizes reported correctly, and the state reports asrunning.# virsh pool-info guest_images_disk Name: guest_images_disk UUID: 551a67c8-5f2a-012c-3844-df29b167431c State: running Capacity: 465.76 GB Allocation: 0.00 Available: 465.76 GB # ls -la /dev/sdb brw-rw----. 1 root disk 8, 16 May 30 14:08 /dev/sdb # virsh vol-list guest_images_disk Name Path -----------------------------------------
Optional: Remove the temporary configuration file
Remove the temporary storage pool XML configuration file if it is not needed.# rm ~/guest_images_disk.xml
A disk based storage pool is now available.
12.1.2. Deleting a Storage Pool Using virsh
The following demonstrates how to delete a storage pool using virsh:
- To avoid any issues with other guest virtual machines using the same pool, it is best to stop the storage pool and release any resources in use by it.
# virsh pool-destroy guest_images_disk
- Remove the storage pool's definition
# virsh pool-undefine guest_images_disk
