Raising the priority of the defrag process to manage disk space more efficiently also sounds like a critical enhancement. Keen to see how this update impacts performance and reliability in real-world setups! Are you still running LSFS in your environment? Could you be so kind as to share details ab...

I've done some testing a while ago using XenServer and Starwind works on top of it in both scenarios - dedicated and converged - out of the box. Moreover, I don't think you will be able to squeeze more performance out of your configuration since your network is only 1 GbE which is most probably slow...

Unfortunately I did not test so deep. Just configured and ensured it works.
Anyways, multipathing is more Xen related thing since Starwind listens and accepts connections on all possile interfaces and supports multipathing as default and by design.

Hi JonSmith,

There should be no issues in obtaining a custom license if you really need one. You have to contact Starwind guys directly, they are very friendly. Or try to PM Oksana (Staff).

Since we are talking about device header files here, have you tried changing cache settings in the header file? <cache type="write-through" size="1" units="GB" level="2"> <storage_ref id="2"/> </cache> I believe it is possible to change the type=&quo...

In the case of running one box, you should be fine with iSCSI and multipathing. As for the issues you have, I just tested similar scenario in my home lab. 2 VMs with XEN and 1 VM with Starwind. I used the guide provided by Vladislav (Staff) above and successfully connected my Starwind LUN to both Xe...

Do not think so.

In order to use VVOLs, it must be supported by storage vendor (hardware or software, does not matter). So, there is no way you could use it without special VVOLs build of Starwind.

Hi, Darth Maul!

Unfortunately, you need a 64-bit OS in order for StarWind to work properly. As per https://www.starwindsoftware.com/system-requirements the minimal Windows version is 2008 R2.

Hi Chris, It seems to me, this thread is full of misunderstandings and misleads. I will try to get what you are actually doing and to unravel this tangle. Are you using StarWind Virtual SAN Free? Right? In that case, you will not be able to connect StarWind HA devices over iSCSI. As I already wrote ...

Hi, Cabuzzi, These settings will not disrupt your FreeNAS connectivity since these are only iSCSI tweaks for better performance. Latest XenServer version has: node.startup = automatic node.session.iscsi.FirstBurstLength = 262144 node.session.iscsi.MaxBurstLength = 16776192 You can surely leave these...

To get a general idea of what you are actually trying to achieve, please refer to following guides: https://www.starwindsoftware.com/starwind-virtual-san-free-getting-started - to get the basic understanding of how it actually works. https://www.starwindsoftware.com/technical_papers/StarWind_HA_FS_N...

You have to choose Hard Disk Device -> Virtual Disk instead of Physical Disk option while creating a Starwind device. And you will be fine. My concern here is that AFAIK Storage Spaces is aligned to 4K block size and for XenServer you have to use 512B block size devices... not sure it will work this...

As far as I know starwind supports NVMe for both - as storage and as the cache. Obviously, if you have an all-flash host, you do not have L2 caching since you are already flash (you might use NVMe/PCIe Flash/FusionIO as L2 caching for all-SSD host). I believe 40Gbit network for sync is a must in suc...

There is no big deal to use SSDs or NVMe cards for L2 caching. Furthermore, the write-back mode for L2 caching was there a couple of starwind builds ago. In the current build only write-through (read optimize) L2 cache is available, but starwind guys told somewhere on the forum that this feature is ...

I usually treat L2 cache size to be able to cover your "working set" or so-called "hot data". Usually, it is 10%-20% of you total virtualized data, that is why I assume starwind recommends to size it this way. Basically, the same applies to L1 cache also, but it is rather expensi...