Bookmark this page

Chapter 7. Managing RHV Storage

Abstract

Goal Create and manage data storage domains.
Objectives
  • Explain how data storage domains and the Storage Pool Manager work.

  • Create and manage data storage domains from NFS, iSCSI, and GlusterFS sources.

  • Explain how to configure volume and image storage from an external OpenStack provider.

Sections
  • Creating and Managing Storage Domains (and Guided Exercise)

  • Configuring External Storage Providers (and Quiz)

Lab

Managing RHV Storage

Creating and Managing Storage Domains

Objectives

After completing this section, you should be able to:

  • Describe how data storage domains and the Storage Pool Manager work.

  • Create and manage data storage domains from NFS, iSCSI and GlusterFS sources.

Storage Domain Overview

A storage domain is a collection of images with a common storage interface. A storage domain contains images of templates, virtual machines, snapshots, and ISO files. A storage domain is made of either block devices (iSCSI, FC) or a file system (NFS, GlusterFS).

On file system backed storage, all virtual disks, templates, and snapshots are files. On block device backed storage, each virtual disk, template, or snapshot is a logical volume. Block devices are aggregated into a logical entity called a volume group, and then divided by LVM (Logical Volume Manager) into logical volumes for use as virtual hard disks.

Virtual disks use either the QCOW2 or raw format. Storage can be either sparse or preallocated. Snapshots are always sparse, but can be taken for disks of either format. Virtual machines that share the same storage domain can migrate between hosts in the same cluster.

Types of Storage Domain Back Ends

Storage domains may use file-based or block-based storage. The supported file-based storage types are NFS, GlusterFS, other POSIX compliant file system, or local host storage devices. The supported block-based storage types are iSCSI and Fibre Channel (FC).

NFS

Red Hat Virtualization (RHV) supports NFS exports to create a storage domain. NFS exports are easy to manage, and work seamlessly with RHV. RHV recognizes NFS export resizing immediately, without requiring any additional manual intervention. NFS is supported for data, ISO, and export storage domains. When enterprise NFS is deployed over 10GbE, segregated with VLANs, and individual services are configured to use specific ports, it is both fast and secure.

GlusterFS

RHV supports the native GlusterFS driver for creating a Red Hat Gluster Storage backed data storage domain. Three or more servers are configured as a Red Hat Gluster Storage server cluster, instead of using a SAN array. Red Hat Storage should be used over 10GbE and segregated with VLANs. Red Hat Gluster Storage is only supported for data domains.

Important

Not all versions of RHV work with all versions of Red Hat Gluster Storage. Refer to the Red Hat Gluster Storage Version Compatibility and Support document at https://access.redhat.com/articles/2356261 to verify.

iSCSI

An iSCSI-based storage domain enables RHV to use existing Ethernet networks to connect to the block devices presented as LUNs in an iSCSI target. iSCSI-based storage is only supported for data domains. In a production environment, also consider booting hosts from the enterprise grade iSCSI server Enterprise iSCSI servers have native cloning features for easy deployment of new hosts using host templates. For optimum performance, hosts should use hardware-based iSCSI initiators and deploy over 10 GbE or faster networks.

FC SAN

RHV also supports fast and secure Fibre Channel based SANs to create data storage domains. If you already have FC SAN in your environment, then you should take advantage of it for RHV. However, FC SANs require specialized network devices and skills to operate. Like iSCSI, a FC SAN also supports booting hosts directly from storage. FC SAN has the native cloning features to support easy deployment of new hosts using host templates.

Local storage

Local storage should only be considered for small lab environments. Do not use local storage for production workloads. Local storage precludes the use of live migration, snapshots, and the flexibility that virtualization supports.

Describing the Storage Pool Manager

The host that can make changes to the structure of the data domain is known as the Storage Pool Manager (SPM). The SPM coordinates all metadata changes in the data center, such as creating and deleting disk images, creating and merging snapshots, copying images between storage domains, creating templates, and storage allocation for block devices. There is one SPM for every data center. All other hosts can only read storage domain structural metadata.

