From 1b2ff7d535c4d04d0841f4a29229013b44411fa8 Mon Sep 17 00:00:00 2001 From: Dmitrii Gilev Date: Fri, 18 Sep 2026 15:20:43 +0200 Subject: [PATCH 1/4] F OpenNebula/engineering#910: Refactored Generic SAN guide, added FC, updated iSCSI, DM multipath conf and FE configuration Signed-off-by: Dmitrii Gilev --- .../lvm/generic_guide.md | 300 ++++++++++++++---- 1 file changed, 230 insertions(+), 70 deletions(-) diff --git a/content/product/cluster_configuration/lvm/generic_guide.md b/content/product/cluster_configuration/lvm/generic_guide.md index 89d0f12e6..db71c6a38 100644 --- a/content/product/cluster_configuration/lvm/generic_guide.md +++ b/content/product/cluster_configuration/lvm/generic_guide.md @@ -5,109 +5,269 @@ weight: "4" --- -### Hosts SAN Configuration +This guide describes how to configure a generic SAN-backed LVM datastore for OpenNebula. -The abstraction required to access LUNs consists of block devices. This means that there are several ways to set them up, although it usually involves using a network block protocol such as iSCSI or Fibre Channel, as well as some form of path redundancy, such as DM Multipath. + -Hypervisor hosts acting as SCSI initiators must be configured according to the storage vendor's documentation and recommended best practices. The exact implementation may vary depending on the storage platform, access protocol (iSCSI or Fibre Channel), and multipathing requirements. Vendor-specific guidance should always take precedence over generic operating system configuration procedures. +## Hosts SAN Configuration -The following example illustrates a generic iSCSI and DM Multipath configuration on Linux hosts and is provided for reference purposes only. +The LUNs used by the LVM datastore must be exposed as block devices to all hypervisor hosts using the datastore. They can be accessed using iSCSI or Fibre Channel, with DM Multipath providing path redundancy when multiple paths to the storage are available. +The storage system, iSCSI targets or Fibre Channel fabric, and LUN mappings must be configured according to the storage vendor's documentation. The following sections describe the host-side configuration for iSCSI, Fibre Channel, and DM Multipath. + +### iSCSI + +When iSCSI is used to provide access to the SAN, each OpenNebula Host must have an iSCSI initiator configured and network connectivity to the storage targets. + +Before configuring the iSCSI initiator, ensure that: + +- The iSCSI target is configured on the storage system. +- The required LUNs are mapped to the corresponding iSCSI initiators. +- All OpenNebula Hosts that need access to the datastore can access the same LUNs. +- Network connectivity between the OpenNebula Hosts and the iSCSI target is available. +- For redundant configurations, multiple paths to the storage are available. + +#### Install the iSCSI initiator tools. + +##### RHEL/AlmaLinux + +On RHEL and AlmaLinux, the iSCSI initiator tools are provided by the `iscsi-initiator-utils` package: + +```bash +dnf install iscsi-initiator-utils sg3-utils +``` + +##### Debian/Ubuntu + +On Debian and Ubuntu, the iSCSI initiator tools are provided by the `open-iscsi` package: + +```bash +apt update +apt install open-iscsi sg3-utils +``` + +##### SUSE/openSUSE + +On SUSE and openSUSE, install the iSCSI initiator tools with: + +```bash +zypper install open-iscsi sg3_utils +``` + +#### Configure the iSCSI Initiator + +Enable and start the `iscsid` service: + +```bash +systemctl enable --now iscsid +``` + +The initiator IQN required when configuring LUN mapping or access control on the storage system. + +The iSCSI initiator name assigned to the Host can be checked in `/etc/iscsi/initiatorname.iscsi`: + +Discover the iSCSI targets available on the storage system: + +```bash +iscsiadm -m discovery -t sendtargets -p +``` + +The discovery operation creates node records for the targets returned by the storage system. The configured nodes can be listed with: + +```bash +iscsiadm -m node +``` + +Log in to the required iSCSI target: + +```bash +iscsiadm -m node -T -p --login ``` -# === ISCSI === -TARGET_IP="192.168.1.100" # IP of SAN appliance -TARGET_IQN="iqn.2023-01.com.example:storage.target1" # iSCSI Qualified Name +If the same target is accessible through multiple storage interfaces, repeat the discovery and login process for each required path. + +Verify the active iSCSI sessions: -# === Install tools === -# RedHat derivates: -sudo dnf install -y iscsi-initiator-utils -# Ubuntu/Debian: -sudo apt update && sudo apt install -y open-iscsi -# SLES/openSUSE: -sudo zypper install -y open-iscsi +```bash +iscsiadm -m session +``` + +Configure the target to be automatically connected after the Host reboots: -# === Enable iSCSI services === -# RedHat derivates: -sudo systemctl enable --now iscsid -# Ubuntu/Debian: -sudo systemctl enable --now open-iscsi -# SLES/openSUSE: -sudo systemctl enable --now iscsid.socket iscsi +```bash +iscsiadm -m node -T -p --op update -n node.startup -v automatic +``` -# === Discover targets === -sudo iscsiadm -m discovery -t sendtargets -p "$TARGET_IP" +After logging in to the target, the LUNs mapped to the initiator should be detected by the Linux SCSI subsystem and exposed as block devices. -# === Log in to the target === -sudo iscsiadm -m node -T "$TARGET_IQN" -p "$TARGET_IP" --login +Verify that the SAN LUNs are visible: -# === Make login persistent across reboots === -sudo iscsiadm -m node -T "$TARGET_IQN" -p "$TARGET_IP" \ - --op update -n node.startup -v automatic +```bash +lsblk ``` +The detected SCSI devices can also be inspected with: +```bash +lsscsi ``` -# === MULTIPATH === -# === Install tools === -# RedHat derivates: -sudo dnf install -y device-mapper-multipath -# Ubuntu/Debian: -sudo apt update && sudo apt install -y multipath-tools -# SLES/openSUSE: -sudo zypper install -y multipath-tools +If new LUNs are presented to an already connected Host, or the expected LUNs are not detected automatically, rescan the SCSI buses to discover new devices. -# === Enable multipath daemon === -sudo systemctl enable --now multipathd +```bash +rescan-scsi-bus.sh +``` + +### Fibre Channel + +When Fibre Channel is used to provide access to the SAN, each OpenNebula Host must have one or more Fibre Channel HBAs configured and connected to the SAN fabric. + +Before configuring the operating system, ensure that: + +- The Fibre Channel HBAs are detected by the operating system. +- The required zoning is configured on the Fibre Channel switches. +- The SAN LUNs are mapped to the WWPNs of the corresponding OpenNebula Hypervisors. +- All Hosts that need access to the datastore can access the same LUNs. +- For redundant configurations, multiple independent paths to the storage are available. + +The exact zoning, LUN mapping, and HBA configuration depends on the SAN and Fibre Channel infrastructure. Refer to the storage and Fibre Channel switch vendor documentation for the recommended configuration. + +Check the Fibre Channel HBA ports available on the Host: +```bash +ls /sys/class/fc_host/ +``` + +The WWPNs of the Fibre Channel HBA ports can be obtained with: + +```bash +cat /sys/class/fc_host/host*/port_name +``` -# === Create multipath config file === -sudo tee /etc/multipath.conf > /dev/null < ## Front-end Configuration -The Front-end needs access to the shared SAN server in order to perform LVM operations. It can -either access it directly, or using some host(s) as proxy/bridge. +The Front-end needs access to the shared SAN storage to perform LVM operations. It can either access the SAN directly or use one or more hypervisor hosts as SAN proxies. -For direct access, **the Front-end will need to be configured in the same way as hosts**, and no -further configuration will be needed. Example for illustration purposes: +For direct access, the Front-end must be configured in the same way as the hypervisor hosts. For iSCSI storage, it must have connectivity to the iSCSI target and be configured as an iSCSI initiator. For Fibre Channel storage, it must have Fibre Channel connectivity to the SAN, and the required LUNs must be presented to the WWPNs of its Fibre Channel HBA ports. -``` +When DM Multipath is used, it must also be configured on the Front-end so that the SAN LUNs are available as Multipath devices. No additional OpenNebula configuration is required for direct SAN access. + +Example for illustration purposes: + +```text ------------- | Front-end | ---- /dev/mapper/mpath* ------+ -------------- (iSCSI + multipath) | - | - v - --------- -------------- - | host2 | ---- /dev/mapper/mpath* ---> | SAN server | - --------- (iSCSI + multipath) -------------- - ^ - | - --------- | - | hostN | ---- /dev/mapper/mpath* --------+ - --------- (iSCSI + multipath) -``` - -Alternatively, delegate front-end SAN operations to one or more specific hosts by setting the `BRIDGE_LIST` attribute in both the System and Image datastores. The front-end refers to one of the hosts in the list to proxy SAN operations. Only a reduced set of operations are initiated in the front-end, such as the ones intended for undeployed VMs. +------------- + (iSCSI/FC + Multipath) | + | + v +--------- --------------- +| host2 | ---- /dev/mapper/mpath* -----> | SAN Target | +--------- (iSCSI/FC + Multipath) --------------- + ^ + | +--------- | +| hostN | ---- /dev/mapper/mpath* -----------+ +--------- + (iSCSI/FC + Multipath) +``` + +If direct SAN connectivity cannot be provided to the Front-end, set the `BRIDGE_LIST` attribute in both the System and Image datastores to specify one or more hypervisor hosts that will act as SAN proxies. + +This configuration is particularly useful with Fibre Channel storage when the Front-end does not have an FC HBA or cannot be connected to the Fibre Channel fabric. The hosts specified in `BRIDGE_LIST` must have access to the SAN and be configured with the corresponding iSCSI or Fibre Channel connectivity and DM Multipath configuration. ## Troubleshooting From 88416e92f6b88bc7116d8c3c56cf73e33a856131 Mon Sep 17 00:00:00 2001 From: Dmitrii Gilev Date: Tue, 29 Sep 2026 15:44:39 +0200 Subject: [PATCH 2/4] F OpenNebula/engineering#910: fixed a small typo in line 67 Signed-off-by: Dmitrii Gilev --- content/product/cluster_configuration/lvm/generic_guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/product/cluster_configuration/lvm/generic_guide.md b/content/product/cluster_configuration/lvm/generic_guide.md index db71c6a38..16137ddc8 100644 --- a/content/product/cluster_configuration/lvm/generic_guide.md +++ b/content/product/cluster_configuration/lvm/generic_guide.md @@ -64,7 +64,7 @@ systemctl enable --now iscsid The initiator IQN required when configuring LUN mapping or access control on the storage system. -The iSCSI initiator name assigned to the Host can be checked in `/etc/iscsi/initiatorname.iscsi`: +The iSCSI initiator name assigned to the Host can be checked in `/etc/iscsi/initiatorname.iscsi`. Discover the iSCSI targets available on the storage system: From e3abfc396f4d0281e48eb2859768ae366901e785 Mon Sep 17 00:00:00 2001 From: Dmitrii Gilev Date: Tue, 29 Sep 2026 17:40:45 +0200 Subject: [PATCH 3/4] F OpenNebula/engineering#910: addressed some techniacal inconsistencies based on feedback from Matt Signed-off-by: Dmitrii Gilev --- .../lvm/generic_guide.md | 43 +++++++++++++++---- 1 file changed, 34 insertions(+), 9 deletions(-) diff --git a/content/product/cluster_configuration/lvm/generic_guide.md b/content/product/cluster_configuration/lvm/generic_guide.md index 16137ddc8..976af551a 100644 --- a/content/product/cluster_configuration/lvm/generic_guide.md +++ b/content/product/cluster_configuration/lvm/generic_guide.md @@ -15,6 +15,29 @@ The LUNs used by the LVM datastore must be exposed as block devices to all hyper The storage system, iSCSI targets or Fibre Channel fabric, and LUN mappings must be configured according to the storage vendor's documentation. The following sections describe the host-side configuration for iSCSI, Fibre Channel, and DM Multipath. +#### Install the SCSI Utilities + +The SCSI utilities are used to inspect discovered LUNs and rescan the SCSI buses. Install them on all hypervisor hosts that access the SAN. + +##### RHEL/AlmaLinux + +```bash +dnf install -y sg3_utils +``` + +##### Debian/Ubuntu + +```bash +apt update +apt install -y sg3-utils +``` + +##### SUSE/openSUSE + +```bash +zypper install -y sg3_utils +``` + ### iSCSI When iSCSI is used to provide access to the SAN, each OpenNebula Host must have an iSCSI initiator configured and network connectivity to the storage targets. @@ -34,7 +57,7 @@ Before configuring the iSCSI initiator, ensure that: On RHEL and AlmaLinux, the iSCSI initiator tools are provided by the `iscsi-initiator-utils` package: ```bash -dnf install iscsi-initiator-utils sg3-utils +dnf install iscsi-initiator-utils ``` ##### Debian/Ubuntu @@ -43,7 +66,7 @@ On Debian and Ubuntu, the iSCSI initiator tools are provided by the `open-iscsi` ```bash apt update -apt install open-iscsi sg3-utils +apt install open-iscsi ``` ##### SUSE/openSUSE @@ -51,7 +74,7 @@ apt install open-iscsi sg3-utils On SUSE and openSUSE, install the iSCSI initiator tools with: ```bash -zypper install open-iscsi sg3_utils +zypper install open-iscsi ``` #### Configure the iSCSI Initiator @@ -62,7 +85,7 @@ Enable and start the `iscsid` service: systemctl enable --now iscsid ``` -The initiator IQN required when configuring LUN mapping or access control on the storage system. +The initiator IQN may be required when configuring LUN mapping or access control on the storage system. The iSCSI initiator name assigned to the Host can be checked in `/etc/iscsi/initiatorname.iscsi`. @@ -98,6 +121,8 @@ Configure the target to be automatically connected after the Host reboots: iscsiadm -m node -T -p --op update -n node.startup -v automatic ``` +If the target is accessed through multiple storage interfaces, repeat this configuration for each required target portal. + After logging in to the target, the LUNs mapped to the initiator should be detected by the Linux SCSI subsystem and exposed as block devices. Verify that the SAN LUNs are visible: @@ -154,7 +179,7 @@ Verify that the SAN LUNs are visible: lsblk ``` -If `lsscsi` is installed, the discovered SCSI devices can also be verified with: +The discovered SCSI devices can also be verified with: ```bash lsscsi @@ -180,7 +205,7 @@ The exact Multipath configuration depends on the storage system. Refer to the st dnf install -y device-mapper-multipath ``` -#### Debian/Ubuntu +##### Debian/Ubuntu ```bash apt update @@ -267,7 +292,7 @@ Example for illustration purposes: If direct SAN connectivity cannot be provided to the Front-end, set the `BRIDGE_LIST` attribute in both the System and Image datastores to specify one or more hypervisor hosts that will act as SAN proxies. -This configuration is particularly useful with Fibre Channel storage when the Front-end does not have an FC HBA or cannot be connected to the Fibre Channel fabric. The hosts specified in `BRIDGE_LIST` must have access to the SAN and be configured with the corresponding iSCSI or Fibre Channel connectivity and DM Multipath configuration. +This configuration is particularly useful with Fibre Channel storage when the Front-end does not have an FC HBA or cannot be connected to the Fibre Channel fabric. The hosts specified in `BRIDGE_LIST` must have access to the SAN and be configured with the corresponding iSCSI or Fibre Channel connectivity and, when multiple paths are available, DM Multipath. ## Troubleshooting @@ -291,8 +316,8 @@ If it returns `devices/use_devicesfile=1`, then the devices file is being used a case, just add the device path to the whitelist and check again: ``` -# echo /dev/mapper/mpatha >> /etc/lvm/devices/system.devices -# pvs +lvmdevices --adddev /dev/mapper/mpatha +pvs ``` ### Pool becomes full after live datastore migration From 7333c10e0d8bb864fdc0c50a23b4a1ed43879c2a Mon Sep 17 00:00:00 2001 From: mattrowe-opennebula Date: Tue, 29 Sep 2026 17:58:20 +0200 Subject: [PATCH 4/4] M #~: TW review --- .../lvm/generic_guide.md | 133 +++++++++--------- 1 file changed, 70 insertions(+), 63 deletions(-) diff --git a/content/product/cluster_configuration/lvm/generic_guide.md b/content/product/cluster_configuration/lvm/generic_guide.md index 976af551a..5425eaea6 100644 --- a/content/product/cluster_configuration/lvm/generic_guide.md +++ b/content/product/cluster_configuration/lvm/generic_guide.md @@ -11,32 +11,34 @@ This guide describes how to configure a generic SAN-backed LVM datastore for Ope ## Hosts SAN Configuration -The LUNs used by the LVM datastore must be exposed as block devices to all hypervisor hosts using the datastore. They can be accessed using iSCSI or Fibre Channel, with DM Multipath providing path redundancy when multiple paths to the storage are available. +The LUNs used by the LVM datastore must be exposed as block devices to all hypervisor Hosts using the datastore. They can be accessed using iSCSI or Fibre Channel, with DM Multipath providing path redundancy when multiple paths to the storage are available. -The storage system, iSCSI targets or Fibre Channel fabric, and LUN mappings must be configured according to the storage vendor's documentation. The following sections describe the host-side configuration for iSCSI, Fibre Channel, and DM Multipath. +The storage system, iSCSI targets or Fibre Channel fabric, and LUN mappings must be configured according to the storage vendor's documentation. The following sections describe the Host-side configuration for iSCSI, Fibre Channel, and DM Multipath. #### Install the SCSI Utilities -The SCSI utilities are used to inspect discovered LUNs and rescan the SCSI buses. Install them on all hypervisor hosts that access the SAN. +The SCSI utilities are used to inspect discovered LUNs and re-scan the SCSI buses. Install them on all hypervisor Hosts that access the SAN. -##### RHEL/AlmaLinux +{{< tabpane text=true right=false >}} +{{% tab header="**OS**:" disabled=true /%}} -```bash +{{% tab header="RHEL / AlmaLinux"%}} +```shell dnf install -y sg3_utils ``` - -##### Debian/Ubuntu - -```bash +{{% /tab %}} +{{% tab header="Debian / Ubuntu"%}} +```shell apt update apt install -y sg3-utils ``` - -##### SUSE/openSUSE - -```bash +{{% /tab %}} +{{% tab header="SUSE / openSUSE"%}} +```shell zypper install -y sg3_utils ``` +{{% /tab %}} +{{< /tabpane >}} ### iSCSI @@ -48,62 +50,64 @@ Before configuring the iSCSI initiator, ensure that: - The required LUNs are mapped to the corresponding iSCSI initiators. - All OpenNebula Hosts that need access to the datastore can access the same LUNs. - Network connectivity between the OpenNebula Hosts and the iSCSI target is available. -- For redundant configurations, multiple paths to the storage are available. +- For redundant configurations, multiple paths to the storage are available. -#### Install the iSCSI initiator tools. +#### Install the iSCSI Initiator Tools -##### RHEL/AlmaLinux +{{< tabpane text=true right=false >}} +{{% tab header="**OS**:" disabled=true /%}} +{{% tab header="RHEL / AlmaLinux"%}} On RHEL and AlmaLinux, the iSCSI initiator tools are provided by the `iscsi-initiator-utils` package: -```bash +```shell dnf install iscsi-initiator-utils ``` - -##### Debian/Ubuntu - +{{% /tab %}} +{{% tab header="Debian / Ubuntu"%}} On Debian and Ubuntu, the iSCSI initiator tools are provided by the `open-iscsi` package: -```bash +```shell apt update apt install open-iscsi ``` - -##### SUSE/openSUSE - +{{% /tab %}} +{{% tab header="SUSE / openSUSE"%}} On SUSE and openSUSE, install the iSCSI initiator tools with: -```bash +```shell zypper install open-iscsi ``` +{{% /tab %}} +{{< /tabpane >}} #### Configure the iSCSI Initiator Enable and start the `iscsid` service: -```bash +```shell systemctl enable --now iscsid ``` The initiator IQN may be required when configuring LUN mapping or access control on the storage system. -The iSCSI initiator name assigned to the Host can be checked in `/etc/iscsi/initiatorname.iscsi`. +The iSCSI initiator name assigned to the Host can be inspected in `/etc/iscsi/initiatorname.iscsi`. Discover the iSCSI targets available on the storage system: -```bash +```shell iscsiadm -m discovery -t sendtargets -p ``` The discovery operation creates node records for the targets returned by the storage system. The configured nodes can be listed with: -```bash +```shell iscsiadm -m node ``` Log in to the required iSCSI target: -```bash +```shell iscsiadm -m node -T -p --login ``` @@ -111,13 +115,13 @@ If the same target is accessible through multiple storage interfaces, repeat the Verify the active iSCSI sessions: -```bash +```shell iscsiadm -m session ``` Configure the target to be automatically connected after the Host reboots: -```bash +```shell iscsiadm -m node -T -p --op update -n node.startup -v automatic ``` @@ -127,18 +131,18 @@ After logging in to the target, the LUNs mapped to the initiator should be detec Verify that the SAN LUNs are visible: -```bash +```shell lsblk ``` The detected SCSI devices can also be inspected with: -```bash +```shell lsscsi ``` -If new LUNs are presented to an already connected Host, or the expected LUNs are not detected automatically, rescan the SCSI buses to discover new devices. +If new LUNs are presented to an already connected Host, or the expected LUNs are not detected automatically, re-scan the SCSI buses to discover new devices. -```bash +```shell rescan-scsi-bus.sh ``` @@ -157,72 +161,75 @@ Before configuring the operating system, ensure that: The exact zoning, LUN mapping, and HBA configuration depends on the SAN and Fibre Channel infrastructure. Refer to the storage and Fibre Channel switch vendor documentation for the recommended configuration. Check the Fibre Channel HBA ports available on the Host: -```bash + +```shell ls /sys/class/fc_host/ ``` The WWPNs of the Fibre Channel HBA ports can be obtained with: -```bash +```shell cat /sys/class/fc_host/host*/port_name ``` Check the state of the Fibre Channel ports: -```bash +```shell cat /sys/class/fc_host/host*/port_state ``` Verify that the SAN LUNs are visible: -```bash +```shell lsblk ``` The discovered SCSI devices can also be verified with: -```bash +```shell lsscsi ``` -If new LUNs are presented to an already connected Host, or the expected LUNs are not detected automatically, rescan the SCSI buses to discover new devices. +If new LUNs are presented to an already connected Host, or the expected LUNs are not detected automatically, re-scan the SCSI buses to discover new devices. -```bash +```shell rescan-scsi-bus.sh ``` ### DM Multipath -DM Multipath provides path redundancy by combining multiple paths to the same SAN LUN into a single block device. It should be configured on all hypervisor hosts that have multiple paths to the storage. +DM Multipath provides path redundancy by combining multiple paths to the same SAN LUN into a single block device. It should be configured on all hypervisor Hosts that have multiple paths to the storage. The exact Multipath configuration depends on the storage system. Refer to the storage vendor's documentation for the recommended configuration and device-specific settings. -#### Install the Multipath tools. +#### Install the Multipath Tools -##### RHEL/AlmaLinux +{{< tabpane text=true right=false >}} +{{% tab header="**OS**:" disabled=true /%}} -```bash +{{% tab header="RHEL / AlmaLinux"%}} +```shell dnf install -y device-mapper-multipath ``` - -##### Debian/Ubuntu - -```bash +{{% /tab %}} +{{% tab header="Debian / Ubuntu"%}} +```shell apt update apt install -y multipath-tools ``` - -##### SLES/openSUSE - -```bash +{{% /tab %}} +{{% tab header="SUSE / openSUSE"%}} +```shell zypper install -y multipath-tools ``` +{{% /tab %}} +{{< /tabpane >}} #### Configure DM Multipath Enable and start the `multipathd` service: -```bash +```shell systemctl enable --now multipathd ``` @@ -237,13 +244,13 @@ defaults { Restart `multipathd` to apply the configuration: -```bash +```shell systemctl restart multipathd ``` Verify the detected Multipath devices and their paths: -```bash +```shell multipath -ll ``` @@ -264,9 +271,9 @@ The resulting Multipath device is available under `/dev/mapper/`, for example `/ ## Front-end Configuration -The Front-end needs access to the shared SAN storage to perform LVM operations. It can either access the SAN directly or use one or more hypervisor hosts as SAN proxies. +The Front-end needs access to the shared SAN storage to perform LVM operations. It can either access the SAN directly or use one or more hypervisor Hosts as SAN proxies. -For direct access, the Front-end must be configured in the same way as the hypervisor hosts. For iSCSI storage, it must have connectivity to the iSCSI target and be configured as an iSCSI initiator. For Fibre Channel storage, it must have Fibre Channel connectivity to the SAN, and the required LUNs must be presented to the WWPNs of its Fibre Channel HBA ports. +For direct access, the Front-end must be configured in the same way as the hypervisor Hosts. For iSCSI storage, it must have connectivity to the iSCSI target and be configured as an iSCSI initiator. For Fibre Channel storage, it must have Fibre Channel connectivity to the SAN, and the required LUNs must be presented to the WWPNs of its Fibre Channel HBA ports. When DM Multipath is used, it must also be configured on the Front-end so that the SAN LUNs are available as Multipath devices. No additional OpenNebula configuration is required for direct SAN access. @@ -290,9 +297,9 @@ Example for illustration purposes: (iSCSI/FC + Multipath) ``` -If direct SAN connectivity cannot be provided to the Front-end, set the `BRIDGE_LIST` attribute in both the System and Image datastores to specify one or more hypervisor hosts that will act as SAN proxies. +If direct SAN connectivity cannot be provided to the Front-end, set the `BRIDGE_LIST` attribute in both the System and Image datastores to specify one or more hypervisor Hosts that will act as SAN proxies. -This configuration is particularly useful with Fibre Channel storage when the Front-end does not have an FC HBA or cannot be connected to the Fibre Channel fabric. The hosts specified in `BRIDGE_LIST` must have access to the SAN and be configured with the corresponding iSCSI or Fibre Channel connectivity and, when multiple paths are available, DM Multipath. +This configuration is particularly useful with Fibre Channel storage when the Front-end does not have an FC HBA or cannot be connected to the Fibre Channel fabric. The Hosts specified in `BRIDGE_LIST` must have access to the SAN and be configured with the corresponding iSCSI or Fibre Channel connectivity and, when multiple paths are available, DM Multipath. ## Troubleshooting @@ -320,7 +327,7 @@ lvmdevices --adddev /dev/mapper/mpatha pvs ``` -### Pool becomes full after live datastore migration +### Pool Becomes Full After Live Datastore Migration **Problem:** After a live datastore migration between two `fs_lvm_ssh` datastores with `LVM_THIN_ENABLE=yes` the disk now shows full: