EVMS lets you manage storage space in a way that is more intuitive and flexible than many other Linux volume management systems. Practical tasks, such as migrating disks or adding new disks to your Linux system, become more manageable with EVMS because EVMS can recognize and read from different volume types and file systems. EVMS provides additional safety controls by not allowing commands that are unsafe. These controls help maintain the integrity of the data stored on the system.

You can use EVMS to create and manage data storage. With EVMS, you can use multiple volume management technologies under one framework while ensuring your system still interacts correctly with stored data. With EVMS, you are can use drive linking, shrink and expand volumes, create snapshots of your volumes, and set up RAID (redundant array of independent devices) features for your system. You can also use many types of file systems and manipulate these storage pieces in ways that best meet the needs of your particular work environment.

EVMS also provides the capability to manage data on storage that is physically shared by nodes in a cluster. This shared storage allows data to be highly available from different nodes in the cluster.

There are currently three user interfaces available for EVMS: graphical (GUI), text mode (Ncurses), and the Command Line Interpreter (CLI). Additionally, you can use the EVMS Application Programming Interface to implement your own customized user interface.

Table 1.1 tells more about each of the EVMS user interfaces.

To avoid confusion with other terms that describe volume management in general, EVMS uses a specific set of terms. These terms are listed, from most fundamental to most comprehensive, as follows:

There are numerous drivers in the Linux kernel, such as Device Mapper and MD (software RAID), that implement volume management schemes. EVMS is built on top of these drivers to provide one framework for combining and accessing the capabilities.

The EVMS Engine handles the creation, configuration, and management of volumes, segments, and disks. The EVMS Engine is a programmatic interface to the EVMS system. User interfaces and programs that use EVMS must go through the Engine.

EVMS provides the capacity for plug-in modules to the Engine that allow EVMS to perform specialized tasks without altering the core code. These plug-in modules allow EVMS to be more extensible and customizable than other volume management systems.

EVMS defines a layered architecture where plug-ins in each layer create abstractions of the layer or layers below. EVMS also allows most plug-ins to create abstractions of objects within the same layer. The following list defines these layers from the bottom up.

The EVMS GUI is a flexible and easy-to-use interface for administering volumes and storage objects. Many users find the EVMS GUI easy to use because it displays which storage objects, actions, and plug-ins are acceptable for a particular task.

The EVMS Ncurses (evmsn) user interface is a menu-driven interface with characteristics similar to those of the EVMS GUI. Like the EVMS GUI, evmsn can accommodate new plug-ins and features without requiring any code changes.

The EVMS Ncurses user interface allows you to manage volumes on systems that do not have the X and GTK+ libraries that are required by the EVMS GUI.

The EVMS Command Line Interpreter (EVMS CLI) provides a command-driven user interface for EVMS. The EVMS CLI helps automate volume management tasks and provides an interactive mode in situations where the EVMS GUI is not available.

Because the EVMS CLI is an interpreter, it operates differently than command line utilities for the operating system. The options you specify on the EVMS CLI command line to invoke the EVMS CLI control how the EVMS CLI operates. For example, the command line options tell the CLI where to go for commands to interpret and how often the EVMS CLI must save changes to disk. When invoked, the EVMS CLI prompts for commands.

The volume management commands the EVMS CLI understands are specified in the /usr/src/evms-x.y.z/engine2/ui/cli/grammar.txt file that accompanies the EVMS package. These commands are described in detail in the EVMS man page, and help on these commands is available from within the EVMS CLI.

"This is a name containing ""embedded"" quote marks."

/* This is a comment */
Create:Vo/*This is a silly place for a comment, but it is
allowed.*/lume,"lvm/Sample Container/My LVM
Volume",compatibility

The EVMS Engine creates a log file called /var/log/evmsEngine.log every time the Engine is opened. The Engine also saves copies of up to nine previous Engine sessions in the files /var/log/evmsEngine.n.log, where n is the number of the session between 1 and 9.

There are several possible logging levels that you can choose to be collected in /var/log/evmsEngine.log. The "lowest" logging level, critical, collects only messages about serious system problems, whereas the "highest" level, everything, collects all logging related messages. When you specify a particular logging level, the Engine collects messages for that level and all the levels below it.

The following table lists the allowable log levels and the information they provide:

By default, when any of the EVMS interfaces is opened, the Engine logs the Default level of messages into the /var/log/evmsEngine.log file. However, if your system is having problems and you want to see more of what is happening, you can change the logging level to be higher; if you want fewer logging messages, you can change the logging level to be lower. To change the logging level, specify the -d parameter and the log level on the interface open call. The following examples show how to open the various interfaces with the highest logging level (everything):

GUI:		evmsgui -d everything

Ncurses:	evmsn -d everything

CLI:		evms -d everything

