Logical Volume Archive - PowerCampus 01

October 31, 2021October 31, 2021

Administering Storage Pools in PowerVM

In many cases, the use of SAN LUNs via NPIV is not suitable for the rapid provisioning of client LPARs. The SAN LUNs must first be created on the external storage systems and then the zoning in the SAN fabric must be adjusted, so that the new SAN LUNs are visible to the WWPNs of the client LPAR. Using VSCSI to map the SAN LUNs to the client LPARs also requires some effort. Each SAN LUN is assigned to one or more client LPARs via VSCSI, which can lead to a large number of SAN LUNs on the virtual I/O servers.

One way to provide storage for client LPARs more quickly, is to use storage pools on the virtual I/O servers. Once a storage pool has been created, storage can be made available for client LPARs with just one command. So-called backing devices are generated in the storage pool, which can be assigned to the client LPARs via virtual SCSI. Storage for client LPAR can thus be made available by the virtual I/O servers via PowerVM. This means that, for example, a boot disk, for a new client LPAR, can be created within a few seconds and can be used immediately.

PowerVM offers two different types of storage pools: local storage pools and shared storage pools. A local storage pool, or simply storage pool, is only available on one virtual I/O server. Each virtual I/O server has its own independent storage pools. A shared storage pool, on the other hand, can be made available by several virtual I/O servers that are combined in a cluster. Access to the shared storage pool is possible from each virtual I/O server that belong to the cluster. Shared storage pools are not dealt with in this chapter.

There are two types of local storage pools: logical volume storage pools and file storage pools. With a logical volume storage pool, storage is made available for the client LPARs in the form of logical volumes, with a file storage pool in the form of files.

Figure 8.13 shows a logical volume storage pool. The storage pool is implemented in the form of a volume group and therefore draws its storage capacity from the associated physical volumes. In order to provide storage for client LPARs, logical volumes are created in the storage pool. In the figure, the logical volumes bd01, bd02 and bd03 have been created. The logical volumes are referred to as backing devices, because they ultimately serve as the storage location for the data of the client LPARs. The assignment of a backing device to a client LPAR, more precisely a vhost adapter, which is assigned one-to-one to a virtual SCSI adapter of a client LPAR, takes place using a so-called virtual target device (vtscsi0, vtscsi1 and vtscsi2 in the figure). The virtual target device is a child device of one of the vhost adapters and points to the corresponding backing device via the device attribute aix_tdev. When mapping, the virtual target device is created as a child of a vhost adapter.

As long as the storage pool still has free capacity, additional backing devices can be created and assigned to client LPARs at any time. The provisioning of storage for client LPAR is therefore very flexible and, above all, very fast and is completely under the control of the PowerVM administrator.

In addition to logical volume storage pools, file storage pools are also supported. Such a file storage pool is shown in figure 8.14; it is implemented as a file system. The underlying logical volume is in the logical volume storage pool mypool. The storage pool name is used as the name for the logical volume, in the figure then name filepool is used. The file system is mounted under /var/vio/storagepools/filepool, whereby the last path component is the same as the storage pool name. Files are used as backing devices, the file name being the same as the backing device name. The mapping is still implemented using virtual target devices, in the figure vtscsi3 and vtscsi4 are shown as examples. The attribute aix_tdev of the virtual target devices points in this case to the respective file in the file storage pool.

8.6. Storage Pools

8.6.1. Creation of a Logical Volume Storage Pool

8.6.2. Creation of Backing Devices

8.6.3. Extending a Backing Device

8.6.4. Removing a Backing Device

8.6.5. Extending and Reducing a Logical Volume Storage Pool

8.6.6. Deleting a Logical Volume Storage Pool

8.6.7. Creating a File Storage Pool

8.6.8. Extending a File Storage Pool

8.6.9. Deleting a File Storage Pool

March 23, 2021

0516-404 allocp: This system cannot fulfill the allocation request

When increasing logical volumes or file systems, the error “0516-404 allocp: This system cannot fulfill the allocation request” often occurs. Many AIX administrators are at first a little at a loss as to what the cause of the problem is: is it due to max LPs or upper bound, the chosen strictness or does the problem have completely different causes. Unfortunately, the error message is only generic and does not say what the real problem is. A good way to get to the bottom of the problem is the alog lvmt, in which all LVM actions, especially the low-level commands, including error messages are logged.

Our article Troubleshooting problems with extendlv and file system extension uses a series of examples to show how the cause of the problem can be found in many cases.

March 22, 2021March 22, 2021

0516-787 extendlv: Maximum allocation for logical volume lv01 is 512

If the following message occurs while expanding a logical volume or file system:

# chfs -a size=+5G /fs01
0516-787 extendlv: Maximum allocation for logical volume fslv01
        is 512.
#

Then the cause is a limitation of the logical volume. The size of a logical volume is limited by the maximum number of LPs (logical partitions) that can be allocated for the logical volume. The error message says exactly that and even gives the current value for the maximum number of LPs. This is a changeable attribute of the logical volume and can be displayed with the lslv command:

$ lslv fslv01
...MAX LPs:            512                    PP SIZE:        8 megabyte(s)
...$

The attribute can be changed with the command chlv:

# chlv -x 768 fslv01
#

With a PP (Physical Partition) size of 8 MB, 768 PPs are sufficient for exactly 6 GB. Of course, you could consider the next expansion and set the value accordingly higher.

If there are enough 0516-787 extendlv: Maximum allocation for logical volumes free in the underlying volume group and no other limits are exceeded, the file system or logical volume should now be able to be expanded:

# chfs -a size=+5G /fs01
Filesystem size changed to 12582912
Inlinelog size changed to 24 MB.
#

February 23, 2021

Correcting “wrong” LVM mirroring

In Part III of our article series “AIX LVM: Mechanics of migratepv” we show how incorrect mirroring of logical volumes can be corrected online. All that is required is the migratelp and migratepv commands and a good understanding of how these commands work.

Here are the links to the articles in the series:

AIX LVM: Mechanics of migratepv (Part I)

AIX LVM: Mechanics of migratepv (Part II)

AIX LVM: Mechanics of migratepv (Part III)