All hosts can read and write to stored images within a storage domain, but only the SPM can apply changes to the configuration of storage domains. Either manually enable a host as the SPM, or let RHV-M select one automatically.

Figure 7.1: Storage Pool Manager writing metadata

RHV-M identifies the SPM based on the SPM assignment history for the host. If the host was the last SPM used, RHV-M selects the host as the SPM. If the selected SPM is unresponsive, RHV-M randomly selects another potential SPM. This selection process requires the host to assume and retain a storage-centric lease, which allows the host to modify storage metadata. Storage-centric leases are saved in the storage domain, rather than in the RHV-M or hosts.

The SPM must be running on a data center host to add and configure storage domains. An administrator must register a host (hypervisor) before setting up a new data center. Once a host is part of the data center, it is possible to configure the data center storage domains.

In an NFS data domain, the SPM creates a virtual machine disk as a file in the file system, either as a QCOW2 file for thin provisioning (sparse), or as a normal file for preallocated storage space (RAW).

In an iSCSI or FC data domain, the SPM creates a volume group (VG) on the storage domain's LUN, and creates a virtual machine disk as a logical volume (LV) in that volume group. For a preallocated virtual disk, the SPM creates a logical volume of the specified size (in GB). For a thin provisioned virtual disk, the SPM initially creates a 512 MB logical volume. The host on which the virtual machine is running continuously monitors the logical volume. If the host determines that more space is needed, then the host notifies the SPM, and the SPM extends the logical volume by another 512 MB.

From a performance standpoint, a preallocated (RAW) virtual disk is significantly faster than a thin provisioned (QCOW2) virtual disk. The recommended practice is to use thin provisioning for non-I/O intensive virtual desktops, and preallocation for virtual servers.

Storage Domain Types

Red Hat Virtualization supports three types of storage domains. Beginning in RHV 4, the ISO and export storage domains are deprecated, but remain available and supported. Functionality for ISO and export storage domains is now handled by data storage domains.

Data Storage Domain

A data storage domain stores hard disk images for virtual machines. These disk images can contain the operating system or other virtual machine data. ISO disk images, used to install operating systems and applications, are uploaded to a data domain. When creating a new virtual machine, an ISO image from a data storage domain is attached as a virtual CD/DVD drive. Data storage domains support NFS, iSCSI, FC, GlusterFS and POSIX compliant storage backing. Every RHV data center must have at least one data storage domain. A data domain can be associated with only one RHV data center at a time.

ISO Storage Domain

An ISO storage domain stores disk images used to install virtual machine operating systems and applications. These are ISO 9660-formatted CD or DVD images. Unlike the data storage domain, the ISO storage domain can store only ISO images and not hard disk images. Only one ISO domain is needed in a data center, and a single ISO domain can be shared by multiple data centers in a deployed RHV environment. An ISO storage domain supports the NFS, GlusterFS, and POSIX compliant storage backing.

Export Storage Domain

An export storage domain holds hard disk images and virtual machine templates to transfer between data centers. An export storage domain can be attached to only one data center at a time. To share the domain contents across data centers, detach the export storage domain from the current data center and attach it to the intended data center. Export storage domains support the NFS, GlusterFS, and POSIX compliant storage backing.

Note

The ISO and export storage domains are deprecated. Instead, upload ISO images to any data storage domain. Also, use a data storage domain to transfer data between data centers. To move images and templates, detach the data storage domain from the source data center and attach it to the destination data center.

Configuring an NFS backed Storage Domain

To configure an NFS backed storage domain, navigate to StorageDomains from the Administration Portal menu. From the Storage Domains page, click the New Domain button to open the New Domain window. Specify appropriate values for the required fields.

Enter a meaningful name and optional description for the new storage domain. Select the data center from the drop-down list in the Data Center field that the storage domain will serve. New virtual disks created for virtual machines assigned to this data center are stored in the storage domain for this data center. The Domain Function field selects one of the three storage domain types described previously.

