There are some questions that pop up way more often than others. To help you and us save time, we’ve gathered the most routine ones being asked and provided comprehensive answers to them. Whether it’s general virtualization information you need or something more specific, you will probably find your answer in the Frequently Asked Questions section below.
You can find full information about StarWind VSAN in StarWind help: https://www.starwindsoftware.com/help/
Find out all the latest updates and release notes at the following link: https://www.starwindsoftware.com/release-notes-build
Detailed instructions are provided in the following KB article: https://knowledgebase.starwindsoftware.com/guidance/upgrading-from-any-starwind-version-to-any-starwind-version/
The best way to do it would be following the steps described in this KB article: https://knowledgebase.starwindsoftware.com/maintenance/how-to-restartshutdown-servers-with-starwind-vsan-installed/
NOTE: While restarting a server with StarWind VSAN installed, the connection to standalone devices (i.e., StarWind HA devices that are temporarily not replicated and StarWind .img files with no replication) will be interrupted. Make sure that resources that use standalone devices are turned off before the server shutdown.
NOTE: In case of a network driver or VMware Tools installation/upgrade, it is recommended to stop and disable the StarWind service manually on the node where this operation is going to be performed to avoid the split-brain issue. See more details about VMware Tools releases here.
If all servers with StarWind VSAN installed should be turned off, follow the steps below:
After all nodes of the HA cluster went down, StarWind VSAN may not able to determine which one holds the most recent data (i.e., was powered off the last). In order to prevent possible data loss (i.e., when a device with actual data is overwritten), StarWind VSAN blocks all the incoming connections until the synchronization source is identified and synchronization begins.
If you face the “Not Synchronized” device status on all StarWind nodes, you would need to discover which node has the most recent data. To do so, investigate Application logs on all nodes and identify the node with the synchronized device(s) at the moment of an outage.
If you are not sure which node has the actual data, contact StarWind Support or stop and disable StarWind VSAN service on all nodes except the one you assume to have the most recent data, mark the devices on that node as Synchronized, and check data consistency. If the data is not relevant (e.g.., old data appear, VMs are not able to boot, etc), stop the service on the current node, run it on the next one, Mark device(s) as Synchronized, and check data consistency on it. If you succeeded in determining data consistency, simply run the service on the nodes where it is not running yet and let the devices get synchronized.
Heartbeat is an advanced mechanism that is used to avoid data corruption in case of synchronization channel failure. If data can`t be transferred through the synchronization channel, StarWind VSAN checks the availability of the second node through an alternate network interface and marks the secondary node as Not Synchronized.
Find out more information about StarWind VSAN failover strategies in StarWind help: https://www.starwindsoftware.com/help/StarWindFailoverStrategies.html
Select the corresponding device in Starwind Management Console. In the right side window, click the Replication Node Interfaces. In the window that will appear, you can edit heartbeat and synchronization channels’ settings on the fly.
NOTE: Do not delete all the interfaces at a time and avoid situations that would result in having all the replication node interfaces down. If all the IP addresses from the Replication Node Interfaces list are to be modified, change them on the entire network stack one by one on both sides (e.g., change heartbeat IP addresses on all partner nodes first, then, modify synchronization IP addresses).
We strongly recommend connecting every data link to a dedicated subnet (every synchronization channel and heartbeat). When you select one IP, the wizard automatically reserves all IPs in that subnet. This is intended to protect StarWind VSAN users from misconfiguring HA by assigning Heartbeat and Synchronization Channel to the same data link.
In StarWind Management Console, select the device that you want to extend and click the Extending Size of HA (High availability) Device/Image File Size button in the right side window. Then, specify the disk space that you want to add and click the Finish button.
Link to KB article: https://knowledgebase.starwindsoftware.com/maintenance/how-to-extend-image-file-or-high-availability-device/
You need to install MPIO (MultiPath I/O) Feature to make Windows recognize the HA devices properly.
Unlike file-level protocols used in NAS, iSCSI is a block-level protocol and it cannot arbiter read-write access to an iSCSI device connected to multiple servers. In order to provide the access to one device from multiple servers, the device needs to have a clustered file system. While VMFS is a clustered file system and no additional actions should be done to see updated data on datastore, iSCSI storage, connected to the nodes in a Microsoft failover cluster should be managed by the cluster and formatted as CSVFS if used as Cluster Shared Volume (CSV). Such an approach allows to share single storage device between the nodes in the cluster and get updated data on them.
See StarWind VSAN help for detailed steps:
Configuring Access Rights for the targets:
https://www.starwindsoftware.com/help/TheAccessRightsTaboftheManagementConsole.html
Configuring CHAP permissions:
https://www.starwindsoftware.com/help/TheCHAPPermissionsTaboftheManagementConsole.html
We recommend you to take a look at the StarWind VSAN Benchmarking Best Practices document: https://www.starwindsoftware.com/best-practices/starwind-virtual-san-starwind-benchmarking-best-practices/
If you still face with low performance even after implementing the appropriate tweaks and checking the hardware, please contact our support team.
Write-Back caching improves write speed and lowers the latency while Write-Through caching improves only the read speed. The cache expiry period is the timeframe data is kept in the cache from the moment of the last access before being flushed to the disk. More information about StarWind cache can be found in this document: https://knowledgebase.starwindsoftware.com/explanation/starwind-virtual-san-l1-and-l2-caches-operational-principles/
You can find a detailed description of changing cache settings in this KB:
Changing, adding, and disabling L1 cache:
https://knowledgebase.starwindsoftware.com/guidance/changing-and-disabling-l1-cache/
Adding, Changing, and removing L2 cache:
https://knowledgebase.starwindsoftware.com/guidance/661/
With StarWind VSAN and the production environment set up according to StarWind VSAN Best Practices, a hardware upgrade does not normally require downtime. Below, you can find a procedure for a hardware upgrade in a 2-node setup. In Windows clusters, the procedure assumes that Windows together with its roles and features is already installed and configured on new Nodes 1 and 2. This procedure also implies each server to be capable of hosting the entire production during the maintenance.
To migrate StarWind HA to new hardware in a 2-node setup:
The storage pool is the default path to place StarWind virtual disks (LSFS proprietary files, *.img, etc. )
To change the default storage pool path please do the following actions:
StarWind included as Niche Player for the fourth consecutive time in 2021 Magic Quadrant™ for HCI Software