To start the GUI on IRIX, use one of the following methods:

To start the GUI on a system running SGI ProPack for Linux where the XVM GUI rpms and the Java J2SE 1.4.2 SDK software are installed, enter the following command line:

# /usr/bin/xvmgr

To use a Web-based version of the GUI on a PC or from a remote location via VPN or WAN, do the following:

The XVM Manager GUI runs in its own windows outside of your browser. If you launch the XVM Manager GUI from a web browser and exit your browser, all your XVM Manager GUI windows will exit as well.

To ensure that the required privileges are available for performing all of the tasks, you should log in to the GUI as root. However, some or all privileges can be granted to any other user by the system administrator using the GUI privilege tasks. (This functionality is also available with the Privilege Manager, part of the IRIX Interactive Desktop System Administration sysadmdesktop product. For more information, see the Personal System Administration Guide.)

After you start the XVM manager GUI, a dialog box appears prompting you to log in to a host.You can choose one of the following connection types:

Local runs the server-side process on the local host instead of going over the network.

Direct creates a direct socket connection using the tcpmux TCP protocol (tcpmux must be enabled).

Remote Shell connects to the server via a user-specified command shell, such as rsh(1C) or ssh(1). For example:

ssh -l root servername

---

Note: For secure connection, choose Remote Shell and type a secure connection command using a utility such as ssh(1). Otherwise, XVM Manager GUI will not encrypt communication and transferred passwords will be visible to users of the network.

---

Proxy connects to the server through a firewall via a proxy server.

---

Note: You should only make changes from one instance of the GUI running at any given time; changes made by a second GUI instance (a second invocation of xvmgr) may overwrite changes made by the first instance. However, multiple XVM Manager windows accessed via the File menu are all part of the same application process; you can make changes from any of these windows.

---

To reconfigure a logical volume, select a volume element icon, then drag the icon and drop it on another volume element icon. Icons turn blue as you drag to indicate when it is valid to drop upon them. When you drag, if the mouse cursor reaches the top or the bottom of the View area, the display will scroll automatically.

You can use drag-and-drop to operate on multiple volume elements of different types. For example, you can detach several types of volume elements by selecting items and dragging them to any Unattached heading, even if no selected item belongs to that category. You can select multiple items of different types and attach them to a parent. For example, you can select two concats and a stripe and use drag-and-drop to attach them to a parent concat.

You can rename volume elements by clicking a selected (highlighted) volume element and typing a new name into the resulting Name text field.

To label or unlabel disks using drag-and-drop, select Disks from the View menu. Select an unlabeled disk and then drag and drop it on the Labeled Disks heading, or select a labeled disk and then drag and drop it on the Unlabeled Disks heading.

You can rename a disk by clicking a selected (highlighted) disk and typing a name into the resulting Name text field.

You cannot use drag-and-drop in the following circumstances:

In order to create XVM logical volumes on a physical disk, you must label the disk as an XVM disk. Labeling a disk writes out an XVM physical volume label on a disk and allows the XVM Volume Manager to control the partitioning on the disk. In a CXFS cluster, any XVM physical volumes that will be shared must be physically connected to all cells in the cluster.

When you label a disk as an XVM physical volume, the first four bytes of logical block one, when represented as ASCII characters, yield xlab. This enables you to determine whether a disk is an XVM physical volume even if you are not running the XVM Volume Manager.

If you do not specify a name for the XVM disk, the default name will be the base name of the unlabeled disk path (e.g., dks0d1). If you specify a name when assigning multiple disks to XVM, the supplied name acts as a prefix for each physical volume name, with a unique numeric suffix added. If you do not specify a name when assigning multiple disks, the unlabeled disk path is used as the prefix for each physical volume name.

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. Use this feature with caution, as data corruption or system panics can result from labeling disks with partitions that are in use.

When you label an XVM disk, you can specify how much space to assign to the volume header; the default value is the number of blocks currently in the volume header of the disk being labeled. You can also specify how much space to assign to the XVM label area in the volume header; the default is 1024 blocks (usually leaving 3072 blocks in the volume header that are not part of the XVM label area).

The usual default values for the volume header size and label area size support approximately 5000 XVM objects; this should be sufficient for most XVM logical volume configurations. If you will have more than that many objects on the XVM physvol that the label area needs to maintain, you may need to increase the XVM label area size. As a rule of thumb, one block is required for every seven objects. Note that a volume element and a name for a volume element count as two objects.

