jjameson
Cadet
- Joined
- Aug 26, 2019
- Messages
- 2
This past weekend, I attempted to upgrade from FreeNAS 11.1-U7 to 11.2-U5. The upgrade completed without any errors, but I subsequently discovered missing iSCSI disks on some of the NAS clients. Note that the configuration of the iSCSI portal, target, and extents in 11.2-U5 match the original configuration in 11.1-U7. However, the iSCSI initiator on the clients (specifically, the three Hyper-V cluster nodes) only show one of the three iSCSI volumes -- and it is always the volume corresponding to the last extent configured in FreeNAS for the target (in this particular environment, this is the third extent). I have rebooted the Hyper-V cluster nodes and FreeNAS server multiple times and the result is consistent.
Also note that after reverting back to 11.1-U7 (by activating the previous version in System -> Boot), the three iSCSI disks are once again recognized by the Hyper-V cluster nodes. If I subsequently "roll forward" to 11.2-U5 -- and reboot all the servers -- then the first two iSCSI disks are once again missing from the cluster nodes (but the one corresponding to the third extent in FreeNAS appears as expected. I have repeated this "back and forth" process several times and the result is always the same (i.e. works as expected in 11.1-U7, but does not work in 11.2-U5).
Note that I am using Multipath I/O (MPIO) on the iSCSI target to provide redundancy across two physical switches (one network is 10.1.10.0/24 and the other is 10.1.13.0/24).
During troubleshooting, I shutdown two of the three Hyper-V cluster nodes and also tried recreating the iSCSI target on the first cluster node using a single network (10.1.10.0/24). The results were the same.
I also captured the network packets on the Hyper-V cluster node in both the 11.1-U7 and 11.2-U5 scenarios.
With FreeNAS 11.1-U7, the response from FreeNAS for the iSCSI "Report LUNs" command (i.e. 0xA0) specifies a LUN list length of 24. This is shortly followed by three distinct groups of iSCSI "Inquiry" commands (i.e. 0x12) to retrieve information about each of the three LUNs (i.e. iSCSI disks) -- such as the unit serial number. This is what I expect.
With FreeNAS 11.2-U5, the response from FreeNAS for the iSCSI "Report LUNs" command (i.e. 0xA0) specifies a LUN list length of 8. This is shortly followed by a single group of iSCSI "Inquiry" commands (i.e. 0x12) to retrieve information about the LUN corresponding to the last extent configured in FreeNAS for the target.
While investigating, I came across a forum post that talked about having a single extent per target for performance reasons. However, for "shared storage" (e.g. to support VM clustering), it seems like multiple extents per target would not be uncommon. Is anyone running multiple iSCSI extents for a single target in FreeNAS 11.2-U5? Was there some change made in the new version that precludes using this configuration?
Here are some details about my environment:
Regards,
Jeremy Jameson
Also note that after reverting back to 11.1-U7 (by activating the previous version in System -> Boot), the three iSCSI disks are once again recognized by the Hyper-V cluster nodes. If I subsequently "roll forward" to 11.2-U5 -- and reboot all the servers -- then the first two iSCSI disks are once again missing from the cluster nodes (but the one corresponding to the third extent in FreeNAS appears as expected. I have repeated this "back and forth" process several times and the result is always the same (i.e. works as expected in 11.1-U7, but does not work in 11.2-U5).
Note that I am using Multipath I/O (MPIO) on the iSCSI target to provide redundancy across two physical switches (one network is 10.1.10.0/24 and the other is 10.1.13.0/24).
During troubleshooting, I shutdown two of the three Hyper-V cluster nodes and also tried recreating the iSCSI target on the first cluster node using a single network (10.1.10.0/24). The results were the same.
I also captured the network packets on the Hyper-V cluster node in both the 11.1-U7 and 11.2-U5 scenarios.
With FreeNAS 11.1-U7, the response from FreeNAS for the iSCSI "Report LUNs" command (i.e. 0xA0) specifies a LUN list length of 24. This is shortly followed by three distinct groups of iSCSI "Inquiry" commands (i.e. 0x12) to retrieve information about each of the three LUNs (i.e. iSCSI disks) -- such as the unit serial number. This is what I expect.
With FreeNAS 11.2-U5, the response from FreeNAS for the iSCSI "Report LUNs" command (i.e. 0xA0) specifies a LUN list length of 8. This is shortly followed by a single group of iSCSI "Inquiry" commands (i.e. 0x12) to retrieve information about the LUN corresponding to the last extent configured in FreeNAS for the target.
While investigating, I came across a forum post that talked about having a single extent per target for performance reasons. However, for "shared storage" (e.g. to support VM clustering), it seems like multiple extents per target would not be uncommon. Is anyone running multiple iSCSI extents for a single target in FreeNAS 11.2-U5? Was there some change made in the new version that precludes using this configuration?
Here are some details about my environment:
- Motherboard make and model
- SUPERMICRO MBD-X10SRL-F Server Motherboard LGA 2011 R3
- CPU make and model
- Intel(R) Xeon(R) CPU E5-2603 v4 @ 1.70GHz
- RAM quantity
- 32 GB
- Hard drives, quantity, model numbers, and RAID configuration, including boot drives
- Boot - SanDisk UltraFit USB 3.0 16GB flash drive (x2)
- Seagate IronWolf Pro 4TB NAS Hard Drive 7200 RPM 128MB Cache SATA 6.0Gb/s 3.5" Internal Hard Drive ST4000NE0025 (x4)
- Hard disk controllers
- Intel® C612 controller (on-board SATA ports x10)
- Network cards
- Dual LAN with Intel® Ethernet Controller I210 (on-board network adapters)
Regards,
Jeremy Jameson
