View figure.
You can use SMIT or the vsdnode command to enter virtual shared disk node information into the SDR.
To enter virtual shared disk node information using SMIT:
See the book PSSP: Command and Technical Reference for the command syntax.
Global volume group information is stored in the System Data Repository (SDR) VSD_Global_Volume_Group object. For each volume group on which virtual shared disks will be defined, the following data is required:
The LVM volume group's name on the serving node. The length of the name must be less than or equal to 15 characters.
The node number of the server node. The primary server node may be identified in four ways. See the vsdvg command reference page for specific information.
If you do not have the IBM Recoverable Virtual Shared Disk software installed, all server nodes are primary nodes.
The secondary server node is only intended for use with the IBM Recoverable Virtual Shared Disk software.
The node number of the serving node. The secondary server node may be identified in four ways. See the vsdvg command reference page for specific information.
The global volume group name is the globally unique name for this virtual shared disk volume group. The global volume group name is usually identical to the volume group name. The length of the name must be less than or equal to 31 characters. IBM suggests that the global volume group names be unique across the physical SP system. It must be unique within a system partition.
To enter virtual shared disk global volume group information using SMIT:
You can also enter virtual shared disk volume group information using the vsdvg command:
vsdvg [-g global_group_name ] local_group_name primary_server_node [secondary_server_node]
A virtual shared disk is defined by creating a VSD_Table object in the SDR. For each virtual shared disk, the following data is required:
The globally unique name of the virtual shared disk. The name must be less than or equal to 31 characters. IBM suggests that the name be unique across the physical SP system.
If you choose a vsd_name that is already the name of another device, the cfgvsd command will reject the name to insure that the special device files created for the name do not overlay and destroy files of the same name representing another device type (such as a logical volume).
The name of the logical volume on the serving node. The length of the name must be less than or equal to 15 characters.
The globally unique name of the volume group on which the virtual shared disk resides. This field is used to access the VSD_Global_Volume_Group to determine the node and the volume group that contains the underlying logical volume. The length of the name must be less than or equal to 31 characters.
Use the cache option only if your application does I/O in 4K blocks aligned on 4K disk boundaries, and issues a read immediately following a write.
Nocache is the default for new virtual shared disks created with the defvsd command.
This number is automatically allocated.
To enter virtual shared disk information using SMIT:
You can also enter virtual shared disk information using the defvsd command:
defvsd logical_volume_name global_group_name vsd_name [nocache | cache ]
Figure 18 is a simple example of a virtual shared disk. There are three virtual shared disks, one on each node. We have two physical hard disks per node and we defined a logical volume on one disk per node.
Figure 18. An Example of a Virtual Shared Disk Configuration
View figure.
Here's how we did it. First, we decided that three virtual
shared disks were needed, one on each node on a separate volume group.
We created a table of the information for our configuration.
Table 7. Virtual Shared Disk Information
| Node Number | hdisks | Volume Groups | Logical Volumes | vsd Name |
|---|---|---|---|---|
| 1 | hdisk0 | |||
| hdisk1 | vg1n1 | lv1vg1n1 | vsd1vg1n1 | |
| 2 | hdisk0 | |||
| hdisk2 | vg1n2 | lv1vg1n2 | vsd1vg1n2 | |
| 3 | hdisk0 | |||
| hdisk5 | vg1n3 | lv1vg1n3 | vsdvg1n3 |
You must create the volume groups and logical volumes before defining the virtual shared disk information. We created the volume groups (vg1n1, vg1n2, vg1n3) on each node for each virtual shared disk using SMIT:
smit mkvg
and entered the volume group information requested. We took the defaults. See AIX System Management Guide: Operating Systems and Devices, for more information.
Next we created the logical volume groups (lv1vg1n1, lv1vg1n2, lv1vg1n3) on each node using SMIT:
smit mklv
and entered the global volume group information. See AIX System Management Guide: Operating Systems and Devices, for more information on tuning logical volumes.
Next we used SMIT to check the volume group and logical volume information we created:
smit lsvg
smit lslv
Now we start to define our virtual shared disks. We entered the virtual shared disk node information using SMIT. This information was entered separately for node 1, 2, and 3. See Designating nodes as IBM Virtual Shared Disk nodes for more information.
smit vsd_data
and selected the VSD Node Information option.
In the table italics show the information we entered. A constant width font shows the default data. We took most of the defaults except where noted.
Table 8. Virtual Shared Disk Node Information
| Node Number | Adapter | Initial Cache | Max Cache | Request Blocks | pbufs | Min Buddy Buffer | Max Buddy Buffer | # Buddy Buffers |
|---|---|---|---|---|---|---|---|---|
| 1 | css0 | 64 | 256 | 256 | 48 | 4096 | 24576 | 4 |
| 2 | css0 | 64 | 256 | 256 | 48 | 4096 | 24576 | 4 |
| 3 | css0 | 64 | 256 | 256 | 48 | 4096 | 24576 | 4 |
Next we used SMIT to enter the virtual shared disk global volume group information for vg1n1, vg1n2 and vg1n3. See Entering global volume group information in the SDR for one node for more information.
smit vsd_data
and selected the VSD Global Volume Information option.
Table 9. Virtual Shared Disk Volume Group Information
| Global Group Name | Local VG Name | Primary Server | Secondary Server |
|---|---|---|---|
| vg1n1 | vg1n1 | 1 | - |
| vg1n2 | vg1n2 | 2 | - |
| vg1n3 | vg1n3 | 3 | - |
We did not enter information about secondary servers because that is only for users of the IBM Recoverable Virtual Shared Disk software.
Next we entered the virtual shared disk definition information for vsd1vg1n1, vsd1vg1n2 and vsd1vg1n3. See Entering Virtual Shared Disk information in the SDR for one node for more information.
Again we used the SMIT command:
smit vsd_data
and selected the Define a Virtual Shared Disk option.
Table 10. Virtual Shared Disk Definition Information
| LV Name | Global Group | Name | Option |
|---|---|---|---|
| lv1vg1n1 | vg1n1 | vsd1vg1n1 | nocache |
| lv1vg1n2 | vg1n2 | vsd1vg1n2 | nocache |
| lv1vg1n3 | vg1n3 | vsd1vg1n3 | nocache |
Now we have defined our virtual shared disk in the SDR.
smit list_vsd
Once you have defined virtual shared disk information in the SDR, you can display this information.
To list virtual shared disk definition information using SMIT (from the SP Configuration Database Management menu):
Or you can use the fastpath invocation for this menu:
smit list_vsd
At this point, you can select options for listing node, global volume group, and defined virtual shared disk information.
You can also list virtual shared disk information using the vsdsklst command with the appropriate flags to indicate what kind of information you want to display. The following example shows the format of the information returned by vsdsklst for one node from the vsdsklst -dv -a command.
k7n12.ppd.pok.ibm.com
Node Number:12; Node Name:k7n12.ppd.pok.ibm.com
Volume group:rootvg; Partition Size:4; Total:537; Free:315
Physical Disk:hdisk0; Total:537; Free:315
Volume group:vsdvg; Partition Size:4; Total:537; Free:533
Physical Disk:hdisk1; Total:537; Free:533
VSD Name:1HsD8n12{lv1HsD8n12}; Size:2
VSD Name:1HsD20n12{lv1HsD20n12}; Size:2
To view virtual shared disk information using SMIT:
You can also display virtual shared disk node information using the vsdatalst command:
vsdatalst -n
To view virtual shared disk global volume group information using SMIT:
You can also display virtual shared disk node information using the vsdatalst command:
vsdatalst -g
To view defined virtual shared disk information using SMIT:
You can also display defined virtual shared disk information using the vsdatalst command:
vsdatalst -v
You can delete the virtual shared disk information you have stored in the SDR. Once you have defined virtual shared disk information in the SDR, you may want to delete or change (delete and add) information. To delete virtual shared disk definition information using SMIT (from the SP Configuration Database Management menu):
The fastpath invocation for this menu is:
smit delete_vsd
At this point, you can select options for deleting node and global volume group information and for undefining a virtual shared disk.
You can also use the removevsd or undefvsd commands to remove a virtual shared disk, a list of virtual shared disks, or all the virtual shared disks in a system or system partition. See the command reference pages for removevsd and undefvsd for more information.
Once virtual shared disks have been defined in the SDR, they can be configured to the system and managed to various states by using SMIT menus or commands.
Running any of the following commands affects the virtual shared disk states only on the node on which the command is run:
The SMIT panels use dsh to run the command on any number of nodes you select. The SMIT menus may be invoked from the control workstation. See Figure 19 for an overview of virtual shared disk states and associated commands.
In order for an application to be able to read or write vsd.nnn, vsd.nnn must be in the active state on both the client and server. Both cfgvsd and startvsd must be run on vsd.nnn. Once vsd.nnn is in the active state, the application may open /dev/rvsd.nnn, providing the permissions on the file permit access. For example, to allow an application on node 1 to access /dev/rvsd1vg1n1, cfgvsd and startvsd must have been run on node 1 for vsd1vg1n1. To allow access to vsd1vg1n1 from node 2, cfgvsd and startvsd must also be run on node 2. You may use cfgvsdhsd on all nodes instead of cfgvsd on each node.
Figure 19 summarizes virtual shared disk states, how I/O requests are treated in each state, and the commands (sometimes called methods) used to change states. New users should study Figure 19 to understand virtual shared disk operation.
If you use the IBM Recoverable Virtual Shared Disk software, do not issue any commands that change the state of the virtual shared disks (cfgvsd, startvsd, stopvsd, or ucfgvsd.) The IBM Recoverable Virtual Shared Disk software issues these commands for you.
Figure 19. Virtual Shared Disk States and Associated Commands
View figure.
To manage virtual shared disks using SMIT:
The fastpath invocation for this menu is:
smit vsd_mgmt
Configuring puts a defined virtual shared disk in the stopped state, but does not make it available. The virtual shared disk configuration method (cfgvsd) issues /usr/lpp/csd/bin/readSDR to extract information from the SDR and puts it into the flat files VSD_Global_Volume_Group, VSD_Table, VSD_ipaddr and Node in the /usr/lpp/csd/vsdfiles directory. Other virtual shared disk commands access these files.
Use cfgvsd with dsh to configure virtual shared disks on more than one node at a time.
To configure a virtual shared disk using SMIT (from the VSD Management menu):
You can also configure a virtual shared disk using the cfgvsd command.
cfgvsd -a
cfgvsd vsd_name ...
Starting a virtual shared disk puts a stopped one in the active (and available) state. (This is equivalent to preparing and resuming a virtual shared disk.) Note that for a virtual shared disk to be usable, it must be in the active state on both the server and client nodes.
To start a virtual shared disk using SMIT (from the VSD Management menu):
You can also start a virtual shared disk using the startvsd command.
startvsd -a
startvsd vsd_name ...
Preparing a virtual shared disk puts a stopped one in the suspended state. In the suspend state, open and close requests are honored. Read and write requests are held until the virtual shared disk is brought to the active state.
To prepare a virtual shared disk using SMIT (from the VSD Management menu):
You can also prepare a virtual shared disk using the preparevsd command.
preparevsd -a
preparevsd vsd_name ...
Resuming a virtual shared disk puts a suspended one in the active state. The virtual shared disk remains available and read and write requests that were held are resumed.
To resume a virtual shared disk using SMIT (from the VSD Management menu):
You can also resume a virtual shared disk using the resumevsd command.
resumevsd -a
resumevsd vsd_name ...
Suspending a virtual shared disk puts an active one in the suspended state. The virtual shared disk remains available and read and write requests that were active are suspended and held. All read and write requests subsequent to those that were active are also held.
To suspend a virtual shared disk using SMIT (from the VSD Management menu):
You can also suspend a virtual shared disk using the suspendvsd command.
suspendvsd -a
suspendvsd vsd_name ...
Stopping a virtual shared disk puts a suspended one in the stopped state. The virtual shared disk becomes unavailable. All applications that have outstanding requests to a stopped virtual shared disk terminate in error.
To stop a virtual shared disk using SMIT (from the VSD Management menu):
You can also stop a virtual shared disk using the stopvsd command.
stopvsd -a
stopvsd vsd_name ...
Unconfiguring a stopped virtual shared disk makes it inaccessible. It does not, however, undefine or change the definition information for the virtual shared disk in the SDR.
To unconfigure a virtual shared disk using SMIT (from the VSD Management menu):
You can also unconfigure a virtual shared disk using the ucfgvsd command.
ucfgvsd -a
ucfgvsd vsd_name ...
Configuration information for a virtual shared disk includes:
To display managed virtual shared disk characteristics for all virtual shared disks using SMIT (from the VSD Management menu):
You can also display managed virtual shared disk characteristics using the lsvsd command. To display configuration information for specific virtual shared disks in your system, enter:
lsvsd -l vsd_name ...
To display managed virtual shared disk usage statistics for all virtual shared disks using SMIT (from the VSD Management menu):
You can also display managed virtual shared disk usage statistics using the lsvsd command. To display usage information for virtual shared disks in your system, enter:
lsvsd -s vsd_name ...
You might want to display usage information about the virtual shared disk device driver. Usage information includes:
To display usage information about the virtual shared disk device driver using SMIT (from the VSD Management menu):
You can also display virtual shared disk device driver usage statistics using the statvsd command:
statvsd
See the book PSSP: Command and Technical Reference for a description of these statistics.
You may wish to display and, in some cases, set virtual shared disk device driver operational parameters. Operational parameters include:
To display and set virtual shared disk device driver operational parameters using SMIT (from the VSD Management menu):
You can also display and set virtual shared disk device driver operational parameters using the ctlvsd command.
Warning: The vsdvts command writes data to the virtual shared disk. Do not use the command after you have put real data on a virtual shared disk. Refer to the vsdvts command reference page.
To test that you have successfully installed the IBM Virtual Shared Disk software and that you can successfully define and make a virtual shared disk active, and then read and write to it, follow these steps:
cfgvsd vsd_name
preparevsd vsd_name
resumevsd vsd_name
lsvsd -l vsd_name
The display should show that vsd.LV is in the active state.
vsdvts vsd_name
The command should complete within 15 seconds and you should get the message:
VSD verification test successful!
You can use the vsdvts command to verify all of your virtual shared disks. Use it to verify both local and remote virtual shared disks. Run the cfgvsd and startvsd commands on all client and server nodes. Use the SMIT panels to verify that the panels work.