qtsmbstatus

package: qtsmbstatus

title: qtsmbstatus(7)

text:
# qtsmbstatus(7)

## NAME
qtsmbstatus - qtsmbstatus client : GUI (graphical user interface) for smbstatus

## SYNOPSIS
qtsmbstatus [-m] [-i seconds] [-p port]

## DESCRIPTION
This manual page documents briefly the qtsmbstatus commands.

QtSmbstatus is a GUI (graphical user interface) for smbstatus. It is meant to provide the possibility of administering remote machines. QtSmbstatus was designed as a client/server system secured with SSL. A login and password is required to log on to server (PAM).

To use QtSmbstatus only locally (without qtsmbstatus-server), see qtsmbstatusl.

## OPTIONS
-i <seconds> : Interval between smbstatus requests in seconds, (interval > 2). default value = 10

-p <port> : TCP port. default = 4443

-v : Show qtsmbstatus version

-m : Show debug messages

--help : help

## SEE ALSO
qtsmbstatusd(7), qtsmbstatusl(7), samba(1), smbstatus(1).

## AUTHOR
qtsmbstatus was written by Daniel Rocher <daniel.rocher@adella.org>.

This manual page was written by Daniel Rocher <daniel.rocher@adella.org>, for the Debian project (but may be used by others).


qtsmbstatusl

package: qtsmbstatus-light

title: qtsmbstatusl(7)

text:
# qtsmbstatusl(7)

## NAME
qtsmbstatusl - qtsmbstatus light : GUI (graphical user interface) for smbstatus

## SYNOPSIS
qtsmbstatusl [-m] [-i seconds]

## DESCRIPTION
This manual page documents briefly the qtsmbstatusl commands.

QtSmbstatus is a GUI (graphical user interface) for smbstatus. smbstatusl only works locally (no remote access). It doesn't require qtsmbstatus-server.

## OPTIONS
-i <seconds> : Interval between smbstatus requests in seconds, (interval > 2). default value = 10

-v : Show qtsmbstatusl version

-m : Show debug messages

--help : help

## SEE ALSO
qtsmbstatus(7), qtsmbstatusd(7), samba(1), smbstatus(1).

## AUTHOR
qtsmbstatus was written by Daniel Rocher <daniel.rocher@adella.org>.

This manual page was written by Daniel Rocher <daniel.rocher@adella.org>, for the Debian project (but may be used by others).


qtsmbstatusd

package: qtsmbstatus-server

title: qtsmbstatusd(7)

text:
# qtsmbstatusd(7)

## NAME
qtsmbstatusd - qtsmbstatus server : GUI (graphical user interface) for smbstatus

## SYNOPSIS
qtsmbstatusd [-d] [-m] [-p port]

## DESCRIPTION
This manual page documents briefly the qtsmbstatusd commands.

QtSmbstatus is a GUI (graphical user interface) for smbstatus. It is meant to provide the possibility of administering remote machines.

QtSmbstatus was designed as a client/server system secured with SSL. A login and password is required to log on to server (PAM). The server's application ought to be installed with samba server.

## OPTIONS
-d : Daemonize

-p <port> : TCP port. default = 4443

-v : Show qtsmbstatusd version

-m : Show debug messages

--help : help

## SEE ALSO
qtsmbstatus(7), qtsmbstatusl(7), samba(1), smbstatus(1).

## AUTHOR
qtsmbstatusd was written by Daniel Rocher <daniel.rocher@adella.org>.

This manual page was written by Daniel Rocher <daniel.rocher@adella.org>, for the Debian project (but may be used by others).


librabbitmq-tools

package: rabbitmq-c

title: librabbitmq-tools(7)

summary: Command line AMQP tools

text:
# librabbitmq-tools(7)

## NAME
librabbitmq-tools - Command line AMQP tools

## DESCRIPTION
A set of command line AMQP tools based on librabbitmq. This page describes common options and conventions used by all of the tools.

## COMMON OPTIONS
-s, --server=hostname:port

The host name (or address) to connect to. Defaults to localhost. The port number may also be specified; if omitted, it defaults to the standard AMQP port number (5672).

--vhost=vhost

The AMQP vhost to specify when connecting. Defaults to /.

--username=username

The username to authenticate to the AMQP server with. Defaults to guest.

--password=password

The password to authenticate to the AMQP server with. Defaults to guest.

## SEE ALSO
amqp-publish(1), amqp-consume(1), amqp-get(1)

## AUTHOR
The RabbitMQ Team <<info@rabbitmq.com>>


esil

title: esil(7)

text:
# esil(7)

## NAME
ESIL - Evaluable Strings Intermediate Language

## SYNOPSIS
ESIL provides an abstract, stack-based format for representing CPU instruction semantics across various architectures, facilitating instruction emulation for analysis and debugging within the radare2 framework.

## DESCRIPTION
Evaluable Strings Intermediate Language (ESIL) adopts a Forth-like syntax, offering a method to describe and emulate the behavior of machine instructions in a platform-agnostic manner. It is particularly useful in reverse engineering, allowing for cross-architecture binary analysis and exploitation through radare2.

## SYNTAX
ESIL expressions use a series of operands and operations, manipulating values on an internal stack. These expressions are executed within an ESIL virtual machine (VM), enabling the simulation of CPU instructions' effects on registers and memory.

Uppercase words are special keywords that operate on the esil VM.

Lowercase words are register names that can be used for reading or writing through operations.

Words starting with $ represent internal variables of the VM that are readonly

Numbers can be in base 10 or hexadecimal.

The rest of keywords can be added or removed via esil or arch plugins, but this document describes all the common and standard ESIL commands. Note that the list of instructions is subject to change (will be reduced over time) for simplicity reasons.

## USING ESIL IN RADARE2
Radare2's visual mode and various configuration options, such as `emu.str` and `asm.esil`, facilitate the inspection of ESIL evaluations alongside traditional disassembly. This dual view can greatly enhance understanding of binary behavior without requiring physical execution.

## ESIL COMMANDS
Radare2 leverages ESIL for detailed emulation of instruction execution, enabling users to step through instructions, inspect changes to registers and memory, and evaluate conditional logic in a controlled environment.

In the visual mode of radare2 you can emulate code doing single stepping, but it is also possible to debug the expressions using the `aev` command

ae: Evaluate an ESIL expression. Note that some expressions contain special characters that can be evaluated by the radare2 shell, so it's better to prefix the command with a single quote ' to skip that parsing.

"aev": Enter the interactive visual debugger to debug and emulate an esil expression.

"aes": ESIL Step: execute a single step in ESIL emulation.

"aeso": ESIL Step Over: perform a step over call instructions in ESIL emulation.

"aesu": ESIL Step Until: continue ESIL execution until a specified address is reached.

"ar": Show or modify ESIL registers.

## WORDS
The comma separated words in an ESIL expression can be grouped into different scopes:

internal flags

Prefixed with '$' they represent internal states of the esil vm and are used to perform conditional comparison flags: $z, $c, $b, $p, $s, $o, $ds, $jt, $js

current address: $$

assignment

Pop the value and the destination from the stack "=": strong assignment (update flags)

":=": weak assignment without updating flags

arithmetic and binary operations

Basic math operations like add, sub, mul, mod, div, shift, rotate, and, or + - / * %

"~" sign extend

"<<" shift left (see ">>" for shift right)

