• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 28 subscribers
  • Views 11128 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VM Export Failing "File or folder already exists"

CoreyvsWorld
over 7 years ago

Hi all,

I've been demoing the rapid recovery software for a couple weeks now and the one issue that has been absolutely killing me is setting up a virtual standby.  I can create the initial image with no issue and am able to work on the VM, but it continually fails doing the exports when I push a snapshot giving the following error:

 

Task 'Create virtual machine' failed: Cannot complete the operation because the file or folder /vmfs/volumes/5911bb9b-e8cc1f68-050b-2c768a4f1954/ALMO-EXCHANGE/ALMO-EXCHANGE.vmx already exists. For more details open events on ESXi host/vCenter

 

I can't seem to find anything on this so any help would be amazing!  Thanks in advance!

Parents
  • 0 over 7 years ago
    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.
Reply
  • 0 over 7 years ago
    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.
Children
No Data