The EVMS GUI lets you change the logging level during an Engine session. To do so, follow these steps:

The CLI command, probe, opens and closes the Engine, which causes a new log to start. The log that existed before the probe command was issued is renamed /var/log/evmsEngine.1.log and the new log is named /var/log/evmsEngine.log.

If you will be frequently using a different log level than the default, you can specify the default logging level in /etc/evms.conf rather than having to use the -d option when starting the user interface. The "debug_level" option in the "engine" section sets the default logging level for when the Engine is opened. Using the -d option during the command invocation overrides the setting in /etc/evms.conf.

If you are using the EVMS GUI as your preferred interface, you can view your migrated volumes by typing evmsgui at the command prompt. The following window opens, listing your migrated volumes.

Figure 4.1. GUI start-up window

If you are using the Ncurses interface, you can view your migrated volumes by typing evmsn at the command prompt. The following window opens, listing your migrated volumes.

Figure 4.2. Ncurses start-up window

If you are using the Command Line Interpreter (CLI) interface, you can view your migrated volumes by following these steps:

Figure 4.3. CLI volume query results

With the EVMS GUI, it is only possible to display additional details on an object through the Context Sensitive Menus, as shown in the following steps:

Follow these steps to display additional details on an object with Ncurses:

Use the query command (abbreviated q) with filters to display details about EVMS objects. There are two filters that are especially helpful for navigating within the command line: list options (abbreviated lo) and extended info (abbreviated ei).

The list options command tells you what can currently be done and what options you can specify. To use this command, first build a traditional query command starting with the command name query, followed by a colon (:), and then the type of object you want to query (for example, volumes, objects, plug-ins). Then, you can use filters to narrow the search to only the area you are interested in. For example, to determine the acceptable actions at the current time on lvm/Sample Container/Sample Region, enter the following command:

query: regions, region="lvm/Sample Container/Sample Region", list options

The extended info filter is the equivalent of Display Details in the EVMS GUI and Ncurses interfaces. The command takes the following form: query, followed by a colon (:), the filter (extended info), a comma (,), and the object you want more information about. The command returns a list containing the field names, titles, descriptions and values for each field defined for the object. For example, to obtain details on lvm/Sample Container/Sample Region, enter the following command:

query: extended info, "lvm/Sample Container/Sample Region"

Many of the field names that are returned by the extended info filter can be expanded further by specifying the field name or names at the end of the command, separated by commas. For example, if you wanted additional information about logical extents, the query would look like the following:

query: extended info, "lvm/Sample Container/Sample Region", Extents

Adding a segment manager to a disk allows the disk to be subdivided into smaller storage objects called disk segments. The add command causes a segment manager to create appropriate metadata and expose freespace that the segment manager finds on the disk. You need to add segment managers when you have a new disk or when you are switching from one partitioning scheme to another.

EVMS displays disk segments as the following types:

There are seven types of segment managers in EVMS: DOS, GPT, S/390, Cluster, BSD, MAC, and BBR.

When you add a segment manager to a disk, the segment manager needs to change the basic layout of the disk. This change means that some sectors are reserved for metadata and the remaining sectors are made available for creating data disk segments. Metadata sectors are written to disk to save information needed by the segment manager; previous information found on the disk is lost. Before adding a segment manager to an existing disk, you must remove any existing volume management structures, including any previous segment manager.

When a new disk is added to a system, the disk usually contains no data and has not been partitioned. If this is the case, the disk shows up in EVMS as a compatibility volume because EVMS cannot tell if the disk is being used as a volume. To add a segment manager to the disk so that it can be subdivided into smaller disk segment objects, tell EVMS that the disk is not a compatibility volume by deleting the volume information.

If the new disk was moved from another system, chances are good that the disk already contains metadata. If the disk does contain metadata, the disk shows up in EVMS with storage objects that were produced from the existing metadata. Deleting these objects will allow you to add a different segment manager to the disk, and you lose any old data.

This section shows how to add a segment manager with EVMS.

EVMS initially displays the physical disks it sees as volumes. Assume that you have added a new disk to the system that EVMS sees as sde. This disk contains no data and has not been subdivided (no partitions). EVMS assumes that this disk is a compatibility volume known as /dev/evms/sde.

Example 6.1. Add the DOS Segment Manager

Add the DOS Segment Manager to disk sde.

Delete:/dev/evms/sde

Add:DosSegMgr={},sde

When a segment manager is removed from a disk, the disk can be reused by other plug-ins. The remove command causes the segment manager to remove its partition or slice table from the disk, leaving the raw disk storage object that then becomes an available EVMS storage object. As an available storage object, the disk is free to be used by any plug-in when storage objects are created or expanded. You can also add any of the segment managers to the available disk storage object to subdivide the disk into segments.

