Veeam Integration with vRA Part 2: Restore

In this 2 part series we will walk through integrating Veeam with vRealize Automation and vRealize Orchestrator. Part 1 focused on giving users the ability to add virtual machines to existing Veeam backup jobs from within the vRA self-service portal. In Part 2 we will add the ability to restore virtual machines from a list of available restore points in vRA. The versions used are Veeam 9.5 and vRA 7.2 / 7.3.

The steps outlined below assume that you have already installed and configured Veeam Backup and Replication, and vRealize Automation with either embedded or external vRealize Orchestrator instance, as well as having a basic knowledge of both areas. The following process and the sample workflows we will import are not endorsed by, or supported by Veeam. Finally, Veeam Enterprise Manager is required to use Veeam RESTful API. For further reading material see the Veeam RESTful API Reference here. Alternative sample workflows and reading provided by The IT Hollow here, and another useful article by vRatpack here with vRA 6.2.

Add the REST Host

If you have already added your Veeam backup server as a REST host in part 1 then skip this step. Otherwise, open the vRealize Orchestrator client and log in as an administrator, change the view to Design from the drop down menu. The first thing we will do is add the Veeam server as a REST host. From the Workflows tab expand Library, HTTP-REST, Configuration.

REST_host_1

Right click Add a REST host and click Start workflow. Enter the name and URL of the Veeam server, the default URL uses port 9399, for example http://VeeamServer:9399. Review the default options and click Next.

REST_host_2

Configure the host authentication options as required. Here I have used Basic authentication, and entered the credentials for a service account with administrative access to Veeam.

REST_host_3

Configure proxy and advanced settings if required, then click Submit. The workflow will run and add the Veeam server as a REST host. There are also Update a REST host, and Remove a REST host, workflows if you want to make any changes. Existing REST hosts can be viewed from the inventory tab under expand HTTP-REST.

Import the Sample Workflows

If you have already imported the sample workflows in part 1 then skip this step. In this example I am using sample workflows provided here, again these are not supported by Veeam. Download and extract the ZIP file to a location accessible from the vRO client. Change to the packages tab and click the Import Package icon. When prompted browse to the downloaded package file and click Import.

Veeam_Package_1

Ensure all the required elements are included and click Import selected elements.

Veeam_Package_2

We have now imported the backup workflow and action, and the restore workflow and action. The final element is a settings file which we will use to determine the REST host. Open the configurations tab and expand Library, Veeam. Click the Settings file and the pencil icon to edit. Select Attributes and locate the restHost attribute, click the Not set value and expand HTTP-REST, select the Veeam server we added earlier from the list of REST hosts and click Select. Click Save and close. The value of the restHost attribute should now be the Veeam backup server.

The restore jobs users select from are pulled using the getVMRestorePoints action under com.veeam.library in the actions tab. If you want to examine the workflow in more detail go to the workflows tab and expand Library, Veeam. Select the Restore VM workflow and go through the tabs in the right hand pane. From the General tab you can see the restHost attribute is using the settings configuration file we have just configured. The Inputs for the workflow are Date (the Veeam restore point) and vmObj (virtual machine name). Under the Schema tab you can view the Scripting task which is making the API calls.

Restore_VM

Update Sample Script

