Replication question

[trickybits]

Hi Veeam folks,
First of all I'm extremely happy with Veeam and it has saved us on a couple of occasions already.
Since I'm new to this I'd very much like for someone to explain a couple of things or point me in the right direction.

We have used replication to migrate VMs from one datastore to another (where vmotion is not available). Manually removed the replica from inventory, moved it out from the VeeamBackup folder to the datastore root, and then registered the VM. So basically we've turned replicas into active VMs. I'm not sure if this is the feng shui way of doing things.

Typically, turning a replica into an active VM in this fashion leaves the VM folder packed with files like .vbk and .vrb. So, as it's technically no longer a replica, can the vbk and vrb's be removed?
There's also an exact copy of the vmname.vmdk file called vmname_working.vmdk which I'm not sure why it exists or even if it's Veeam that created it. What is this file and once again, can this file be removed?

Thanks in advance

[Gostev]

Hello, yes you can remove .vbk and .vrb files - these are no longer needed if your VM is no longer a part of replication job. I would not recommend deleting _working.vmdk file though. This is auxilary file Veeam replication engine uses, so it is no longer needed. Essentially, it is a descriptor file pointing to an existing VMDK (nevermind the displayed size, it is really small - datastore browser simply shows the size of VMDK this descriptor point to). I am afraid that deleting this file through datastore browser will drag actual flat VMDK along. I have already asked devs/QC to determine and test safe way of removing this file, but they are very busy right now pushing v5 out, so this research would have to wait a little. So for now, it would be safer to just leave it this file alone there - again, it does not eat any disk space despite of what datastore browser shows. Thanks!

[trickybits]

Thanks for these answers Gostev,
I can check on a lab-VM to see how the VM is affected by removing _working.vmdk in the datastore browser.

[trickybits]

yep, removing the vmname_working.vmdk in the datastore browser will also delete the vmname.vmdk

[wdbarker3]

You can remove the _working.vmdk, but NOT using the VI Client. Just use the console, cd to /vmfs/volumes/<DATASTORENAME>/<FOLDERNAME> and do a ls -als to see what's there. If you remove using "vmkfstools -U machinename_working.vmdk", you will kill the real file, just as the VI Client would. However, if you "rm machinename_working.vmdk", you will delete only the Veeam file, and not the underlying machinename-flat.vmdk, on which the VM relies. Do a "cat machinename_working.vmdk" and compare it to a cat "machinename.vmdk" to see they both refer to the same underlying flat file. The working file uses a single head and a bazillion cylinders to simplify math, I guess. The base vmdk file uses a more realistic number of cylinders and heads.

[Vitaliy S.]

Dan, thanks for sharing this info.

[eliseocd]

Another way to remove the _working.vmdk file is going to <DATASTORENAME>/<FOLDERNAME> from Veeam Backup itself. Before doing that you must add the ESX servers (or VCenter) to Veeam.

From here you can edit _working.vmdk, rename the line with machinename-flat.vmdk to machinename2-flat.vmdk or whatever. Save changes, and now you can remove safely the _working.vmdk file.

Anyway, I think that Veeam Backup should have the option to do that a replicate VM can be handled from VI Client definitely, extracting it from VeeamBackup folder and so on.

[Gostev]

And we think so too