WilliamLam.com

Automating VMware Site Recovery (DRaaS) with VMC

by // 2 Comments

VMware Site Recovery provides customers with an easy and on-demand Disaster Recovery as-as-Service (DRaaS) for both their on-premises and VMware Cloud on AWS (VMC) workloads. DRaaS is one of the most popular VMware Cloud Service as it literally enables customers to setup a fully functional target DR site with just a click of a button, no joke!


As simple as this is, customers are also interested in automating the setup of DRaaS, especially for testing purposes. A couple of weeks back, I had a customer reach out asking if it was possible to automate the setup of DRaaS?

Funny enough, I just had this conversation a few weeks prior with the PM/Engineer and was in the process of looking into this. It turns out we do indeed have DRaaS Service API, which is what the VMC Console uses, however we had not publicized the API nor showed how to actually get more information about it. Do not worry, I have already feature request with the PM to not only get this published publicly but also show up as part of the VMC Developer Center API Explorer 🙂

[Read more...]

Quick Tip - Locating SRM Placeholder VMs using the vSphere API

by // 5 Comments

I had received a question the other day from a reader where they were trying to distinguish between the running VM and its placeholder VM due to their use of VMware Site Recovery Manager (SRM). Since the VM name is exactly the same in both vCenter Servers, it was not clear how to identify between the two. As mentioned in my reply to the reader, there are a couple of ways. You could use the SRM API in-conjunction with the vSphere API (in his case, he was using PowerCLI) to be able to check whether the VM in question was the placeholder VM or not.

Another option is to simply use the vSphere API and querying for the managedBy property which is populated when SRM and/or other solutions are associated with managing a set of VMs. In the case of SRM, you will see an extensionKey with value of "com.vmware.vcDR" and type with value of "placeholderVm" which tells you that the VM is an SRM Placeholder VM, pretty easy, right!? 🙂

Since I did not have an SRM environment handy, the next best thing was to check out VMware Hands-On-Lab environment which anyone can access for free. Lab HOL-1705-SDC-1 was exactly what I needed and here is a quick screenshot of the vSphere MOB showing you what the managedBy property looks like in the vSphere API.

To demonstrate the use of this vSphere API, I wrote a quick PowerCLI function called PlaceholderVMs.ps1 and below is an example of running the Get-PlaceholderVM command:

Automating the silent installation of Site Recovery Manager 6.0/6.1 w/Embedded vPostgres DB

by // 4 Comments

For customers looking to Automate the latest release of Site Recovery Manager 6.0 / 6.1 with an Embedded vPostgres DB, you may have found that my previous deployment scripts for SRM 5.8 no longer work with the latest release. The reason for this is that SRM 6.x now supports the Platform Services Controller (PSC) and in doing so, there are a couple of new silent installer flags that are now required. With the help of the SRM Engineering team, I was able to modify my script to include these new options for automating the silent installation of both SRM 6.0 and 6.1. You can download the new script called install_srm6x.bat.

Before using this script, I highly recommend that you take a look my previous article here which provides more details on how the script works in general.

There are 5 new silent options that have been introduced with SRM 6.x which are all required:

  • PLATFORM_SERVICES_CONTROLLER_HOST - The hostname of the Platform Services Controller
  • PLATFORM_SERVICES_CONTROLLER_PORT - The port for the PSC, default is 443 (recommend leaving this the default)
  • PLATFORM_SERVICES_CONTROLLER_THUMBPRINT - PSC SSL SHA1 Thumbprint (Must be in all CAPS)
  • SSO_ADMIN_USER - The SSO Administrator account (e.g. *protected email*)
  • SSO_ADMIN_PASSWORD - The SSO Administrator password

In addition to the above options, you will still need to populate the following options below and the script outlines which options need to be modified before running the script.

  • SRM_INSTALLER - The full path to the SRM 6.x installer
  • DR_TXT_VCHOSTNAME - vCenter Server Hostname
  • DR_TXT_VCUSR - vCenter Server Username
  • DR_TXT_VCPWD - vCenter Server Password
  • VC_CERTIFICATE_THUMBPRINT - vCenter Server SSL SHA1 Thumbprint (Must be in all CAPS)
  • DR_TXT_LSN - SRM Local Site Name
  • DR_TXT_ADMINEMAIL - SRM Admin Email Address
  • DR_CB_HOSTNAME_IP - SRM Server IP/Hostname
  • DR_TXT_CERTPWD - SSL Certificate Password
  • DR_TXT_CERTORG - SSL Certificate Organization Name
  • DR_TXT_CERTORGUNIT - SSL Certification Organization Unit Name
  • DR_EMBEDDED_DB_DSN - SRM DB DSN Name
  • DR_EMBEDDED_DB_USER - SRM DB Username
  • DR_EMBEDDED_DB_PWD - SRM DB Password
  • DR_SERVICE_ACCOUNT_NAME - Windows System Account to run SRM Service

Note: If you deployed either your vCenter Server or PSC using FQDN, be sure to specify that for both DR_TXT_VCHOSTNAME and PLATFORM_SERVICES_CONTROLLER_HOST. This is a change in behavior compared to SRM 5.8 which only required the IP Address of the vCenter Server.

If you run into any issues, you can take a look at the logs that are generated. From what I have seen, you will normally get a 1603 error code which you need to step back through the logs and eventually you will see the actual error.