can anyone point me in a direction for vmware documentation on recovery of virtual center?
Thanks
I think the key to VCMS recovery is to have a good backup plan for your DB. As for your VCMS host itself, I would backup the license file, and vpxd.cfg
Hope this helps
I agree with Troy - everything about your VC environment is installed in the VC DB - so as long as that data is protected it is very easy to rebuild a VC server and as long as the DB is available just point the new VC server at it and your environment is back -
I have same question about DR solution for VC. I contacted VMWare support, I was told DR serve for VC must be:
1. Use same DB. This is not a problem for SQL server.
2. Same IP. Don't know how to do this. There is no where to have same IP address in DR site as production site, unless you do something using 192.168.x.y where you will lose some access.
3. Same Keys. ssh Keys generated when ESX join the cluster. This can be done as well, such as ghost image the original server.
I don't know how to overcome item 2 in current VC 2.5, windows cluster is not for this. During our DR test, I use VC Client to point to ESX directly to operation VM as a work around.
I can only think of make one VC server in each data center, but this is not a good solution. I heard that next version of VC will have some kind of Federated service which is great.
Jeff
If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points
thanks, I will try step 9 in my QA.
You could cluster VirtualCenter in Windows by using the "generic application" type and installing the app on both servers. That would allow you to have a single VirtualCenter identity (name and IP address) on any member node of the cluster. To do this, you'd need an Enterprise version of Windows, and potentially some shared disk (newer versions of Windows can have a file share witness instead). The ODBC would need to be configured on each server, and you would need to be able to, on your own, ensure that the stateful information on the cluster nodes themselves (there isn't much, since, as previous posters have said, almost all of it is in the database) stays synchronized.
I've been working on another system that as very senstiive to IP changes and the network team suggested using a non-geographic IP address - how about trying this? Theory is that the physical address of the server can change but the non-geographic address stays the same so you get what you're looking for.
I can't provide more info about non-geographic addresses but it shouldn't be hard to find out on the web I would think.
Jon