DSM Reset upon Reboot / Shutdown-Start of DSM 6.2.3 on VMware ESXi


Recommended Posts

Hello All,

 

Thought I would quickly post what I have been having trouble with here.  I have been trying to get XPEnology to run DSM on VMware ESXi 6.x and 7 (I have also tried all of this on VMware Workstation Pro 15).  Every time I get things configured inside DSM, I loose the entire configuration and my RAID Pool crashes upon restart (reboot, shutdown & start).  I am presented with the Web Assistant / "Welcome to Synology" screen asking me to install DSM again.  Each time this happens I am loosing my configurations.

 

I will admit, I am trying to mod the limits of the system by making changes to the /etc.defaults/synoinfo.conf file.  Specifically what I am changing is as follows:

  • Increase of the total number of supported disks:
    • Old Value:  maxdisks="12"
    • New Value:  maxdisks="40"
  • Telling DSM to treat every volume connected to it as an internal disk (so it can be used in pools):
    • Old Values:
      • internalportcft="0xfff"
      • usbportcfg="0x300"
      • esataportcft="0x3c00"
    • New Values:
      • internalportcft="0xffffffffff"
      • usbportcfg="0"
      • esataportcft="0"

 

As I stated, I have tried this on ESXi 6.x, ESXi 7 and VMware Workstation Pro 15.  I am experiencing this issue in each environment.

 

This makes me thing that some process may be trying to check the integrity of the synoinfo.conf file...  no sure of this at all however.

 

Has anyone else experienced this issue?  Any advice or guidance anyone may be able to provide would be greatly appreciated.

 

Best,

 

Link to post
Share on other sites

Hello All,

 

First of all allow me to apologize for my rather lackluster writeup about this issue in my prior posting...  I was facing down a hungry girlfriend.  so...  I made the executive decision to try to express this issue very quickly😉

 

I have done a bunch of additional testing and have found that the issue does not appear to be with the implementation of XPEnology / DSM on VMware; however, it appears to arise every time I made certain changes to the /etc.defaults/synoinfo.conf file.  So to reiterate and clarify, I am experiencing an issue where upon reboot / shutdown & startup, the DSM appears to be resetting bringing me to the "Welcome Back" / Disk Migration screen and asking me to reinstall DSM - of course when this happens, I loose all the modded configurations I have set.  This seems to occur only when I have made changes to any of the following variable in the synoinfo.conf file:

  • maxdisks
  • internalportcfg
  • usbportcfg
  • esataportcfg

Interestingly enough, the issue does not occur if I made the changes to allow the system to use SHR and SHR-2:

  • Adding line for support_syno_hybrid_raid="yes"
    • This is being added specifically under the line for the supportphotos variable
  • Commenting out the line for the supportraidgroups variable

I am not at all certain what is actually going on here, but somehow this seems like a level of integrity checking is occurring against the /etc.defauts/synoinfo.conf file.  Does anyone know if such integrity checks are occurring?

 

Here nitty-gritty details:

  • I am using JUNs Loader for DSM 6.2 provided here:
  • I am using the pre-built VMDK file provided here:
  • I am using the PAT file for DSM 6.2
    • Not 6.2.3 though I have tried this but am experiencing the same issues
    • DSM_DS3615xs_25426.pat
  • I am using OSF Mount to modify the grub.cfg file:
    • Changing the Series Number to one generated using the Serial Number Generation Tool
    • Changing the MAC address to match what is set for the VMs NIC.
      • Yes, I am removing the ":"
    • Commenting out the boot options that do not apply to my deployment.
  • I have modified the VMs each to use e1000 network adapter.
    • To cover my bases, I have also tried this with vmxnet3 even though this is not supposed to be supported.
  • I have tried this with both BIOS and UEFI and still no luck.
  • All disks are connected via SATA
  • The DSM disk (synoboot.vmdk -> synoboot.img) are attached to SATA0:0
  • All other disks (data disks) are attached to SATA1:*

 

I have found several instances of people running into similar issues, but does not appear to be exactly the same.

 

Has anyone else run into an issue like this?  Has anyone identified a manner in which to overcome this issue?

 

I'd be SO happy if there is a "fix" that would simply disable the ability for DSM to get pissed off over the changes to synoinfo.conf.

 

Best!

 

Link to post
Share on other sites
1 hour ago, exetus said:

I am not at all certain what is actually going on here, but somehow this seems like a level of integrity checking is occurring against the /etc.defauts/synoinfo.conf file.  Does anyone know if such integrity checks are occurring?


I don't believe this happens.  The synoinfo.conf is overwritten with regularity on upgrades, but not simply because you are booting.

 

I think the likelihood is that your modifications to the portcfg parameters are creating a situation where the drives are no longer assigned properly and DSM cannot start.  The only option it has at that point is to provide access to the recovery functionality.

Link to post
Share on other sites
Quote

