VMware Cloud Community
thorntonm3
Contributor
Contributor

How to recreate a machine that has a missing VMX file and 2 exiting vmdk files with snapshots

I have a virtual machine that I can no longer see in my VC 2.5. The good news is that the vmdk files (along with 4 snapshots), are sitting out on a VMFS partition on my SAN. I feel confident that no data has been lost and that I just need to perform the right steps to get the machine going again. The bad news is that the machine is missing its .vmx file. Not sure how that happened, but its gone. I do have the vmware.log file. Saw one post that mentioned recreating the .vmx file from that .log file but it looked dicey.

I need to get this machine up and running again as quickly as possible (Exchange server). I have two questions:

1) Is it ok to create a new VM and simply add my existing vmdk files to the machine? The New Machine wizard allows me to do this, but I want to make sure the data in the snapshots is taken into account. Will the new machine know that snapshots exist?

2) I want to make sure I have a backup of the machine/folder on the vmfs volume. Is there a way to copy intra-vmfs volumes without bringing the files out to local disk and then back again? Its about 200GB and takes forever to copy that way. I have another VMFS volume I could copy to.

Thank you for any ideas!

Reply
0 Kudos
10 Replies
lamw
Community Manager
Community Manager

Yes, we've done this before. Basically, you'll want to make a backup of your current VM in question (.vmdk, -flat.vmdk, delta-0000x.vmdk) just to be safe. What you can do, which is what we did was create a new VM through the GUI and use an existing VMDK disk, this will link to your .vmdk file which will have references to your actual disks which are -flat.vmdk files. Once the VM has been created, it's registered by ESX/VC and it'll see the delta files for the snapshots. Again, you would have backedup your directory, but this will not modify any of your files, your VM will get a new UUID as it's being registed by ESX.

kjb007
Immortal
Immortal

To answer the second question first, yes, you can copy files on vmfs as any other filesystem, if you have the space available. Open a service console connection, and cd into the datastore folder. Then, create a new folder and simply cp all of the files from one folder into another. Alternatively, you can create an archive of those files. To do that, once you're in the datastore folder, run 'tar cvf vmname.tar vmname' That will create an archive named vmname.tar that you can have as a backup.

Do you have the .vmsd file in the folder as well? Those files link your snapshots to your disk, and without them, you will have an even harder time getting all of the snapshots back in order. If they are there, you are in better shape. After you create your backup copy or your archive, create a new vm and with the same name as before and add the existing disks, but use the highest numbered snapshot disk, as that will be the most current. The other delta files should be linked togher in their .vmdk file descriptors.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
Reply
0 Kudos
thorntonm3
Contributor
Contributor

Thanks to both of the above for good info. I'm still copying (and will be for a few more hours) to get a good backup before trying anything. I'll be sure to give credit once I am able to try the suggestions.

Two clarifying questions:

1) When I create the new virtual machine and I add these existing VMDK files to the machine, which vmdk should I choose? The snapshot one, the base file or something else? Not clear on which one to pick.

2) If I don't care about keeping the snapshots, but just don't want to lose any data that occured after they were taken, is there any change to the recommendations above?

Thank you.

Reply
0 Kudos
thorntonm3
Contributor
Contributor

So, I made a backup of the old directory with my vmdk files on my local machine. I then copied this to a new directory on another vmfs volume. I then created a new virtual machine and added the existing disks in this volume to the machine. My problem was that it didn't let me choose the highest numbered file, only the baseline name of the file. When I booted, I was back several days ago. Granted - I now have a worst case scenario - I can be a few days back, but obviously not optimal.

I've attached a screen capture of the directory of files as they exist in my local backup. You can see that I'm missing the vmx, vmsd, maybe others.

Just FYI - I don't need the snapshots anymore. Would just like to get back to the most recent state and start it up. Do I need to merge the snapshots back into the base disk with vmkfstools or is there a way to just pick the correct version of the disk to run from? Any other thoughts?

I am now copying the original files back out to a new directory on my vmfs volume since I changed the parent vmdk when I booted earlier. Once this is done (few more hours), I think I'll be ready to try any suggestions.

Thank you.

Message was edited by: thorntonm3

Reply
0 Kudos
lamw
Community Manager
Community Manager

