This chapter summarizes the xvm command-line interface (CLI) and provides examples of each command. For a full description of each command, see the help text, as described in “Online Help for xvm CLI Commands ” in Chapter 4:
xvm:cluster> help -verbose command |
This chapter discusses the following
See also Chapter 4, “Overview of the xvm CLI”.
This section discusses the following:
The set command changes the current XVM domain, which can be either cluster or local.
 | Note: You can set the domain to cluster only if the appropriate services are started; see “CXFS Service Requirements for Cluster Domain” in Chapter 2. |
If the current domain is local, the XVM objects you are creating belong to the local node you on which you are executing the xvm command. If the current domain is cluster, the XVM objects you are creating belong to the cluster that the local node belongs to.
The current domain is displayed as part of the xvm prompt, which appears as one of the following:
Cluster prompt:
xvm:cluster>
Local prompt:
xvm:local>
The following example changes the current domain from cluster to local:
xvm:cluster> set domain local |
You can also display the current domain from the shell command line. For example:
# /sbin/xvm set domain cluster |
For more information, see “Local Domain and Cluster Domain” in Chapter 2.
The label command assigns a disk to XVM. The label command writes or modifies a physvol label on a disk. In a clustered environment, you can label only the disks that are attached to the local node.
The -name option assigns a name to the physvol. When assigning multiple disks to XVM, the supplied name acts as a prefix for each physvol name, with a unique numeric suffix added.
For example, to label disk 600a0b8000269d1e00004ce048bfb304 as the XVM physvol fred:
xvm:cluster> label -name fred /dev/pm/600a0b8000269d1e00004ce048bfb304 |
You cannot label a disk as an XVM disk if the disk contains any partitions that are currently in use as mounted filesystems. On systems with many disks, these checks can be time-consuming. You can specify whether you want to override this restriction and not check for in-use partitions.
 | Caution: Data corruption or system panics can result from labeling disks with partitions that are in use. |