Most segment manager plug-ins check to determine if any of the segments are still in use by other plug-ins or are still part of volumes. If a segment manager determines that there are no disks from which it can safely remove itself, it will not be listed when you use the remove command. In this case, you should delete the volume or storage object that is consuming segments from the disk you want to reuse.

This section shows how to remove a segment manager with EVMS.

Example 6.2. Remove the DOS Segment Manager

Remove the DOS Segment Manager from disk sda.

Delete:/dev/evms/sda1

Remove: sda

A disk can be subdivided into smaller storage objects called disk segments. A segment manager plug-in provides this capability. Another reason for creating disk segments is to maintain compatibility on a dual boot system where the other operating system requires disk partitions. Before creating a disk segment, you must choose a segment manager plug-in to manage the disk and assign the segment manager to the disk. An explanation of when and how to assign segment managers can be found in Chapter 6. "Adding and removing a segment manager".

This section provides a detailed explanation of how to create a segment with EVMS by providing instructions to help you complete the following task:

Example 7.1. Create a 100MB segment

Create a 100MB segment from the freespace segment sde_freespace1. This freespace segment lies on a drive controlled by the DOS Segment Manager.

Create: Segment,sde_freespace1, size=100MB

query:plugins,plugin=DosSegMgr,list options

Segments and disks can be combined to form a container. Containers allow you to combine storage objects and then subdivide those combined storage objects into new storage objects. You can combine storage objects to implement the volume group concept as found in the AIX and Linux logical volume managers.

Containers are the beginning of more flexible volume management. You might want to create a container in order to account for flexibility in your future storage needs. For example, you might need to add additional disks when your applications or users need more storage.

This section provides a detailed explanation of how to create a container with EVMS by providing instructions to help you complete the following task.

Example 8.1. Create "Sample Container"

Given a system with three available disk drives (sdc, sdd, hdc), use the EVMS LVM Region Manager to combine these disk drives into a container called "Sample Container" with a PE size of 16 MB.

Create:Container,LvmRegMgr={name="Sample Container",pe_size=16MB},sdc,sdd,hdc

query:plugins,plugin=LvmRegMgr,list options

You can create regions because you want the features provided by a certain region manager or because you want the features provided by that region manager. You can also create regions to be compatible with other volume management technologies, such as MD or LVM. For example, if you wanted to make a volume that is compatible with Linux LVM, you would create a region out of a Linux LVM container and then a compatibility volume from that region.

This section tells how to create a region with EVMS by providing instructions to help you complete the following task.

Example 9.1. Create "Sample Region"

Given the container "Sample Container," which has a freespace region of 8799 MB, create a data region 1000 MB in size named "Sample Region."

Create:region, LvmRegMgr={name="Sample Region", size=1000MB},
"lvm/Sample Container/Freespace"

query:plugins,plugin=LvmRegMgr,list options

Drive linking linearly concatenates objects, allowing you to create larger storage objects and volumes from smaller individual pieces. For example, say you need a 1 GB volume but do not have contiguous space available of that length. Drive linking lets you link two or more objects together to form the 1 GB volume.

The types of objects that can be drive linked include disks, segments, regions, and other feature objects.

Any resizing of an existing drive link, whether to grow it or shrink it, must be coordinated with the appropriate file system operations. EVMS handles these file system operations automatically.

Because drive linking is an EVMS-specific feature that contains EVMS metadata, it is not backward compatible with other volume-management schemes.

The drive link plug-in consumes storage objects, called link objects, which produce a larger drive link object whose address space spans the link objects. The drive link plug-in knows how to assemble the link objects so as to create the exact same address space every time. The information required to do this is kept on each link child as persistent drive-link metadata. During discovery, the drive link plug-in inspects each known storage object for this metadata. The presence of this metadata identifies the storage object as a link object. The information contained in the metadata is sufficient to:

If any link objects are missing at the conclusion of the discovery process, the drive link storage object contains gaps where the missing link objects occur. In such cases, the drive link plug-in attempts to fill in the gap with a substitute link object and construct the drive link storage object in read-only mode, which allows for recovery action. The missing object might reside on removable storage that has been removed or perhaps a lower layer plug-in failed to produce the missing object. Whatever the reason, a read-only drive link storage object, together logging errors, help you take the appropriate actions to recover the drive link.

The drive link plug-in provides a list of acceptable objects from which it can create a drive-link object. When you create an EVMS storage object and then choose the drive link plug-in, a list of acceptable objects is provided that you can choose from. The ordering of the drive link is implied by the order in which you pick objects from the provided list. After you provide a name for the new drive-link object, the identified link objects are consumed and the new drive-link object is produced. The name for the new object is the only option when creating a drive-link.

