Automation – Page 200

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

10.28.2014 by William Lam // 6 Comments

Last week I had a nice email exchange with Ben Meadowcroft who is the Product Manager for VMware's Site Recovery Manager. While chatting with Ben, I learned about new feature that I was not aware of in the latest SRM 5.8 release which now supports an embedded vPostgres database. Not only does this greatly simplify the installation and not requiring an external database like Microsoft SQL or Oracle, it is also on par in terms scalability with the external databases which is great for customers. I definitely like this improvement in the SRM installation and making it easier to evaluate and POC without requiring a large resource footprint.

UPDATE (11/09/15) - For silent installation of SRM 6.x, please take a look at this article here as some of the install params have changed.

In addition to new database feature, I also learned that SRM supports a silent mode installation which I was not aware of before either. I figured this might come in handy for those needing to automate an SRM deployment given you will need at least two installation: one for the protection site and one for the recovery site. I did not see much documentation on this topic and it has been awhile since I have played with SRM, I thought this would be a good opportunity for some automation goodness as well as checking out some of the new SRM 5.8 features including VSAN support as well as the new vSphere Web Client integration.

In my lab, I wanted to run the a minimal setup and the least amount of Windows 🙂 With that, I was able to use two VCSA, 2 SRM hosts running on Windows 2008 R2 and six Nested ESXi hosts as shown in the diagram below:

To perform a silent installation of SRM, you need to specify a list of 35 parameters to the actual executable which is quite daunting and can also be quite error prone. It actually took me a few tries before I was able to get it working and I wanted to make easier so that anyone can just consume it. I decided to create a simple Windows batch script called install_srm.bat which wraps all the required parameters in a set of variables that can easily be modified by anyone. Out of the 35, only 31 of the parameters can be edited and of those only 15 is really required to be tweaked (which is clearly noted in the script) but also shown below:

SRM_INSTALLER - The full path to the SRM 5.8 installer
DR_TXT_VCHOSTNAME - vCenter Server IP/Hostname
DR_TXT_VCUSR - vCenter Server Username
DR_TXT_VCPWD - vCenter Server Password
VC_CERTIFICATE_THUMBPRINT - vCenter Server SSL SHA1 Thumbprint
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: To retrieve the vCenter Server SSL Certificate Thumbprint, you can either view the details using a regular web browser as shown in the screenshot below

or you can run the following command on a UNIX/Linux using the openssl utility to extract the thumbprint:

echo -n | openssl s_client -connect [VC-IP-ADDRESS]:443 2>/dev/null | openssl x509 -noout -fingerprint -sha1

Depending on the number of SRM installations you require, you will need to modify the script to perform those additional deployments. As you can see below, I have my two SRM sites implemented. I have also gone ahead and paired both my SRM setups as well as deploy and configure the vSphere Replication 5.8 using the vSphere Web Client. I definitely recommend checking out the latest SRM 5.8 release if you have not already and you may also want to consider using the embedded vPostgres database for future SRM installation to help simplify the deployment and management of SRM.

For those of you who are interested in the variable mappings to the SRM UI installer (which is pretty straight forward), I took screenshots of each step and mapped them for your convenience.

How to evaluate the vSphere VCSA Beta running on VMware Fusion & Workstation?

10.13.2014 by William Lam // 17 Comments

If you are taking part in the vSphere Beta (available to public to sign up but still under NDA), you may have recently noticed a new milestone release (RC) that has been made available for download. Having been a long time Beta participant when I was customer and still continuing to do so in my current role, the best way to evaluate and test new VMware software is to of course run them on top of vSphere! I know this may not be an option for everyone and the next best thing would be to use VMware Fusion or Workstation.

For those of you who have tried to run the vSphere Beta of VCSA on VMware Fusion or Workstation, you may have found that it does not work as there are some input parameters that are required as part of the new VCSA deployment. These parameters leverages OVF properties which are currently not supported in VMware Fusion and Workstation and therefore the new injectOvfEnv option in ovftool can not be used.

