AndroidCat

Thanks for the update. Is the warning something to worry about? May 9 19:23:24 unraid emhttp: /usr/local/sbin/plugin install http://unraid.zeron.ca/plugins/open-vm-tools/openVMTools.plg 2>&1 May 9 19:23:24 unraid logger: plugin: skipping: /boot/packages/open_vm_tools-9.10.0.2476743_unRaid6.0beta15-x86_64-3Zeron.tgz already exists May 9 19:23:24 unraid logger: plugin: running: /boot/packages/open_vm_tools-9.10.0.2476743_unRaid6.0beta15-x86_64-3Zeron.tgz May 9 19:23:26 unraid kernel: vmw_vmci 0000:00:07.7: Found VMCI PCI device at 0x11080, irq 16 May 9 19:23:26 unraid kernel: vmw_vmci 0000:00:07.7: Using capabilities 0xc May 9 19:23:26 unraid kernel: Guest personality initialized and is active May 9 19:23:26 unraid kernel: VMCI host device registered (name=vmci, major=10, minor=57) May 9 19:23:26 unraid kernel: Initialized host personality May 9 19:23:26 unraid vmsvc[8416]: [ warning] [vmtoolsd] Opening plugin 'libdeployPkgPlugin.so' failed: libDeployPkg.so.0: cannot open shared object file: No such file or directory. May 9 19:23:26 unraid kernel: NET: Registered protocol family 40

Me too.

Are you considering it for next beta/rc? If you are hesitant could you provide it as a plugin or just binaries for those willing to test it?

Ok, I misunderstood your post. So if someone is formatted today with xfs and we include new progs and they want to use xfs v5, you are saying they will have to reformat, correct? But if they don't care about v5 and we update the progs, even to 3.3 when released, it won't force them to reformat. Yes Sir, you got it right.

What I understood reading xfs docs: Kernels above 3.14 support v5 of xfs without any additional work, To use v5 you have to do mkfs.xfs with additional switches and that will create additional structures on disk allowing new functionalities, UnRAID will not have problems handling either old or v5 format as it has kernel new enough to support both, Newest version of xfsprogs is needed to format HDD with v5, Upcoming xfsprogs 3.3 will format disks with v5 by default (no cmdline switches needed). Seems pretty straightforward to me and no harm is done to anybody.

Simply because if you want to use newer xfs version you need to reformat all array drives yet again.

Thanks a lot for trying. Still hope for b15 to be out soon, but in case it goes slow there is time to fix the compilaton issue

jonp-> It's a good first step. According to XFS wiki those switches (-m crc=1,finobt=1) will be invoked by default in upcoming xfsprogs 3.3 - mkfs.xfs They create additional data structures during formatting and the only downside, which is not relevant to unRAID, is that kernels <3.15 will mount such disk as RO.

Can we please get an answer from LT about the following: -estimate when new version of xfs tools will make it into unRAID, -is there any issue with manually formatting disks with additional switches (outside of unRAID) and using them with current unRAID versions? -does any of the new xfs feature seem useful to LT in the future? Rationale: if possible update xfstools asap and add those switches to 'format' command by default. Even if the new features are not going to be used any time soon by unRAID, that will save another round of moving data and re-formatting disks. Thank you.

There is no such thing acceptable in production systems as "FS being pretty stable". It is either stable and proven or unstable. Like in Bulgakov's book `Second freshness - that's what is nonsense! There is only one freshness - the first - and it is also the last. And if sturgeon is of the second freshness, that means it is simply rotten.'

Jonp, xfsprogs were not updated? http://lime-technology.com/forum/index.php?topic=36619.0

+1

Well, at the time tried to talk to Dynamix developer but he was not interested.

I've been running the setup you want for over a year with no issues. Virtual disk lays on top of SSD and there is no any perceivable loss of performance. I can tell that because I previously used same SSD, but connected as a physical cache drive in unRAID. Started using virtual disk for the same reason as you- to save physical ports of a disk controller card. With SSD you will easily saturate a gig network with either solution.

Please improve NFS handling even if you have to drop v3. I am currently forced to use CIFS towards several Linux VMs, because NFS has been so unreliable in unRAID.

Correct, vCenter

I use ESXi 5.1 and don't intend to upgrade it. All is running well and there is simply no reason to upgrade IMHO. Besides, new features in 5.5 require vSphere which is not free.

What HDMI 2 Ethernet converters do you use? Is that 100% reliable solution? Thanks.

grumpybutfun-> **With your implementation would it be possible to use current unRAID array right away without any import/conversion? If somebody already has working array of xxTB will it be recognized by your distribution? You understand that it would be a killer when we somehow have to transfer that much data from one place to another. **Then ideally will I be able to swap ReiserFS for BTRFS (or other filesystem of choice) one disk at a time? Really appreciate your work and speaking the truth about unRAID being behind.

Yes, IPMI version only for those who have server-grade boards equipped with it. If you want to tackle it in the future, just let me know, I can easily test your code. I believe the user base is quite big and growing as more and more go with Supermicro boards and ESXi. I'm curious whether lm-sensors work in KVM/XEN unRAID (if the VM has access to the MB chip)? Anyway, thanks for your efforts!

ogi-> As stated before that only works on bare-metal X9SCM-F. I just compiled freeIPMI package on separate Slackware VM and it works. I can only hope bonienl would be interested in adding that option to his plugin. That would require adding freeIPMI package and then parsing its output //see attachment//.

Anyone found a way to use lm-sensors on X9SCM-F but with unRAID running under ESXi? In that case modprobe w83627ehf complains 'no such device found'. Apparently such devices are not passed-through to a VM. I tried with other modules, but they do not work either. Maybe the only way is to read system temp via IPMI linux tools? Edit: I found this: http://www.thomas-krenn.com/en/wiki/Supermicro_X9SCM-F_Motherboard We would require FreeIPMI package then and modified/alternative version of System Temp plugin for IPMI.

Nice work, I have the same problem with last drive (disk 10) in the array failing the test: (...) Drive 9: 168 MB/sec avg /dev/=sdh: No such file or directory ./diskspeed.sh: line 58: / 1000: syntax error: operand expected (error token is ./diskspeed.sh: line 70: /tmp/diskspeed.disk10: No such file or directory rm: cannot remove `/tmp/diskspeed.disk10': No such file or directory Attached mdcmd. Thanks. mdcmd.txt

Looks very nice and functional. Great work!

Upgraded test server from rc15 to final without wiping. All is fine.