@obsolesce said in Linux-based StarWind VSAN: hardware-agnostic, minimalistic, and FREE SDS: @travisdh1 said in Linux-based StarWind VSAN: hardware-agnostic, minimalistic, and FREE SDS: @obsolesce said in Linux-based StarWind VSAN: hardware-agnostic, minimalistic, and FREE SDS: Is this tied together with VMWare? I thought this was going to be usable on Fedora, for example. If the Starwind software is running on Linux, the hypervisor shouldn't matter. You'll be able to mount the share Starwind it's exporting on XenServer or KVM just as well, but well all the experts just in case. @KOOLER @Oksana I'm asking because Linux and SW vSAN are worded everywhere as if it's 100% tied to VMWare, with no other use case. I can't imagine that being the case, but am asking to make sure... perhaps it's worded like that because it's written by a VMWare Architect trying to boast and sell VMWare. Just wondering, because I was under the impression you can use it how you want, not just with VMWare. I agree with you, seems like bad marketing. I’ll be interestes in using it with KVM, for example. I thing it will just export iSCSI.

@stacksofplates said in If all hypervisors were priced the same...: @storageninja said in If all hypervisors were priced the same...: @stacksofplates said in If all hypervisors were priced the same...: Also, decisions are often more nuanced than simple TCO decisions. If you have compliance requirements this often shifts to commercial solutions that have validated FIPS 140-2 modules/solutions. If you need a DISA STIG at a given level paying some money and being able to deploy a single VIB to harden compliance vs. go through checklists and argue with auditors can be a big deal. How do you quantify the cost of applying with NIST for validation with a do it yourself setup vs. a turnkey solution? RHEL/RHV have a good solution here. Auditors go through OpenSCAP scans with nice HTML reports and we justify any “failures.” It’s a pretty nice system. That just audits if it was set. What I'm talking about is a single package you deploy that goes ahead and sets the configuration settings up for you. On ESXi you can use Update Manager to track compliance with the DISA VIB, and use that for tracking it. Just attach as a baseline to your clusters and let Update Manager keep it up to date. Ed Groggin I think has a tool that will do an auto-generation of a report on the hardening guidelines. Looking online, I'm not seeing Server 2016 in STIG viewer yet. Has Microsoft not gotten a STIG out yet? Also Redhat Virtulization licensing cost as much (or more) than vSphere Standard. At that point if you don't need/want Redhat support VMware looks a lot more attractive. Oddly the only STIG for Suse I'm seeing is for Z series. Well yes and no. They have built in remediations with OpenSCAP, so you can have it auto remediate your machine. We ran an auto remediate to get the correct settings and then pushed it all out with Ansible since we can apply specific rules or not based on the type of machine since they are all RHEL based (workstations, servers, hypervisors, etc). We don’t use RHV, but they have a subset of rules for RHV which is why I mentioned it. We use bare KVM for systems and it works out pretty well. Ya I’m not sure about 2016 but I wouldn’t be surprised seeing how slow they are. The remediations are in Bash, Ansible, and I think Puppet? Anyway I have written a few of the Ansible remediations for them and have had them pulled into the project.

Thanks for sharing. I hope it saves others from making a similar mistake. I know I probably would have done just what you did.

@thwr Correct

@Dashrender said: Why should I do it more often than that? Linux boxes have been known to go years without rebooting. Because it provides for safety and reliability. Just because machines CAN go without rebooting doesn't make it a good idea. And reboots are not to make systems run better, they are to protect against the unability to reboot when things are critical. No amount of "systems can run for years without a reboot" matters because that's not related to why we reboot. http://www.smbitjournal.com/2011/02/why-we-reboot-servers/

Awesome!

This is for trading systems. It is not for anything that a normal SMB or even a normal enterprise would face. This is very specialized. Normal workloads need throughput optimization not latency optimization. So this would be the opposite of what you would want.

New to me, thanks for the heads up. Will definitely be checking these out.

That's an easy fix. As long as you have the foresight to have SSH enabled.