Having said that, VMware Engineering is quite aware that this can be challenging for many customers as well as VMware Employees who make use of Fusion and Workstation on a daily basis. That is why they have built the VCSA to be quite flexible to support both vSphere as well as Fusion and Workstation, however the process may not be completely obvious for the latter. If you inspect the latest VCSA Beta OVA, which you will need to extract from the ISO, you will notice a series of "keys" that begin with guestinfo which is just leveraging custom key/value pairs for the OVF environment.

Ideally, these are passed in from the OVF Properties using either the vSphere Web Client or the new VCSA deployment tool. However, due to the lack of OVF Property support, it can also be passed in through the VMX file of the Virtual Machine.

Here are the steps to deploy the VCSA Beta using either VMware Fusion or Workstation:

Step 1 - Download the VCSA Beta which is available as an ISO

Step 2 - Extract the contents of the ISO and add the .ova extension to following file located in vcsa/vmware-vcsa (this is the VCSA OVA)

Step 3 - Upload the OVA using either VMare Fusion or Workstation (you can either double click or just go to File->Open) but make sure you do not power it on after deployment. (this is very important)

Step 4 - Locate the directory in which the VCSA was deployed to and open up the VMX file and append the following (make sure to change the IP information and passwords based on your environment):

guestinfo.cis.appliance.net.addr.family = "ipv4"
guestinfo.cis.appliance.net.mode = "static"
guestinfo.cis.appliance.net.addr = "192.168.1.90"
guestinfo.cis.appliance.net.prefix = "24"
guestinfo.cis.appliance.net.gateway = "192.168.1.1"
guestinfo.cis.appliance.net.dns.servers = "192.168.1.1"
guestinfo.cis.vmdir.password = "VMware1!"
guestinfo.cis.appliance.root.passwd = "VMware1!"
guestinfo.cis.appliance.time.tools-sync = "True"
guestinfo.cis.appliance.ssh.enabled = "True"

Note: The example above is a very basic VCSA deployment which should suffice for the majority of you. If you wish to deploy a more complex scenario, you can inspect the VCSA OVA for additional parameters and see their expected values.

Step 5 - Once you have saved your changes, go ahead and power on the VCSA. At this point, the guestinfo properties that you just added will be read in by VMware Tools as the VCSA is booting up and the configuration will begin. Depending on the speed of your hardware, hopefully in a very short amount of time you will have a fully configured VCSA that is ready for your evaluation and testing.

Here is a screenshot of running the VCSA Beta on both VMware Fusion and Workstation:

If you wanted to take this one step further and automate the entire deployment, you can leverage the ovftool to deploy the OVA as shown with the Fusion example below:

'/Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool/ovftool' --name=vmware-vcsa --acceptAllEulas --allowExtraConfig /PATH/TO/VCSA/OVA '/Users/lamw/Documents/Virtual Machines.localized'

and then append the specific configuration using either an echo or here-statement. You can also do the same on Windows leveraging either plain Windows Bat script or PowerShell.

Hopefully for those of you who only have access to Fusion or Workstation, you can now also take part in the vSphere Beta if you do not have a vSphere lab that can be used. I would also recommend checking out the vSphere Beta Community as there is a new contest that launched today for finding bugs in the latest RC release. Not only can you help improve the product through your feedback, you can also win some some $$$ in doing so!

Standalone VMRC (VM Remote Console) re-introduced in vSphere 5.5 Update 2b

10.10.2014 by William Lam // 53 Comments

The VMRC (VM Remote Console) has gone through several transitions from initially being available as a standalone Windows application to an integrated browser based plugin with the release of the vSphere Web Client. In the latest vSphere 5.5 Update 2b release, a new standalone VMRC has been re-introduced to provide an alternative way to launch a VM console. The reason for this is due to the deprecated and eventual removal of NPAPI (Netscape Plugin Application Programming Interface) based plugin support from all modern web browsers which the current VMRC implementation leverages. Here is a quick excerpt from the vSphere 5.5 Update 2b release notes:

