wingspinner

I’ll have to give the ds3615 a retry because when I tested on a ds3615 VM with the sas controller it booted once then almost immediately crashed and would not boot thereafter. Didn’t pursue further. Could be I did something wrong so I’ll give it another try and look at the serial output.

I’ve been delaying making a similar request as flyride for some time. I am in agreement regarding the value of Jun focusing his efforts on a 1.04x like loader for the ds3615 . However the ds3617 has the capability of using the LSI SAS virtual controller on esxi which allows SMART to work on DSM with many SAS drives (not all in my experience). Ds3615 won’t work with the LSI sas controller Im not sure if it is a kernel issue or simply a driver issue. If the ds3615 can be made to work with SAS drives then that’s the answer for me. Otherwise, I wouldn’t rule out the value of having a 1.04x type loader for ds3617. I’ve had a ds3617 vm with 8 SAS drives (via rdm and the LSI sas controller) on 1.03b and dsm6.2.0 running 24/7 for months without any crashes or other issues.

Flyride, This isn’t what I’m seeing with ds918 and the 1.04b loader. If you’ve made it work i’m eager to be corrected and to understand what you have done to make it so.

That and the same hardware as Synology includes drivers for in their .pat file. As of update 6.2.1-23824 it appears that Synology has turned on module signing and security software that prevents anything but a Synology generated module from loading. So, I ntil someone puts a lot more effort in to find a way to bypass this you’ll need to have hardware that has uses the same chips for disk and networking as Synology uses. It also appears that they are taking drivers out that aren’t specific to the model it’s running on.

Don’t know anything about your ibm controller so can’t help you there. The route I chose was to go virtual which can simplify things a lot by reducing dependence on having the exact hardware. I use ESXI. The reality is DSM is designed for Synology hardware and if you want to use it you either have to build a compatible system and use available hacks, research and build your own hack, or buy a Synology box and help them pay for the costs to develop DSM. 😉

Ok, well, your post indicated you had already upgraded and it wasn’t working hence the wild goose chase....🙄

But which update? I’ve found that it works with 6.2.1 but breaks after updating to 6.2.2 because Synology doesn’t include mpt2sas in 6.2.2 and has also turned on module signing causing non Synology generated modules to be rejected.

As a result of a bit of research on the matter I can add more clarity. As I understand it, the ESXI LSI Logic Parallel and the ParaVirtual controller have no provision for translating SMART commands into something a SCSI drive can understand while the LSI Logic SAS controller does have this capability and I’ve confirmed that SMART works fine on a ds3617xs vm as long as it’s using the LSI SAS controller. . However, the SAS controller requires an Mpt2sas/mptsas set of drivers which are present in the 103b/ds3617xs combination but not in the 1.04b/ds918+. It is not recognized by the Mpt3sas driver and therefore the ESXI SAS controller doesn’t work in ds918+ vm. Two possibilities I have imagined are 1. Inject a Mpt2sas support in the ds918+ or 2. Somehow patch the syno disk data collector daemon (which appears to issue SMART commands directly to the drives without using the smartctl utility). As I understand it,, as of dsm6.2.2 module security has been turned on preventing the use of new modules not compiled by Synology and a community community generated modules will no longer work once you update past 6.2.2. That’s something that Jun mentioned and I’d like to get confirmation that I understood it correctly.

If the necessary drivers (MPT2SAS etc.)are there (as with 103b/ds3617xs) and you use the Esxi LSI SAS controller SMART works fine with no work arounds. On 1.04b/ds918+ the MPT2SAS support is missing and existing MPT3SAS driver doesn’t recognize/support the Esxi LSI sas controller.

As I recall Synology removed support for HA on the ds918+ With 6.2

In my experience using them both via Esxi they are both very stable. While I would prefer the ds3617xs because it can provide SMART info for SAS/scsi drives through 6.2 update 2, it breaks with update 3. If you are using SATA controller and drives then no problem. 1.04b/Ds918 cannot fully support sas/scsi because the necessary kernel support and drivers are not included however if you have braswell or later processor and only use Sata or don’t care about SMART support on scsi/sas then 1.04b/Ds918 works well, supports transcoding and has the benefits of a later kernel.

The ds918+ does not support SAS. Plus, the 1.04b loader only loads ds918+ as is well documented in this thread.

Thanks Ideaman! Got it working.

So I’ve been experimenting trying to get vdsm working on my ESXi 6.7 ds918 v1.04b expenology install (that’s been working flawlessly for weeks BTW). I’ve installed the VMM and have been trying to get a nested Vdsm working however the vdsm never gets and ip address and can’t be accessed. Anyway, after trying many things that didn’t help, I decided to add a static route designating my primary network interface as a gateway to my lan thinking it could be a routing problem. Well, big mistake because I lost network access to the ESXi ds819 vm. I need to remove this static route to fix it and I prefer not to do a complete reinstall if it can be avoided since I’d need to reconfigure a lot of stuff again. I have no experience with the DSM serial port so question is, after boot, is it configured such that one can use it to log in to the shell/command line? If so then I’ll set up a virtual serial port to connect to the Ds819 vm’s serial port and fix it (HPE ML350 gen 9 has virtual serial port capability ). Or, is there and easier way to cause DSM to reset the network configuration? Maybe via a grub parameter or ? Sincerely appreciate some guidance! Wingspinner ds819 v1.04b loader esxi 6.7 HPE ML350 gen 9