Although the default size for the XVM label area should be sufficient for most XVM logical volume configurations, you can increase the XVM label area size by shrinking the volume header from the default value and increasing the XVM label area correspondingly. For example, the default options will give you 1024 blocks for the XVM label area and, usually, 3072 blocks for the volume header. The user data then starts at block 4096. If you set the number of volume header blocks to 2048 you can set the number of XVM label blocks to 2048. This will double the XVM label area, shrinking the volume header area from the default and leaving the user data starting at block 4096.

If you add a new disk that has already been labeled as an XVM physical volume to a running system, you must manually probe the disk with the XVM Volume Manager in order for the system to recognize the disk as an XVM disk. You do not have to do this when you are labeling a new XVM disk on your system, however, since the XVM Volume Manager probes the disk as part of the label process. All disks are probed when the system is booted to determine which disks are XVM disks.

---

Note: Before you can label a disk as an XVM disk, it must be formatted as an IRIX disk. If your disk has not been initialized during factory set-up, use the fx(1M) command to initialize the disk.

---

---

Note: When an unlabeled-disk is given to XVM to manage, it is repartitioned so that the raw disk may no longer be directly used for disk I/O. In general, only the volume header and volume partitions remain available. The original partitioning information is saved to a file in the volume header directory under the name backvh. This information is restored when the disk is unlabeled.

---

To label a disk as an XVM disk, do the following:

Slicing a disk creates a slice from a block range of an XVM physical volume. You can specify the starting block of a slice and you can specify the length of a slice. In addition, you can specify the following methods of creating slices:

Slices are named automatically and are persistent across machine reboots. You cannot rename slices.

If a slice length is not supplied, the address range will be from the indicated start block to the end of the free area containing the start block.

When volume elements other than volumes are created, the system automatically creates a volume and a subvolume that are associated with the volume element. When you create a volume element, you can explicitly name this generated volume, in which case the volume name is stored in label space and persists across machine reboots.

To create slices on an XVM disk, do the following:

You can rename a physical volume. The name you give a physical volume is persistent across reboots.

To rename an XVM disk with the GUI, do the following:

To remove an XVM physical volume from a system, you remove the XVM label from the physical volume. After a disk is unlabeled, the original partitioning information is restored from a file saved in the volume header directory under the name backvh.

In a clustered environment, you cannot unlabel a disk that is not attached to the system you are working from.

You cannot unlabel disks containing slices unless you also delete the slices on those physical volumes. When you indicate that you are deleting all slices on the disk, the slices are deleted even if the slice is part of an open subvolume and its deletion will cause the subvolume state to go offline. If any of the attempts to delete a slice on a disk fails when you are unlabeling a disk, the unlabel will fail. If all deletes succeed, the physical volume will be unlabeled.

To remove XVM labels from one or more disks with the GUI, do the following:

Statistics collection for an XVM physical volume may be set to on or off. You can change the state of statistics collection on a disk, and you can reset the current statistics to 0.

Statistics for physical volumes show the number of read and write operations as well as the number of 512-byte blocks read and written.

In a clustered environment, statistics are maintained for the local cell only.

To modify statistics collection on one or more disks with the GUI, do the following:

You change the domain of an XVM physical volume by giving ownership of that physical volume to another machine or cluster.

You cannot give away ownership of a physical volume that has slices that are part of open subvolumes. For this reason, an attempt to give away a disk will fail while a mirror revive is active. In general, you must unmount filesystems on XVM logical volumes that contain the XVM physvol and wait for mirror revives to complete before giving away a physical volume.

Giving a disk away will result in all slices on the disk (and any empty parents that result) being deleted on the current host, as well as the physical volume. The configuration information will be retained on the disk. Subvolumes that span disks might go offline if giving a disk away will cause slices belonging to that physvol to be removed.

When you give a disk away, the new owning node or cluster must read the disk before the configuration is visible to the new owner. This happens in either of two ways: automatically on reboot, or when the new owner probes the new disk.

You can specify a physical volume to give away by either the name of the physical volume name or by the name of the disk itself.

To give away ownership of one or more disks to another host or cluster, do the following:

This task is valid in a clustered environment only.

In some circumstances, the node or cluster that currently owns the physical volume may be unable to give a disk away. In these cases, you can steal a disk to change the domain of an XVM physical volume. Only disks which are foreign to the current node or cluster can be the targets of a steal.

