{"id":1705,"date":"2012-02-13T11:26:32","date_gmt":"2012-02-13T16:26:32","guid":{"rendered":"http:\/\/chriscolotti.us\/?p=1705"},"modified":"2012-05-06T19:08:56","modified_gmt":"2012-05-06T23:08:56","slug":"disaster-recovery-in-vcloud-director","status":"publish","type":"post","link":"https:\/\/chriscolotti.us\/vmware\/disaster-recovery-in-vcloud-director\/","title":{"rendered":"Disaster Recovery in vCloud Director"},"content":{"rendered":"

Note:<\/strong> This is a re-post of the article written for the VMware vCloud Blogs<\/a>.<\/p>\n

This article assumes the reader has knowledge of vCloud Director, Site Recovery Manger, and vSphere. It will not go in to depth on some topics, we would like to refer to the Site Recovery Manager, vCloud Director and vSphere documentation for more in-depth details around some of the concepts.  This solution is very much about Disaster Recovery OF the Cloud infrastructure itself using Site Recovery Manager and vCloud Director.  This is not intended to be a fully integrated solution, but rather a way to use both products together to achieve BCDR of the cloud.<\/p>\n

Creating DR solutions for vCloud Director poses multiple challenges. These challenges all have a common theme. That is the automatic creation of objects by VMware vCloud Director such as resource pools, virtual machines, folders, and portgroups. vCloud Director and vCenter Server both heavily rely on management object reference identifiers (MoRef ID’s) for these objects. Any unplanned changes to these identifiers could, and often will, result in loss of functionality. vSphere Site Recovery Manager currently does not support protection of virtual machines managed by vCloud Director.<\/p>\n

The vCloud Director and vCenter objects, which are referenced by each product, that are both identified to cause problems when identifiers are changed are:<\/p>\n