What does this mean?

[abaum]

All,

I am getting this in my vmkernel log file:

Jul 16 03:32:17 isavm01 vmkernel: 63:15:05:27.445 cpu0:1044)WARNING: SCSI: 1736: Unexpected status returned: bad000a I/O error

Jul 16 03:32:17 isavm01 vmkernel: 63:15:05:27.445 cpu2:1044)WARNING: SCSI: 1736: Unexpected status returned: bad000a I/O error

Jul 16 03:37:17 isavm01 vmkernel: 63:15:10:27.444 cpu5:1044)WARNING: SCSI: 1736: Unexpected status returned: bad000a I/O error

Jul 16 03:37:17 isavm01 vmkernel: 63:15:10:27.445 cpu5:1044)WARNING: SCSI: 1736: Unexpected status returned: bad000a I/O error

What does this mean? Is this a SCSI reset? It occurs every 5 minutes.

adam

[Zathras]

Hi,

I would like to know as well...

Our ESX farm seems to be running fine. But the vmkernel log is filled with the same warnings:

Jul 17 16:14:35 vmkernel: 10:00:00:25.859 cpu7:1044)WARNING: SCSI: 1736: Unexpected status returned: bad000a I/O error

Jul 17 16:19:35 vmkernel: 10:00:05:25.860 cpu3:1044)WARNING: SCSI: 1736: Unexpected status returned: bad000a I/O error

Jul 17 16:24:35 vmkernel: 10:00:10:25.861 cpu0:1044)WARNING: SCSI: 1736: Unexpected status returned: bad000a I/O error

Jul 17 16:29:35 vmkernel: 10:00:15:25.861 cpu0:1044)WARNING: SCSI: 1736: Unexpected status returned: bad000a I/O error

Jul 17 16:34:35 vmkernel: 10:00:20:25.861 cpu3:1044)WARNING: SCSI: 1736: Unexpected status returned: bad000a I/O error

We work with dell servers (so no HP insight stuff), and use iSCSI to connect to a netapp san.

I hope someone can illuminate abaum and myself

[grasshopper]

Abaum, unfortunately the 'bad000a' simply tranlates to a generic 'I/O error' as you have gathered from the original log message.

What's interesting is that it happens every five minutes as if there is a scheduled polling interval.

Zathras, did you configure your LUN type on the NetApp as 'vmware'? What Dell hardware are you using? Finally, which NIC is your iSCSI connected to on the server (i.e. onboard NIC 1)?

[Zathras]

Hello grasshopper,

Yups the LUN types on the Netapp are configured as vmware.

The dell hardware are all dell poweredge 6850's.

The two onboard nics are connected to the iSCSI network. The rest of the networking (vmotion, console and vmware network) are connected via 2 intel quad cards.

My Warning messages happen every 5 minutes too. Another intresting thing is that it happen on only 2 of the 4 ESX machines. They are all connected to the same LUNS's

Thanks for the reply

Message was edited by:

Zathras

[Zathras]

While I was increasing the console memory reservation i had to reboot.

After this reboot the warnings where gone. Upon reading the vmkernel log it seems that esx found out a Destoyed lun no longer existed. \*(Which the storage configuration in VI-Client already knew before the reboot)*

This would explain why only 2 of the 4 ESX server's had these warnings coze only those two knew the lun existed.

so it seems that if you have the same warning messages every 5 minutes and you had removed a lun somewhere during the uptime of the server a reboot might clear you of these warnings...

I bet there is a proper way to do this

[Andy_Banta · Accepted solution]

The message is the result of ESX trying to find some lost storage (that is'nt there any more, in this case.) ESX checks this every five minutes.

If there's any reference to the LUN (from a VMFS or other use of the storage), the path can't be removed and will continue to be checked. If there's no reference to te storage, a rescan removes the path and thereforegets rid of this message.

[mpverr]

While this thread is old, i happen to come across it as i too was just getting tons of those errors. I have found that with the latest build of ESX 3.01 42829 (44 patches) that if you unpresent a VMFS-2 lun and rescan, you start getting those errors. The only solution i found was to reboot the host. HOpe this helps someone else out in the future...

[NYSDHCR]

I too have received serveral of these errosr. I found out these errors occur when the luns where the .vmdks are not on the correct path (partner path). After changing them to the corrrect path and perform a 'esxcfg-rescan-vmhba0' (or whatever your hba number is), the errors cease.

Just my 2 cents...