This section tells how to maintain twin-tailed Logical Volume Manager (LVM) components shared by two nodes in an SP system running the IBM Recoverable Virtual Shared Disk software. It includes procedures for volume groups, logical volumes, and physical volumes.
Some of the definitions you need to understand are:
The twin-tailed components must have the same definition on both twin-tailed nodes. Any change to an LVM component must be reflected in the Object Data Manager (ODM) definitions on both nodes.
Follow the procedures in this chapter carefully in the order given to keep the LVM ODM definitions on both nodes synchronized.
The overall procedure for modifying a twin-tailed LVM component is the same for all tasks. In general, you export the volume group from a secondary node, make the change on the primary node, and then reimport the volume group on the secondary node. Specific operations, however, have unique steps. They are described in the following sections.
The table below summarizes the steps you must complete on the primary node
and the secondary node to change a twin-tailed LVM component in a recoverable
virtual shared disk system. Perform all the steps in the correct order
so the data does not become corrupted.
Table 11. General Procedure for Changing a Twin-tailed LVM Component
Step Number | Primary Node | Secondary Node |
---|---|---|
Step 1 | Complete prerequisite tasks | Complete prerequisite tasks |
Step 2 | Export a volume group | |
Step 3 | Vary on a volume group | |
Step 4 | Make changes to the twin-tailed LVM component | |
Step 5 | Vary off the volume group | |
Step 6 | Import a volume group | |
Step 7 | Change a volume group to remain dormant at start up | |
Step 8 | Vary off the volume group | |
Step 9 | Complete follow-up tasks | Complete follow-up tasks |
The prerequisite tasks, while not directly involved in modifying LVM components, must be completed before you begin to make the change.
The prerequisite tasks can vary for the different operations. The descriptions for each operation on the following pages have a list of specific prerequisite tasks.
Maintaining twin-tailed volume groups requires the following administrative tasks:
The table below summarizes the steps you must complete on the primary node and the secondary node to create a twin-tailed volume group. Perform all the steps in the correct order so the data does not become corrupted.
Table 12. Steps to Create a Twin-tailed Volume Group
Step Number | Primary Node | Secondary Node |
---|---|---|
Step 1 | Complete prerequisite tasks | Complete prerequisite tasks |
Step 2 | Create a twin-tailed volume group | |
Step 3 | Create logical volumes | |
Step 4 | Vary off the volume group | |
Step 5 | Import a volume group | |
Step 6 | Change a volume group to remain dormant at startup | |
Step 7 | Vary off the volume group | |
Step 8 | Complete follow-up tasks | Complete follow-up tasks |
Complete the following steps to create a twin-tailed volume group.
Use the smit mkvg fastpath to create a volume group.
smit mkvg
SMIT returns a screen similar to the following:
Use the smit mklv fastpath to create logical volumes. Create the logical volumes you want for this virtual shared disk.
Use the varyoffvg command to quiesce the affected volume group.
To vary off the volume group so that it can be activated as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts, enter:
varyoffvg volume_group_name
You now return to the secondary node. First, import the volume group onto the secondary node. Importing the volume group onto the secondary node synchronizes the ODM definition of the volume group on both nodes.
smit importvg
SMIT returns a screen similar to the following:
By default, a volume group that was just imported is configured to automatically become active at system restart. However, a recoverable virtual shared disk volume group should be varied on as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts. Therefore, after importing a volume group, use the SMIT Change a Volume Group screen to reconfigure the volume group to remain dormant at start up.
smit chvg
SMIT prompts you to select the volume group.
SMIT returns a screen similar to the following: The first field contains the volume group name you specified.
Use the varyoffvg command to quiesce the affected volume group after making the change.
To vary off the volume group so that it can be activated as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts, enter:
varyoffvg volume_group_name
Once you have created the volume group, do the following tasks:
The following table summarizes the steps you do on both the primary and
secondary nodes to extend (add one or more physical volumes to) a twin-tailed
volume group. Perform all the steps in the correct order so the data
does not become corrupted.
Table 13. Procedure for Extending a Twin-tailed LVM Component
Step Number | Primary Node | Secondary Node |
---|---|---|
Step 1 | Complete prerequisite tasks | Complete prerequisite tasks |
Step 2 | Export a volume group | |
Step 3 | Vary on a volume group | |
Step 4 | Extend a twin-tailed volume group | |
Step 5 | Vary off the volume group | |
Step 6 | Import a volume group | |
Step 7 | Change a volume group's characteristics | |
Step 8 | Vary off the volume group | |
Step 9 | Complete follow-up tasks | Complete follow-up tasks |
Before making any changes to the LVM elements on the primary node, you must export the appropriate volume group from the secondary node. Exporting the volume group deletes the information about this volume group from the ODM.
To use the exportvg command to export the volume group containing the component you are going to change on the secondary node, enter:
exportvg volume_group_name
To use the varyonvg command to activate the affected volume group after making the change, enter:
varyonvg volume_group_name
Use the smit extendvg fastpath to extend a volume group.
smit extendvg
SMIT returns a screen similar to the following:
Use the varyoffvg command to quiesce the affected volume group after making the change.
To vary off the volume group so that it can be activated as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts, enter:
varyoffvg volume_group_name
You now return to the secondary node. First, import the volume group onto the secondary node. Importing the volume group onto the secondary node synchronizes the ODM definition of the volume group with the primary node.
smit importvg
SMIT returns a screen similar to the following:
By default, a volume group that was just imported is configured to automatically become active at system restart. However, a recoverable virtual shared disk volume group should be varied on as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts. Therefore, after importing a volume group, use the SMIT Change a Volume Group screen to reconfigure the volume group to remain dormant at start up.
smit chvg
SMIT prompts you to select the volume group.
SMIT returns a screen similar to the following. The first field contains the volume group name you specified.
Use the varyoffvg command to quiesce the affected volume group after making the change.
To vary off the volume group so that it can be activated as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts, enter:
varyoffvg volume_group_name
Once the you have extended the volume group, do the following tasks:
The following table summarizes the steps you do on both the primary and
secondary nodes to add or remove logical volumes to or from a twin-tailed
volume group. Perform all the steps in the correct order so the data
does not become corrupted.
Table 14. Procedure for Extending a Twin-tailed LVM Component
Step Number | Primary Node | Secondary Node |
---|---|---|
Step 1 | Complete prerequisite tasks | Complete prerequisite tasks |
Step 2 | Export a volume group | |
Step 3 | Create or remove logical volumes | |
Step 4 | Vary off the volume group | |
Step 5 | Import a volume group | |
Step 6 | Change a volume group's characteristics | |
Step 7 | Vary off the volume group | |
Step 8 | Vary on the volume group | |
Step 9 | Complete follow-up tasks | Complete follow-up tasks |
Before making any changes to the LVM elements on the primary node, you must export the appropriate volume group from the secondary node. Exporting the volume group deletes the information about this volume group from the ODM.
To use the exportvg command to export the volume group containing the component you are going to change on the secondary node, enter:
exportvg volume_group_name
To create the logical volumes, use the fastpath invocation to the SMIT panel:
smit mklv
Alternatively, you can use the command line interface to create the logical volumes:
mklv
To remove the logical volumes, use the fastpath invocation to the SMIT panel:
smit rmlv
Alternatively, you can use the command line interface to remove the logical volumes:
rmlv
Use the varyoffvg command to quiesce the affected volume group after making the change.
To vary off the volume group so that it can be activated as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts, enter:
varyoffvg volume_group_name
You now return to the secondary node. First, import the volume group onto the secondary node. Importing the volume group onto the secondary node synchronizes the ODM definition of the volume group with the primary node.
smit importvg
By default, a volume group that was just imported is configured to automatically become active at system restart. However, a recoverable virtual shared disk volume group should be varied on as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts. Therefore, after importing a volume group, use the SMIT Change a Volume Group screen to reconfigure the volume group to remain dormant at start up.
To use the smit chvg fastpath to change the characteristics of a volume group, enter:
smit chvg
For more information, refer to Step 7: Change volume group characteristics on the secondary node.
Alternatively, to use the command line interface to change the volume group to remain dormant at startup, enter:
chvg -a `n' -Q`y' volume_group_name
Use the varyoffvg command to quiesce the affected volume group after making the change.
To vary off the volume group so that it can be activated as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts, enter:
varyoffvg volume_group_name
Use the varyonvg command to quiesce the affected volume group after making the change.
To vary on the volume group so that it can be activated as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts, enter:
varyonvg volume_group_name
Once the you have extended the volume group, do the following tasks:
The following table summarizes the steps you do on both the primary and
secondary nodes to reduce (remove one or more physical volumes from) a
twin-tailed volume group:
Table 15. Procedure for Reducing a Twin-Tailed Volume Group
Step Number | Primary Node | Secondary Node |
---|---|---|
Step 1 | Complete prerequisite tasks | Complete prerequisite tasks |
Step 2 | Export a volume group | |
Step 3 | Vary on a volume group | |
Step 4 | Remove data from the physical volume | |
Step 5 | Reduce a twin-tailed volume group | |
Step 6 | Vary off the volume group | |
Step 7 | Import volume group | |
Step 8 | Change volume group characteristics | |
Step 9 | Vary off the volume group | |
Step 10 | Complete follow-up tasks | Complete follow-up tasks |
Complete the following tasks to reduce a twin-tailed volume group.
Before making any changes to the LVM elements on the primary node, you must export the appropriate volume group from the secondary node. Exporting the volume group deletes the information about this volume group from the ODM.
To use the exportvg command to export the volume group containing the component you are going to change on the secondary node, enter:
exportvg volume_group_name
To use the varyonvg command to verify that the affected volume group is varied on after making the change, enter:
varyonvg volume_group_name
Use the smit migratepv fastpath to move data on the physical volume being removed from the volume group to a different physical volume. If you do not, data will be lost.
smit migratepv
SMIT returns a screen similar to the following:
SMIT returns a screen similar to the following. The physical volumes being migrated are entered in the SOURCE physical volume names field.
Use the smit reducevg fastpath to reduce a volume group.
smit reducevg
SMIT returns a screen similar to the following:
SMIT returns a screen similar to the following:
SMIT returns a screen similar to the following. The name of the volume group you specified in the preceding screen is entered.
Use the varyoffvg command to quiesce the affected volume group after making the change.
To vary off the volume group so that it can be activated as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts, enter:
varyoffvg volume_group_name
You now return to the secondary node. First, import the volume group on the secondary node. Importing the volume group onto the secondary node synchronizes the ODM definition of the volume group on the node.
smit importvg
SMIT returns a screen similar to the following:
By default, a volume group that was just imported is configured to automatically become active at system restart. However, a recoverable virtual shared disk volume group should be varied on as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts. Therefore, after importing a volume group, use the SMIT Change a Volume Group screen to reconfigure the volume group to remain dormant at startup.
smit chvg
SMIT prompts you to select the volume group.
A screen similar to the following appears. The first field contains the volume group name you specified.
Use the varyoffvg command to quiesce the affected volume group after making the change.
You vary off the volume group so that it can be activated as appropriate by the IBM Recoverable Virtual Shared Disk recovery scripts. Enter:
varyoffvg volume_group_name
Once the you have reduced the volume group, complete the following tasks:
See the following table for an overview of the steps needed to remove a
twin-tailed volume group.
Table 16. Steps to Remove a Shared Volume Group
Step Number | Primary Node | Secondary Node |
---|---|---|
Step 1 | Complete prerequisite tasks | Complete prerequisite tasks |
Step 2 | Export volume group information | |
Step 3 | Vary on a volume group | |
Step 4 | Delete a twin-tailed volume group |
Complete the following steps to remove a twin-tailed volume group.
Before making any changes to the LVM elements on the primary node, you must export the appropriate volume group from the secondary node. Exporting the volume group deletes the information about this volume group from the ODM. To use the exportvg command to export the volume group containing the component you are going to change on the secondary nodes, enter:
exportvg volume_group_name
To use the varyonvg command to activate the affected volume group after making the change, enter:
varyonvg volume_group_name
smit reducevgSMIT returns a screen similar to the following:
SMIT returns a screen similar to the following: