1.1 Local LDAP users and groups authentication for SMB /CIFS protocol
1.2 Support for NVMe disks in High Availability Metro Cluster (Cluster over Ethernet)
1.3 Support for three ZFS pools in HA cluster
1.4 File-IO write-back and write-through modes for iSCSI volumes
1.5 Block-IO mode for Fibre Channel volumes
1.6 Support for Broadcom BCM573xx and Broadcom BCM574xx controllers (bnxt v.1.8.54)
1.7 Additional sysctl based system tuning option in TUI
1.8 Option for emergency-boot with no zpool import
1.9 Additional system log for optimization report for Mellanox Ethernet/Infiniband Adapters
1.10 Password modification for Adaptec MaxView and Broadcom MSM tools (System console -> Ctrl+Alt+r -> Storage controller tools)
2.1 Samba 4.7.3
2.2 Microsemi Adaptec SmartHBA and SmartRAID driver (smartpqi, v1.1.4-132)
2.3 Microsemi Adaptec Series SAS/SATA 6/12 Gb RAID driver (aacraid, v1.2.1-56008)
2.4 Microsemi Adaptec MaxView tool Version v2.06.23167
2.5 Broadcom 12Gb SAS HBA driver (mpt3sas, v27.00.00.00)
2.6 QLogic QL4xxx Series Everest FastLinQ Driver (qede, v188.8.131.52)
3.1 Low performance of sequential read via iSCSI protocol
3.2 Very long time of moving resources between cluster nodes in the case of a large number of disks
3.3 Problem with displaying zvols with thousands of snapshots
3.4 In some environments system hangs during reboot
3.5 Infiniband to Ethernet switching tool does not work for Mellanox ConnectX-4 Adapters
3.6 In some environments, Active Directory “Users/groups list” synchronization status shows false information
3.7 Problem with ACLs for secondary groups set for folders and files on NFS shares
3.8 NVMe SSD cannot be used as a boot medium
3.9 Cannot import pool after going back to factory defaults (console option) or after reinstalling system
3.10 Samba share names ending with $ are visible in Windows OS
3.11 VLANs are not activated on bond devices after reboot
4 Important notes for JovianDSS HA configuration
4.1 It is necessary to use sync always option for zvols and datasets in cluster
4.2 It is strongly recommended not to use more than eight ping nodes
4.3 It is strongly recommended to configure each IP address in separate subnetwork
4.4 It is necessary to run Scrub scanner after failover action triggered by power failure (dirty system close)
4.5 It is strongly recommended to use UPS unit for each cluster node
4.6 It is necessary to use static discovery in all iSCSI initiators
4.7 It is strongly not recommended to change any settings when both nodes do not have the same JovianDSS version, for example during software updating
4.8 It is necessary to use different Server names for cluster nodes
4.9 HA cluster does not work properly with Infiniband controllers
4.10 HA cluster does not work stable with ALB bonding mode
4.11 FC Target HA cluster does not support Persistant Reservation Synchronization and it cannot be used as a storage for Microsoft Hyper-V cluster. This problem with be solved in future releases.
5 Known issues
Write cache sync requests (sync) set to “always” for zvol is the safest option and is set by default. However, it can cause write performance decreases since all operations are written and flushed directly to the persistent storage. In case of using sync=always, it is strongly recommended using mirrored write log devices (very fast random writes devices).
Sync=standard or sync=disabled zvol options provide huge performance improvement but the most recent (up to 5 seconds) cached data can be lost in case of a sudden power failure. Use this option only in environments equipped with UPS.
For NFS shares the Synchronous data record is enabled by default. This option causes performance to be worse, but data can be safely written. In order to improve the NFS performance you can use Asynchronous data record but in such case, it is strongly recommended to use UPS.
It is strongly recommended to use Mozilla Firefox browser to navigate the system’s GUI. When using other browsers some slight problems with displaying content may occur.
Web browser’s cache
After updating from previous versions, some problems with WebGUI content and navigation may occur. To resolve this problems, please clear Web browser cache.
System as a guest in virtual environments
In case of installing the system as a Hyper-V guest please use the following settings:
- Number of virtual processors: 4
- Memory: Minimum 8GB
- Boot Disk: 20GB IDE Disk
- Add at least 6 virtual disk
In case of installing the system as a VMware ESXi guest please use the following settings:
- Guest OS: Other 2.6.x Linux ( 64bit )
- Number of Cores: 4
- Memory: Minimum 8GB
- Network Adapter: VMXNET 3
- SCSI Controller Type: Paravirtual or LSI Logic SAS
- Boot Disk : 20GB Thick Provision Eager Zeroed
- Add at least 6 virtual disk
- Edit Settings->Options->Advanced-General->Configuration-> Add row: disk.EnableUUID : TRUE
Reclaim deleted blocks on thin-provisioned LUNs in various systems
In case of deleting large amounts of data, reclaimed deleted blocks on thin-provisioned LUNs in Windows 2012 can significantly slow down system performance. If you predict frequent deletions of large amounts of data, we recommend turning off the automatic reclaim function in Windows 2012. This can be done by disabling the "file-delete notification" feature in the system registry. To do so, follow the steps below:
- start Registry Editor.
- locate the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
- double-click DisableDeleteNotification.
- in the Value data box, enter a value of 1, and then click OK.
In order to reclaim the free space in Windows 2012 please change the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\DisableDeleteNotification key value back to 0 and use "Optimize" tool located in Disc Management->[disk]->Properties->Tools. As the operation can generate a very high load in the system, it is recommended to perform it after-hours.
In case of VMware ESXi, the automatic reclaim feature is disabled by default. To reclaim the space of deleted blocks on thin-provisioned LUNs, please use vmkfstools. For details, please refer to the VMware Knowledge Base:
For VMware ESXi 5.0: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2014849
For VMware ESXi 5.5 and newer: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2057513
In case of using Windows 2008 there is no possibility to reclaim the space released by deleted data of thin-provisioned LUNs.
Deduplication issues and recommendations
Please be aware that deleting the zvol with deduplication enabled can generate a very high load in the system and lead to unstable behavior. It is strongly recommended to perform such operation only after-hours. To avoid this issue, please use (if possible) single zvol on zpools dedicated for deduplication and delete the zpool which includes the single zvol.
To determine the amount of System RAM required for deduplication, use this formula:
(Size of Zvol / Volume block size) * 320B / 0.75 / 0.25
320B - is the size of entry in DDT table
0.75 - Percentage of RAM reservation for ARC (75%)
0.25 - Percentage of DDT reservation in ARC (25%)
Example for 1TB data and 64KB Volume block size:
(1099511627776B / 65536B) * 320B / 0.75 / 0.25 = 28633115306.67B
28633115306.67B / 1024 / 1024 / 1024 = 26.67GB
so for every extra 1TB of storage, system needs extra 26.67GB RAM.
Example for 1TB data and 128KB Volume block size:
(1099511627776B / 131072B) * 320B / 0.75 / 0.25 = 14316557653.33B
14316557653.33B / 1024 / 1024 / 1024 = 13.33GB
so for every extra 1TB of storage, system needs extra 13.33GB RAM.
Example for 1TB data and 1MB Volume block size:
(1099511627776B / 1048576B) * 320B / 0.75 / 0.25 = 1789569706,66B
1789569706,66B / 1024 / 1024 / 1024 = 1.66GB
so for every extra 1TB of storage, system needs extra 1.66GB RAM.
IMPORTANT: The above calculations only apply to the worst case scenario, when data is completely unique and will not be deduplicated. For the deduplicable data, the need for RAM drastically decreases. If SSD based Read Cache is present, part of deduplication table will be moved to the SSD and deduplication will work with good performance using less RAM.
IMPORTANT: With SAN (iSCSI) it is CRITICAL to match User-File-System format block size with the zvol volume-block-size. A simple example is a Windows file system NTFS with default format block size 4k and zvol default volume-block-size is 128k. With defaults like this deduplication will mostly NOT match because files can be aligned in 32 (128/4) different positions on the pool. If the NTFS format is increased to 64k and the zvol default volume-block-size is 128k, deduplication match can fail only one time because a file can be aligned to 2 (128/64) different positions on the pool. Every next write will match already as both alignment options already exist on the pool. In order to achieve all files matching and efficient memory usage NTFS must use 64k format block size and the zvol volume-block-size must equal 64k. Another option is that the NTFS=32k and zvol=32k, but in this case the deduplication table will be twice as large. That is why the NTFS=64k and zvol=64k is the most efficient setting for deduplication.
IMPORTANT: With NAS (NFS, SMB/CIFs) deduplication matching works always due to the data blocks being aligned by ZFS natively.
IMPORTANT: De-duplication is working on the pool level in the pool-range. This is why zvol-Physical size cannot show de-duplication benefit. In order to prove that deduplication saved space run the scrub and notice the current physical data space on the pool reported by the scrub. Next copy of new data and run the scrub again. Now scrub will show new physical data space. Comparing the data size from storage client side with the data space growth from the scrub will give the deduplication advantage. The exact pool of the deduplication ratio can be found in LOGs in zfs.log.
Zvols configuration issues and recommendations
It is strongly recommended to set the client file system block size same as the zvol volume block size. For example, when using 64k zvol volume block size, the Windows Allocation unit size of NTFS should be set to 64k.
Target number limit
In case of more than 60 targets, GUI will not be displayed correctly. This issue will be fixed in the next releases.
Targets with the same name are not assigned correctly
Having two or more targets with the same name but belonging to various Zpools, will cause that all targets with the same name will be assigned to one Zpool during the import process.
Installation on disks containing LVM metadata
There is no possibility to install the system on disks containing LVM metadata. You will need to clear those disks before installation. To do so, use the “Remove ZFS data structures and disks partitions” function located in the Extended tools. To access this function, boot the system from a temporary media like a USB drive or DVD.
Import Zpool with broken write log
There is no option to import Zpool with a broken write log disk using the system’s functions. This is why it is STRONGLY recommended to use mirrored disks for write logs. In case it is necessary to import Zpool with a broken write log, please contact technical support.
Replacing disks in data groups for larger ones can cause your storage license capacity to be exceeded
In case of replacing damaged disks for larger ones, the size of the entire Zpool will increased. Make sure that the new size will not exceed your purchased storage license.
Periodically after some operations, the GUI needs to be manually refreshed
After performing some operations, e.g. resilvering, the GUI will show outdated information. In this case refresh the web page manually by pressing F5 on your keyboard. This issue will be fixed in next releases.
Replacing disks in data groups for smaller ones can cause an error and make the disk disappear from the list of available disks
Operation of replacing a disk in a data group for a smaller one will cause an error "zpool unknown error, exit code 255", and the disk will become unavailable. In order to reuse this disk, please use function "Remove ZFS data structures and disks partitions" located in the Extended tools on the Console screen.
It is strongly recommended to use 64KB or higher Volume block size
Smaller than 64KB block sizes used with deduplication or read cache will cause very high memory consumption.
RAM recommendations for Read Cache
To determine how much System RAM is required for Read Cache, use the following formula:
RAM needed = (Size of Read Cache - reserved size and labels) * bytes reserved by l2hdr structure / Volume block size
For 8KB Volume block size and 1TB Read Cache:
RAM needed = (1099511627776B - 4718592B) * 432B / 8192B = 57981809664B
57981809664B / 1024 / 1024 / 1024 = 54GB
1099511627776B - 1TB Read Cache
4718592B - reserved size and labels
432B - bytes reserved by l2hdr structure
8192B - Volume block size
For 64KB Volume block size and 1TB Read Cache:
RAM needed = (1099511627776B - 4718592B) * 432B / 65536B = 7247726208B
7247726208B / 1024 / 1024 /1024 = 6.75GB
For 128KB Volume block size and 1TB Read Cache:
RAM needed = (1099511627776B - 4718592B) * 432B / 131072B = 3623863104B
3623863104B / 1024 / 1024 /1024 = 3.37GB
Multiple GUI disk operations may result in an inaccurate available disks list
Multiple operations of adding and detaching disks from groups can cause that the next operation of detaching will fail, but the disk will be shown on a list of available disks. When trying to add this disk to one group it will fail with the following error "[zfslib-wrap-zpool-ZpoolCmdError-1] invalid vdev specification". In this case, detach this disk once again.
After removing disks from groups they may not be displayed on a list of available disks
Sometimes after removing disks from groups, Spare/Read Cache/Write Log disks are displayed on a list of unassigned disks, but they are not on a list of available disks. In this case, click the rescan button located in the adding group form.
Reusing disks from an exported and deleted Zpool
After deleting an exported Zpool, not all disks which were a part of a Zpool become immediately available. Before you can reuse disks, which were previously used as a Spare or a Read Cache, you must first clean them. Use “Remove ZFS data structures and disks partitions” function located in the “Extended tools”.
Negotiated speed of network interfaces may not display correctly
For some network interfaces, the negotiated speed field may display an incorrect value in GUI and Console. This issue will be fixed in next releases.
Limited possibility to display a large number of elements by the GUI
After creating multiple snapshots, clones or zvols some forms in GUI work very slow. If you need to create many snapshots, clones or zvols, it is strongly recommended to use CLI in order to perform operations on them.
Open-E VSS Hardware Provider system recommendations
It is strongly recommended to use Windows Server 2012. On the other Windows systems, Open-E VSS Hardware Provider Configuration works unstable.
Exceeded quota for dataset does not allow to remove files
Files located on datasets with exceeded quota cannot be removed. In this case, please resize quota and then remove unnecessary files.
Slow WebGUI with multiple datagroups
Zpool with more than 20 datagroups causes that some forms on WebGUI work very slow. If you need to create many datagroups, it is strongly recommended to use CLI API.
Slow WebGUI with multiple datasets
More than 25 datasets cause that WebGUI works slow.
For Open-E JovianDSS users, it is recommended to upgrade Zpools to the latest ZFS file system. Although the file system upgrade is absolutely safe for your data, and takes only few minutes, please be aware that this operation cannot be undone. In order to upgrade a single Zpool, please use "WebGUI -> Zpool options -> Upgrade file system" from Zpool's option menu.
Intel® Ethernet Controller XL710 Family
In case of using Open-E JovianDSS with Intel® Ethernet Controller XL710 Family, it is necessary to update firmware’s network controller to the version: f4.33.31377 a1.2 n4.42 e1932.
Motherboards with x2APIC technology
In case of using a motherboard with x2APIC technology enabled, it is necessary to disable x2APIC in BIOS. Otherwise, problems with CPU cores will occur.
NFS FSIDs and Zpool name
One of the factors that have been taken into account when NFS FSIDs are generated is Zpool name. It indicates that when Zpool name is changed, e.g. during export and import with different names, FSIDs for NFS Shares located on this Zpool will also be changed.
High Availability shared storage cluster does not work with Infiniband controllers
Due to technical reasons the High Availability shared storage cluster does not work properly when using the Infiniband controllers for VIP interface configuration. This limitation will be removed in the future releases.
Static routing functionality was removed
Starting from up10, there is no possibility to configure static routing in TUI. In case the static routing was configured in previous versions, this configuration will be removed from the system.
Disks with LVM data cannot be used with the created Zpool
Attempt to create Zpool with drives that contain LVM data will fail with the following error:
"cannot open 'lvm-pv-uuid-R25lTS-kcDc-eiAN-eAlf-ppgi-rAqu-Oxy1Si': no such device in /dev must be a full path or shorthand device name"
In this case, if you want use those disks, please use “Remove ZFS data structures and disks partitions” function located in “Extended tools”.
Unexpected long failover time, especially with HA-Cluster with two or more pools
Current failover mechanism procedure is moving pools in sequence. Since up27 release, up to 3 pools are supported in HA-cluster. If all pools are active on single node and failover needs to move all 3 pools, the failover may take longer than 60 seconds which is a default iSCSI timeout in Hyper-V Clusters. In some environments, under heavy load a problem with too long time of cluster resources switching may occur as well. If the switching time exceeds the iSCSI initiator timeout, it is strongly recommended to increase the timeout up to 600 seconds.
In case of using Windows, to increase iSCSI initiator timeout, please perform following steps:
1. Run regedit tool and find: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\...\Parameters\MaxRequestHoldTime registry key
2. Change value of the key from default 60 sec to 600 sec (decimal)
In case of using VMware, to increase iSCSI initiator timeout, please perform following steps:
1. Select the host in the vSphere Web Client navigator
2. Go to Settings in the Manage tab
3. Under System, select Advanced System Settings
4. Choose the Misc.APDTimeout attribute and click the Edit icon
5. Change value from default 140 to 600 sec.
In case of using XenServer, to increase iSCSI initiator timeout, please perform following steps:
A. For existing Storage Repositories (SR):
1. Edit /etc/iscsi/iscsid.conf
2. node.session.timeo.replacement_timeout = 120
3. Change value from default 120 to 600 sec.
4. Detach and reattach SRs. This will update the new iSCSI timeout settings for the existing SRs.
B. For new Storage Repositories (SR):
1. Edit /etc/iscsi/iscsid.conf
2. node.session.timeo.replacement_timeout = 120
3. Change value from default 120 to 600 sec.
4. Create the new SR. New and existing SRs will be updated with the new iSCSI timeout settings.
Activation may be lost after update
In some environments, after update to up11 system may require re-activation. This issue will be removed in the future releases.
Bonding ALB does not work in Hyper-V and VMware environments
In case of using JovianDSS as Hyper-V or VMware guest, bonding ALB is not supported. Please use another type of bonding.
Continuous writing in VMware guest can cause that deleting VMware snapshot can take long time
Using ODPS on zvol/dataset with VMware guest where many I/O operations are performed can cause that the process of deleting VMware snapshot can take long time. Please take this into consideration while you set up the scheduler for Off-site Data Protection Service task.
Enabling quota on dataset can cause file transfer interrupt
Enabling quota functionality on a dataset can cause file transfer interrupt. Before using it in production environment, please enable quota on dataset, or make sure that no file transfers are active.
Nodes connected to the same AD server must have unique Server names
If JovianDSS nodes are connected to the same AD server, they cannot have the same Server names.
Share can not be named the same as Zpool
In case of share with the same name as Pool connections problem will occur. Please use different names.
No persistent rules for network cards in virtual environment
Changing settings of virtual network cards (delete, changing MAC, etc.) can cause unstable system behaviour. Please do not change settings on production system. This issue will be fixed in next releases.
Downgrade to up17 or earlier is not possible
Starting from up18 bootable medium has always SW RAID structure. Attempt to come back to earlier version is impossible. If you need come back to earlier version, you must reinstall version again.
System cannot be installed on NVMe disks and on cciss based controllers
This issue will be fixed in next releases.
Interrupt the process of adding second disk to SW RAID (bootable medium) can cause run system from disk with uncompleted data
Performing operation like: reboot, shutdown, power off, etc. during mirroring data on new added disk can cause that system will be booted from new disk which has incomplete data. In this case, SW RAID function shows empty status and wrong number of RAID members. To resolve this issue, please plug off disk which has incomplete data, boot system, plug in disk and add it once again to SW RAID.
SAS-MPIO cannot be used with Cluster over Ethernet
It is strongly not recommended to use Cluster over Ethernet with SAS-MPIO functionality. Such a configuration can lead to a very unstable cluster behavior.
On- & Off-site Data Protection backward compatibility problem
In case of using On- & Off-site Data Protection functionality in up21 or earlier, it is strongly recommended to remove all backup tasks created by CLI API and re-create it using GUI.
Wrong state of storage devices in VMware after power cycle of both nodes in HA FC Target
In FC Target HA environment, power cycle of both nodes simultaneously may lead to a situation when VMware is not able to restore proper state of the storage devices. In vSphere GUI LUNs are displayed as Error, Unknown or Normal,Degraded. Moving affected pools to another node and back to its native node should bring LUNs back to normal. A number two option is to restart the Failover in Jovian’s GUI. Refresh vSphere’s Adapters and Devices tab afterwards.
Problem with maintenance in case of disk failure
In case of disk failure, please remove the damaged disks from the system, before starting administrative work to replace the disk. The order of actions is important.
Separated mode after update from JovianDSS up24 to JovianDSS up25
In HA cluster environment after updating of one node from JovianDSS up24 to JovianDSS up25 the other node can fall into separated mode and the mirror path might indicate disconnected status. In such a case go to Failover Settings and in the Failover status section select Stop Failover on both nodes. Once this operation is finished select Start Failover.
Different Write Cache default setting for zvols in early beta versions of Jovian DSS up25
In the early beta versions of JovianDSS up25 the default value of the Write Cache Log bias of zvols was set to “In Pool (Throughput)”. In the final release of Jovian up25 the Log bias is set to “Write log device (Latency)”.
Please note, that “In Pool (Throughput)” setting may cause a drop in performance in environments with a lot of random access workloads which is a common factor for a majority of production environments.
Target alias name is required while configuring HA FC Target in case of adding two or more ports to one FC group
If we want to have more then one port in each FC group (in HA FC configuration) it is necessary to type in Target alias name for every port. Otherwise an error message “Target alias is already used” can show up while setting up remote port mapping for FC targets in (pool name) -> Fibre Channel -> Targets and initiators assigned to this zpool. This issue will be resolved in the future release.
New default value for qlini_mode parameter for FC kernel module qla2xxx_scst
In order to configure FC Target, kernel module parameter qlini_mode should be set to “exclusive” (in some early beta versions of Jovian up25 qlini_mode was set up to “enabled”). In order to verify the value of this parameter open Jovian TUI and use CTRL+ALT+W key combination to launch Hardware configuration. Press "Yes" to acknowledge the initial warning message. Type in the password. Choose option: Kernel module parameters. Select qla2xxx_scst QLogic Fibre Channel HBA Driver and make sure the value of this parameter is set to “exclusive”.
Please note that in order to change this parameter Failover must be stopped first.
Very low performance of FIO/WT in case of mixed FIO/WT and FIO/WB zvol configurations over Fiber Channel
In case of the mixed FIO/WT and FIO/WB zvol configurations over FC one can observe significantly decreased performance on FIO/WT.
In certain situations system page cache is not able to flush File I/O errors by itself and cache flushing has to be performed manually
Under certain conditions (like overfilling zvol and then expanding its size) some File I/O errors may be held by the system page cache and it requires manual flushing (in GUI use Storage -> Rescan).
Updating nodes of the Jovian cluster from up24 and earlier versions changes FC ports to target mode resulting in losing connection to a storage connected via FC initiator
There is a significant difference in FC configurations in up24 and earlier versions. Those versions allowed the FC ports to be configured in initiator mode only, while later versions allow both target and initiator mode with target as default, so in case of using storage connected via FC initiator, FC port(s) must be manually corrected in GUI of the updated node.
Updating Metro Cluster node with NVMe disks as read cache from JovianDSS up26 or earlier can cause the system to lose access to the NVMe disks
The process of updating of Metro Cluster node from JovianDSS up26 or earlier is changing NVME disk IDs. In consequence moving pool back to updated node is possible but the read cache is gone (ID mismatch). In order to bring read cache back to the pool we recommend to use console tools in the following way: press Ctrl+Alt+x -> “Remove ZFS data structures and disks partitions”, locate and select the missing NVMe disk and press OK to remove all ZFS metadata on the disk. After this operation click Rescan button in GUI -> Storage. The missing NVMe disk should now appear in Unassigned disks at the bottom of the page which allows to select that disk in pool’s Disk group’s tab. Open Disk group tab of the pool, press the Add group button and select Add read cache. The missing disk should now be available to select it as a read cache.
LDAP synchronization fails and cannot be resumed, in case of power cycle of source node while synchronization is in progress
A temporary solution is to restart the destination node and if synchronization is not automatically resumed, use Reset button in GUI -> User Management -> Lightweight Directory Access Protocol (LDAP) function. This problem will be solved in the future releases.
Synchronization of a large LDAP database can last for a long time (e.g. 10h for 380K users) and a can be associated with high system load
This problem will be solved in future releases.
Cluster node is not joining after update if restart operation was performed while LDAP synchronisation was in progress
Updating of cluster node while LDAP synchronisation was in progress may corrupt LDAP database which causes the node joining process to fail. It’s recommended to wait with updating of nodes until the LDAP database is fully synchronized (check the status of synchronization in GUI -> User Management -> Lightweight Directory Access Protocol (LDAP) function).
Long time of a failover procedure in case of Xen client with iSCSI MPIO configuration
In a scenario where Xen client is an iSCSI initiator in MPIO configuration, the power-off of one node starts the failover procedure that takes a very long time. Pool is finally moved successfully but there are many errors showing up in dmesg in meantime. In case of such an environment we recommend to add the following entry in the Devices section of the configuration file: /etc/multipath.conf: