I have a lab environment where I have a Synology NAS that provides iSCSI targets which are used by Windows 2012 R2 VM's running on virtual box.

I want to setup a Windows Failover Cluster and in order to do so the VM's need to share a disk.

I added a new target with a new LUN. I added this via the iSCSI initiator on the VM, formatted the disk and then added in the Storage Disks for my cluster via the Failover Cluster Manager. I can bring the Role online and it correctly initiates the disk.

By default the Synology does not allow multiple connections to the same iSCSI target.

Not enabling multiple sessions results in only one node to connect thus bring the corresponding disk online. Performing a Failover didn't automatically bring the iSCSI connection up on the other node.

It seems I have the following options:

  1. Enable *Allow multiple sessions from one or more iSCSI Initiators. This has the large warning:

    To avaoid risk of significant data corruption, please make sure you are operating in a cluster aware filesystem.

  2. Add an additional target to the LUN. Having two targets share the same LUN thus having a target per cluster node.

Both of these options result in that the iSCSI initiators on both nodes are able to connect to the iSCSI targets.


  • Which of these should I use?
  • Both seem to work does it make a difference? I understand that a target has its own buffers.
  • Is Windows Failover Clustering supporting this?
  • Which of these can result in data loss?
  • I also see that I can create a Shared cluster volume should that be used? Maybe I'm doing it completely wrong.

1 Answer 1


What I read and what I understand suggest to me that in either case you're likely to end up with corruption unless you're using a cluster-aware file system such as CSVFS. I'm not a Synology user, but I do work with iSCSI and Failover Clusters.

I would say that in your case, allowing multiple sessions will be the most appropriate option. Adding a new target might be helpful if you wanted to take advantage of MPIO, where you have two separate network segments for accessing the storage simultaneously, thus creating redundant paths.

It sounds like this would be a supported solution, and yes you should add the disk to cluster shared volumes, but you only do this once all nodes are able to 'see' the LUN.

After you've done this you can experiment by moving the CSV between nodes and seeing it stay online, and shutting down cluster nodes to watch it fail over.

One other thing... All nodes in the cluster need to be able to communicate with each other so that they can co-ordinate activities and keep an eye out for nodes going offline (heartbeat).

  • Based on your response I would say: * I should make a CSVFS in Windows Failover Clustering * That CSVFS should use the iSCSI target on my Synology NAS? The cluster is virtual, just two VM's on my desktop to get familiar on how to setup a cluster. May 9, 2016 at 16:04
  • That's correct. But you need to allow multiple sessions so that both cluster nodes can see the storage.
    – john
    May 9, 2016 at 17:00
  • John, any idea how I can test if no data loss is occurring when doing a failover? May 13, 2016 at 17:12
  • I don't think there is such a thing. Each node communicates directly with the storage, regardless of who currently owns the CSV. If there's no lock on a file/vhd/whatever (either by Cluster or Windows file system, then I guess data loss could occur. Same if a node suddenly fell out of the cluster. I think ultimately it's down to the clustered resource / application to take care of that. CSV just allows the coordination of resource locking AFAIK.
    – john
    May 13, 2016 at 17:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .