Enterprise Plus, HPE 3PAR, and Storage Snapshots

[Vejete]

Greetings all,

When the VBR server and all proxies are virtualized, how exactly do you utilize hardware snapshots on HPE 3PAR?

vSphere/ESXi: 5.5
VBR: 9.5 U1 Enterprise Plus
Storage: 3PAR 8450 running software 3.2.2 (MU4)
Transport: Fiber Channel (no NFS, no iSCSI)

Here are the proxy FC requirements I see:



My VMware knowledge is a bit limited, but at ESXi 5.5, I'm not sure a virtual HBA is possible for a VM.

Right now when we try to utilize storage snapshots, we get the error you might expect:



Does this mean that the Veeam proxy must be physical (not virtual), so that it can have a real HBA and fabric access to the 3PAR VVols at the Windows OS level?

Thanks in advance.

[nielsengelen]

Correct, if you use fibre channel it has to be physical with a HBA to access the volumes.

[foggy]

Hello Jim, you can pass the FC adapter from ESXi to VM through DirectPath I/O. Also it is recommended to apply Veeam B&R v9.5 Update 2, since it provides a number of fixes related to 3PAR support. Thanks.

[MichaelCade]

Vejete, here is the KB article from VMware outlining what needs to be done - https://kb.vmware.com/selfservice/micro ... Id=1010789

You can also find requirements for VMDirectPath here - https://kb.vmware.com/selfservice/searc ... Id=2142307

[Vejete]

I sure appreciate t he replies, everyone.

If you statically map a specific ESXi host PCI slot (with HBA) to a VM, this caveat applies:

While VMDirectPath I/O can improve performance of a virtual machine, enabling it makes several important features of vSphere unavailable to the virtual machine, such as Suspend and Resume, Snapshots, Fault Tolerance, and vMotion.

That notation is followed by a dizzying array of host and PCI requirements that must be met. In short, this will only work if Venus, Mercury, and Mars align perfectly.

By the time you go to all that trouble, it would probably be easier/better to simply stand up a couple of physical machines to act as dedicated FC transport proxies.

It sure would be nice if VMware could get around to truly virtualizing a FC HBA like they do with NICs and SCSI adapters.

[MichaelCade]

Our recommendation would be to go physical as a preference, the virtual FC HBA and requirements is out of our hands. Unfortunatly.

[Vejete]

Agreed, Michael. Not a dig on Veeam at all. It's a VMware limitation, as you say. I can only speculate, but I'm guessing relatively low demand coupled with potential tech roadblocks may be to blame for keeping FC HBA virtualization off the top of VMware's to-do list.

[Delo123]

Why would you need snapshotting and vMotion on a proxy VM? Also if your hardware is on the HCL there is no need for planets to be aligned Anyway, a physical proxy will probably give you much better performance with those beefy 3PAR's

[rweis]

Replying to this thread based on the Top Content listing in this weeks Digest: There are many solid and indisputable justifications for physical Veeam proxies, including the removal of the CPU & RAM burden on your valuable ESXi resource pools, for backup. One dual socket bare metal proxy server can easily service dozens of tasks with modern 12 to 22 core processors. If a server had dual 22 core processors, and just the first rank of DIMM slots filled with 8 GB sticks (64 GB RAM!), and connected with just 8 Gb FC, you'd have 800 MB of bandwidth to service 44 simultaneous VMDK backup streams. Use 16 Gb FC and...well, you get the picture. Some configurations could actually find the bottleneck to then be pushed to the 3PAR array itself with either subsystem IO contention or host port oversubscription. Not a bad place to find yourself in. As a long time SAN, backup and storage engineer, backup architecture boils down to bottleneck "whack-a-mole". Eliminate one bottleneck, only to find another one downstream!

[jane.antov]

Not recommended, but the following solution is a workaround until physical server will be available:
enable NPIV on the virtual machine and generate new WWN, zone the SAN infrastructure and create a new host on the 3PAR for the needed LUNs
https://pubs.vmware.com/vsphere-50/inde ... 0755C.html