b0fh

Is anyone here running the NFS VAAI plugin in their ESX environment and have it working under 5967? I used to use it, but one of the older updates made it quit working. I was curious if it was working under current code. Thanks!

@RobsterUK - Just upgraded mine the same way. No issues to report. Thanks for the information and testing - it was quite helpful!

Thanks @RobsterUK. I am just now getting to work on mine. This was helpful!

I was hoping that was the process I could follow. I will be working on mine this weekend, so we will see who gets done first. I will try to make sure I check/update the post before and after.

Thanks @sbv3000. Anyone go straight from 5592 to 5967 yet? I might just rebuild that particular box as 5967 from the beginning, but I have two others that would not be fun to rebuild.

If you have to pull a new cable, perhaps you can tape the end of the new wire onto the end of the old wire and pull new in and old out at once. Not typical for a cable in wall to go bad though, unless hit with nail or chewed on. I would re-terminate the ends before I tried to pull new cable in. Of course, if you just pulled a pre-made patch cable through the wall, they use different ends than typical structure cable (patch cables are braided wire, structure cable is solid), and it might be easier to just pull a new one in.

@Allgamer - Cat5 is sufficient for short runs unless you are in a noisy (RF) environment. PCI will be his enemy long before Cat5 vs Cat5e comes into play. Also, Cat5 is twisted, not straight. Gigabit was adopted before Cat5e existed and was written with the intent of using Cat5. Cat5e is really only needed, like I said, in noisy environments or over full length runs (~100m) due to crosstalk.

Can anyone else chime in please?

And check your cable...some cables, especially that come with devices, only have 4 pins terminated instead of all 8 in the rj45. Make sure you are using at least Cat 5 patch cables (should be printed on the cable itself).

I am using 5592u4 right now. What is the upgrade path to get to 5967u1? Do I need to stop at 5644 in between updates or can I go straight to 5967 then 5967u1? Also, can I use the 5967 usb img to use 5644 releases during an upgrade if needed? TIA!

Check the disk group management button then.

Ok, so a followup to my own. By deleting the /var/db/iscso/EP_JNL file, I was able to get my LUN to report okay again. In the end, apparently there was a corruption of the file-based LUN. I ended up with a corrupt VM and had to rebuild it. However, using vmfs-tools in Ubuntu, I was able to recover all of my other virtual machines without issue.

Hey guys...having a problem with two file-based iscsi luns. After a reboot they are reporting that they are unavailable. I have two different volumes and each volume contains a LUN. Are there some commands I can run to fsck the volumes? Do you know the proper process (power off script?) and commands to do it? I see some references to a journal issue and found some stuff on some posts, but wanted to see if anyone here had any experience. The log center on the syno box itself doesn't show any errors related to iscsi. I don't have physical access to the box right now, so I will be slow to reply. Any help would be greatly appreciated. Lots of virtual machines down at home right now... I have some backups, but don't want to resort to it. If it matters, the drives are all samsung 850 EVO ssds connected via sata. I am using 5.2 (cannot remember the build but it is the latest build using the previous boot loader).

Just out of my own curiosity, does Synology ship their boxes with ECC? I am sure the high-end stuff does, but what about 18 series and down? I guess I thought they were non-ECC. Since they (currently) only perform XOR functions, I can't see where it would be needed. I suppose with BTRFS it *may* become more important, but I suspect using consumer class drives with consumer class interfaces that is far more likely a source of problems than the RAM. Just my opinion...

@vikino - Thanks for the info. That is quite helpful!

Do you even know what it does that would *require* an upgrade? Is there some new feature or something or is it just a matter of having the latest and greatest?

Yeah, that can be done and is functional, but then you still have a funky disk with a partial OS installed on it while running. The rmmod take might work as well, but is that something that must be reran after each XPEnology update? This is really only a test XPEnology install for testing updates for functionality (iSCSI, etc.) rather than a production system. Thanks!

@NeoID - I pretty much followed your guide, I just could not get the VM to quit seeing the boot drive as a hard drive. I could not find a setting to make the vmdk read only. By using the ISO, I got around both issues. I forgot I had a license for UltraISO from WAY back that still works, so I was able to use that to update the cfg file. All is good now I think.

Ok, so I found some hints here on the board via google. So for now I have updated the ISO file cfg file and am booting off that by adding: bios.bootOrder = "cdrom,hdd,floppy" to the vmx file. It seems to be working for now.

I built a new Xpenology box in a VM last night for testing purposes and have an issue I had hoped to solve. During the initial install, everything went find booting the vmdk. I installed the OS but it defaulted to using the vmdk that was the boot image and overwrote it such that the machine would not boot again. I replaced the vmdk and it booted fine. However, it still shows the 24mb vmdk file as a valid hard drive in the gui. Am I missing something somewhere? I attached the hardware as indicated (LSI controller with 7 16gb vmdks attached, boot vmdk on IDE bus). After replacing the VMDK, I expected it to complain at the system OS was degraded, but luckily it did not. I tried a quick search on the board and did not find anything. Has anyone else ran into this? I am running the 5592 builds of DSM (currently up to Update 4) and I am running a completely up to date ESXi 6.0 install. Thanks in advance!

I am using Rocket 620 by highpoint (http://www.newegg.com/Product/Product.a ... 6816115072) successfully.

The fact that it has (twice in my experience) caused a reboot loop where the system will not boot with the drives installed and set up a an SSD cache. It is currently being reported with the latest build 5644 now if you look through the forums.

I would be worried about SSD caching on XPEnology. It has been fairly problematic and inconsistent with support.

Use NFS - it is probably faster anyway.

Provide me with some instructions and if I have everything I need (hardware, time, clear steps & expected results, etc) I'll give it a shot. For the record I have no idea what the esx nfs plugin is. I should probably add that this policy applies to any features that the community wants added to the tests that I run. I would point out that all of my testing is done manually; so if you ask me to test something that takes more than 5 minutes to test it might not make the cut. Also keep in mind that just because something may be part of the tests that I run doesn't guarantee that it will work when we go to release. For the sake of getting releases out only core DSM functionality needs to be functional. The esx nfs plugin allows VAAI instructions to be used between ESX and Synology/XPEnology NAS devices. It allows eager-zeroed VMDK files, offloads cloning, etc. from an ESX host to the NAS device. The ESX box sees the changes immediately, even though they are still occurring on the NAS. It makes snapshotting, cloning, etc. very quick. You can download the plugin from Syno, and install it in ESXi 5.5 or 6 for testing. It would show as hardware acceleration in the ESXi client storage page. The xpenology DSM 5.1 worked fine with it, DSM5.2 has been broken the whole time. I can PM you some instructions if that would be helpful, but the syno docs show everything you would need I think. It is pretty easy to install and nothing really to configure.