VM Export Failing "File or folder already exists"

Greetings. I'm curious what do you mean by this part for your process:

I can create the initial image with no issue and am able to work on the VM

Are you turning on the standby VM and working on it, configuring it, using it as it if it was live? The VS is a clone of the protected node, it's purpose isn't really meant to be on/working/live, and if it was powered on the next time you would go to do a virtual standby it would either provide you with an error message similar to what you listed, or that it was locked.

The other issue is that if you powered it on, and then DRS kicked in for your environment, then the VM would no longer be where it was when we left it last, so the core would try to create a new one, and then your VC would throw the error that it already exists (cause it does). To remedy this piece of the puzzle however, if you use DRS, disable the standby VMs for DRS.

I may have overstated a bit. Once the initial one-time export is complete I was able to power on the VM and log in to confirm that it was working.

This has definitely given me a lot of information to work with, but also leads me to a few questions.

When we do a virtual standby, assuming we disable DRS for it, are we able to power on the VM at all without messing anything up? The scenario that was brought to me by a coworker was what happens if our physical device dies so we have to run off the VS and then we get the physical device working again, will there be issues with the export after that?

As I really had nothing to go off of one thing I tried was renaming the .vmx file to .vmx.old, I pushed a snapshot again and it seems like the export is running. Did I just cause myself more issues doing this?

No problem. By all means you can power on the VS to make sure it boots properly and such. If you were to watch the VS passes like a hawk you will see that there is a hanging snapshot left on the VM after the job finishes and upon the next pass that snapshot is reverted and then a new one taken which we write to, and then that is committed and a new one taken and the process continues. That is so if/when you do power on the VM, you do not change it and it is then dis-similar from the source. This is also why you can't log into it and setup a static IP or anything preemptively and that info will be purged (but that also leads me into that since it is a new VM it will have a new MAC on the virtual NIC and when you 'cut over' to it, you'll need to re-specify the static IP).

For the situation you describe, there will be a disconnect of your changed data. So honestly you'd either want to schedule a downtime and do a restore back to the physical otherwise you'd have to scrutinize which files are where and what changed. Assuming you are doing agent based backups, once you cut over to the virtual standby your backups will continue. So the VM will start backing up as the primary. Once the hardware is functional again you can schedule a downtime, do 1 final backup on the VM, and then do a restore through RR back to the physical.

You won't harm anything by the rename, usually you can just delete from disk as we are going to push a fresh copy of the VM out.

Thank you so much for all your help on this Phuffers! You've definitely gotten me a lot further than any of my prior research. If I'm still having issues after trying a few things I will certainly be coming back here.

I don't know if you use reddit, but if you do I would love to gift you gold!