If you are using the sample script referenced in this post then there are further steps required to fix the date formatting with later versions of Veeam. If you are using alternative or custom workflows then the following is not required.

  • Edit the Restore VM workflow, open the Schema tab and click the Find Restore Point script. Update the date and time format on line 25 to: var rpDateLocale = System.getDateFromFormat(restorePointNodes.item(i).getElementsByTagName(“CreationTimeUTC”).item(0).textContent,”yyyy-MM-dd’T’HH:mm:ss.sss’Z'”).toLocaleString();

Find_Restore_Point_OldFind_Restore_Point_New

  • Edit the getVMRestorePoints action, open the Scripting tab. Update the date and time format on line 26 to: var rpDateLocale = System.getDateFromFormat(restorePointNodes.item(i).getElementsByTagName(“CreationTimeUTC”).item(0).textContent + ” UTC”,”yyyy-MM-dd’T’HH:mm:ss.sss’Z’ ZZZ”).toLocaleString();

Restore_Point_Action_OldRestore_Point_Action_New

  • You can test the API calls are successfully bringing back restore points by running the workflow in vRO and selecting a virtual machine, a list of available restore points should be displayed.

Run_vRO

vRA Integration

The final step is to hook the vRO workflow into vRA. Log into the vRealize Automation portal as a user with service architect permissions. From the Design tab select XaaS and Resource Actions. Any existing resource actions are listed. Click New.

Existing_Resource

Map the resource action to the relevant vRO workflow. In this case we need to expand Library, Veeam and select the Restore VM workflow. Click Next.

Restore_VM_Resource

The input mappings should already be populated; the resource type is IaaS VC Virtual Machine, the input parameter matches up with the parameter configured in the vRO workflow (vmObj which passes the virtual machine name), and this maps to the VC:VirtualMachine orchestrator type.

Restore_VM_Input

Accept the default values for the resource action form and click Finish.

Restore_VM_Form

The new resource action is now listed as a draft. To start using the action select it and click Publish.

New_Resource

Now select the Administration tab and Catalog Management. Open the Actions page, the new resource action we created should now be displayed.

If you want to change the icon of the resource action you can do so by selection the action and clicking Configure. There are a number of useful vRA icons available here, including sample icons for day 2 actions. Note for users of vRA 7.2 there is a known issue with changing the icon for custom actions, resolved in 7.3 as per this KB article.

Restore_VM_Action

The next step is to assign our custom action to an entitlement. Open the Entitlements page and select the relevant entitlement. Click the Items & Approvals tab, under Entitled Actions click the green plus symbol. Locate the new resource action and select the check box to add it to the entitled actions. Click Ok and Finish.

Restore_VM_Entitlement

To confirm the configuration has worked browse to the Items tab and select Machines. Any virtual machines that have the custom resource action added to the entitlement will show the new action in the drop-down Actions menu.

restore_vm_item

When selecting the new action I am presented with the action form as per the design canvas we saw earlier. In this example I select the restore point from the drop-down list that the getVMRestorePoints vRO action has pulled from the Veeam backup server, and click Submit.

restore_request

The virtual machine name is then passed through to the next stage of the workflow, along with the restore point ID. You can check the status of the job in vRA under the Requests tab, check the Restore VM workflow has run successfully in the vRO console, and check the restore task that will be running as normal in the Veeam Backup & Replication console.

_______________

Veeam Integration with vRA Part 1: Backup

Veeam Integration with vRA Part 2: Restore

Veeam Integration with vRA Part 1: Backup

In this 2 part series we will walk through integrating Veeam with vRealize Automation and vRealize Orchestrator. Part 1 will focus on giving users the ability to add virtual machines to existing Veeam backup jobs from within the vRA self-service portal. In Part 2 we will add the ability to restore virtual machines from a list of available restore points in vRA. The versions used are Veeam 9.5 and vRA 7.2 / 7.3.

The steps outlined below assume that you have already installed and configured Veeam Backup and Replication, and vRealize Automation with either embedded or external vRealize Orchestrator instance, as well as having a basic knowledge of both areas. The following process and the sample workflows we will import are not endorsed by, or supported by Veeam. Finally, Veeam Enterprise Manager is required to use Veeam RESTful API. For further reading material see the Veeam RESTful API Reference here. Alternative sample workflows and reading provided by The IT Hollow here, and another useful article by vRatpack here with vRA 6.2.

Add the REST Host

Open the vRealize Orchestrator client and log in as an administrator, change the view to Design from the drop down menu. The first thing we will do is add the Veeam server as a REST host. From the Workflows tab expand Library, HTTP-REST, Configuration.

REST_host_1

Right click Add a REST host and click Start workflow. Enter the name and URL of the Veeam server, the default URL uses port 9399, for example http://VeeamServer:9399. Review the default options and click Next.

REST_host_2

Configure the host authentication options as required. Here I have used Basic authentication, and entered the credentials for a service account with administrative access to Veeam.

REST_host_3

Configure proxy and advanced settings if required, then click Submit. The workflow will run and add the Veeam server as a REST host. There are also Update a REST host, and Remove a REST host, workflows if you want to make any changes. Existing REST hosts can be viewed from the inventory tab under expand HTTP-REST.

Import the Sample Workflows

In this example I am using sample workflows provided here, again these are not supported by Veeam. Download and extract the ZIP file to a location accessible from the vRO client. Change to the packages tab and click the Import Package icon. When prompted browse to the downloaded package file and click Import.

Veeam_Package_1

Ensure all the required elements are included and click Import selected elements.

Veeam_Package_2

We have now imported the backup workflow and action, and the restore workflow and action. The final element is a settings file which we will use to determine the REST host. Open the configurations tab and expand Library, Veeam. Click the Settings file and the pencil icon to edit. Select Attributes and locate the restHost attribute, click the Not set value and expand HTTP-REST, select the Veeam server we added earlier from the list of REST hosts and click Select. Click Save and close. The value of the restHost attribute should now be the Veeam backup server.

The backup jobs users select from are pulled using the getBackupJobs action under com.veeam.library in the actions tab. If you want to examine the workflow in more detail go to the workflows tab and expand Library, Veeam. Select Add VM to Backup Job and go through the tabs in the right hand pane. From the General tab you can see the restHost attribute is using the settings configuration file we have just configured. The Inputs for the workflow are jobname (Veeam backup job) and vmObj (virtual machine name). Under the Schema tab you can view the Scripting task which is making the API calls.

Add_VM

vRA Integration

The final step is to hook the vRO workflow into vRA. Log into the vRealize Automation portal as a user with service architect permissions. From the Design tab select XaaS and Resource Actions. Any existing resource actions are listed. Click New.

Existing_Resource

Map the resource action to the relevant vRO workflow. In this case we need to expand Library, Veeam and select the Add VM to Backup Job workflow.

Backup_VM_Resource

The input mappings should already be populated; the resource type is IaaS VC Virtual Machine, the input parameter matches up with the parameter configured in the vRO workflow (vmObj which passes the virtual machine name), and this maps to the VC:VirtualMachine orchestrator type.

Backup_VM_Input

Accept the default values for the resource action and click Finish.

Backup_VM_Form

The new resource action is now listed as a draft. To start using the action select it and click Publish.

vra6

Now select the Administration tab and Catalog Management. Open the Actions page, the new resource action we created should now be displayed.

If you want to change the icon of the resource action you can do so by selection the action and clicking Configure. There are a number of useful vRA icons available here, including sample icons for day 2 actions. Note for users of vRA 7.2 there is a known issue with changing the icon for custom actions, resolved in 7.3 as per this KB article.

vra7

The next step is to assign our custom action to an entitlement. Open the Entitlements page and select the relevant entitlement. Click the Items & Approvals tab, under Entitled Actions click the green plus symbol. Locate the new resource action and select the check box to add it to the entitled actions. Click Ok and Finish.

vra8

To confirm the configuration has worked browse to the Items tab and select Machines. Any virtual machines that have the custom resource action added to the entitlement will show the new action in the drop-down Actions menu.

vra9

When selecting the new action I am presented with the action form as per the design canvas we saw earlier. In this example I select the backup job from the drop-down list of jobs that the getBackupJobs vRO action has pulled from the Veeam backup server, and click Submit.

vra10

The virtual machine name is then passed through to the next stage of the workflow, which adds the virtual machine to the selected backup job. You can check the status of the job in vRA under the Requests tab, check the Add VM to Backup Job workflow has run successfully in the vRO console, and check the backup job itself has been updated using the Veeam Backup & Replication console.

_______________

Veeam Integration with vRA Part 1: Backup

Veeam Integration with vRA Part 2: Restore

Deploying an NSX Load Balancer with vRA

In this post we will walk through the process of deploying an NSX Load Balancer using vRealize Automation. We will also cover high availability and post deployment scaling. In order to take advantage of the direct NSX API integration with vRA you will need to be running at least v7.3, read more about the enhancements made in vRA 7.3 from the release notes or what’s new. In the example we’ll work towards multiple web servers are provisioned with an On-Demand Load Balancer, along with app servers and a database server. The On-Demand Load Balancer deploys an NSX edge for load balancing and adds the web servers as pool members. There are a number of available customisations which we’ll cover in the configuration process below.

Blueprint_2

Adding Endpoints

The following process assumes that you have a fully deployed vRA topology with all the components required to provision virtual machines; vCenter endpoint(s), reservations, compute resources, and a published catalog with entitlements. It would also be beneficial to have an understanding of using an NSX edge for load balancing or have deployed an edge manually to see the corresponding deployment options.

The first step is to add the NSX Manager as a vRA endpoint. From the Infrastructure tab select Endpoints and Endpoints again. Click New and select Networking and Security, NSX. Enter the details for the NSX Manager. Before adding the NSX endpoint we can create an association with the registered vCenter Server. From the Associations tab, click New. Select the vCenter Server from the dropdown, the platform type will auto-populate to vSphere and the description vSphere to NSX Association. Click Test Connection and then Ok to save the configuration.

NSX_Endpoint

Blueprint Modifications

After NSX has been added as an endpoint navigate to Blueprints under the Design tab. From the design canvas of a new or existing blueprint select Network & Security, drag and drop the On-Demand Load Balancer onto the canvas.

Blueprint_1

Click the On-Demand Load Balancer that has been added to the canvas. When the load balancer is provisioned in NSX the servers associated with the load balancer in the blueprint are automatically added as members in the pool. This is set in the Member field, in the example below the web servers in the blueprint are added as members of the load balancer.

Blueprint_3

The network for the member servers and the network for the VIP address are configured in the appropriate fields. Leave the IP address blank to automatically assign an IP address from the associated VIP network. Under Virtual servers click New, here you can configure the protocol settings for the load balancer, and the algorithm/persistence, health check, and connection settings by selecting Customize.

Customize_LB

Before saving the blueprint click the settings cog at the top of the page, this opens the blueprint properties. From the NSX Settings tab set the Transport zone to attach the load balancer to, this can be a local or universal transport zone. Next select the Edge and routed gateway reservation policy, this is the reservation policy (compute, storage) that will be used when provisioning the edge.

Blueprint_Properties_1

Click the Properties tab and select Custom Properties. There are a number of optional parameters we can add here.

  • NSX.Edge.ApplianceSize sets the appliance size of the edge, accepted values are compact, large, quadlarge and xlarge.
  • NSX.Edge.HighAvailability deploys the edge appliance in HA mode when the value is true. Without this property only a single appliance is deployed.
  • NSX.Edge.HighAvailability.PortGroup references the port group to use for the heartbeat network of the edge appliances deployed in HA mode.

Blueprint_Properties_2

Click Ok and Finish to save the blueprint. Make the blueprint available as a catalog item and request a test deployment. In vSphere you will see the edge and VMs being provisioned and, once complete, the virtual machines will be added as members in the load balacer pool. You can view the settings of the deployed edge in the vSphere web client under Networking & Security, NSX Edges, double click the edge and select Load Balancer.

NSX_Load_Balancer

Post Deployment

When the deployment is destroyed the edge appliances are removed along with the VMs as part of the cleanup process. If the deployment is scaled out then the new server is added as a member to the existing load balancer pool, likewise if the deployment is scaled in then the server deleted is also removed from the pool.

Scale_Out

The scale in and scale out actions are assigned as entitled actions from within the relevant entitlement  Aswell as having the permissions to perform the scale actions the blueprint must also contain a higher number of maximum instances. In the example below 2 web servers will be deployed with an On-Demand Load Balancer, as the maximum number of instances is set to 10 the requester can scale out the number of web servers and pool members to a maximum of 10 servers.

Blueprint_Scale

Configuring VMware Cross-vCenter NSX

This post provides an overview of cross-vCenter NSX and walks through the configuration steps. Cross-vCenter NSX allows central management of network virtualization and security policies across multiple vCenter Server systems. Cross vCenter NSX introduces universal objects; such as universal logical switches, universal logical routers, and universal distributed firewall rules. Universal objects are able to span multiple sites or vCenter Server instances, enhancing workload mobility by allowing cross vCenter and long distance vMotion for virtual machines, whilst keeping the same network settings and firewall rules. This improves DR capabilities, overcomes scale limits of vCenter Server, and gives administrators more control over resource pooling and the separation of environments.

Cross vCenter-NSX was introduced in NSX v6.2 and requires vSphere v6.0 or later. As normal NSX Manager is deployed with vCenter server in a 1:1 pairing.  In a single site NSX deployment the NSX Manager is given the standalone role by default. When configuring cross-vCenter NSX one NSX Manager is assigned the primary role, and up to seven other NSX Managers are assigned the secondary role. NSX Managers configured for cross-vCenter NSX must all be running the same version. The primary NSX Manager is responsible for deploying the Universal Controller Cluster; forming the control plane across the NSX Managers. The Universal Controller Cluster runs in the site of the primary NSX Manager. Universal objects are created on the primary NSX Manager and automatically synchronized across the multi-site NSX environment.

Configuring Cross-vCenter NSX

The steps below assume you have already deployed and registered the NSX Managers, and have a good understanding of NSX. This post is intended as add on to the NSX Install Guide to provide an outline of the additional or different steps required for a cross-vCenter NSX install, further resources are listed at the bottom of the page. If you are using vCenter enhanced linked mode then multiple NSX Manager instances are displayed within the same interface, or single pane of glass, when managing the Network & Security section of the vSphere web client. Enhanced linked mode is not a requirement for cross-vCenter NSX however, and vCenter Server systems not in enhanced linked mode can still be configured for cross-vCenter NSX.

From the Networking & Security page of the vSphere web client select Installation, highlight the NSX Manager in the primary site, from the Actions menu select Assign Primary Role.

NSX_Promote

The secondary NSX Manager(s) synchronize with the primary using the Universal Synchronization Service. These sites do not run any NSX Controllers, although they can be redeployed easily in the event of a primary site outage. Before assigning the secondary role you should ensure there are no existing NSX Controllers deployed in the associated vCenter. If you have already assigned a segment ID pool to the NSX Managers then ensure the segment ID pools do not overlap. Select the primary NSX Manager and from the Actions menu click Add Secondary NSX Manager. Enter the secondary NSX Manager information and admin password.

NSX2

Review the table of NSX Managers, the roles have now changed accordingly.

NSX_Roles

The universal controller cluster is formed by individually deploying the NSX controllers from the primary NSX Manager, the method of deploying the controllers is the same (see NSX Install Guide Part 1 – Mgmt and Control Planes for further assistance). Once the controllers are deployed you will notice placeholder controllers listed against the secondary NSX Manager, these are not connected or deployed. In the event of a site failure the configuration is synchronized between NSX Managers so you can simply re-deploy the controllers in the DR site. To see the failover process review this blog post. VMware recommend deploying 3 controllers on different hosts with anti-affinity rules.

NSX_Controllers

The next part of the install process is to follow the host preparation and VXLAN configuration steps as normal (see NSX Install Guide Part 2 – Data Plane for further assistance). Create the segment ID pools for each NSX Manager, making sure they do not overlap. On the primary NSX Manager you will also assign a universal segment ID pool.

In order for us to deploy universal logical switches we need to create a universal transport zone. A universal transport zone determines which hosts a universal logical switch can reach, spanning multiple vCenters. From the Logical Network Preparation tab open Transport Zones, ensure the primary NSX Manager is selected and click the plus symbol. Select Mark this object for Universal Synchronization, and enter the configuration for the universal transport zone. All universal objects must be created on the primary NSX Manager, change the NSX Manager to the secondary site and you will see the universal transport zone has synchronized there also.

NSX_TZ

Next we will create a universal logical switch for the transit network. Local objects such as logical switches, logical routers, and Edge Services Gateways can still be deployed from each NSX Manager, although by design they are only local to the vCenter linked to that specific NSX Manager, and cannot be deployed or edited elsewhere. From the left hand navigation pane in Networking & Security select Logical Switches, ensure the primary NSX Manager is selected and click the plus symbol. Enter a name for the transit network and select the universal transport zone we created earlier.

NSX_Universal_Transit

At this stage you can also deploy another universal logical switch, connecting a couple of test VMs on a private subnet, and have them ping one another to confirm connectivity. Now that we have a transit network and test universal logical switches connected to our universal transport zone we can go ahead and create a universal DLR. In this particular environment we have already deployed an ESG in each site. For further assistance with deploying an ESG and DLR see NSX Install Guide Part 3 – Edge and DLR.

From the Networking & Security page click NSX Edges, ensure the primary NSX Manager is selected and click the plus symbol. The control VM for the DLR is deployed to the primary site, again the configuration is synchronized and this can be re-deployed to the DR site in the event of a primary site outage. Select Universal Logical Router and follow the wizard as normal, if local egress is required then check the appropriate box. Sites configured in a cross-vCenter NSX environment can use the same physical routers for egress traffic, or have the local egress feature enabled within a universal logical router. The local egress feature allows routes to be customized at host, cluster, or router level.

NSX_UDLR

From the NSX Edges page double click the new universal DLR, select Manage, Settings, Interfaces and click the add button. In order for traffic to route from the universal DLR to the ESG(s) we must add an uplink interface connecting them to the universal transit network. Change the logical router interface to Uplink, in the Connected To field select the transit network universal logical switch we created earlier. Configure the IP and MTU settings of the interface per your own environment.

NSX_UDLR_Interface

You can also add Internal interfaces here corresponding with universal logical switches for virtual machine subnets. Before these subnets can route out follow the same process to add an Internal interface to the ESG(s) connecting them to the same transit network.

A virtual machine connected to the test universal logical switch can now vMotion between sites keeping the same IP addressing, providing L2 over L3 capability. As well as remaining on the same logical network a virtual machine can also be migrated across sites without any additional firewall rules, this is achieved with the use of universal firewall rules. Universal firewall rules require a dedicated section creating under the Firewall section of Networking & Security, you must select Mark this section for Universal Synchronization. For assistance with creating universal firewall rules see here.

NSX_Universal_Firewall

Additional Resources

To plan a cross-vCenter NSX installation review the VMware Cross-vCenter NSX Design Guide, Cross-vCenter NSX Topologies Guide, and the VMware Cross-vCenter Installation Guide. For more information on cross-vCenter NSX design see the following blog posts:

Installing vCenter Internal CA signed SSL Certificates

This post will walk through the process of replacing the default self-signed certificates in vCenter with SSL certificates signed by your own internal Certificate Authority (CA). In previous versions of vSphere the certificate replacement procedure was so complex that many administrators ignored it completely. Now with the certificate tool improvements in vSphere 6.x, and the ever increasing security threat of todays digital world, applying SSL certificates takes on an enhanced significance for verifying servers, solutions, and users are who they say they are.

The procedure outlined below is specific to installing Microsoft intermediate CA signed certificates on VCSA 6.5 with embedded PSC, protecting us against man in the middle attacks with a secure connection which we can see in the screenshot below. From v6.0 onwards the VMware Certificate Authority (VMCA) was also introduced, for more information on using the VMCA see this blog post, or to read how to use the VMCA as an intermediate CA see here. VMware documentation for replacing self-signed certificates can be reviewed from this KB article.

Trusted_vSphere

Before beginning the replacement certificate process ensure you have a good backup, and snapshot of the VCSA. The following links are the official VMware guides and this blog post provides a good overview of the certificates we’re actually going to be replacing. Replacing default certificates with CA signed SSL certificates in vSphere 6.x (2111219)Replacing a vSphere 6.x Machine SSL certificate with a Custom Certificate Authority Signed Certificate (2112277)How to replace the vSphere 6.x Solution User certs with CA signed certs (2112278).

Generate CSR

The first thing we need to do is generate a Certificate Signing Request (CSR). Open an SSH connection to the VCSA using an SSH client such as Putty, and login as root – if you need to enable SSH you can do so from the VAMI (https://vCenterIPorFQDN:5480) under Access; enable both SSH Login and Bash Shell. Run the following command to open the VMware built in Certificate Manager tool:

/usr/lib/vmware-vmca/bin/certificate-manager

Cert_Tool_1

Select the appropriate option. In this case we first want to replace the machine SSL certificate with a custom certificate, option 1. When prompted enter the SSO administrator username and password. Enter 1 again to generate certificate signing request(s) and Key(s) for machine SSL certificate, and enter the output directory. In the example below we are using the /tmp directory. Fill in the required values for the certool.cfg file.

Cert_Tool_2

The CSR and key are generated in the location specified. Change the shell to /bin/bash using chsh -s "/bin/bash" root and open an SCP connection to the VCSA using WinSCP. Copy the vmca_issued_csr.csr file to your local machine, you can use Notepad to view the contents of the file. Leave the WinSCP session open as we’ll need it to copy the certificate chain back to the VCSA.

Request Certificate

The next step is to use the CSR to request a certificate from your internal Certificate Authority (official KB here). A Microsoft CA template needs creating with the settings specified here (official KB here) before requesting the certs. Once this is done open a web browser to the Microsoft Certificate Services page (normally https://CAServer/certsrv) and select Request a Certificate.

Internal_CA_1

Then we want to Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file. The next page allows us to enter the CSR generated earlier to request a certificate with the pre-configured vSphere 6.5 certificate template.

Internal_CA_2

Click Submit and then select Base 64 encoded and Download certificate and Download certificate chain. A .cer file will be downloaded, I have renamed this machine_name_ssl.cer, and a .p7b. Double click the .p7b file to open in certmgr, locate and right click the root certificate, select All Tasks, Export. Export the root certificate in Base-64 encoded X.509 (.CER) format, in this example I have named the file Root64.cer. Using WinSCP copy the machine and root certificate files to the VCSA.

Install Certificate

Go back to Certificate Manager and enter 1 to continue to importing custom certificate(s) and key(s) for machine SSL certificate. Enter the file for the machine SSL certificate we copied, I have used /tmp/machine_name_ssl.cer. Enter the associated custom key that was generated with the CSR request, in this case /tmp/vmca_issued_key.key. Finally, enter the signing certificate of the machine SSL certificate, in this case /tmp/Root64.cer. When prompted enter y to replace the default machine SSL certificate with the custom certificate.

Cert_Tool_3

The certificate will now be installed, when finished a success message will be displayed. If certificate installation fails at 0% see this KB article.

Cert_Tool_4

To verify the machine certificate open a web browser to the vCenter FQDN, the connection will now show secure. Depending on the browser used you can view the certificate properties to verify it is correct, alternatively browse to https://vCenterFQDN/psc and log in with an SSO administrator account. Open Certificate Management and Machine Certificates, select the installed machine certificate and click Show Details, verify the certificate properties are correct.

Certificate_Management

Solution User Certificates

Repeat the steps above for the solution user certificates (official KB here). Replacing the solution user certificates may break some external plugins, such as SRM, in which case you should review this KB article for corrective action. To recap: /usr/lib/vmware-vmca/bin/certificate-manager. This time select option 5 replace solution user certificates with custom certificates. Generate the CSRs and keys, you will notice that for the solution user certs 4 CSR and key files are created; machine, vsphere-webclient, vpxd, and vpxd-extension.

Cert_Tool_5

Using WinSCP copy the files to your local machine and repeat the certificate request process from the Microsoft Certificate Services page. Copy the new certificates to the VCSA and repeat the install process. Solution User certificates can be viewed on the PSC web interface under Certificate Management, Solution User Certificates.

Solution_User_Management

Altaro VM Backup 7.5 Install and Overview

In this post we will install and configure Altaro VM Backup 7.5 whilst taking a look at the some of the key features. Version 7.5 introduces cloud backup to Azure and restore from Azure to Altaro instances in different locations. The Cloud Management Console (CMC) allows for users to monitor and manage all installations of Altaro through an intuitive and easy to use web client accessible anywhere. Support for vSphere 6.5 is also now included, for a full list of the new functionality see this post.

Overview

Altaro allows users to backup VMware and Hyper-V environments; taking application and file consistent backups of Windows, Linux, and applications compatible with the Microsoft VSS writer including Exchange and SQL. Backups benefit from compression, inline deduplication, and military grade encryption configurable right down to individual VM level. Granular restores also allow for individual file or email restores, as well as sandbox restores. Furthermore Altaro’s unique Backup Health Monitor proactively monitors backups and automatically repairs or replaces any corruption as part of the next backup job. Advanced automation and reporting can be configured using Altaro’s built in REST API. Altaro has easily accessible pricing and licensing information, and multiple channels to engage technical support including live chat from within the management console itself.

  • See the graphic below for a summary of Altaro features for each licensing option. For full product, version, and pricing information click here.
  • The Altaro VM Backup Quick Start Guide can be reviewed here, and full product user guides here. Altaro Support and FAQ can be accessed here.

Versions

Install

The installation of the main backup console is simple and quick. Download the installer to a Windows machine and run as administrator. Accept the license agreement, set the destination, and hit Install. Altaro VM Backup can run on 64 bit versions of Windows 7, 8, or 10, and Windows Server 2008 R2 through to Windows 2016 (including Hyper-V and Core versions).

Once the install has completed open the management console. The VM Backup management console offers an intuitive user interface, allowing for local or remote management of multiple Altaro instances. In this example we’ll connect to the instance running on the local machine.

Altaro_Console_1

After connecting to the new instance the dashboard will load with a handy quick setup workflow.

Altaro_Console_2

Step 1 is to add the hosts to backup. In this example we’re using VMware so after clicking Add Hyper V / VMware Host select VMware vCenter Server and Next.

Altaro_Console_3

Enter and validate the vCenter Server information using Test Connection, click Next.

Altaro_Console_5

Review the hosts detected and click Finish. The hosts and inventory information from the specified vCenter Server are now added to the management console. We can see the host status and number of VMs for each host that has been added.

Altaro_Console_6

The product comes with a 30 day fully functioning trial. At any time you can install a license key by clicking Manage License under Setup and Hosts.

Step 2 is to configure a backup location, this can be a physical drive or network path. From the dashboard workflow click Choose Where to Store Backups.

Altaro_Console_7

For the purposes of this lab installation we will use the data drive of the Windows server.

Altaro_Console_8

Multiple backup locations can be added. Once a backup location is configured you can drag and drop VMs, clusters, datacenters, or vCenters into the appropriate area. After adding a local or LAN based backup location you can also add an offsite location, such as a WAN or Azure target. When the objects you require backing up are all assigned a backup location click Save Changes.

Altaro_Console_9

The final step in the workflow is to take our first backup, to take an on demand backup straight away click Take First Backup. Backup schedules and retention policies can be configured from the navigation menu on the left hand side. You’ll also notice Notifications and Advanced Settings where deduplication, encryption, and CBT can be configured on a per object basis, as well as providing the ability to exclude certain drives. Application consistent backups and truncating logs can be enabled under VSS Settings.

Cloud Management Console

The Cloud Management Console (CMC) can be accessed here. When you first login the getting started dashboard will be displayed, use the workflow to link an Altaro VM Backup installation.

Altaro_CMC_1

A one time access key is generated to link the Cloud Management Console with the Altaro VM Backup installation. From the management console click the CMC button and enter this code to pair the installation with the CMC.

Altaro_CMC_3

Once CMC is paired with your Altaro VM Backup instance you can monitor and manage the backup environment using the web client. Multiple installations can be added to CMC.

Altaro_CMC_2

Configuring vRealize Automation with vRealize Log Insight

In this post we will walk through integrating vRealize Automation with vRealize Log Insight to monitor and collect events for the vRA management stack. The following example we will be based on vRealize 7.3 with Log Insight 4.5, but the process has been validated with vRealize 7.x and Log Insight 4.x. If you do not already have Log Insight installed see the vRealize Log Insight Install Guide, if you are also using NSX see the NSX with Log Insight Integration Guide.

The configuration process consists of installing the management pack for Log Insight, installing the Log Insight agent on the Windows components, configuring the built-in Log Insight agent on the vRealize Automation appliances, and creating Log Insight templates and filters to gather the required information.

Management Pack Installation

Browse to the IP address or FQDN of the Log Insight instance and log in using the admin account. From the drop-down menu in the top right select Content Packs and Marketplace. Locate VMware – vRA 7 and click Install.

mp1

The management pack is now installed, review the Setup Instructions and click Ok.

mp2

Log Insight Agent Installation

From the drop-down menu in the top right again, select Administration. Under Management open the Agents page.

agents1

Select Download Log Insight Agent. Select the Windows MSI and copy the file to the Windows servers in the vRA management stack, in this case the IaaS Web and Manager servers, DEM, and Agent servers.

  • Right click and Install the file.
  • Accept the license terms and click Next.
  • Confirm the Log Insight server is auto-populated and click Next.
  • The install will now run. Click Finish once complete.

Go back to the Agents page in the Log Insight web interface. You should see the servers start populating the detected agents table. Next we’ll configure the built-in Log Insight agent on the vRA appliances. If you need to re-install or upgrade the built-in agent see this KB.

Open an SSH connection to the vRA appliance using an SSH client such as Putty. If SSH is not enabled on the appliance you can configure this by browsing to https://yourappliance:5480 and enabling SSH under the Admin tab.

Browse to the correct location cd /etc

View the liagent configuration file more liagent.ini

Edit the file, press the insert key to start typing vi liagent.ini

Remove the semi-colon that is commenting out the hostname, protocol, and port lines. Enter the hostname of the Log Insight instance, leave the protocol and ports with the default settings. To save and exit the file use :wq

Restart the Log Insight service service liagentd restart

edit

Log Insight Configuration

Log back in to the Log Insight web UI. Now that the agents are all installed or configured you should see the corresponding servers populating the agents table under Administration, Management, Agents.

agents

Click the drop-down arrow next to All Agents. Locate the vRealize Automation 7 – Windows template and click Copy Template. In the filter field add the Windows servers running vRA components with the Log Insight agent installed. Scroll down to the Agent Configuration and review the build settings if you want to configure specific event collections or if you need to change the default install path for vRA. Click Save New Group.

agentconfig

Locate the vRealize Automation 7 – Linux template and click Copy Template. Repeat the process this time adding the vRA appliances to the configuration. Once complete you should have templates configured to monitor all servers in the vRA management stack.

templates

Go back to Dashboards. Under VMware – vRA 7 you will start to see events being collected by Log Insight.

dashboard