oVirt 3.5: Issue with FC Storage on EL7 host
Just a heads up I ran into an issue with adding a Fibre Channel storage domain on a CentOS 7 host. vdsm-4.16.7-1.gitdb83943.el7.x86_64 from oVirt 3.5 Release repo This version of vdsm still has the code in /usr/share/vdsm/storage/hba.py that performs issue_lip to rescan fibre channel HBAs. In my setup, the HBA paths are still recovering when 'dmsetup status' is run resulting in paths being offline and the LUNs being made unavailable to oVirt (UI shows exclamation mark). Issue discussed here: https://bugzilla.redhat.com/show_bug.cgi?id=1159839 Quick workaround that worked for me: (1) Comment line 107 in /usr/share/vdsm/storage/multipath.py i.e.: #supervdsm.getProxy().hbaRescan() (2) Restart supervdsmd systemctl restart supervdsmd.service Regards Paul
On Thu, Nov 06, 2014 at 09:08:36PM +0800, The Austrian wrote:
Just a heads up I ran into an issue with adding a Fibre Channel storage domain on a CentOS 7 host.
vdsm-4.16.7-1.gitdb83943.el7.x86_64 from oVirt 3.5 Release repo
This version of vdsm still has the code in /usr/share/vdsm/storage/hba.py that performs issue_lip to rescan fibre channel HBAs. In my setup, the HBA paths are still recovering when 'dmsetup status' is run resulting in paths being offline and the LUNs being made unavailable to oVirt (UI shows exclamation mark).
Issue discussed here: https://bugzilla.redhat.com/show_bug.cgi?id=1159839
Quick workaround that worked for me:
(1) Comment line 107 in /usr/share/vdsm/storage/multipath.py i.e.:
#supervdsm.getProxy().hbaRescan()
(2) Restart supervdsmd
systemctl restart supervdsmd.service
Thanks for providing wider audience for this issue. An ad-hoc fix for ovirt-3.5.1 has been merged in http://gerrit.ovirt.org/#/c/34215/
participants (2)
-
Dan Kenigsberg -
The Austrian