I think the likelihood is that your modifications to the portcfg parameters are creating a situation where the drives are no longer assigned properly and DSM cannot start.  The only option it has at that point is to provide access to the recovery functionality.

 

That is a really good point.  The values I am using here seem pretty straight forward so I'm not certain I am doing anything incorrectly here:

  • maxdisks="40"
  • internalportcfg="0xffffffffff"
  • usbportcfg="0"
  • esataportcfg="0"

I thinking three possible solutions here...

  1. Because this is all emulating a DS3615xs - a chases that should only support 36 drives maximum (with the extended unit), perhaps I should set these values for a maximum of 36 drives.
  2. Perhaps something is going odd with the VMware USB Controller...  maybe there is something that is awkwardly attached to this controller that is confusing DSM.  Perhaps this could be the Virtual Printer device attached...  I'll do some more testing here...
  3. I would wonder if this would "correct" itself if I remove the volume / storage pool before making the changes???  Maybe DSM is confused that these changes are being made after a pool and corresponding volume have been setup...

All-in-all I will do some more testing and come back with what I find.

 

In the meantime, any additional information, hints, guidance or other tales of woe would be greately appreciated.

 

Best!

Link to post
Share on other sites

I've never personally tried to experiment with that many drives, but I believe Maxdisks=24 is the practical limit.  I wouldn't be surprised if that was your issue right there.

 

Maxdisks refers to the number of internal SATA-connected devices.  The Maxdisks=12 value is the factory setting for DS3615xs and DS3617xs native hardware.  The external arrays that expand a DS36xx to 36 drives are assigned using a different device naming scheme.

Edited by flyride
Link to post
Share on other sites
Quote

Maxdisks refers to the number of internal SATA-connected devices.  The Maxdisks=12 value is the factory setting for DS3615xs and DS3617xs native hardware.  The external arrays that expand a DS36xx to 36 drives are assigned using a different device naming scheme.

Edited 7 minutes ago by flyride

flyride,

 

This is very helpful.  Thank you!

 

I can confirm making the following changes produces the same result (recovery):

  • maxdisks="36"
  • internalportcfg="0xfffffffff"
  • usbportcfg="0"
  • estataportcfg="0"

 

I can also confirm that removing the virtual printer from the VM had no impact on this behavior.

 

I will try setting to a maximum of 24 and report back.

 

Best!

Link to post
Share on other sites

All,

 

TL;DR Version:

  • DSM supports a maximum (regardless of model emulated) of 24 disk drives - see screenshot.
    • Setting maximumdisks variable to anything higher than 24 will result in system instability and DSM resetting itself.
  • SHR/SHR-2 may seem like viable and extremely flexible options for creating your arrays; however, Synology is in the process of deprecating SHR and SHR-2.
    • There have been numerous issues with SHR and SHR-2 that have resulted in data loss for many Synology customers.
  • Changes are easy to make in the /etc.defaults/synoinfo.conf file; however, they will not persist through any updates to DSM.
    • Don't rely on such modifications...  If you build your storage pools to take advantage of either A) an increased number of disks; and/or B) Synology Hybrid Raid, your pool will crash upon any updates to DSM.
    • While never updating your system IS an option, as a security guy, I would be remis if I didn't caution against this.
    • Perhaps, if anyone owns or has access to a FS3400, we could create a IMG file using this platform and in so doing provide native support for 24 disks and RAID Groups.
  • DS3615xs does not support RAID Groups despite what it says within the interface.
  • Synology, while very nice and easy to use / manage; is actually very limited in its overall configurability.

