twolf

I have updated to ESXi 6.5 U2 (May 2019 Patch) in the meantime and retried installing the compiled tools after deleting as you suggested. The plugin install still fails the first time: plugin: installing: https://raw.githubusercontent.com/StevenDTX/unRAID-open-vm-tools/master/openVMTools_compiled.plg plugin: downloading https://raw.githubusercontent.com/StevenDTX/unRAID-open-vm-tools/master/openVMTools_compiled.plg plugin: downloading: https://raw.githubusercontent.com/StevenDTX/unRAID-open-vm-tools/master/openVMTools_compiled.plg ... done Kernel Version: 4.18.20-unRAID plugin: run failed: /bin/bash retval: 8 And then succeeds on the second attempt: plugin: installing: https://raw.githubusercontent.com/StevenDTX/unRAID-open-vm-tools/master/openVMTools_compiled.plg plugin: downloading https://raw.githubusercontent.com/StevenDTX/unRAID-open-vm-tools/master/openVMTools_compiled.plg plugin: downloading: https://raw.githubusercontent.com/StevenDTX/unRAID-open-vm-tools/master/openVMTools_compiled.plg ... done Kernel Version: 4.18.20-unRAID plugin: downloading: https://raw.githubusercontent.com/StevenDTX/unRAID-open-vm-tools/master/packages/libdnet-1.12-x86_64-6cf.txz ... done +============================================================================== | Installing new package /boot/config/plugins/OpenVMTools_compiled/packages/libdnet-1.12-x86_64-6cf.txz +============================================================================== Verifying package libdnet-1.12-x86_64-6cf.txz. Installing package libdnet-1.12-x86_64-6cf.txz: PACKAGE DESCRIPTION: # libdnet # # libdnet provides a simplified, portable interface to several # low-level networking routines, including # Executing install script for libdnet-1.12-x86_64-6cf.txz. Package libdnet-1.12-x86_64-6cf.txz installed. plugin: downloading: https://raw.githubusercontent.com/StevenDTX/unRAID-open-vm-tools/master/packages/libffi-3.2.1-x86_64-2.txz ... done +============================================================================== | Skipping package libffi-3.2.1-x86_64-2 (already installed) +============================================================================== Starting VMWare Tools Daemon. ----------------------------------------------------------- Plugin OpenVMTools_compiled is installed. Plugin Version: 2019.05.17 ----------------------------------------------------------- plugin: installed ESXi still does not recognize any tools running though, inspecting processes no VMware Tools Daemon is running. Looking at the packages subfolder lists two libraries as from the installation log, but a 0 byte "open_vm_tools-10.3.5-4.18.20-Unraid-x86_64.tgz" which I assume is the problem. Looking at your install script and repository, I have found the issue. The kernel of 6.6.7 is "4.18.20-unRAID", and your repository correctly contains "open_vm_tools-10.3.5-4.18.20-unRAID-x86_64.tgz". Your script on the other hand attempts to download and install "open_vm_tools-10.3.5-4.18.20-Unraid-x86_64.tgz", which gives an error 404 due to the case mismatch in the filename. Manually downloading and installing with the correct filename yielded running tools, which also work after reboot. So it all comes down to that one typo of "Unraid" vs. "unRAID".

I am running unRAID 6.6.7, but have no luck running the current openVMTools_compiled plugin. It should still be downward compatible to older versions, right? A first install attempt results in errors, a second install attempt seems to succeed, and the log also shows VMware tools being started after reboot, but ESXi (6.0.0 U3, current patch) doesn't recognize any installed tools. Anything I can do to further troubleshoot this? I managed to get the last posted version of the openVMTools_auto plugin with the packages for 6.7.0-rc4 working, but the precompiled plugin seems like a more future proof solution if I would manage to get it working.

Yes, it will. But of course only with half the bandwidth compared to a full 8x slot.

OK, decided to take the plunge and rebuild the disk then. Rebuild speed was slugging along at 3-4MB/s... Massively repeated mpt2sas entries in syslog pointed to hundreds of bus resets within minutes. Finally replaced the SFF8087 cables running to the M1015, and the rebuild is moving at a decent 120MB/s now. Guess one of the cables was faulty, probably also the reason why the disk red balled in the first place. Regards, Tobias

My unRAID (5.0rc11) VM on ESXi has been happily running for over half a year now. Today I decided to shut down the host to do some hardware upgrades. Status of unRAID was perfectly fine before shutdown, no errors of any kind in the statistics or syslog, everything green. As soon as I stopped the array in preparation for shutdown, disk 6 red balled. As far as I remember nothing of import was in the syslog, but of course I forgot to save it before shutting the VM down... After checking the cabling, I powered the host and VM back up. The disk is recognized without problems (sdb), but remains of course red balled. The only other oddity is that no temperature is shown on the main screen, despite smartctl having no trouble accessing that information. Syslog and smartctrl report are attached, everything looks OK to me. As this is my first unRAID incident, I'm a bit hesitant to move forward. Should I just remove the disk, add it back again and start a regular recovery? This seems wasteful to me, as there wasn't any write access to the disk for weeks, and the last parity check in July was fine as well. How can a drive even red ball on array shutdown, is there any form of write access (metadata update) at that time? Regards, Tobias syslog.txt smartctl-sdb.txt

I still do not observe any slowdown on my mixed M1015/SAS2LP setup, so your comment about RC11 having issues with SAS2LP "for sure" is not all that sure. Other factors must play a part as well...

I think the EARX use three 667GB platters, while the EZRX use two 1TB ones instead. I have two EARX and three EZRX in my setup, and the two EARX are slower and run hotter than any of the EZRX. So my vote would clearly go to the EZRX unless the EARX was quite a bit cheaper.

Have you already tried replacing the CMOS battery with a new one? Having to force a reset sounds like the CMOS settings keep getting corrupted, one of the possible symptoms of a dying battery...

The CSE-M14TB has a SFF-8484 socket, so you would need a SFF-8484 to SFF-8087 adapter cable to connect it directly to the SASLP-MV8. But of course all the drives would be passed through then, and not only some of them.

I would suggest to purchase a cable that directly connects the 5in3 to the controller, and avoid any attempt at somehow connecting the SATA connectors of the two cables (I'm not even aware that such a thing is possible). Which controller and 5in3 model are you talking about specifically? Can't be the 5in3 listed in your signature, because that one has 5 individual SATA connectors. If the controller is the SASLP-MV8, that side needs a SFF-8087 connector.

I've never seen such a specimen in the wild, but it appears they really do exist. I stand corrected then.

Oops. Of course I meant TB and not GB. And you are quite correct about the 2.2 TB border as well, I simplified since there are no drive sizes between 2 and 3 TB.

What makes you think that is an error? As far as I remember from adding additional disks the last weeks, it's plain informational. Just start the array, unRAID will tell you that the new disks are unformatted. Check the box and click the button to format all unformatted disks, and once unRAID is done with that they will be available as regular data shares.

The -A option is only relevant for smaller advanced format drives, 3 GB (and also larger) drives will always be 4k-aligned on the GPT partition. Preclear will tell you that the partition is starting at sector 1, but that's only the (unused) MBR partition which is not actually being used.

I'm using two of the modular Seasonic cables as well to power all six backplanes. I didn't have a spare cable around, but the Seasonic support was kind enough to send me two additional cables for free. Great to experience such a fantastic customer service in this day and age!