---

Caution: Stealing a disk unconditionally resets the owner of an XVM physical volume to the current node or cluster. No attempt is made to inform the previous owner of the change in ownership. If another host or cluster has the XVM physvol instantiated, this could result in configuration corruption. You should steal a disk only when ownership cannot be changed by giving the disk away. In a situation where you need to steal a disk to change the domain of an XVM physical volume, you may not know the name of the current owner of the physical volume.

---

You cannot use steal a physical volume that has slices that are part of open subvolumes. In general, you must unmount filesystems on XVM logical volumes that contain the XVM physvol and wait for mirror revives to complete before stealing the XVM physvol.

To take control of a foreign disk with the GUI, do the following:

This task is valid in a clustered environment only.

If you add a new disk that has already been labeled as an XVM physical volume to a running system, you must manually probe the disk in order for the system to recognize the disk as an XVM disk. You do not have to do this when you are labeling a new XVM disk on your system, however, since the XVM Volume Manager probes the disk as part of the label process.

It is assumed that the disk to be probed is available in the hardware inventory (the controller that it is connected to has been probed outside of XVM).

If the disk being probed has not been previously labeled by XVM, an error is returned.

To probe one or more disks for XVM label information with the GUI, do the following:

You can dump configuration information for an individual volume element, or you can dump the configuration information for all of the volume elements under the volume element you specify. You can also use dump configuration commands for a physical volume; you must explicitly dump the physical volume separately from a volume element tree. Dumping configuration information allows you to replace a disk in a running system and to regenerate the XVM configuration on the new disk without rebooting the system.

When you dump and regenerate a device, you do not regenerate the data on the disk you are replacing, but rather you regenerate the XVM configuration on the new disk.

When you dump a volume element, a new uuid is generated for the object being dumped in order to avoid any possible name collision issues when the object is later re-created.

To dump the XVM configuration commands of one or more volume elements and disks to a file, do the following:

A concat is a volume element that concatenates all of its child volume elements into one address space.

When volume elements other than volumes are created, the system automatically creates a volume and a subvolume that are associated with the volume element. When you create a volume element, you can explicitly name this generated volume, in which case the volume name is stored in label space and persists across machine reboots.

To create a concat, do the following:

A mirror is a volume element that mirrors all of its child volume elements. A mirror cannot have more than eight members.

---

Note: To use the mirroring feature of the XVM Volume Manager, you must purchase and install the appropriate FLEXlm license on IRIX or LK license on SGI ProPack 6 for Linux. For more information on LK, see the SGI ProPack 6 for Linux Service Pack 4 Start Here.

---

When you create a mirror that has more than one piece, the mirror begins the reviving process; This means that the system is begins the process of mirroring the data, synchronizing the data in each of the legs.

For large mirror components, this revive process may take a long time. When you are creating a new mirror that does not need to be revived, you should consider specifying that the mirror does not need to revive on creation.

When you are creating a new mirror that you will use for scratch filesystems such as /tmp or swap that will never need to be revived, you should consider specifying that the mirror will never revive.

You cannot halt a mirror revive once it has begun except by detaching all but one of the pieces of the mirror.

The XVM Volume Manager allows you to specify one of the following read policies for a mirror:

Balance the I/O load among the members of the mirror, blindly reading in a round-robin fashion.

You can specify whether a particular leg of a mirror is to be preferred for reading by marking it as a primary leg.

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.

When volume elements other than volumes are created, the system automatically creates a volume and a subvolume that are associated with the volume element. When you create a volume element, you can explicitly name this generated volume, in which case the volume name is stored in label space and persists across machine reboots.

To create a mirror, do the following:

A stripe is a volume element that stripes a set of volume elements across an address space.

You can create a stripe that is made up of volume elements of unequal size, although this will leave unused space on the larger volume elements.

The actual size of the stripe volume element depends on the stripe unit size and the size of 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, since the same amount of space in each volume element that makes up the slice is used.

The general formula for determining what the stripe size will be is the following, where stripe_width is the number of volume elements that make up the stripe:

stripe_size = (smallest_stripe_member / stripe_unit) * stripe_unit * stripe_width

Note that this formula uses integer arithmetic.

If your XVM configuration requires that you spread I/O across controllers, you must have a complete failover.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 failover.conf file to specify a primary path.

