(Although, I truely feel that a little time exploring the user interface and anyone could figure this out on their own.)
I have written about snapshots quite a bit as Hyper-V snapshots are a new thing for most folks.
Not that a snapshot is new (or a checkpoint for those of you using SCVMM), but the way that Hyper-V does it is definitely different.
You can find those previous posts here, here, and here.
Anytime you think Hyper-V snapshots, always remember that the integrity of the timeline must be maintained. That is key to grokking the concept.
Now, let’s begin.
First of all, you can create a snapshot (
Second, you can Apply a snapshot. This takes me back to the point in time that is represented by the snapshot I selected. It does this by the same process as above, it creates a differencing disk and attaches it to the VHD that is referenced by the snapshot.
Okay, if I am losing you – you need to back up and read the posts I referenced above.
For the next couple you need to think about trees and the branching of a tree structure. The simplest way to show this is a single picture of an expanded tree (visual aids are always good).
Third, I can delete a single snapshot. This deletes the moment in time that a snapshot represents, its differencing disk and any saved memory state. If a snapshot is ‘below’ this one on the subtree, then its reference pointers are modified to reference the proper snapshot ‘above’ it.
In this example I deleted Snapshot B.1
There are other things happening here as well. To maintain integrity of the snapshot timeline the differencing disks need to be merged. This happens in the background when a VM is powered off and I will save the gritty details for another post.
Fourth, I can delete a snapshot subtree. This deletes the moment in time that a snapshot represents and any other snapshots that are ‘below’ it in the tree. Thus it does what a delete does, but without selecting individual snapshots, it takes an entire branch. Yes, we get a merge, not a revert as I mistakenly put in my graphic.
Now, to get started on the really complicated post..what happens under the hood.
I have alluded to this before with the instructions about how to manually merge VHDs. Maybe I need to back up even more and talk about differencing disks...hmm..
5 comments:
Hello, I've been using SCVMM 2K8 for a while and have a litle issue with the checkpoints, when I restore a VM to a previous state it looses the SID, just like when you create a new VM, but I'm not creating one, I'm restoring to a checkpoint (or to the original state of the VM before creating the chackpoint). So the Active Directory detects the VM as a new one and causing many problems. Could you help me? Thanks.
What I am guessing is happening is that your kerberos ticket for the OS in the VM is expired.
This is one problem with taking one entity back in time but not being able to take all entities back in time.
Periodically a domain joined machine and the AD domain controllers negotiate and set the security ticket of the machine.
Over time this is changed as it is re-negotiated (much like a user logging out and logging in again). This is to prevent something from simulating the authentication ticket of a machine.
If you roll back the VM it is using an older ticket than AD thiks it should have, thus AD considers that authentication ticket as being 'faked'.
The old soulution is to unjoin the machine fromt eh domain and re-join the machine to the domain. Every now and then it is required to unjoin, delete the computer account, and re-join to get teh domain controller and the machine to get back in sync.
There is no magical solution.
BrianEh:
Thanks for your help, I did research about AD Tickets and your comment makes sense. Now, I know the AD Tickets "expire" after certain time, and if I take the snapshot (or checkpoint) and restore it some days/months later the ticket will be expired for sure... But, If I take the checkpoint and restore it right after taking it, the ticket should be the same, is that right? Well, I just did that test, and still have the exact same problem, the SID is changed.
If the VM is a Domain Controller, what can I do?
If the VM is a domain controller you just highly complicate the world. All entities that depend on the Domain Controller must roll back to the same point in time as well (to have a stable environment).
And taking a snapshot should not result in a SID change unless the machine is being generalized in some way, such as with newSID or sysprep.
The SID should remain.
This has been very helpful. I'm not sure who at Microsoft writes the messages that it gives when dealing with such things as snapshots but your article has helped.
keep up the great work
Post a Comment