Balrog

Hello! I just expand a vmdk in a virtual Xpenology (a simple basic volume). The instructions are working very good besides two little differences: 1. After "mdadm --grow /dev/md2 --size=max" I have to use "lvextend -l +100%FREE /dev/vg1/volume_1" to grow the volume itself. 2. "btrfs filesystem resize max ..." does not work for me. I have to use "Storage Manager - Volume - Action - Expand" instead in DSM itself. But after all, the expanding works very well. Thanks very much for the information!

You can't create a snapshot of a a powered on virtual machine if you have a passthrough controller attached to this virtual machine. Then you must first shutdown the vm and then you are able to create a snapshot.

So I have now build your setup by myself. Everything went well and only one step was missing I used some info from this article to get the missing pieces: https://www.stavros.io/posts/how-to-configure-wireguard/ After adding these two lines into the server configuration file I am able to access my LAN and also the DSM via my smartphone over wireguard! I think the procedure itself will be running fine even on a raspberry pi as there is also docker available. Thank you very much again for this fine idea. 👏 Edit: I was building the first part of your manual to connect to the DSM or local LAN via wireguard. Not the second extended manual with "NFS only" or even the unprivileged access. This is something for another day.

So I just got the time to read through all information: Thank you very much for this!! Btw: We have a similar backup routine for backup "real" linux equipment (I use also Veeam Linux Free). For now I have the only issue that Veeam currently is not supporting LUKS2-encryption (only LUKS1). But this is much off topic and only a matter of time.

Nice to read that you solved the issue.

The first thing coming to my mind during reading your text is: "check speed and duplex settings!". Sometimes there is a mismatch between the NIC and the connected network switch regarding these settings which results exactly into the issues you are describing. The default setting in DSM is "auto" but maybe it helps if you to set speed/duplex fix to "1000mbit/full duplex". You can find the setting in the NIC settings of DSM. Before testing this I would suggest that you configure the second NIC as a fallback with a own fixed IP if the change doesn't work and you lost completely your connection. You can also check your network switch (if your have a manageable one) and check if the speed/duplex settings from this side is matching what DSM sees and set them fix to 1000 mbit/full duplex.

Thank you very much! Your instructions are working very well! I applied it in the same way as yours (only for supressing SMART errors on /dev/sda and /dev/sdb) and /var/log/messages is a lot quieter now!! EDIT: After enabling your fix for suppressing the SMART-Error messages I recognize a new error message which comes every minute: Every minute an error will be logged in /var/log/messages: 2020-05-19T06:17:38+02:00 diskstation ovs-appctl: ovs|00001|daemon_unix|WARN|/var/run/openvswitch/ovs-vswitchd.pid: open: No such file or directory But the openvswitch is not in use or even activated/configured! I never touched it or used docker on this DSM. Workaround: mkdir -p /var/run/openvswitch touch /var/run/openvswitch/ovs-vswitchd.pid Then the error messages are stopping instantly. ...just for others who might get the error every minute also...

Yes that's exactly the issue: your cpu does not have the needed instructions for the newest DSM. But in my case the 3615xs-image is working stable and without issues for a long time. So either upgrade your cpu/motherboard or stay at 3615/3617.

"Port URI" is set to "telnet://:8601" at my installation and it's working since years. But you use the wrong network card type: should be "E1000e" and not "E1000".

Ah well, that makes sense too. I broken hard disk is also a good reason for breaking a RAID.

Hi! I just read this thread and the first thing which comes to my mind was: "Maybe the new WD red hard disks are "new ones" with SMR.". WD40EFAX is SMR (shingled recording) with many problems on a RAID rebuild when used in a mixed environment with to good old and fast WD40EFRX (which uses CMR). If it is the case that you have a mixed environment and getting performance problems you can say "thank you" to western digital. Just google about this.