For information on configuration of failover for storage devices, see your SGI support provider. Information on the failover.conf file can also be found on the failover(7M) man page and in the /etc/failover.conf file itself.

When volume elements other than volumes are created, the system automatically creates a volume and a subvolume that are associated with the volume element. When you create a volume element, you can explicitly name this generated volume, in which case the volume name is stored in label space and persists across machine reboots.

To create a stripe, do the following:

When you delete volume elements, parents of deleted volume elements remain and have open slots.

If a volume element you delete is part of an open subvolume, its deletion cannot cause the subvolume state to go offline.

If a volume element contains any attached children, it cannot be deleted. However, the Delete a Volume Elements task provides two options that override this restriction: You delete the volume element and all volume elements below it, or you delete a volume element and all non-slice volume elements below it, detaching and keeping the slices.

If a slice is mapped to a partition, the underlying partition will be removed from the partition table.

To delete one or more volume elements, do the following:

You can rename an volume element. The name you give an object when you explicitly rename it remains persistent across reboots. You cannot change the name of a slice.

To rename a volume element, do the following:

You can insert a mirror or a concat volume element above another volume element. You cannot insert a volume element above a volume or a subvolume.

You can grow a volume element on a running system by inserting a concat and you can 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.

To insert a new mirror or concat above an existing volume element, do the following:

You can remove an unneeded mirror or concat from an XVM tree if the mirror or concat has only one child. This task links the child to the parent of the mirror or concat that you remove.

You can remove a mirror or concat in an open subvolume. Generally, you perform this task during configuration to reverse a previous insert operation.

To remove mirrors and concats with only one child, do the following:

When a volume element is disabled no I/O will be issued to it until you explicitly enable it.

To enable one or more volume elements that have been disabled, do the following:

When a volume element is disabled no I/O will be issued to it until explicitly enable the volume element. An object remains disabled across machine reboots.

To disable one or more volume elements, do the following:

A volume element is online when it is properly configured. It is able to be opened, or it is already open.

The system kernel may disable a volume element and take that element offline. This could happen, for example, when a mirror member shows an I/O error.

To bring a set of volume elements online, do the following:

The XVM snapshot feature provides the ability to create virtual point-in-time images of a filesystem without causing a service interruption. The snapshot feature requires a minimal amount of storage because it uses a copy-on-write mechanism that copies only the data areas that change after the snapshot is created.

Snapshot copies of a filesystem are virtual copies, not actual media backup for a filesystem. You can, however, use a snapshot copy of a filesystem to create a backup dump of a filesystem, allowing you to continue to use and modify the filesystem while the backup runs.

You can also use a snapshot copy of a filesystem to provide a recovery mechanism in the event of data loss due to user errors such as accidental deletion. A full filesystem backup, however, is necessary in order to protect against data loss due to media failure.

Snapshot filesystems are supported for read access only.

---

Note: Use of the snapshot feature of the XVM Volume Manager requires a FLEXlm license on IRIX or LK license on SGI ProPack 6 for Linux. For more information on LK, see the SGI ProPack 6 for Linux Service Pack 4 Start Here.

---

Before creating a snapshot, you must create an XVM volume to use as a snapshot repository, in which original copies of regions of data that have changed on the filesystem are stored. The snapshot repository may be used for more than one base volume in the same domain.

As long as a base volume has at least one snapshot, all snapshots of that volume will use the same repository.

When you create a snapshot, XVM creates a snapshot volume, which is a virtual volume containing the regions that have changed in the base filesystem volume since the snapshot was created.

To create a snapshot of an existing volume, do the following:

The repository will be initialized, if necessary, and a new snapshot will be created for each of the selected base volumes. For the volume vol/foo, the first snapshot will be named vol/foo%0, the second will be vol/foo%1, and so on.

You can increase the size of an existing snapshot repository. It is very important that the size of the repository be increased before it fills up, since any snapshot using the repository will become inconsistent and therefore invalid if a region can't be written.

Growing a snapshot repository is similar to growing a mounted filesystem. First, the size of the repository volume must be increased. You can do this by adding slices to existing concats in the repository volume; if necessary, you can use the Insert Mirrors or Concats above Volume Elements task to insert new concats into the repository volume's structure.

Once additional space has been provided, use the Grow Snapshot Repositories task to cause the repository to grow into the additional space.

To grow snapshot repositories, do the following:

This will cause each of the selected snapshot repositories to make use of all the available space in its volume.

