Hi @Owk
First of all you need to understand how Hyperflex works. A web search for Seven Things to Know to Make Hyperflex Go should lead you to a blog post I wrote some time ago. I've stolen part of this post to help explain.
When you create the first Snapshot in one of the two HXDP methods, a special SENTINAL snapshot is created. This ensures that any future snapshots can trace their pointer-based log-structured file system origins back to the original format. IF YOU CREATE THE FIRST SNAPSHOT using the VMware standard Snapshot functions, then you are stuck with the VMware Re-do snapshot system and will be stuck with the non-HX aware consolidation process should you wish to consolidate in the future.
The VMware Re-do snapshot system works like this: The first snapshot is made, and the .vmdk file for that VM is locked. A new .vmdk file is created to record any changes that are made after the original snapshot is made. Similarly, when the next snapshot is made, the second .vmdk file for that VM is locked and a new one created, and so on. The problem with this method is not so much that no data is ever deleted, and the size of the snapshot re-do files may become far greater than the original, but that if you find that you need to reclaim the space, VMware now has to revert to the original snapshot and process the Re-do files. This process can take minutes, hours or even days depending on the size and complexity of the Re-do files – and there is a possibility that the process may exhaust your existing disk space before completion (after all, you are probably doing the consolidation to reclaim some space).
Hyperflex consolidation works like this: All the pointer-based snapshots are deleted in a matter of seconds, and the redundant chunks of data marked for deletion. Job done. In seconds. And no chance of running out of disk space.
Moral of this story: Use Hyperflex pointer-based snapshots for the first snapshot for all VMs. And to ensure this happens, why not take the approach of using Hyperflex pointer-based snapshots for all snapshots?
Hopefully that clears most of your concerns up. But to be sure:
1. Why would be the implication if we stick to the VMWare snapshot without the inital native snapshots?
You are stuck with VMware snapshots, and can't take advantage of the space-saving and inherent de-duplication that Native snapshots give you, not to mention the time savings if you ever need to revert.
2. What would be the benefit? Is it only faster in reverting and deleting snapshots?
Huge space saving benefits for one, and if you use an integrated backup system such as Veeam or Cohesity, they will leverage the native snapshot system too to deliver similar savings on your backup system.
3. Does it make a differenece if the VMs were existing VMs migrated from non-HX cluster or newly created VMs?
I have no evidence other than hearsay, but I've been led to believe that there are some space saving benefits if you have newly created VMs. I can't explain why, and I would do whatever is easier to do at the time of migration.
4. Would this stil be a big deal if we generally do not allow taking of VM snapshots (usually only 1 or 2 and retained for a week) and encourage clones?
Snapshots are convenient and can even be scheduled, but as far as space saving etc goes, a snapshot is essentially a clone anyway, so the answer to this really comes down to your own preference. Not a "big deal", but I'd advise snapshots for convenience and extra sleep at night.
I hope this helps
Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem
RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.
