I have an LTO9 tape drive on a MS Hyper-V Host running Tape Redirector 8.0.15159.0
Installed and configured as per your technical papers, connected to the Hyper-V VM MS-server and phsycally working OK, initially impressions - a really great product and very pleased.
Upon actual usage testing though, I have as seems to be a common issue, very very slow speed issues with Tape Director iSCSI writing to the tape
After days of wasted time finding dribs and snippets of information, it seems shame that you don't provide a more user friendly interface or more informataion for more modern equipment and devices.
Server host is HPE Proliant Gen10 with dedicated fast 12G raided drives using multiple 10Gb NICs, 1x for local network access and 1x dedicated for iSCSI connection on both server host and windows server virtual,
iSCSI connection has dedicated 10Gb NIC to 10Gb NIC with no other network devices.
I see a maximum backup to tape transfer speed of 250mbps (megabits)
I expect to see at least 300MBps (megabytes) backup write speed
It all works great, its just slow
A simple 1.5Tb file backup to tape job without compresssion, takes 18hours to write, which isn't acceptable.
TROUBLESHOOTING workings:
I've not installed MPIO assuming single session of backup job to Tape with single dedicated NIC is correct for this setup
Turn off MS Defender
Installed StarWind iSCSI Accelerator on both Host and VM
Test manual copy of backup job data from VM to Host over iSCSI 10Gb nic, results in 800MBps and recopy following confirms raid controller cache working with 1300MBps transfer.
Check with HPE who confirm native write speed of LTO9 drive is 350MBps so physical network bandwidth and HDD speeds are more than acceptable
LTO9 is on dedicated SAS Controller
All LTO Firmware and Drivers are genuine HPE and latest
Set Host and VM iSCSI 10Gb NIC's for Jumbo Frames as per your vSAN recomendations.
Set and adjust TCP/IP properties as per your vSAN recomendations.
netsh int ipv4 set subint "<Name of NIC>" mtu=9000 store=persistent
netsh int tcp set heuristics disabled
netsh int tcp set global autotuninglevel=normal
netsh int tcp set global congestionprovider=ctcp
netsh int tcp set global ecncapability=enabled
netsh int tcp set global rss=enabled
netsh int tcp set global chimney=enabled
netsh int tcp set global dca=enabled
StarWind log identifies LTO9 device as follows:
'\\?\scsi#sequential&ven_hpe&prod_ultrium_9-scsi#5&3a99fb66&0&020100#{53f5630b-b6bf-11d0-94f2-00a0c91efb8b}': iScsiSptiDevice::openDevice: 'HPE Ultrium 9-SCSI Q3F9': adapter 3, bus 2, target 1, LUN 0; maxTransferLength 1048576, alignmentMask 0x3
NOTING: maxTransferLength 1048576
Picking out some other forum discussions I've adjusted the StarWind Config file as follows:
<MinBufferSize value="262144"/>
<iScsiFirstBurstLength value="262144"/>
<iScsiMaxBurstLength value="1048576"/>
<MaxPendingRequests value="1024"/>
<iScsiMaxReceiveDataSegmentLength value="1048576"/>
After restart of services, settings confirmed within Console Advanced settings
(NOTE: even though there is the handy option to modify these settings in the console, I find some settings are resticted and need to set in the config file instead, why have them modifyable and then not?)
I then adjust the MS iSCSI Initiator registry settings on the VM as per other forum discussions to match:
"[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e97b-e325-11ce-bfc1-08002be10318}\<Instance Number>\Parameters]"
<FirstBurthLength = HEX 0x0040000 (262144)>
<MaxBurstLength = HEX 0x00100000 (1048576)>
<MaxPendingRequests = HEX 0x00000400 (1024)>
<MaxRecvDataSegmentLength = HEX 0x00100000 (1048576)>
<MaxTransferLength = HEX 0x00100000 (1048576)>
LOG FILE RESULTS:
(starting of host target services):
1aa0 conf: 'MinBufferSize' = '262144'
1aa0 conf: 'iScsiFirstBurstLength' = '262144'
1aa0 conf: 'iScsiMaxBurstLength' = '1048576'
1aa0 conf: 'MaxPendingRequests' = '1024'
1aa0 conf: 'iScsiMaxReceiveDataSegmentLength' = '1048576'
1aa0 conf: Variable 'MinBufferSize' is set to '262144'.
1aa0 conf: Variable 'iScsiFirstBurstLength' is set to '262144'.
1aa0 conf: Variable 'iScsiMaxBurstLength' is set to '1048576'.
1aa0 conf: Variable 'MaxPendingRequests' is set to '1024'.
1aa0 conf: Variable 'iScsiMaxReceiveDataSegmentLength' is set to '1048576'.
(starting of vmhost & initiator)
160 Params: iScsiParameter::update: <<< Numeric param 'MaxRecvDataSegmentLength': received 1048576, accepted 1048576
160 Params: iScsiParameter::update: <<< Numeric param 'MaxBurstLength': received 1048576, accepted 1048576
160 Params: iScsiParameter::update: <<< Numeric param 'FirstBurstLength': received 262144, accepted 262144
160 Params: iScsiParams::createKeys: >>> MaxRecvDataSegmentLength=1048576.
160 Params: iScsiParams::createKeys: >>> MaxBurstLength=1048576.
160 Params: iScsiParams::createKeys: >>> FirstBurstLength=262144.
All looks good until immediately following these logs there is an additional entry:
1164 Params: iScsiParams::createKeys: >>> MaxRecvDataSegmentLength=8192.
SUMMARY:
After days and days of trolling the internet and all your forums and picking up on snippets of information adjustments as per the above.
Final transfer speed is STILL 250mbps
Nothing appears to have made any difference!
I'm thinking the last log (1164 Params: iScsiParams::createKeys: >>> MaxRecvDataSegmentLength=8192)
is a mismatch of parameters and is resetting the setting to the default 8192 which is capping the transfer?
what am I missing and why is your product so frustating to use?
Thanks for any assistance, its very much appreciated.
