VMware Cloud Community
ArsonSmith
Contributor
Contributor

ESX 3.5 Patch manager upgrade lost iSCSI targets

Using Update Manager I had recently updated an ESX 3.5 server to the latest patch level.

I lost all my iSCSI targets, My iSCSI device (Dell MD3000i) no longer sees the initiator from this patched host.

I've checked the firewall, removed and reconfigured the iSCSI initiator and still don't see it showing up. What else do I need to look at to troubleshoot this further?

Thanks in advance

EDIT:

This update included these two patches:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100832...

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101012...

Reply
0 Kudos
8 Replies
ArsonSmith
Contributor
Contributor

Seeing this in /var/log/messages

Jun 5 10:18:22 srv48 vmkiscsid[3642]: Connected to Discovery Address x.x.x.28

Jun 5 10:18:22 srv48 vmkiscsid[3642]: discovery login to x.x.x.28 rejected: initiator error (02/00), non-retryable, giving up

Jun 5 10:18:22 srv48 vmkiscsid[3643]: Connected to Discovery Address x.x.x.29

Jun 5 10:18:22 srv48 vmkiscsid[3643]: discovery login to x.x.x.29 rejected: initiator error (02/00), non-retryable, giving up

Jun 5 10:18:22 srv48 vmkiscsid[3644]: Connected to Discovery Address x.x.x.30

Jun 5 10:18:22 srv48 vmkiscsid[3644]: discovery login to x.x.x.30 rejected: initiator error (02/00), non-retryable, giving up

Jun 5 10:18:23 srv48 vmkiscsid[3645]: Connected to Discovery Address x.x.x.31

Jun 5 10:18:23 srv48 vmkiscsid[3645]: discovery login to x.x.x.31 rejected: initiator error (02/00), non-retryable, giving up

Reply
0 Kudos
AndreTheGiant
Immortal
Immortal

Have you tried (from your ESX box) to do a ping and a vmkping to your target IPs?

Are you using a CHAP password?

On MD3000i you see the host connected?

Andre

**if you found this or any other answer useful please consider allocating points for helpful or correct answers

Andre | http://about.me/amauro | http://vinfrastructure.it/ | @Andrea_Mauro
Reply
0 Kudos
ArsonSmith
Contributor
Contributor

I think I had an invalid initiator name. I finally blew away the config includeing removing /etc/initiatorname.vmkiscsi and added the GenerateName=yes option there.

A reboot and the scan showed up all the iscsi target luns.

For some reason though I am not seeing the VMFS on them, and if I go to add storage I see only one of the detected targets. I'm still looking into this and will reply if i figure out what is up with that.

Reply
0 Kudos
ArsonSmith
Contributor
Contributor

hmm, getting this in the logs

Jun 5 11:50:11 srv48 vmkernel: 0:00:09:37.233 cpu1:1048)LVM: 5579: Device vml.02000000006001ec9000f2ed1a00000f5a4a20110a4d4433303030:1 detected to be a snapshot:

Jun 5 11:50:11 srv48 vmkernel: 0:00:09:37.233 cpu1:1048)LVM: 5586: queried disk ID: <type 2, len 22, lun 0, devType 0, scsi 6, h(id) 43829692620502042>

Jun 5 11:50:11 srv48 vmkernel: 0:00:09:37.233 cpu1:1048)LVM: 5593: on-disk disk ID: <type 2, len 22, lun 0, devType 0, scsi 6, h(id) 10411692989888280535>

Jun 5 11:50:11 srv48 vmkernel: 0:00:09:37.233 cpu1:1048)ALERT: LVM: 4482: vml.02000000006001ec9000f2ed1a00000f5a4a20110a4d4433303030:1 may be snapshot: disabling access. See resignaturing section in SAN config guide.

Jun 5 11:50:11 srvews48a vmkernel: 0:00:09:37.438 cpu1:1048)WARNING: Vol3: 611: Couldn't read volume header from 4a207776-52a2de33-b839-001ec9f280af: Address temporarily unmapped

Although these luns are being used on other ESX hosts in this cluster.

Reply
0 Kudos
admin
Immortal
Immortal

From what you have mentioned, I would recommend that you open a support request with the logs collected using vm-support.

Reply
0 Kudos
ArsonSmith
Contributor
Contributor

I like to make that the very last call, or if there is production stuff at risk. As this cluster is our Dev/QA cluster and the newest host and iSCSI stuff is all brand new installs I am working my way through it.

It also helps me to learn by breaking Smiley Happy

So far I have narrowed it down to being a problem with me trying to change the initiator name. Something is holding on to the original one until I reboot the host. Now I'm still not sure why the LUNs didn't come back right, though I have wiped the config and started over. So far I have fixed 2 of the 3 hosts in the cluster and hope to be able to fix the 3rd next week when I get back.

I tried to go through the procedure outlined here https://support.misdivision.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=379&nav=0%2C42... but it didn't work.

If it comes up again then I will probably open a ticket, otherwise I'm sure it's something I screwed up.

Reply
0 Kudos
admin
Immortal
Immortal

OK then, are these same luns visible to all the other hosts on the cluster? Can you see the vmfs volumes on these luns via the other ESX hosts in the cluster? Are all the ESX hosts at the same patch level (i.e. running ESX35U4)?

If the answer is yes to all the above questions, then resignaturing your the volume is not a good idea as then those hosts will see a mismatch.

Reply
0 Kudos
ArsonSmith
Contributor
Contributor

The were visible, but as I said I messed up the config which made them dissapear after a reboot. They are currently not hte same patch level. I am waiting ona fiber channel connection to the newest server so I can get the shared storage and vmotion hosts to it so I can patch the other two hosts.

Reply
0 Kudos