You'll need to choose the base lifeapp.vmdk (This is your disk descriptor file, which points to your actual storage *-flat.vmdk). This is what the .vmx will reference and then the lifeapp.vmdk will then reference your actual storage. From your screenshot, you can see that this VM has taken 4 snapshot, and all the .vmsn look to be intact, as kjb007 stated before, without your .vmsn memory state files it'll be harder to revert to any of the snapshot states. Hopefully this clears it up, so what you'll want to do is just load up the .vmdk and then revert back to your original baseline image, which you'll just do by going into the snapshot manager and you should see 4 level deep tree, just revert back to the original base at the very top. If you want to bring the VM to the last known or working state, then you would just load it up and it would be at the current snapshot of #4 which is your latest state. I would suggest just rollling back slowly to see exactly where you want to be, hopefully whoever took the snap hots were pretty descriptive about what changes were made.

Reply
0 Kudos
thorntonm3
Contributor
Contributor

I chose the base .vmdk, but when I booted I was back at a point in time prior to the snapshots. The snapshot window didn't show any snapshots available for me to jump to. Is that because I am missing the vmsd file? Is there a way to recreate that file? If not, would the highest numbered file be the latest snapshot?

As for the snapshots - I do know that they were created just prior to a number of server upgrades (exchange std to exchange ent, etc.). They were applied to the server and we never jumped back in time. Just kept running on the latest.

So - the only one I really care about it the latest snapshot. After a bunch of reading, I was going to run a vmkfstools -e lifeapp001-000004.vmdk <new folder>/lifeapp001new.vmdk command. I read here http://www.vmworld.com/vmworld/message/1967 that this should create a single vmdk file with the latest info in it. I would do it for each of the two disks with their latest snapshots. I was going to create a new VM and then use these two existing disks.

Do you think this might work?

Reply
0 Kudos
kjb007
Immortal
Immortal

Since you don't have a state file (.vmsd), you don't have an easy way to re-link your snapshots.

You need to use the latest snapshot delta disk as the disk you use to mount to your vm.

I would look at the descriptor files (.vmdk) of the deltas to see if they are in order of parent/child. Meaning, if you open a .vmdk file, it should tell you which other vmdk is the parent of that delta file. If they are all in order, meaning delta2 has a parent of delta1, then the last file, delta4, should be your latest file, and that is what you should have in your vm config file.

Use that and boot up. Once you're up, see if you are at the correct state for the vm. If you are, then we'll need to get rid of the snapshots. Go to snapshot manager, without the vmsd file, it should show you no snapshots. Create a new snapshot, and then delete it. This should clean up all of your snapshots and incorporate them back into the base vmdk file.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
thorntonm3
Contributor
Contributor

KjB,

That is a great suggestion. Didn't realize that I could edit the newly created .vmx file and just point it at the lifeapp001-000004.vmdk file. Should have thought through that.

I am about 40% done with doing the vmkfstools clone/copy (-i). Used the latest snapshot (yes - they are all just parent - child with no branches) as the source and set a new directory as destination. I think this is going to result in a single vmdk for each of my to disks that will have the latest snapshot data in it that I can add to a newly created virtual machine. Please let me know if that's not the case.

Thank you,

-TTM

Reply
0 Kudos
thorntonm3
Contributor
Contributor

See comment below from follow up after marking question answered.

Reply
0 Kudos
thorntonm3
Contributor
Contributor

All, thanks to all for the help with this issue. I ended up using bits and pieces of most of the suggestions and would probably have tried KjB's last suggestion if I hadn't been so far along with the vmkfstools clone work.

So, for others that have vmdk files with snapshots but no vmx or vmsd file, here's what worked for me:

1) First - do a full backup. I used mine a couple of times. Without this, I would have been out of luck as I tried various solutions.

2) Don't Panic (probably should have been #1).

3) As long as you are able to commit one of the snapshots, you should be in good shape. For me, all I needed was to end up with the last snapshot as my starting point.

4) Ended up using vmkfstools to clone the disks and used the desired snapshot vmdk as the source for the clone operation. Just used putty to jump onto one of my esx's service console. Command is essentially vmkfstools /vmfs/volumes/.vmdk. If you have more than one disk, as I did, you can console into another esx box and use its service console to issue the same command again on the next vmdk file. Just be sure to change the destination file name.

5) One nice thing about #4 was that you get immediate confirmation or erros or of successful clone start. The % complete shown is also accurate and doesn't jump all over the place. No time remaining is shown, but it's easy to extrapolate based on time it takes to complete each percentage point.

6) Once done, create a new virtual machine in VC. Choose the Custom configuration in the Add New Virtual Machine wizard and then choose Add Existing Disk when you get to that option. Be sure you choose the correct adapter (mine was Buslogic and ESX defaulted to lsilogic).

7) Make any other changes (network, etc.) and boot. Mine came right up and need no other config. Just worked. I felt very lucky.

So, thanks again. I can now go on vacation!

Reply
0 Kudos