Not Surprised, Veeam 11 Broke Our 3PAR Integration

[CrispyPancake404]

We are currently running 3PAR at version 3.2.2 MU6, we upgraded from Veeam 10a to Veeam 11 and since have noticed all 3PAR related storage integrations fail with the following results in the logs.

Was 3.2.2 MU6 actually validated? or was just 3.3.1 and above only QA'd.... How do i explain this to my manager when we meet all the requirements but yet it doesn't work.

Please help, sorry for the venting - Case #04680817

[Gostev]

According to the system requirements, it is within the supported range:

HPE 3PAR StoreServ
• 3PAR OS versions 3.2.2 to 3.3.1 MU5

So you should be good from this perspective.

You can disable storage snapshot integration while our support is investigating your situation.

[foggy]

3.2.2 MU6 is not something new so I don't think it is related to that specific update - rather something environmental or related to Remote Copy licensing. Our higher support tiers are on it, so let's wait for their investigation results.

[CrispyPancake404]

Hello,

We did notice the following in the log:

[RemoteCopy] Remote copy is not licensed for host: '$NAME' (System.Exception)

However we see this in the documentation:

A license for the HPE 3PAR StoreServ storage system must support HPE 3PAR Virtual Copy.
https://helpcenter.veeam.com/docs/backu ... er=110#hpe

Did the requirements change?

Thank you,

CP404

[foggy]

Virtual Copy and Remote Copy are different things.

Per the initial investigation, the issue is in getting IP = 0.0.0.0 for all iSCSI adapters during rescan and inability to match those with the proxies. In v11 we've changed some requests in this area - now we're waiting for the extended logs to check the detailed calls and responses to find out the reason for this.

[foggy]

Confirmed. The issue is caused by switching to a newer WSAPI version where the format of the network configuration response has changed a bit. Shows up in case VLAN is used only. Will be fixed in one of the upcoming updates.