Managing storage devices

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
             - sdb
           fs_type: xfs

   • The volume name (barefs in the example) is currently arbitrary. The storage role identifies the volume by the disk device listed under the disks: attribute.
   • You can omit the fs_type: xfs line because XFS is the default file system in RHEL 9.

   • To create the file system on an LV, provide the LVM setup under the disks: attribute, including the enclosing volume group. For details, see Managing logical volumes by using the storage RHEL system role.

     Do not provide the path to the LV device.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
             - sdb
           fs_type: xfs
           mount_point: /mnt/data
           mount_user: somebody
           mount_group: somegroup
           mount_mode: 0755

   • This playbook adds the file system to the /etc/fstab file, and mounts the file system immediately.
   • If the file system on the /dev/sdb device or the mount point directory do not exist, the playbook creates them.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Create logical volume
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_pools:
             - name: myvg
               disks:
                 - sda
                 - sdb
                 - sdc
               volumes:
                 - name: mylv
                   size: 2G
                   fs_type: ext4
                   mount_point: /mnt/data

   The settings specified in the example playbook include the following:

   size: <size>

   You must specify the size by using units (for example, GiB) or percentage (for example, 60%).

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Enable online block discard
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_volumes:
             - name: barefs
               type: disk
               disks:
                 - sdb
               fs_type: xfs
               mount_point: /mnt/data
               mount_options: discard

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
             - sdb
           fs_type: ext4
           fs_label: label-name
           mount_point: /mnt/data

   • The playbook creates the file system on the /dev/sdb disk.
   • The playbook persistently mounts the file system at the /mnt/data directory.
   • The label of the file system is label-name.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - hosts: all
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: barefs
           type: disk
           disks:
             - sdb
           fs_type: ext3
           fs_label: label-name
           mount_point: /mnt/data
           mount_user: somebody
           mount_group: somegroup
           mount_mode: 0755

   • The playbook creates the file system on the /dev/sdb disk.
   • The playbook persistently mounts the file system at the /mnt/data directory.
   • The label of the file system is label-name.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Create a disk device with swap
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.storage
     vars:
       storage_volumes:
         - name: swap_fs
           type: disk
           disks:
             - /dev/sdb
           size: 15 GiB
           fs_type: swap

   The volume name (swap_fs in the example) is currently arbitrary. The storage role identifies the volume by the disk device listed under the disks: attribute.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Create a RAID on sdd, sde, sdf, and sdg
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_safe_mode: false
           storage_volumes:
             - name: data
               type: raid
               disks: [sdd, sde, sdf, sdg]
               raid_level: raid0
               raid_chunk_size: 32 KiB
               mount_point: /mnt/data
               state: present

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure LVM pool with RAID
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_safe_mode: false
           storage_pools:
             - name: my_pool
               type: lvm
               disks: [sdh, sdi]
               raid_level: raid1
               volumes:
                 - name: my_volume
                   size: "1 GiB"
                   mount_point: "/mnt/app/shared"
                   fs_type: xfs
                   state: present

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Configure stripe size for RAID LVM volumes
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_safe_mode: false
           storage_pools:
             - name: my_pool
               type: lvm
               disks: [sdh, sdi]
               volumes:
                 - name: my_volume
                   size: "1 GiB"
                   mount_point: "/mnt/app/shared"
                   fs_type: xfs
                   raid_level: raid0
                   raid_stripe_size: "256 KiB"
                   state: present

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Create LVM-VDO volume under volume group 'myvg'
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_pools:
             - name: myvg
               disks:
                 - /dev/sdb
               volumes:
                 - name: mylv1
                   compression: true
                   deduplication: true
                   vdo_pool_size: 10 GiB
                   size: 30 GiB
                   mount_point: /mnt/app/shared

   The settings specified in the example playbook include the following:

   vdo_pool_size: <size>

   The actual size that the volume takes on the device. You can specify the size in human-readable format, such as 10 GiB. If you do not specify a unit, it defaults to bytes.

   size: <size>

   The virtual size of VDO volume.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      luks_password: <password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: Create and configure a volume encrypted with LUKS
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_volumes:
             - name: barefs
               type: disk
               disks:
                 - sdb
               fs_type: xfs
               fs_label: <label>
               mount_point: /mnt/data
               encryption: true
               encryption_password: "{{ luks_password }}"

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Verification

1. Find the luksUUID value of the LUKS encrypted volume:

   # ansible managed-node-01.example.com -m command -a 'cryptsetup luksUUID /dev/sdb'
   
   4e4e7970-1822-470e-b55a-e91efe5d0f5c

2. View the encryption status of the volume:

   # ansible managed-node-01.example.com -m command -a 'cryptsetup status luks-4e4e7970-1822-470e-b55a-e91efe5d0f5c'
   
   /dev/mapper/luks-4e4e7970-1822-470e-b55a-e91efe5d0f5c is active and is in use.
     type:    LUKS2
     cipher:  aes-xts-plain64
     keysize: 512 bits
     key location: keyring
     device:  /dev/sdb
   ...

3. Verify the created LUKS encrypted volume:

   # ansible managed-node-01.example.com -m command -a 'cryptsetup luksDump /dev/sdb'
   
   LUKS header information
   Version:        2
   Epoch:          3
   Metadata area:  16384 [bytes]
   Keyslots area:  16744448 [bytes]
   UUID:           4e4e7970-1822-470e-b55a-e91efe5d0f5c
   Label:          (no label)
   Subsystem:      (no subsystem)
   Flags:          (no flags)
   
   Data segments:
     0: crypt
           offset: 16777216 [bytes]
           length: (whole device)
           cipher: aes-xts-plain64
           sector: 512 [bytes]
   ...

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     become: true
     tasks:
       - name: Create shared LVM device
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_pools:
             - name: vg1
               disks: /dev/vdb
               type: lvm
               shared: true
               state: present
               volumes:
                 - name: lv1
                   size: 4g
                   mount_point: /opt/test1
           storage_safe_mode: false
           storage_use_partitions: true

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Resize LVM PV size
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_pools:
              - name: myvg
                disks: ["sdf"]
                type: lvm
                grow_to_fill: true

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Store your sensitive variables in an encrypted file:

   1. Create the vault:

      $ ansible-vault create vault.yml
      New Vault password: <vault_password>
      Confirm New Vault password: <vault_password>

   2. After the ansible-vault create command opens an editor, enter the sensitive data in the <key>: <value> format:

      luks_password: <password>

   3. Save the changes, and close the editor. Ansible encrypts the data in the vault.

2. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     vars_files:
       - vault.yml
     tasks:
       - name: Create a new encrypted Stratis pool with Clevis and Tang
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_pools:
              - name: mypool
                disks:
                  - sdd
                  - sde
                type: stratis
                encryption: true
                encryption_password: "{{ luks_password }}"
                encryption_clevis_pin: tang
                encryption_tang_url: tang-server.example.com:7500

   The settings specified in the example playbook include the following:

   encryption_password

   Password or passphrase used to unlock the LUKS volumes.

   encryption_clevis_pin

   Clevis method that you can use to encrypt the created pool. You can use tang and tpm2.

   encryption_tang_url

   URL of the Tang server.

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

3. Validate the playbook syntax:

   $ ansible-playbook --ask-vault-pass --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

4. Run the playbook:

   $ ansible-playbook --ask-vault-pass ~/playbook.yml

Procedure

1. Start the interactive parted shell:

   # parted block-device

2. Determine if there already is a partition table on the device:

   # (parted) print

   If the device already contains partitions, they will be deleted in the following steps.

3. Create the new partition table:

   # (parted) mklabel table-type

   • Replace table-type with with the intended partition table type:

     • msdos for MBR
     • gpt for GPT

   Example 5.1. Creating a GUID Partition Table (GPT) table

   To create a GPT table on the disk, use:

   # (parted) mklabel gpt

   The changes start applying after you enter this command.

4. View the partition table to confirm that it is created:

   # (parted) print

5. Exit the parted shell:

   # (parted) quit

Procedure

1. Start the parted utility. For example, the following output lists the device /dev/sda:

   # parted /dev/sda

2. View the partition table:

   # (parted) print
   
   Model: ATA SAMSUNG MZNLN256 (scsi)
   Disk /dev/sda: 256GB
   Sector size (logical/physical): 512B/512B
   Partition Table: msdos
   Disk Flags:
   
   Number  Start   End     Size    Type      File system  Flags
    1      1049kB  269MB   268MB   primary   xfs          boot
    2      269MB   34.6GB  34.4GB  primary
    3      34.6GB  45.4GB  10.7GB  primary
    4      45.4GB  256GB   211GB   extended
    5      45.4GB  256GB   211GB   logical

3. Optional: Switch to the device you want to examine next:

   # (parted) select block-device

Procedure

1. Start the parted utility:

   # parted block-device

2. View the current partition table to determine if there is enough free space:

   # (parted) print

   • Resize the partition in case there is not enough free space.

   • From the partition table, determine:

     • The start and end points of the new partition.
     • On MBR, what partition type it should be.

3. Create the new partition:

   # (parted) mkpart part-type name fs-type start end

   • Replace part-type with with primary, logical, or extended. This applies only to the MBR partition table.
   • Replace name with an arbitrary partition name. This is required for GPT partition tables.
   • Replace fs-type with xfs, ext2, ext3, ext4, fat16, fat32, hfs, hfs+, linux-swap, ntfs, or reiserfs. The fs-type parameter is optional. Note that the parted utility does not create the file system on the partition.
   • Replace start and end with the sizes that determine the starting and ending points of the partition, counting from the beginning of the disk. You can use size suffixes, such as 512MiB, 20GiB, or 1.5TiB. The default size is in megabytes.

   Example 5.2. Creating a small primary partition

   To create a primary partition from 1024MiB until 2048MiB on an MBR table, use:

   # (parted) mkpart primary 1024MiB 2048MiB

   The changes start applying after you enter the command.

4. View the partition table to confirm that the created partition is in the partition table with the correct partition type, file system type, and size:

   # (parted) print

5. Exit the parted shell:

   # (parted) quit

6. Register the new device node:

   # udevadm settle

7. Verify that the kernel recognizes the new partition:

   # cat /proc/partitions

Procedure

1. Start the interactive fdisk shell:

   # fdisk block-device