Yes. The Dell H200 HBA will be driven by the mpt2sas-driver. Here are some information aboute it: lspci -v | more [....] 0000:03:00.0 Class 0107: Device 1000:0072 (rev 03) Subsystem: Device 1028:1f1c Flags: bus master, fast devsel, latency 64, IRQ 18 I/O ports at 4000 [size=256] Memory at fd4f0000 (64-bit, non-prefetchable) [size=64K] Memory at fd480000 (64-bit, non-prefetchable) [size=256K] Capabilities: [50] Power Management version 3 Capabilities: [68] Express Endpoint, MSI 00 Capabilities: [d0] Vital Product Data Capabilities: [a8] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [c0] MSI-X: Enable+ Count=15 Masked- Capabilities: [100] Advanced Error Reporting Capabilities: [138] Power Budgeting <?> Kernel driver in use: mpt2sas [....] lsmod [....] mpt3sas 139651 0 mpt2sas 239426 12 mptscsih 18713 2 mptsas,mptspi mptbase 61898 4 mptctl,mptsas,mptspi,mptscsih scsi_transport_spi 19106 1 mptspi [....] There is no "modinfo" available under DSM. So the only info I can get quick is: root@ds2:~# ls -lah /lib/modules/mpt2sas.ko -rw-r--r-- 1 root root 416K Apr 14 09:44 /lib/modules/mpt2sas.ko root@ds2:~# cat /sys/class/scsi_host/host2/board_name SAS9211-8i root@ds2:~# cat /sys/class/scsi_host/host2/version_fw 20.00.07.00 root@ds2:~# cat /sys/module/mpt2sas/version 20.00.00.00 The HBA is listed as following in ESXi: # "Broadcom / LSI 6Gbps SAS HBA Adapter" 6Gbps SAS HBA Adapter ID 0000:07:00.0 Device ID 0x72 Vendor ID 0x1000 Function 0x0 Bus 0x7 Vendor Name Broadcom / LSI Class ID 0x107 Subdevice ID 0x1f1c Subvendor ID 0x1028 Slot 0x0 I hope you can do something with these information.

I just have a look on my 2 VMs: - the first VM has a Dell H200 HBA flashed to IT-Mode and is configured as passthrough (under ESXi 6.7 and also 7.0 on a HPE Microserver Gen 8): SMART works very well! All values are shown in DSM and I run successfully a short SMART-Test on the disks. - on the second VM I have passthroughed the original "Cougar Point 6 port SATA AHCI Controller" of the HPE Microserver Gen8: SMART is working also very well without any issues. Both VMs are running as "DS3615xs". I hope this helps a little bit to localize a little bit where to look for the root cause for your SMART issues.

Thank you very much for the new updated version of your script! It work absolute fabulous! I just exchanged the first version with the new one and rebooted a few times: root@ds2:~# chmod 0755 FixSynoboot.sh root@ds2:~# cp FixSynoboot.sh /usr/local/etc/rc.d/ root@ds2:~# reboot - the script works very well! - the login of the serial console stays now rock stable and did not disappears once since the new script is used - in DSM are no remaining remnants left from the loader - in the console of course I can see the loader still as block device: root@ds2:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT [ .... other block devices .... ] sdm 8:192 0 50M 0 disk ├─sdm1 8:193 0 15M 0 part ├─sdm2 8:194 0 30M 0 part └─sdm3 8:195 0 4M 0 part or a little bit longer: root@ds2:~# lsblk --fs NAME FSTYPE LABEL UUID MOUNTPOINT [ .... other block devices .... ] sdm ├─sdm1 vfat 00C2-16A7 ├─sdm2 vfat 2016-2016 └─sdm3 I installed "lsblk" as ipkg as it is my favorite command to list block devices in a much more human readable way. The loader is correctly available: root@ds2:~# ls /dev/syno* /dev/synobios /dev/synoboot /dev/synoboot1 /dev/synoboot2 So for now I can only say "Thank you very much!" and I have a lot to do to understand the new parts of the script. I never had contact with "uevents" before and it looks that my unmount-commands are not so bad at all. "synocheckshare" is the next command which I will have a deeper look also. I will run this for a few days and then I am going to update my main NAS. Have a nice day!

Thank you for your suggestions! I will compare everything from the ground up and give feedback. Just to make sure that I do not have any settings which are not default in the grub.cfg. These are my current entries in the grub.cfg: set common_args_3615='syno_hdd_powerup_seq=0 HddHotplug=0 syno_hw_version=DS3615xs vender_format_version=2 console=ttyS0,115200n8 withefi elevator=elevator quiet syno_port_thaw=1' set sata_args='sata_uid=1 sata_pcislot=5 synoboot_satadom=1 DiskIdxMap=0C SataPortMap=114 SasIdxMap=0' It was a long time ago that I must have a look into the grub.cfg and I am not sure if this is modified or not. I have 2 SATA Disks connected to the the VM: - "SATA Controller 0" with a 32 GByte VMDK connected as "SATA 0:0" (for some packages). This will be seen as /volume1 in DSM. - "SATA Controller 1" with the 50 Mbyte-Loader connected as "SATA 1:0" - and finally 1 Dell H200 flashed to IT-Mode with pass through to the VM (these are the data-disks) which will be seen as /volume2 in DSM. Maybe this is the root of the issue. But the VM runs fine for about 2 years now. I just tried to swap SATA 0:0 with 1:0 and change the boot order in the BIOS of the VM: - DSM is booting but /volume1 is not found anymore. So I changed the settings back to the original ones. Besides these Tests I rebooted a few times and till now I have a stable serial console on /dev/ttyS0 just like described in grub.cfg: "console=ttyS0,115200n8". EDIT: The syno-devices are looking good with the script in "/usr/local/etc/rc.d/FixSynoboot.sh" and the above settings for the VM: root@ds2:~# ls /dev/syno* /dev/synobios /dev/synoboot /dev/synoboot1 /dev/synoboot2

