Need to save contents of redo logs on nonpersistent disks

[fantasticdan]

I've inherited a few VMs with nonpersistent disks set but i need to have this data written to disk somehow.  How can i go about doing this?  I'm happy to drop to the command line or similar but i can't lose the contents of the redo logs so i can't power off the vm.

[continuum]

To play this safe every action that powers off rthe VM is tabu.,
So I would recommend to add a disk instead and use tools like rsync (Linux) or robocopy (Windows) to copy the data you need to keep to the newly added vmdk.
Another quite ugly approach is to force the VMs from inside to write everything thing to disk.
Then leave the VM in idle state for a few minutes and suspend it.
Once the VM is suspended you can remove the nonpersistent flag and treat the redo-log like a normal snapshot.
This approach is rather advanced and you should only try this road if you can handle the required vmx-file changes and eventually renaming of the redo-log files.

[fantasticdan]

Thanks for replying.  What would be the process for forcing it to write the redo logs?  I have one less important vm I could test the process with.  I haven't found any response in a Google search.

I know you can for example edit a vmx  to discard snapshots etc but I don't know how that would work in this case.

Is it a case of suspending the vm going to disk properties, set it to persistent and it will try and write the redo logs?

[continuum · Accepted solution]

> What would be the process for forcing it to write the redo logs? 
Linux Sync Command
Sync - Windows Sysinternals | Microsoft Docs
> I know you can for example edit a vmx  to discard snapshots etc but I don't know how that would work in this case.
Be very careful here - one mistake and the redo-logs are gone !!!
I once was in the same situation and figured out how to work around the automatic delete of the Redo-files using the suspend approach.
If you are worried - lets do one sample VM together.
Call me via Skype and give me access via Anydesk.
Steps:
1. use sync-tool from inside the guest
2. wait a little bit
3. suspend the VM
4.remove  VM from inventory
5. remove the non-persistant flag for each vmdk (requires vmx-file editing)
6. remove the reference to the vmss-file (requires vmx-file editing)
7. rename the redo-log vmdks so that they follow the naming conventions of regular snapshots
8. check parentFileNameHint and CID references in the vmdk descriptorfiles
9. doublecheck filenames and entries in the vmx-file
10. register the VM again
The VM will behave like it was shutdown hard - like after a power-failure. (That should be harmless if you used sync in step 1)
I know that this looks quite ugly - but I am not aware of another approach that I would consider to be safe.
If you call in the next few minutes we can do that right now.
If not - I will be back home in 2 hours.
Ulli
By the way - it would be nice to document the procedure with some screenshots - this is useful stuff for my vm-sickbay.com blog ....

[fantasticdan]

K, i did a quick and dirty test witha new VM to test a process.

If i suspend a vm, go to the vmx i can change the drive type from independent-nonpersistent to independent-persistent.  Save the vmx.  It then says there are redo logs to be written wen i unsuspend it and it writes them.  Effectively a vm disk consolidation.  That seems to work the quick and dirty test vm unsuspends.

I'll test more thoroughly tomorrow, thanks for pointing this out to me though, was in a right pickle how i was going to fix this this has been the best option so far by a mile.

[continuum]

Good
so all the hazzle with renaming the Redo-logs is not even necessary ?
Ulli

[fantasticdan]

Just to confirm I have done a couple of these now.  The process is:

suspend the virtual machine

download the vmx file

open it and delete the non part from independent-nonpersistent

save the file

upload it to the datastore again

power on the VM

at the vm question select commit logs.

It'll then take as long as it takes to write back the changes to the now persistent disk before it un-suspends the VM.

Cheers