2. View the current partition table to determine the minor partition number:

   Command (m for help): print

   You can see the current partition type in the Type column and its corresponding type ID in the Id column.

3. Enter the partition type command and select a partition using its minor number:

   Command (m for help): type
   Partition number (1,2,3 default 3): 2

4. Optional: View the list in hexadecimal codes:

   Hex code (type L to list all codes): L

5. Set the partition type:

   Hex code (type L to list all codes): 8e

6. Write your changes and exit the fdisk shell:

   Command (m for help): write
   The partition table has been altered.
   Syncing disks.

7. Verify your changes:

   # fdisk --list block-device

Procedure

1. Start the parted utility:

   # parted block-device

2. View the current partition table:

   # (parted) print

   From the partition table, determine:

   • The minor number of the partition.
   • The location of the existing partition and its new ending point after resizing.

3. Resize the partition:

   # (parted) resizepart 1 2GiB

   • Replace 1 with the minor number of the partition that you are resizing.
   • Replace 2 with the size that determines the new ending point of the resized partition, counting from the beginning of the disk. You can use size suffixes, such as 512MiB, 20GiB, or 1.5TiB. The default size is in megabytes.

4. View the partition table to confirm that the resized partition is in the partition table with the correct size:

   # (parted) print

5. Exit the parted shell:

   # (parted) quit

6. Verify that the kernel registers the new partition:

   # cat /proc/partitions

7. Optional: If you extended the partition, extend the file system on it as well.

Procedure

1. Start the interactive parted shell:

   # parted block-device

   • Replace block-device with the path to the device where you want to remove a partition: for example, /dev/sda.

2. View the current partition table to determine the minor number of the partition to remove:

   (parted) print

3. Remove the partition:

   (parted) rm minor-number

   • Replace minor-number with the minor number of the partition you want to remove.

   The changes start applying as soon as you enter this command.

4. Verify that you have removed the partition from the partition table:

   (parted) print

5. Exit the parted shell:

   (parted) quit

6. Verify that the kernel registers that the partition is removed:

   # cat /proc/partitions

7. Remove the partition from the /etc/fstab file, if it is present. Find the line that declares the removed partition, and remove it from the file.

8. Regenerate mount units so that your system registers the new /etc/fstab configuration:

   # systemctl daemon-reload

9. If you have deleted a swap partition or removed pieces of LVM, remove all references to the partition from the kernel command line:

   1. List active kernel options and see if any option references the removed partition:

      # grubby --info=ALL

   2. Remove the kernel options that reference the removed partition:

      # grubby --update-kernel=ALL --remove-args="option"

10. To register the changes in the early boot system, rebuild the initramfs file system:

    # dracut --force --verbose

Procedure

1. Install the targetcli tool:

   # dnf install targetcli

2. Start the target service:

   # systemctl start target

3. Configure target to start at boot time:

   # systemctl enable target

4. Open port 3260 in the firewall and reload the firewall configuration:

   # firewall-cmd --permanent --add-port=3260/tcp
   Success
   
   # firewall-cmd --reload
   Success

Procedure

1. Navigate to the iSCSI directory:

   /> iscsi/

   Note

   The cd command is used to change directories as well as to list the path to move into.

2. Use one of the following options to create an iSCSI target:

   1. Creating an iSCSI target using a default target name:

      /iscsi> create
      
      Created target
      iqn.2003-01.org.linux-iscsi.hostname.x8664:sn.78b473f296ff
      Created TPG1

   2. Creating an iSCSI target using a specific name:

      /iscsi> create iqn.2006-04.com.example:444
      
      Created target iqn.2006-04.com.example:444
      Created TPG1
      Here iqn.2006-04.com.example:444 is target_iqn_name

      Replace iqn.2006-04.com.example:444 with the specific target name.

3. Verify the newly created target:

   /iscsi> ls
   
   o- iscsi.......................................[1 Target]
       o- iqn.2006-04.com.example:444................[1 TPG]
           o- tpg1...........................[enabled, auth]
              o- acls...............................[0 ACL]
               o- luns...............................[0 LUN]
              o- portals.........................[0 Portal]

Procedure

1. Navigate to the fileio/ from the backstores/ directory:

   /> backstores/fileio

2. Create a fileio storage object:

   /backstores/fileio> create file1 /tmp/disk1.img 200M write_back=false
   
   Created fileio file1 with size 209715200

Procedure

1. Navigate to the block/ from the backstores/ directory:

   /> backstores/block/

2. Create a block backstore:

   /backstores/block> create name=block_backend dev=/dev/sdb
   
   Generating a wwn serial.
   Created block storage object block_backend using /dev/vdb.

Procedure

1. Navigate to the pscsi/ from the backstores/ directory:

   /> backstores/pscsi/

2. Create a pscsi backstore for a physical SCSI device, a TYPE_ROM device using /dev/sr0 in this example:

   /backstores/pscsi> create name=pscsi_backend dev=/dev/sr0
   
   Generating a wwn serial.
   Created pscsi storage object pscsi_backend using /dev/sr0

Procedure

1. Navigate to the ramdisk/ from the backstores/ directory:

   /> backstores/ramdisk/

2. Create a 1GB RAM disk backstore:

   /backstores/ramdisk> create name=rd_backend size=1GB
   
   Generating a wwn serial.
   Created rd_mcp ramdisk rd_backend with size 1GB.

Procedure

1. Navigate to the TPG directory:

   /iscsi> iqn.2006-04.example:444/tpg1/

2. Use one of the following options to create an iSCSI portal:

   1. Creating a default portal uses the default iSCSI port 3260 and allows the target to listen to all IP addresses on that port:

      /iscsi/iqn.20...mple:444/tpg1> portals/ create
      
      Using default IP port 3260
      Binding to INADDR_Any (0.0.0.0)
      Created network portal 0.0.0.0:3260

      Note

      When an iSCSI target is created, a default portal is also created. This portal is set to listen to all IP addresses with the default port number that is: 0.0.0.0:3260.

      To remove the default portal, use the following command:

      /iscsi/iqn-name/tpg1/portals delete ip_address=0.0.0.0 ip_port=3260

   2. Creating a portal using a specific IP address:

      /iscsi/iqn.20...mple:444/tpg1> portals/ create 192.168.122.137
      
      Using default IP port 3260
      Created network portal 192.168.122.137:3260

Procedure

1. Create LUNs of already created storage objects:

   /iscsi/iqn.20...mple:444/tpg1> luns/ create /backstores/ramdisk/rd_backend
   Created LUN 0.
   
   /iscsi/iqn.20...mple:444/tpg1> luns/ create /backstores/block/block_backend
   Created LUN 1.
   
   /iscsi/iqn.20...mple:444/tpg1> luns/ create /backstores/fileio/file1
   Created LUN 2.

2. Verify the created LUNs:

   /iscsi/iqn.20...mple:444/tpg1> ls
   
   o- tpg.................................. [enambled, auth]
       o- acls ......................................[0 ACL]
       o- luns .....................................[3 LUNs]
       |  o- lun0.........................[ramdisk/ramdisk1]
       |  o- lun1.................[block/block1 (/dev/vdb1)]
       |  o- lun2...................[fileio/file1 (/foo.img)]
       o- portals ................................[1 Portal]
           o- 192.168.122.137:3260......................[OK]

   Default LUN name starts at 0.

   Important

   By default, LUNs are created with read-write permissions. If a new LUN is added after ACLs are created, LUN automatically maps to all available ACLs and can cause a security risk. To create a LUN with read-only permissions, see Creating a read-only iSCSI LUN.

3. Configure ACLs. For more information, see Creating an iSCSI ACL.

Procedure

1. Set read-only permissions:

   /> set global auto_add_mapped_luns=false
   
   Parameter auto_add_mapped_luns is now 'false'.

   This prevents the auto mapping of LUNs to existing ACLs allowing the manual mapping of LUNs.

2. Navigate to the initiator_iqn_name directory:

   /> iscsi/target_iqn_name/tpg1/acls/initiator_iqn_name/

3. Create the LUN:

   /iscsi/target_iqn_name/tpg1/acls/initiator_iqn_name> create mapped_lun=next_sequential_LUN_number tpg_lun_or_backstore=backstore write_protect=1

   Example:

   /iscsi/target_iqn_name/tpg1/acls/2006-04.com.example:888> create mapped_lun=1 tpg_lun_or_backstore=/backstores/block/block2 write_protect=1
   
   Created LUN 1.
   Created Mapped LUN 1.

4. Verify the created LUN:

   /iscsi/target_iqn_name/tpg1/acls/2006-04.com.example:888> ls
    o- 2006-04.com.example:888 .. [Mapped LUNs: 2]
    | o- mapped_lun0 .............. [lun0 block/disk1 (rw)]
    | o- mapped_lun1 .............. [lun1 block/disk2 (ro)]

   The mapped_lun1 line now has (ro) at the end (unlike mapped_lun0’s (rw)) stating that it is read-only.

5. Configure ACLs. For more information, see Creating an iSCSI ACL.

Procedure

1. Optional: To disable auto mapping of LUNs to ACLs see Creating a read-only iSCSI LUN.

2. Navigate to the acls directory:

   /> iscsi/target_iqn_name/tpg_name/acls/

3. Use one of the following options to create an ACL:

   • Use the initiator_iqn_name from the /etc/iscsi/initiatorname.iscsi file on the initiator:

     iscsi/target_iqn_name/tpg_name/acls> create initiator_iqn_name
     
     Created Node ACL for initiator_iqn_name
     Created mapped LUN 2.
     Created mapped LUN 1.
     Created mapped LUN 0.

   • Use a custom_name and update the initiator to match it:

     iscsi/target_iqn_name/tpg_name/acls> create custom_name
     
     Created Node ACL for custom_name
     Created mapped LUN 2.
     Created mapped LUN 1.
     Created mapped LUN 0.

     For information about updating the initiator name, see Creating an iSCSI intiator.

Procedure

1. Set attribute authentication:

   /iscsi/iqn.20...mple:444/tpg1> set attribute authentication=1
   
   Parameter authentication is now '1'.

2. Set userid and password:

   /tpg1> set auth userid=redhat
   Parameter userid is now 'redhat'.
   
   /iscsi/iqn.20...689dcbb3/tpg1> set auth password=redhat_passwd
   Parameter password is now 'redhat_passwd'.

