Veeam v7 Tape compatible using VMDirectPath

[resruss]

Hi all,

We received Gostev's tips to allow us to prepare for v7 in the coming months.
We are using tape, very excited by v7, so need to make sure that his tips for tap readiness will work in our environment

For those using tape, in this first iteration of tape support we will only devices which are directly connected to the backup management server. This means, for example, that if your backup server is virtual, and your tape library uses FC connectivity, you will have to move your backup server to the physical box that your tape library is connected to. Also, we require that OEM drivers for your tape devices are installed (there is no support for devices that appear as Unknown or Generic in Windows Device Manager), so start looking for the latest drives now.

Our setup is:

The SAS tape and media changer backplane is connected by using VMDirectPath, and using OEM drivers

Will VMDirectPath work with Veeam v7?

I'm sure we're not the only people in the same boat, just wanting to pose the question in case we need to work out another way to setup our tape loader

Thanks.

[Berniebgf]

I think you will need to be careful, there is a fine line between "it works" and "its supported". Not from a Veeam perspective but from a hyper-visor perspective.

From a VMware perspective: VMware do NOT support tape directly connected to the VMware Host. (Depending on release...)

vSphere 5.0 specific
https://www.vmware.com/support/vsphere5 ... notes.html

We have done it for some customers and it works fine (not talking about Veeam 7 just Tape with Vmware),
however if you have problems you are on your own. We have experience this (can't help you response) from both VMware and the Tape Vendor (and fair enough to).

Bernie

[veremin]

Even though this scenario is likely to work, there are certain points you have to bear in mind while thinking about it. The most crucial one is that VMware explicitly states that it doesn’t support such scenarios.

Also, having VMDirectPath option will lock corresponding VM to one physical server, so, you should forget about using any of the following VMware features: Fault Tolerance , vMotion , Storage vMotion , HA , DRS, Snapshots , Memory Hot add, CPU Hot plug , HDD Hot add , VM suspension.

Additionally, it might be worth using this article as a side, though, useful source of knowledge regarding tape support in VMware.

Thanks.

[resruss]

So essentially, we're on our own if it doesn't work, as VMware don't support it

If that is the case, we may look at using a physical server and leverage virtual proxies down the track

Thanks everyone for your help

[veremin]

The best idea, indeed; since not only is this scenario not supported by VMware, but also it has number of limitations.

Also, don’t forget that it’s just a matter of first iteration of tape support; we’ve been looking already on how it can be addressed in next releases. Thanks.

[lp@albersdruck.de]

Just a thought:

You could try to export your tape library via iscsi to the vm.
At least on linux you should be able to create a target for the tape library and export that to a windows machine.
I did that for a regular tape drive and a dvd-recorder. Initiator was the microsoft iscsi software on windows 7 pro.
I do not know if that will work with a tape library and Veeam, though.

Or you could try something like http://www.starwindsoftware.com/downloa ... redirector.

Regards,
Lars

[foggy]

Just a thought:

You could try to export your tape library via iscsi to the vm.
At least on linux you should be able to create a target for the tape library and export that to a windows machine.
I did that for a regular tape drive and a dvd-recorder. Initiator was the microsoft iscsi software on windows 7 pro.
I do not know if that will work with a tape library and Veeam, though.

Yep, this approach should also work. Just be sure to have proper drivers installed both in the VM and on the host, to which tape library is connected.

[lowlander]

running a virtual machine that connects to a tape library via passtrough.

VMWare : As I interpret the support statements of VMWare they don't validate this solution anymore.
HP : you can try it en when it works it is fine, BUT when driver updates occur / firmware changes and tape unit fails > it is hard to get support.
Veeam : refers to VMWare, basically use a physical server not a virtual.

ESXi 4.x worked fine
however......

Is there anyone using this unsupported configuration in combination with a ESX 5.5 deployment in combination with veeam 8 ?

[veremin]

Not only doesn't VMware support such implementation, but also there are number of limitation mentioned above, absence of vMotion, etc. So, if I were you, I would strongly consider attaching tape device to any Windows-based physical server, assigning tape server role to that machine and using it afterwards. Thanks.

[lowlander]

No chance to get it work on VMWare

We have repositories configured as a virtual machine.

Idea is we use a 10 GBE adapter in the ESXi host where the repository is hosted, and connect this to a physical server with a 10 GBE adapter directly.

Is it possible for the tape component of Veeam to transfer the repository data to tape over the 10 GBE adapter ?

[Dima P.]

and connect this to a physical server with a 10 GBE adapter directly

Physical server with directly attached tape library, rigth?

[lowlander]

Correct

[Dima P.]

Sounds good to me. Can I ask you to share the performance results once you are up and running? Thank you in advance.

[lowlander]

Hi Dmitry,

130 MBps for a LTO5 tape out !

we tested the backup over 10 GBE. Works like expected, bottleneck is now the target = tape.

Thing to keep in mind is when using dedup (2012 R2) on your repository. This will impact the overall tapeout performance. Restore to a repository with dedup enabled gives you full performance, while dedup is not inline

So basically it is a tradeoff between backup capacity and restore performance

[Dima P.]

Thanks - good results! I guess you can tune your performance a little bit more with enabling connections between server components unitizing the shared memory instead of TCP sockets. Check this post: New Features and Enhancements - Performance enhancements part

[lowlander]

Thanks !

Performance enhancements

Added experimental support for direct data movers communication when both are running on the same server (for example, when backing up to a local storage on backup proxy server). If your local backup jobs report Network as the bottleneck, and you see high load on some backup proxy server NICs when the data was supposed to stay local to the server, your jobs performance is likely to benefit from this behavior modifier. To enable alternative data exchange path, create the DataMoverLocalFastPath (DWORD) registry value under HKLM\SOFTWARE\Veeam\Veeam Backup and Replication, and set it to the following values:
0: Default behavior (no optimizations)
1: Data exchange through TCP socket on the loopback interface (faster)
2: Data exchange through shared memory (fastest)

We will test it in a lab if possible.

Why it is experimental, and what is the roadmap of this enhancement ?

[Dima P.]

lowlander,
Well, back to the v8 release it was, indeed, an experimental feature. For now the QA team has confirmed it to be valid and reliable, so next major version will have it as a default configuration (at least that’s the plan).