Recently I stumbled upon a limitation in VCF that isn’t very clearly documented, and while not an issue you would regularly come accross. It is an import limitation to be aware of if you plan to adjust your pNIC configuration of any VCF hosts post deployment/commisioning.

The Problem

We have a few customers who will not be able to commision their new hosts with the desired pNIC configuration due to current hardware availability. The availability of the pNICs due to global supply challenges has meant severe delays in availability.

On the 10th February VCF 4.4 was released, this was quite a significant milestone as it removed a few things from the equation and also provided more flexbility.

Firstly and arguably the big change.

vRealize Suite

vRealize Lifecycle Manager 8.6.2, upgrade and deployment of the vRealize Suite products is managed by vRealize Suite Lifecycle Manager. You can upgrade vRealize Suite products as new versions become available in your vRealize Suite Lifecycle Manager. vRealize Suite Lifecycle Manager will only allow upgrades to compatible and supported versions of vRealize Suite products. Specific vRealize Automation, vRealize Operations, vRealize Log Insight, and Workspace ONE Access versions will no longer be listed in the VMware Cloud Foundation BOM.

If you have spent any time designing IT soutions with VMware products you will very likely have come into contact with VMware Validated Designs (VVD)

VMware Validated Design is a family of solutions for data center designs that span compute, storage, networking, and management, serving as a blueprint for your Software-Defined Data Center (SDDC) implementation. The documentation of VMware Validated Design consists of succeeding deliverables for all stages of the SDDC life cycle.

vROps Remote Collectors - Design Considerations

Product Version - vRealize Operations 7.x and 8.x

As part of VMware Validated Designs tyically you would use Remote Collectors not just in different DCs but also local to the analytics cluster. However there are a circumstances where the rules “change”.

When using RecoverPoint or Site Recovery Manager

Design Assumption - you have Remote Collectors on your Primary Site and on your Failover Site.

As promised, I am posting the recording for the 5th Session of vROps Webinar Series 2016. Both Sunny and I successfully delivered the session on Design and Deployment considerations.

Session Details:- In this instalment of the series, we discussed the steps and thought processes that should be used before and during the design and deployment of vRealize Operations Manager. During the session among other things we will cover the planning, core components, correct sizing, HA, clustering, DR and future growth**.**

Time to announce the next part of the year long webinar series on vRealize Operations Manager. This time around, Sunny  and I thought about discussing Architecture of vROps. To some, it might sound strange as for smaller deployments you might not have to worry about Sizing and Architecture much since it is pretty simple to install and configure a small or a medium node for a small shop. However as your monitoring needs grow and you start adding solutions for monitoring data sources beyond vSphere, you would need to think about scaling up or scaling out. As your monitoring environment weaves into your incident ticketing system, you would start to see the need to HA of vROps and as you have a DR strategy for your workloads, you will start thinking about DR for your operations tools as well.

Given the flexibility in which you can choose to use and deploy vROps a question that frequently comes out is “is there a best practice?”

While that phrase is getting pretty tired it is still valid if you are just starting a design for a new vROps build or trying to make the best of a bad implementation. Rather than me trying to tell you how you should use vROps in your place of work I would direct you to a very useful PDF VMware have produced vRealize Operations Manager Reference Architecture .