An administrator receives an escalation to investigate a low disk space alarm on a datastore. The administrator discovers that a snapshot has been accidentally taken on a production, write-intensive database server. The snapshot has grown to nearly 1 TB in size in less than an hour and continues growing every second.
Which behavior should the administrator expect while deleting the snapshot?
When deleting a snapshot on a production, write-intensive database server, especially one that has grown significantly, the ESXi host will commit the snapshot delta disk into the base disk. This process involves significant data merging and synchronization, leading to potential long stun times if there is ongoing high write activity, as the system needs to ensure data integrity and consistency during the snapshot deletion. This extensive merging operation can notably impact the performance of the virtual machine due to the size and continuous growth of the snapshot.
The keywords here are not "commit" or "merge" but "briefly stunned" and "result in long stun times" and the experience tells me that if you try to delete a big snapshot that also is growing every second then the VM is highly impacted by a long time.
Answer is B https://kb.vmware.com/s/article/1002836
Deleting a large snapshot takes long time and has impact in the VM.
I believe c is the answer
The answer is B. Recommend to read the full KB. The word "commit" is used and it does mention considerable delay times when dealing with high IO VMs. https://kb.vmware.com/s/article/1002836
I believe the answer is B. Forget whether the word used is "merge" or "commit", they ultimately mean the same thing. The key difference is B indicates long stun times, which aligns with merging a 1TB Snapshot, whereas C says there will be a brief stun, which definitely will not be the case with a 1TB snapshot. Therefore the answer should be B
It's not the size of the snapshot that determines the delay. It's the size of the second delta disk that is committed after the first 1TB delta disk is committed. A second delta disk is always created for the VM to write to during a consolidation operation. The is prevents delays during consolidation. Once this is done, the second delta disk is then consolidated. The second delta disk is usually pretty small since its only there for a short while and will only cause a small delay when being consolidated but not in the case of high IO operations.
Answer is C, merge
Option B is correct. Bu experience big snapshot cloud be a headache
For busy virtual machines, the volume of activity may consume system resources for longer than a usual amount of time, resulting in a larger Consolidate Helper snapshot delta. https://kb.vmware.com/s/article/1002836
For my experience committing large snapshot delta files is a non zero impact activity, if the VM is also still heavy working, the impact will be quite noticeable
Option B states that the ESXi will commit the snapshot delta disk into the base disk, but this is not the correct term used by VMware. The correct term is "merge," which is described in option C. Additionally, option B states that ongoing database write activity could result in long stun times, which is not entirely accurate since stun times are determined by the size of the snapshot and the level of disk activity on the virtual machine, not just ongoing database write activity
True, but option C states the VM will be briefly stunned, which is not true in the case of a 1TB snapshot.
Answer is B
C is the Answer
The comments here supporting answer C, try to highlight a difference between "commit" and "merge" but VMware's documentation seems to use the 2 terms interchangeably. Looking at the VMware vSphere Install, Configure, Manage V7 Lecture Manual, page 335, it mentions changes are "merged" with the base VMDK. Then the next page, it mentions snap data is "committed" to the parent (base disk). For every page until 339, it continuously mentioned "committing" delta disks to the base disks. I found other documentation link on VMware's site also mentioning committing to base disk. As those who support answer B point out, the high writes as described in the question will result in a long stun time. Considering that "commit" and "merge" mean the same thing, and unless you have super fast storage, you will end up with a long stun time, answer B seems like the correct answer.
I think C is the answer. at first,I am also confused by commit and merge. thinking about these two option,I think the words are note important, the key is "ongoing database write activity could result in long stun times". when merging delta disks into base,the guest vm OS is stopped,how database write activity happens then?and merging is the cause of vm stun not the database activity.
B, According to the VMware vSphere: Install, Configure, Manage [V7] STUDENT Lecture Manual. The key word here is "commit". I can not share a link to the material.
C is correct, Merge https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.hostclient.doc/GUID-06CB6D7D-9ECE-4C53-AA11-C5F2662328CD.html
B: https://kb.vmware.com/s/article/1002836