Procedure

1. Log off from the target:

   # iscsiadm -m node -T iqn.2006-04.example:444 -u

   For more information about how to log in to the target, see Creating an iSCSI initiator.

2. Remove the entire target, including all ACLs, LUNs, and portals:

   /> iscsi/ delete iqn.2006-04.com.example:444

   Replace iqn.2006-04.com.example:444 with the target_iqn_name.

   • To remove an iSCSI backstore:

     /> backstores/backstore-type/ delete block_backend

     • Replace backstore-type with either fileio, block, pscsi, or ramdisk.
     • Replace block_backend with the backstore-name you want to delete.

   • To remove parts of an iSCSI target, such as an ACL:

     /> /iscsi/iqn-name/tpg/acls/ delete iqn.2006-04.com.example:444

Procedure

1. Install iscsi-initiator-utils on client machine:

   # dnf install iscsi-initiator-utils

2. Check the initiator name:

   # cat /etc/iscsi/initiatorname.iscsi
   
   InitiatorName=iqn.2006-04.com.example:888

3. If the ACL was given a custom name in Creating an iSCI ACL, update the initiator name to match the ACL:

   1. Open the /etc/iscsi/initiatorname.iscsi file and modify the initiator name:

      # vi /etc/iscsi/initiatorname.iscsi
      
      InitiatorName=custom-name

   2. Restart the iscsid service:

      # systemctl restart iscsid

4. Discover the target and log in to the target with the displayed target IQN:

   # iscsiadm -m discovery -t st -p 10.64.24.179
       10.64.24.179:3260,1 iqn.2006-04.example:444
   
   # iscsiadm -m node -T iqn.2006-04.example:444 -l
       Logging in to [iface: default, target: iqn.2006-04.example:444, portal: 10.64.24.179,3260] (multiple)
       Login to [iface: default, target: iqn.2006-04.example:444, portal: 10.64.24.179,3260] successful.

   Replace 10.64.24.179 with the target-ip-address.

   You can use this procedure for any number of initiators connected to the same target if their respective initiator names are added to the ACL as described in the Creating an iSCSI ACL.

5. Find the iSCSI disk name and create a file system on this iSCSI disk:

   # grep "Attached SCSI" /var/log/messages
   
   # mkfs.ext4 /dev/disk_name

   Replace disk_name with the iSCSI disk name displayed in the /var/log/messages file.

6. Mount the file system:

   # mkdir /mount/point
   
   # mount /dev/disk_name /mount/point

   Replace /mount/point with the mount point of the partition.

7. Edit the /etc/fstab file to mount the file system automatically when the system boots:

   # vi /etc/fstab
   
   /dev/disk_name /mount/point ext4 _netdev 0 0

   Replace disk_name with the iSCSI disk name and /mount/point with the mount point of the partition.

Procedure

1. Enable CHAP authentication in the iscsid.conf file:

   # vi /etc/iscsi/iscsid.conf
   
   node.session.auth.authmethod = CHAP

   By default, the node.session.auth.authmethod is set to None

2. Add target username and password in the iscsid.conf file:

   node.session.auth.username = redhat
   node.session.auth.password = redhat_passwd

3. Start the iscsid daemon:

   # systemctl start iscsid.service

Procedure

1. Install the iscsi-initiator-utils on client machine:

   # dnf install iscsi-initiator-utils

2. Find information about the running sessions:

   # iscsiadm -m session -P 3

   This command displays the session or device state, session ID (sid), some negotiated parameters, and the SCSI devices accessible through the session.

   • For shorter output, for example, to display only the sid-to-node mapping, run:

     # iscsiadm -m session -P 0
             or
     # iscsiadm -m session
     
     tcp [2] 10.15.84.19:3260,2 iqn.1992-08.com.netapp:sn.33615311
     tcp [3] 10.15.85.19:3260,3 iqn.1992-08.com.netapp:sn.33615311

     These commands print the list of running sessions in the following format: driver [sid] target_ip:port,target_portal_group_tag proper_target_name.

Procedure

1. Determine which devices are paths for a multipath logical unit:

   multipath -ll

2. Re-scan Fibre Channel logical units on a system that uses multipathing:

   $ echo 1 > /sys/block/sdX/device/rescan

Procedure

1. Create a snapshot of your root logical volume:

   • If your root file system uses thin provisioning, create a thin snapshot:

     # lvcreate -s rhel/root -kn -n root_snapshot_before_changes
      Logical volume "root_snapshot_before_changes" created.

     Here:

     • -s creates the snapshot.
     • rhel/root copies the file system to the logical volume.
     • -kn automatically activates LV at boot time.

     • -n root_snapshot_before_changes shows the name of the snapshot.

       While creating a thin snapshot, do not define the snapshot size. The snapshot is allocated from the thin pool.

   • If your root file system uses thick provisioning, create a thick snapshot:

     # lvcreate -s rhel/root -n root_snapshot_before_changes -L 25g
       Rounding up size to full physical extent 25 GiB
       Logical volume "root_snapshot_before_changes" created.

     In this command:

     • -s creates the snapshot.
     • rhel/root copies the file system to the logical volume.
     • -n root_snapshot_before_changes shows the name of the snapshot.

     • -L 25g is the snapshot size. Make a size estimate based on the size of the original installation.

       While creating a thick snapshot, define the snapshot size that can hold all the changes during the upgrade.

       Important

       The created snapshot does not include any additional system changes.

2. Create the profile:

   Creating a profile requires an architecture-specific workaround to avoid an interaction between kexec-tools or kdumpctl and boom. During the upgrade, the updated kexec-tools package attempts to modify all boot entries with updated crashkernel settings. This deletes the boot images used by the entry. You can avoid this by appending the RHEL 9 crashkernel settings to the RHEL 8 profile options.

   • On an Intel 64 or AMD64 (x86_64), or IBM Z (s390x) architecture:

     # boom profile create --from-host --os-options "root=%{root_device} ro %{root_opts} rhgb quiet crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M"
     Created profile with os_id 43747d3:
       OS ID: "43747d3888b663d2bc88efd35d0813159a84d291",
       Name: "Red Hat Enterprise Linux", Short name: "rhel",
       Version: "8.9 (Ootpa)", Version ID: "8.9",
       Kernel pattern: "/vmlinuz-%{version}", Initramfs pattern: "/initramfs-%{version}.img",
       Root options (LVM2): "rd.lvm.lv=%{lvm_root_lv}",
       Root options (BTRFS): "rootflags=%{btrfs_subvolume}",
       Options: "root=%{root_device} ro %{root_opts} rhgb quiet crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M",
       Title: "%{os_name} %{os_version_id} (%{version})",
       Optional keys: "", UTS release pattern: "el8"

   • On an 64-bit ARM (AArch64) architecture:

     # boom profile create --from-host --os-options "root=%{root_device} ro %{root_opts} rhgb quiet crashkernel=1G-4G:256M,4G-64G:320M,64G-:576M"

   • On an IBM POWER little-endian (ppc64le) architecture:

     # boom profile create --from-host --os-options "root=%{root_device} ro %{root_opts} rhgb quiet crashkernel=2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G" --optional-keys "grub_users grub_arg grub_class id"

     The --optional-keys argument is required on ppc64le to ensure that the grub2-mkconfig command generates the correct boot entry in step 10.2.3. For more information, see RHEL-36180.

3. Create a snapshot boot entry of the original system using backup copies of the original boot images:

   # boom create --backup --title "Root LV snapshot before changes" --rootlv rhel/root_snapshot_before_changes
   WARNING - Boom grub2 integration is disabled in '/boot/../etc/default/boom'
   Created entry with boot_id c919f89:
     title Root LV snapshot before changes
     machine-id b1dcec73886b45218892b1a7bbfa0dee
     version 4.18.0-513.24.1.el8_9.x86_64
     linux /vmlinuz-4.18.0-513.24.1.el8_9.x86_64.boom0
     initrd /initramfs-4.18.0-513.24.1.el8_9.x86_64.img.boom0
     options root=/dev/rhel/root_snapshot_before_changes ro rd.lvm.lv=rhel/root_snapshot_before_changes rhgb quiet crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M

   Here:

   • --title "Root LV snapshot before changes" is the name of the boot entry, that shows in the boot entry list during system startup.

   • --rootlv is the root logical volume that corresponds to the new boot entry.

     After you complete the previous step, you have a boot entry that enables access to the original system, before the upgrade.

     Ignore "WARNING - Boom grub2 integration is disabled in '/boot/../etc/default/boom'". For details, see RHEL-35983.

   • On systems with ppc64le architecture, update boot entries:

     # grub2-mkconfig -o /boot/grub2/grub.cfg
     Generating grub configuration file ...
     Generating boot entries from BLS files...
     done

4. Upgrade to Red Hat Enterprise Linux 9 using the Leapp utility:

   # leapp upgrade
   ==> Processing phase `configuration_phase`
   ====> * ipu_workflow_config
           IPU workflow config actor
   ==> Processing phase `FactsCollection`
   ...
   ============================================================
                         REPORT OVERVIEW
   ============================================================
   
   Upgrade has been inhibited due to the following problems:
       1. Firewalld Configuration AllowZoneDrifting Is Unsupported
       2. Possible problems with remote login using root account
   
   HIGH and MEDIUM severity reports:
       1. Remote root logins globally allowed using password
       2. GRUB2 core will be automatically updated during the upgrade
   
   Reports summary:
       Errors:                      0
       Inhibitors:                  2
       HIGH severity reports:       2
       MEDIUM severity reports:     0
       LOW severity reports:        1
       INFO severity reports:       3
   
   Before continuing consult the full report:
       A report has been generated at /var/log/leapp/leapp-report.json
       A report has been generated at /var/log/leapp/leapp-report.txt
   
   ============================================================
                      END OF REPORT OVERVIEW
   ============================================================

   Review and resolve any blockers indicated by the leapp upgrade command report. For detailed instructions on the report, see Reviewing the pre-upgrade report.

5. Reboot into the upgrade boot entry:

   # leapp upgrade --reboot
   ==> Processing phase `configuration_phase`
   ====> * ipu_workflow_config
           IPU workflow config actor
   ==> Processing phase `FactsCollection`
   ...

   Select the Red Hat Enterprise Linux Upgrade Initramfs entry from the GRUB boot screen.

   Note

   The Snapshots submenu from the GRUB boot screen is not available in Red Hat Enterprise Linux 9.

