physical volume Archive - PowerCampus 01

April 8, 2022April 8, 2022

Changing the PVID of a Physical Volume

Each physical volume used by AIX LVM has a unique physical volume ID, or PVID for short. The PVID is a software-generated ID that is stored in the header area of a disk (block 0). When a new disk is added to an AIX system, the new physical volume does not yet have a PVID. As soon as a physical volume is added to a volume group, a PVID is automatically generated if the physical volume should not already have a PVID. An already existing PVID is adopted.

A PVID can also be created manually, using the chdev command. The pv attribute is set to the value yes:

# chdev -l hdisk3 -a pv=yes
hdisk3 changed
#

The set PVID can be displayed either with the lsattr command or simply with lspv:

$ lsattr -El hdisk3 -a pvid -F value
00c276b0084049750000000000000000
$
$ lspv |grep hdisk3
hdisk3          00c276b008404975                    None                       
$

A PVID can also be removed again. However, the physical volume must not be in use for this (e.g. as part of a volume group).

To clear a PVID of a physical volume, the pv attribute can be set to the value clear:

# chdev -l hdisk3 -a pv=clear
hdisk3 changed
#

The PVID has been removed as shown by the following outputs:

$ lsattr -El hdisk3 -a pvid -F value
none
$
$ lspv |grep hdisk3
hdisk3          none                                None                       
$

Attempting to delete the PVID of a physical volume that is in use, results in the following error message:

# chdev -l hdisk0 -a pv=clear
Method error (/usr/lib/methods/chgdisk):
        0514-062 Cannot perform the requested function because the
                 specified device is busy.
     pv    

#

April 7, 2022

Determining the Size of a Physical Volume

There are a number of different ways to determine the size of a physical volume (disk, LUN) under AIX.

If you have root privileges, you can use the bootinfo command with the “-s” (size) option:

#  bootinfo -s hdisk0
51200
#

The size of the physical volume is given in MB. In the example 51,200 MB or about 50 GB.

Without root privileges, the getconf command can be used. With this command, system-wide configuration parameters as well as device-specific variables can be displayed. The device-specific variable DISK_SIZE can be used to display the size of a physical volume. The physical volume in question is specified by the absolute path of the physical volume’s block or character device file:

$ getconf DISK_SIZE /dev/hdisk0
51200
$

Here, too, the size is given in MB.

Another option, which again requires root privileges, is to use the lsmpio command. The command offers the option “-q” (query) to display data about an MPIO storage device:

# lsmpio -ql hdisk0
Device:  hdisk0
…
           Capacity:  50.00GiB
…
#

The size is directly displayed in GB (GiB) this time.

If the physical volume is part of a volume group, the lspv command can also be used to at least estimate the size:

$ lspv hdisk0
…
TOTAL PPs:          199 (50944 megabytes)    VG DESCRIPTORS:   2
…                                      
$

The area that can be used for data is specified here (50,944 MB), the physical volume itself is somewhat larger, since space is also used for administrative information.

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)