disable NICs on Protected Servers during Test

[mwkirk]

Hello,

In years past when we have done a DR test we have been using a combination of DoubleTake and Veeam for Disaster Recovery.  Generally, the way the test is run is we do it on a weekend when no production activity is taking place I have disabled the NICs on the production boxes and one way or another I get the boxes up and running at their DR site.  Users are generally logging in via VPN and there are systems external to the organization that these boxes need to talk to in order to effectively test. Once the test is done I shut down the test machines re-enable the nics on the production machines and then start whatever replication I had going before back to the DR site.  We are not interested in trying to replicate back.

Well now we have 3PAR Remote Copy and SRM installed.  I would like to play out this same scenario which I am assuming I would need to script the NIC shutdown.  There is a Guest shutdown option but that action is not performed during a test.  What would be the best method of automating what I we have done in the past using SRM?

TIA

Mike

[LucD]

You could use the Set-NetworkAdapter cmdlet on the VMs you want to include in the tests.

To disable (disconnect) the vNIC you could do

Get-VM -Name MyVM | Get-NetworkAdapter | Set-NetworkAdapter -Connected:$false

Would that serve the purpose of your tests ?

[mwkirk]

Ok....  Actually I think I may have posted this in the wrong forum?  Was looking for how to do it in SRM.  I think maybe I was thinking PowerCLI might be the way which it could be.  Any idea how I would execute that from within SRM?  I may most this same question over in the SRM group as well.

MK

[LucD]

Sorry, no.

Shall I move the thread to the SRM Community ?

[mwkirk]

Sure

[mwkirk]

Sure

[LucD]

Thread moved to the SRM community

[vbrowncoat]

The Test workflow in SRM will accomplish what you are looking for and do it non-disruptively. There is no need to shutdown the nics on VMs. SRM will handle the automation, orchestration and testing of your DR plan.

In an SRM Test a snapshot is taken of the replicated LUNs at the test site. Replication continues to the LUN. These snapshots are then mounted to hosts and VMs connected to the isolated test network (that you specify) and then powered on in the desired order. When you are done testing you run the "cleanup" workflow and the VMs are powered off and deleted, snapshots unmounted and then removed and you are ready for another test or failover.

If you want to actually move your workloads to the other site you can use the Planned Migration or Disaster Recovery workflows. These will shutdown your VMs at your production site (in the reverse order to startup), replicate your storage, then mount LUNs, add VMs and start them up at your recovery site as specified. This is disruptive (as your production VMs are shutdown). The difference between Planned migration and DR is that PM will stop if any errors are encountered and give you a chance to fix them, DR will just keep going to minimize downtime.

The SRM admin guide has details about these and all the other workflows in SRM.

Does this answer your question?

[mwkirk]

To properly test DR in this instance there is connectivity to outside vendors and such that needs to be in place.  The test is doing everything exactly as I need I just need to pull the production boxes off the wire while the test is done.  The actual recovery plan does a lot of things I don't necessarily want. 

[vbrowncoat]

You can add a step to run a script to the plan or to pre/post boot on individual VMs. This script would run on the SRM server so you'd need to have PowerCLI installed, correct permissions, etc but as Luc mentioned you could run a script to accomplish this.

Have you looked at making the external systems available in your test environment (P2V, clone, etc)?