It seems that I am unable to edit my first post so I have to make another one instead: After applying the `FixSynoboot.sh` the first time the Loader disappears as ESATA-Devices but also at the same time I lost the access to the serial console (which is my last resort of contact if something will failing). I found my failure was I just made a `chmod 755 FixSynoboot.sh`. I deleted the `/usr/local/etc/rc.d/FixSynoboot.sh` and rebooted: I got access to the serial console is back again. At the reboot after deleting `FixSynoboot.sh` I see some messages again regarding the console: [341.514080] synobios write k to /dev/ttyS1 failed [341.558121] synobios write k to /dev/ttyS1 failed [341.591942] synobios write t to /dev/ttyS1 failed The solution is to apply the rights correct as: root@ds2:~# chmod 0755 FixSynoboot.sh root@ds2:~# cp FixSynoboot.sh /usr/local/etc/rc.d/ (Just as you have written! ). After a second reboot I get now a message "External device External SATA Disk1 on ds2 was not ejected properly." and I see two new shares "satashare1-1" and "satashare1-2" with the content of the Loader: # Rights and Owner of the script: root@ds2:~# ls -lah /usr/local/etc/rc.d/ total 12K drwxr-xr-x 2 root root 4.0K Apr 18 11:02 . drwxr-xr-x 10 root root 4.0K Aug 11 2018 .. -rwxr-xr-x 1 root root 1.6K Apr 18 11:02 FixSynoboot.sh # remaining ESATA-Share after boot and running the script: root@ds2:~# mount | grep satashare /dev/sdm1 on /volumeSATA1/satashare1-1 type vfat (rw,relatime,uid=1024,gid=100,fmask=0000,dmask=0000,allow_utime=0022,codepage=fault,iocharset=default,shortname=mixed,quiet,utf8,flush,errors=remount-ro) /dev/sdm2 on /volumeSATA1/satashare1-2 type vfat (rw,relatime,uid=1024,gid=100,fmask=0000,dmask=0000,allow_utime=0022,codepage=fault,iocharset=default,shortname=mixed,quiet,utf8,flush,errors=remount-ro) # Contents of the shares are the Loader: root@ds2:~# ls -lah /volumeSATA1/satashare1-1 total 2.6M drwxrwxrwx 6 admin users 16K Jan 1 1970 . drwxr-xr-x 6 root root 4.0K Apr 18 11:13 .. -rwxrwxrwx 1 admin users 2.5M Aug 1 2018 bzImage drwxrwxrwx 3 admin users 2.0K Apr 18 11:13 @eaDir drwxrwxrwx 3 admin users 2.0K Aug 1 2018 EFI drwxrwxrwx 6 admin users 2.0K Aug 1 2018 grub -rwxrwxrwx 1 admin users 103 Apr 25 2019 GRUB_VER -rwxrwxrwx 1 admin users 225 Aug 1 2018 info.txt drwxrwxrwx 2 admin users 2.0K Apr 18 10:27 @tmp root@ds2:~# ls -lah /volumeSATA1/satashare1-2 total 11M drwxrwxrwx 4 admin users 16K Jan 1 1970 . drwxr-xr-x 6 root root 4.0K Apr 18 11:13 .. -rwxrwxrwx 1 admin users 111 Apr 18 10:25 checksum.syno drwxrwxrwx 3 admin users 2.0K Apr 18 11:13 @eaDir -rwxrwxrwx 1 admin users 1.9M Aug 1 2018 extra.lzma -rwxrwxrwx 1 admin users 55 Apr 18 10:25 grub_cksum.syno -rwxrwxrwx 1 admin users 5.9M Apr 18 10:25 rd.gz -rwxrwxrwx 1 admin users 512 Nov 26 2018 Sone.9 drwxrwxrwx 2 admin users 2.0K Apr 18 10:27 @tmp -rwxrwxrwx 1 admin users 3.0M Apr 18 10:25 zImage root@ds2:~# ls -lah /volumeSATA1/satashare1-3 total 8.0K drwxrwxrwx 2 root root 4.0K Apr 18 11:47 . drwxr-xr-x 6 root root 4.0K Apr 18 11:47 .. I do not know where my error is or if its an issue with the loader 1.3b (you have written that you take the parts of the script from loader 1.4b). My Loader was not edited in any way besides just the PID/VID and MAC-Entries as usal. Then I started the script manually as root and the ESATA-Shares went away: # manually start the script: root@ds2:~# ./FixSynoboot.sh start # check ESATA-mounts afterwards: root@ds2:~# mount | grep satashare # check contents of ESATA-Shares: root@ds2:~# ls -lah /volumeSATA1/satashare1-2 total 8.0K drwxrwxrwx 2 root root 4.0K Apr 18 11:13 . drwxr-xr-x 6 root root 4.0K Apr 18 11:13 .. root@ds2:~# ls -lah /volumeSATA1/satashare1-1 total 8.0K drwxrwxrwx 2 root root 4.0K Apr 18 11:13 . drwxr-xr-x 6 root root 4.0K Apr 18 11:13 .. In DSM I see "External device External SATA Disk1 on ds2 was not ejected properly." I think that the the script is time or order related to run or there is a DSM-unmount command missing. I found a shell unmount command for USB-Devices (e.g. `/usr/syno/bin/synousbdisk -umount sdk1`) but I haven't found a similar command for correctly unmounting ESATA-shares in DSM from the shell. I just tried: root@ds2:~# umount /dev/sdm1 root@ds2:~# umount /dev/sdm2 I works but `satashare1-1` and `satashare1-2` are remaining empty in DSM. After another reboot there is only one mount left: root@ds2:~# mount | grep sdm /dev/sdm1 on /volumeSATA1/satashare1-1 type vfat (rw,relatime,uid=1024,gid=100,fmask=0000,dmask=0000,allow_utime=0022,codepage=fault,iocharset=default,shortname=mixed,quiet,utf8,flush,errors=remount-ro) So I think there is a time or order related issue left with the script or we need to cleanup the auto mounted "ESATA"-shares afterwards. EDIT: So I am now pretty sure that there is really some time or order related issue. - I inserted the function "FixSynoboot" into "/etc/rc.local" so it runs a little bit earlier in the boot process. - Now I don't have any mounts in DSM regarding ESATA and it looks clean. - But I lost the serial console again. Not the entire console (I must correct myself) but there is no login-prompt anymore. Messages are still written to the console but I am unable to login. - I can access the console via ssh without problems. So there must be a link between the loader and the local serial console. - I will comment out my edits in "/etc/rc.local" and will use the standalone script in "/usr/local/etc/rc.d/FixSynoboot.sh" again. Better to have some entries left in DSM than no login prompt anymore via the serial console. Maybe you have an idea how to solve the remaining issues.

