Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Using VMware Server ESXi (freebie version)

I have a Virtual Machine (win 2k3 r2 server). When I first provisioned it I took a snapshot of it. I recently tried to clone the primary drive using my standard hardware-based method to grow a windows disk. (using knoppix, clone drive to a new drive, make it bootable, then I intended to extend the partition via diskpart from within windows). This process failed; I tried setting the cloned drive (via the vmware gui) to replace the original drive, boot and be done. This didn't work out so well. The machine never booted. I checked the boot order, the disk location and all the basics I usually do.

As a failsafe, I then tried changing all the settings back so the machine would boot to the original drive and I could figure out (as I eventually did) a better way of growing the disk. However when I powered on the machine with the original drive, it reverted back to that initial snapshot I created; It lost all the changes since.

I looked in the file system and found a few files, I think the keyfile here is one named "delta" and I'm assuming that's the disk I want, but I can't find a way to have the Virtual Machine actually use that drive/file. It isn't available to add when I go to add an existing drive.

Do I need to somehow commit that delta to the original drive and then boot from it again? Can you point me in the right direction?

I've since discovered the proper way of growing drives using "vmkfstools" but I need to get back to the original state of the machine to try this out. Any help would be greatly appreciated.

share|improve this question

3 Answers 3

You may be out of luck but if you don't have a backup it may be work taking a structured approach to this.

With the VM powered off make a copy of all the files in the VM folder and put them away somewhere safe, they may be damaged but you want to have a complete copy in case you want to start over.

From an SSH shell or with an SCP utility (Veeam FastSCP or Tunnellier are handy if your using Windows) locate the VM folder and find all of the files with .vmdk extensions. There should be two for the base disk (a small descriptor file called VMname1.vmdk and a much larger file that contains the actual disk data called VMname1-flat.vmdk) and a similar pair for each of your snapshot delta's (a small descriptor called VMname1-00001.vmdk and a larger file called VMname1-00001-delta.vmdk that contains the changes made to the base disk during the lifetime of this snapshot). These are also referred to in the snapshot management file (the VMname.vmsd file) that contains all of the metadata about all active snapshots on a VM. The Virtual Machine itself has all its settings stored in the .VMX file including (importantly) the reference to the location of the current active VMDK for it's disk(s) - this will point to the latest snapshot delta.

VMware then uses internal ID's (called CID's) and a parameter called the ParentFileNameHint within the descriptor VMDK's to link each delta back to its parent (which may itself be a delta) recursively until it gets to the basedisk. A -delta on its own is not a complete disk it needs to be linked to an unmodified copy of its parent in order to work. If the parent file has been modified you are almost certainly out of luck.

You can manually move the delta files and their associated descriptor and fix scenarios where things have gotten lost but this will only work if no changes have been made to the base disks or any intermediate deltas. The descriptor files can all be edited with a text editor.

Once you have gotten your head around this you should read SANBarrow's CID chain repair guide that will help you figure out how to stitch things back together if they can be stitched back together.

Finally - never rely on Snapshots as Backups. They are not suitable for that purpose and they cause a significant additional IO overhead when active.

share|improve this answer
    
I think this answer is spot on... I need to check and confirm the details. I've already made a copy of all the files on there so I'll now be checking out the CID repair guide. I'll post back as I progress through this. I was affraid to read something like this: "If the parent file has been modified you are almost certainly out of luck." I think by definition, the moment I powered the system back up it must have been modified to some degree, just by turning it on but I'll give the rest of your answer a try for sure. Thanks a lot! –  Oscar Gonzalez Jun 3 '10 at 19:42

Usually the delta file is a file that is created when you replicate a disk, and possibly with cloning. The delta is just a 1 off file that stores all changes made to a live VM, not powered down, as it is being copied. Upon exiting the clone, replicate, etc... the delta (changes) is written back to the live VM. I don't think you can revert back to a delta since it is + changes.

Side note: You are talking about growing a disk also using vmkfstools... but this won't work with a non-dynamic disk will it? I am pretty sure your diskpart and/or vmkfstools will only work with a dynamic primary. If you can just create a new disk and add it to the system.

share|improve this answer
    
Well, I'm trying to get back to an original state before I tried cloning the drive without using vmkfstools. The drive isn't dynamic, but I was attempting to clone it like I would clone a hard drive based drive. I can't just add a new drive because this is the OS drive, I need to "grow" it. I think I found the way to grow it properly. However the delta files are usually created, it seems that my changes (applications installed, new files, etc) tthat I've worked on since that initial snapshot are in that delta file. I'll include a listing to make myself more understandable. –  Oscar Gonzalez Jun 3 '10 at 18:03
    
Growing disks will work with non-dynamic disks under Windows- the main problem is that Windows 2003 doesn't allow you grow system disks with its native tools so you need to use some third party mechanism. –  Helvick Jun 3 '10 at 18:27
    
You can extend disks natively with windows 2003 server after you've grown them. Same thing as cloning a physical drive to a bigger drive, then extending Windows FS to use that newfound space. You're right, you can't grow natively, but you can extend natively; Using a utility built-in called diskpart. –  Oscar Gonzalez Jun 3 '10 at 19:44

VMware snapshots work by writing all changes to the disk from the moment you took the snapshot to a new file, the delta file. When you revert to the snapshot, the system simply deletes the delta and bam, you are back to the pre-snapshotted point. If you delete the snapshot, then the system merges all the changes to the original file, which can take a long time if you took the snapshot long ago.

Your question isn't particularly clear on what you did to the files on the host, but since it sounds like the system already reverted the snapshot for you, you are probably out of luck, since the host no longer thinks that the VM has a snapshot. Here is what I would try though:

  1. Implement a policy of making backups that doesn't rely on snapshots.
  2. Power the VM off.
  3. Copy all the files to a safe place.
  4. Try deleting the snapshot.
  5. See what happens. If step 3 didn't do what you wanted, proceed to 5.
  6. Take a new snapshot.
  7. Copy all the delta files from your backup on top of the delta files that are created by step 5.
  8. See what happens. If step 6 didn't do what you wanted, accept fate and start trying to restore what you lost.

Good luck, --jed

share|improve this answer
1  
This wont work - VMware uses internal ID's to track the relationship between parent VMDK's and snapshot-Delta files so simply dropping the delta's into a folder and possibly renaming them wont work. –  Helvick Jun 3 '10 at 18:33
    
@Helvick +1 Thanks. That is what I suspected, but it is something I would have tried without knowing for sure. I think basically Step 1. and Step 8. are the only ones here that are worth anything. –  Jed Daniels Jun 3 '10 at 19:27
    
Thanks for the answer, I knew it would be a little bit unclear because I'm a little unclear on how this happened to begin with but with some of your responses I think I can move along a bit further. Thank you for the suggestion on the policy for backups. I'll look into that as soon as I clear this up. –  Oscar Gonzalez Jun 3 '10 at 19:45
    
I had in fact given up the idea of restoring this and was going to move forward with recreating things from backup but if there's a chance I can roll back to it initial state, its worth the time. TY again. –  Oscar Gonzalez Jun 3 '10 at 19:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.