flyride

Ah, you are editing the Syno JavaScript file where the information is hardcoded. Thanks for posting it!

Thank you, however: Can you publish your source script? I assumed you were loading node.js to run the javascript code, but I am not sure how that could be compiled into an executable file with shc. I do not understand why you prefer to distribute as an executable file, seems a risk for others to accept this.

Any idea why this works?

Thanks for relaying your experience. But your comment #3 - let's all not forget that 1.03b development and 6.2 support is still seriously in beta. If you want stability and lack of problems, stay on 6.1 for now.

As Dfds says, yes it's ok. Answers to your future questions in this regard are found here.

I disagree with this generalization - Xeon does not offer any capabilities that desktop processors do not have. ECC RAM and improved security are Xeon's two main benefits, both which are irrelevant to DSM. So I would not worry about using DS3617xs with a non-Xeon processor as long as it supported the needed instruction set, which is a function of processor generation, not server vs. desktop. The final answer for your CPU should be discernible by reviewing the hardware capabilities as described in the Intel Ark pages. How to summarize all this? Basically, the DS916/3615/3617 DSM code base, AS COMPILED BY SYNOLOGY, seems to require a Sandy Bridge or later CPU. DSM on DS918 appears to use instructions that appeared in Haswell and later, which includes Broadwell, Skylake, Kaby Lake, Coffee Lake, Apollo Lake, Gemini Lake. The community is still compiling information about exactly which CPU's are supported, so don't assume this list is definitive. Also note that the embedded Linux kernel for DSM DS916/3615/3617 is v3.10 (even on DSM 6.2) and the DS918 uses v4.4. This may also turn out to be a threshold for CPU selection. For hardware transcoding, QuickSync processor extension is required both for Synology native support (via Video Station) or third party (i.e. Plex). QuickSync capability increases with each processor generation, so even if your processor has QuickSync support, it may not meet the specific requirements of the software you are trying to run. Also, not every modern processor has QuickSync silicon (no Atoms have it, most desktop processors do, some Xeons do). In addition to the above, DSM must support QuickSync with kernel drivers, and the required components are only available with DSM on the DS916 and DS918 platforms today.

See this here

Info Center reports what it expects on the intended hardware for the image and is not correlated to the actual CPU in the system. That said I don't think you can use more than 8 cores in DSM, if you have HT and more than 4 cores, disable hyperthreading.

Yes, that is the way Synology is supporting the older CPU's; they are not upgrading the kernel, at least in 6.2. So if you want a newer kernel, 918 will be the way to go.

Load a vmdk file in a text editor and you will have your answer.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.7-15284U1 - Loader version and model: Jun's loader v1.02b - DS3615xs - Using custom extra.lzma: NO - Installation type: VM - ESXi 6.5.0 U1-7388607 - Additional comments: REBOOT REQUIRED / No issues with physical RDM and controller pass-through.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.7-15284 Update 1 - Loader version and model: Jun's Loader v1.02b - DS916 - Using custom extra.lzma: NO - Installation type: BAREMETAL - ASRock J4105-ITX - Additional comments: NO REBOOT REQUIRED

Unless you manually modify them yourself, you will not be using anything other than original PAT files from Synology. You should read the FAQ and best practices regarding updates. In short, nobody knows for sure whether an update is going to break XPEnology. Most folks either wait for someone to report success on a software/hardware platform similar to theirs before applying an update, or have a test system that they don't mind crashing to try it out on prior to committing the production system.

If you are not using DSM to provide storage redundancy, why are you using it in the first place vs. a Linux fileshare or Docker host? You could theoretically use vSAN to achieve redundancy in the VMWare space (again DSM seems useless at that point). Like IG-88 says, you can provision on two datastores and the JBOD them together in DSM, but there is no redundancy. If you have a 1.5TB volume on a 3TB datastore, and you want a 2TB volume on a 3TB datastore, it's not difficult to add space to your VMDK, then use mdadm and btrfs/ext tools to expand the disk from command line. Another option is to create 2TB VMDK on the 2nd 3TB datastore, convert the volume to a RAID1, expand the 1.5TB VMDK to 2TB, repair which will automatically expand the volume, then drop the member on the 2nd datastore. You will then have a "critical" RAID1 which is the same as a Basic volume, you then can get rid of the error message with mdadm --grow -n 1 --force /dev/mdX

Nice, I had not seen native NVMe for cache validated yet.

XPEnology is only Intel-based, there is no support for the ARM platforms.

See this post for your first issue.

I had a similar problem, only way I could get things to work when ANY NIC had jumbo frames was to use E1000. I pass through my 10GBe card to DSM finally, and that works but I don't have other VM's that need high bandwidth.

As you found out, for some reason 6.1.7 and ESXi don't work on DS3617 image. 6.1.5 works with DS3617. DS3615 works with all 6.1.x I have not used LSI controller before but most LSI components seem to be supported, either natively on DS3617 or via extra.lzma. You do have the choice to present storage to DSM via 1) virtual drive on datastore, 2) rdm or 3) passthrough controller and drives

Make the boot disk a SATA drive (add SATA controller, delete IDE controller). The boot drive should be the only drive on that SATA controller. Make sure you are using the ESXi boot option on the loader. Then your boot disk should be hidden.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.1.7-15284 - Loader version and model: Jun's loader v1.02b - DS3615xs - Using custom extra.lzma: NO - Installation type: VM - ESXi 6.5.0 U1-7388607 - Additional comments: REBOOT REQUIRED / No issues with test VM upgrade or production VM with physical RDM and controller pass-through.

https://xpenology.com/forum/topic/12779-tried-a-recovery-choosing-migrate-option-worried-now-bricked/

I have J4105 which presumably has the same ASMedia controller, and this is not the case. The four ports (Intelx2, ASMediax2) line up disk 1-4. Which image are you using?

It works on my Kaby Lake processor, and Skylake/Kaby Lake are basically identical. I don't have QuickSync model however, so can't address transcoding questions.

https://xpenology.com/forum/topic/12764-dsm-62-23739-downgrade-or-possible-solution/?do=findComment&comment=91880