For whatever reason the xxxxx#.vmdk files still appear in the datastore. I have been following several threads in an attempt to get the snapshots consolidated. I have created a snapshot and then done a delete all using the snapshot manager. I have tried this several times as a matter of fact. I just recently tried it again with quiesce guest file system selected. Nothing has worked. In addition anytime I try to pulI vmdk files down the connection times out. It's been a bit nerve racking; I would very grateful for some advice.
No matter what I do the files are still there. Now for some specs...
Running: ESXi 4.0 Build 171294
I have over 600 gigs of free space in the datastore.
See attached log file on the VM I am trying to consolidate
See screenshot below as well.
There's an error 5 (Access Denied) error message in the log file, but unfortunately it doesn't show a file name!? Do you have an image based backup application in place, which creates snapshots?
What you could try, is to restart the Management Agents, take another snapshot and then run "Delete All". Caution: If you have automatic startup of VMs configured, don't do this, because it will shut down the VMs.
Another option would be to consolidate the snapshots manually by cloning the virtual disks. If you want to go this way, please let me know and I will provide the steps to do this. In this case I need to know the current virtual disks names from the VM's HDD settings (I assume these are the 000009.vmdk files).
André
Wow...thanks for the quick response. I am not sure about the image based back up...I will be checking into that in a minute. This is a development environment. I can do what I want to the setup, at least for today. Nobody is relying on any of the VM's for now. The manual approach I think will be fine. Yes the 000009 series are the current disks. Just so you know I am pretty new to all of this, I recently inherited this setup.
The following manual approach will not modify the current files. Anyway, if something does not work as expected please stop and report back.
1.) cleanly power off the VM from within the OS (don't suspend)
right click the VM in the inventory and select "Remove from Inventory"
2.) login to the command line (or SSH) and change to the VM's directory
cd /vmfs/volumes/4b6aa70a-eec1013e-dbae-0026b9532a04/Astro
3.) create clones of the virtual disks (on the CLI)
vmkfstools -i ScoobyDoo-000009.vmdk ScoobyDoo-Clone.vmdk
vmkfstools -i ScoobyDoo_1-000009.vmdk ScoobyDoo_1-Clone.vmdk
4.) backup the original files (from the Datastore Browser)
create a new sub-directory in the VM's folder (e.g. "old")
move all .vmdk files (except the new ...Clone.vmdk files) to this new directory
move the .vmsd file to this new directory
5.) rename the clones to the original files (on the CLI)
vmkfstools -E ScoobyDoo-Clone.vmdk ScoobyDoo.vmdk
vmkfstools -E ScoobyDoo_1-Clone.vmdk ScoobyDoo_1.vmdk
(the commands are case sensitive, make sure this is an upper case "-E")
6.) backup and then edit the VM's configuration file using the vi editor (on the CLI)
cp ScoobyDoo.vmx old/ScoobyDoo.vmx
change the virtual disk names to:
-> scsi0:0.fileName = "ScoobyDoo.vmdk"
-> scsi0:1.fileName = "ScoobyDoo_1.vmdk"
7.) add the VM to the inventory (from the Datastore Browser)
right click the VM's .vmx file and select "Add to Inventory"
If the VM works as expected and containls the latest changes, you can safely delete the "old" folder and its contents.
André
FYI, no image based backup that I can tell. I am pretty sure there is nothing external either...in other words directly backing up stuff at the ESXi box level.
The clone really seems to be process intensive. Quick question: I get this "Clone: 1% done." message and the new file seems to exist with the right size. I just want to make sure that was right. I was kind of expecting a percent count down to 100% or something. No worries, I am moving ahead if I don't hear from you. Appears I forgot to remove the VM from inventory initially...I think its working correctly now...at least it is for the second disk.
Ok cloning the scsi:0 drive failed with this: Failed to clone disk : Input/output error (327689). I found this post from you: http://communities.vmware.com/thread/316039 do you think its the controller cache policy of the RAID card? Any other ideas? I will try to look at the RAID config while I wait to hear from you. Again...thanks for your knowledge share on all of this...I am respectfully thankful!
FYI the scsi:1 clone was successful!! Thanks.
Not sure what this is, maybe a disk issue!? Do you have any vendor tools to check the disks?
What you could try is to reboot the host to ensure it's not a process which - for whatever reason - locks a file!?
If nothing helps you can try to find out which snapshot file causes the issue by trying to clone the disks in the reverse order of the snapshots. In your case the snapshot order corresponds with the file names, so you could try to run:
vmkfstools -i ScoobyDoo-000009.vmdk ScoobyDoo-Clone.vmdk
if this fails try:
vmkfstools -i ScoobyDoo-000008.vmdk ScoobyDoo-Clone.vmdk
and so forth.
Depending on what's on the C-Drive you may be able to restore the server with an older snapshot of this disk!?
André
I don't have any vendor tools that I know of...I have tried rebooting the host, which did not seem to work either. I will try the reverse order technique this evening after COB. Again thanks. I will let you know the outcome of course.
I worked through the whole chain. Not one of them worked. Each failed the exact same way. I noticed one of them now says ScoobyDoo-000005-delta.vmdk. I am not sure what to do with it. I am trying to move the whole chain to an NFS share now. I figured if I can not get the clone to work, at least I can run it with all of the snapshots. I tried moving the files so many different ways but it keeps timing out. Seems I am running out of options.
Earlier in this thread I mentioned I was able to successfully clone the secondary drive. Well thankfully thats where the data we cared about was, so I moved that clone over to a new ESXi box and spun up a new server. At this point I consider this thread finished. I want to thank you Andre for everything. I trully appreciate your help.