1 person found this helpful
our company is going to implement SRM in a landscape of approx. 200 VMs @ 10 ESX boxes.
We did a Jump Start workshop on SRM to discuss which things have to be in the concept before starting to implement it.
While discussing test scenarios we get the information that it is possible to export recovery plans once they have been created. But it seems at this time that there is no import procedure to get this recovery plan back after you deleted it. BUT deletion of the existing recovery plan is mandatory before creating a fail back plan.
How did you folks solve this problem. Do you recreate the recovery plan each time you failed over and failed back?
In a testing environment this can be a lot of work to do by hand :-/
Any suggestions welcome!!
I think this is a VERY GOOD question. I think the answer is NO... The recovery plans are stored in the SQL backend - and cannot be saved into an XML format or something like....
It means you have to do ALL your priorities, orders, message, scripts ALL over again!
My feature req would be an export to AND import from XML... Currently, all we can do export the RESULTS of a recovery plan
thanks for this quick response :o)
Unfortunately until today I only touched SRM in Cannes at VMworld but not in our testing environment. So most of my thoughts come from a theoretical point of view at this time. I hope I can put my hands on it and collect some experiences asap.
Nevertheless in an environment like ours I imagine a holy lot of work to do to recreate a recovery plan for all VMs. Maybe in a testing scenario it is acceptable to recreate it manually. So I think we should hardly address this issue to VMware.
Do you know how to open up a feature request? Maybe you have good contacts to product development? My way of addressing this issue would be through a feature request to our Technical Account Manager of VMware.
What do you think?
You raise a number of interesting points. But firstly, I would like to say - don't take me words as the definitive answer. I've been working with SRM since April. BUT, everyone is on a learning curve. I can imagine where there is will there's way...
Incidentally, I thought deleting the recovery plan at the recovery site, was only done as a part of the failover process and its clean up. You don't have to clear out all your recovery plans do you? It's been a while since I did this for book - so I would want to validate what I said previously.
It was a quick and dirty answer - i've found no way of saving recovery plans to another location. I guess VMware could probably do that now (after all where there is a will there is always way..!), but this is NOT exposed in the UI as far as I can tell...
Incidentally, personally I think this 1.0 release is not without its structual flaws. That's not a damning criticism - just an acknowledgement that this 1.0 release and we all know that means. Natually, I'm a "glass-half-full" kinda of guy - and take the attitude that in the abscense of ANY automation tool, something is always better than nothing. I set out to demonstrate this in the last chapter of book, by showing how you would a manual failover of VMs - and also how to automate that manual process with PowerShell. My intention is not discredit SRM, but show how difficult life would be without it. So, my main point is don't rush to judgement too quick - and think about the consequences/alternatives. Sorry, if this sounds like teaching gramma how to suck eggs!
As for those limitations. Well, two VC kept in synch is going to be difficult for those living in one of those "on-demand, dynamic datacenters" (blah, blah, blah). SRM needs to speak to your storage and virtualcenter - so lets just say the networking and firewalling is going to be a "challenge". Chaning the IP address in side the VM using guest customization is NOT neat, BUT i know VMware have a method that is better than this - and I wouldn't be suprised if this enhancement came through in 1.1 release. Lastly, I find SRM to be quite delicate. This largely comes from its design. In other words there's a bit "that's just the way it is".... Here's an example, a casual change such as deleting a Protection Group can enormonous consequences. When you delete the protection group, it will be removed from the recovery plan - as a consquence all the VMs contained in that protection group will be removed from the recovery plan - that's as it should be. However, you if you recreate the protection group and relink it to the recovery plan - ALL the VMs in the protection group will be dumped into the normal priority.... meaning you have relocate them and reorder them ALL over again.... This is why I would love to be able export/import recovery plans at will - I wouldn't loose those settings...
As for passing on this kind of feedback to VMware SRM. Personal contact is always best - but were in luck. One of the most active users on this forum is Jay. Jay is VMware employee - and product manager for SRM. So I'm sure he's been reading every word of this post (Hiya Jay!)... you can't get any more direct than elevating your concerns/worries/criticisms to PM!
I agree completely with you attitude.
Yesterday was only the first technical discussion on SRM in our project and we are looking forward doing the implementation after the concept is finished. Saving and reimporting the recovery plan was the point with the most question marks That's why I wanted to know what the community is thinking about that.
I hope I can contribute something in more technical depth when we are in the next stage.
Drop us a line when your book is finished!
P.S. half-glass-full is always good :o)