Reply to Message

View discussion in a popup

Replying to:
srwsol
Hot Shot
Hot Shot

I checked into some more things and found that i have the April patch applied, not the May patch, although the description of the May patch indicates that it fixed just one bug which had nothing to do with my issue; so instead I went ahead and and upgraded the LSI driver to the current version, but it had no effect.  I still got the lost access message when I started up a couple of the VMs, and the RAID array still appears degraded to the ESXi esxcfg-scsidevs -l command even though the RAID Bios says it's fine.

I'm beginning to suspect that there is some incompatibility here.  I wonder if they tried RAID 5 with this controller, and if that's the issue.  With this motherboard you have to buy an extra key dongle and attach it to the motherboard to enable RAID 5 on the LSI controller and I wonder if in their testing they didn't do that.  That's also true of the other Intel motherboard in the S2600CW series that comes with the attached LSI controller (the difference between the two boards is that my model also comes with 10gb NICs and the LSI controller where the other model with the LSI controller just has 1gb NICs).

I'm trying to think of what happens at VM startup and shutdown that would cause this issue which doesn't happen at other times, as I don't get the message when I'm doing lots of I/Os to the controller from running VMs.  I've transferred gigabytes of data between VMs, both of which are hitting the same datastore, and I don't get the message, which leads me to believe it's note the rate of I/O's or even the rate of writes that's doing this.  The only thing I can think of is that I know VM startup and shutdown involves locking files that ESXi uses to know that a VM is active, and I'm wondering if ESXi does something different I/O wise when it's creating, manipulating, or deleting these lock files, such as trying to quiesce all I/O's to the datastore while this process is happening.   From what I can tell my controller doesn't do write caching because there is no battery option, but I didn't think that would be an issue with SSD drives.  Perhaps it is an issue if ESXi is doing something strange at VM startup and shutdown that holds up I/Os to the controller for a short period of time.  This is just my guess however.

There is another RAID option on this motherboard, as I could use the software RAID capability present on all the S2600CW motherboards.  That would require re-cabling and probably a reformat of the disks, but if I can't get this figured out I may have to do it, as the configuration really isn't stable as is.  It also means I will have wasted my money in buying this version of the motherboard with the LSI controller.  <sigh>

If you can think of anything else I'm certainly all ears, and I do thank you for your assistance.

Here's the current info:

[root@intelserver:~] esxcfg-scsidevs -l

naa.6001e67ca647e0001cd1cdb8275eb90e

   Device Type: Direct-Access

   Size: 4878040 MB

   Display Name: Intel Serial Attached SCSI Disk (naa.6001e67ca647e0001cd1cdb8275eb90e)

   Multipath Plugin: NMP

   Console Device: /vmfs/devices/disks/naa.6001e67ca647e0001cd1cdb8275eb90e

   Devfs Path: /vmfs/devices/disks/naa.6001e67ca647e0001cd1cdb8275eb90e

   Vendor: Intel     Model: RS3YC             Revis: 4.26

   SCSI Level: 5  Is Pseudo: false Status: degraded

   Is RDM Capable: true  Is Removable: false

   Is Local: false Is SSD: true

   Other Names:

      vml.02000000006001e67ca647e0001cd1cdb8275eb90e525333594320

   VAAI Status: unsupported

[root@intelserver:~] vmkload_mod -s lsi_mr3

vmkload_mod module information

input file: /usr/lib/vmware/vmkmod/lsi_mr3

Version: 6.606.10.00-1OEM.550.0.0.1391871

License: GPLv2

Required name-spaces:

  com.vmware.vmkapi#v2_2_0_0

Parameters:

  lb_pending_cmds: int

    Change raid-1 load balancing outstanding threshold.Valid Values are 1-128. Default: 4

  mfiDumpFailedCmd: int

    Hex dump of failed command in driver log

  max_sectors: int

    Maximum number of sectors per IO command

Reply
0 Kudos