For more information and examples, see the full help text.
If you want to disable the default automatic probing of devices under appropriate circumstances, use one of the following methods:
Use the -noprobe option of the label command when you label a disk to temporarily disable automatic probing for the current action:
xvm:cluster> label -name physvolname -noprobe unlabeled-disk
Use the set command to disable autoprobing entirely:
xvm:cluster> set autoprobe disabled
To reenable autoprobing, use the following command:
xvm:cluster> set autoprobe enabled
The show command displays information about XVM objects:
The following example using the show -extend option displays all the existing physvols and their device paths:
xvm:cluster> show -extend phys phys/_mtx 2339536896 online,cluster,accessible (/dev/disk/by-path/pci-0000:08:03.1-fc-0x201400a0b8269d1e-lun-6) phys/first 2339536896 online,cluster,accessible (/dev/disk/by-path/pci-0000:08:03.1-fc-0x201400a0b8269d1e-lun-5) phys/phenix 2339536896 online,cluster,accessible (/dev/disk/by-path/pci-0000:08:03.1-fc-0x201400a0b8269d1e-lun-7) |
The following example shows all information for the physvol first:
xvm:cluster> show -v phys/first XVM physvol phys/first ========================= size: 2339536896 blocks sectorsize: 512 bytes state: online,cluster,accessible uuid: 30ac6373-75f7-4518-b4f0-826fd99a0aa6 system physvol: no path manager device: /dev/pm/SGI-TP9700--lun6-600a0b8000269d1e0000c9b14d31a849 on host cxfsxe18 using paths: /dev/disk/by-path/pci-0000:08:03.1-fc-0x201400a0b8269d1e-lun-5 <sdah 66:16> affinity=none ws /dev/disk/by-path/pci-0000:08:03.1-fc-0x203400a0b8269d1e-lun-5 <sdy 65:128> affinity=none /dev/disk/by-path/pci-0000:08:03.1-fc-0x201500a0b8269d1e-lun-5 <sdp 8:240> affinity=none /dev/disk/by-path/pci-0000:08:03.1-fc-0x203500a0b8269d1e-lun-5 <sdg 8:96> affinity=none [ GPT label. magic:EFI PART GPT Label detected Disk has the following XVM label: Clusterid: 0 Host Name: clustard Disk Name: first Magic: 0x786c6162 (balx) Version 2 Uuid: 30ac6373-75f7-4518-b4f0-826fd99a0aa6 last update: Tue Nov 27 17:19:53 2012 state: 0xa1<online,cluster,accessible> flags: 0x0<idle> secbytes: 512 label area: 8157 blocks starting at disk block 35 (10 used) user area: 2339536896 blocks starting at disk block 8192 Physvol Usage: Start Length Name --------------------------------------------------- 0 233953664 slice/firsts0 233953664 233953664 slice/firsts1 467907328 70186080 slice/firsts10 538093408 70186080 slice/firsts11 608279488 70186080 slice/firsts12 678465568 70186080 slice/firsts13 748651648 70186080 slice/firsts14 818837728 70186080 slice/firsts15 889023808 70186080 slice/firsts16 959209888 70186080 slice/firsts17 1029395968 70186080 slice/firsts18 1099582048 70186080 slice/firsts19 1169768128 70186080 slice/firsts20 1239954208 70186080 slice/firsts21 1310140288 70186080 slice/firsts22 1380326368 70186080 slice/firsts23 1450512448 70186080 slice/firsts24 1520698528 70186080 slice/firsts25 1590884608 70186080 slice/firsts26 1661070688 70186080 slice/firsts27 1731256768 70186080 slice/firsts28 1801442848 70186080 slice/firsts29 1871628928 384 (unused) 1871629312 233953664 slice/firsts8 2105582976 233953664 slice/firsts9 2339536640 256 (unused) Local stats for phys/first since being enabled or reset: ------------------------------------------------------------------------------ stats collection is not enabled for this physvol |
The following example displays information about unlabeled disks:
xvm:cluster> show -v unlabeled Unlabeled disk unlabeled/dev/pm/SGI-TP9700--lun6-600a0b8000269d1e0000c9b14d31a849 ================================ using paths: /dev/disk/by-path/pci-0002:00:02.1-fc-0x21000011c61dd97e:0x0000000000000000 <sdbr 68:80> affinity=none ws ] /dev/disk/by-path/pci-0002:00:02.1-fc-0x22000011c61dd97e:0x0000000000000000 <sdbq 68:64> affinity=none /dev/disk/by-path/pci-0002:00:02.0-fc-0x21000011c61dd97e:0x0000000000000000 <sdz 65:144> affinity=none /dev/disk/by-path/pci-0002:00:02.0-fc-0x22000011c61dd97e:0x0000000000000000 <sdy 65:128> affinity=none |
The show command can also display information about foreign disks, which can be useful if you must use the steal command to take control of an XVM physvol from its current owner. In this situation, you may need to determine the owner of a disk that you cannot read as a physvol, because it appears as a foreign disk to you. The output of the show command will show the current owner as the Host Name of the physvol.
For example, the following shows that the foreign disk is owned by the node named clux2:
xvm:cluster> show -v foreign Foreign disk foreign//dev/pm/SGI-ST336753FC-3HX2XSST00007513R1LT ================================ using paths: /dev/disk/by-path/pci-0002:00:02.1-fc-0x22000011c61dd974:0x0000000000000000 <sdbs 68:96> affinity=none ws /dev/disk/by-path/pci-0002:00:02.1-fc-0x21000011c61dd974:0x0000000000000000 <sdbt 68:112> affinity=none /dev/disk/by-path/pci-0002:00:02.0-fc-0x22000011c61dd974:0x0000000000000000 <sdaa 65:160> affinity=none /dev/disk/by-path/pci-0002:00:02.0-fc-0x21000011c61dd974:0x0000000000000000 <sdab 65:176> affinity=none Disk has the following XVM label: Clusterid: 0 Host Name: clux2 Disk Name: clux4 Magic: 0x786c6162 (balx) Version 2 Uuid: 47a1faf5-7a9e-4f69-848d-a94de981f57d last update: Wed Aug 31 17:34:08 2011 state: 0xa1<online,cluster,accessible> flags: 0x0<idle> secbytes: 512 label area: 8157 blocks starting at disk block 35 (10 used) user area: 71670988 blocks starting at disk block 8192 |
For information on foreign disks, see “Local Domain and Cluster Domain” in Chapter 2. For information on the steal command, see “Forcibly Transferring Ownership of a Foreign Disk with the steal Command”.
| Note: The steal command should be used only when ownership cannot be changed using the give command. See “Gracefully Transferring Ownership of a Disk or Physvol with the give Command”. |
The show command output indicates whether a physical volume has no physical connection to the system and would return an I/O error when read or write activity is attempted anywhere on the volume. In the following examples, the physical volume lcmtst has no physical connection on this system.
xvm:cluster> show vol
vol/c1 0 online
vol/con1 0 offline,no physical connection
vol/lmc1 0 online,no physical connection
vol/lmctst3s2 0 online
vol/lmctst3s3 0 online
vol/lmctst3s4 0 online
xvm:cluster> show -topology vol/con1
vol/con1 0 offline,no physical connection
subvol/con1/data 400000 offline,pieceoffline
concat/concat9 400000 offline,tempname,incomplete
slice/lmctsts1 200000 online
(empty) * *
xvm:cluster> show -topology vol/lmc1
vol/lmc1 0 online,no physical connection
subvol/lmc1/data 200000 online
mirror/mirror7 200000 online,tempname
slice/lmctst2s1 200000 online
slice/lmctsts0 200000 online |
The show command can also be used to display information about other volume elements. For more examples of the show command see “Displaying Volume Elements with the show Command”.
You can make the following modifications by using the change command:
The name of the following objects:
Physvol
Volume
User-defined subvolume
Concat
Mirror
Stripe
Note: You cannot modify slice names. The online/offline or disabled/enabled state of a volume element
The primary leg of a mirror
The user ID, group ID, and permission modes of a subvolume
Whether statistics are gathered or reset for the local node
For example, to enable statistics for physvol pvol0 and the data subvolume of volume fred:
xvm:cluster> change stat on phys/pvol0 vol/fred/data |
The probe command probes a disk with XVM labels so that the system is able to recognize the disk as an XVM disk. Disks are probed automatically when the system is booted, but you must manually execute a probe command when you add an XVM disk to a running system. If you execute the probe command on a disk that has not been previously labeled, an error is returned.
For example:
To probe the unlabeled drives:
xvm:cluster> probe unlabeled/*
To probe the physvol named fred:
xvm:cluster> probe fred
The dump command outputs the xvm CLI commands that will generate a volume element; you can save the output to a file and use it to regenerate a physvol. For examples of the dump command, see “Reconstructing Volume Elements with the dump Command”.
The unlabel command removes an XVM label from a disk so that the disk is no longer an XVM disk. This restores the original partitioning scheme to the disk.
| Note: In a clustered environment, you can unlabel only those disks that are attached to the local node. |
For example:
To remove the XVM label from the physvol named phys1:
xvm:cluster> unlabel phys1
To forcibly unlabel phys1, first deleting any slices that may exist:
xvm:cluster> unlabel -force phys1
To gracefully give the ownership of a disk or physvol to another node or another cluster, use the give command.
| Note: You cannot give away a disk or physvol that has slices that are part of open subvolumes. For this reason, an attempt to give away a disk will fail during a mirror revive. In general, you must unmount filesystems on XVM volumes that contain the physvol and wait for mirror revives to complete before giving away a physvol. |
Giving a disk or physvol away from a domain will result in all slices (and any empty parents that result) being deleted in the nodes of that domain. The configuration information will be retained on the disk. Subvolumes that span disks might go offline if giving a disk away causes slices belonging to that physvol to be removed. The new owner must probe the disk for the configuration information to become visible, either as part of a reboot or if you explicitly execute the probe command on the new owner.
For example, to relinquish ownership of the physvol named fred to the cluster named mycluster:
xvm:cluster> give -cluster mycluster fred |
| Note: You can specify any host or cluster name as the new owner of the disk, even if it is not valid when you execute the command. |
In situations where you cannot use the give command to gracefully change the ownership, such as when the owning host/cluster is unavailable or when disks are moved from one machine to another, it may be necessary to use the steal command to transfer the ownership of a foreign disk to the local node or cluster.
| Caution: The steal command will unconditionally reset the owner of a foreign disk. No attempt is made to inform the previous owner that the ownership has changed. If another host or cluster has the physvol instantiated, configuration corruption or data corruption can occur. You should only use steal if you cannot use give. |
For example:
To change the ownership of the specified disk from the cluster yourcluster to the current cluster:
xvm:cluster> steal -cluster yourcluster foreign//dev/pm/600a0b8000269d1e00004ce048bfb304
To change the ownership of the specified disk from the node yournode to the current cluster:
xvm:cluster> steal -cluster yourcluster foreign//dev/pm/600a0b8000269d1e00004ce048bfb304
To change the ownership of the specified disk from the node yournode to the local node:
xvm:cluster> set domain local xvm:local> steal yournode foreign//dev/pm/600a0b8000269d1e00004ce048bfb304
This section discusses the following:
This section discusses the following commands:
The concat command creates a volume element that concatenates all of its children into one address space. When you create a concat, you must specify whether you are naming the generated volume to which it is attached or whether the system will generate a temporary volume name. If you explicitly name this generated volume, the name is stored in label space and persists across reboots.
The following example concatenates the slices freds0 and wilmas0 into a larger address space. The created concat has a system-generated temporary name and is contained in a volume with a system-generated temporary name:
xvm:cluster> concat -tempname slice/freds0 slice/wilmas0 |
The following example also concatenates the slices freds0 and wilmas0 into a larger address space. It explicitly names the resulting concat myconcat and the volume it belongs to concatvol:
xvm:cluster> concat -vename myconcat -volname concatvol slice/freds0 slice/wilmas0 |
The mirror command creates a volume element that maintains identical data images on its underlying volume elements. When you create a mirror, you must specify whether you are naming the generated volume to which it is attached or whether the system will generate a temporary volume name. If you explicitly name this generated volume, the name is stored in label space and persists across reboots.
When you create a mirror that has more than one leg, a message is written to the system log, indicating that the mirror is reviving. This indicates that the system is beginning the process of mirroring the data. Another message is written to the system log when this process is complete. For large mirror components, this may take a long time. You cannot halt a mirror revive after it has begun except by detaching all but one of the legs of the mirror.
If the revive fails, a message will be written to the system console as well as to the system log. For more information, see “Mirror Revives” in Chapter 9.
When you create a mirror, you can define a read policy and a primary leg for the mirror. You can also specify that the mirror does not need to be revived when it is created. Alternately, you can specify that the mirror will never need to be revived; this is an option that is useful when you are mirroring a scratch filesystem. These features are described in “Creating Mirrors” in Chapter 2.
| Note: The components of a mirror do not have to be identical in size, but if they are not there will be unused space in the larger components. |
For example:
To create a mirror whose legs are the slices freds0 and wilmas0 and associate the mirror with a volume named mirvol:
xvm:cluster> mirror -volname mirvol slice/freds0 slice/wilmas0
To create a mirror with legs slice/freds0 and slice/wilmas0 and volume name newmirvol :
xvm:cluster> mirror -volname newmirvol -clean slice/freds0 slice/wilmas0
In this example, a revive will not be initiated when the mirror is created.
To create an empty mirror with a sequential read policy:
xvm:cluster> mirror -tempname -rpolicy sequential
This command creates a mirror with a system-generated name that is contained in a volume with a system-generated name. To make this mirror usable, you must explicitly add legs using the attach command.
To create a two-leg mirror with a primary leg named freds0:
xvm:cluster> mirror -tempname -primary slice/freds0 slice/freds0 slice/wilmas0
All reads will be directed to freds0, with writes going to both freds0 and wilmas0. This command creates a mirror with a system-generated name that is contained in a volume with a system-generated name.
The slice command creates slices from specified block ranges of physvols.
For example:
To create one slice covering the whole usable space of the physvol phys1:
xvm:cluster> slice -all phys1
To create four equal-sized slices covering the physvol phys1:
xvm:cluster> slice -equal 4 phys1
To create a slice starting with block 5,000 with a length of 100,000 blocks:
xvm:cluster> slice -start 5000 -length 100000 phys1
To divide the 100,000-block chunk beginning at block 5,000 into four equal-sized slices:
xvm:cluster> slice -start 5000 -length 100000 -equal 4 phys1
The stripe command creates a volume element that distributes a set of volume elements across an address space. When you create a stripe, you must specify whether you are naming the generated volume to which it is attached or whether the system will generate a temporary volume name. If you explicitly name this generated volume, the name is stored in label space and persists across reboots.
| Note: It is legal to create a stripe that consists of volume elements of unequal size, although this may leave some space unused. |
By default, a stripe unit must be a multiple of 32 512-byte blocks. You can remove this restriction with the -noalign flag.
The actual size of the stripe depends on the size of the stripe unit size and the volume elements that make up the stripe. In the simplest case, the volume elements are all the same size and are an even multiple of the stripe unit size. For example, if the stripe unit is 128 512-byte blocks (the default stripe unit size), and you create a stripe consisting of two slices that are each 256,000 blocks, all the space of each of the slices is used. The stripe size is the full 512,000 blocks of the two slices.
On the other hand, if two slices that make up a stripe are each 250,000 blocks and the stripe unit is 128 blocks, then only 249,984 of the blocks on each slice can be used for the stripe and the size of the stripe will be 499,968 blocks. This situation may arise when you create the slices on a disk by dividing the disk equally, or use the entire disk as a slice, and do not coordinate the resulting stripe size with the stripe unit size.
Even if one of the two slices that make up the two-slice stripe in the second example is 256,000 blocks (while the other is 250,000 blocks), the stripe size will be 499,968 blocks because the same amount of space in each volume element that makes up the slice is used.
Following is the general formula for determining the stripe size, where stripe_width is the number of volume elements that make up the stripe (using integer arithmetic):
stripe_size = (smallest_stripe_member / stripe_unit) * stripe_unit * stripe_width
You can view the stripe unit of an existing stripe using either of the following commands (where stripename is the name of the existing stripe):
xvm:cluster> show -extend stripename xvm:cluster> show -v stripename |
If your non-ALUA RAID configuration requires that you spread I/O across controllers, you must have a complete /etc/failover2.conf file configured. This is necessary to ensure that I/O is restricted to a chosen primary path. For example, if you want a striped volume to span two host bus adapters, you must configure a /etc/failover2.conf file to specify a primary path. For information on configuration of failover for storage devices, see your SGI support provider. Information on the /etc/failover2.conf file can also be found in the /etc/failover2.conf file itself. See Chapter 6, “XVM Path Failover”.
For information on configuring stripes that span two host bus adapters, see Chapter 6, “XVM Path Failover”.
For example:
To stripe the slices freds0 and wilmas0 and associate the volume stripedvol with the slices:
xvm:cluster> stripe -volname stripedvol slice/freds0 slice/wilmas0
To stripe the mirror0 and mirror1 using a stripe-unit size of 512 512-byte blocks:
xvm:cluster> stripe -tempname -unit 512 mirror[01]
To create an empty stripe with room for four slices:
xvm:cluster> stripe -tempname -pieces 4
Note: Four volume elements must be attached to the stripe before it will come online.
The subvolume command creates a subvolume and optionally attaches a specified concat, mirror, stripe, or slice to the subvolume. (The volume element attached to the subvolume cannot be a volume or another subvolume.)
When you create a subvolume, you must specify whether you are naming the generated volume to which it is attached or whether the system will generate a temporary volume name. If you explicitly name this generated volume, the name is stored in label space and persists across reboots.
You can create a subvolume of a system-defined type (data , log, or rt) or you can create a subvolume of a user-defined type. There cannot be more than one subvolume with the same type under a volume. For example, there can be only one data subvolume under a volume. See “Subvolume” in Chapter 2.
For example:
To create a log subvolume, attach concat0 to it, and associate the volume myvol with the subvolume:
xvm:cluster> subvolume -volname myvol -type log concat0
To create a subvolume and attach concat0 to it, setting the user ID and permission mode of the block and character special files corresponding to the subvolume:
xvm:cluster> subvolume -tempname -uid 1823 -mode 0664 concat0
To create a subvolume with a user-defined type of 100:
xvm:cluster> subvolume -tempname -type 100 concat0
| Caution: You should unmount a filesystem before making changes to it via XVM if those changes will affect address space. See “Unmount Filesystems Before Making XVM Topology Changes” in Chapter 3. |
This section discusses the following commands:
The attach command attaches an existing volume element to another existing volume element. For information on the restrictions that XVM imposes on attachments, see “Attaching Volume Elements” in Chapter 2.
You can explicitly specify where to attach a volume element; if you do not, the source volume element will be attached to the first (leftmost) hole in the XVM topology tree for the target volume element. If there are no holes in the tree, the source volume element will be appended to the end (that is, to the rightmost position).
You can attach multiple source volume elements to a single target volume element by using the attach command. When attaching multiple source volume elements, the position you specify for the attachment applies only to the first volume element; remaining volume elements will be placed to the right, filling holes or appending.
When you attach multiple source volume elements to a single target volume element, they are attached one at a time, in turn. If an attach in the list fails, XVM attempts to restore the volume elements to their previous parents. If a volume element cannot be restored, a warning message is generated and manual intervention is needed.
The following example attaches the slice freds0 to concat0 at the first available position:
xvm:cluster> attach slice/freds0 concat0 |
The following example attaches all subvolumes of vol0 to vol1:
xvm:cluster> attach vol0/* vol1 |
The following example attaches slice/freds0 to concat0, performing checks as if concat0 and slice/freds0 were part of open subvolumes, even if they are not:
xvm:cluster> attach -safe slice/freds0 concat0 |
The change command modifies the attributes of a physvol or volume element that you have previously defined. You can change a variety of attributes, depending on the object. You can use the change command to enable statistics collection for an object, to bring a volume element back online that the kernel has disabled, and to manually disable and reenable a volume element.
You can use the change command to rename most existing objects (you cannot change the name of a slice). The name you give an object with this command remains persistent across reboots.
For example:
To enable statistics for physvol pvol0 and the data subvolume of vol/fred:
xvm:cluster> change stat on phys/pvol0 vol/fred/data
To reset statistics for all objects that have statistics enabled:
xvm:cluster> change stat reset *
To change the name of volume fo1s0 to myvol:
xvm:cluster> change name myvol vol/fo1s0
The detach command detaches a volume element from its parent. When you detach a volume element, a new volume will be created, just as a volume is created when you create a volume element. You can name the generated volume explicitly or you can specify that the volume be automatically generated with a temporary name. If you explicitly name this generated volume, the name is stored in label space and persists across reboots. A subvolume of type data is automatically generated for the volume element you are detaching unless the volume element you are detaching is itself a subvolume of a different type.
You cannot detach the last valid leg of an open mirror from that mirror because this will cause the mirror to go offline.
An element of an open subvolume can only be detached if this will not cause the subvolume to go offline. The only element that can be detached without putting the subvolume offline is a mirror leg that is not the last leg of that mirror. The detach command provides a -force option to override this restriction and a -safe option to impose this restriction even if the subvolume is not open.
For example:
To detach the volume element concat0 from its parent and associate concat0 with the volume fred:
xvm:cluster> detach -volname fred concat0
To detach concat0, even if it is part of an open subvolume, and the subvolume would go offline as a result:
xvm:cluster> detach -force -tempname concat0
To detach concat0 but ensure that the detachment will not cause the subvolume to go offline, even if the corresponding subvolume is not currently open:
xvm:cluster> detach -safe -tempname concat0
The remake command reorganizes volume elements by collapsing holes in its XVM topology tree or by rearranging its children. You can use a single remake command as a convenient alternative to executing a series of attach and detach commands.
When you rearrange the children, you can specify one of the following rearrangement methods:
| Method | Description | |
| swap | Swaps the positions of two children under a volume element | |
| reorder | Reorders all of the children under a volume element |
If you do not specify a method, XVM will collapse any holes in the XVM topology tree for the volume element.
For example:
To reorganize the children of concat0, swapping pieces numbered 0 and 1:
xvm:cluster> remake concat0 swap concat0/0 concat0/1
For more information, see “Specifying Objects by Piece Number” in Chapter 4.
To reorganize concat0, reversing the order of its three children:
xvm:cluster> remake concat0 reorder concat0/2 concat0/1 concat0/0
To collapse any holes in the XVM topology tree for concat0:
xvm:cluster> remake concat0
This section discusses the following commands:
The insert command inserts a mirror or a concat above another volume element. You cannot insert a volume element above a volume or a subvolume.
The insert command allows you to grow a volume element on a running system by inserting a concat or to add mirroring on a running system by inserting a mirror. The volume element you are growing or mirroring can be part of an open subvolume and can have active I/O occurring.
For example, if you begin with a simple logical volume named tinyvol that contains a single slice named freds0 , the topology of the logical volume is as follows:
xvm:cluster> show -top tinyvol
vol/tinyvol 0 online
subvol/tinyvol/data 177792 online,open
slice/freds0 177792 online,open |
You can insert a concat in the volume above the slice, which allows other members to be attached, and allows the corresponding subvolume to be grown without having to take it offline:
xvm:cluster> insert concat slice/freds0 </dev/cxvm/tinyvol> concat/concat0 |
The topology of the logical volume is now as follows:
xvm:cluster> show -top tinyvol
vol/tinyvol 0 online
subvol/tinyvol/data 177792 online,open
concat/concat0 177792 online,tempname,open
slice/freds0 177792 online,open |
You can now grow the volume by attaching another slice to the concat.
The following example inserts a one-member mirror over the volume element concat0. This allows other members to be attached and concat0 to be mirrored without having to take it offline.
xvm:cluster> insert mirror concat0 |
The collapse command removes a layer from the XVM topology tree by removing a volume element, linking the child of the volume element to the volume element's parents.
You can use the collapse command to collapse a mirror or concat in an open subvolume. Generally, this is used to reverse a previous insert operation.
For example, the following command sequence inserts a mirror above an existing concat named concat1 and then displays the topology of the resulting logical volume:
xvm:cluster> insert mirror concat1
</dev/cxvm/vol9> mirror/mirror2
xvm:cluster> show -top vol9
vol/vol9 0 online,tempname
subvol/vol9/data 5926338 online
mirror/mirror2 5926338 online,tempname
concat/concat1 5926338 online,tempname
slice/pebbless0 2963169 online
slice/bettys0 2963169 online |
The following sequence of commands reverses this insert operation by collapsing the mirror and displays the topology of the resulting logical volume:
xvm:cluster> collapse mirror/mirror2
xvm:cluster> show -top vol9
vol/vol9 0 online,tempname
subvol/vol9/data 5926338 online
concat/concat1 5926338 online,tempname
slice/pebbless0 2963169 online
slice/bettys0 2963169 online |
The show command display information about volume elements as well as physvols and unlabeled disks. This command includes an -extend option, which shows additional information about physvols, slices, and stripes. The command also includes a -verbose option, which displays as much information as possible about the indicated object.
For example:
To show name, size, and state information for the object named concat0:
xvm:cluster> show concat0
To show all XVM slices:
xvm:cluster> show slice/*
To show the names of all XVM volumes:
xvm:cluster> show -name vol/*
To show the names of all unlabeled disks:
xvm:cluster> show -name unlabeled/*
To show statistics for the physvol named fred :
xvm:cluster> show -stat phys/fred
To show the topology of the a volume and display the stripe unit size of the stripes in the volume as well as the name and device path of the physvols associated with any slices in the volume:
xvm:cluster> show -topology -extend volume
For example:
xvm:cluster> show -topology vol/drives0 subvol/drives0/data 111406464 online,reviving,accessible mirror/mirror0 111406464 online,tempname,reviving:1%,accessible concat/concat0 111406464 online,tempname,accessible slice/drives0 55703232 online,accessible slice/drives1 55703232 online,accessible stripe/stripe1 167109504 online,tempname,reviving,accessible slice/drives2 55703232 online,accessible slice/drives3 55703232 online,accessible slice/drives4 55703232 online,accessible
After the revive completes:
xvm:local> show -top vol/drives0 vol/drives0 0 online,accessible subvol/drives0/data 111406464 online,accessible mirror/mirror0 111406464 online,tempname,accessible concat/concat0 111406464 online,tempname,accessible slice/drives0 55703232 online,accessible slice/drives1 55703232 online,accessible stripe/stripe1 167109504 online,tempname,accessible slice/drives2 55703232 online,accessible slice/drives3 55703232 online,accessible slice/drives4 55703232 online,accessible
The dump command outputs XVM configuration commands that you can use to reconstruct volume elements and physvols.
| Note: You must explicitly dump the physvol separately from a volume element topology tree. |
For example:
To dump a one-line creation command for the volume named fred:
xvm:cluster> dump vol/fred volume -volname fred -uuid e5570d23-a491-4f03-9e4c-0a047ae100ff
To dump information for all volume elements under each volume:
xvm:cluster> dump -topology vol/*
To dump the contents of all physvol and volume topology trees to the file foo:
xvm:cluster> dump -topology -file foo phys/* vol/*
The delete command deletes a volume element. Parents of deleted volume elements remain and have open slots.
You cannot delete a volume element that is part of an open subvolume if doing so would cause the subvolume state to go offline. You can override this restriction with the -force option of the delete command.
If a volume element contains any attached children, it cannot be deleted. However, the delete command provides the following mutually exclusive options that override this restriction:
The -all option deletes a volume element and all volume elements below it
The -nonslice option deletes a volume element and all non-slice volume elements below it, detaching and keeping the slices
If a disk becomes inaccessible and must be replaced, you must tear down the existing configuration information for that disk. In this circumstance, you may not be able to execute standard XVM configuration commands on logical volumes that include that disk. To recover from this situation, you can use the reprobe command to remove previous configuration information from the kernel. The following example illustrates a situation where you can use the reprobe command. In this example, there is a volume configured with a mirror:
vol/test
mirror/mirror0
slice/lun9s0
slice/lun8s0 |
If lun8 begins to generate I/O errors, you may need to replace the disk. If you try to detach slice/lun8s0, however, the system will be unable to write the update to the disk and will not perform the detach. In this case, you can execute the following command:
xvm:cluster> reprobe lun8 |
This removes all the places where lun8 is used in a configuration, even though you cannot write to the lun8 physvol. After executing this command, you can attach a new slice to mirror/mirror0.
You can also use the reprobe command to recover from an inconsistent configuration that could arise when you use the steal command to take a disk from a running system. In this case, the disk label may not match the configuration information in the kernel and the configuration may show the disk as both owned and foreign. The reprobe command will remove the configuration information for the physvol from the kernel.
The reprobe command will remove configuration information for the indicated physvol only if the disk is inaccessible or if the configuration on the disk label does not match the current information in the kernel.
The following example removes the configuration information in the kernel for the XVM physvol named fred if fred is not available or if the configuration information in the disk label of fred does not match the configuration information in the kernel:
xvm:cluster> reprobe fred |