Procedure

1. Reboot the system:

   # reboot

2. Select the required boot entry from the GRUB boot loader screen.

Procedure

1. Boot into Red Hat Enterprise Linux 9 from the GRUB boot loader screen.

2. After the system loads, view the available boot entries. The following output shows the snapshot boot entry in the list of boom boot entries:

   # boom list
   BootID  Version                      Name                     RootDevice
   1e1a9b4 4.18.0-513.5.1.el8_9.x86_64  Red Hat Enterprise Linux /dev/mapper/rhel-root
   4ea37b9 4.18.0-513.24.1.el8_9.x86_64 Red Hat Enterprise Linux /dev/mapper/rhel-root
   c919f89 4.18.0-513.24.1.el8_9.x86_64 Red Hat Enterprise Linux /dev/rhel/root_snapshot_before_changes

3. Delete the snapshot entry by using the BootID value:

   # boom delete --boot-id c919f89
   Deleted 1 entry

   This deletes the boot entry from the GRUB menu.

4. Remove the LV snapshot:

   # lvremove rhel/root_snapshot_before_changes
   Do you really want to remove active logical volume rhel/root_snapshot_before_changes? [y/n]: y
         Logical volume "root_snapshot_before_changes" successfully removed

5. Complete the remaining post-upgrade tasks. For details, see Upgrading from RHEL 8 to RHEL 9.

Procedure

1. Merge the snapshot with the original volume:

   # lvconvert --merge rhel/root_snapshot_before_changes
     Logical volume rhel/root_snapshot_before_changes contains a filesystem in use.
     Delaying merge since snapshot is open.
     Merging of thin snapshot rhel/root_snapshot_before_changes will occur on next activation of rhel/root.

   Warning

   After you merge the snapshot, you must continue with all the remaining steps in this procedure to prevent data loss.

2. Create a rollback boot entry for the merged snapshot:

   # boom create --backup --title "RHEL Rollback" --rootlv rhel/root
   WARNING - Boom grub2 integration is disabled in '/boot/../etc/default/boom'
   WARNING - Options for BootEntry(boot_id=1e1a9b4) do not match OsProfile: marking read-only
   WARNING - Options for BootEntry(boot_id=1ccc554) do not match OsProfile: marking read-only
   WARNING - Options for BootEntry(boot_id=4ea37b9) do not match OsProfile: marking read-only
   WARNING - Options for BootEntry(boot_id=e22dd61) do not match OsProfile: marking read-only
   Created entry with boot_id 6c44638:
     title RHEL Rollback
     machine-id b1dcec73886b45218892b1a7bbfa0dee
     version 4.18.0-513.24.1.el8_9.x86_64
     linux /vmlinuz-4.18.0-513.24.1.el8_9.x86_64.boom0
     initrd /initramfs-4.18.0-513.24.1.el8_9.x86_64.img.boom0
     options root=/dev/rhel/root ro rd.lvm.lv=rhel/root rhgb quiet crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M

   Ignore all WARNING messages, see RHEL-35983.

3. Reboot your machine to restore the operating system state:

   # reboot

   • After the system reboots, select the RHEL Rollback boot entry from the GRUB screen.

   • When the root logical volume is active, the system automatically starts the snapshot merge operation.

     Important

     When the merge operation starts, the snapshot volume is no longer available. After successfully booting the RHEL Rollback boot entry, the Root LV snapshot boot entry no longer works. Merging the snapshot logical volume destroys the Root LV snapshot and restores the prior state of the original volume.

4. After you complete the merge operation, remove the unused entries and restore the original boot entry:

   1. Remove the unused Red Hat Enterprise Linux 9 boot entries from the /boot file system and rebuild the grub.cfg file for the changes to take effect:

      # rm -f /boot/loader/entries/*.el9*

      # rm -f /boot/*.el9*

      # grub2-mkconfig -o /boot/grub2/grub.cfg
      Generating grub configuration file ...
      done

5. After a successful rollback to the system, delete the boom snapshot and rollback boot entries:

   # boom list -o+title
   WARNING - Options for BootEntry(boot_id=1e1a9b4) do not match OsProfile: marking read-only
   WARNING - Options for BootEntry(boot_id=1ccc554) do not match OsProfile: marking read-only
   WARNING - Options for BootEntry(boot_id=4ea37b9) do not match OsProfile: marking read-only
   BootID  Version                      Name                     RootDevice                             Title
   1e1a9b4 4.18.0-513.5.1.el8_9.x86_64  Red Hat Enterprise Linux /dev/mapper/rhel-root                  Red Hat Enterprise Linux (4.18.0-513.5.1.el8_9.x86_64) 8.9 (Ootpa)
   4ea37b9 4.18.0-513.24.1.el8_9.x86_64 Red Hat Enterprise Linux /dev/mapper/rhel-root                  Red Hat Enterprise Linux (4.18.0-513.24.1.el8_9.x86_64) 8.9 (Ootpa)
   c919f89 4.18.0-513.24.1.el8_9.x86_64 Red Hat Enterprise Linux /dev/rhel/root_snapshot_before_changes Root LV snapshot before changes
   6c44638 4.18.0-513.24.1.el8_9.x86_64 Red Hat Enterprise Linux /dev/rhel/root                         RHEL Rollback

   # boom delete c919f89
   WARNING - Options for BootEntry(boot_id=1e1a9b4) do not match OsProfile: marking read-only
   WARNING - Options for BootEntry(boot_id=1ccc554) do not match OsProfile: marking read-only
   WARNING - Options for BootEntry(boot_id=4ea37b9) do not match OsProfile: marking read-only
   Deleted 1 entry

   # boom delete 6c44638
   WARNING - Options for BootEntry(boot_id=1e1a9b4) do not match OsProfile: marking read-only
   WARNING - Options for BootEntry(boot_id=1ccc554) do not match OsProfile: marking read-only
   WARNING - Options for BootEntry(boot_id=4ea37b9) do not match OsProfile: marking read-only
   Deleted 1 entry

   Ignore the warnings. For details, see RHEL-35983.

Procedure

1. Create the nvmet-rdma subsystem:

   # modprobe nvmet-rdma
   
   # mkdir /sys/kernel/config/nvmet/subsystems/testnqn
   
   # cd /sys/kernel/config/nvmet/subsystems/testnqn

   Replace testnqn with the subsystem name.

2. Allow any host to connect to this controller:

   # echo 1 > attr_allow_any_host

3. Configure a namespace:

   # mkdir namespaces/10
   
   # cd namespaces/10

   Replace 10 with the namespace number

4. Set a path to the NVMe device:

   # echo -n /dev/nvme0n1 > device_path

5. Enable the namespace:

   # echo 1 > enable

6. Create a directory with an NVMe port:

   # mkdir /sys/kernel/config/nvmet/ports/1
   
   # cd /sys/kernel/config/nvmet/ports/1

7. Display the IP address of mlx5_ib0:

   # ip addr show mlx5_ib0
   
   8: mlx5_ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 4092 qdisc mq state UP group default qlen 256
       link/infiniband 00:00:06:2f:fe:80:00:00:00:00:00:00:e4:1d:2d:03:00:e7:0f:f6 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
       inet 172.31.0.202/24 brd 172.31.0.255 scope global noprefixroute mlx5_ib0
          valid_lft forever preferred_lft forever
       inet6 fe80::e61d:2d03:e7:ff6/64 scope link noprefixroute
          valid_lft forever preferred_lft forever

8. Set the transport address for the controller:

   # echo -n 172.31.0.202 > addr_traddr

9. Set RDMA as the transport type:

   # echo rdma > addr_trtype
   
   # echo 4420 > addr_trsvcid

10. Set the address family for the port:

    # echo ipv4 > addr_adrfam

11. Create a soft link:

    # ln -s /sys/kernel/config/nvmet/subsystems/testnqn   /sys/kernel/config/nvmet/ports/1/subsystems/testnqn

Procedure

1. Install the nvmetcli package:

   # dnf install nvmetcli

2. Download the rdma.json file:

   # wget http://git.infradead.org/users/hch/nvmetcli.git/blob_plain/0a6b088db2dc2e5de11e6f23f1e890e4b54fee64:/rdma.json

3. Edit the rdma.json file and change the traddr value to 172.31.0.202.

4. Setup the controller by loading the NVMe controller configuration file:

   # nvmetcli restore rdma.json

Procedure

1. Install the nvme-cli tool:

   # dnf install nvme-cli

2. Load the nvme-rdma module if it is not loaded:

   # modprobe nvme-rdma

3. Discover available subsystems on the NVMe controller:

   # nvme discover -t rdma -a 172.31.0.202 -s 4420
   
   Discovery Log Number of Records 1, Generation counter 2
   =====Discovery Log Entry 0======
   trtype:  rdma
   adrfam:  ipv4
   subtype: nvme subsystem
   treq:    not specified, sq flow control disable supported
   portid:  1
   trsvcid: 4420
   subnqn:  testnqn
   traddr:  172.31.0.202
   rdma_prtype: not specified
   rdma_qptype: connected
   rdma_cms:    rdma-cm
   rdma_pkey: 0x0000

4. Connect to the discovered subsystems:

   # nvme connect -t rdma -n testnqn -a 172.31.0.202 -s 4420
   
   # lsblk
   NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
   sda                            8:0    0 465.8G  0 disk
   ├─sda1                         8:1    0     1G  0 part /boot
   └─sda2                         8:2    0 464.8G  0 part
     ├─rhel_rdma--virt--03-root 253:0    0    50G  0 lvm  /
     ├─rhel_rdma--virt--03-swap 253:1    0     4G  0 lvm  [SWAP]
     └─rhel_rdma--virt--03-home 253:2    0 410.8G  0 lvm  /home
   nvme0n1
   
   # cat /sys/class/nvme/nvme0/transport
   rdma

   Replace testnqn with the NVMe subsystem name.

   Replace 172.31.0.202 with the controller IP address.

   Replace 4420 with the port number.

Procedure

1. Install the nvme-cli utility:

   # dnf install nvme-cli

   This creates the hostnqn file in the /etc/nvme/ directory. The hostnqn file identifies the NVMe host.