Only the last object in a drive link can be expanded, shrunk or removed. Additionally, a new object can be added to the end of an existing drive link only if the file system (if one exists) permits. Any resizing of a drive link, whether to grow it or shrink it, must be coordinated with the appropriate file system operations. EVMS handles these file system operations automatically.

This section shows how to create a drive link with EVMS:

Example 10.1. Create a drive link

Create a new drive link consisting of sde4 and hdc2, and call it "dl."

query: plugins, plugin=DriveLink, list options

create: object, DriveLink={Name=dl}, sde4, hdc2

A drive link is an aggregating storage object that is built by combining a number of storage objects into a larger resulting object. A drive link consumes link objects in order to produce a larger storage object. The ordering of the link objects as well as the number of sectors they each contribute is described by drive link metadata. The metadata allows the drive link plug-in to recreate the drive link, spanning the link objects in a consistent manner. Allowing any of these link objects to expand would corrupt the size and ordering of link objects; the ordering of link objects is vital to the correct operation of the drive link. However, expanding a drive link can be controlled by only allowing sectors to be added at the end of the drive link storage object. This does not disturb the ordering of link objects in any manner and, because sectors are only added at the end of the drive link, existing sectors have the same address (logical sector number) as before the expansion. Therefore, a drive link can be expanded by adding additional sectors in two different ways:

If the expansion point is the drive link storage object, you can perform the expansion by adding an additional storage object to the drive link. This is done by choosing from a list of acceptable objects during the expand operation. Multiple objects can be selected and added to the drive link.

If the expansion point is the last storage object in the drive link, then you expand the drive link by interacting with the plug-in that produced the object. For example, if the link was a segment, then the segment manager plug-in that produced the storage object expands the link object. Afterwords, the drive link plug-in notices the size difference and updates the drive link metadata to reflect the resize of the child object.

There are no expand options.

Shrinking a drive link has the same restrictions as expanding a drive link. A drive link object can only be shrunk by removing sectors from the end of the drive link. This can be done in the following ways:

The drive link plug-in attempts to orchestrate the shrinking of a drive-link storage object by only listing the last link object. If you select this object, the drive link plug-in then lists the next-to-last link object, and so forth, moving backward through the link objects to satisfy the shrink command.

If the shrink point is the last storage object in the drive link, then you shrink the drive link by interacting with the plug-in that produced the object.

There are no shrink options.

A drive link can be deleted as long as it is not currently a compatibility volume, an EVMS volume, or consumed by another EVMS plug-in.

No options are available for deleting a drive link storage object.

A snapshot represents a frozen image of a volume. The source of a snapshot is called an "original." When a snapshot is created, it looks exactly like the original at that point in time. As changes are made to the original, the snapshot remains the same and looks exactly like the original at the time the snapshot was created.

Snapshotting allows you to keep a volume online while a backup is created. This method is much more convenient than a data backup where a volume must be taken offline to perform a consistent backup. When snapshotting, a snapshot of the volume is created and the backup is taken from the snapshot, while the original remains in active use.

You can create a snapshot object from any unused storage object in EVMS (disks, segments, regions, or feature objects). The size of this consumed object is the size available to the snapshot object. The snapshot object can be smaller or larger than the original volume. If the object is smaller, the snapshot volume could fill up as data is copied from the original to the snapshot, given sufficient activity on the original. In this situation, the snapshot is deactivated and additional I/O to the snapshot fails.

Base the size of the snapshot object on the amount of activity that is likely to take place on the original during the lifetime of the snapshot. The more changes that occur on the original and the longer the snapshot is expected to remain active, the larger the snapshot object should be. Clearly, determining this calculation is not simple and requires trial and error to determine the correct snapshot object size to use for a particular situation. The goal is to create a snapshot object large enough to prevent the shapshot from being deactivated if it fills up, yet small enough to not waste disk space. If the snapshot object is the same size as the original volume, or a little larger, to account for the snapshot mapping tables, the snapshot is never deactivated.

After you've created the snapshot object and saved the changes, the snapshot will be activated (as long as the snapshot child object is already active). This is a change from snapshots in EVMS 2.3.x and earlier, where the snapshot would not be activated until the object was made into an EVMS volume. If you wish to have an inactive snapshot, please add the name of the snapshot object to the "activate.exclude" line in the EVMS configuration file (see section about selective-activation for more details). If at any point you decide to deactivate a snapshot object while the original volume is still active, the snapshot will be reset. The next time that the snapshot object is activated, it will reflect the state of the original volume at that point in time, just as if the snapshot had just been created.

In order to mount the snapshot, the snapshot object must still be made into an EVMS volume. The name of this volume can be the same as or different than the name of the snapshot object.

This section shows how to create a snapshot with EVMS:

Example 11.1. Create a snapshot of a volume

Create a new snapshot of /dev/evms/vol on lvm/Sample Container/Sample Region, and call it "snap."

query: plugins, plugin=Snapshot, list options

