Virtual hardware change during replication

[jeff.preou]

Fairly certain I know the answer (unfortunately).
We will probablye have a VM running under vSphere Enterprise with 8vCPUs.
The DR host only has vSphere Standard, which is limited to 4 vCPUs per VM.
a) Will Veeam be able to replicate the VM (thinking the DR host may bitch about registering the VM)?
b) Can Veeam modify the virtual hardware on the fly (drop the vCPU count from 8 to 4)?
c) If none of the above, anyone know of any other workaround other than licensing the DR host up to Enterprise?
Cheers
JEFF

[Vitaliy S.]

Hi Jeff,

Since VM registration happens at the end of the job, then we should be able to replicate this VM with no issues.

Besides, I've just googled for the same situation as you have and found out that your virtual machine WILL be registered, however the total amount of vCPUs will be reduced to 4: http://communities.vmware.com/message/1770754

As regards VM modification, then as you've already guessed, that is not possible within the replication job, but it should be okay, since the first option will most likely work.

Thanks.

[jeff.preou]

Hi there. I managed to get my hands onto a test system after I posted earlier today.
I removed the license from the source ESX host so it was in eval mode and this allowed me to create an 8 vCPU VM.
What I discovered was that Veeam would then replicate without issue.
It didn't reduce the vCPU count at the destination, but of course when I tried to fire it up so the ESX host complained that it didn't have the right license.
Easy fix is a manual task of editing the vCPU on the replica before firing it up and all good after that.
When we upgrade to vSphere5 I think all versions allow 8 vCPUs so we wouldn't have that issue.
So
a) yes it will
b) no it can't
c) well, (a) worked so manually reduce vCPUs before powering on the replicated VM and the job's a goodun'!

[mooreka777]

Fairly certain I know the answer (unfortunately).
We will probablye have a VM running under vSphere Enterprise with 8vCPUs.
The DR host only has vSphere Standard, which is limited to 4 vCPUs per VM.
a) Will Veeam be able to replicate the VM (thinking the DR host may bitch about registering the VM)?
b) Can Veeam modify the virtual hardware on the fly (drop the vCPU count from 8 to 4)?
c) If none of the above, anyone know of any other workaround other than licensing the DR host up to Enterprise?
Cheers
JEFF

a> I would strongly recommend against replication for DR. Backup and restore is WAY faster. Also, if you power up a vm that is replicated you have to delete it before the backups work again. You also have no history. So, you cant backup a replicated VM from two weeks ago, etc. Besides, you can probably have the systems up and ready before the network is up.

b> No, but there are some pretty simple PowerCLI commands that can do this. Get-Host and then manipulate away. Install it on your vcenter host. If you are perl geek then install the API on a linux box and away you go. SUPER easy. PM me if you need more help.

c> Licensing. Load vcenter, keep the same license as production and power the vm off with no hosts attached to it. Backup through the ESX host or a CIFS share. Done.


-----------------------------------------

Let me know if that helps.


-Kelly

[Vitaliy S.]

Also, if you power up a vm that is replicated you have to delete it before the backups work again.

In order to avoid this one can use snapshots or our failover wizard.

You also have no history. So, you cant backup a replicated VM from two weeks ago, etc.

What history are you referring to? Rollbacks?

[jeff.preou]

Thanks Kelly, but...

a> I would strongly recommend against replication for DR. Backup and restore is WAY faster. Also, if you power up a vm that is replicated you have to delete it before the backups work again. You also have no history. So, you cant backup a replicated VM from two weeks ago, etc. Besides, you can probably have the systems up and ready before the network is up.

The machine is too big to recover from backup in a timely manner and we cannot take too much data loss. Customer RPO (one hour) and RTO (four hours). *IF* we ever fail over to the replica, we would then re-create backup jobs, etc as necessary while we run under DR. We are fully aware of Veeams limitations/policy with respect to fail-back to the production VM. We don't use *only* replica, by the way, we also have a window where we perform backups (and yes, this obviously affects RPO/RTO during the window, but customer accepts that as an exception).

b> No, but there are some pretty simple PowerCLI commands that can do this. Get-Host and then manipulate away. Install it on your vcenter host. If you are perl geek then install the API on a linux box and away you go. SUPER easy. PM me if you need more help.

Agree we can do this via scripting, but given that the change takes justa minute or two and would only be necessary during a DR event when all hands are on deck, why script it? Having this manual change required also prevents mistakes in the replicating VM being accidentally powered up, since it cannot under the current licensing model (though the move to vSphere5 will change that).

c> Licensing. Load vcenter, keep the same license as production and power the vm off with no hosts attached to it. Backup through the ESX host or a CIFS share. Done.

Customer is practically 24/7 with only occasional outage windows. Power off of the VM cannot happen regularly, let alone the need to meet the RPO stated above.

--JEFF

[ekisner]

I noticed in the newer version that Veeam will now default to thin provision VMDKs.. this is excellent - but it got me thinking.

If it's going to change some items to more desirable defaults, why not change more items to desirable defaults.

For example CPU socket/core count:
In my particular case, my ESXi hosts in production have access to 8 cores. My DR hosts, however, only have access to 4. It's a simple matter for me to "manually failover" the VMs in question using 8 cores (shut down source, replicate, edit target cpu count, power on target). Perhaps within the job wizard, include a screen for the target resources. Or perhaps I'm just the one-off case not using identical hardware at each site.

Another example would be memory... within the surebackup you have the option of scaling back the memory to a percentage of the source. Doing so for replicas would be interesting (especially since it's a DR site). Would allow you to scale back the replicated VMs and run more at reduced performance.

One other which may prove interesting would be the optical drive. I keep a datastore in my production SAN where I store all my ISOs. Makes for some spectacularly fast OS installs! Unfortunately, without replicating that datastore(which would be easy to do, just a waste of disk space) I end up having VMs with inaccessible ISOs . Setting a default option for the target, such as 'Client Device', would allow things to stay cleaner. I am, however, reaching for straws at this point, as it's pretty easy to simply unmount an ISO when you're done with it

In any case, the usual disclaimers about stability would probably be needed. But it may simplify failovers? Thoughts?

[dellock6]

Hi,
about differences in hardware between production and DR, no is not so uncommon. Many times older servers are beeing dismissed from production, and to save on budget they are moved to DR instead of buying new ones.
If there are differences between servers, like you said 8core vs 4core, this is a design decision you have deal with an pick the best option for your envorment, for example by replicating VMs to a host with the same amount of vCPU. This is not an option on the software, by a design decision...