"<<<" rotate left (">>>" for rotate right

"<<<<" arithmetic shift left (">>>>" for asr)

"&" binary AND

"|" binary OR

"!" negate value ins tack

"L*": long multiplication

"*": multiplication

"^": xor

"~/": signed division

"%": mod

comparison

Comparison words update the internal flags and can be used to make conditional operations.

"<": smaller than

"<=": smaller or equal

"<=": bigger or equal

">": bigger than

"==": compare equality

control flow

Conditional expressions, loops GOTO BREAK "?{" "}" "}{"

memory access

The memory access expressions contain the [] braces to read and =[] to write, address and value are popped from the stack, and size is defined between the brackets. In order to simplify the VM and reduce the amount of keywords those combined operations may change in the future.

reading: [1] [2] [4] [8] [16]

writing: =[1] =[2] =[4] =[8] =[16]

combined: |=[2] +=[4] &=[4] --=[2]

special [*] =[*]

special

Represented as uppercase words, they are used to manipulate the internal esil stack, swaping, perform a cast, set flags and so on STACK POP TODO CLEAR DUP NUM SWAP TRAP BITS SETJT SETJTS SETD

other (may use uppercase words)

"()": syscall "$": interrupt "#!": r2 command

floating point

NAN I2D U2D D2I D2F F2D F== F!= F< F<= F+ F- F* F/ -F CEIL FLOOR ROUND SQRT

## BASIC OPERATIONS
Core operations in ESIL are designed to replicate basic CPU instructions' behavior, including arithmetic, logical, and control flow.

"=" Assignment: Transfers the value from the right operand to the left operand.

"+" Addition: Adds the two topmost values on the stack, pushing the result.

"-" Subtraction: Subtracts the top value from the second top value on the stack, pushing the result.

"*" Multiplication: Multiplies the two topmost values on the stack, pushing the result.

"/" Division: Divides the second top value by the top value on the stack, pushing the result.

"[]" Memory Access: Represents reading or writing to memory, with operation size being context-dependent.

"?{" Conditional Execution: If the top value of the stack is not zero, execute the following block of instructions.

"$" Special Flags and Operations: Accesses internal VM flags for conditions like carry, zero, and overflow or performs special operations like system calls.

"<<", ">>" Bit Shifts: Performs bitwise shift left or right operations.

"&", "|", "^" Bitwise Operations: Executes AND, OR, XOR on the two topmost stack values.

"!" Logical NOT: Inverts the top value on the stack.

## INTERNAL FLAGS AND COMPARISONS
ESIL uses internal flags to represent the outcome of operations, similar to how CPU flags work. These flags enable conditional execution and comparisons within the ESIL VM.

"$z" Zero Flag: Set if the result of an operation is zero. Used to perform equality checks.

"$c" Carry Flag: Set if an operation results in a carry out of the most significant bit. Useful for unsigned arithmetic operations.

"$s" Sign Flag: Set if the result of an operation is negative, indicating the sign in signed arithmetic.

"$o" Overflow Flag: Set if an arithmetic operation produces a result too large for the destination register, indicating overflow in signed arithmetic.

"$p" Parity Flag: Set if the number of set bits in the operation result is even. Rarely used in high-level analysis.

Flags are often used following comparison or arithmetic operations to guide conditional jumps and other control flow decisions, mimicking the behavior of physical CPUs.

## EXPRESSION EXAMPLES
Compares EAX and EBX, setting the zero flag (zf) in ESIL if they are equal.

cmp eax, ebx -> ebx,eax,==,$z,zf,:="

Adds 1 to EAX, demonstrating basic arithmetic.

add eax, 1 -> 1,eax,+=

Jumps to the label if the zero flag (zf) is set, illustrating conditional execution based on comparison results.

jz .label -> zf,?{,.label,eip,=,}

## R2WARS
Code-wars like game implemented on top of ESIL, this is the implementation used in the r2con conference.

https://github.com/radareorg/r2wars

## SEE ALSO
radare2(1),

## WWW
https://www.radare.org/

## AUTHORS
pancake <pancake@nopcode.org>


rxe

package: rdma-core

title: rxe(7)

summary: Software RDMA over Ethernet

text:
# rxe(7)

## NAME
rxe - Software RDMA over Ethernet

## SYNOPSIS
modprobe rdma_rxe

This is usually performed by a configuration utility (see rdma link(8).)

## DESCRIPTION
The rdma_rxe kernel module provides a software implementation of the RoCEv2 protocol. The RoCEv2 protocol is an RDMA transport protocol that exists on top of UDP/IPv4 or UDP/IPv6. The InfiniBand (IB) Base Transport Header (BTH) is encapsulated in the UDP packet.

Once a RXE instance has been created, communicating via RXE is the same as communicating via any OFED compatible Infiniband HCA, albeit in some cases with addressing implications.

In particular, while the use of a GRH header is optional within IB subnets, it is mandatory with RoCE. Verbs applications written over IB verbs should work seamlessly, but they require provisioning of GRH information when creating address vectors. The library and driver are modified to provide for mapping from GID to MAC addresses required by the hardware.

## FILES
/sys/class/infiniband/rxe[0,1,...]

Directory that holds RDMA device information. The format is the same as other RDMA devices.

/sys/module/rdma_rxe_net/parameters/mtu

Write only file used to configure RoCE and Ethernet MTU values.

/sys/module/rdma_rxe/parameters/max_ucontext

Read/Write file that sets a limit on the number of UCs allowed per RXE device.

/sys/module/rdma_rxe/parameters/max_qp

Read/Write file that sets a limit on the number of QPs allowed per RXE device.

/sys/module/rdma_rxe/parameters/max_qp_wr

Read/Write file that sets a limit on the number of WRs per QP allowed per RXE device.

/sys/module/rdma_rxe/parameters/max_mr

Read/Write file that sets a limit on the number of MRs allowed per RXE device.

/sys/module/rdma_rxe/parameters/max_fmr

Read/Write file that sets a limit on the number of FMRs allowed per RXE device.

/sys/module/rdma_rxe/parameters/max_cq

Read/Write file that sets a limit on the number of CQs allowed per RXE device.

/sys/module/rdma_rxe/parameters/max_log_cqe

Read/Write file that sets a limit on the log base 2 of the number of CQEs per CQ allowed per RXE device.

/sys/module/rdma_rxe/parameters/max_inline_data

Read/Write file that sets a limit on the maximum amount of inline data per WR allowed per RXE device. The above configuration parameters only affect a new RXE instance when it is created not afterwards.

/sys/module/rdma_rxe/parameters/crc_disable

Read/Write file that controls the disabling of ICRC computation. Set to a nonzero value for TRUE. Zero for FALSE.

/sys/module/rdma_rxe/parameters/fast_comp|req|resp|arb

Read/Write file that enables calling kernel tasklets as subroutines to reduce latency.

/sys/module/rdma_rxe/parameters/nsec_per_packet|kbyte

Read/Write file that controls static rate pacing for output packets. If set to nonzero values the minimum delay to the next packet is set to nsec_per_kbyte * sizeof(current packet in KBytes) or nsec_per_packet which ever is less.

/sys/module/rdma_rxe/parameters/max_packet_per_ack

Read/Write file that controls the issuing of acks by the responder during a long message. If set additional acks will be generated every max_pkt_per_ack packets.

/sys/module/rdma_rxe/parameters/max_skb_per_qp

Read/Write file that controls the number of skbs (packets) that a requester can queue for sending internally.

/sys/module/rdma_rxe/parameters/max_req_comp_gap

Read/Write file that controls the maximum gap between the PSN of request packets send and ack packets received.

/sys/module/rdma_rxe/parameters/default_mtu

Read/Write file that controls the default mtu used for UD packets.

## SEE ALSO
rdma(8), verbs(7),

## AUTHORS
Written by John Groves, Frank Zago and Bob Pearson at System Fabric Works.


efadv

package: rdma-core-devel

title: efadv(7)

text:
# efadv(7)

## NAME
efadv - Direct verbs for efa devices

This provides low level access to efa devices to perform direct operations, without general branching performed by libibverbs.

## DESCRIPTION
The libibverbs API is an abstract one. It is agnostic to any underlying provider specific implementation. While this abstraction has the advantage of user applications portability, it has a performance penalty. For some applications optimizing performance is more important than portability.

The efa direct verbs API is intended for such applications. It exposes efa specific low level operations, allowing the application to bypass the libibverbs API.

The direct include of efadv.h together with linkage to efa library will allow usage of this new interface.

## SEE ALSO
verbs(7)

## AUTHORS
Gal Pressman <galpress@amazon.com>


title: mlx4dv(7)

summary: Direct verbs for mlx4 devices

text:
# mlx4dv(7)

## NAME
mlx4dv - Direct verbs for mlx4 devices

This is low level access to mlx4 devices to perform data path operations, without general branching performed by ibv_post_send(3).

## DESCRIPTION
The libibverbs API is an abstract one. It is agnostic to any underlying provider specific implementation. While this abstraction has the advantage of user applications portability it has a performance penalty. For some applications optimizing performance is more important than portability.

The mlx4 direct verbs API is intended for such applications. It exposes mlx4 specific low level data path (send/receive/completion) operations, allowing the application to bypass the libibverbs data path API.

This interface consists from one hardware specific header file with relevant inline functions and conversion logic from ibverbs structures to mlx4 specific structures.

The direct include of mlx4dv.h together with linkage to mlx4 library will allow usage of this new interface.

Once an application uses the direct flow the locking scheme is fully managed by itself. There is an expectation that no mixed flows in the data path for both direct/non-direct access will be by same application.

## SEE ALSO
ibv_post_send(3), verbs(7)

## AUTHORS
Maor Gottlieb <maorg@mellanox.com>


title: mlx5dv(7)

summary: Direct verbs for mlx5 devices

text:
# mlx5dv(7)

## NAME
mlx5dv - Direct verbs for mlx5 devices

This is low level access to mlx5 devices to perform data path operations, without general branching performed by ibv_post_send(3).

## DESCRIPTION
The libibverbs API is an abstract one. It is agnostic to any underlying provider specific implementation. While this abstraction has the advantage of user applications portability it has a performance penalty. For some applications optimizing performance is more important than portability.

The mlx5 direct verbs API is intended for such applications. It exposes mlx5 specific low level data path (send/receive/completion) operations, allowing the application to bypass the libibverbs data path API.

This interface consists from one hardware specific header file with relevant inline functions and conversion logic from ibverbs structures to mlx5 specific structures.

The direct include of mlx5dv.h together with linkage to mlx5 library will allow usage of this new interface.

Once an application uses the direct flow the locking scheme is fully managed by itself. There is an expectation that no mixed flows in the data path for both direct/non-direct access will be by same application.

## NOTES
All Mellanox NIC devices starting from Connect-IB (Connect-IB, ConnectX-4, ConnectX-4Lx, ConnectX-5, ...) implement the mlx5 API, thus using the mlx5 direct verbs does not limit the applications to a single NIC HW device thus keeping some level of portability.

## SEE ALSO
ibv_post_send(3), verbs(7), mlx5dv_is_supported(3)

## AUTHORS
Leon Romanovsky <leonro@mellanox.com>


title: rdma_cm(7)

summary: RDMA communication manager.

text:
# rdma_cm(7)

## NAME
rdma_cm - RDMA communication manager.

## SYNOPSIS
\#include <rdma/rdma_cma.h>

## DESCRIPTION
Used to establish communication over RDMA transports.

## NOTES
The RDMA CM is a communication manager used to setup reliable, connected and unreliable datagram data transfers. It provides an RDMA transport neutral interface for establishing connections. The API concepts are based on sockets, but adapted for queue pair (QP) based semantics: communication must be over a specific RDMA device, and data transfers are message based.

The RDMA CM can control both the QP and communication management (connection setup / teardown) portions of an RDMA API, or only the communication management piece. It works in conjunction with the verbs API defined by the libibverbs library. The libibverbs library provides the underlying interfaces needed to send and receive data.

The RDMA CM can operate asynchronously or synchronously. The mode of operation is controlled by the user through the use of the rdma_cm event channel parameter in specific calls. If an event channel is provided, an rdma_cm identifier will report its event data (results of connecting, for example), on that channel. If a channel is not provided, then all rdma_cm operations for the selected rdma_cm identifier will block until they complete.

The RDMA CM gives an option to different libibverbs providers to advertise and use various specific to that provider QP configuration options. This functionality is called ECE (enhanced connection establishment).

## RDMA VERBS
The rdma_cm supports the full range of verbs available through the libibverbs library and interfaces. However, it also provides wrapper functions for some of the more commonly used verbs funcationality. The full set of abstracted verb calls are:

rdma_reg_msgs - register an array of buffers for sending and receiving

rdma_reg_read - registers a buffer for RDMA read operations

rdma_reg_write - registers a buffer for RDMA write operations

rdma_dereg_mr - deregisters a memory region

rdma_post_recv - post a buffer to receive a message

rdma_post_send - post a buffer to send a message

rdma_post_read - post an RDMA to read data into a buffer

rdma_post_write - post an RDMA to send data from a buffer

rdma_post_recvv - post a vector of buffers to receive a message

rdma_post_sendv - post a vector of buffers to send a message

rdma_post_readv - post a vector of buffers to receive an RDMA read

rdma_post_writev - post a vector of buffers to send an RDMA write

rdma_post_ud_send - post a buffer to send a message on a UD QP

rdma_get_send_comp - get completion status for a send or RDMA operation

rdma_get_recv_comp - get information about a completed receive

## CLIENT OPERATION
This section provides a general overview of the basic operation for the active, or client, side of communication. This flow assume asynchronous operation with low level call details shown. For synchronous operation, calls to rdma_create_event_channel, rdma_get_cm_event, rdma_ack_cm_event, and rdma_destroy_event_channel would be eliminated. Abstracted calls, such as rdma_create_ep encapsulate several of these calls under a single API. Users may also refer to the example applications for code samples. A general connection flow would be:

rdma_getaddrinfo

retrieve address information of the destination

rdma_create_event_channel

create channel to receive events

rdma_create_id

allocate an rdma_cm_id, this is conceptually similar to a socket

rdma_resolve_addr

obtain a local RDMA device to reach the remote address

rdma_get_cm_event

wait for RDMA_CM_EVENT_ADDR_RESOLVED event

rdma_ack_cm_event

ack event

rdma_create_qp

allocate a QP for the communication

rdma_resolve_route

determine the route to the remote address

rdma_get_cm_event

wait for RDMA_CM_EVENT_ROUTE_RESOLVED event

rdma_ack_cm_event

ack event

rdma_connect

connect to the remote server

rdma_get_cm_event

wait for RDMA_CM_EVENT_ESTABLISHED event

rdma_ack_cm_event

ack event

Perform data transfers over connection

rdma_disconnect

tear-down connection

rdma_get_cm_event

wait for RDMA_CM_EVENT_DISCONNECTED event

rdma_ack_cm_event

ack event

rdma_destroy_qp

destroy the QP

rdma_destroy_id

release the rdma_cm_id

rdma_destroy_event_channel

release the event channel

rdma_set_local_ece

set desired ECE options

An almost identical process is used to setup unreliable datagram (UD) communication between nodes. No actual connection is formed between QPs however, so disconnection is not needed.

Although this example shows the client initiating the disconnect, either side of a connection may initiate the disconnect.

## SERVER OPERATION
This section provides a general overview of the basic operation for the passive, or server, side of communication. A general connection flow would be:

rdma_create_event_channel

create channel to receive events

rdma_create_id

allocate an rdma_cm_id, this is conceptually similar to a socket

rdma_bind_addr

set the local port number to listen on

rdma_listen

begin listening for connection requests

rdma_get_cm_event

wait for RDMA_CM_EVENT_CONNECT_REQUEST event with a new rdma_cm_id

rdma_create_qp

allocate a QP for the communication on the new rdma_cm_id

rdma_accept

accept the connection request

rdma_ack_cm_event

ack event

rdma_get_cm_event

wait for RDMA_CM_EVENT_ESTABLISHED event

rdma_ack_cm_event

ack event

Perform data transfers over connection

rdma_get_cm_event

wait for RDMA_CM_EVENT_DISCONNECTED event

rdma_ack_cm_event

ack event

rdma_disconnect

tear-down connection

rdma_destroy_qp

destroy the QP

rdma_destroy_id

release the connected rdma_cm_id

rdma_destroy_id

release the listening rdma_cm_id

rdma_destroy_event_channel

release the event channel

rdma_get_remote_ece

get ECe options sent by the client

rdma_set_local_ece

set desired ECE options

## RETURN CODES
= 0

success

= -1

error - see errno for more details

Most librdmacm functions return 0 to indicate success, and a -1 return value to indicate failure. If a function operates asynchronously, a return value of 0 means that the operation was successfully started. The operation could still complete in error; users should check the status of the related event. If the return value is -1, then errno will contain additional information regarding the reason for the failure.

Prior versions of the library would return -errno and not set errno for some cases related to ENOMEM, ENODEV, ENODATA, EINVAL, and EADDRNOTAVAIL codes. Applications that want to check these codes and have compatibility with prior library versions must manually set errno to the negative of the return code if it is < -1.

## SEE ALSO
rdma_accept(3), rdma_ack_cm_event(3), rdma_bind_addr(3), rdma_connect(3), rdma_create_ep(3), rdma_create_event_channel(3), rdma_create_id(3), rdma_create_qp(3), rdma_dereg_mr(3), rdma_destroy_ep(3), rdma_destroy_event_channel(3), rdma_destroy_id(3), rdma_destroy_qp(3), rdma_disconnect(3), rdma_event_str(3), rdma_free_devices(3), rdma_getaddrinfo(3), rdma_get_cm_event(3), rdma_get_devices(3), rdma_get_dst_port(3), rdma_get_local_addr(3), rdma_get_peer_addr(3), rdma_get_recv_comp(3), rdma_get_remote_ece(3), rdma_get_request(3), rdma_get_send_comp(3), rdma_get_src_port(3), rdma_join_multicast(3), rdma_leave_multicast(3), rdma_listen(3), rdma_migrate_id(3), rdma_notify(3), rdma_post_read(3) rdma_post_readv(3), rdma_post_recv(3), rdma_post_recvv(3), rdma_post_send(3), rdma_post_sendv(3), rdma_post_ud_send(3), rdma_post_write(3), rdma_post_writev(3), rdma_reg_msgs(3), rdma_reg_read(3), rdma_reg_write(3), rdma_reject(3), rdma_resolve_addr(3), rdma_resolve_route(3), rdma_get_remote_ece(3), rdma_set_option(3), mckey(1), rdma_client(1), rdma_server(1), rping(1), ucmatose(1), udaddy(1)


rds

package: rds-devel

title: rds(7)

summary: Reliable Datagram Sockets

text:
# rds(7)

## NAME
RDS - Reliable Datagram Sockets

## SYNOPSIS

```
#include <sys/socket.h>
#include <netinet/in.h>
```

## DESCRIPTION
This is an implementation of the RDS socket API. It provides reliable, in-order datagram delivery between sockets over a variety of transports.

Currently, RDS can be transported over Infiniband, and loopback. RDS over TCP is disabled, but will be re-enabled in the near future.

RDS uses standard AF_INET addresses as described in ip(7) to identify end points.

### Socket Creation
RDS is still in development and as such does not have a reserved protocol family constant. Applications must read the string representation of the protocol family value from the pf_rds sysctl parameter file described below.

```
rds_socket = socket(pf_rds, SOCK_SEQPACKET, 0);
```

### Socket Options
RDS sockets support a number of socket options through the setsockopt(2) and getsockopt(2) calls. The following generic options (with socket level SOL_SOCKET) are of specific importance:

SO_RCVBUF

Specifies the size of the receive buffer. See section on "Congestion Control" below.

SO_SNDBUF

Specifies the size of the send buffer. See "Message Transmission" below.

SO_SNDTIMEO

Specifies the send timeout when trying to enqueue a message on a socket with a full queue in blocking mode.

In addition to these, RDS supports a number of protocol specific options (with socket level SOL_RDS). Just as with the RDS protocol family, an official value has not been assigned yet, so the kernel will assign a value dynamically. The assigned value can be retrieved from the sol_rds sysctl parameter file.

RDS specific socket options will be described in a separate section below.

### Binding
A new RDS socket has no local address when it is first returned from socket(2). It must be bound to a local address by calling bind(2) before any messages can be sent or received. This will also attach the socket to a specific transport, based on the type of interface the local address is attached to. From that point on, the socket can only reach destinations which are available through this transport.

For instance, when binding to the address of an Infiniband interface such as ib0, the socket will use the Infiniband transport. If RDS is not able to associate a transport with the given address, it will return EADDRNOTAVAIL.

An RDS socket can only be bound to one address and only one socket can be bound to a given address/port pair. If no port is specified in the binding address then an unbound port is selected at random.

RDS does not allow the application to bind a previously bound socket to another address. Binding to the wildcard address INADDR_ANY is not permitted either.

### Connecting
The default mode of operation for RDS is to use unconnected socket, and specify a destination address as an argument to sendmsg. However, RDS allows sockets to be connected to a remote end point using connect(2). If a socket is connected, calling sendmsg without specifying a destination address will use the previously given remote address.

### Congestion Control
RDS does not have explicit congestion control like common streaming protocols such as TCP. However, sockets have two queue limits associated with them; the send queue size and the receive queue size. Messages are accounted based on the number of bytes of payload.

The send queue size limits how much data local processes can queue on a local socket (see the following section). If that limit is exceeded, the kernel will not accept further messages until the queue is drained and messages have been delivered to and acknowledged by the remote host.

The receive queue size limits how much data RDS will put on the receive queue of a socket before marking the socket as congested. When a socket becomes congested, RDS will send a congestion map update to the other participating hosts, who are then expected to stop sending more messages to this port.

There is a timing window during which a remote host can still continue to send messages to a congested port; RDS solves this by accepting these messages even if the socket's receive queue is already over the limit.

As the application pulls incoming messages off the receive queue using recvmsg(2), the number of bytes on the receive queue will eventually drop below the receive queue size, at which point the port is then marked uncongested, and another congestion update is sent to all participating hosts. This tells them to allow applications to send additional messages to this port.

The default values for the send and receive buffer size are controlled by the A given RDS socket has limited transmit buffer space. It defaults to the system wide socket send buffer size set in the wmem_default and rmem_default sysctls, respectively. They can be tuned by the application through the SO_SNDBUF and SO_RCVBUF socket options.

### Blocking Behavior
The sendmsg(2) and recvmsg(2) calls can block in a variety of situations. Whether a call blocks or returns with an error depends on the non-blocking setting of the file descriptor and the MSG_DONTWAIT message flag. If the file descriptor is set to blocking mode (which is the default), and the MSG_DONTWAIT flag is not given, the call will block.

In addition, the SO_SNDTIMEO and SO_RCVTIMEO socket options can be used to specify a timeout (in seconds) after which the call will abort waiting, and return an error. The default timeout is 0, which tells RDS to block indefinitely.

### Message Transmission
Messages may be sent using sendmsg(2) once the RDS socket is bound. Message length cannot exceed 4 gigabytes as the wire protocol uses an unsigned 32 bit integer to express the message length.

RDS does not support out of band data. Applications are allowed to send to unicast addresses only; broadcast or multicast are not supported.

A successful sendmsg(2) call puts the message in the socket's transmit queue where it will remain until either the destination acknowledges that the message is no longer in the network or the application removes the message from the send queue.

Messages can be removed from the send queue with the RDS_CANCEL_SENT_TO socket option described below.

While a message is in the transmit queue its payload bytes are accounted for. If an attempt is made to send a message while there is not sufficient room on the transmit queue, the call will either block or return EAGAIN.

Trying to send to a destination that is marked congested (see above), the call will either block or return ENOBUFS.

A message sent with no payload bytes will not consume any space in the destination's send buffer but will result in a message receipt on the destination. The receiver will not get any payload data but will be able to see the sender's address.

Messages sent to a port to which no socket is bound will be silently discarded by the destination host. No error messages are reported to the sender.

### Message Receipt
Messages may be received with recvmsg(2) on an RDS socket once it is bound to a source address. RDS will return messages in-order, i.e. messages from the same sender will arrive in the same order in which they were be sent.

The address of the sender will be returned in the sockaddr_in structure pointed to by the msg_name field, if set.

If the MSG_PEEK flag is given, the first message on the receive is returned without removing it from the queue.

The memory consumed by messages waiting for delivery does not limit the number of messages that can be queued for receive. RDS does attempt to perform congestion control as described in the section above.

If the length of the message exceeds the size of the buffer provided to recvmsg(2), then the remainder of the bytes in the message are discarded and the MSG_TRUNC flag is set in the msg_flags field. In this truncating case recvmsg(2) will still return the number of bytes copied, not the length of entire messge. If MSG_TRUNC is set in the flags argument to recvmsg(2), then it will return the number of bytes in the entire message. Thus one can examine the size of the next message in the receive queue without incurring a copying overhead by providing a zero length buffer and setting MSG_PEEK and MSG_TRUNC in the flags argument.

The sending address of a zero-length message will still be provided in the msg_name field.

### Control Messages
RDS uses control messages (a.k.a. ancillary data) through the msg_control and msg_controllen fields in sendmsg(2) and recvmsg(2). Control messages generated by RDS have a cmsg_level value of sol_rds. Most control messages are related to the zerocopy interface added in RDS version 3, and are described in rds-rdma(7).

The only exception is the RDS_CMSG_CONG_UPDATE message, which is described in the following section.

### Polling
RDS supports the poll(2) interface in a limited fashion. POLLIN is returned when there is a message (either a proper RDS message, or a control message) waiting in the socket's receive queue. POLLOUT is always returned while there is room on the socket's send queue.

Sending to congested ports requires special handling. When an application tries to send to a congested destination, the system call will return ENOBUFS. However, it cannot poll for POLLOUT, as there is probably still room on the transmit queue, so the call to poll(2) would return immediately, even though the destination is still congested.

There are two ways of dealing with this situation. The first is to simply poll for POLLIN. By default, a process sleeping in poll(2) is always woken up when the congestion map is updated, and thus the application can retry any previously congested sends.

The second option is explicit congestion monitoring, which gives the application more fine-grained control.

With explicit monitoring, the application polls for POLLIN as before, and additionally uses the RDS_CONG_MONITOR socket option to install a 64bit mask value in the socket, where each bit corresponds to a group of ports. When a congestion update arrives, RDS checks the set of ports that became uncongested against the bit mask installed in the socket. If they overlap, a control messages is enqueued on the socket, and the application is woken up. When it calls recvmsg(2), it will be given the control message containing the bitmap. on the socket.

The congestion monitor bitmask can be set and queried using setsockopt(2) with RDS_CONG_MONITOR, and a pointer to the 64bit mask variable.

Congestion updates are delivered to the application via RDS_CMSG_CONG_UPDATE control messages. These control messages are always delivered by themselves (or possibly additional control messages), but never along with a RDS data message. The cmsg_data field of the control message is an 8 byte datum containing the 64bit mask value.

Applications can use the following macros to test for and set bits in the bitmask:

```
#define RDS_CONG_MONITOR_SIZE   64
#define RDS_CONG_MONITOR_BIT(port)  (((unsigned int) port) % RDS_CONG_MONITOR_SIZE)
#define RDS_CONG_MONITOR_MASK(port) (1 << RDS_CONG_MONITOR_BIT(port))
```

### Canceling Messages
An application can cancel (flush) messages from the send queue using the RDS_CANCEL_SENT_TO socket option with setsockopt(2). This call takes an optional sockaddr_in address structure as argument. If given, only messages to the destination specified by this address are discarded. If no address is given, all pending messages are discarded.

Note that this affects messages that have not yet been transmitted as well as messages that have been transmitted, but for which no acknowledgment from the remote host has been received yet.

### Reliability
If sendmsg(2) succeeds, RDS guarantees that the message will be visible to recvmsg(2) on a socket bound to the destination address as long as that destination socket remains open.

If there is no socket bound on the destination, the message is silently dropped. If the sending RDS can't be sure that there is no socket bound then it will try to send the message indefinitely until it can be sure or the sent message is canceled.

If a socket is closed then all pending sent messages on the socket are canceled and may or may not be seen by the receiver.

The RDS_CANCEL_SENT_TO socket option can be used to cancel all pending messages to a given destination.

If a receiving socket is closed with pending messages then the sender considers those messages as having left the network and will not retransmit them.

A message will only be seen by recvmsg(2) once, unless MSG_PEEK was specified. Once the message has been delivered it is removed from the sending socket's transmit queue.

All messages sent from the same socket to the same destination will be delivered in the order they're sent. Messages sent from different sockets, or to different destinations, may be delivered in any order.

## SYSCTL VALUES
These parameteres may only be accessed through their files in /proc/sys/net/rds. Access through sysctl(2) is not supported.

pf_rds

This file contains the string representation of the protocol family constant passed to socket(2) to create a new RDS socket.

sol_rds

This file contains the string representation of the socket level parameter that is passed to getsockopt(2) and setsockopt(2) to manipulate RDS socket options.

max_unacked_bytes and max_unacked_packets

These parameters are used to tune the generation of acknowledgements. By default, the system receiving RDS messages does not send back explicit acknowledgements unless it transmits a message of its own (in which case the ACK is piggybacked onto the outgoing message), or when the sending system requests an ACK.

However, the sender needs to see an ACK from time to time so that it can purge old messages from the send queue. The unacked bytes and packet counters are used to keep track of how much data has been sent without requesting an ACK. The default is to request an acknowledgement every 16 packets, or every 16 MB, whichever comes first.

reconnect_delay_min_ms and reconnect_delay_max_ms

RDS uses host-to-host connections to transport RDS messages (both for the TCP and the Infiniband transport). If this connection breaks, RDS will try to re-establish the connection. Because this reconnect may be triggered by both hosts at the same time and fail, RDS uses a random backoff before attempting a reconnect. These two parameters specify the minimum and maximum delay in milliseconds. The default values are 1 and 1000, respectively.

## SEE ALSO
rds-rdma(7), socket(2), bind(2), sendmsg(2), recvmsg(2), getsockopt(2), setsockopt(2).


rds-rdma

title: rds-rdma(7)

summary: Interface for RDMA over RDS

text:
# rds-rdma(7)

## NAME
RDS zerocopy - Interface for RDMA over RDS

## DESCRIPTION
This manual page describes the zerocopy interface of RDS, which was added in RDSv3. For a description of the basic RDS interface, please refer to rds(7).

The principal mode of operation for RDS zerocopy is like this: one participant (the client) wishes to initiate a direct transfer to or from some area of memory in its process address space. This memory does not have to be aligned.

The client obtains a handle for this region of memory, and passes it to the other participant (the server). This is called the RDMA cookie. To the application, the cookie is an opaque 64bit data type.

The client sends this handle to the server application, along with other details of the RDMA request (such as which data to transfer to that memory area). Throughout the following discussion, we will refer to this message as the RDMA request.

The server uses this RDMA cookie to initiate the requested RDMA transfer. The RDMA transfer is combined atomically with a normal RDS message, which is delivered to the client. This message is called the RDMA ACK throughout the following. Atomic in this context means that either both the RDMA succeeds and the RDMA ACK is delivered, or neither succeeds.

Thus, when the client receives the RDMA ACK, it knows that the RDMA has completed successfully. It can then release the RDMA cookie for this memory region, if it wishes to.

RDMA operations are not reliable, in the sense that unlike normal RDS messages, RDS RDMA operations may fail, and get dropped.

## INTERFACE
The interface is currently based on control messages (ancillary data) sent or received via the sendmsg(2) and recvmsg(2) system calls. Optionally, an older interface can be used that is based on the setsockopt(2) system call. However, we recommend using control messages, as this reduces the number of system calls required.

### Control message interface
With the control message interface, the RDMA cookie is passed to the server out-of-band, included in an extension header attached to the RDS message.

The following outlines the mode of operation; the data types used will be specified in details in a subsequent section.

Initially, the client will send RDMA requests along with a RDS_CMSG_RDMA_MAP control message. The control message contains the address and length of the memory region for which to obtain a handle, some flags, and a pointer to a memory location (in the caller's address space) where the kernel will store the RDMA cookie.

Alternatively, if the application has already obtained a RDMA cookie for the memory range it wants to RDMA to/from, it can hand this cookie to the kernel using the RDS_CMSG_RDMA_DEST control message.

Either way, the kernel will include the resulting RDMA cookie in an extension header that is transmitted as part of the RDMA request to the server.

When the server receives the RDMA request, the kernel will deliver the cookie wrapped inside a RDS_CMSG_RDMA_DEST control message.

The server then initiates the data transfer by sending the RDMA ACK message along with a RDS_CMSG_RDMA_ARGS control message. This message contains the RDMA cookie, and the local memory to copy to or from.

The server process may request a notification when an RDMA operation completes. Notifications are delivered as a RDS_CMSG_RDMA_STATUS control messages. When an application calls recvmsg(2), it will either receive a regular RDS message (possibly with other RDMA related control messages), or an empty message with one or more status control messages.

In addition, applications When an RDMA operation fails for some reason and is discarded, the application can ask to receive notifications for failed messages as well, regardless of whether it asked for success notification of an individual message or not. This behavior is turned on by setting the RDS_RECVERR socket option.

### Setsockopt interface
In addition to the control message interface, RDS allows a process to register and release memory ranges for RDMA through calls to setsockopt(2).

RDS_GET_MR

To obtain a RDMA cookie for a given memory range, the application can use setsockopt with RDS_GET_MR. This operates essentially the same way as the RDS_CMSG_RDMA_MAP control message: the argument contains the address and length of the memory range to be registered, and a pointer to a RDMA cookie variable, in which the system call will store the cookie for the registered range.

RDS_FREE_MR

Memory ranges can be released by calling setsockopt with RDS_FREE_MR, giving the RDMA cookie and additional flags as arguments.

RDS_RECVERR

This is a boolean option which can be set as well as queried (using getsockopt). When enabled, RDS will send RDMA notification messages to the application for any RDMA operation that fails. This option defaults to off.

For all of these calls, the level argument to setsockopt is SOL_RDS.

## RDMA MACROS AND TYPES

RDMA cookie

```
typedef u_int64_t       rds_rdma_cookie_t
```

This encapsulates a memory location in the client process. In the current implementation, it contains the R_Key of the remote memory region, and the offset into it (so that the application does not have to worry about alignment.

The RDMA cookie is used in several struct types described below. The RDS_CMSG_RDMA_DEST control message contains a rds_rdma_cookie_t all by itself as payload.

Mapping arguments

The following data type is used with RDS_CMSG_RDMA_MAP control messages and with the RDS_GET_MR socket option:

```
struct rds_iovec {

        u_int64_t       addr;

        u_int64_t       bytes;
};
struct rds_get_mr_args {

        struct rds_iovec vec;

        u_int64_t       cookie_addr;

        uint64_t        flags;
};
```

The cookie_addr specifies a memory location where to store the RDMA cookie.

The flags value is a bitwise OR of any of the following flags:

RDS_RDMA_USE_ONCE

This tells the kernel that the allocated RDMA cookie is to be used exactly once. When the RDMA ACK message arrives, the kernel will automatically unbind the memory area and release any resources associated with the cookie.

If this flag is not set, it is the application's responsibility to release the memory region at a later time using the RDS_FREE_MR socket option.

RDS_RDMA_INVALIDATE

Normally, RDMA memory mappings are invalidated lazily, as this requires some relatively costly synchronization with the HCA. However, this means that the server application can continue to access the registered memory for some indeterminate amount of time. If this flag is set, the RDS code will invalidate the mapping at the time it is released (either upon arrival of the RDMA ACK, if USE_ONCE was specified; or when the application destroys it using FREE_MR).

RDMA Operation

RDMA operations are initiated by the server using the RDS_CMSG_RDMA_ARGS control message, which takes the following data as payload:

```
struct rds_rdma_args {

        rds_rdma_cookie_t cookie;

        struct rds_iovec remote_vec;

        u_int64_t       local_vec_addr;

        u_int64_t       nr_local;

        u_int64_t       flags;

        u_int32_t       user_token;
};
```

The cookie argument contains the RDMA cookie received from the client. The local memory is given via an array of rds_iovecs. The array address is given in local_vec_addr, and its number of elements is given in nr_local.

The struct member remote_vec specifies a location relative to the memory area identified by the cookie: remote_vec.addr is an offset into that region, and remote_vec.bytes is the length of the memory window to copy to/from. This length must match the size of the local memory area, i.e. the sum of bytes in all members of the local iovec.

The flags field contains the bitwise OR of any of the following flags:

RDS_RDMA_READWRITE

If set, any RDMA WRITE is initiated from the server's memory to the client's. If not set, RDS will do a RDMA READ from the client's memory to the server's memory.

RDS_RDMA_FENCE

By default, Infiniband makes no guarantee about the ordering of an RDMA READ with respect to subsequent SEND operations. Setting this flag asks that the RDMA READ should be fenced off the subsequent RDS ACK message. Setting this flag requires an additional round-trip of the IB fabric, but it is a good idea to use set this flag by default, unless you are really sure you do not want it.

RDS_RDMA_NOTIFY_ME

This flag requests a notification upon completion of the RDMA operation (successful or otherwise). The noticiation will contain the value of the user_token field passed in by the application. This allows the application to release resources (such as buffers) assosicated with the RDMA transfer.

The user_token can be used to pass an application specific identifier to the kernel. This token is returned to the application when a status notification is generated (see the following section).

RDMA Notification

The RDS kernel code is able to notify the server application when an RDMA operation completes. These notifications are delivered via RDS_CMSG_RDMA_STATUS control messages.

By default, no notifications are generated. There are two ways an application can request them. On one hand, status notifications can be enabled on a per-operation basis by setting the RDS_RDMA_NOTIFY_ME flag in the RDMA arguments. On the other hand, the application can request notifications for all RDMA operations that fail by setting the RDS_RECVERR socket option (see below). In both cases, the format of the notification is the same; and at most one notification will be sent per completed operation.

The message format is this:

```
struct rds_rdma_notify {

        u_int32_t       user_token;

        int32_t         status;
};
```

The user_token field contains the value previously given to the kernel in the RDS_CMSG_RDMA_ARGS control message. The status field contains a status value, with 0 indicating success, and non-zero indicating an error.

The following status codes are currently defined:

RDS_RDMA_SUCCESS

The RDMA operation succeeded.

RDS_RDMA_REMOTE_ERROR

The RDMA operation failed due to a remote access error. This is usually due to an invalid R_key, offset or transfer size.

RDS_RDMA_CANCELED

The RDMA operation was canceled by the application. (This error code is not yet generated).

RDS_RDMA_DROPPED

RDMA operations were discarded after the connection broke and was re-established. The RDMA operation may have been processed partially.

RDS_RDMA_OTHER_ERROR

Any other failure.

RDMA setsockopt arguments

When using the RDS_GET_MR socket option to register a memory range, the application passes a pointer to a struct rds_get_mr_args variable, described above.

The RDS_FREE_MR call takes an argument of type struct rds_free_mr_args:

```
struct rds_free_mr_args {

        rds_rdma_cookie_t cookie;

        u_int64_t       flags;
};
```

cookie specifies the RDMA cookie to be released. RDMA access to the memory range will usually not be invoked instantly, because the operation is rather costly. However, if the flags argument contains RDS_RDMA_INVALIDATE, RDS will invalidate the indicated mapping immediately, as described in section Mapping arguments above.

If the cookie argument is 0, and RDS_RDMA_INVALIDATE is set, RDS will invalidate old memory mappings on all devices.

## ERRORS
In addition to the usual error codes returned by sendmsg, recvmsg and setsockopt, RDS returns the following error codes:

EAGAIN

RDS was unable to map a memory range because the limit was exceeded (returned by RDS_CMSG_RDMA_MAP and RDS_GET_MR).

EINVAL

When sending a message, there were were conflicting control messages (e.g. two RDMA_MAP messages, or a RDMA_MAP and a RDMA_DEST message).

In a RDS_CMSG_RDMA_MAP or RDS_GET_MR operation, the application specified memory range greater than the maximum size supported.

When setting up an RDMA operation with RDS_CMSG_RDMA_ARGS, the size of the local memory (given in the rds_iovec) did not match the size of the remote memory range.

EBUSY

RDS was unable to obtain a DMA mapping for the indicated memory.

## LIMITS
Currently, the following limits apply

- The maximum size of a zerocopy transfer is 1MB. This can be adjusted via the fmr_message_size module parameter.

- The maximum number of memory ranges that can be mapped is limited to 2048 at the moment. This can be adjusted via the fmr_pool_size module parameter. However, the actual limit imposed by the hardware may in fact be lower.

## AUTHORS
RDS was written and is Copyright (C) 2007-2008 by Oracle, Inc.


package: resource-agents

title: ocf_heartbeat_AoEtarget(7)

summary: Manages ATA\-over\-Ethernet (AoE) target exports

text:
# ocf_heartbeat_AoEtarget(7)

## NAME
ocf_heartbeat_AoEtarget - Manages ATA-over-Ethernet (AoE) target exports

## SYNOPSIS
AoEtarget [start | stop | monitor | meta-data | validate-all]

## DESCRIPTION
This resource agent manages an ATA-over-Ethernet (AoE) target using vblade. It exports any block device, or file, as an AoE target using the specified Ethernet device, shelf, and slot number.

## SUPPORTED PARAMETERS
device

The local block device (or file) to export as an AoE target. (required, string, no default)

nic

The local Ethernet interface to use for exporting this AoE target. (required, string, default "eth0")

shelf

The AoE shelf number to use when exporting this target. (optional, integer, no default)

slot

The AoE slot number to use when exporting this target. (required, integer, no default)

pid

The file to record the daemon pid to. (unique, optional, string, default "/var/run/resource-agents/AoEtarget-RESOURCE_ID.pid")

binary

Location of the vblade binary. (optional, string, default "/usr/sbin/vblade")

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 15s.

stop

Stops the resource. Suggested minimum timeout: 15s.

monitor

Performs a detailed status check. Suggested minimum timeout: 15s. Suggested interval: 10s.

reload

Suggested minimum timeout: 15s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 15s.

## EXAMPLE CRM SHELL
The following is an example configuration for a AoEtarget resource using the crm(8) shell:

```
primitive p_AoEtarget ocf:heartbeat:AoEtarget \

  params \

    device=string \

    nic="eth0" \

    slot=integer \

  op monitor timeout="15s" interval="10s" depth="0"
```

## EXAMPLE PCS
The following is an example configuration for a AoEtarget resource using pcs(8)

```
pcs resource create p_AoEtarget ocf:heartbeat:AoEtarget \

  device=string \

  nic="eth0" \

  slot=integer \

  op monitor timeout="15s" interval="10s" OCF_CHECK_LEVEL="0"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_AudibleAlarm(7)

text:
# ocf_heartbeat_AudibleAlarm(7)

## NAME
ocf_heartbeat_AudibleAlarm - Emits audible beeps at a configurable interval

## SYNOPSIS
AudibleAlarm [start | stop | status | monitor | meta-data | validate-all]

## DESCRIPTION
Resource script for AudibleAlarm. It sets an audible alarm running by beeping at a set interval.

## SUPPORTED PARAMETERS
nodelist

The node list that should never sound the alarm. (optional, string, no default)

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 10s.

stop

Stops the resource. Suggested minimum timeout: 10s.

restart

Suggested minimum timeout: 10s.

status

Performs a status check. Suggested minimum timeout: 10s. Suggested interval: 10s.

monitor

Performs a detailed status check. Suggested minimum timeout: 10s. Suggested interval: 10s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 5s.

## EXAMPLE CRM SHELL
The following is an example configuration for a AudibleAlarm resource using the crm(8) shell:

```
primitive p_AudibleAlarm ocf:heartbeat:AudibleAlarm \

  op monitor depth="0" timeout="10s" interval="10s"
```

## EXAMPLE PCS
The following is an example configuration for a AudibleAlarm resource using pcs(8)

```
pcs resource create p_AudibleAlarm ocf:heartbeat:AudibleAlarm \

  op monitor OCF_CHECK_LEVEL="0" timeout="10s" interval="10s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_ClusterMon(7)

text:
# ocf_heartbeat_ClusterMon(7)

## NAME
ocf_heartbeat_ClusterMon - Runs crm_mon in the background, recording the cluster status to an HTML file

## SYNOPSIS
ClusterMon [start | stop | monitor | meta-data | validate-all]

## DESCRIPTION
This is a ClusterMon Resource Agent. It outputs current cluster status to the html.

## SUPPORTED PARAMETERS
user

The user we want to run crm_mon as (optional, string, default "root")

update

How frequently should we update the cluster status (optional, integer, default 15000)

extra_options

Additional options to pass to crm_mon. Eg. -n -r (optional, string, no default)

pidfile

PID file location to ensure only one instance is running (unique, optional, string, default "/var/run/resource-agents/ClusterMon_RESOURCE_ID.pid")

htmlfile

Location to write HTML output to. (unique, optional, string, default "/var/run/resource-agents/ClusterMon_RESOURCE_ID.html")

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 20s.

stop

Stops the resource. Suggested minimum timeout: 20s.

monitor

Performs a detailed status check. Suggested minimum timeout: 20s. Suggested interval: 10s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 30s.

## EXAMPLE CRM SHELL
The following is an example configuration for a ClusterMon resource using the crm(8) shell:

```
primitive p_ClusterMon ocf:heartbeat:ClusterMon \

  op monitor depth="0" timeout="20s" interval="10s"
```

## EXAMPLE PCS
The following is an example configuration for a ClusterMon resource using pcs(8)

```
pcs resource create p_ClusterMon ocf:heartbeat:ClusterMon \

  op monitor OCF_CHECK_LEVEL="0" timeout="20s" interval="10s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_Delay(7)

summary: Waits for a defined timespan

text:
# ocf_heartbeat_Delay(7)

## NAME
ocf_heartbeat_Delay - Waits for a defined timespan

## SYNOPSIS
Delay [start | stop | status | monitor | meta-data | validate-all]

## DESCRIPTION
This script is a test resource for introducing delay.

## SUPPORTED PARAMETERS
startdelay

How long in seconds to delay on start operation. (optional, integer, default 20)

stopdelay

How long in seconds to delay on stop operation. Defaults to "startdelay" if unspecified. (optional, integer, default 30)

mondelay

How long in seconds to delay on monitor operation. Defaults to "startdelay" if unspecified. (optional, integer, default 30)

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 30s.

stop

Stops the resource. Suggested minimum timeout: 30s.

status

Performs a status check. Suggested minimum timeout: 30s. Suggested interval: 10s.

monitor

Performs a detailed status check. Suggested minimum timeout: 30s. Suggested interval: 10s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 5s.

## EXAMPLE CRM SHELL
The following is an example configuration for a Delay resource using the crm(8) shell:

```
primitive p_Delay ocf:heartbeat:Delay \

  op monitor depth="0" timeout="30s" interval="10s"
```

## EXAMPLE PCS
The following is an example configuration for a Delay resource using pcs(8)

```
pcs resource create p_Delay ocf:heartbeat:Delay \

  op monitor OCF_CHECK_LEVEL="0" timeout="30s" interval="10s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_Dummy(7)

summary: Example stateless resource agent

text:
# ocf_heartbeat_Dummy(7)

## NAME
ocf_heartbeat_Dummy - Example stateless resource agent

## SYNOPSIS
Dummy [start | stop | monitor | migrate_to | migrate_from | meta-data | validate-all]

## DESCRIPTION
This is a Dummy Resource Agent. It does absolutely nothing except keep track of whether its running or not. Its purpose in life is for testing and to serve as a template for RA writers.

NB: Please pay attention to the timeouts specified in the actions section below. They should be meaningful for the kind of resource the agent manages. They should be the minimum advised timeouts, but they shouldn't/cannot cover _all_ possible resource instances. So, try to be neither overly generous nor too stingy, but moderate. The minimum timeouts should never be below 10 seconds.

This resource agent may be configured for native migration if available in the cluster manager. For Pacemaker, the allow-migrate="true" meta attribute enables native migration.

## SUPPORTED PARAMETERS
state

Location to store the resource state in. (unique, optional, string, default "/var/run/resource-agents/Dummy-RESOURCE_ID.state")

fake

Fake attribute that can be changed to cause a reload (optional, string, default "dummy")

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 20s.

stop

Stops the resource. Suggested minimum timeout: 20s.

monitor

Performs a detailed status check. Suggested minimum timeout: 20s. Suggested interval: 10s.

reload

Suggested minimum timeout: 20s.

migrate_to

Executes steps necessary for migrating the resource to the node. Suggested minimum timeout: 20s.

migrate_from

Executes steps necessary for migrating the resource away from the node. Suggested minimum timeout: 20s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 20s.

## EXAMPLE CRM SHELL
The following is an example configuration for a Dummy resource using the crm(8) shell:

```
primitive p_Dummy ocf:heartbeat:Dummy \

  meta allow-migrate="true" \

  op monitor timeout="20s" interval="10s" depth="0"
```

## EXAMPLE PCS
The following is an example configuration for a Dummy resource using pcs(8)

```
pcs resource create p_Dummy ocf:heartbeat:Dummy \

  op monitor timeout="20s" interval="10s" OCF_CHECK_LEVEL="0"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_EvmsSCC(7)

text:
# ocf_heartbeat_EvmsSCC(7)

## NAME
ocf_heartbeat_EvmsSCC - Manages EVMS Shared Cluster Containers (SCCs) (deprecated)

## SYNOPSIS
EvmsSCC [start | stop | status | monitor | meta-data]

## DESCRIPTION
Deprecation warning: EVMS is no longer actively maintained and should not be used. This agent is deprecated and may be removed from a future release. -- Resource script for EVMS shared cluster container. It runs evms_activate on one node in the cluster.

## SUPPORTED PARAMETERS
ignore_deprecation

If set to true, suppresses the deprecation warning for this agent. (optional, boolean, default false)

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 60s.

stop

Stops the resource. Suggested minimum timeout: 60s.

notify

Suggested minimum timeout: 60s.

status

Performs a status check. Suggested minimum timeout: 10s. Suggested interval: 10s.

monitor

Performs a detailed status check. Suggested minimum timeout: 10s. Suggested interval: 10s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

## EXAMPLE CRM SHELL
The following is an example configuration for a EvmsSCC resource using the crm(8) shell:

```
primitive p_EvmsSCC ocf:heartbeat:EvmsSCC \

  op monitor depth="0" timeout="10s" interval="10s"
```

## EXAMPLE PCS
The following is an example configuration for a EvmsSCC resource using pcs(8)

```
pcs resource create p_EvmsSCC ocf:heartbeat:EvmsSCC \

  op monitor OCF_CHECK_LEVEL="0" timeout="10s" interval="10s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_Evmsd(7)

text:
# ocf_heartbeat_Evmsd(7)

## NAME
ocf_heartbeat_Evmsd - Controls clustered EVMS volume management (deprecated)

## SYNOPSIS
Evmsd [start | stop | monitor | meta-data]

## DESCRIPTION
Deprecation warning: EVMS is no longer actively maintained and should not be used. This agent is deprecated and may be removed from a future release. -- This is a Evmsd Resource Agent.

## SUPPORTED PARAMETERS
ignore_deprecation

If set to true, suppresses the deprecation warning for this agent. (optional, boolean, default false)

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 20s.

stop

Stops the resource. Suggested minimum timeout: 20s.

monitor

Performs a detailed status check. Suggested minimum timeout: 20s. Suggested interval: 10s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

## EXAMPLE CRM SHELL
The following is an example configuration for a Evmsd resource using the crm(8) shell:

```
primitive p_Evmsd ocf:heartbeat:Evmsd \

  op monitor timeout="20s" interval="10s" depth="0"
```

## EXAMPLE PCS
The following is an example configuration for a Evmsd resource using pcs(8)

```
pcs resource create p_Evmsd ocf:heartbeat:Evmsd \

  op monitor timeout="20s" interval="10s" OCF_CHECK_LEVEL="0"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_Filesystem(7)

summary: Manages filesystem mounts

text:
# ocf_heartbeat_Filesystem(7)

## NAME
ocf_heartbeat_Filesystem - Manages filesystem mounts

## SYNOPSIS
Filesystem [start | stop | monitor | meta-data | validate-all]

## DESCRIPTION
Resource script for Filesystem. It manages a Filesystem on a shared storage medium.

The standard monitor operation of depth 0 (also known as probe) checks if the filesystem is mounted. If you want deeper tests, set OCF_CHECK_LEVEL to one of the following values:

10: read first 16 blocks of the device (raw read)

This doesn't exercise the filesystem at all, but the device on which the filesystem lives. This is noop for non-block devices such as NFS, SMBFS, or bind mounts.

20: test if a status file can be written and read

The status file must be writable by root. This is not always the case with an NFS mount, as NFS exports usually have the "root_squash" option set. In such a setup, you must either use read-only monitoring (depth=10), export with "no_root_squash" on your NFS server, or grant world write permissions on the directory where the status file is to be placed.

## SUPPORTED PARAMETERS
device

The name of block device for the filesystem, or -U, -L options for mount, or NFS mount specification. (required, string, no default)

directory

The mount point for the filesystem. (required, string, no default)

fstype

The type of filesystem to be mounted. (required, string, no default)

options

Any extra options to be given as -o options to mount. For bind mounts, add "bind" here and set fstype to "none". We will do the right thing for options such as "bind,ro".

(optional, string, no default)

statusfile_prefix

The prefix to be used for a status file for resource monitoring with depth 20. If you don't specify this parameter, all status files will be created in a separate directory. (optional, string, default ".Filesystem_status/")

run_fsck

Specify how to decide whether to run fsck or not. "auto" : decide to run fsck depending on the fstype(default) "force" : always run fsck regardless of the fstype "no" : do not run fsck ever.

(optional, string, default "auto")

fast_stop

Normally, we expect no users of the filesystem and the stop operation to finish quickly. If you cannot control the filesystem users easily and want to prevent the stop action from failing, then set this parameter to "no" and add an appropriate timeout for the stop operation. This defaults to "no" for GFS2 filesystems.

(optional, boolean, default no)

force_clones

The use of a clone setup for local filesystems is forbidden by default. For special setups like glusterfs, cloning a mount of a local device with a filesystem like ext4 or xfs independently on several nodes is a valid use case. Only set this to "true" if you know what you are doing!

(optional, boolean, default false)

force_unmount

This option allows specifying how to handle processes that are currently accessing the mount directory. "true" : Kill processes accessing mount point "safe" : Kill processes accessing mount point using methods that avoid functions that could potentially block during process detection "false" : Do not kill any processes.

The 'safe' option uses shell logic to walk the /procs/ directory for pids using the mount point while the default option uses the fuser cli tool. fuser is known to perform operations that can potentially block if unresponsive nfs mounts are in use on the system.

(optional, boolean, default true)

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 60s.

stop

Stops the resource. Suggested minimum timeout: 60s.

monitor

Performs a detailed status check. Suggested minimum timeout: 40s. Suggested interval: 20s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 5s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

## EXAMPLE CRM SHELL
The following is an example configuration for a Filesystem resource using the crm(8) shell:

```
primitive p_Filesystem ocf:heartbeat:Filesystem \

  params \

    device=string \

    directory=string \

    fstype=string \

  op monitor depth="0" timeout="40s" interval="20s"
```

## EXAMPLE PCS
The following is an example configuration for a Filesystem resource using pcs(8)

```
pcs resource create p_Filesystem ocf:heartbeat:Filesystem \

  device=string \

  directory=string \

  fstype=string \

  op monitor OCF_CHECK_LEVEL="0" timeout="40s" interval="20s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_ICP(7)

text:
# ocf_heartbeat_ICP(7)

## NAME
ocf_heartbeat_ICP - Manages an ICP Vortex clustered host drive

## SYNOPSIS
ICP [start | stop | status | monitor | meta-data | validate-all]

## DESCRIPTION
Resource script for ICP. It Manages an ICP Vortex clustered host drive as an HA resource.

## SUPPORTED PARAMETERS
driveid

The ICP cluster drive ID. (required, string, no default)

device

The device name. (required, string, no default)

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 20s.

stop

Stops the resource. Suggested minimum timeout: 20s.

status

Performs a status check. Suggested minimum timeout: 20s. Suggested interval: 10s.

monitor

Performs a detailed status check. Suggested minimum timeout: 20s. Suggested interval: 10s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 5s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

## EXAMPLE CRM SHELL
The following is an example configuration for a ICP resource using the crm(8) shell:

```
primitive p_ICP ocf:heartbeat:ICP \

  params \

    driveid=string \

    device=string \

  op monitor depth="0" timeout="20s" interval="10s"
```

## EXAMPLE PCS
The following is an example configuration for a ICP resource using pcs(8)

```
pcs resource create p_ICP ocf:heartbeat:ICP \

  driveid=string \

  device=string \

  op monitor OCF_CHECK_LEVEL="0" timeout="20s" interval="10s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_IPaddr(7)

text:
# ocf_heartbeat_IPaddr(7)

## NAME
ocf_heartbeat_IPaddr - Manages virtual IPv4 addresses (portable version)

## SYNOPSIS
IPaddr [start | stop | monitor | meta-data | validate-all]

## DESCRIPTION
This script manages IP alias IP addresses It can add an IP alias, or remove one.

## SUPPORTED PARAMETERS
ip

The IPv4 address to be configured in dotted quad notation, for example "192.168.1.1". (unique, required, string, no default)

nic

The base network interface on which the IP address will be brought online. If left empty, the script will try and determine this from the routing table.

Do NOT specify an alias interface in the form eth0:1 or anything here; rather, specify the base interface only.

Prerequisite:

There must be at least one static IP address, which is not managed by the cluster, assigned to the network interface.

If you can not assign any static IP address on the interface, modify this kernel parameter: sysctl -w net.ipv4.conf.all.promote_secondaries=1 (or per device)

(optional, string, default "eth0")

cidr_netmask

The netmask for the interface in CIDR format. (ie, 24), or in dotted quad notation 255.255.255.0). If unspecified, the script will also try to determine this from the routing table.

(optional, string, no default)

broadcast

Broadcast address associated with the IP. If left empty, the script will determine this from the netmask. (optional, string, no default)

iflabel

You can specify an additional label for your IP address here. (optional, string, no default)

lvs_support

Enable support for LVS Direct Routing configurations. In case a IP address is stopped, only move it to the loopback device to allow the local node to continue to service requests, but no longer advertise it on the network. (optional, boolean, default false)

local_stop_script

Script called when the IP is released (optional, string, no default)

local_start_script

Script called when the IP is added (optional, string, no default)

ARP_INTERVAL_MS

milliseconds between ARPs (optional, integer, default 500)

ARP_REPEAT

How many gratuitous ARPs to send out when bringing up a new address (optional, integer, default 10)

ARP_BACKGROUND

run in background (no longer any reason to do this) (optional, boolean, default yes)

ARP_NETMASK

netmask for ARP - in nonstandard hexadecimal format. (optional, string, default "ffffffffffff")

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 20s.

stop

Stops the resource. Suggested minimum timeout: 20s.

monitor

Performs a detailed status check. Suggested minimum timeout: 20s. Suggested interval: 5s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 20s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

## EXAMPLE CRM SHELL
The following is an example configuration for a IPaddr resource using the crm(8) shell:

```
primitive p_IPaddr ocf:heartbeat:IPaddr \

  params \

    ip=string \

  op monitor depth="0" timeout="20s" interval="5s"
```

## EXAMPLE PCS
The following is an example configuration for a IPaddr resource using pcs(8)

```
pcs resource create p_IPaddr ocf:heartbeat:IPaddr \

  ip=string \

  op monitor OCF_CHECK_LEVEL="0" timeout="20s" interval="5s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_IPaddr2(7)

text:
# ocf_heartbeat_IPaddr2(7)

## NAME
ocf_heartbeat_IPaddr2 - Manages virtual IPv4 and IPv6 addresses (Linux specific version)

## SYNOPSIS
IPaddr2 [start | stop | status | monitor | meta-data | validate-all]

## DESCRIPTION
This Linux-specific resource manages IP alias IP addresses. It can add an IP alias, or remove one. In addition, it can implement Cluster Alias IP functionality if invoked as a clone resource.

If used as a clone, "shared address with a trivial, stateless (autonomous) load-balancing/mutual exclusion on ingress" mode gets applied (as opposed to "assume resource uniqueness" mode otherwise). For that, Linux firewall (kernel and userspace) is assumed, and since recent distributions are ambivalent in plain "iptables" command to particular back-end resolution, "iptables-legacy" (when present) gets prioritized so as to avoid incompatibilities (note that respective ipt_CLUSTERIP firewall extension in use here is, at the same time, marked deprecated, yet said "legacy" layer can make it workable, literally, to this day) with "netfilter" one (as in "iptables-nft"). In that case, you should explicitly set clone-node-max >= 2, and/or clone-max < number of nodes. In case of node failure, clone instances need to be re-allocated on surviving nodes. This would not be possible if there is already an instance on those nodes, and clone-node-max=1 (which is the default).

## SUPPORTED PARAMETERS
ip

The IPv4 (dotted quad notation) or IPv6 address (colon hexadecimal notation) example IPv4 "192.168.1.1". example IPv6 "2001:db8:DC28:0:0:FC57:D4C8:1FFF". (unique, required, string, no default)

nic

The base network interface on which the IP address will be brought online. If left empty, the script will try and determine this from the routing table. Do NOT specify an alias interface in the form eth0:1 or anything here; rather, specify the base interface only. If you want a label, see the iflabel parameter.

Prerequisite:

There must be at least one static IP address, which is not managed by the cluster, assigned to the network interface. If you can not assign any static IP address on the interface, modify this kernel parameter:

sysctl -w net.ipv4.conf.all.promote_secondaries=1 # (or per device)

(optional, string, no default)

cidr_netmask

The netmask for the interface in CIDR format (e.g., 24 and not 255.255.255.0) If unspecified, the script will also try to determine this from the routing table.

(optional, string, no default)

broadcast

Broadcast address associated with the IP. It is possible to use the special symbols '+' and '-' instead of the broadcast address. In this case, the broadcast address is derived by setting/resetting the host bits of the interface prefix. (optional, string, no default)

iflabel

You can specify an additional label for your IP address here. This label is appended to your interface name. The kernel allows alphanumeric labels up to a maximum length of 15 characters including the interface name and colon (e.g. eth0:foobar1234)

A label can be specified in nic parameter but it is deprecated. If a label is specified in nic name, this parameter has no effect.

(optional, string, no default)

lvs_support

Enable support for LVS Direct Routing configurations. In case a IP address is stopped, only move it to the loopback device to allow the local node to continue to service requests, but no longer advertise it on the network. Notes for IPv6: It is not necessary to enable this option on IPv6. Instead, enable 'lvs_ipv6_addrlabel' option for LVS-DR usage on IPv6.

(optional, boolean, default false)

lvs_ipv6_addrlabel

Enable adding IPv6 address label so IPv6 traffic originating from the address's interface does not use this address as the source. This is necessary for LVS-DR health checks to realservers to work. Without it, the most recently added IPv6 address (probably the address added by IPaddr2) will be used as the source address for IPv6 traffic from that interface and since that address exists on loopback on the realservers, the realserver response to pings/connections will never leave its loopback. See RFC3484 for the detail of the source address selection. See also 'lvs_ipv6_addrlabel_value' parameter.

(optional, boolean, default false)

lvs_ipv6_addrlabel_value

Specify IPv6 address label value used when 'lvs_ipv6_addrlabel' is enabled. The value should be an unused label in the policy table which is shown by 'ip addrlabel list' command. You would rarely need to change this parameter. (optional, integer, default 99)

mac

Set the interface MAC address explicitly. Currently only used in case of the Cluster IP Alias. Leave empty to chose automatically. (optional, string, no default)

clusterip_hash

Specify the hashing algorithm used for the Cluster IP functionality. (optional, string, default "sourceip-sourceport")

unique_clone_address

If true, add the clone ID to the supplied value of IP to create a unique address to manage (optional, boolean, default false)

arp_interval

Specify the interval between unsolicited ARP packets in milliseconds. This parameter is deprecated and used for the backward compatibility only. It is effective only for the send_arp binary which is built with libnet, and send_ua for IPv6. It has no effect for other arp_sender.

(optional, integer, default 200)

arp_count

Number of unsolicited ARP packets to send at resource initialization. (optional, integer, default 5)

arp_count_refresh

Number of unsolicited ARP packets to send during resource monitoring. Doing so helps mitigate issues of stuck ARP caches resulting from split-brain situations. (optional, integer, default 0)

arp_bg

Whether or not to send the ARP packets in the background. (optional, string, default "true")

arp_sender

The program to send ARP packets with on start. Available options are: - send_arp: default - ipoibarping: default for infiniband interfaces if ipoibarping is available - iputils_arping: use arping in iputils package - libnet_arping: use another variant of arping based on libnet (optional, string, no default)

send_arp_opts

Extra options to pass to the arp_sender program. Available options are vary depending on which arp_sender is used. A typical use case is specifying '-A' for iputils_arping to use ARP REPLY instead of ARP REQUEST as Gratuitous ARPs.

(optional, string, no default)

flush_routes

Flush the routing table on stop. This is for applications which use the cluster IP address and which run on the same physical host that the IP address lives on. The Linux kernel may force that application to take a shortcut to the local loopback interface, instead of the interface the address is really bound to. Under those circumstances, an application may, somewhat unexpectedly, continue to use connections for some time even after the IP address is deconfigured. Set this parameter in order to immediately disable said shortcut when the IP address goes away. (optional, boolean, default false)

run_arping

Whether or not to run arping for IPv4 collision detection check. (optional, string, default "false")

noprefixroute

Use noprefixroute flag (see 'man ip-address'). (optional, string, default "false")

preferred_lft

For IPv6, set the preferred lifetime of the IP address. This can be used to ensure that the created IP address will not be used as a source address for routing. Expects a value as specified in section 5.5.4 of RFC 4862. (optional, string, default "forever")

network_namespace

Specifies the network namespace to operate within. The namespace must already exist, and the interface to be used must be within the namespace. (optional, string, no default)

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 20s.

stop

Stops the resource. Suggested minimum timeout: 20s.

status

Performs a status check. Suggested minimum timeout: 20s. Suggested interval: 10s.

monitor

Performs a detailed status check. Suggested minimum timeout: 20s. Suggested interval: 10s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 20s.

## EXAMPLE CRM SHELL
The following is an example configuration for a IPaddr2 resource using the crm(8) shell:

```
primitive p_IPaddr2 ocf:heartbeat:IPaddr2 \

  params \

    ip=string \

  op monitor depth="0" timeout="20s" interval="10s"
```

## EXAMPLE PCS
The following is an example configuration for a IPaddr2 resource using pcs(8)

```
pcs resource create p_IPaddr2 ocf:heartbeat:IPaddr2 \

  ip=string \

  op monitor OCF_CHECK_LEVEL="0" timeout="20s" interval="10s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_IPsrcaddr(7)

text:
# ocf_heartbeat_IPsrcaddr(7)

## NAME
ocf_heartbeat_IPsrcaddr - Manages the preferred source address for outgoing IP packets

## SYNOPSIS
IPsrcaddr [start | stop | monitor | meta-data | validate-all]

## DESCRIPTION
Resource script for IPsrcaddr. It manages the preferred source address modification.

## SUPPORTED PARAMETERS
ipaddress

The IP address. (required, string, no default)

cidr_netmask

The netmask for the interface in CIDR format. (ie, 24), or in dotted quad notation 255.255.255.0). (optional, string, no default)

destination

The destination IP/subnet for the route (default: 0.0.0.0/0) (optional, string, default "0.0.0.0/0")

proto

Proto to match when finding network. E.g. "kernel". (optional, string, no default)

table

Table to modify. E.g. "local". The table has to have a route matching the "destination" parameter.

(optional, string, no default)

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 20s.

stop

Stops the resource. Suggested minimum timeout: 20s.

monitor

Performs a detailed status check. Suggested minimum timeout: 20s. Suggested interval: 10s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 5s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

## EXAMPLE CRM SHELL
The following is an example configuration for a IPsrcaddr resource using the crm(8) shell:

```
primitive p_IPsrcaddr ocf:heartbeat:IPsrcaddr \

  params \

    ipaddress=string \

  op monitor depth="0" timeout="20s" interval="10s"
```

## EXAMPLE PCS
The following is an example configuration for a IPsrcaddr resource using pcs(8)

```
pcs resource create p_IPsrcaddr ocf:heartbeat:IPsrcaddr \

  ipaddress=string \

  op monitor OCF_CHECK_LEVEL="0" timeout="20s" interval="10s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_LVM-activate(7)

text:
# ocf_heartbeat_LVM-activate(7)

## NAME
ocf_heartbeat_LVM-activate - This agent activates/deactivates logical volumes.

## SYNOPSIS
LVM-activate [start | stop | monitor | meta-data | validate-all]

## DESCRIPTION
This agent manages LVM activation/deactivation work for a given volume group.

It supports the following modes, controlled by the vg_access_mode parameter:

* lvmlockd * system_id * clvmd * tagging

Notes:

1. There are two possible configuration combinations: lvmlockd+LVM-activate and clvm+LVM-activate. However, it is not possible to use both at the same time!

2. Put all "lvmlockd"/"clvmd" volume groups into auto management by the agent if using the cluster to manage at least one of them. If you manage some manually, the stop action of the lvmlockd agent may fail and the node may get fenced, because some DLM lockspaces might be in use and cannot be closed automatically.

3. The autoactivation property of volume group will be disabled when vg_access_mode is set to system_id.

Option: OCF_CHECK_LEVEL

The standard monitor operation of depth 0 checks if the VG or LV is valid. If you want deeper tests, set OCF_CHECK_LEVEL to 10:

10: read first 1 byte of the underlying device (raw read)

If there are many underlying devs in VG, it will only read one of the devs. This is not perfect solution for detecting underlying devices livable. e.g. iscsi SAN IO timeout will return EIO, and it makes monitor failed.

## SUPPORTED PARAMETERS
vgname

The volume group name. (required, string, no default)

lvname

If set, only the specified LV will be activated. (optional, string, no default)

vg_access_mode

This option decides which solution will be used to protect the volume group in cluster environment. Optional solutions are: lvmlockd, clvmd, system_id and tagging. (required, string, no default)

activation_mode

The activation mode decides the visibility of logical volumes in the cluster. There are two different modes: "shared" for cluster filesystem and "exclusive" for local filesystem. With "shared", an LV can be activated concurrently from multiple nodes. With "exclusive", an LV can be activated by one node at a time. This option only has effect on "lvmlockd"/"clvmd" vg_access_mode. For "system_id" and "tagging", they always mean exclusive activation.

(optional, string, default "exclusive")

tag

The tag used for tagging activation mode. (optional, string, default "pacemaker")

partial_activation

If set, the volume group will be activated partially even with some physical volumes missing. It helps to set to true when using mirrored logical volumes. (optional, string, default "false")

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 90s.

stop

Stops the resource. Suggested minimum timeout: 90s.

monitor

Performs a detailed status check. Suggested minimum timeout: 90s. Suggested interval: 30s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 10s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 20s.

## EXAMPLE CRM SHELL
The following is an example configuration for a LVM-activate resource using the crm(8) shell:

```
primitive p_LVM-activate ocf:heartbeat:LVM-activate \

  params \

    vgname=string \

    vg_access_mode=string \

  op monitor timeout="90s" interval="30s" depth="0"
```

## EXAMPLE PCS
The following is an example configuration for a LVM-activate resource using pcs(8)

```
pcs resource create p_LVM-activate ocf:heartbeat:LVM-activate \

  vgname=string \

  vg_access_mode=string \

  op monitor timeout="90s" interval="30s" OCF_CHECK_LEVEL="0"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_LinuxSCSI(7)

summary: Enables and disables SCSI devices through the kernel SCSI hot\-plug subsystem (deprecated)

text:
# ocf_heartbeat_LinuxSCSI(7)

## NAME
ocf_heartbeat_LinuxSCSI - Enables and disables SCSI devices through the kernel SCSI hot-plug subsystem (deprecated)

## SYNOPSIS
LinuxSCSI [start | stop | status | monitor | meta-data | validate-all]

## DESCRIPTION
Deprecation warning: This agent makes use of Linux SCSI hot-plug functionality which has been superseded by SCSI reservations. It is deprecated and may be removed from a future release. See the scsi2reservation and sfex agents for alternatives. -- This is a resource agent for LinuxSCSI. It manages the availability of a SCSI device from the point of view of the linux kernel. It make Linux believe the device has gone away, and it can make it come back again.

## SUPPORTED PARAMETERS
scsi

The SCSI instance to be managed. (required, string, no default)

ignore_deprecation

If set to true, suppresses the deprecation warning for this agent. (optional, boolean, default false)

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 20s.

stop

Stops the resource. Suggested minimum timeout: 20s.

methods

Suggested minimum timeout: 5s.

status

Performs a status check. Suggested minimum timeout: 20s. Suggested interval: 10s.

monitor

Performs a detailed status check. Suggested minimum timeout: 20s. Suggested interval: 10s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 5s.

## EXAMPLE CRM SHELL
The following is an example configuration for a LinuxSCSI resource using the crm(8) shell:

```
primitive p_LinuxSCSI ocf:heartbeat:LinuxSCSI \

  params \

    scsi=string \

  op monitor depth="0" timeout="20s" interval="10s"
```

## EXAMPLE PCS
The following is an example configuration for a LinuxSCSI resource using pcs(8)

```
pcs resource create p_LinuxSCSI ocf:heartbeat:LinuxSCSI \

  scsi=string \

  op monitor OCF_CHECK_LEVEL="0" timeout="20s" interval="10s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_MailTo(7)

text:
# ocf_heartbeat_MailTo(7)

## NAME
ocf_heartbeat_MailTo - Notifies recipients by email in the event of resource takeover

## SYNOPSIS
MailTo [start | stop | status | monitor | meta-data | validate-all]

## DESCRIPTION
This is a resource agent for MailTo. It sends email to a sysadmin whenever a takeover occurs.

## SUPPORTED PARAMETERS
email

The email address of sysadmin. (required, string, no default)

subject

The subject of the email. (optional, string, default "Resource Group")

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 10s.

stop

Stops the resource. Suggested minimum timeout: 10s.

status

Performs a status check. Suggested minimum timeout: 10s. Suggested interval: 10s.

monitor

Performs a detailed status check. Suggested minimum timeout: 10s. Suggested interval: 10s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 5s.

## EXAMPLE CRM SHELL
The following is an example configuration for a MailTo resource using the crm(8) shell:

```
primitive p_MailTo ocf:heartbeat:MailTo \

  params \

    email=string \

  op monitor depth="0" timeout="10s" interval="10s"
```

## EXAMPLE PCS
The following is an example configuration for a MailTo resource using pcs(8)

```
pcs resource create p_MailTo ocf:heartbeat:MailTo \

  email=string \

  op monitor OCF_CHECK_LEVEL="0" timeout="10s" interval="10s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)


title: ocf_heartbeat_ManageRAID(7)

summary: Manages RAID devices

text:
# ocf_heartbeat_ManageRAID(7)

## NAME
ocf_heartbeat_ManageRAID - Manages RAID devices

## SYNOPSIS
ManageRAID [start | stop | status | monitor | meta-data | validate-all]

## DESCRIPTION
Manages starting, stopping and monitoring of RAID devices which are preconfigured in /etc/conf.d/HB-ManageRAID.

## SUPPORTED PARAMETERS
raidname

Name (case sensitive) of RAID to manage. (preconfigured in /etc/conf.d/HB-ManageRAID) (required, string, no default)

## SUPPORTED ACTIONS
This resource agent supports the following actions (operations):

start

Starts the resource. Suggested minimum timeout: 75s.

stop

Stops the resource. Suggested minimum timeout: 75s.

status

Performs a status check. Suggested minimum timeout: 10s. Suggested interval: 10s.

monitor

Performs a detailed status check. Suggested minimum timeout: 10s. Suggested interval: 10s.

validate-all

Performs a validation of the resource configuration. Suggested minimum timeout: 5s.

meta-data

Retrieves resource agent metadata (internal use only). Suggested minimum timeout: 5s.

## EXAMPLE CRM SHELL
The following is an example configuration for a ManageRAID resource using the crm(8) shell:

```
primitive p_ManageRAID ocf:heartbeat:ManageRAID \

  params \

    raidname=string \

  op monitor depth="0" timeout="10s" interval="10s"
```

## EXAMPLE PCS
The following is an example configuration for a ManageRAID resource using pcs(8)

```
pcs resource create p_ManageRAID ocf:heartbeat:ManageRAID \

  raidname=string \

  op monitor OCF_CHECK_LEVEL="0" timeout="10s" interval="10s"
```

## SEE ALSO
http://clusterlabs.org/

## AUTHOR
ClusterLabs contributors (see the resource agent source for information about individual authors)