Hi Experts,
I'm hoping some expert or Cisco person can tell me officially:
When & how does snapshot.alwaysAllowNative=True get set in HyperFlex?
BACKGROUND
When HXDP v4.5(2a) came out, I was excited to learn that the SENTINEL snapshot was no longer needed when your hosts were running ESXi v7.0U2.
This is made possible because in ESXi v7.0U2, a new parameter was added, called snapshot.alwaysAllowNative. Read about it here.
But I've always been perplexed about this question:
When & how does snapshot.alwaysAllowNative=True get set in HyperFlex?
I'd already asked a similar question earlier, to which no-one (publicly) responded (I did get a nice PM from someone at Cisco though that helped a bit)
With such underwhelming response, I thought I'd set out to try and answer my own questions, and in the process discovered that Cisco just hasn't told us the truth - at least not the WHOLE truth about this.
I take particular exception to the statement in the Release notes for HyperFlex v4.5(2a) when they state
Supports VAAI offload for all snapshots of a VM by automatically configuring VM attribute snapshot.alwaysAllowNative=TRUE. [Side issue: in the release notes the space between "attribute" and "snapshot" is missing, making the point very hard to read/understand]
MY EXPERIENCE
I've just deployed a VM from a .ova - and when I investigate the settings, the snapshot.alwaysAllowNative parameter IS NOT THERE
So at this stage, THE RELEASE NOTES FOR HYPERFLEX V4.5(2a) ARE LYING - when they state
Supports VAAI offload for all snapshots of a VM by automatically configuring VM attribute snapshot.alwaysAllowNative=TRUE.
Clearly NOT automatic at this stage anyway.
So let's try powering the VM on, and checking again. Nope - no change
Al right. Let's clone the VM while running - I'm going to do a VMware clone, (which will FORCE a snapshot to be created temporarily) and see
- If the clone has the parameter set
- If the original VM has the parameter set
Results:
- Does the clone has the parameter set? NO
- Does the original VM has the parameter set? NO
Clearly NOT automatic here either, even though I observed a snapshot being created and deleted during the process.
My suspicion is that I'll have to do SOMETHING that causes the HXDP to kick in and do something. So I'll see what happens when I use the vCenter plugin to do a HyperFlex Ready Clone of the new VM
Results:
- Does the clone has the parameter set? NO (I thought it might)
- Does the original VM has the parameter set? NO
By now I'm REALLY STRUGGLING to understand the meaning of "automatically configuring VM attribute snapshot.alwaysAllowNative=TRUE"
Maybe it will be different if I use HX Connect to create a Ready Clone
Results:
- Does the clone has the parameter set? NO (Again, I thought it might)
- Does the original VM has the parameter set? NO
OK so maybe I'm being unfair, let me read that point again:
Supports VAAI offload for all snapshots of a VM by automatically configuring VM attribute snapshot.alwaysAllowNative=TRUE.
So let's take a snapshot. Since VAAI offload is supported for all snapshots, it shouldn't matter if it is a VMware imitated snapshot or HX initiated, so I'll do a VMware snapshot of my VM. (OK I know I'm being unfair. But I'm just reading what was said)
Results:
- Does the VM has the parameter set after taking a snapshot? NO
I'm not surprised. OK I'll use the vCenter plugin to do another snapshot.
OH NO
Well. I expected that, given I'd just taken a Redo snapshot. And this BTW answers one of my questions from my earlier post:
- Does this mean that it is now impossible to create a VMware redo snapshot?
Clearly I can.
By this stage I'm beginning to believe that the "new" way of doing things is just as convoluted as the old SENTINEL snapshot method, except much harder to see - at least I could always easily see if the SENTINEL snapshot existed.
So, I give up. I'm going to assume that - like the old system - you actually have to take a HX snapshot to force the attribute to be set - just as in the old system you had to take a HX snapshot to force the SENTINEL to be created.
automatically configuring VM attribute snapshot.alwaysAllowNative=TRUE.
=BS
Let's do it then. I'll take a HX snapshot of the first clone I took.
Results:
- Does the clone has the parameter set after the snapshot is taken? YES
HOORAY AT LAST.
SUMMATION
Now my biggest disappointment with this feature is the complete lack of documentation. A VERY misleading statement in the release notes IS NOT SUFFICIENT.
I shouldn't have to waste a few hours of MY day doing this documentation for Cisco. It SHOULD have already been made clear, like the SENTINEL is well explained in the Administration Guides. Even the Administration Guide for v4.5 explains the SENTINEL snapshot, but FAILS TO EVEN MENTION THE snapshot.alwaysAllowNative parameter AT ALL, let alone explain that IT TOO MUST BE TREATED just like the SENTINEL snapshot.
In other words, you still need to take the first snapshot using the HXDP tools (plugin or HX Connect or API). It just WAY harder now to tell if such a snapshot has been taken or not.
Now I should finish by saying (this info is also sadly missing from any Cisco documentation) that creating the first Native snapshot in v4.5(2a) on ESXi v7.0U2 has a much shorter stun time for running VMs than perviously when the SENTINEL was created. This is important when backup software (Veeam, Commvault, Cohesity) take snapshots of running VMs so they can back them up, so the net result is positive, but the worst case of Cisco communication I've seen for some time.
Accepted Solutions
