Improving Virtual Labs flexibility

[kacsp]

We're currently using SureBackup Jobs with Replicas to provide dev/test Virtual Lab facilities for our developers, and I'm now looking at providing the ability to hotadd / remove VMs on the fly to improve flexibility. I want to adapt a couple of the processes described here: http://forums.veeam.com/vmware-vsphere- ... 12030.html for our purposes.

a)
1. use the vSphere client to start your Veeam vLab proxy VM manually (power it on)
2. do Instant VM Restores (IVMR) of all of your VMs in your Sharepoint application group but DO NOT connect to network
3. edit each VM's vNIC to use the appropriate vLAB port group
4. do your restore

I'd be using our Replica VMs instead of the IVMRs discussed above.


Furthermore, I'm thinking of using SureBackup Jobs with Linked Replication Jobs, and then combining this with the VMs hotadd method described above to give real flexibility in building & operating Labs.

Again from the same forum article:

b)
1. create (or reduce your current) application group to just the DC and SQL VMs
2. create a new SureBackup job
3. choose the reduced App Group on the Application Group page of the wizard
4. On the Backup Jobs screen (the next one) check the box to link backups and pick a backup job with your Sharepoint VMs
5. Be sure to change the "process simultaneously up to" field at the bottom to 4 VMs (in your case)
6. Finish and try the job

So, I'd be grateful if someone from Veeam would review this and indicate any obvious potential issues before I test things out. At the moment we run concurrent SureBackup Jobs, each Job managing a Virtual Lab containing cloned copies of Replica VMs, so I guess my main concern here is that there might be conflicts when running multiple VM clones outside of SureBackup Job management (albeit with each clone VM connected to a different Virtual Lab proxy)? Would hotadded cloned VMs be as isolated in the same way as if they'd been fired up and managed by SureBackup Jobs alone. Or could what I describe above cause potential problems with existing SureBackup-managed VMs somewhere down the line?

Thanks...

[Gostev]

Hi Keith

a) This looks good except one thing. To initialize Virtual Lab, instead of manually starting vLab appliance, you should start it with the SureBackup job. For that purpose, you can create an application group with a single VM (backup or replica), and check the option to keep group running. You can even use some dummy/empty VM, if there is no any core infrastructure VMs you need for that Virtual Lab to be useful.

b) This one is somewhat confusing. May be you can instead describe what are your TRYING to achieve for (b), and we can suggest the best process?

Thanks!

[kacsp]

Hi Anton,

Thanks for your reply.

We operate a series of continuously running SureBackup Job-based (using Replicas) Virtual Labs for dev/test purposes. These labs contain core a set of cloned VMs, so the DC, Exchange, SQL, Web Servers and Test Clients are essentially the same in each lab. So far so good.

From our perspective SureBackup Jobs have a couple shortcomings. First is that although there is the bonus that all VMs will have their network & other configs checked properly during start-up, this is only really useful first time round in the initial lab build phase. From then on, starting a SureBackup Job can be an unnecessarily slow process.

So I thought that I after the lab was build I could improve subsequent lab start-up times by simply Linking our Replication Jobs for the all VMs except the DC (this still started by SureBackup) to the SureBackup Job. Since this would bypass start-up checks for most of the VMs, lab start-up time overall should be a lot quicker.

Second shortcoming is that SureBackup Jobs lack flexibility when we need to add or remove VMs on an ad-hoc basis from a running Virtual Lab. Here, I thought I could simply reconfigure the VM's port group of the VM I wish to hotadd, changing this to the port group of the target virtual lab, then just fire up the VM. An added bonus with this method is that I see advantages in terms of recovering DataStore storage space by being able to use just single source VMs, as opposed to the Source/ Replica pairs needed by 'pure' SureBackup Job-based virtual labs, which take up a more space.

To date I've found that it's OK to remove VMs from a running lab without any negative affect, but hot-adding didn't seem feasible. Coming across the forum article I mentioned previously indicates though that it should be possible for me to do this.

So I now want to test out the two scenarios described above, but - and this is the main reason for my post here - since both of the changes I talk about above involve running VMs 'outside' of SureBackup Jobs, I wanted to ask if you could forsee if there might be any negative affects on existing lab VMs (clones), or anything else, when trying this. Would the VM clones added using either of the methods I describe above be as 'isolated' as their SureBackup Job-managed counterparts in existing labs?

I hope that's a little clearer.

Thanks for your time in answering this.

[Gostev]

Hi, Keith.

Thanks for the explanation. Both of your use cases do make sense specifically from the On-Demand Sandbox feature usability perspective. I will certainly keep them in mind for the future releases.

As far as clones, I don't expect them causing any issues as long as your don't connect them into the networks where their "parents" are already running (be it production or Virtual Lab), otherwise you will get nasty conflicts on both network and application level.

Thanks

[kacsp]

OK Anton, thanks for your comments. That's reassured me, so I'll try these ideas out in the next day or so. If everything works fine, that'll be a big step forward for us in terms of Labs usability.

I'll feedback here how it goes...