So, in theory, if you want to go back to "prior state" you would "revert". It simply cleans up partial or duplicate logs and/or. Consolidate won't change the number of snapshots you have. "Consolidate" would clean them up, probably by removing the redundant ones. For example, if a snap fails, you an have redundant logs and perhaps. vmdks from failed past processes and has nothing to do with the disk changes. "Consolidate" really has nothing to do with which choice you want to pursue consolidate simply consolidates redundant logs or. In this approach the term "current snapshot" is kind of misleading but think of it as the state before the snapshot.Ģ) Delete the snapshot which accepts all of the changes you have made since taking the snapshot and rolls them into the running VM. In VMware, you can do two things with a snapshot (I'm simplifying somewhat) ġ) go back to "prior state" (the way it was BEFORE the snapshot), which is the "revert to current snapshot".
To revert to the original, you simply pick "revert to current snapshot" from the right click menu, assuming you only have the one snapshot. I'd have to move off all the VM files first, then restore a backup which would take many hours so I'd rather avoid that if possible. It also has about 1TB of data and not enough free space on the data store to restore it all. VM is a Windows SBS box (which has both Exchange and AD). Thanks to anyone that can offer some advice. vmdk files will be in read-only mode though - is there a way I can set them back to read-write? REDO_nSGail extension that I assume I would need to move too).
Is there a supported way to delete these unwanted delta disks without consolidating them?Ĭould I simply move the diskname-000001.vmdk files elsewhere then boot the VM? (I also have some files with the. I can't find anything about deleting the unwanted delta disks to revert to the original. Has anyone been in this situation before? I've done lots of reading but have only found articles explaining how to fix the "needs consolidation" error by consolidating. That made me suspect the defrag may have completed, but alas it wouldn't mount.Īt this stage my preference would be to revert to the snapshot. The Exchange database is now ~160GB (down from about 240GB), which is about the size I expected it to be after the defrag. I answered the question and chose Abort/Cancel. When I woke up today the server was offline, and when I opened vSphere I saw the message "Configuration Issues - Virtual machine disks consolidation is needed". Last night I took a snapshot of a VM before adding a new disk and running an offline defrag of Exchange (using the newly added disk as the temporary path).
0 kommentar(er)
