Hello
When you take a snapshot of a VM all changes (writes) in the VM is going to the delta file (if not running VVOL), Thus causing the delta to grow up to the size of the base .vmdk - but what if the same blocks inside the VM is changed multiple times?
ie. if a VM continously writes data, deletes data, and then writes data etc. (for example an FTP server serving as "relay" for incoming files, which are cached locally and then transfered to other server, and after that deleted on FTP server) - I suppose only the sum of the changes wil contribute to the size of the delta?
Or what if the same blocks of data is changed multiple times while running in snapshot - for exampel an Datawarehouse SQL server doing changes/updates to data like...
thanks for any feedback ![]()
Very simplified the logic works like this:
scsi-driver of guestOS asks latest delta vmdk: do you have block 12345 ?
If yes - the delta answers: here it is and reads or write it.
If not - the delta answers: no - ask my parent.
Effectivly that means that every block that exists in the configured size of the basedisk also can exist in any of the delta. But only once !
For the size of the delta this means that it can grow to the same size of a thick provisioned flat vmdk + plus the additional overhead for the blocktable (graintable)
I never looked in detail - over the thumb I would guess that a 100Gb vmdk could have deltas of 110Gb.
In my experience I see a quickly rising failure rate when you get close to the max size.
Anyway - for a vmdk with lots of writes and deletes I would suggest to use thick provisioning and just use snapshots as long as needed for the backup jobs to finish.
its always best practice to stop the DB services during the creation of snapshot ,. yes the blocks changes during the snapshot creation for the servers like DB, or Active directory ,
or you can choose the option quiesce which will buffer the IOPS for a while during the snapshot creation .
