
This week winner of the comment competition is Craig Waters of AUSTRALIA. Criag is a Virtualisation Architect and Data Centre specialist with over 15 years experience in IT, a self-employed IT consultant providing solutions utilizing VMware virtualisation with storage and networking infrastructure technologies. He recently became the chairman of the Melbourne VMUG, and is looking forward to meeting other IT Professionals and sharing my IT knowledge and experience. He’s keen to contribute to the future development of SRM after having designed and implemented the product for his current customer (55 VMs, 6 ESX hosts 4Prod & 2DR, 2 x CX4-240′s with MirrorView/S all going over a 1Gbps microwave link <would you believe>!!!).
This is the comment that won the competition.
My number one feature request would be for a drag and drop style arrangement when configuring the VM startup order on a recovery plan, I tell you we have a relatively small number of VMs (100?s) but it’s still a time consuming job clicking those arrows to get the VMs in the right order based on the companies server shutdown/startup procedures.
Another one that would be good is some DR procedure generation tool which once you’ve configured your SRM would spit out the DR operational procedures for each/all VMs based on a protection group / recovery plan. Keeping this documentation up-to-date is time consuming and every time we add a new VM the whole thing needs reviewing (anything to reduce documentation!)
I just upgraded to SRM 4.1 on vCenter 4.1, so another suggestion would be a 64bit version of SRM including ODBC, I’ve ran some test recovery plans and they’re a lot quicker which will get our recovery time down further, I still love seeing peoples faces when I tell them a) we did a full DR live failover/failback in about 5 hours end to end for all applications in the business and b) we test this procedure every 90 days…
Also another quick one would be changing SRM coding from Perl to Powershell? This way a lot more automation could be achieved and powershell developers could put more into the customisation of SRM…
The real challenge with SRM has always been the dependency on storage, as other people have commented here, the storage layer and how you carve up your LUNs / assign VMs can really dictate how SRM functions, when we first sold SRM to management there was no end of debate on how single VMs should be recoverable using SRM so if I have an operational failure I can just failover my single app… it took some time for management to get their head around this and even now they have to be reminded that DR is an all or nothing proposition.
The only problem with storage change suggestions is that it will ultimately effect the storage vendors who VMware rely on to create the SRA integration, so again not sure where this could go… I’ve heard about the replication features in the next release, but what about some help with the storage configuration?
My final rant would be about the ability to change the state of the VM on the recovery side, if you are not fortunate enough to have a stretched VLAN between Data Centres then IP recoding is required, what about some greater control on how VMs startup, like the ability to control services on a VM or change the VM hardware configuration…?
Anyway, that’s all, hope there’s something there for you Mike to pass on to VMware.