When you remake a volume element, you collapse holes in the volume element. The child volume elements remain in their current order.

To remake a volume element, do the following:

You can detach volume elements from their parents.

If a volume element you detach is part of an open subvolume, its detachment cannot cause the subvolume state to go offline. Any command that would reduce the address space of an open subvolume, such as detaching a slice that is not mirrored, will cause it to go offline. You cannot detach the last valid piece of an open mirror from that mirror, since this will cause the mirror to go offline.

To detach volume elements, do the following:

When you create a volume, you can specify subvolumes to attach to the volume after it is created.

A volume cannot have more than one system-defined subvolume of a given type. The system-defined subvolumes are data subvolumes, log subvolumes, and real-time subvolumes.

To create a volume, do the following:

When you create a subvolume you can optionally attach a specified volume element to the subvolume. The volume element attached to the subvolume cannot be a volume or another subvolume.

You can create a subvolume of a system-defined type of data, log, or real-time (rt), or you can create a subvolume of a user-defined type.

There cannot be more than one subvolume having the same system-defined type under a volume. For example, there can be only one data subvolume under a volume. There is no such restriction for the user-defined subvolume types.

A user-defined subvolume type is in the range 16 through 255 (0 through 15 are reserved for system-defined types). User-defined subvolume types are used to associate an application-dependent type with a subvolume. Subvolume types in the user-defined range are not interpreted in any way by the system. You can specify more than one subvolume of a specific user-defined type under a volume.

When you create a subvolume, you specify the user-id (uid) of the subvolume owner (default 0), the group-id of the subvolume owner (default 0), and the mode of the subvolume (default is 0644).

If you do not specify a child volume element, an empty subvolume is created, which can be attached to later.

 When volume elements other than volumes are created, the system automatically creates a volume and a subvolume that are associated with the volume element. When you create a volume element, you can explicitly name this generated volume, in which case the volume name is stored in label space and persists across machine reboots.

To create a subvolume, do the following:

When you create a subvolume, you specify the user-id (uid) of the subvolume owner (default 0), the group-id of the subvolume owner (default 0), and the mode of the subvolume (default is 0644). You can change these parameters when you modify a subvolume.

To change the parameters of one or more subvolumes, do the following:

Statistics collection for a subvolume, stripe, concat, mirror, or slice may be set to on or off. You can change the state of statistics collection on a volume, and you can reset the current statistics on a volume element to 0. Statistics are collected only for the volume element layer you specify. If you want to collect statistics for more than one layer of an XVM logical volume, you must specify each layer explicitly.

Statistics for volume elements show the number of read and write operations as well as the number of 512-byte blocks read and written.

In a clustered environment, statistics are maintained for the local cell only.

To modify statistics collection on one or more volume elements, do the following:

This task lets you create a filesystem on a volume that is online but not open. To create filesystems on multiple volume elements, use the Browse button.

---

Caution: Clicking OK will erase all data that exists on the target volume.

---

To make a filesystem, do the following:

This task lets you grow a mounted filesystem.

---

Note: Before you can grow a filesystem, you must first increase the size of the logical volume on which the filesystem is mounted. You can launch the Insert Mirrors or Concats above Volume Elements task to add a concat, or you can use the drag-and-drop mechanism to attach a slice to an existing concat. You cannot add a slice to an existing volume element if this changes the way that the data is laid out in that volume element or in any ancestor of that volume element.

---

To grow a filesystem, do the following:

This task lets you mount a filesystem only on the node to which the GUI is connected (the local node).

To mount a filesystem locally, do the following:

For more information, see the mount(1M) man page.

To unmount a filesystem from the local node, do the following:

This task lets you delete a local filesystem's mount information in /etc/fstab.

---

Note: The filesystem will still be present on the volume.

---

Do the following:

You can grant access to a specific task to one or more users at a time.

Do the following:

Click Next to move to the next page.

To see which tasks a specific user can access, select View: Users. Select a specific user to see details about the tasks available to that user.

To see which users can access a specific task, select View: Task Privileges. Select a specific task to see details about the users who can access it and the privileged commands it requires.

You can revoke task access from one or more users at a time.

Do the following:

To see which tasks a specific user can access, select View: Users. Select a specific user to see details about the tasks available to that user.

To see which users can access a specific task, select View: Task Privileges. Select a specific task to see details about the users who can access it.