FIlter vRealize Automation 6.2 has been released. This release although not a Major Version packs a pretty powerful punch. It’s loaded with new features and enhancements that you are all going to want. This release aims to add some features that solve some basic challenges that have been seen by many of you running the product in your production environments. Here is a breakdown of what is new in this release:
- vCloud Air EndPoint with support for Proxy Servers with vCloud Air
- Configurable email tempaltes
- Calendar of Events
- Use IaaS custom properties within Application Services (Application Services)
- Support for CloudFoundry as a deployment target (Application Services)
- vRealize Operations Integration including health badges in vRA Portal.
- XenDesktop 7.x Support
- Support for OpenStack Havana
- Ability to edit Custom Properties during approval time
- Scheduler for reconfigure operations
- Ability to change lease times to indefinite
- Enhanced Event and Audit Logging
- Log Bundle tool
- VM Disk Support for up to 60 disks (Previously 15)
- Improved Rest API
- API for Reservation Management
- Better control for DB log rollover
- Swap Space Custom Property to account for swap space on disk
- Filter Catalog by Business Groups
- Enhanced installation for easier HA deployments
- UI Performance Improvements
Continue reading “vRealize Automation – vRA (vCAC) 6.2 – vRealize Automation 6.2 released”
This is something that has been long sought after by many. The hardening guide is 38 pages long packed with hardening information for the vRA Appliance, IaaS Server, Identity Appliance, and Application services appliance. This document takes you through the hardening of the SLES 11, PostgresSQL, Windows Host including SQL Server, IIS, and Microsoft .Net. The hardening guide also covers the network security and securing communications between the vRA components.
The network security section of the guide includes a complete list of all the vRA components and the ports/protocols that are used by the component. Even if you are not ready to start creating a fully hardened deployment it’s worth taking a look at the guide and becoming familiar with the the communications between the different components.
Continue reading “VRealize Automation – vRA (vCAC) 6.2 – Hardening Guide Released”
I am frequently get asked “Should we deploy the vRealize Automation Identity Appliance or should we connect vRealize to the vCenter SSO server”? The answer to this really depends on what is important to you. There are pro’s and con’s both scenarios. Let’s look at the vRealize Identity appliance first.
vRealize Identity Appliance
The major benefit to running the vRealize Identiy appliance is that it is released as part of the vRealize Automation code stream. This is important because if new features are released in vRealize Automation that have dependencies on specific support from the SSO server the Identity Appliance will be updated with the needed support. This will allow you upgrade when a new version is released without having to worry about external dependencies.
The downside of running the vRealize Identity Appliance is the extra administrative overhead, especially of you are deploying an HA environment. It’s extra servers to support, backup, and maintain on top of the vRA Appliance, IaasS Server, and any deployed for DEM’s/Agents. Not a huge deal, but it’s something to consider.
Continue reading “vRealize Autoamtion – vCAC 6.x – Identity Appliance vs. vCenter SSO Server”
Have you ever needed more control over what custom properties get assigned to specific component machines of a multi-machine blueprint, or want to use the same component blueprints for all component machine of a multi-machine blueprint? The Ultimate Multi-Machine Blueprint Extension aims to help with that.
The Ultimate Multi-Machine Blueprint Extension allows you to utilize the same source component blueprint for multiple component machines while at the same time controlling which custom propertied get assigned to each of the components. This allows you customize each of them differently during deployment.
This extension works well with the Custom Hostname and the Custom vCenter Folders extension to round out the use of Multi-Machine Blueprints.
Example Use Cases:
- Use a single machine blueprint for all components of a multi-tiered multi-machine blueprint and customize the name of each component.
- Use a single machine blueprint for all components of a multi-tiered multi-machine blueprint and customize the guest agent actions of each component machine.
- Use a single machine blueprint for all components of a multi-tiered multi-machine blueprint and override the template for each component to deploy from a different source vCenter template for each component.
The goal of this extension is to limit blueprint sprawl and leverage the multi-machine construct to customize the component machines and rely less on customizing the single machine blueprints making them more re-usable.
This extension was designed and built as a collective effort by Tom Bonanno and Sid Smith. If you have any feedback please let us know.
- Define which component machines to apply custom properties to in a multi-machine blueprint.
- Utilize a singular blueprint for all component machines in a multi-machine blueprint.
- Fixed bug that caused properties with Multiple periods not to be processed properly.
Remember we have performed a large amount of testing, but this is a v1.0 extension so please test and let us know if you find any issues.
Continue reading “vRealize Automation – vCAC 6.1 – Ultimate Multi-Machine Blueprint Extension v1.0.2 – Updated”
Are you getting ready for the pending release of vRealize Automation 6.2 next week? If so you’ll want to make your first stop GitHub to download Brian Graf’svCAC62-PreReq-Automation.ps1 script. If you are not familiar with Brian’s PreREq automation scrip, it is a script that configures all of the needed requirements ion your Windows IaaS server prior to installing vCAC. Brian did a fantastic job with the creation of this, it is a must have if you are installing vCAC from scratch.
In this version he updated the script to account for vCAC 6.2 Pre-Requisites so head on over to https://github.com/vtagion/Scripts/blob/master/vCAC62-PreReq-Automation.ps1 to download the script and get familiar with it to be prepared for the pendinf release.
For those of you who have not seen this yet, it is a must have for anyone writing vCO workflows for vCAC. VMware’s own Dan Linsey build a set of pre-built workflows to help aid you in your own development efforts. The toolkit includes workflows for performing Create, Read, Update, & Delete Operations for vCAC custom properties for more than just virtual machine objects. IT includes support for the following:
- Build Profiles
- Business Groups
- Property Dictionary
- Virtual Machines
- and more
Top check out this incredibly useful toolkit head over to the VMware Communities and download it.
CloudUtil is a vRA(vCAC) repository management tool that is part of the vRA Designer. It actually is what you are launching when you run the designer. When run without parameters it launches the GUI Designer. It however has other functions that can prove useful from time to time.
For starters if you don’t have the Designer Installed you can get it by going to https://FQDNofvCACAppliance:5480 –> IaaS Install –> vCloud Automation Center Designer. When you install it make sure you put in the IaaS host, NOT the vCAC appliance hostname.
I frequently get asked how can workflow revisions be removed from the designer. The answer is they can, but you need a Development Kit license to do so with CloudUtil. Working in the designer you will come to find out that the revisions add up fast and before you know it you could have hundreds. I’m going to walk you through a way to remove the revisions without a Development License for CloudUtil.
Continue reading “vRealize Automation – vCAC 6.x – Removing workflow revisions from Design Center”
vCAC by default will place all provisioned machines into a vCenter folder named VRM. You can override this using the custom property VMware.VirtualCenter.Folder to tell vCAC where to place the provisioned machine. While this is great that you can tell vCAC where to place the provisioned machine it isn’t very flexible. I built the Custom vCenter Folder Extension to fix that and make folder placement as flexible as you need it to be. VM folder placement is just about organizing virtual machines. It provides a way to control access to these machines through vCenter as well. Many organizations control permissions to these environments using these folders and need to be able to place any machine where they need for these purposes.
Multi-Machine blueprints is another area where this extension adds value. You can control placement of virtual machines by defining the VMware.VirtualCenter.Folder property on a Multi-Machine blueprint folder, but all VM’s for all Multi-Machine apps are placed in the same folder creating confusion as to which VM’s belong to which Multi-Machine application. Now if you add NSX into the mix and you have Multi-Machine components spread all over the place with no way to easily determine which VM’s as well as NSX Edges go to which application.
When used with Multi-Machine blueprints the Custom vCEnter Folder Extension can place all component Virtual Machines as well as Deployed NSX Edge appliances in a folder named after the Multi-Machine application if you desire making it easy to identify related components of an application. This also allows you to easily permission vCenter access to the components of the application if necessary.
- Dynamic Folder Names based on custom naming scheme
- Multi-Machine folder placement including NSX Edge applince
- Automatic Multi-Machine folder removal when Multi-Machine app is destroyed
Continue reading “vRealize Automation – vCAC 6.1 – Custom vCenter Folder Extension”
One-to-One NAT environments allow you to perform both SNAT and DNAT for all machines provisioned behind and NSX Edge Gateway. For each machine provisioned onto the One-to-One NAT network an External IP is added to the Edge gateway for the NAT translation. The External IP is assigned from the External Network Profile that is assigned to the One-to One NAT Network Profile. Although the One-To-One NAT network will use NAT translation to communicate with the upstream networks (North – South) it is routed to other networks connected to the same NSX Edge Gateway. When deploying a multi-tier application that has multiple network tiers attached to an NSX Edge Gateway all the back-end networks are routable so it’s important no to re-use IP space across different Network Profiles.
In the below diagram there are three Multi-Machine apps. Each one has three web servers, two app servers, and two database servers. The database servers are on a private network, no NAT translation to the upstream networks. The App servers are using a One-to-Many NAT network where they are using SNAT to get access to the upstream network, and the Web Servers are using DNAT for both inbound and outbound traffic. You will notice that each of the Multi-Machine Apps are using the same Up address on the backend, however the IP’s assigned to the NSX Edge Gateway’s external interfaces are different. Notice for the One-to-One NAT that there is an equal number of external IP address. Lao notice in this scenario where we are using both One-to-One and One-To Many the external IP’s are on the same subnet. They all should come from the same External Network Profile that the related to the network that the NSX Edge Uplink interface is provisioned to.
Continue reading “vRealize Autoamtion – vCAC 6.1 – Creating a One to One NAT Network Profile”
Private networks have no upstream (North – South) NAT or routing when they are deployed. They are networks attached to the deployed NSX Edge Gateway that have East – West routing to other netowrks attached to the same NSX Edge Gateway and that is it. Due to this unlike the other NSX related Network Profiles we can create the Private Network Profile does not need to have an External Network Profile attached to it. It’s simply a range of IP’s to be used for the machines provisioned on to the network.
In the below diagram the blue network will be my private network. Machines placed on the blue network will only be able to communicate with machines placed on the orange or green network and not anything upstream. I can also limit it’s communications further by using security policies which we will discuss as a separate topic
Continue reading “vRealize Automation – vCAC 6.1 – Creating a Private Network Profile”