iSCSI Dynamic Discovery Lost after Reboot --after 6.7 to 7.0.3 Upgrade

[ChadGlass]

After upgrading one of our ESXi hosts from 6.7 to 7.0.3, the iSCSI Dynamic Discovery settings are not persisting after reboot.  I can manually re-add the dynamic discovery IP address, rescan, and all our datastores return.  The host will not lose access to the datastores until it's rebooted, at which point the dynamic discovery settings disappear again.  The software iSCSI configuration seems to be simply reset after reboot; but works perfectly once the dynamic discovery address is re-entered.  

This host has been in production since 2019 and has not had an issue with iSCSI until the 7.0.3 upgrade.  I can ping both iSCSI subnets without issue from the host.  I've tried setting the "LoginTimeout" in iSCSI from 5 (default) all the way up to 60.  The other host in this cluster, still running 6.7, is configured identically and is not experiencing any issues.  I've also removed the initiator for this host from our SAN and recreated the record.  

I've run out of ideas here.  I can't figure out why the dynamic discovery address is getting cleared on reboot.  I have a ticket open with support, but I've not heard anything back yet.  I'm hoping someone else has run across this issue and can point me in the right direction.  

[sramanuja]

Have you taken a look at https://kb.vmware.com/s/article/84339

[ChadGlass]

Thanks for the idea.  I did see that KB when looking around for a solution.  The IQN didn't change during the upgrade, however.  I did remove and replace the IQN on the SAN side just to be sure.  

[ITHelpdeskPW]

Hi,

We see the same problem with just one of our hosts. 
Have you been able to solve this with Dell support in the meantime?

[ChadGlass · Accepted solution]

@smsben Pointed me to the solution, which is in this reddit thread:

Missing iSCSI datastores after vSphere 7.0 U3 upgrade : vmware (reddit.com)

Clearing the configuration of a stale vmk and dynamic discovery address from the CLI fixed the issue for me.  It's frustrating VMWare support couldn't have pointed me in this direction, but nonetheless, this solution worked for me.