Comprehensive data protection for all workloads
Post Reply
jeff.preou
Novice
Posts: 3
Liked: never
Joined: Aug 05, 2011 1:17 am
Full Name: Jeff Preou
Contact:

Virtual hardware change during replication

Post by jeff.preou » Aug 05, 2011 1:30 am

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.
Product Manager
Posts: 22777
Liked: 1526 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Virtual hardware change during replication

Post by Vitaliy S. » Aug 05, 2011 8:10 am

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
Novice
Posts: 3
Liked: never
Joined: Aug 05, 2011 1:17 am
Full Name: Jeff Preou
Contact:

Re: Virtual hardware change during replication

Post by jeff.preou » Aug 05, 2011 8:35 am

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
Influencer
Posts: 18
Liked: 1 time
Joined: Jan 20, 2011 1:05 pm
Full Name: K Moore
Contact:

Re: Virtual hardware change during replication

Post by mooreka777 » Aug 07, 2011 9:48 pm

jeff.preou wrote: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.
Product Manager
Posts: 22777
Liked: 1526 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Virtual hardware change during replication

Post by Vitaliy S. » Aug 08, 2011 9:58 am

mooreka777 wrote: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.
mooreka777 wrote: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
Novice
Posts: 3
Liked: never
Joined: Aug 05, 2011 1:17 am
Full Name: Jeff Preou
Contact:

Re: Virtual hardware change during replication

Post by jeff.preou » Aug 21, 2011 11:39 pm

Thanks Kelly, but...
mooreka777 wrote: 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).
mooreka777 wrote: 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).
mooreka777 wrote: 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
Expert
Posts: 194
Liked: 33 times
Joined: Jul 26, 2012 8:04 pm
Full Name: Erik Kisner
Contact:

[MERGED] VM Hardware Re: 6.5

Post by ekisner » Nov 06, 2012 7:09 pm

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
Veeam Software
Posts: 5689
Liked: 1604 times
Joined: Jul 26, 2009 3:39 pm
Full Name: Luca Dell'Oca
Location: Varese, Italy
Contact:

Re: VM Hardware Re: 6.5

Post by dellock6 » Nov 06, 2012 11:40 pm

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...
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software

@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2019
Veeam VMCE #1

Post Reply

Who is online

Users browsing this forum: AdsBot [Google] and 17 guests