2. Find the World Wide Node Name (WWNN) and World Wide Port Name (WWPN) identifiers of the local and remote ports:

   # cat /sys/class/scsi_host/host*/nvme_info
   
   NVME Host Enabled
   XRI Dist lpfc0 Total 6144 IO 5894 ELS 250
   NVME LPORT lpfc0 WWPN x10000090fae0b5f5 WWNN x20000090fae0b5f5 DID x010f00 ONLINE
   NVME RPORT       WWPN x204700a098cbcac6 WWNN x204600a098cbcac6 DID x01050e TARGET DISCSRVC ONLINE
   
   NVME Statistics
   LS: Xmt 000000000e Cmpl 000000000e Abort 00000000
   LS XMIT: Err 00000000  CMPL: xb 00000000 Err 00000000
   Total FCP Cmpl 00000000000008ea Issue 00000000000008ec OutIO 0000000000000002
       abort 00000000 noxri 00000000 nondlp 00000000 qdepth 00000000 wqerr 00000000 err 00000000
   FCP CMPL: xb 00000000 Err 00000000

   Using these host-traddr and traddr values, find the subsystem NVMe Qualified Name (NQN):

   # nvme discover --transport fc \ --traddr nn-0x204600a098cbcac6:pn-0x204700a098cbcac6 \ --host-traddr nn-0x20000090fae0b5f5:pn-0x10000090fae0b5f5
   
   Discovery Log Number of Records 2, Generation counter 49530
   =====Discovery Log Entry 0======
   trtype:  fc
   adrfam:  fibre-channel
   subtype: nvme subsystem
   treq:    not specified
   portid:  0
   trsvcid: none
   subnqn:  nqn.1992-08.com.netapp:sn.e18bfca87d5e11e98c0800a098cbcac6:subsystem.st14_nvme_ss_1_1
   traddr:  nn-0x204600a098cbcac6:pn-0x204700a098cbcac6

   Replace nn-0x204600a098cbcac6:pn-0x204700a098cbcac6 with the traddr.

   Replace nn-0x20000090fae0b5f5:pn-0x10000090fae0b5f5 with the host-traddr.

3. Connect to the NVMe controller using the nvme-cli:

   # nvme connect --transport fc \ --traddr nn-0x204600a098cbcac6:pn-0x204700a098cbcac6 \ --host-traddr nn-0x20000090fae0b5f5:pn-0x10000090fae0b5f5 \ -n nqn.1992-08.com.netapp:sn.e18bfca87d5e11e98c0800a098cbcac6:subsystem.st14_nvme_ss_1_1 \ -k 5

   Note

   If you see the keep-alive timer (5 seconds) expired! error when a connection time exceeds the default keep-alive timeout value, increase it using the -k option. For example, you can use, -k 7.

   Here,

   Replace nn-0x204600a098cbcac6:pn-0x204700a098cbcac6 with the traddr.

   Replace nn-0x20000090fae0b5f5:pn-0x10000090fae0b5f5 with the host-traddr.

   Replace nqn.1992-08.com.netapp:sn.e18bfca87d5e11e98c0800a098cbcac6:subsystem.st14_nvme_ss_1_1 with the subnqn.

   Replace 5 with the keep-alive timeout value in seconds.

Procedure

1. Install the nvme-cli utility:

   # dnf install nvme-cli

   This creates the hostnqn file in the /etc/nvme/ directory. The hostnqn file identifies the NVMe host.

2. Reload the qla2xxx module:

   # modprobe -r qla2xxx
   # modprobe qla2xxx

3. Find the World Wide Node Name (WWNN) and World Wide Port Name (WWPN) identifiers of the local and remote ports:

   # dmesg |grep traddr
   
   [    6.139862] qla2xxx [0000:04:00.0]-ffff:0: register_localport: host-traddr=nn-0x20000024ff19bb62:pn-0x21000024ff19bb62 on portID:10700
   [    6.241762] qla2xxx [0000:04:00.0]-2102:0: qla_nvme_register_remote: traddr=nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6 PortID:01050d

   Using these host-traddr and traddr values, find the subsystem NVMe Qualified Name (NQN):

   # nvme discover --transport fc \ --traddr nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6 \ --host-traddr nn-0x20000024ff19bb62:pn-0x21000024ff19bb62
   
   Discovery Log Number of Records 2, Generation counter 49530
   =====Discovery Log Entry 0======
   trtype:  fc
   adrfam:  fibre-channel
   subtype: nvme subsystem
   treq:    not specified
   portid:  0
   trsvcid: none
   subnqn:  nqn.1992-08.com.netapp:sn.c9ecc9187b1111e98c0800a098cbcac6:subsystem.vs_nvme_multipath_1_subsystem_468
   traddr:  nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6

   Replace nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6 with the traddr.

   Replace nn-0x20000024ff19bb62:pn-0x21000024ff19bb62 with the host-traddr.

4. Connect to the NVMe controller using the nvme-cli tool:

   # nvme connect --transport fc \ --traddr nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6 \ --host-traddr nn-0x20000024ff19bb62:pn-0x21000024ff19bb62 \ -n nqn.1992-08.com.netapp:sn.c9ecc9187b1111e98c0800a098cbcac6:subsystem.vs_nvme_multipath_1_subsystem_468\ -k 5

   Note

   If you see the keep-alive timer (5 seconds) expired! error when a connection time exceeds the default keep-alive timeout value, increase it using the -k option. For example, you can use, -k 7.

   Here,

   Replace nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6 with the traddr.

   Replace nn-0x20000024ff19bb62:pn-0x21000024ff19bb62 with the host-traddr.

   Replace nqn.1992-08.com.netapp:sn.c9ecc9187b1111e98c0800a098cbcac6:subsystem.vs_nvme_multipath_1_subsystem_468 with the subnqn.

   Replace 5 with the keep-live timeout value in seconds.

Procedure

1. Install the nvme-cli tool:

   # dnf install nvme-cli

   This tool creates the hostnqn file in the /etc/nvme/ directory, which identifies the NVMe host.

2. Find the nvme hostid and hostnqn:

   # cat /etc/nvme/hostnqn
   nqn.2014-08.org.nvmexpress:uuid:8ae2b12c-3d28-4458-83e3-658e571ed4b8
   
   # cat /etc/nvme/hostid
   09e2ce17-ccc9-412d-8dcf-2b0a1d581ee3

   Use the hostid and hostnqn values to configure the NVMe/TCP controller.

3. Check the status of the controller:

   # nmcli device show ens6
   GENERAL.DEVICE:                         ens6
   GENERAL.TYPE:                           ethernet
   GENERAL.HWADDR:                         52:57:02:12:02:02
   GENERAL.MTU:                            1500
   GENERAL.STATE:                          30 (disconnected)
   GENERAL.CONNECTION:                     --
   GENERAL.CON-PATH:                       --
   WIRED-PROPERTIES.CARRIER:               on

4. Configure the host network for a newly installed Ethernet controller with a static IP address:

   # nmcli connection add con-name ens6 ifname ens6 type ethernet ip4 192.168.101.154/24 gw4 192.168.101.1

   Here, replace 192.168.101.154 with the host IP address.

   # nmcli connection mod ens6 ipv4.method manual
   # nmcli connection up ens6

   Since a new network is created to connect the NVMe/TCP host to the NVMe/TCP controller, execute this step on the controller too.

Procedure

1. Load the nvme-tcp module if not already:

   # modprobe nvme-tcp

2. Discover the available subsystems on the NVMe controller:

   # nvme discover --transport=tcp --traddr=192.168.101.55 --host-traddr=192.168.101.154 --trsvcid=8009
   
   Discovery Log Number of Records 2, Generation counter 7
   =====Discovery Log Entry 0======
   trtype:  tcp
   adrfam:  ipv4
   subtype: current discovery subsystem
   treq:	not specified, sq flow control disable supported
   portid:  2
   trsvcid: 8009
   subnqn:  nqn.2014-08.org.nvmexpress.discovery
   traddr:  192.168.101.55
   eflags:  not specified
   sectype: none
   =====Discovery Log Entry 1======
   trtype:  tcp
   adrfam:  ipv4
   subtype: nvme subsystem
   treq:	not specified, sq flow control disable supported
   portid:  2
   trsvcid: 8009
   subnqn:  nqn.2014-08.org.nvmexpress:uuid:0c468c4d-a385-47e0-8299-6e95051277db
   traddr:  192.168.101.55
   eflags:  not specified
   sectype: none

   Here, 192.168.101.55 is the NVMe/TCP controller IP address and 192.168.101.154 is the NVMe/TCP host IP address.

3. Configure the /etc/nvme/discovery.conf file to add the parameters used in the nvme discover command :

   # echo "--transport=tcp --traddr=192.168.101.55 --host-traddr=192.168.101.154 --trsvcid=8009" >> /etc/nvme/discovery.conf

4. Connect the NVMe/TCP host to the controller system:

   # nvme connect-all

Procedure

1. Check if the native NVMe multipathing is enabled:

   # cat /sys/module/nvme_core/parameters/multipath

   The command displays one of the following:

   N

   Native NVMe multipathing is disabled.

   Y

   Native NVMe multipathing is enabled.

2. If the native NVMe multipathing is enabled, disable it by using one of the following methods:

   • Using a kernel option:

     1. Add the nvme_core.multipath=N option to the command line:

        # grubby --update-kernel=ALL --args="nvme_core.multipath=N"

     2. On the 64-bit IBM Z architecture, update the boot menu:

        # zipl

     3. Reboot the system.

   • Using a kernel module configuration file:

     1. Create the /etc/modprobe.d/nvme_core.conf configuration file with the following content:

        options nvme_core multipath=N

     2. Back up the initramfs file:

        # cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date +%m%d-%H%M%S).img

     3. Rebuild the initramfs:

        # cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date +%m-%d-%H%M%S).img
        # dracut --force --verbose

     4. Reboot the system.

3. Enable DM Multipath:

   # systemctl enable --now multipathd.service

4. Distribute I/O on all available paths. Add the following content in the /etc/multipath.conf file:

   devices {
           device {
                   vendor "NVME"
                   product ".*"
                   path_grouping_policy group_by_prio
           }
   }

   Note

   The /sys/class/nvme-subsystem/nvme-subsys0/iopolicy configuration file has no effect on the I/O distribution when DM Multipath manages the NVMe devices.