Inability to open virtual machine console using Google Chrome browser when NPAPI support is deprecated
When the NPAPI support in Google Chrome is deprecated, the virtual machine console provided in the vSphere Client Integration Plugin might no longer function when the Chrome browser is updated. As a result, you might be unable to open the virtual machine console using the Google Chrome browser and you might not be able to connect to devices.

UPDATE (10/21/14) - Looks like the standalone VMRC has just been made available and you can now download it by either following the link in the vSphere Web Client if you are on vSphere 5.5 Update 2b OR simply by going to http://www.vmware.com/go/download-vmrc

UPDATE (10/12/14) - It looks like the standalone VMRC is currently not available for download just yet. You can continue using the existing methods to connect to your VM Console, the new Standalone VMRC is NOT required but the links have been put in place to proactively get ready for NPAPI deprecation (more details below). You can subscribe to VMware KB 2091284 which will be updated when the download is available.

UPDATE (05/31/15) - If you are connecting directly to an ESXi host you can either use the vSphere API to query for the VM MoRef ID or you can easily pull it by running the following command directly in the ESXi Shell:

vim-cmd vmsvc/getallvms

The deprecation of NPAPI support is nothing new and has actually been communicated by all major web browsers for quite some time now. To ensure that VMware customers are not affected when this change goes into effect, a new standalone VMRC is being introduced to preempt the upcoming change and provides a new way of launching a VM console using the vSphere Web Client as seen in the screenshot below.

To be able to open a VM Console using the new standalone VMRC, you will of course need to have it installed first. You can find the link to the download on VMware.com but there is also a direct link provided on the VM Summary page in the vSphere Web Client. In addition to the new standalone VMRC, you will still be able to use the existing method as well as the HTML5 based VM console. The HTML5 console continues to work if you do not have CIP (Client Integration Package) installed on your Windows system or if you are running on a Mac OS X system. I am sure many of you are probably asking when will there be Mac OS X version of VMRC? I know I definitely am 🙂 The good news is that this is being worked on and hopefully we will see a Mac OS X version in the very near future.

Furthermore, the new standalone VMRC also includes some nice enhancements that I know some of you have been asking for, especially those that have used the previous standalone VMRC application. The new VMRC can now be directly launched using the following two URI methods:

vmrc://[USERNAME]@[VC]/?moid=[VM-MOREF-ID]
vmrc://clone:[VC-TICKET]@[VC]/?moid=[VM-MOREF-ID]

Here is a screenshot of the standalone VMRC application:

The first method accepts basic authentication using username/password, the vCenter Server address and the VM MoRef Id. Here is an example of what that would look like:

C:\Program Files (x86)\VMware\VMware Remote Console\vmrc.exe vmrc://*protected email*/?moid=vm-37

The second method accepts a vCenter Server session ticket which you can generate by using vSphere API acquireCloneTicket() method. A quick way to test this example is by using the vSphere MOB and making a call to acquireCloneTicket using the following URL https://[VCENTER-SERVER]/mob/?moid=SessionManager&method=acquireCloneTicket and then specifying the ticket as seen in the example below.

C:\Program Files (x86)\VMware\VMware Remote Console\vmrc.exe vmrc://clone:*protected email*/?moid=vm-37

With the new URI handler, you can automatically associate it with the standalone VMRC application which means you can type this into a browser or into a Windows explorer and it will automatically launch VMRC. The other nice thing about the new standalone VMRC is if you would like to reduce the complexity of getting a regular use connected to their desktop, you can easily use the standalone VMRC and dynamically generating a link for your end users to access their VMs without ever exposing them to the underlying vSphere infrastructure. I suspect there will be some really interesting use cases for the new standalone VMRC and the VMRC team will continue to iterate to make it better based on customer feedback.