Can you see if there are any errors reported in ESX's
/var/log/vmkernel?.
/var/log/vmkernel?.
Yep. And those have been provided to Vmware. When using the Software iSCSI initiator, the problem happens much more rapidly than using an HBA. This makes a lot of sense, as the HBA is interrupt driven, while the Software is system-load dependent. On a highly utilized Host, the Software iSCSI initiator is NOT going to be able to service the data as quickly as an HBA will.
So.. back to your question.. We see buffer overruns for reserve/release activity, and several iSCSI timeouts. The timeouts appear to indicate a networking issue such as dropped packets (none showd on either end, or on either port!!!), but we can account for every packet back and forth between the client and the target and there ARE NO DROPPED PACKETS!
We've even removed the switch from the mix and gone to crossover cables between the host and the target. Same problem.
Also, make sure network connectivity is healthy and
there are no intermittent failures. Path to storage
being down for extended amount of time (for RH it is
typically 1min, I guess) can take the FS read-only.
Which target are you using?.
there are no intermittent failures. Path to storage
being down for extended amount of time (for RH it is
typically 1min, I guess) can take the FS read-only.
Which target are you using?.
IETD, specifically patched w/ Reserve/Release and several other patches that have been submitted back to the project as a result of 9 months of testing w/ Vmware.
Is this a shared network or dedicated to iSCSI only?.
Dedicated to iSCSI only.
Are any VLAN configuration in the picture?.
No.
Any
traffic shaping or bandwidth allocation restrictions
placed on the physical switch that is connected to
iSCSI?.
traffic shaping or bandwidth allocation restrictions
placed on the physical switch that is connected to
iSCSI?.
On a crossover cable?
No.