Thank you very much @flyride for his extremely well written article!! 💪👏 I will try your solution today on my second backup NAS, which runs as a VM under ESXi 7.0 (since yesterday 😀 ) on a HPE Microserver Gen8 (as DS3615 with 1.03b) and give some feedback. So to make it clear. I will: - install the Update 6.2.3 manually - reboot DSM as part of the update process (as usal) - afterwards I will see the loader as ESATA - I will apply/install your script - reboot again => and now the loader disappears as ESATA and everything is like before

I just have read that you are quicker than me and found the nvme-patch. Nice to read that the patch is working!

I have found the url to the thread: https://xpenology.com/forum/topic/13342-nvme-cache-support/page/3/ There you find hopefully useful information regarding NVMEs.

If I remember it correctly then there is a hack to modify some libraries so any NVME will be recognised and shown by DSM and not only a few types. I sadly do not have the exact url to this patch but you can read from here as a first starting point: https://xpenology.com/forum/topic/21663-driver-extension-jun-103b104b-for-dsm622-for-3615xs-3617xs-918/page/9/?tab=comments#comment-130074 Please search for the term "libNVMEpatch" in the forum and I am sure that you will find some info s regarding NVMEs and DSM.

Thank you very much for this idea and solution! It looks very nice! I will have a deeper look if I got some time. May I ask if you use rsync for the copy process? I use for backup and recovery a combination of Titanium Backup (for full backup of all apps including the data) and a rsync of the internal sdcard to the NAS afterwards (made with shell scripts and no graphical output). So I have all data including apps with data pictures and so on available for a full restore.

I think that is the point to look at: I always use my B120i controller in AHCI mode under ESXi and have never suffer from bad performance or compatibility problems. But I use the internal B120i in AHCI-mode only for the ESXi-Datastore (with a SSD connected) and make a passthrough of an extra Dell H200-HBA in IT-mode to the Xpenology-VM. That works rock stable and fast. With this combination I even don't need to pass the single harddisks as RDM to the Xpenology VM.

My idea is to make a sidegrade and move your installation to DS3615. I have 3 Microserver Gen 8 which runs very fine with DSM 6.2.2 under ESXi and bare metal. I have made some tests with DS3617 and only got issues I never see with the DS3615-Branch. There are howtos in this forum how to make the move from DS3617 to DS3615. The most important part is to set the NIC to Intel E1000E (if on ESXi) or use a real Intel NIC and set the hdd-controller to SATA. Details are written in the howtos for sure.

I use Dell H200 and Dell H310 flashed to IT Mode with great success under ESXi 6.7 update 2 as passthrough and as bare metal install.

Nice! I am glad that you found the reason for not having enough space on the system for an upgrade. So this thread will be a good help for similar issues.