I realized last night that in my efforts to get ESXi up and running, I had installed the original release of ESXi 7.0. Since I had taken Friday off work to take care of a few things that needed to be done during the weekdays I decided to upgrade ESXi to Update 2. It also allowed me to test my theory from my previous post. <\/p>\n\n\n\n
The update worked as planned (and boy-oh-boy are updates slow!) but was successful. As I expected the iSCSI share did not show up in ESXi. Let’s check the NAS and see if the targets are still there and if the ESXi server is connected. Yep, ESXi is shown as a host in DSM. <\/p>\n\n\n\n
Okay, ssh into the ESXi box. Can I ping the NAS? Yes, working fine.<\/p>\n\n\n\n
Log into the ESXi console (again, I’m not using vSphere). The software iSCSI sees the host and the target. But, no iSCSI devices are showing up under storage devices and obviously the datastores are not present.<\/p>\n\n\n\n
Let’s try my theory from the last post. Try Time for some deep thinking. No panic this time as I know that the VMs are still in the iSCSI LUNs and I just have to get them mounted. And I have good backups!<\/p>\n\n\n\n Some more Googling and the first result from Reddit (vSphere 7.0 U2 iSCSI not working with older HP Lefthand SAN<\/a>) seems to have the answer. It seems that the issue is around the IQN and how ESXi is handling this. I deleted the ESXi host<\/strong> on the NAS and re-created it. A rescan of the storage devices showed the iSCSI LUNs. I then did the From the Reddit post, there is now a KB article from VMware on this issue (iSCSI adapter IQN may change during the upgrade of ESXi 7.0 U1 (84339)<\/a>). I didn’t see the workaround (I’ll try it if a patch not available and I have to shutdown the ESXi or NAS) but here is that workaround example from the article:<\/p>\n\n\n\n To work around the issue<\/strong>: EDIT<\/strong><\/p>\n\n\n\n I couldn’t wait for the next time that I needed to reboot the ESXi server. That is probably a good idea given that I probably don’t want to have a number of things going on at the same time. I applied the VMware KB work around and then shutdown the VMs and rebooted the server. <\/p>\n\n\n\n SUCCESS!<\/strong> The iSCSI datastores automatically came up. A gin and tonic with lots of ice may be in order!<\/p>\n","protected":false},"excerpt":{"rendered":" I realized last night that in my efforts to get ESXi up and running, I had installed the original release of ESXi 7.0. Since I had taken Friday off work to take care of a few things that needed to … Continue reading esxcfg-volume -l<\/code> and get the UUIDs. Well now, iSCSI volumes are not showing up. Let’s try a few more pings to the NAS, rescan the devices. Nope, not working.<\/p>\n\n\n\nesxcfg-volume -l<\/code> and mounted, using esxcfg-volume -M UUID<\/code> (with the “M” rather than the “m” option), the two UUIDs. Bang, the datastores reappears. While the article is for upgrades and not reboots, my gut is that this problem will persist until the bug is squashed. I haven’t tested a reboot because this is a pain in the arse and I have other things I have to do.<\/p>\n\n\n\n
Prior to the upgrade, use the\u00a0esxcli get\u00a0and\u00a0set\u00a0commands to set the generated iSCSI adapter\u00a0IQN explicitly. As the IQN is a user setting it won’t change after the upgrade.
Get the IQN details:<\/strong>$ esxcli iscsi adapter get -A vmhba67<\/code>
vmhba67
\u00a0 \u00a0Name: iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67<\/code>
Set the IQN details:<\/strong>$ esxcli iscsi adapter set -A vmhba67 -n iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67<\/code><\/p>\n\n\n\n
\n\n\n\n