Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 6624
  • Last Modified:

VM has multiple vmdk files in datastore..

So I'm not really sure what is going on with this VM but it looks like every time I delete a snapshot it creates an additional vmdk file as opposed to consolidating down to a single vmdk.

Any ideas on what is going on / how I should go about resolving this?
(see attached file for image of datastore)

Running:
VMWare ESX 4.0
This-is-what-my-data-store-looks.doc
0
ASB_Tech
Asked:
ASB_Tech
  • 10
  • 10
  • 4
1 Solution
 
coolsport00Commented:
So, if you go into Snapshot Manager and choose to "Delete All", do all the snapshots delete, or does nothing happen? You have a WHOLE BUNCH of snapshots listed there, so it would take a while for the snapshots to commit to the parent disk, then delete.

~coolsport00
0
 
ASB_TechAuthor Commented:
Guess I had a typo in the original post...

Yes I was hitting 'Delete All' in the snapshot manager.  In the past all I would need to do is create a snapshot & then hit the Delete All from SM and it would consolidate all of the individual vmdk's to a single one.  However, it not only appears to not consolidate the vmdk's but it adds another one to the end of the list.
0
 
coolsport00Commented:
Hmm...ok; so it seems you're having issues with Snapshot Mgr committing your snaps. And you are correct, if you just create a new snap, then go into Snap Mgr and Delete All, it 'should' commit, then delete ALL the snaps listed. You can try 1 of a few other things. Use cmd line - see KB here: http://kb.vmware.com/kb/1002310; or you can try Cloning the VM (assuming you have vCenter Server; see here: http://kb.vmware.com/kb/1007849); or, you can use vCenter Converter Standalone (http://www.vmware.com/products/converter/), both of which (Clone & Convert) would commit and remove the snaps.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Download VMware vCenter Converter here, and complete a V2V.
http://downloads.vmware.com/d/info/datacenter_downloads/vmware_vcenter_converter_standalone/4_0

VMware vCenter Converter Standalone 4.x Documentation
http://www.vmware.com/support/pubs/converter_pubs.html

VMware vCenter Converter Standalone 4.3 User Guide
http://www.vmware.com/pdf/convsa_43_guide.pdf
0
 
ASB_TechAuthor Commented:
OK well it looks like there are some viable options there.. I'm most inclined to try the cmd prompts on the ESX but will need to wait until users are least affected by my tinkering..

Here's something interesting though, when I checked to see what delta disk the VM was using I came across this:

Hard Disk 1 - Disk File - [DatastoreXX]ServerName/ServerName-000004.vmdk
Hard Disk 2 - Disk File - [DatastoreXX]ServerName/ServerName_1-000021.vmdk

Why would the two HD's be pointing to different locations?
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
that's normal, that both disks have different filenames, but what is odd, that the snapshots seem out of order.

they should both be 4.
0
 
coolsport00Commented:
You have more than 1 volume/hard disk on the VM, correct? As such, when a snap is created, they are separate. It's hard to say exactly why they're pointing to the number snap that they are, but otherwise pointing to -xxx and _1-xxx is 'normal'.
0
 
coolsport00Commented:
Try the cmd line option when you're able and report back if that resolves it. If not, try the Clone or Convert option...
0
 
ASB_TechAuthor Commented:
Yea, I know that multiple HD's will create the -xxx & _1-xxx, that's not what was odd to me.

What's odd is why HD1 went from Exchange.vmdk to Exchange-000004.vmdk  &  HD2 is working off of Exchange_1-000021.vmdk...  I would have thought they would both be on 4, although I'm not sure what exactly happened to xx01, xx02, & xx03 for HD1..

I'll give the cmd line option a go this Saturday (earliest I can get it done) and see if I can make any headway on this.
0
 
coolsport00Commented:
I agree; that is odd. But, that could just have something to do with you creating multiple snaps and then when going to delete them in Snp Mgr, it not working correctly. Do you have a VM b/u utility (Veeam, vRanger) that runs against the VM? Those create snaps when the jobs run, but then "should" remove the snap once the job is complete. But, I've seen where the snap isn't deleted upon job completion (using Veeam).
0
 