create: object, Snapshot={original=/dev/evms/vol, snapshot=snap}, 
"lvm/Sample Container/Sample Region"

Snapshots can be reinitialized. Reinitializing causes all of the saved data to be erased and starts the snapshot from the current point in time. A reinitialized snapshot has the same original, chunk size, and writeable flags as the original snapshot.

To reinitialize a snapshot, use the Reset command on the snapshot object (not the snapshot volume). This command reinitializes the snapshot without requiring you to manually deactivate and reactivate the volume. The snapshot must be active but unmounted for it to be reinitialized.

This section continues the example from the previous section, where a snapshot object and volume were created. The snapshot object is called "snap" and the volume is called "/dev/evms/snap."

As mentioned in Section 11.2, "Creating snapshot objects", as data is copied from the original volume to the snapshot, the space available for the snapshot might fill up, causing the snapshot to be invalidated. This situation might cause your data backup to end prematurely, as the snapshot volume begins returning I/O errors after it is invalidated.

To solve this problem, EVMS now has the ability to expand the storage space for a snapshot object while the snapshot volume is active and mounted. This feature allows you to initially create a small snapshot object and expand the object as necessary as the space begins to fill up.

In order to expand the snapshot object, the underlying object must be expandable. Continuing the example from the previous sections, the object "snap" is built on the LVM region lvm/Sample Container/Sample Region. When we refer to expanding the "snap" object, the region lvm/Sample Container/Sample Region is the object that actually gets expanded, and the object "snap" simply makes use of the new space on that region. Thus, to have expandable snapshots, you will usually want to build your snapshot objects on top of LVM regions that have extra freespace available in their LVM container. DriveLink objects and some disk segments also work in certain situations.

One notable quirk about expanding snapshots is that the snapshot object and volume do not actually appear to expand after the operation is complete. Because the snapshot volume is supposed to be a frozen image of the original volume, the snapshot volume always has the same size as the original, even if the snapshot has been expanded. However, you can verify that the snapshot object is using the additional space by displaying the details for the snapshot object and comparing the percent-full field before and after the expand operation.

query:region,region="lvm/Sample Container/Sample Region",lo

expand:"lvm/Sample Container/Sample Region", add_size=100MB

When a snapshot is no longer needed, you can remove it by deleting the EVMS volume from the snapshot object, and then deleting the snapshot object. Because the snapshot saved the initial state of the original volume (and not the changed state), the original is always up-to-date and does not need any modifications when a snapshot is deleted.

No options are available for deleting snapshots.

Situations can arise where a user wants to restore the original volume to the saved state of the snapshot. This action is called a rollback. One such scenario is if the data on the original is lost or corrupted. Snapshot rollback acts as a quick backup and restore mechanism, and allows the user to avoid a more lengthy restore operation from tapes or other archives.

Another situation where rollback can be particularly useful is when you are testing new software. Before you install a new software package, create a writeable snapshot of the target volume. You can then install the software to the snapshot volume, instead of to the original, and then test and verify the new software on the snapshot. If the testing is successful, you can then roll back the snapshot to the original and effectively install the software on the regular system. If there is a problem during the testing, you can simply delete the snapshot without harming the original volume.

You can perform a rollback when the following conditions are met:

No options are available for rolling back snapshots.

EVMS treats volumes and storage objects separately. A storage object does not automatically become a volume; it must be made into a volume.

Volumes are created from storage objects. Volumes are either EVMS native volumes or compatibility volumes. Compatibility volumes are intended to be compatible with a volume manager other than EVMS, such as the Linux LVM, MD, OS/2 or AIX. Compatibility volumes might have restrictions on what EVMS can do with them. EVMS native volumes have no such restrictions, but they can be used only by an EVMS equipped system. Volumes are mountable and can contain file systems.

EVMS native volumes contain EVMS-specific information to identify the volume name. After this volume information is applied, the volume is no longer fully backward compatible with existing volume types.

Instead of adding EVMS metadata to an existing object, you can tell EVMS to make an object directly available as a volume. This type of volume is known as a compatibility volume. Using this method, the final product is fully backward-compatible with the desired system.

This section provides a detailed explanation of how to create an EVMS native volume with EVMS by providing instructions to help you complete the following task.

Example 12.1. Create an EVMS native volume

Create an EVMS native volume called "Sample Volume" from the region, /lvm/Sample Container/Region, you created in Chapter 9. "Creating regions".

Create: Volume, "lvm/Sample Container/Sample Region", Name="Sample Volume"

This section provides a detailed explanation of how to create a compatibility volume with EVMS by providing instructions to help you complete the following task.

Example 12.2. Create a compatibility volume

Create a compatibility volume called "Sample Volume" from the region, /lvm/Sample Container/Region, you created in Chapter 9. "Creating regions".

