movevdisk
Use the movevdisk command to update the preferred node of a volume either within the same caching I/O group or to another caching I/O group.
Syntax
Parameters
- -iogrp iogrp_id | iogrp_name IBM SAN Volume Controller only
- (Optional) Specifies the I/O group to move the volume to.
- -nocachingiogrp
- (Optional) If you specify this parameter, the volume has no caching I/O group. This option should be used under the direction of IBM Support only. The -nocachingiogrp parameter is mutually exclusive with the -iogrp and -node parameters.
- -force
- (Optional) If you specify the -force parameter, the contents of the cache are discarded and the volume might be corrupted. Use with caution.
- -node node_id | node_name
- (Optional) Specifies the node ID or name that is assigned as the preferred node.
- vdisk_id | vdisk_name | vdisk_uid
- (Required) Specifies the volume by ID, name, or UID to move.
Description
Use the movevdisk command to update the preferred node of a volume.
This command is not supported to change the I/O group if either copy is thin-provisioned or compressed and within a data reduction pool. The preferred node can be changed for volumes that are in data reduction pools.
A compressed volume can also be moved, and you can specify the preferred node in the new I/O
group. You can move a volume that is in a FlashCopy®
mapping, but the FlashCopy bitmaps remain in the
original I/O group. You cannot move volumes when the FlashCopy mapping is in preparing or prepared state.
Additionally, a volume can be moved if it is the target of a FlashCopy mapping that is in stopping state.
If the volume is offline, use one of the recovervdisk commands to recover the volume and bring it back online. To specify a preferred node for the volume, use the -node node_id | node_name parameter with the movevdisk command. Use the movevdisk command to change the I/O group with which this volume is associated.
- A volume to an offline I/O group under any circumstance. Remember: To avoid data loss, make sure that the I/O group is online before you move the volume.
- An offline volume to the recovery I/O group.
You can migrate a volume to a new I/O group to manually balance the workload across the nodes in the clustered system. You might end up with a pair of nodes that are overworked and another pair of nodes that are underworked.
For systems that support multiple I/O groups, if the volume is a target of a FlashCopy mapping with a source volume in an
active-active relationship, then the new I/O group must be in the same site as the
source volume. The system allows moving a volume in a remote copy relationship if the move does not
change the I/O group (it changes the preferred node). If the volume is in an
active-active relationship, the new I/O group must be in the same site as the
source I/O group.
A volume in a volume group with a replication policy cannot be moved to a different I/O group. The preferred node for the volume can be changed if the new preferred node is in the same I/O group. When the preferred node is changed, the preferred node for the change volume will also be changed.
Modifying the I/O group that services the volume can be done concurrently with I/O operations if the host supports non- disruptive volume move. It also requires a rescan at the host level to ensure that the multipathing driver is notified that the allocation of the preferred node has changed and the ports by which the volume is accessed has changed. This can be done in the situation where one pair of nodes becomes over used.
If there are any host mappings for the volume, the hosts must be members of the target I/O group or the migration fails.
Verify that you created paths to I/O groups on the host system. After the system successfully adds the new I/O group to the volume's access set and you moved selected volumes to another I/O group, detect the new paths to the volumes on the host. The commands and actions on the host vary depending on the type of host and the connection method used. These steps must be completed on all hosts to which the selected volumes are currently mapped.
The volume between I/O groups can be moved by using the addvdiskaccess command.
The following example move the DB_Volume to I/O group 2
movevdisk -iogrp 2 DB_VolumeThe resulting output:
No feedback