Hyper-V and deleting Snapshots
-
In Hyper-V when you take a snapshot you are actually creating a new disk for the changes to write to. This new disk becomes the primary one and the original disk remains untouched. When you "delete" a snapshot what you are really doing is merging the snapshot into the original vhdx.
-
So why doesn't Hyper-V simply remove the original vhdx?
-
Because then it would delete everything except the changes that have been made.
-
Install Windows Server 2012.... it writes to Server2012.vhdx ... Make a snapshot... it locks Server2012.vhdx and creates a new vhdx file (We'll call it Server2012-Snapshot1.vhdx for simplicity) that only has new changes... So now you install say... SQL Server 2035 Technical Preview and it completely hoses the server...
Delete the snapshot, and BAM! You are back to a working Server 2012 blank install.
So you try agan, but this time you install SQL Server 2014... It works. So you make a Snapshot (we'll call it Server2012-Snapshot2.vhdx, keeping in mind that we have completely deleted snapshot1). Then you configure your SQL Server and get it all happy, and then you tell the Snapshot to Merge.
This looks at the Server2012.vhdx file and compares it with the Server2012-Snapshot2.vhdx (which has information on where these changes would have been written to on the original vhdx).... and then it will take those changes and put them where they should have gone on the original Server2012.vhdx file.
After it finishes, then it would delete the Snapshot2.vhdx.
Clear as mud?
-
@dafyre said:
Because then it would delete everything except the changes that have been made.
This. The new snapshot file only has the changes written to it. It still references back to the original vhdx for reads.
-
So Hyper-V is actually using the original vhdx file, to run the OS and each snapshot to run the changes that were made to the system at the time of the snapshot?
-
@DustinB3403 said:
So Hyper-V is actually using the original vhdx file, to run the OS and each snapshot to run the changes that were made to the system at the time of the snapshot?
Yep. If you take one snapshot. Then a few weeks later take another it also freezes the previous snapshot and writes all changes to the most recent one. It uses the previous snapshot and the original as references.
-
@coliver Exactly.
-
@DustinB3403 said:
So Hyper-V is actually using the original vhdx file, to run the OS and each snapshot to run the changes that were made to the system at the time of the snapshot?
No, the original file is the "snapshot", the new file is a "delta" file. It writes changes to the delta file and uses both or else your data wouldn't show up.
-
@scottalanmiller said:
@DustinB3403 said:
So Hyper-V is actually using the original vhdx file, to run the OS and each snapshot to run the changes that were made to the system at the time of the snapshot?
No, the original file is the "snapshot", the new file is a "delta" file. It writes changes to the delta file and uses both or else your data wouldn't show up.
That was the word I was looking for, "delta".
-
Ok so that makes a bit more sense, now the last part.
Why if you went to delete a VM and it's snapshots would the system merge them into one large file before dumping the entire item?
-
@DustinB3403 said:
Ok so that makes a bit more sense, now the last part.
Why if you went to delete a VM and it's snapshots would the system merge them into one large file before dumping the entire item?
Because otherwise you would lose your data and users would be pretty upset if that happened.
-
@DustinB3403 said:
Ok so that makes a bit more sense, now the last part.
Why if you went to delete a VM and it's snapshots would the system merge them into one large file before dumping the entire item?
That one I don't know.
My guess is that the original files and proceeding snapshots are locked for writing. So they have to merge the snapshots one at a time to release them. That is only a guess though.
-
@DustinB3403 If you want to delete the entire VM (and its snapshots), it shouldn't try to merge. It would just delete all of the VHD's associated with that particular VM.
-
StrongBad I get the part about being upset, but if your goal is to "free space" on your hyper-v server, presumably you know what you're wanting to do, which is the topic of the SW links in the original post.
If the only way to free space on your server is to delete the VM's Snapshots, you're effectively deleting the delta changes to the VM.
So you're telling the server to "go back to when I first installed the VM" in effect.
-
@DustinB3403 If you delete the snapshots, then yes.... But if you merge them, then that is when it will free up the space.
Typically what I do is merge in the oldest snapshots to free up space...
-
@DustinB3403 said:
StrongBad I get the part about being upset, but if your goal is to "free space" on your hyper-v server, presumably you know what you're wanting to do, which is the topic of the SW links in the original post.
Deleting snapshots is not an action for freeing space but for merging changes. If someone was doing snapshot deletion for the purpose of savings much space (other than the deltas) then presumably they don't know what they wanted to do.
-
@dafyre which this will initially bloat the file size on the Hyper-V server, correct?
Until the merge is completed, what would happen if you attempted this merge, and didn't have enough free space on your Hyper-V server?
-
@DustinB3403 said:
If the only way to free space on your server is to delete the VM's Snapshots, you're effectively deleting the delta changes to the VM.
So you're telling the server to "go back to when I first installed the VM" in effect.
No, it might seem that way once you learn how each system works under the hood, but all VM platforms work the same - deletions DO remove the snapshot file but they don't kill the data, they merge it. VMware started this because it has a different kind of snapshot file and if HyperV did not keep the terminology you would have people killing their data right and left from confusion.
-
@StrongBad I can't speak for the SWOP, I'm just trying to understand Hyper-V as I avoid it here in our environment.
I prefer XenServer as the process is much more straight-forward.