Create:Volume,"lvm/Sample Container/Sample Region",compatibility

EVMS currently ships with seven FSIMs. These file system modules allow EVMS to interact with file system utilities such as mkfs and fsck. Additionally, the FSIMs ensure that EVMS safely performs operations, such as expanding and shrinking file systems, by coordinating these actions with the file system.

You can invoke operations such as mkfs and fsck through the various EVMS user interfaces. Any actions you initiate through an FSIM are not saved to disk until the changes are saved in the user interface. Later in this chapter we provide examples of creating a new file system and coordinating file system checks through the EVMS GUI, Ncurses, and command-line interfaces.

The FSIMs supported by EVMS are:

After you have made an EVMS or compatibility volume, add a file system to the volume before mounting it. You can add a file system to a volume through the EVMS interface of your choice.

Example 13.1. Add a JFS File System to a Volume

This example creates a new JFS file system, named jfs_vol, on volume /dev/evms/my_vol.

mkfs: JFS={vollabel=jfs_vol}, /dev/evms/my_vol

query: plugins, plugin=JFS, list options

You can also coordinate file system checks from the EVMS user interfaces.

Example 13.2. Check a JFS File System

This example shows how to perform a file system check on a JFS file system, named jfs_vol, on volume /dev/evms/my_vol, with verbose output.

check: /dev/evms/my_vol, verbose=TRUE

Note the following rules and limitations for creating cluster containers:

This section tells how to create a sample private container and provides instructions for completing the following task:

Example 14.1. Create a private cluster container

Given a system with three available shared disks (sdd, sde, and sdf), use the EVMS Cluster Segment Manager to combine these disk drives into a container called Priv1 owned by node1.

create: container,CSM={name="Priv1",type="private",nodeid="node1"},sdd,sde,sdf

This section tells how to create a sample shared container and provides instructions to help you complete the following task:

Example 14.2. Create a shared cluster container

Given a system with three available shared disks (sdd, sde, and sdf), use the EVMS Cluster Segment Manager to combine these disk drives into a shared container called Shar1.

create: container,CSM={name="Shar1",type="shared"},sdd,sde,sdf

This section tells how to convert a sample private container to a shared container and provides instructions for completing the following task:

Example 14.3. Convert a private container to shared

Given a system with a private storage container Priv1 owned by evms1, convert Priv1 to a shared storage container with the same name.

modify: Priv1,type=shared

This section tells how to convert a sample shared container to a private container and provides instructions for completing the following task:

Example 14.4. Convert a shared container to private

Given a system with a shared storage container Shar1, convert Shar1 to a private storage container owned by node node1 (where node1 is the nodeid of one of the cluster nodes).

modify: Shar1,type=private,node=node1

When a container is deported, the node disowns the container and deletes all the objects created in memory that belong to that container. No node in the cluster can discover objects residing on a deported container or create objects for a deported container. This section explains how to deport a private or shared container.

Example 14.5. Deport a cluster container

Given a system with a private or shared storage container named c1, deport c1.

modify: c1,type=deported

The procedure for deleting a cluster container is the same for deleting any container. See Section 21.2, "Example: perform a delete recursive operation"

EVMS supports the Linux-HA cluster manager in EVMS V2.0 and later. Support for the RSCT cluster manager is also available as of EVMS V2.1, but is not as widely tested.

Follow these steps to set up failover and failback of a private container:

EVMS supports the administration of cluster nodes by any node in the cluster. For example, storage on remote cluster node node1 can be administered from cluster node node2. The following sections show how to set up remote administration through the various EVMS user interfaces.

evms -n node2

A private container and its objects are made active on a node if:

Similarly, a shared container and its objects are made active on a node if the node is in a cluster that currently has quorum. However, the administrator can force the activation of private and shared containers by overriding these rules.

There are several different scenarios that might help you determine what type of volumes you need. For example, if you wanted persistent names or to make full use of EVMS features, such as Drive Linking or Snapshotting, you would convert your compatibility volumes to EVMS volumes. In another situation, you might decide that a volume needs to be read by a system that understands the underlying volume management scheme. In this case, you would convert your EVMS volume to a compatibility volume.

A volume can only be converted when it is offline. This means the volume must be unmounted and otherwise not in use. The volume must be unmounted because the conversion operation changes both the name and the device number of the volume. Once the volume is converted, you can remount it using its new name.

A compatibility volume can be converted to an EVMS volume in the following situations:

This section provides a detailed explanation of how to convert compatibility volumes to EVMS volumes and provides instructions to help you complete the following task.

Example 15.1. Convert a compatibility volume

You have a compatibility volume /dev/evms/hda3 that you want to make into an EVMS volume named my_vol.

convert: /dev/evms/hda3, Name=my_vol

