Previously, I wrote about snapshots with Hyper-V and the architecture behind them.
There still seems to be some confusion among administrators regarding them, so let’s take another look.
The big first hurdle to understanding snapshots is that a snapshot is a moment in time.
(Start thinking like Lieutenant Daniels in Star Trek Enterprise and forget the Vulcan Science Directorate opinion that time travel is impossible).
The second concept is how snapshots work.
I have a virtual machine that I will call “TestVM.” I just created TestVM using the new virtual machine wizard and finished installing Windows Server 2008. My intent with TestVM is to test various WS08 Roles and Features.
My root run state is my fresh and clean install of WS08.
To make an offline snapshot I shutdown the VM and take a snapshot – this snapshot is (by default) labeled with the moment in time of ‘now’ (5/6/08 1:06 pm).
In the background Hyper-V copied my hardware configuration and attached a differencing disk to my TestVH.VHD thus when I power on the VM anything that I do while the VM is running will be written to the differencing disk.
If I power on the VM and do something then decide that what I did was ‘bad’ for my VM I perform a Revert. What does the revert do?
The revert takes the differencing disk that my current running state is using and throws it away and creates a new one, thus returning me back to the moment in time that the snapshot was taken.
After performing the revert I added IIS and ASP.net. This is good. But I want to go back to my clean snapshot moment (saving my current moment) and do something different. In this case I choose apply. And I select the option to “take a snapshot and apply”.
Now I have a new Online snapshot of ‘now’ (5/6/08 1:12pm) and I return back to my previous Offline snapshot.
In the background Hyper-V did something a bit different. Hyper-V copied my hardware configuration, but it also saved my running memory state, and created a differencing disk for when I return to that snapshot.
Now that I have gone back in time I am running within (yet another) new differencing disk attached to TestVM.VHD
Wow, this is getting deep. And it can. You can build an entire tree with many branches.
What I need to remember is what each moment in time represents (I can rename snapshots), that they return me to a moment in time that includes the hardware configuration (in case I change that), the disk state of the VM (whatever was written) and the running state of the VM at that moment in time.
You can see how this is pretty powerful in a test and development type of scenario. But production is a totally different issue, and smells like a new post.
4 comments:
Ahhh....I read this about an hour to late. Thanks for the info it was helpful.
Nice Post. But there is one more thing, which needs to be clarified.
What happens in the case you have two VHDs linked to the Virtual Environment. And these two VHD resides in separate disks. At the end when we create the first snapshot. Hyper V creates the AVHD file for both the VHDs on the same disk where (probably) the .vmc of the machine resides.
Now nothing is being written to the other physical disk because the .vhd file over there, stays the same size, while first physical disk keeps on increasing in size.
And on top of this, even if we delete all the snapshots, the AVHDs still stay there and all the changes are written on the AVHD rather than the original VHD.
Isn't this wrong? Shouldn't it keep the AVHD on the same disk as the VHD file? Is there a way to merge the AVHD file with the VHD file?
Wow, don't over analyze things.
First of all, Hyper-V does not have a vmc file for the VMs. Each Hyper-V hypervisor maintains a database of the resources, the virtual machines, the status, etc.
In the case of VHDs. You can put them where ever you like. This is allowed.
In the case of snapshots (or differencing disks, since that is really what they are) the child disk (the current running state) can be in any location as well. There is a pointer in the AVHD that says: "my daddy is over there and I need to link to him"
Any NEW information that is written to disk is written to the AVHD. Any reads for existing information is across both files ( the VHD and AVHD).
This is why shapshots and snapshot chains can decrease the performance of a VM. Not the writing but the reading.
and, the snapshots must be deleted in the Hyper-V manager. This will cause a merge process to happen when and only when the VM is powered down. And this merge process can take any amount of time it likes. As each disk is compared and merged into the previous. The final changes are not merged unto the root VHD until all snapshots are deleted.
But first the differencing disks are merged together.
Like I said, deleting snapshots causes a background merge, when the VM is powered off.
If you need to merge manually becuase of an "oh sh**" then take a look over here:
http://itproctology.blogspot.com/2008/06/how-to-manually-merge-hyper-v-snapshots.html
If this site had a facebook button, I would press Like 31 times!
Post a Comment