Figure 7.2: Creating an NFS-based storage domain

When configuring an NFS backed storage domain, select NFS from the drop-down list for the Storage Type field to enable additional NFS related fields. In the Export Path field, enter a complete NFS server and share name, such as nfs-server:/filesystem_path. The NFS shares must be previously created, and configured with correct ownership and permissions, to be available for connection.

RHV will attempt to access and create initial metadata structures on the NFS share. In the Host to Use field, you can specify any data center host that is correctly configured to access the share URL for the NFS server. The designated host will NFS mount the share and perform the initial storage domain configuration tasks.

Note

When specifying the Host to Use, any correctly configured data center host is sufficient. You do not need to select the SPM. Also, this selection does not make that host preferred for subsequent, ongoing storage domain activity.

Click the OK button to create the NFS storage domain. If successfully created, then the storage domain will list as active in the Storage Domains table.

Configuring an iSCSI backed Storage Domain

Red Hat Virtualization supports iSCSI backed storage to create a data storage domain. iSCSI storage domains are configured as iSCSI server targets containing configured LUNs. Hosts act as iSCSI initiators, and log in to the iSCSI target specified by the data domain to locate the LUNs. Only one storage domain at a time can connect to and use each iSCSI LUN.

To configure an iSCSI backed data storage domain, navigate to StorageDomains from the Administration Portal menu. From the Storage Domains page, click the New Domain button to open the New Domain window. Specify appropriate values for the required fields.

Figure 7.3: Creating an iSCSI backed storage domain

When configuring an iSCSI backed storage domain, selecting iSCSI from the drop-down list for the Storage Type field enables additional iSCSI related fields. Set the IP address and port for the iSCSI target server, and then click Discover to discover the available targets. Select the right arrow button to log in to the presented target.

After successfully logging in to the target, a + button appears next to the iSCSI target. Clicking on the button expands and displays a list of available iSCSI LUNs for the target. An Add button displays next to each LUN, to include the LUN in the storage domain. After adding one or more LUNs, click the OK button to confirm creating the iSCSI backed storage domain.

Note

Previously used LUNs contain metadata that prevents the LUN from being accidentally selected for another domain. To reuse a LUN, you must clear the partition table for that LUN. To determine the LUN ID, use the multipath -l command on any RHV Host supporting the iSCSI storage domain.

host# dd if=/dev/zero of=/dev/mapper/LUN_ID bs=1M count=200 oflag=direct

After clearing the partition table for a LUN, use the systemctl command to stop all of the multipathd.service instances on every domain host. When all multipathd.service instances are stopped, start them all again.

Configuring a GlusterFS backed Storage Domain

Red Hat Virtualization supports using Red Hat Gluster Storage to create block device backed storage domains. Red Hat Gluster Storage presents a GlusterFS volume made of combined XFS file system bricks, which are redundantly distributed across multiple storage nodes for performance and resiliency. GlusterFS provides flexible and scalable storage to handle the dynamic storage growth of data centers in Red Hat Virtualization.

Install the glusterfs-fuse and glusterfs packages on your data center hosts to enable native GlusterFS client support.

Figure 7.4: Red Hat Virtualization Integrated with Red Hat Gluster Storage

To configure a GlusterFS backed data storage domain, navigate to StorageDomains from the Administration Portal menu. Specify appropriate values for the required fields.

When configuring an iSCSI backed storage domain, selecting GlusterFS from the drop-down list for the Storage Type field enables additional GlusterFS related fields. In the Path field, specify the IP address and name for the GlusterFS volume using a colon (:) as the delimiter. Be sure to specify any required Mount Options that you generally use on your GlusterFS mount command. Click the OK button to confirm the creation of the storage domain.

References

For more information, refer to the Storage chapter in the Red Hat Virtualization Administration Guide at https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html-single/administration_guide/chap-storage

Revision: rh318-4.3-c05018e