An EVMS volume can be converted to a compatibility volume only if the volume does not have EVMS features on it. This section provides a detailed explanation of how to convert EVMS volumes to compatibility volumes by providing instructions to help you complete the following task.

Example 15.2. Convert an EVMS volume

You have an EVMS volume, /dev/evms/my_vol, that you want to make a compatibility volume.

convert: /dev/evms/my_vol, compatibility

Expanding and shrinking volumes are common volume operations on most systems. For example, it might be necessary to shrink a particular volume to create free space for another volume to expand into or to create a new volume.

EVMS simplifies the process for expanding and shrinking volumes, and protects the integrity of your data, by coordinating expand and shrink operations with the volume's file system. For example, when shrinking a volume, EVMS first shrinks the underlying file system appropriately to protect the data. When expanding a volume, EVMS expands the file system automatically when new space becomes available.

Not all file system interface modules (FSIM) types supported by EVMS allow shrink and expand operations, and some only perform the operations when the file system is mounted ("online"). The following table details the shrink and expand options available for each type of FSIM.

You can perform all of the supported shrink and expand operations with each of the EVMS user interfaces.

This section tells how to shrink a compatibility volume by 500 MB.

Example 16.1. Shrink a volume

Shrink the volume /dev/evms/lvm/Sample Container/Sample Region, which is the compatibility volume that was created in the chapter entitled "Creating Volumes," by 500 MB.

query: shrink points, "/dev/evms/lvm/Sample Container/Sample Region"

query: objects, object="lvm/Sample Container/Sample Region", list options

shrink: "lvm/Sample Container/Sample Region", remove_size=500MB

This section tells how to expand a volume a compatibility volume by 500 MB.

Example 16.2. Expand a volume

Expand the volume /dev/evms/lvm/Sample Container/Sample Region, which is the compatibility volume that was created in the chapter entitled "Creating Volumes," by 500 MB.

query: expand points, "/dev/evms/lvm/Sample Container/Sample Region"

query: objects, object="lvm/Sample Container/Sample Region", list options

expand: "lvm/Sample Container/Sample Region", add_size=500MB, 
"lvm/Sample Container/Freespace"

EVMS lets you add features such as drive linking to a volume that already exists. By adding features, you avoid having to potentially destroy the volume and recreate it from scratch. For example, take the scenario of a volume that contains important data but is almost full. If you wanted to add more data to that volume but no free space existed on the disk immediately after the segment, you could add a drive link to the volume. The drive link concatenates another object to the end of the volume and continues seamlessly.

The following example shows how to add drive linking to a volume with the EVMS GUI, Ncurses, and CLI interfaces.

Example 17.1. Add drive linking to an existing volume

The following sections show how to add a drive link to volume /dev/evms/vol and call the drive link "DL."

NOTE

Drive linking can be done only on EVMS volumes; therefore, /dev/evms/vol must be converted to an EVMS volume if it is not already.

query: plugins, plugin=DriveLink, list options

