Hyper-V - LUN just 'disappears'

[ldoodle]

Hi,

We have a QNAP TS-EC1679U-RP NAS: 16x 2TB SATA disks, 1 big RAID 10 of 14 disks + 2 spares. We are creating LUNs on top of the RAID and exposing to Hyper-V hosts to be used in guest OS'. The NAS is exclusively used for iSCSI. We have 1 NIC for management connected to the LAN and another 2 for iSCSI traffic (we use MPIO on the hosts so there is no teaming going on). The 2 NICs for iSCSI are connected to independent switches from the LAN. The hosts are Server 2016, and the guest OS is 2008 R2.

We have 3 LUNs attached to our file server VM: 1 for data, 1 for DFS staging area data and 1 for volume shadow copies. Strangely, the first LUN (data) just disappears, and this causes clients to grind to a halt (we have folder redirection on, pointing to this file file server). After some time (15-20 seconds) it will just come back. During this time, continuous pings to the NAS are fine. I've just needed to update NTFS permissions and while it was progressing through, the LUN dropped out repeatedly so I had to stop that process!

We have another SAN (NetApp) going through the same NICs on the hosts and the same switches. They do not show any issues.

When I say "disappear", it is seen in the screenshot attached: the capacity bar and text become hidden and any navigation of this drive is impossible until it comes back (as seen by the gray background in the address bar). The C: drive here is on the NetApp, the F: and G: drives are on the QNAP too. So it seems to be just this particular LUN going AWOL.

Most interestingly, we have EXACTLY the same configuration in our other site's file server VM (guest OS version, QNAP, NetApp etc. - the only difference is the hosts are 2012 R2 there) and this has exactly the same problem: only this one LUN goes AWOL for a bit.

What can I do to identify the problem. The LUN is 6TB (again, on both sites QNAPs).

Thanks so much!

[storageman]

Assume you have latest firmware.
What kind of LUNs are they, block or file, if file what kind of volume is it?
Can you try creating new target and reconnecting the LUNs?
Also can try connecting to a different host, is it any more reliable (obviously disconnect existing host)?

[ldoodle]

Thanks for your reply.

We've been having this problem for a while now, even after continuous firmware upgrades. We're currently on 4.3.3.0299 (2017/09/01).
They are block-based
I will try that on Saturday as I'm already in for other bits (though if it was the target, wouldn't all of E:, F: and G: disks suffer the same thing at the same time)?
Good point - I forgot to mention we actually have a 2-node cluster. Doesn't matter which host this VM is running on we still have this problem (in both of our sites)

[storageman]

Replacing the target is a long shot.
Regardless switch is ok I would test a direct connection.
If there is any space left are shares more reliable, this would prove storage not going on walkabout.
Also make sure only the ISCSI ports are set for ISCSI via service binding.

[ldoodle]

I must have exhausted all short shots!

Direct connection is a good shout.

Not sure what you mean by that?

Yep, service binding set correctly for iSCSI.

[storageman]

CIFS/SMB shares - you must know what I mean "\nas\public" say. Is it reliable?

[ldoodle]

Oh sorry - yeah know what you mean now.

I'll try it and get back to you.