Bottom Line:  After this whole adventure (which I wouldn't count as lost time - I learned a lot), I am likely not to build my NAS based upon Synology DSM (using XPEnology).  I will likely be looking at once again TrueNAS Core (formerly FreeNAS) which has come a very long way in the last year.

 

Long/Detailed Version:

 

Here is what my additional testing has been able to conclude...

  1. @flyrideYou are correct, the maximum number of drive supported is 24 drives.  I was able to get DSM to run stable being configured for no more than 24 drives maximum.  For anyone here is interested in doing this, here are the values that should be set in /etc.defaults/synoinfo.conf:
    • maximumdisks="24"
    • internalportcfg="0xffffff"
    • usbportcfg="0"
    • esataportcfg="0"
  2. I can also confirm the changes to support SHR do not cause any instability on the system (however...  read to the end).  If anyone is interested in configuring the SHR support for the DS3615xs image, here is what should be changed in the /etc.defaults/synoinfo.conf file:
    • Add:  support_syno_hybrid_raid="yes"
      • Above supportphotos="yes"
    • Comment out supportraidgroup="yes"
  3. Finally, I can confirm that none of these configuration changes will persist an update of DSM.  Any updates to DSM that I have attempted (even minor updates) seem to replace the synoinfo.conf file with a known-good image.  From a product support perspective, this is an ingenious move on the part of Synology; however, it does make our lives a little more difficult.
    • This can be problematic as if you have setup your pools to use a larger number of disks (more than 12) and/or if you have setup your pools to use SHR / SHR-2...  Updates will change these setting in the synoinfo.conf file and cause your pools to crash if you are relying upon either of these modifications.
  4. I have also identified that the DS3615xs does not support RAID Groups.
    • Setting up RAID Groups was going to be my workaround for the lacking support of SHR; however, that does not appear to be an option.

I also did a LOT of additional research and found out that Synology is in the process of deprecating SHR and SHR-2...  there apparently have been a great number of issues that ultimately have been cited as the cause of data loss.  This alone was enough for me to choose not to continue trying to use SHR.  This, along with the fact that the DS3615xs does not support RAID Groups makes things a little more complicated and far less flexible in setting up a NAS the way I would like using XPEnology.

 

Unfortunately this leaves me backed into a bit of a corner as I work to setup an NAS using XPEnology...  Because of the limitation of the number of disks, I have to size this solution for the total amount of space I will require throughout the whole life of the solution well in mind.  Even with options like RAID 5 and RAID6, my options for expanding my arrays will be limited to implementing a maximum of 11 disks of the same size - 11, not 12 as the 50mb DSM disk does take a "slot" in the device.

 

I will say, while I have fallen in love with the DSM OS and all its quickly-deployable applications, I have am giving some renewed thought to building my NAS solution upon FreeNAS (now part of TrueNAS).  While DSM is exceptionally quick and easy to use, I am seeing the limitations here as being a major hinderance to what I will ultimately want to setup.

 

For anyone curious, here is what I am building to run this NAS:

  • OS:  ESXi 7
  • Mobo:  H170N-WIFI
  • CPU:  i3-6100
  • RAM:  Crucial Ballistix 16GB (x2) - Total 32GB RAM
  • Disks:  Seagate Exos 7E8 4TB (x4)

A note about the H170N-WIFI Motherboard:  There are a total of six (6) SATA III interfaces on the board and all the marketing documentation for this indicates that this allows for six SATA drives to be connected.  In reality, this is not necessarily the case in all situations...  If you have any device connected to the M2 interface on this motherboard, SATA ports 0 and 2 will not longer work - this is SATA ports 0 & 2 according to the system documentation and layout; however, inside the BIOS / UEFI, these show up as SATA ports 5 and 6.  Therefore, as I am using an M2 for the OS, this will ultimately limit the total number of SATA drives supported on this motherboard to 4, not 6.  While I am exceptionally hesitant to do so, I will probably end up buying a new mobo (which will essentially lock me into a new CPU as well).

 

Final notes...  I have also been doing a bunch of research on rack-mounted chases.  In the past I have used the Rosewill 2U and 3U chases; however, these are not the greatest (though they are cheep - you get what you pay for...).  PlinkUSA (http://plinkusa.com) make a great number of modular rack-mounted chases that would fit very nicely for buiding a rack-mounted NAS system.  While I am not building my NAS using either of these chases (found them after I ordered a different case), I will be building my new VM server using one of these.

 

@flyrideThank you so much for all your help, assistance, and guidance in all of this.

 

Best!

24_max_success.png

Link to post
Share on other sites
14 hours ago, exetus said:
  • SHR/SHR-2 may seem like viable and extremely flexible options for creating your arrays; however, Synology is in the process of deprecating SHR and SHR-2.

I don't believe this is true; SHR/SHR2 are disabled on the models that support RAIDF1 (including the DS3615xs and DS3617xs) because RAIDF1 and SHR are not algorithmically compatible with each other.  If you have a reference where SHR is being deprecated for the SOHO and personal models, please advise.

 

Quote

If SHR is turned on, Raid Groups are not supported.  Turn it back off and you should see the UI options for Raid groups.

DS3615xs is listed in the support link you cited.

 

Quote
  • Synology, while very nice and easy to use / manage; is actually very limited in its overall configurability.

Bottom Line:  After this whole adventure (which I wouldn't count as lost time - I learned a lot), I am likely not to build my NAS based upon Synology DSM (using XPEnology).  I will likely be looking at once again TrueNAS Core (formerly FreeNAS) which has come a very long way in the last year.

If you want btrfs snapshot capability on low-end hardware, DSM is the only option over FreeNAS.  That said, FreeNAS is far better supported as an open-source product.

 

14 hours ago, exetus said:

my options for expanding my arrays will be limited to implementing a maximum of 11 disks of the same size - 11, not 12 as the 50mb DSM disk does take a "slot" in the device.

If the grub parameter DiskIdxMap is set correctly for your MaxDisks, the loader disk does not take up a slot.  It is initially configured for the 12 disk maximum, but will appear in the port list when you bump MaxDisks to 24.  DiskIdxMap=18 should resolve that.

 

Quote

 

@flyrideThank you so much for all your help, assistance, and guidance in all of this.

 

You are more than welcome.

Edited by flyride
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.