***Disclaimer: This article was written to explain what not to do and is in no way blaming Synology for my mistake. I want to ensure no one else makes a similar mistake and loses data as I did.***
It has been a while since I blogged about the Synology DS920+ that I have and received for testing, as well as to create blogs about features, etc. I recently had an experience with my LUNs on my NAS which caused them to be deleted and thought that a blog article was warranted.
NOTE: This applies to anyone that upgraded from DSM 6.x to DSM 7.x RC prior to the GA release
My Synology DS920+ came with DSM 6.x for the operating system. I have used it for several things as noted in the other articles I have written, so when I had the chance to test the DSM 7.x RC release I figured why not and completed the upgrade on my device.
While everything looked normal after the upgrade including some new applications and a giant list of enhancements the one thing I did notice with my Intel NUCs in my home lab is that they showed the LUN devices but were not automatically mapping them. This is where the troubleshooting started out.
I tried many things like:
- Removing the iSCSI target in the Software iSCSI adapter, rescanning and then adding it back – this did not solve the problem
- I checked the configuration on my Synology device and everything looked good as the hosts were connected via their IQNs
So what to do now? Well, next step was opening a ticket with Synology to determine what the issue might be and if possibly related to VMware 7.0. I got a response to my ticket the next day indicating that there was a change in the DSM 7.x on how it handles iSCSI LUNs and connections. Now you need to create a Generic iSCSI connector and then use a new tab called “HOSTS” to manage the IQNs for the hosts and what LUNs they can access in the new – “SAN Manager” application.
So I proceeded to create a new iSCSI using the Create button –
Once you click Create the wizard opens asking for things like Name, IQN, LUNs and then you complete the wizard. It was explained to me by Support to leave the generic IQN that Synology puts there and NOT to change it because you can cause conflicts with your VMware hosts.
This is where things got very interesting for me once I upgraded to the DSM 7.x RC release of the Operating System. While troubleshooting my hosts not mapping the LUNs, I decided to delete the iSCSI target that I created. When you do this you are then prompted with another dialog to confirm that it will “Delete” the LUNs. At this point, I don’t recall seeing this prompt but might have been a little too click-happy and just clicked through it (unfortunate for me and no fault on Synology’s part).
Once this happens you enter your Administrator password and boom the iSCSI target is gone, but unlucky for me so were my LUNs. So another Support case was opened and in the end, recovery was determined to be a best effort at which point I decided to create new LUNs and rebuild my environment again from scratch. 🙁
After rebuilding my environment including my hosts again when I created a new iSCSI target on DSM 7.x (GA at this point) there was something that I noticed with the default setting and that is you can only Disable it and the Delete button is grayed out. This is a nice touch to prevent accidental deletion of LUNs.
This was a big lesson learned but one that I felt should be told to help others that may have upgraded to DSM 7.x from 6.x to inform them of the new SAN Manager as well as the new method of using iSCSI to connect to hosts for VMware. As well as what not to do like in my case by deleting the iSCSI target.
If you are able to recreate your LUNs and iSCSI target then use the Host tab to manage your ESXi connections that is the best thing.
Until my next article – stay safe out there.