As far as I am aware and know you can only have one tape Library per tape server with no multi access based on the help page you posted too. Veeam tends to want to control the entire tape Library.
Correct - I have asked for Feature Enhancement, so just wanted to get comments if this would be beneficial - Single VM controlling a large library with numerous drives would never be able to efficiency transfer enough data consistently to keep the drives spinning.
I gotcha. Yeah that would be a good suggestion for sure.
Ok, you are asking for a construct like a library manager and library clients in Spectrum Protect.
Yes, I would be glad if this would work with Veeam, too. Then you could maximize the usage of your libs and drives
I think you have to write such a feature suggestions into the Veeam forums. There is product management reading.
I support this request. 
Sounds good. To understand you right: do you talk about multiple physical tape server?
Just stumbled upon this.
We regulary do connect the individual drives of a single library to different tape servers. Reason is - as stated - to circumvent a bandwidth bottleneck at the tape server. LTO8 wants to have up to 360MB/s. So four drives would be too much for 10G already.
The only thing to keep in mind is: you have to partition the library. So to VBR they look as if they are individual single drive libraries. Most libraries with multiple drives offer that option.
We don’t use virtual tape servers though - as it would only work with iSCSI anyways. I like to combine the tape server role with a Windows repository. So e.g. each extent of a SOBR can become a tape server as well. This ensures maximum speed during tape out. We use SAS or FC for the drives.
Sounds good. To understand you right: do you talk about multiple physical tape server?
i will add a +1 to this feature specially with the increase of bandwith rate of LTO9, didn’t see a bottleneck for the moment but our FC infra is brand new with 32gb ports.
I will deploy a library on ethernet with 10gb/s in short term, now i’m little bit affraid. The controller doesn’t support for the moment 25gb port.
Just stumbled upon this.
We regulary do connect the individual drives of a single library to different tape servers. Reason is - as stated - to circumvent a bandwidth bottleneck at the tape server. LTO8 wants to have up to 360MB/s. So four drives would be too much for 10G already.
The only thing to keep in mind is: you have to partition the library. So to VBR they look as if they are individual single drive libraries. Most libraries with multiple drives offer that option.
We don’t use virtual tape servers though - as it would only work with iSCSI anyways. I like to combine the tape server role with a Windows repository. So e.g. each extent of a SOBR can become a tape server as well. This ensures maximum speed during tape out. We use SAS or FC for the drives.
I like your approach with a tapeserver per repository server. I think this brings good performance.
The disadvantage is that you have to partition your tape library and have to assign the number of drives and tape slots hard to the logical libraries. So, it is not possible to give more or less ressources to one tape server automatically when it needs them.
A management instance which assigns tape drives dynamically to a tape server would solve this. Call it library manager/client or something else. 
I like your approach with a tapeserver per repository server. I think this brings good performance.
The disadvantage is that you have to partition your tape library and have to assign the number of drives and tape slots hard to the logical libraries. So, it is not possible to give more or less ressources to one tape server automatically when it needs them.
A management instance which assigns tape drives dynamically to a tape server would solve this. Call it library manager/client or something else.
Correct. That’s a weak point. But with per-VM-chains VBR more or less equalizes the amount of data being driven to a single library. Good point is, you still have the drive parallelity available for your jobs. Once you reach 3 drives there is no other option anyways. Despite you have >10G at the tape server.
I like your approach with a tapeserver per repository server. I think this brings good performance.
The disadvantage is that you have to partition your tape library and have to assign the number of drives and tape slots hard to the logical libraries. So, it is not possible to give more or less ressources to one tape server automatically when it needs them.
A management instance which assigns tape drives dynamically to a tape server would solve this. Call it library manager/client or something else.
Correct. That’s a weak point. But with per-VM-chains VBR more or less equalizes the amount of data being driven to a single library. Good point is, you still have the drive parallelity available for your jobs. Once you reach 3 drives there is no other option anyways. Despite you have >10G at the tape server.
I have direct fibre channel connections to the library at my tape servers and the repository direct on them. So I can send the data via FC to the drives and these connections are at least 16Gb, the newer ones 32Gb. And I can utilize several FC connection in parallel.
With a suitable disk solution more than three drives can be utilized.
Hello Veeam Community
I've also encountered this limitation at a customer's site. Unfortunately, Veeam cannot operate a physical library or its partitions with multiple tape servers. Will this be possible in the near future?
Best regards,
Markus
Hello Veeam Community
I've also encountered this limitation at a customer's site. Unfortunately, Veeam cannot operate a physical library or its partitions with multiple tape servers. Will this be possible in the near future?
Best regards,
Markus
As far as I know they are not. Unless confirmed otherwise by someone at Veeam. There are libraries that support multiple applications but not sure the same one twice. Veeam tends to need exclusive access to the tape library.