ASB_TechAuthor Commented:
We are using Veaam's B&R to b/up our VMs. The only issue I have seen with our b/u is that sometimes (rarely) will leave a leaflet off the VM called a 'Consolidate Helper-0', or something similar to that.  I'm not entirely clear on what that Helper does but once in a while I will see one on a VM.
0
 
coolsport00Commented:
Yep, you do get that. That is the snap that Veeam "leaves" on the VM. You can remove that. (commit/delete) That is supposed to be removed, but sometimes it doesn't remove it. If you see that, let Veeam know so that can resolve why that happens (the engineers let me know to contact them whenever I notice the behavior)
0
 
ASB_TechAuthor Commented:
I'll keep that in mind to contact them the next time I see that happen..

I'll also post back here after I give the cmd option a try (hopefully with good results)

Thanks for the help guys.
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
If you are using vCenter, set up alerts to Warn you of Leftover Snapshots!
0
 
coolsport00Commented:
No prob...awaiting your results...
0
 
ASB_TechAuthor Commented:
The cmd line fix did not resolve the issue I am experiencing.  I'm going to contact VMware support to see what they recommend

I will post back with the solution when I figure out what that is.
Thanks for your guys' help on this.

ASB_Tech
0
 
ASB_TechAuthor Commented:
VMware support recommended that I clone the VM to a new datastore.  Due to the nature of this server I will need to find a maintenance window that causes the least amount of interruption to my end-users... not sure when that will be exactly, but I will post back when I have more information.
0
 
coolsport00Commented:
Yeah, that was one of my 1st recommendations (see the KB I posted: http://kb.vmware.com/kb/1007849), but there would be slight downtime once the VM is cloned (powering down old VM, verifying cloned VM is config'd correctly, etc.). Again, keep us posted on how it goes. Thanks for the updates @ASB_Tech.

~coolsport00
0
 
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Personally, if it's not affecting service, I would put it on the "back-burner" until the next maintenance Window for the VM. (e.g. next patch WIndow, Memory Upgrade etc).

What you need to establish, is how it occured.
0
 
ASB_TechAuthor Commented:
Looks like this is going to get back-burnered for a few more days.. I may come in over the weekend to run the cloning process but other projects got in the way of available time this week to do this..

I'll post back sometime next week.
Thanks,
ASB_Tech
0
 
ASB_TechAuthor Commented:
Looks like the cloning process via ESX-command line interface did the trick!  It was a bit tedious checking the snapshot tree as the chain had gone up to 67 in total.. but after checking it ran the cloning process without incident & it looks like we haven't lost anything in the process!

An added note:
The massive number of snapshots that had collected on 'servT'  caused a Stack Overflow error in Vcenter.  This error prevented the VMWare VirtualCenter Server service from starting thus rendering our Virtual Center inaccessible.  We were still able to access all Vm's by logging in to the individual ESX hosts via VSphere but without the connection to Vcenter several management functions were not available.  Cloning the afflicted HD to the new datastore & pointing servT to that resolved these issues.

2nd Note:
I have not tried to create & remove a snapshot from  this server as of yet (very important server & I don't want to tinker with it during business hours) but hopefully the cloning process will have cleared up that error as well.

3rd Note:
I am planning on migrating the config file & the rest of the information that is pertinent to the new Datastore this weekend.  After which I will do a little 'clean-up' on the delta files in the old datastore.

I will do the solution/points once I get a chance to do the snapshot test.
Thanks for all your guys' help on this!  
ASB_Tech
0
 
coolsport00Commented:
Thanks for the update. Continue letting us know how it all goes.

~coolsport00
0
 
ASB_TechAuthor Commented:
Looks like things are running smoothly once again!  ServT is up & going as if it never missed a beat and it has had several snapshots taken/removed & we have not run back into the delta file issue we had previously.

This is a big check mark off of my to-do list, so I appreciate the help!
0
 
coolsport00Commented:
Glad you're back up & going!
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 10
  • 10
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now