5. Reload the multipathd service to apply the configuration changes:

   # multipath -r

Procedure

1. Check if native NVMe multipathing is enabled in the kernel:

   # cat /sys/module/nvme_core/parameters/multipath

   The command displays one of the following:

   N

   Native NVMe multipathing is disabled.

   Y

   Native NVMe multipathing is enabled.

2. If native NVMe multipathing is disabled, enable it by using one of the following methods:

   • Using a kernel option:

     1. Remove the nvme_core.multipath=N option from the kernel command line:

        # grubby --update-kernel=ALL --remove-args="nvme_core.multipath=N"

     2. On the 64-bit IBM Z architecture, update the boot menu:

        # zipl

     3. Reboot the system.

   • Using a kernel module configuration file:

     1. Remove the /etc/modprobe.d/nvme_core.conf configuration file:

        # rm /etc/modprobe.d/nvme_core.conf

     2. Back up the initramfs file:

        # cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date +%m-%d-%H%M%S).img

     3. Rebuild the initramfs:

        # dracut --force --verbose

     4. Reboot the system.

3. Optional: On the running system, change the I/O policy on NVMe devices to distribute the I/O on all available paths:

   # echo "round-robin" > /sys/class/nvme-subsystem/nvme-subsys0/iopolicy

4. Optional: Set the I/O policy persistently using udev rules. Create the /etc/udev/rules.d/71-nvme-io-policy.rules file with the following content:

   ACTION=="add|change", SUBSYSTEM=="nvme-subsystem", ATTR{iopolicy}="round-robin"

Verification

1. Verify if your system recognizes the NVMe devices. The following example assumes you have a connected NVMe over fabrics storage subsystem with two NVMe namespaces:

   # nvme list
   
   Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
   ---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
   /dev/nvme0n1     a34c4f3a0d6f5cec     Linux                                    1         250.06  GB / 250.06  GB    512   B +  0 B   4.18.0-2
   /dev/nvme0n2     a34c4f3a0d6f5cec     Linux                                    2         250.06  GB / 250.06  GB    512   B +  0 B   4.18.0-2

2. List all connected NVMe subsystems:

   # nvme list-subsys
   
   nvme-subsys0 - NQN=testnqn
   \
    +- nvme0 fc traddr=nn-0x20000090fadd597a:pn-0x10000090fadd597a host_traddr=nn-0x20000090fac7e1dd:pn-0x10000090fac7e1dd live
    +- nvme1 fc traddr=nn-0x20000090fadd5979:pn-0x10000090fadd5979 host_traddr=nn-0x20000090fac7e1dd:pn-0x10000090fac7e1dd live
    +- nvme2 fc traddr=nn-0x20000090fadd5979:pn-0x10000090fadd5979 host_traddr=nn-0x20000090fac7e1de:pn-0x10000090fac7e1de live
    +- nvme3 fc traddr=nn-0x20000090fadd597a:pn-0x10000090fadd597a host_traddr=nn-0x20000090fac7e1de:pn-0x10000090fac7e1de live

   Check the active transport type. For example, nvme0 fc indicates that the device is connected over the Fibre Channel transport, and nvme tcp indicates that the device is connected over TCP.

3. If you edited the kernel options, verify if native NVMe multipathing is enabled on the kernel command line:

   # cat /proc/cmdline
   
   BOOT_IMAGE=[...] nvme_core.multipath=Y

4. If you changed the I/O policy, verify if round-robin is the active I/O policy on NVMe devices:

   # cat /sys/class/nvme-subsystem/nvme-subsys0/iopolicy
   
   round-robin

Procedure

1. Install the dracut-network package:

   # dnf install dracut-network

2. Add the following line to the /etc/dracut.conf.d/network.conf file:

   add_dracutmodules+=" nfs "

Procedure

1. Enable the tftp service:

   # systemctl enable --now tftp

2. Create a pxelinux directory inside the tftp root directory:

   # mkdir -p /var/lib/tftpboot/pxelinux/

3. Copy the /usr/share/syslinux/pxelinux.0 file to the /var/lib/tftpboot/pxelinux/ directory:

   # cp /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot/pxelinux/

   • You can find the tftp root directory (chroot) in the /var/lib/tftpboot directory.

4. Copy /usr/share/syslinux/ldlinux.c32 to /var/lib/tftpboot/pxelinux/:

   # cp /usr/share/syslinux/ldlinux.c32 /var/lib/tftpboot/pxelinux/

5. Create a pxelinux.cfg directory inside the tftp root directory:

   # mkdir -p /var/lib/tftpboot/pxelinux/pxelinux.cfg/

   This configuration does not boot over the Unified Extensible Firmware Interface (UEFI). To perform the installation for UEFI, follow the procedure in Configuring a TFTP server for UEFI-based clients.

Procedure

1. Add the configuration to the /etc/dhcp/dhcpd.conf file to setup a DHCP server and enable Preboot Execution Environment (PXE) for booting:

   option space pxelinux;
   option pxelinux.magic code 208 = string;
   option pxelinux.configfile code 209 = text;
   option pxelinux.pathprefix code 210 = text;
   option pxelinux.reboottime code 211 = unsigned integer 32;
   option architecture-type code 93 = unsigned integer 16;
   
   subnet 192.168.205.0 netmask 255.255.255.0 {
     option routers 192.168.205.1;
     range 192.168.205.10 192.168.205.25;
   
     class "pxeclients" {
       match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
       next-server 192.168.205.1;
   
       if option architecture-type = 00:07 {
         filename "BOOTX64.efi";
         } else {
         filename "pxelinux/pxelinux.0";
       }
     }
   }

   • Your DHCP configuration might be different depending on your environment, like setting lease time or fixed address. For details, see Providing DHCP services.

     Note

     While using libvirt virtual machine as a diskless client, the libvirt daemon provides the DHCP service, and the standalone DHCP server is not used. In this situation, network booting must be enabled with the bootp file=<filename> option in the libvirt network configuration, virsh net-edit.

2. Enable dhcpd.service:

   # systemctl enable --now dhcpd.service

Procedure

1. Configure the Network File System (NFS) server to export the root directory by adding it to the /etc/exports directory. For the complete set of instructions see

   • Deploying an NFS server

2. Install a complete version of Red Hat Enterprise Linux to the root directory to accommodate completely diskless clients. To do that you can either install a new base system or clone an existing installation.

   • Install Red Hat Enterprise Linux to the exported location by replacing exported-root-directory with the path to the exported file system:

     # dnf install @Base kernel dracut-network nfs-utils --installroot=exported-root-directory --releasever=/

     By setting the releasever option to /, releasever is detected from the host (/) system.

   • Use the rsync utility to synchronize with a running system:

     # rsync -a -e ssh --exclude='/proc/' --exclude='/sys/' example.com:/ exported-root-directory

     • Replace example.com with the hostname of the running system with which to synchronize via the rsync utility.

     • Replace exported-root-directory with the path to the exported file system.

       Note, that for this option you must have a separate existing running system, which you will clone to the server by the command above.

Configuring a File System

1. Copy the diskless client supported kernel (vmlinuz-_kernel-version_pass:attributes) to the tftp boot directory:

   # cp /exported-root-directory/boot/vmlinuz-kernel-version /var/lib/tftpboot/pxelinux/

2. Create the initramfs-kernel-version.img file locally and move it to the exported root directory with NFS support:

   # dracut --add nfs initramfs-kernel-version.img kernel-version

   For example:

   # dracut --add nfs /exports/root/boot/initramfs-5.14.0-202.el9.x86_64.img 5.14.0-202.el9.x86_64

   Example for creating initrd, using current running kernel version, and overwriting existing image:

   # dracut -f --add nfs "boot/initramfs-$(uname -r).img" "$(uname -r)"

3. Change the file permissions for initrd to 0644:

   # chmod 0644 /exported-root-directory/boot/initramfs-kernel-version.img

   Warning

   If you do not change the initrd file permissions, the pxelinux.0 boot loader fails with a "file not found" error.

4. Copy the resulting initramfs-kernel-version.img file into the tftp boot directory:

   # cp /exported-root-directory/boot/initramfs-kernel-version.img /var/lib/tftpboot/pxelinux/

5. Add the following configuration in the /var/lib/tftpboot/pxelinux/pxelinux.cfg/default file to edit the default boot configuration for using the initrd and the kernel:

   default rhel9
   
   label rhel9
     kernel vmlinuz-kernel-version
     append initrd=initramfs-kernel-version.img root=nfs:_server-ip_:/exported-root-directory rw

   • This configuration instructs the diskless client root to mount the exported file system (/exported-root-directory) in a read/write format.

6. Optional: Mount the file system in a read-only format by editing the /var/lib/tftpboot/pxelinux/pxelinux.cfg/default file with the following configuration:

   default rhel9
   
   label rhel9
     kernel vmlinuz-kernel-version
     append initrd=initramfs-kernel-version.img root=nfs:server-ip:/exported-root-directory ro

7. Restart the NFS server:

   # systemctl restart nfs-server.service

Procedure

1. To change the user password, follow the steps below:

   • Change the command line to /exported/root/directory:

     # chroot /exported/root/directory /bin/bash

   • Change the password for the user you want:

     # passwd <username>

     Replace the <username> with a real user to whom you want to change the password.

   • Exit the command line.

2. Install software on a remote diskless system:

   # dnf install <package> --installroot=/exported/root/directory --releasever=/ --config /etc/dnf/dnf.conf --setopt=reposdir=/etc/yum.repos.d/

   • Replace <package> with the actual package you want to install.

3. Configure two separate exports to split a remote diskless system into a /usr and a /var. See

   • Deploying an NFS server

Procedure

1. Create the LVM2 logical volume of size 2 GB:

   # lvcreate VolGroup00 -n LogVol02 -L 2G

2. Format the new swap space:

   # mkswap /dev/VolGroup00/LogVol02

3. Add the following entry to the /etc/fstab file:

   /dev/VolGroup00/LogVol02 none swap defaults 0 0

4. Regenerate mount units so that your system registers the new configuration:

   # systemctl daemon-reload

5. Activate swap on the logical volume:

   # swapon -v /dev/VolGroup00/LogVol02

