My ESX Servers can no longer connect and see the LUNs on the DSS...
Any ideas? I have rebooted the DSS twice and rescanned on ESX 15+ times.
I was already using SCST, so it's not a problem switching to that...
Printable View
My ESX Servers can no longer connect and see the LUNs on the DSS...
Any ideas? I have rebooted the DSS twice and rescanned on ESX 15+ times.
I was already using SCST, so it's not a problem switching to that...
Reverted to: 6.0up14.8101.4221 64bit and did a config restore and it rebooted and all my LUNs returned.
How can I update to 4452 without losing all my LUNs again?
It appears to be related to the update for 4362
I tried to go from 4221 to 4362 and it broke again.
In the release notes for 4362 it states: "New version of iSCSI target architecture (SCST)" This is probably what is causing the issues...
What steps can I take to get my ESX4 servers to see the target/luns/volumes again?
Have you created the LUNs with DSSv6 (with SCST)? Otherwise the following KB article will help you.
Perhaps a resignaturing which is described here can help. This works only in ESXi 3.5.
Hi! Yes, the LUNs were created originally on a DSSv6... version 3536 or something, don't quite remember.Quote:
Originally Posted by SvenB
All of the LUNs are visible and the volumes show up in ESX4 when I'm on 4221. As soon as I upgrade to 4452 they disappear and the only way I can get them back is to revert back to 4452.
I'm wondering if this is a config problem, are there any major config changes since 4221 to the new version that would cause this kind of problem?
I did notice that if I tried to remove targets in 4452 or add additional targets, the page would just refresh and nothing would happen.
I was able to get to 4362 by removing all ESX Volumes, Deleting all Volumes from Volume Groups in DSSv6, recreating all volumes as Block I/O instead of File I/O and then representing those to ESX4.
I then upgraded from 4221 to 4362 and the volumes are still present and LUNs still connecting to ESX.
I will try to 4452 upgrade now and post the results.
Upgrade to 4452 worked perfectly when using Block I/O rather than File I/O...
Apparently VMWare is less picky with Block targets.