Best way to replicate/copy templates between datacenters?

[stingray75]

Hi,

I'm trying to figure out the best way to replicate VM templates between datacenters. We have numerous templates which are updated by the Linux / Windows teams. They update the DR vCenter copy first (maybe updating the name with the new version number), then ask for it to be copied back to production vCenter once its confirmed everything is ok. We need templates in DR because we run dev/test out of the DR site.

What's the best way to do this with Veeam B&R - replication or VM copy?

I tried setting up a replication job, and this works quite well as it creates the VM in production and only replicates changed blocks. However, it doesn't work with templates so I have to convert them to VMs first, and convert back to templates afterwards which is fiddly.

I then tried a VM Copy job, which copies the templates directly to an ESX host in production. On first run I need to register the template in the prod vCenter, but I don't need to convert the templates to VMs and vice versa. Subsequent VM copies require no further interaction as it overwrites the production copy. However, if I change the template name in DR it will write as a new VM in production. As it's a VM copy it needs to copy every block every time, so takes longer than replication.

What's the best way, and are there plans for Replication to support templates?

Thanks

Matt

[Shestakov]

Hi Matt,

Template replication is a quite rare instance and Veeam B&R doesn`t have a special job for that.
What you`ve described is probably the best way to solve the issue.

You can also try to create a special folder on a datastore where all VM templates will be stored; then, create a File copy job, specify the folder you created as a source and remote ESX(i) host as a target and schedule this job to run on a required basis.

Such scenario guarantees that newly-created templates will be transferred successfully.

Thank you.

[veremin]

Additionally, you can probably write a simple script that will check whether there are more than one file in the given location and delete the oldest one(s). Thanks.

[dellock6]

You can also quickly convert the template into a proper VM, run the job you need, and convert back the VM into a template. Have a look here, I wrote this one to do a Storage vMotion, but it can be modified to run other tasks:ù

http://www.virtualtothecore.com/en/stor ... -template/

Luca.

[jimmyetimos]

Actually, template replication is quite oftenly used by any admins with multiple datacenters. It puzzles me as to why the Replication job would not accept templates - would it be such a big hassle to add it?

Also I have a couple of questions on the proposed solutions:

1. The VM copy job seems to accept a vcenter folder as a source so provided you keep all your templates in a folder wouldnt that copy any newly created ones?

2. I would imagine the File Copy job would not leverage CBT, but can anyone confirm that?

We are in the process of evaluation so we only installed veeam temporarily for testing purposes and currently have no testing bed, but I would appreciate any feedback. A lot of people I know with multiple datacenter locations do template replication for obvious reasons. We use a data domain replication pair for now, but even though this works extremely well at the replication level, VAAI cannot be used subsequently on deployments, so we would really prefer the templates reside in a datastore on our storage.

Thanks

[foggy]

1. The VM copy job seems to accept a vcenter folder as a source so provided you keep all your templates in a folder wouldnt that copy any newly created ones?

Yes, it would.

2. I would imagine the File Copy job would not leverage CBT, but can anyone confirm that?

Correct, file copy job is not incremental and performs a full run every time.

[jimmyetimos]

Actually, come to think of it VM Copy would not use CBT either, as each run would be independent and re-copy the whole vm, correct?

So, really only Replication jobs would pass just the changes.

Just checked VMware's replication appliance, and it doesn't do templates either. This seems pretty weird to me, as a template is not that differnet than a vm.

[Vitaliy S.]

Actually, come to think of it VM Copy would not use CBT either, as each run would be independent and re-copy the whole vm, correct?

Correct.

]Actually, template replication is quite oftenly used by any admins with multiple datacenters. It puzzles me as to why the Replication job would not accept templates - would it be such a big hassle to add it?

Since VM templates do not change much, why not to consider using backup jobs instead and store templates in compressed and deduped format?

[dellock6]

I guess because they want to publish the same template in multiple locations, and to update them whenever is updated in one place

I think the quickest workaround is the trick I explained before. It would be interested anyway to understand how many have the need for template replication, to eventually evaluate this as a future feature. Also, what about catalogs? Are you using plain vsphere templates, or also vcloud catalogs?

[jimmyetimos]

Exactly, we have 2 datacenter locations in Europe and 1 in the US. We use only plain vsphere templates, but around 20 of them and update them quite frequently - 6-8 times a year. It is really convenient to update them on one place and have them in all three. In addition, all the colleagues I know with multiple locations do use template replication of some sort.

Thanks for all your input.

[jimmyetimos]

Found some time, took dellock6's advise and link and modified to this:

Code: Select all

Add-PSSnapin VMware.VimAutomation.Core
Connect-viserver eu2-vcenter
   $templates = Get-Folder 'Templates' | Get-Template | where {$_.name -like "*_eu1_replica"}
   foreach ($template in $templates){
     Set-Template -Template $template -ToVM -Confirm:$false}
disConnect-viserver eu2-vcenter -Force -Confirm:$false
Connect-viserver eu1-vcenter
   $templates = Get-Folder 'Templates' | Get-Template
   foreach ($template in $templates) {
     Set-Template -Template $template -ToVM -Confirm:$false}
disConnect-viserver eu1-vcenter -Force -Confirm:$false
Add-PSSnapin VeeamPSSnapIn
Start-VBRJob -Job "Template Replication"
Connect-viserver eu2-vcenter
   $vms = Get-Folder 'Templates' | Get-vm | where {$_.name -like "*_eu1_replica"}
   foreach ($vm in $vms){
     Set-VM -VM $vm -ToTemplate -Confirm:$false}
disConnect-viserver eu2-vcenter -Force -Confirm:$false
Connect-viserver eu1-vcenter
   $vms = Get-Folder 'Templates' | Get-vm
   foreach ($vm in $vms){
     Set-VM -VM $vm -ToTemplate -Confirm:$false}
disConnect-viserver eu1-vcenter -Force -Confirm:$false

The script simply changes all the templates to vms that are named *_eu1_replica (which were created by the first replication job) in the destinnation DC, then changes all the templates to vms (which are under one folder “Templates” as well) in the source DC. Then, it invokes a Veeam vm replication job (which uses CBT so only changes are passed) and when finished changes all the vm’s back to Template format.
Scheduled the script through Windows Scheduler and works like a charm.

[dellock6]

Nice one Jimmy, thanks for sharing!
Just as an addition, you can also use vsphere tags to identify templated, and let Veeam run dedicated jobs filtering VMs based on tags too. In this way you are not forced to use specific names or to place templated in dedicated folders. Just a suggestion

[veremin]

Scheduled the script through Windows Scheduler and works like a charm.

Be aware that with version 8 you can now use automatic job schedule and set the script as a pre-job activity, instead of executing everything via Windows Scheduler. Thanks.

[SGalbincea]

I actually stopped converting machines to templates and just left my templates as live VMs - this way they can automatically update and be ready at any time. This also allows us to replicate our 'template' VMs to our other sites for a single, consistent server image to build from. Clone from VM works the same as clone from template in my experience, so this is how we solved that issue.