Procedure

1. Determine the size of the new swap file in megabytes and multiply by 1024 to determine the number of blocks. For example, the block size of a 64 MB swap file is 65536.

2. Create an empty file:

   # dd if=/dev/zero of=/swapfile bs=1024 count=65536

   Replace 65536 with the value equal to the required block size.

3. Set up the swap file with the command:

   # mkswap /swapfile

4. Change the security of the swap file so it is not world readable.

   # chmod 0600 /swapfile

5. Edit the /etc/fstab file with the following entries to enable the swap file at boot time:

   /swapfile none swap defaults 0 0

   The next time the system boots, it activates the new swap file.

6. Regenerate mount units so that your system registers the new /etc/fstab configuration:

   # systemctl daemon-reload

7. Activate the swap file immediately:

   # swapon /swapfile

Procedure

1. Disable swapping for the associated logical volume:

   # swapoff -v /dev/VolGroup00/LogVol01

2. Resize the LVM2 logical volume by 2 GB:

   # lvresize /dev/VolGroup00/LogVol01 -L +2G

3. Format the new swap space:

   # mkswap /dev/VolGroup00/LogVol01

4. Enable the extended logical volume:

   # swapon -v /dev/VolGroup00/LogVol01

Procedure

1. Disable swapping for the associated logical volume:

   # swapoff -v /dev/VolGroup00/LogVol01

2. Clean the swap signature:

   # wipefs -a /dev/VolGroup00/LogVol01

3. Reduce the LVM2 logical volume by 512 MB:

   # lvreduce /dev/VolGroup00/LogVol01 -L -512M

4. Format the new swap space:

   # mkswap /dev/VolGroup00/LogVol01

5. Activate swap on the logical volume:

   # swapon -v /dev/VolGroup00/LogVol01

Procedure

1. Disable swapping for the associated logical volume:

   # swapoff -v /dev/VolGroup00/LogVol02

2. Remove the LVM2 logical volume:

   # lvremove /dev/VolGroup00/LogVol02

3. Remove the following associated entry from the /etc/fstab file:

   /dev/VolGroup00/LogVol02 none swap defaults 0 0

4. Regenerate mount units to register the new configuration:

   # systemctl daemon-reload

Procedure

1. Disable the /swapfile swap file:

   # swapoff -v /swapfile

2. Remove its entry from the /etc/fstab file accordingly.

3. Regenerate mount units so that your system registers the new configuration:

   # systemctl daemon-reload

4. Remove the actual file:

   # rm /swapfile

Procedure

1. Install the fcoe-utils package:

   # dnf install fcoe-utils

2. Copy the /etc/fcoe/cfg-ethx template file to /etc/fcoe/cfg-interface_name. For example, if you want to configure the enp1s0 interface to use FCoE, enter the following command:

   # cp /etc/fcoe/cfg-ethx /etc/fcoe/cfg-enp1s0

3. Enable and start the fcoe service:

   # systemctl enable --now fcoe

4. Discover the FCoE VLAN on interface enp1s0, create a network device for the discovered VLAN, and start the initiator:

   # fipvlan -s -c enp1s0
   Created VLAN device enp1s0.200
   Starting FCoE on interface enp1s0.200
   Fibre Channel Forwarders Discovered
   interface       | VLAN | FCF MAC
   ------------------------------------------
   enp1s0          | 200  | 00:53:00:a7:e7:1b

5. Optional: Display details about the discovered targets, the LUNs, and the devices associated with the LUNs:

   # fcoeadm -t
   Interface:        enp1s0.200
   Roles:            FCP Target
   Node Name:        0x500a0980824acd15
   Port Name:        0x500a0982824acd15
   Target ID:        0
   MaxFrameSize:     2048 bytes
   OS Device Name:   rport-11:0-1
   FC-ID (Port ID):  0xba00a0
   State:            Online
   
   LUN ID  Device Name   Capacity   Block Size  Description
   ------  -----------  ----------  ----------  ---------------------
        0  sdb           28.38 GiB      512     NETAPP LUN (rev 820a)
        ...

   This example shows that LUN 0 from the SAN has been attached to the host as the /dev/sdb device.

Prerequisites

1. You have installed the mt-st package. For more information, see Installing tape drive management tool.

2. Load the tape drive:

   # mt -f /dev/st0 load

Procedure

1. Check the tape head:

   # mt -f /dev/st0 status
   
   SCSI 2 tape drive:
   File number=-1, block number=-1, partition=0.
   Tape block size 0 bytes. Density code 0x0 (default).
   Soft error count since last status=0
   General status bits on (50000):
    DR_OPEN IM_REP_EN

   Here:

   • the current file number is -1.
   • the block number defines the tape head. By default, it is set to -1.
   • the block size 0 indicates that the tape device does not have a fixed block size.
   • the Soft error count indicates the number of encountered errors after executing the mt status command.
   • the General status bits explains the stats of the tape device.
   • DR_OPEN indicates that the door is open and the tape device is empty. IM_REP_EN is the immediate report mode.

2. If the tape device is not empty, overwrite it:

   # tar -czf /dev/st0 _/source/directory

   This command overwrites the data on a tape device with the content of /source/directory.

3. Back up the /source/directory to the tape device:

   # tar -czf /dev/st0 _/source/directory
   tar: Removing leading `/' from member names
   /source/directory
   /source/directory/man_db.conf
   /source/directory/DIR_COLORS
   /source/directory/rsyslog.conf
   [...]

4. View the status of the tape device:

   # mt -f /dev/st0  status

Prerequisites

1. You have installed the mt-st package. For more information, see Installing tape drive management tool.

2. Load the tape drive:

   # mt -f /dev/nst0 load

Procedure

1. Check the tape head of the non-rewinding tape device /dev/nst0:

   # mt -f /dev/nst0 status

2. Specify the pointer at the head or at the end of the tape:

   # mt -f /dev/nst0 rewind

3. Append the data on the tape device:

   # mt -f /dev/nst0 eod
   # tar -czf /dev/nst0 /source/directory/

4. Back up the /source/directory/ to the tape device:

   # tar -czf /dev/nst0 /source/directory/
   tar: Removing leading `/' from member names
   /source/directory/
   /source/directory/man_db.conf
   /source/directory/DIR_COLORS
   /source/directory/rsyslog.conf
   [...]

5. View the status of the tape device:

   # mt -f /dev/nst0  status

Prerequisites

1. You have installed the mt-st package. For more information, see Installing tape drive management tool.
2. Data is written to the tape device. Fore more information, see Writing to rewinding tape devices or Writing to non-rewinding tape devices.

Prerequisites

1. You have installed the mt-st package. For more information, see Installing tape drive management tool.
2. Data is written to the tape device. For more information, see Writing to rewinding tape devices or Writing to non-rewinding tape devices.

Prerequisites

1. You have installed the mt-st package. For more information, see Installing tape drive management tool.
2. Data is written to the tape device. For more information, see Writing to rewinding tape devices or Writing to non-rewinding tape devices.

Procedure

1. Erase data from the tape device:

   # mt -f /dev/st0 erase

2. Unload the tape device:

   mt -f /dev/st0 offline

Procedure

1. From the left pane of the Manual Partitioning window, select the required partition.
2. Under the Device(s) section, click Modify. The Configure Mount Point dialog box opens.
3. Select the disks that you want to include in the RAID device and click Select.
4. Click the Device Type drop-down menu and select RAID.
5. Click the File System drop-down menu and select your preferred file system type.
6. Click the RAID Level drop-down menu and select your preferred level of RAID.
7. Click Update Settings to save your changes.
8. Click Done to apply the settings to return to the Installation Summary window.

Procedure

1. Create a RAID of two block devices, for example /dev/sda1 and /dev/sdc1:

   # mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sda1 /dev/sdc1
   mdadm: Defaulting to version 1.2 metadata
   mdadm: array /dev/md0 started.

   The level_value option defines the RAID level.

2. Optional: Check the status of the RAID:

   # mdadm --detail /dev/md0
   /dev/md0:
              Version : 1.2
        Creation Time : Thu Oct 13 15:17:39 2022
           Raid Level : raid0
           Array Size : 18649600 (17.79 GiB 19.10 GB)
         Raid Devices : 2
        Total Devices : 2
          Persistence : Superblock is persistent
   
          Update Time : Thu Oct 13 15:17:39 2022
                State : clean
       Active Devices : 2
      Working Devices : 2
       Failed Devices : 0
        Spare Devices : 0
   [...]

3. Optional: Observe the detailed information about each device in the RAID:

   # mdadm --examine /dev/sda1 /dev/sdc1
   /dev/sda1:
             Magic : a92b4efc
           Version : 1.2
       Feature Map : 0x1000
        Array UUID : 77ddfb0a:41529b0e:f2c5cde1:1d72ce2c
              Name : 0
     Creation Time : Thu Oct 13 15:17:39 2022
        Raid Level : raid0
      Raid Devices : 2
   [...]

4. Create a file system on the RAID drive:

   # mkfs -t xfs /dev/md0

   Replace xfs with the file system that you chose to format the drive with.

5. Create a mount point for RAID drive and mount it:

   # mkdir /mnt/raid1
   # mount /dev/md0 /mnt/raid1

   Replace /mnt/raid1 with the mount point.

   If you want that RHEL mounts the md0 RAID device automatically when the system boots, add an entry for your device to the /etc/fstab file:

   /dev/md0   /mnt/raid1 xfs  defaults   0 0

Procedure

1. Log in to the RHEL 9 web console.

   For details, see Logging in to the web console.

2. Click Storage.
3. In the Storage table, click the menu button.

4. From the drop-down menu, select Create MDRAID device.

   

5. In the Create RAID Device dialog box, enter a name for the new RAID.
6. In the RAID Level drop-down list, select a level of RAID you want to use.

7. From the Chunk Size drop-down list, select the size from the list of available options.

   The Chunk Size value specifies how large each block is for data writing. For example, if the chunk size is 512 KiB, the system writes the first 512 KiB to the first disk, the second 512 KiB is written to the second disk, and the third chunk is written to the third disk. If you have three disks in your RAID, the fourth 512 KiB is written to the first disk again.

8. Select the disks you want to use for RAID.
9. Click Create.

Procedure

1. Log in to the RHEL 9 web console.

   For details, see Logging in to the web console.

