1.1. Why choose EVMS?

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.

1.2. The EVMS user interfaces

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.

1.3. EVMS terminology

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:

1.4. What makes EVMS so flexible?

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.

1.5. Plug-in layer definitions

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.

2.1. EVMS GUI

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.

2.2. EVMS Ncurses interface

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.

2.3. EVMS Command Line Interpreter

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-2.2.0/engine2/ui/cli/grammar.ps 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.

---

2.3.1. Using the EVMS CLI

Use the evms command to start the EVMS CLI. If you do not enter an option with evms, the EVMS CLI starts in interactive mode. In interactive mode, the EVMS CLI prompts you for commands. The result of each command is immediately saved to disk. The EVMS CLI exits when you type exit. You can modify this behavior by using the following options with evms:

-b

This option indicates that you are running in batch mode and anytime there is a prompt for input from the user, the default value is accepted automatically. This is the default behavior with the -f option.

-c

This option saves changes to disk only when EVMS CLI exits, not after each command.

-f filename

This option tells the EVMS CLI to use filename as the source of commands. The EVMS CLI exits when it reaches the end of filename.

-p

This option only parses commands; it does not execute them. When combined with the -f option, the -p option detects syntax errors in command files.

-h

This option displays help information for options used with the evms command.

-rl

This option tells the CLI that all remaining items on the command line are replacement parameters for use with EVMS commands.

NOTE

Replacement parameters are accessed in EVMS commands using the $(x) notation, where x is the number identifying which replacement parameter to use. Replacement parameters are assigned numbers (starting with 1) as they are encountered on the command line. Substitutions are not made within comments or quoted strings. An example would be: evms -c -f testcase -rl sda sdb sda is the replacement for parameter1 and sdb is the replacement for parameter2

	NOTE
	Information on less commonly used options is available in the EVMS man page.

"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

3.1. About the EVMS log file

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.

3.2. Log file logging levels

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:

3.3. Specifying the logging levels

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

	NOTE
	If you use the EVMS mailing list for help with a problem, providing to us the log file that is created when you open one of the interfaces (as shown in the previous commands) makes it easier for us to help you.

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

1. Select Settings->Log Level->Engine.

2. Click the Level you want.

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.

4.1. Using the EVMS GUI

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.

4.2. Using Ncurses

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.

4.3. Using the CLI

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

1. Start the Command Line Interpreter by typing evms at the command line.

2. Query the volumes by typing the following at the EVMS prompt:

   query:volumes

   Your migrated volumes are displayed as results of the query.

5.1. Using the EVMS GUI

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:

1. Looking at the volumes view, click the "+" next to volume /dev/evms/Sample Volume. Alternatively, look at the regions view.

2. Right click lvm/Sample Container/Sample Region.

3. Point at Display Details... and click. A new window opens with additional information about the selected region.

4. Click More by the Logical Extents box. Another window opens that displays the mappings of logical extents to physical extents.

5.2. Using Ncurses

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

1. Press Tab to reach the Storage Regions view.

2. Scroll down using the down arrow until lvm/Sample Container/Sample Region is highlighted.

3. Press Enter.

4. In the context menu, scroll down using the down arrow to highlight "Display Details..."

5. Press Enter to activate the menu item.

6. In the Detailed Information dialog, use the down arrow to highlight the "Logical Extents" item and then use spacebar to open another window that displays the mappings of logical extents to physical extents.

5.3. Using the CLI

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

6.1. When to add a segment manager

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:

• Data: a set of contiguous sectors that has been allocated from a disk and can be used to construct a volume or object.

• Freespace: a set of contiguous sectors that are unallocated or not in use. Freespace can be used to create a segment.

• Metadata: a set of contiguous sectors that contain information needed by the segment manager.

6.2. Types of segment managers

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

6.3. Adding a segment manager to an existing disk

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.

6.4. Adding a segment manager to a new disk

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.

6.5. Example: add a segment manager

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.

	NOTE
	In the following example, the DOS Segment Manager creates two segments on the disk: a metadata segment known as sde_mbr, and a segment to represent the available space on the drive, sde_freespace1. This freespace segment (sde_freespace1) can be divided into other segments because it represents space on the drive that is not in use.

Delete:/dev/evms/sde

Add:DosSegMgr={},sde

6.6. Removing a segment manager

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.

6.7. Example: remove a segment manager

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.

	NOTE
	In the following example, the DOS Segment Manager has one primary partition on disk sda. The segment is a compatibility volume known as /dev/evms/sda1.

Delete:/dev/evms/sda1

Remove: sda

7.1. When to create a segment

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.

7.2. Example: create a segment

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.

---

7.2.3. Using the CLI

To create a data segment from a freespace segment, use the Create command. The arguments the Create command accepts vary depending on what is being created. The first argument to the Create command indicates what is to be created, which in the above example is a segment. The remaining arguments are the freespace segment to allocate from and a list of options to pass to the segment manager. The command to accomplish this is:

Create: Segment,sde_freespace1, size=100MB

	NOTE
	The Allocate command also works to create a segment.

The previous example accepts the default values for all options you don't specify. To see the options for this command type:

query:plugins,plugin=DosSegMgr,list options

8.1. When to create a container

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.

8.2. Example: create a container

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

9.1. When to create regions

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.

9.2. Example: create a 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

10.1. What is drive linking?

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.

10.2. How drive linking is implemented

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:

• Identify the link object itself.

• Identify the drive link storage object that the link object belongs to.

• Identify all link objects belonging to the drive link storage. object

• Establish the order in which to combine the child link objects.

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.

10.3. Creating a 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.

10.4. Example: create a drive link

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

10.5. Expanding a drive link

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:

• By adding an additional storage object to the end of the drive link.

• By expanding the last storage object in the drive link.

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.

10.6. Shrinking a drive link

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:

• By removing link objects from the end of the drive link.

• By shrinking the last storage object in the drive link.

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.

10.7. Deleting a drive link

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.

11.1. What is a snapshot?

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.

11.2. Creating snapshot objects

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 fil