IBM does not support same disk and tape across the same HBA on Windows.
Basically, for optimal performance the disk and tape need different values
for a couple of items and they are not testing both disk and tape on the
same HBA.

Here is the reality.  I have been running disk and tape on the same adapters
on AIX and Solaris very successfully.  I have McData Switches with ES-1000s.
The issue is are you using arbitrated hubs or real switches.  LIPs can cause
all types of problems.  In a Brocade switch or McData switch environment
with ES-1000s it is not a problem.

However, there is a case where performance will lag.  FC has a receive and
transmit link.  Remember disk reads and type writes on a backup.  So, if you
are trying to run heavy production processing read/write disk at the same
time with heavy tape backups, it is just like any other interface, it does
not perform very well.  But, if you are reading from disk and writing to
tape with large blocks, it flys.  It performs poorly when the block sizes
are small and there is a lot of chat going on about IO completes or IO
starts.

Sorry, I cannot identify the cause of the performance issue here if it is
single HBA related.  I believe you would be better if you had 2 HBAs and ran
load balancing software to the disk if it is available.  However, I think
the issue is more fundamental, disk pool migrations in the middle of doing
backups, not recommended.  Under that scenario you are doing a lot of IO
against your TSM Database and storage pools.  Have you tuned your database
specifications for buffers, etc.  I believe your problem is the database
activity on the mirrored drives that conflicts with the backup processes and
migration processes.  These migrations are probably lots of little files
causing lots of writes and reads to the database to update the information.
Look to see if the database drives are taking a pounding during this
process.