значит, лучше так не делать

Нажать удалить файл и в середине процесса передумать?

Ну да, так себе идея

Отличная идея, я на 6.5 так делал 😂

вообще, в свойстве задания написано cancelable

так что идея-то норм

интересно, что технически происходит в этот момент

В какой именно?

в момент отмены удаления снепшота

Вероятно, с блоков помеченных на удаление, снимается это флаг

VMware делает facepalm
Потом шумно выдыхает воздух и, например, идет читать файл CBT.

Вот только данные уже могут быть перезаписаны

+

Ну будут - и будут 🙈
Есть базовый VMDK-диск и есть дельта, куда пишутся изменения с момента создания снапшота.
Процесс удаления снапшота - это операция перезаписи блоков базового диска на основе содержимого дельты.
Во время этого процесса вы же продолжаете куда-то писать (запись на диск не останавливается)? ;)

Логично при удалении снапшота помечать где-то перезаписываемые блоки базового диска.
И при желании системного администратора (Cancel) - обратно создать диск дельты и на основе CBT-файла (или любого другого журнала транзакций) привести базовый диск обратно к состоянию "до создания снапшота".

Все равно "для гостевой ОС" у вас существует только одно состояние диска - актуальное на текущий момент. Она и не подозревает о снапшотах

Да действительно, кому нужна эта целостность цепочки зависимых файлов. Да и диск у нас бесконечный, чтобы держать полную копию вмдк, пока идёт трансформ, на случай если юзер передумает

😂
Бесконечный жесткий диск...
В 2010 году и vSphere 4.0 решил удалить разом 20 снапшотов у виртуальной машины. Места на хранилище было 900% от размера VMDK-файла, но увы 😂
Только в v4.0 U2 VMware решила исправить механизм применения снапшотов на "удаляем по-одному" 👍

вообще непонятно, зачем вся эта возня с копированием, когда есть метаданные

Cow, row, зачем это все. Файлы же

Не относится, только начиная с 6.0 добавили выборочное копирование блоков при консолидации снепшотов