vgchange.1m (2010 10)

vgchange(1M) vgchange(1M)

other systems can use read-only access. There is no problem if all systems activate the volume group for

read-only access.

Furthermore, volume group information is only read from the disks during volume group activation.

Dynamic changes to the volume group such as the following are not propagated to other systems sharing

the volume group:

Logical volume conﬁguration changes.

Changes to the status of the mirrored extents.

Bad-block relocation that occurs during write operations.

Because of these limitations, when sharing volume groups between systems it is recommended that logi-

cal volumes be accessed only by one system at a time. If logical volumes must be accessed simultane-

ously, the logical volumes should not be mirrored and should not have bad-block relocation turned on, or

all systems should use read-only access to the logical volumes.

Deactivation of Volume Goups Version 2.2 and Higher

The deactivation of volume groups version 2.2 and higher will automatically back up the volume group

conﬁguration unless the backup is disabled by the user via a

-A n option.

It is recommended that for volume group versions 2.2 and higher, the backup not be disabled during

deactivation. This is because, when snapshots are involved, the on-disk sharing details will change when

I/Os are in progress, in addition to any conﬁguration changes made. The conﬁguration is backed up dur-

ing deactivation to ensure that the latest sharing details are saved in the conﬁguration ﬁle.

Activation Using Physical Volumes With Restored Conﬁguration

If all the physical volumes that are available during an activation have a restored conﬁguration, then the

activation command displays a warning indicating this. This warning should be ignored if the latest

conﬁguration backup ﬁle was used for restoring the physical volumes in question.