2. Click Storage.
3. In the Storage table, click the menu button, ⋮, next to the RAID device you want to format.
4. From the drop-down menu, select Format.
5. In the Format dialog box, enter a name.
6. In the Mount Point field, add the mount path.
7. From the Type drop-down list, select the type of file system.

8. Select the Overwrite existing data with zeros checkbox if you want the RHEL web console to rewrite the whole disk with zeros. This option is slower because the program has to go through the whole disk, but it is more secure. Use this option if the disk includes any data and you need to overwrite it.

   If you do not select the Overwrite existing data with zeros checkbox, the RHEL web console rewrites only the disk header. This increases the speed of formatting.

9. If you want to encrypt the volume, select the type of encryption from the Encryption drop-down menu.

   If you do not want to encrypt the volume, select No encryption.

10. In the At boot drop-down menu, select when you want to mount the volume.

11. In the Mount options section:

    1. Select the Mount read only checkbox if you want the to mount the volume as a read-only logical volume.
    2. Select the Custom mount options checkbox and add the mount options if you want to change the default mount option.

12. Format the RAID partition:

    • If you want to format and mount the partition, click the Format and mount button.

    • If you want to only format the partition, click the Format only button.

      Formatting can take several minutes depending on the volume size and which formatting options are selected.

Procedure

1. Log in to the RHEL 9 web console.

   For details, see Logging in to the web console.

2. Click Storage.
3. In the Storage table, click the RAID device on which you want to create a partition table.
4. Click the menu button, ⋮ in the MDRAID device section.
5. From the drop-down menu, select Create partition table.

6. In the Initialize disk dialog box, select the following:

   1. Partitioning:

      • Compatible with all systems and devices (MBR)
      • Compatible with modern system and hard disks > 2TB (GPT)
      • No partitioning

   2. Overwrite:

      • Select the Overwrite existing data with zeros checkbox if you want the RHEL web console to rewrite the whole disk with zeros. This option is slower because the program has to go through the whole disk, but it is more secure. Use this option if the disk includes any data and you want to overwrite it.

        If you do not select the Overwrite existing data with zeros checkbox, the RHEL web console rewrites only the disk header. This increases the speed of formatting.

7. Click Initialize.

   The partitioning table is created and you can now create partitions on that table.

Procedure

1. Log in to the RHEL 9 web console.

   For details, see Logging in to the web console.

2. Click Storage.
3. In the Storage table, click the RAID device on which you want to create a partition.
4. On the RAID device page, scroll to the GPT partitions section and click the menu button, ⋮, next to the partition table you created. It is named Free space by default.
5. Click Create partition.
6. In the Create partition dialog box, enter a name for the file system. Do not use spaces in the name.
7. In the Mount Point field, add the mount path.
8. In the Type drop-down list, select the type of file system.
9. In the Size field, set the size of the partition.

10. Select the Overwrite existing data with zeros checkbox if you want the RHEL web console to rewrite the whole disk with zeros. This option is slower because the program has to go through the whole disk, but it is more secure. Use this option if the disk includes any data and you want to overwrite it.

    If you do not select the Overwrite existing data with zeros checkbox, the RHEL web console rewrites only the disk header. This increases the speed of formatting.

11. If you want to encrypt the volume, select the type of encryption in the Encryption drop-down menu.

    If you do not want to encrypt the volume, select No encryption.

12. In the At boot drop-down menu, select when you want to mount the volume.

13. In the Mount options section:

    1. Select the Mount read only checkbox if you want the to mount the volume as a read-only logical volume.
    2. Select the Custom mount options checkbox and add the mount options if you want to change the default mount option.

14. Create the partition:

    • If you want to create and mount the partition, click the Create and mount button.

    • If you want to only create the partition, click the Create only button.

      Formatting can take several minutes depending on the volume size and which formatting options are selected.

      You can create more partitions after the partition is created.

      At this point, the system uses mounted and formatted RAID.

Procedure

1. Log in to the RHEL 9 web console.

   For details, see Logging in to the web console.

2. Click Storage.
3. In the Storage table, click the menu button.

4. From the drop-down menu, select Create LVM2 volume group.

   

5. In the Create LVM2 volume group dialog box, enter a name for the new volume group.

6. From the Disks list, select a RAID device.

   If you do not see the RAID in the list, unmount the RAID from the system. The RAID device must not be in use by the RHEL 9 system.

7. Click Create.

Procedure

1. Create a playbook file, for example ~/playbook.yml, with the following content:

   ---
   - name: Manage local storage
     hosts: managed-node-01.example.com
     tasks:
       - name: Create a RAID on sdd, sde, sdf, and sdg
         ansible.builtin.include_role:
           name: rhel-system-roles.storage
         vars:
           storage_safe_mode: false
           storage_volumes:
             - name: data
               type: raid
               disks: [sdd, sde, sdf, sdg]
               raid_level: raid0
               raid_chunk_size: 32 KiB
               mount_point: /mnt/data
               state: present

   For details about all variables used in the playbook, see the /usr/share/ansible/roles/rhel-system-roles.storage/README.md file on the control node.

2. Validate the playbook syntax:

   $ ansible-playbook --syntax-check ~/playbook.yml

   Note that this command only validates the syntax and does not protect against a wrong but valid configuration.

3. Run the playbook:

   $ ansible-playbook ~/playbook.yml

Procedure

1. Extend RAID partitions. For more information, see Resizing a partition with parted.

2. Extend RAID to the maximum of the partition capacity:

   # mdadm --grow --size=max /dev/md0

   To set a specific size, write the value of the --size parameter in kB, for example --size=524228.

3. Increase the size of file system. For example, if the volume uses XFS and is mounted to /mnt/, enter:

   # xfs_growfs /mnt/

Procedure

1. Shrink the file system. For more information, see Managing file systems.

2. Decrease the RAID to the size, for example to 512 MB:

   # mdadm --grow --size=524228 /dev/md0

   Write the --size parameter in kB.

3. Shrink the partition to the size you need.

Procedure

1. Copy the contents of the PowerPC Reference Platform (PReP) boot partition from /dev/sda1 to /dev/sdb1:

   # dd if=/dev/sda1 of=/dev/sdb1

2. Update the prep and boot flag on the first partition on both disks:

   $ parted /dev/sda set 1 prep on
   $ parted /dev/sda set 1 boot on
   
   $ parted /dev/sdb set 1 prep on
   $ parted /dev/sdb set 1 boot on

Procedure

1. Insert the install disk.
2. During the initial boot up, select Rescue Mode instead of Install or Upgrade. When the system fully boots into Rescue mode, you can see the command line terminal.

3. From this terminal, execute the following commands:

   1. Create RAID partitions on the target hard drives by using the parted command.
   2. Manually create raid arrays by using the mdadm command from those partitions using any and all settings and options available.
4. Optional: After creating arrays, create file systems on the arrays as well.
5. Reboot the computer and select Install or Upgrade to install. As the Anaconda installer searches the disks in the system, it finds the pre-existing RAID devices.
6. When asked about how to use the disks in the system, select Custom Layout and click Next. In the device listing, the pre-existing MD RAID devices are listed.
7. Select a RAID device and click Edit.
8. Configure its mount point and optionally the type of file system it should use if you did not create one earlier, and then click Done. Anaconda installs to this pre-existing RAID device, preserving the custom options you selected when you created it in Rescue Mode.

Procedure

1. Create the /etc/mdadm.conf configuration file for monitoring array by scanning the RAID details:

   # mdadm --detail --scan >> /etc/mdadm.conf

   Note, that ARRAY and MAILADDR are mandatory variables.

2. Open the /etc/mdadm.conf configuration file with a text editor of your choice and add the MAILADDR variable with the mail address for the notification. For example, add new line:

   MAILADDR example@example.com

   Here, example@example.com is an email address to which you want to receive the alerts from the array monitoring.

3. Save changes in the /etc/mdadm.conf file and close it.

Procedure

1. Check the failed disk:

   1. View the kernel logs:

      # journalctl -k -f

   2. Search for a message similar to the following:

      md/raid:md0: Disk failure on sdd, disabling device.
      
      md/raid:md0: Operation continuing on 3 devices.

   3. Press Ctrl+C on your keyboard to exit the journalctl program.

2. Mark the failed disk as faulty:

   # mdadm --manage /dev/md0 --fail /dev/sdd

3. Optional: Check if the failed disk was marked correctly:

   # mdadm --detail /dev/md0

   At the end of the output is a list of disks in the /dev/md0 RAID where the disk /dev/sdd has the faulty status:

   Number   Major   Minor   RaidDevice State
      0       8       16        0      active sync   /dev/sdb
      1       8       32        1      active sync   /dev/sdc
      -       0        0        2      removed
      3       8       64        3      active sync   /dev/sde
   
      2       8       48        -      faulty   /dev/sdd

4. Remove the failed disk from the RAID:

   # mdadm --manage /dev/md0 --remove /dev/sdd

   Warning

   If your RAID cannot withstand another disk failure, do not remove any disk until the new disk has the active sync status. You can monitor the progress using the watch cat /proc/mdstat command.

5. Add the new disk to the RAID:

   # mdadm --manage /dev/md0 --add /dev/sdf

   The /dev/md0 RAID now includes the new disk /dev/sdf and the mdadm service will automatically starts copying data to it from other disks.

Procedure

1. Check the array for the failed disks behavior:

   # echo check > /sys/block/md0/md/sync_action

   This checks the array and the /sys/block/md0/md/sync_action file shows the sync action.

2. Open the /sys/block/md0/md/sync_action file with the text editor of your choice and see if there is any message about disk synchronization failures.
3. View the /sys/block/md0/md/mismatch_cnt file. If the mismatch_cnt parameter is not 0, it means that the RAID disks need repair.

4. Repair the disks in the array:

   # echo repair > /sys/block/md0/md/sync_action

   This repairs the disks in the array and writes the result into the /sys/block/md0/md/sync_action file.

5. View the synchronization progress:

   # cat /sys/block/md0/md/sync_action
   repair
   
   # cat /proc/mdstat
   Personalities : [raid0] [raid6] [raid5] [raid4] [raid1]
   md0 : active raid1 sdg[1] dm-3[0]
         511040 blocks super 1.2 [2/2] [UU]
   unused devices: <none>