add feature: DriveLink={ Name="DL }, /dev/evms/vol

There is a section in the EVMS configuration file, /etc/etc/evms.conf, named "activate." This section has two entries: "include" and "exclude." The "include" entry lists the volumes and objects that should be activated. The "exclude" entry lists the volumes and objects that should not be activated.

Names in either of the entries can be specified using "*", "?", and "[...]" notation. For example, the following entry will activate all the volumes:

include = [/dev/evms/*]

The next entry specifies that objects sda5 and sda7 not be activated:

exclude = [ sda[57] ]

When EVMS is started, it first reads the include entry and builds a list of the volumes and objects that it should activate. It then reads the exclude entry and removes from the list any names found in the exclude list. For example, an activation section that activates all of the volumes except /dev/evms/temp looks like this:

activate {
	include = [/dev/evms/*]
	exclude = [/dev/evms/temp]
}

If /etc/evms.conf does not contain an activate section, the default behavior is to activate everything. This behavior is consistent with versions of EVMS prior to 2.4.

Initial activation via /etc/evms.conf does not deactivate any volumes or objects. It only determines which ones should be active.

The EVMS user interfaces offer the ability to activate or deactivate a particular volume or object. The volume or object will be activated or deactivated when the changes are saved.

Activate:name

Deactivate:name

activate {
	include = [*]
	exclude = [hda*]
}

This section tells how to mount a volume through the various EVMS user interfaces.

mount:<volume>, <mount point>, [ <mount options> ]

This section tells how to unmount a volume through the various EVMS user interfaces.

unmount:<volume>

A volume with the SWAPFS file system is not mounted or unmounted. Rather, swapping is turned on for the volume using the sbin/swapon command and turned off using the <command>sbin/swapoff</command>. EVMS lets you turn swapping on or off for a volume from within EVMS without having to go to a separate terminal session.

As with mounting and unmounting, EVMS performs the swapon and swapoff operations immediately. It does not wait until the changes are saved.

Task: swapon, <volume>[, priority=low | , priority=high [level=0..32767]]

Task: swapoff, <volume>

Plug-in tasks are functions that are available only within the context of a particular plug-in. These functions are not common to all plug-ins. For example, tasks to add spare disks to a RAID array make sense only in the context of the MD plug-in, and tasks to reset a snapshot make sense only in the context of the Snapshot plug-in.

This section shows how to complete a plug-in operations task with the EVMS GUI, Ncurses, and CLI interfaces.

Example 20.1. Add a spare disk to a compatibility volume made from an MDRaid5 region

This example adds disk sde as a spare disk onto volume /dev/evms/md/md0, which is a compatibility volume that was created from an MDRaid5 region.

There are two ways in EVMS that you can destroy objects that you no longer want: Delete and Delete Recursive. The Delete option destroys only the specific object you specify. The Delete Recursive option destroys the object you specify and its underlying objects, down to the container, if one exists, or else down to the disk. In order for a volume to be deleted, it must not be mounted. EVMS verifies that the volume you are attempting to delete is not mounted and does not perform the deletion if the volume is mounted.

The following example shows how to destroy a volume and the objects below it with the EVMS GUI, Ncurses, and CLI interfaces.

Example 21.1. Destroy a volume and the region and container below it

This example uses the delete recursive operation to destroy volume /dev/evms/Sample Volume and the region and container below it. Volume /dev/evms/Sample Volume is the volume that was created in earlier. Although we could also use the delete option on each of the objects, the delete recursive option takes fewer steps. Note that because we intend to delete the container as well as the volume, the operation needs to be performed in two steps: one to delete the volume and its contents, and one to delete the container and its contents.

Occasionally, you might wish to change the configuration of a volume or storage object. For instance, you might wish to replace one of the disks in a drive-link or RAID-0 object with a newer, faster disk. As another example, you might have an EVMS volume created from a simple disk segment, and want to switch that segment for a RAID-1 region to provide extra data redundancy. Object-replace accomplishes such tasks.

Object-replace gives you the ability to swap one object for another object. The new object is added while the original object is still in place. The data is then copied from the original object to the new object. When this is complete, the original object is removed. This process can be performed while the volume is mounted and in use.

For this example, we will start with a drive-link object named link1, which is composed of two disk segments named sda1 and sdb1. The goal is to replace sdb1 with another segment named sdc1.

Replace:source_object_name, target_object_name

Replace:sdb1,sdc1

A segment move is when a data segment is relocated to another location on the underlying storage object. The new location of the segment cannot overlap with the current segment location.

Segments are moved for a variety of reasons. The most compelling among them is to make better use of disk freespace. Disk freespace is an unused contiguous extent of sectors on a disk that has been identified by EVMS as a freespace segment. A data segment can only be expanded by adding sectors to the end of the segment, moving the end of the data segment up into the freespace that immediately follows the data segment. However, what if there is no freespace following the data segment? A segment or segments could be be moved around to put freespace after the segment that is to be expanded. For example:

The following segment manager plug-ins support the move function:

This section shows how to move a DOS segment:

task:Move,sda1,sda_freespace1

The following sections tell how to back up metadata in the following ways:

You restore metadata by using the evms_metadata_restore utility. The syntax is:

evms_metadata_restore [options] [thing_name ...]

The following options can be used with evms_metadata_restore:

evms_metadata_restore accepts optional parameters, which are the names of the things (segments, regions, containers, EVMS objects, volumes) for which the metadata are to be restored.

evms_metadata_restore -L

...
Entry #:	2
Parent:		hda_mbr
Child:		hda
Offset:		0
Length:		1

Metadata:

00000000  eb 48 90 00 c0 07 4c 49  4c 4f 01 00 15 06 91 00  |ëH..À.LILO......|
00000010  00 00 00 00 e2 a6 98 3b  85 67 b0 bc 00 86 67 b0  |....â¦.;.g°¼..g°|
00000020  bc 00 84 67 b0 bc 00 01  ff ff 88 67 b0 bc 00 8a  |¼..g°¼.....g°¼..|
00000030  67 b0 bc 00 fd eb b0 bb  00 fe eb b0 bb 00 03 02  |g°¼.ýë°».þë°»...|
00000040  ff 00 00 20 01 00 00 00  00 02 fa ea 50 7c 00 00  |... ......úêP|..|
...

evms_metadata_restore -a

evms_metadata_restore -f /root/backups/evms/2004-06-05

evms-metadata-2004-04-07.07.18.33
evms-metadata-2004-04-10-08.28.12
evms-metadata-2004-04-12-00.00.47

The following sections describe some cautions you need to be aware of when backing up and restoring EVMS metadata.