Nimble storage: Snapshots being presented and ESXi hunged

[victor.bylin@atea.se]

Hi,

We have an enironment which is running the following:

VMware: 6.7 U3
Veeam: V10
Nimble: 5.2.1.100

Problem: "ESXi gets hunged and gets unresponsive, also VM gets hunged"

Nimble case answer:

"As you use Veeam or backup those occurrences are "expected" for Veeam created snapshots.
In some instances, VMware can become aware of these snapshots being set online. This can cause alerts/alarms about storage being inaccessible for a volume that does not seem to exist. As a workaround, you can set the access policy for their ESX hosts to be "Volume Only" instead of "Volume and Snapshots". This will prevent ESX from being aware of an online snapshot. These alerts/alarms typically do not cause a problem, however, this can cause hostd to lockup, preventing management of the ESX host.
In a case with VMware and Veeam, Veeam admitted to triggering a rescan of storage on the ESX hosts, which is what makes ESX aware of these additional devices. It was not clear if Veeam was fixing this issue in the future. What is important to understand that this is not the result of something wrong on the array, but entirely on the Veeam and VMware environment. This is only a workaround to prevent an issue."

Is there any known issues with Veeam and Nimble that you are working on getting resolved?
Case: 04356910.

Best regards!

[Andreas Neufert]

Asked the sepcific team to comment. But to list all snapshot on ESXi hosts is anyway a bad idea as storage rescans can happen independant from Veeam.
"Volume only" is the vendor recommended operation mode for VMware.

[foggy]

HI Victor, this is actually not expected. Snapshots and their clones should be mapped to a different initiator group than datastore volumes during rescan operations. Please investigate with the help of our engineers. They will review the customer's environment closer.

Meanwhile you can alter the default rescan period using the SanMonitorTimeout (REG_DWORD) registry value (in seconds, default is 600) to decrease the number of hangs.

[victor.bylin@atea.se]

Okay, thanks for the fast replies.

I will await the support team then.

Best regards!

[victor.bylin@atea.se]

Hi again,

After been battling with Veeam and VMware support.
Nothing has come out of it.
We decided to do the workaround with not presenting the Snapshot luns and that solved it so far.
But that is a workaround no solution as I see it.

But still i hoped Veeam would help troubleshoot as you @foggy replied.
But instead i have been a proxy for Veeam blame/questions on VMware case.
And where VMware isn't answering the Veeam questions.

To my suprise i got this reply form you:
"I understand that for you it looks like a lack of communication between vendors however I'm 100% honest with you - we do not have any "other" or internal ways of communication with VMware support."

Which to me is weird that your only communication with VMware is through the customers.

Best regards!

[flaren]

Victor,

Rest assured we'll continue working on your ticket. Our plan is to clarify with Nimble expected behavior/settings first and then get back to VMware if needed (since nornally said behavior shouldn't cause hostd crashes)

[Andreas Neufert]

To close this. The official configuration guidelines from Nimble highlight the setting "volume only" for VMware processing in the official documentation.
Nimble KB-000367
It can be accessed over this HPE account webpage:
https://infosight.hpe.com/InfoSight/med ... family.pdf

It is not a bug, it is just how Nimble present automatically the snapshots that are not supposed to be presented to VMware.
At a physical server this is needed for correct VSS processing when you use storage snapshots instead of software snapshots.