Hello there, Would, if possible, very much like to know current status of this request. The VRTX Blade solution, being specifically tailored for the SMB market, needs support for an Enterprise Linux Virtualization solution since the only Virutalization technology currently supported is ESXi and Hyper-V, allowing for Microsoft and Vmware to get a foot hold of smaller companies and locking them in with those vendors. Red Hat will greatly increase RHEV's marketability by supporting said controller asap and allowing Dell to sell a specific, low cost yet enterprise ready blade solution to SMBs along with RHEV. Thanks,
Hello, RHEV inherits the drivers from the underlying RHEL operating system version. The drivers for the VRTX Blade have just recently been provided upstream. http://marc.info/?l=linux-scsi&m=139444512512929&w=2 - http://marc.info/?l=linux-scsi&m=139444510812896&w=2 - http://marc.info/?l=linux-scsi&m=139444510112891&w=2 - http://marc.info/?l=linux-scsi&m=139444509412890&w=2 - http://marc.info/?l=linux-scsi&m=139444507912875&w=2 We are looking to include these in a future version of RHEL, most probably 6.6 and 7.1 and thus RHEV later this year. If you are a customer and have specific requirements please feel free to call into our Support team at 888-GO-REDHAT (888-467-3342). Thanks and have a nice day.
Hello Colin, Thanks for your feedback. I am aware the driver was recently provided upstream. I was who initiated the request directly on the mailing list ;) http://marc.info/?l=linux-scsi&m=139385845220534&w=2 http://marc.info/?l=linux-scsi&m=139388050329096&w=2 I am a Red Hat premier partner, representing a Red Hat customer via whom I created the RFE originating in this ticket. I am asking about the timeframe, because client owns both the VRTX and RHEV and wants to use both to its fullest extent. Can I possibly ask if there is any specific planned date for the release of RHEL 6.6 (which I would assume will be released before RHEL 7.1), also can you be more specific by "later this year" in regards to inclusion in RHEV? Thanks,
We are tracking this driver update in RHEL here: https://bugzilla.redhat.com/show_bug.cgi?id=1059073 I can say that RHEL 6.6 is the next minor version of RHEL and RHEV 3.5 is the next minor version of RHEV and both are looking to be released later this year. If you are seaking more specific dates you may be able to contact your partner manager or TAM if you have one. Thank you, --Colin Devine
This bug is Testonly bug in RHEVH, kernel bug 1059073 was verified on rhel 6.6.0 yet. In QE lab, we did not have Dell PowerEdge VRTX environment. We only have 1 Dell M620 with MegaRAID SAS 2008. # lspci -nn |grep MegaRAID 02:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 2008 [Falcon] [1000:0073] (rev 03) # uname -r 2.6.32-504.3.3.el6.x86_64 # lsmod|grep megaraid_sas megaraid_sas 96205 2 # modinfo megaraid_sas filename: /lib/modules/2.6.32-504.3.3.el6.x86_64/kernel/drivers/scsi/megaraid/megaraid_sas.ko description: LSI MegaRAID SAS Driver author: megaraidlinux version: 06.803.01.00-rh1 license: GPL srcversion: 354E9EA99B1EE236391B0AF alias: pci:v00001000d0000005Fsv*sd*bc*sc*i* alias: pci:v00001000d0000005Dsv*sd*bc*sc*i* alias: pci:v00001000d0000002Fsv*sd*bc*sc*i* alias: pci:v00001000d0000005Bsv*sd*bc*sc*i* alias: pci:v00001028d00000015sv*sd*bc*sc*i* alias: pci:v00001000d00000413sv*sd*bc*sc*i* alias: pci:v00001000d00000071sv*sd*bc*sc*i* alias: pci:v00001000d00000073sv*sd*bc*sc*i* alias: pci:v00001000d00000079sv*sd*bc*sc*i* alias: pci:v00001000d00000078sv*sd*bc*sc*i* alias: pci:v00001000d0000007Csv*sd*bc*sc*i* alias: pci:v00001000d00000060sv*sd*bc*sc*i* alias: pci:v00001000d00000411sv*sd*bc*sc*i* depends: vermagic: 2.6.32-504.3.3.el6.x86_64 SMP mod_unload modversions parm: max_sectors:Maximum number of sectors per IO command (int) parm: msix_disable:Disable MSI-X interrupt handling. Default: 0 (int) parm: msix_vectors:MSI-X max vector count. Default: Set by FW (int) parm: allow_vf_ioctls:Allow ioctls in SR-IOV VF mode. Default: 0 (int) parm: throttlequeuedepth:Adapter queue depth when throttled due to I/O timeout. Default: 16 (int) parm: resetwaittime:Wait time in seconds after I/O timeout before resetting adapter. Default: 180 (int) # cat /etc/system-release Red Hat Enterprise Virtualization Hypervisor release 6.6 (20141218.0.el6ev) Summarized: 1. above verification steps on RHEVH 6.6 for 3.5, the drivers for Dell Shared PERC8 RAID Controller is already provided yet. 2. for comment 5, megaraid driver will be provided on kernel on rhel 7.1, see bug 1088523. so RHEVH 7.0 for 3.5 can not provided this as well.
Fabian, see comment 13, then 1. This bug is fixed in RHEVH 6.6 for 3.5(20141218.0.el6ev). 2. This bug need to clone to RHEV 3.6, because megaraid driver will be provided on kernel on rhel 7.1, see bug 1088523. so RHEVH 7.0 for 3.5 can not provided this as well. 3. This bug need to add document to guide we only support drivers for Dell Shared PERC8 RAID Controller with RHEVH 6.6 for 3.5 Thanks
After comment 14 confirmation, I will change this bug status to 'VERIFIED'.Thanks.
(In reply to Ying Cui from comment #14) > Fabian, see comment 13, then > 1. This bug is fixed in RHEVH 6.6 for 3.5(20141218.0.el6ev). Nice. > 2. This bug need to clone to RHEV 3.6, because megaraid driver will be > provided on kernel on rhel 7.1, see bug 1088523. so RHEVH 7.0 for 3.5 can > not provided this as well. > > 3. This bug need to add document to guide we only support drivers for Dell > Shared PERC8 RAID Controller with RHEVH 6.6 for 3.5 I'll research if we can get a z-stream of bug 1088523, then we'll also have the driver in 7.0. If not, then we'll get the drive in RHEV-H 3.5, as soon as we move to RHEL 7.1. Let's keep this bug ON_QA until I know if we can backport the change, and then we'll update the documentation accordingly.
For RHEL 7, it was decided that we will wait for RHEL 7.1 and not request a backport of this change to 7.0.z.
(In reply to Fabian Deutsch from comment #17) > For RHEL 7, it was decided that we will wait for RHEL 7.1 and not request a > backport of this change to 7.0.z. is that means this bug will be delayed on rhevh 7.1 for rhev 3.5.z? If that, please change this bug status to MODIFIED instead of ON_QA. Thanks
We can verify the bug against RHEV-H 6 Anand, can we somehow document for GSS that the driver in the RHEV-H 7 stream, will land with RHEV-H 7.1?
To better trace this issue on RHEVH 7.1, so I have cloned bug 1186582 in rhev 3.6.0
According to comment 13 and comment 19, then VERIFIED this bug on rhevh 6.6 for 3.5.0 For RHEVH 7.1, let's trace this on bug 1186582 in rhev 3.6.0 then.
I have a VRTX system available for testing if necessary. I have been running RHEV Hypervisor - 6.6 - 20150114.0.el6ev on two M520 Blades and wanted to report that I can see shared storage via the Shared PERC 8 controller on the blades. I have been getting however various multipath errors such as: Jan 28 10:17:24 rhev-s1 kernel: device-mapper: table: 253:6: multipath: error getting device Jan 28 10:17:24 rhev-s1 multipathd: dm-6: remove map (uevent) Jan 28 10:17:24 rhev-s1 multipathd: dm-6: devmap not registered, can't remove Jan 28 10:17:25 rhev-s1 multipathd: dm-6: remove map (uevent) Jan 28 10:17:25 rhev-s1 multipathd: dm-6: devmap not registered, can't remove In any case if anyone needs me to perform any test. I will be happy to do so, that is of course if I can get round other problems I am having with VLAN tagging on the rhevm interface. ----------- # lspci -nn |grep MegaRAID 08:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 2208 IOV [Thunderbolt] [1000:002f] (rev 05) # uname -r 2.6.32-504.3.3.el6.x86_64 # modinfo megaraid_sas filename: /lib/modules/2.6.32-504.3.3.el6.x86_64/kernel/drivers/scsi/megaraid/megaraid_sas.ko description: LSI MegaRAID SAS Driver author: megaraidlinux version: 06.803.01.00-rh1 license: GPL srcversion: 354E9EA99B1EE236391B0AF alias: pci:v00001000d0000005Fsv*sd*bc*sc*i* alias: pci:v00001000d0000005Dsv*sd*bc*sc*i* alias: pci:v00001000d0000002Fsv*sd*bc*sc*i* alias: pci:v00001000d0000005Bsv*sd*bc*sc*i* alias: pci:v00001028d00000015sv*sd*bc*sc*i* alias: pci:v00001000d00000413sv*sd*bc*sc*i* alias: pci:v00001000d00000071sv*sd*bc*sc*i* alias: pci:v00001000d00000073sv*sd*bc*sc*i* alias: pci:v00001000d00000079sv*sd*bc*sc*i* alias: pci:v00001000d00000078sv*sd*bc*sc*i* alias: pci:v00001000d0000007Csv*sd*bc*sc*i* alias: pci:v00001000d00000060sv*sd*bc*sc*i* alias: pci:v00001000d00000411sv*sd*bc*sc*i* depends: vermagic: 2.6.32-504.3.3.el6.x86_64 SMP mod_unload modversions parm: max_sectors:Maximum number of sectors per IO command (int) parm: msix_disable:Disable MSI-X interrupt handling. Default: 0 (int) parm: msix_vectors:MSI-X max vector count. Default: Set by FW (int) parm: allow_vf_ioctls:Allow ioctls in SR-IOV VF mode. Default: 0 (int) parm: throttlequeuedepth:Adapter queue depth when throttled due to I/O timeout. Default: 16 (int) parm: resetwaittime:Wait time in seconds after I/O timeout before resetting adapter. Default: 180 (int)
Fabian, could you check this bug comment 22, and bug 1182048? not sure how impact rhevh multipath function. or only error messages display. Bug 1182048 - [3.5-7.0]Error messages(device-mapper: multipath: error getting device) display while rhevh 7.0 login
(In reply to Istvan Cebrian from comment #22) > I have a VRTX system available for testing if necessary. I have been running > RHEV Hypervisor - 6.6 - 20150114.0.el6ev on two M520 Blades and wanted to > report that I can see shared storage via the Shared PERC 8 controller on the > blades. > > I have been getting however various multipath errors such as: > > Jan 28 10:17:24 rhev-s1 kernel: device-mapper: table: 253:6: multipath: > error getting device > Jan 28 10:17:24 rhev-s1 multipathd: dm-6: remove map (uevent) > Jan 28 10:17:24 rhev-s1 multipathd: dm-6: devmap not registered, can't remove > Jan 28 10:17:25 rhev-s1 multipathd: dm-6: remove map (uevent) > Jan 28 10:17:25 rhev-s1 multipathd: dm-6: devmap not registered, can't remove Istvan, you are probably seeing bug 1173290. This is caused by an different-to-normal multipath config. If it's nothing else, than this error has no functional impact on operation.
> Istvan, you are probably seeing bug 1173290. > This is caused by an different-to-normal multipath config. > > If it's nothing else, than this error has no functional impact on operation. Ok thanks. Lately however the error has not been showing up. Also in the meantime I am currently running RHEV 3.5 Beta on the VRTX, already have shared storage and VM's running and everything seems to be very smooth and without any problems.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-0201.html