Home > Blogs > VMware TAM Blog > Tag Archives: vCenter

Tag Archives: vCenter

Third-party Plug-ins and vCenter Server Appliance (VCSA)

Petr_McAllisterBy Petr McAllister

As a consumer of VMware technology, would you prefer to install an OS on a virtual machine (VM), then deploy an external database, then install vCenter Server bits – or would it be more logical and enjoyable to deploy and maintain VCSA as a single entity?

For the first time, VMware has brought VCSA in parity with vCenter Server for Windows in terms of scale and functionality in vSphere 6. Take a look at the diagram below:

PMcAllister_Platform Diagram

After talking to my enterprise customers about moving to VCSA during their next vSphere upgrade, and getting them overly excited about a new, flexible way of managing their vSphere environment – the questions I received clearly led me to experimentation.

In traditional vCenter Server for Windows environments, many VMware partners provide their own MSI packages. These packages install plug-ins that can be called from the vSphere management interface. What happens to those plug-ins in VCSA’s world? Let’s take a look.

First, we’ll try the HPE package, and make sure we’re running a VCSA appliance. SSH to it and confirm the OS type. VMware Architect William Lam offers some advice on this in his post, “Quick Tip – Determining the vCenter Server OS platform (Windows or VCSA) using vSphere API.”

PMcAllister_vSphere PowerCLI

Now that we know for sure we are running VCSA, let’s start the installer on a Windows machine – let’s call it OpenView Administrator console.

PMcAllister_OneView for vCenter

During installation we need to provide the address of VCSA and its credentials.

PMcAllister_vCenter Information

Now, let’s connect to vSphere using an old-style client. All HPE plugins are visible when the client is pointed to VCSA, and the MSI plug-in package is used.

PMcAllister_Deployment Wizard

To confirm our findings, we can find different plug-ins from different vendors; what about EMC?

EMC has Virtual Storage Integrator products, which is not actually an MSI package, but is an appliance. Let’s now deploy it and see how to access it. After the template is deployed as a VM, the user is provided with a web interface where vSphere integration can be specified.

PMcAllister_Solutions Integration Service

More on installing and using EMC VSI can be found in Virtual Storage Integrator 6.6 is here!

Note: EMC does not create a shortcut on the home page. However, we can access EMC VSI information from the web client. Additionally, you will see in the green square, that HPE plug-ins that were installed in previous steps and are still available.

PMcAllister_vSphere Web Client

As we were able to successfully demonstrate here, there is no difference in behavior if the plug-in is working with VCSA, or the vCenter Server version for Windows.

It’s totally up to the vendor to either provide an MSI package that requires a Windows machine to install on (not vCenter OS), or the plug-in can arrive in the form of an appliance. It is also the vendor’s choice on how the plug-in is presented in the vSphere interface, whether through a web client, or a traditional vSphere Client.

To learn more about VCSA installation and configuration please refer to the vSphere Installation and Configuration Guide. As a huge fan of William Lam his blog offers some advice, “How to remotely run appliances & other shell commands on VCSA w/o requiring SSH” for more information on the topic, and click here for a complete listing of all of William’s VCSA coverage.

Petr joined VMware in 2012 as a Senior Technical Account Manager based in Vancouver, British Columbia, Canada. Since then, he has worked with many customers and diverse industries in three cities on two continents. Petr is recognized as a vExpert 2016, holds multiple industry certifications including VMware VCAP/VCIX, Cisco CCNP, ISC2 CISSP and ITIL. He is a very enthusiastic supporter of Network Virtualization, and uses every chance he gets to discuss with customers a specialized offering called NSX TAM. Petr’s 20+ year technical background helps him to understand customer’s business needs and to find the right technical solution to address those requirements. Connect with him on LinkedIn and follow him on Twitter.

VMware Infrastructure Navigator

Antonin_PerronBy Antonin Perron

Have you ever questioned yourself about the environment you are responsible for and wondered how your servers and applications interact?

VMware Infrastructure Navigator (VIN) is a very powerful tool within VMware’s Cloud Management Platform that can answer such questions and provide application dependency mappings across your environment. Unfortunately, VIN is often forgotten in discussions. Why? Great question! VMware needs to do a better job of showing its value and ensuring our customers utilize this forgotten gem in our toolset. Application dependencies mapping is lacking from competitive Cloud Management offerings, so VIN is a differentiator that could provide tremendous value when trying to deploy and secure applications.


I have had various conversations with customers who are trying to find a quick and easy way to understand their applications workflow and how their environments are actually communicating at various levels, from a virtual and physical standpoint. Leveraging VIN will help in IT consolidation projects, workload migrations, defining firewall flows, and understanding communication from and to the virtual and physical environments.

Used in conjunction with other VMware products, VIN will help with architecture and design. As an example, when defining a disaster recovery (DR) fail-over plan within Site Recovery manager, knowing the applications workflow will help build that plan and prioritize application recovery by grouping the virtual machines. Finally, leveraging the network information (i.e. IPs, ports, services, etc.) captured by VIN will help define NSX distributed firewall (DFW) rules and implement micro-segmentation.


Virtual Infrastructure Administrators can leverage visibility of day-to-day operational management for quicker problem triage, proactive virtual environment resource planning, managing changes, accurate business continuity, recovery planning, and more.

VIN is provided in OVA format (single virtual machine appliance) and has a pre-built application database with easy and accurate labeling of application names and version numbers.

Application relationships extend to virtual machines, hosts, clusters, datastore folders, and virtual networks. VIN can map one hop away to gather information and offers the dependencies via maps and tabular presentations. It is also possible to extract the database information via PowerShell to an Excel format, helping you with internal and external communications. The following diagram shows incoming and outgoing dependencies for each object in the tree. Dependencies from the tabular and maps are exportable to a CSV format.


VIN Architecture and System Requirements

VIN registers with a vCenter server and installs a plug-in in the vSphere Web Client. It probes guest virtual machines with supported operating systems that are running compatible versions of VMware tools. Virtual machines must be powered on and accessible for VIN to gather the information. Data is inserted into the vCenter Inventory service with a default retention period of 72 hours, which can be extended if necessary.

APerron_Infrastructure Navigator Virtual Appliance

User-Defined Services and Application Definitions 

Services that are not part of the vCenter Infrastructure Navigator database are categorized as unknown services. VIN allows you to custom define unknown services within the database. Once defined, these services will be utilized for all discovered instances of the application.

From a VIN perspective, the manual application feature allows you to mark a collection of virtual machines with an application name. From a vCenter Operations Manager standpoint, it can then show the health of that application group, rather than individual virtual machines.

APerron_Infrastructure Navigator Virtual Manage Appliance

APerron_vCenter Operations Manager

VMware NSX and VIN

As mentioned, application definitions, customized services, and all the other information contained in VIN can help with NSX deployments. Using VIN will help to define security groups, tags, and IP sets necessary to develop micro-segmentation rules.

Similar to application definitions, security groups are a collection of assets or grouping objects in the vSphere inventory. They can be used to allow or deny security policies for applications and or solutions. A subset of virtual machines will belong to the same security group and can then be used in Source and/or Destination fields or be applied to other fields of DFW policy rules.

APerron_NSX Manager

Having the network information of all objects helps when defining a collection of IP addresses necessary to create the IP sets.

APerron_vSphere Web Client

For example, security tags can be assigned to virtual machines using the services, user-defined services, or the application definitions from VIN, for use in NSX DFW rules.

APerron_vSphere Web Client Manage

Important Links


Product documentation:

Antonin Perron is a Technical Account Manager for VMware based in Ontario, Canada. He has over 17 years of IT experience filling various roles and after 12 years, 5 overseas deployments as a Communications Specialist in the Canadian Armed Forces, he joined VMware in 2015. He works with Shared Services Canada, Government of Canada, as the only one VMware resource on site and he his using experience to provide technical guidance, optimization recommendations to facilitate their workload migration across their 43 departments.

Platform Services Controller (PSC) and vCenter Server 6 Maximums

Petr McAllisterBy Petr McAllister

One of my customers successfully completed the VMware vSphere: Fast Track [V6] class. The customer provided a lot of positive feedback in regards to the class, and also about new functionality in vSphere 6. However, one thing was unclear: The instructor stated there is a maximum of 10 VMware solutions per vCenter. So the question was, “When we run a complex environment with multiple vCenter servers, vRealize Operations servers, vRealize Automation, vRealize Orchestrator, Site Recovery Manager and backup appliances, how can we fit all those solutions under the 10-solution limit?”

Finding the correct answer was pretty straight forward; VMware has published a document called “Configuration Maximums vSphere 6.0,” and the information is right there. The document has very specific content on exactly what my customer was asking:

A VMware Solution is defined as a product that creates a Machine Account and one or more Solution Users (a collection of vSphere services) … At this time, only vCenter Server is defined as a fully integrated solution and counts against these maximums. Partially integrated solutions, such as vCenter Site Recovery Manager, vCloud Director, vRealize Orchestrator, vRealize Automation Center, and vRealize Operations, do not count against these defined maximums.”

It would be easy to conclude my blog post here, but the nature of my topic is a little bit different. Looking through the PSC section of the “Configuration Maximums vSphere 6.0” document can be somewhat confusing. You’ll notice different unit maximums, some of which are specified as “per vSphere Domain,” “per site,” or “per Single PSC.”



The best way to understand PSC maximums is via a diagram found in the VMware Knowledge Base (KB) article, “List of recommended topologies for VMware vSphere 6.0.x,” which is a brilliant source of information on its own.

PMcAllister PSC

Assume User A has access to all four vCenter servers. When User A is authenticated in the Single Sign-on domain (also known as vSphere domain), the user can:

  • Log in to Site A or Site B using the same credentials
  • See all four vCenter servers in the environment (because these vCenter servers are members of the same SSO domain)
  • Accomplish any task on any of the vCenter servers the user has permissions on, and perform operations that involve multiple vCenter servers as inter-vCenter vMotions

Just to be clear, here is another example: If User B has access to only one vCenter server, he/she will still be able to log in—with the same credentials—to any site that is in the same SSO domain and do any operation that User B has permissions for – but only in the permitted vCenter.

Now let’s move on to the “per single PSC” definition. The PSC can be installed as embedded on the same server with other vCenter components, but in this case, the embedded PSC serves only one vCenter server. For any multi-vCenter server and/or multi-site configuration, PSC has to be installed as an external module on a separate machine in order to serve multiple vCenter servers. But the external PSC has maximums that are specified in the “vSphere 6 Configuration Maximums” document. These limits were introduced to ensure your infrastructure functions at a good performance level.

The final term to explain here is “vSphere Site,” which is partially self-explanatory, but it would help to be a little bit more specific. The KB article “VMware Platform Services Controller 6.0 FAQs” has the best definition of a vSphere 6 site:

A site in the VMware Directory Service is a logical container in which we group Platform Services controllers within a vSphere Domain. You can name them in an intuitive way for easier implementation. Currently, the use of sites is for configuring PSC High Availability groups behind a load balancer.”

So in other words we expect the best possible connection between sites (in terms of latency and bandwidth); however, in case of connectivity issues, every site can be autonomous—for a while—serving with full functionality – with the exception of operations that require connection to another site. PSC will get synchronized when the connection is restored. You might have more questions on PSC in vSphere 6, and if you do, the KB article noted above will answer most of those questions, and reading it is certainly a good investment of your time.

Petr McAllister is a VMware Technical Account Manager based out of Vancouver, British Columbia, Canada.

VMworld 2015: Day 3 –TAM Customer Central Sessions

It’s tough to believe that VMworld US 2015 has nearly come to a close. Tonight, we’ll celebrate our experience with our customers at AT&T Park during the Customer Appreciation Event. Throughout the conference, we’ve had some great sessions and Wednesday was no exception. Today we heard from experts regarding the newly announced EVO SDDC solution, as well as discussed current and future options for vCenter High Availability.

EVO SDDC Best Practices

Presented by Anil Kapur, EVO SDDC Product Management and Jason Lochhead, EVO SDDC CTO, this session focused on the processes and automated best practice configurations that are built into EVO SDDC. Anil presented to a small, but very engaged group, and collected feedback from the audience throughout the presentation that will be used to prioritize the next round of automated services.

Anil highlighted the major challenges for customers implementing SDDC as the up-front setup, the bring-up and lifecycle management. The problem is that configuring a workload domain is non-trivial and complex, and that’s where EVO automation comes in. EVO SDDC is designed to work with EVO Racks, and automates the more common and time-consuming configuration activities. During the session, he showed a demo illustrating the process for creating an IaaS workload domain. The current built-in best practices handles IaaS, Big Data and VDI workload domain configurations.

Utilizing the EVO SDDC Manager UI, Anil was able to quickly define the availability, performance and security requirements from a list of dropdown parameters. These parameters, in turn, select, acquire and deploy the correct resources to meet the defined requirements automatically. Policies are then set automatically from the standard choices. For example, availability can be configured from simple requirements like Low redundancy, Normal redundancy and two levels of High redundancy. Behind the scenes, the automation allocates, configures and enables the appropriate resources to meet these availability requirements.

Anil also went through scenarios showing examples for a typical EVO Rack configuration and how to scale out the workload domains.

It appears the first workload domain automated best practices were right on the mark, as a poll of the attendees revealed that IaaS and SQL configurations were identified as the first and second most time intensive tasks, respectively.

Anil asked for suggestions from the audience about what other tasks they would consider their next challenges on SDDC. The number one response was Internet App Logic workloads, and overwhelmingly, the audience agreed that the ability to standardize and maintain consistent workload builds was the most important to them.

Keep EVO SDDC on your radar! More best practices for automation to standardize and save time are on the way!

vCenter High Availability

Madhup Gulati, VMware Product Manager for vCenter, discussed the current toolset and options for providing High Availability to vCenter in vSphere 6. There were quite a few interesting exchanges between Madhup and the audience regarding who was comfortable with the current options and who wanted better tools and capabilities. This initial discussion also showed that very few customers are using Oracle as the external database for vCenter, and also that quite a few customers are at least testing the vCenter Server Appliance (vCSA). In general, however, customers agreed that they wanted more capabilities to protect their vCenters.

Throughout the session we also discussed High Availability, specifically for the Platform Services Controller (PSC). The PSC is a critical component because it contains the Single Sign On (SSO) feature. Therefore, if there is a PSC failure, user and solution authentication will not be possible creating substantial usability issues within vSphere. Madhup reviewed PSC replication capabilities and the high availability topologies included supported load balancers. Finally, he provided a roadmap of what will be coming in future releases, which were very well received.

This session was very interactive and provided many insights into customers’ requirements and challenges as the criticality of vCenter and the Platform Services Controller has steadily increased. The audience learned how to better protect these components in vSphere 6 as well as the exciting new features coming in future releases.

Be sure to follow @VMwareTAM for all of the latest news, tips, and event information!

The Importance of Foresight: Disaster Recovery for the Modern Age of Finance

sergio_seabra_bwBy Sergio Seabra

In the ever-shifting world of finance, it has become increasingly important to prepare and cater for all contingencies. This is done to not only protect the institution, but customers as well.

It can be argued that the ability to maintain data availability is central to the endeavor. As such, in my little corner of the world, the powers that be stipulated that: in the event of any sort of major setback in a financial institution, the organization would have to provide the means (as well as proof), that a disaster recovery (DR) plan was not only in effect, but also, that a successful trial-run had already taken place.

These environments tend to be quite complex and while some may had already taken measures to, at the very least, have some form of DR, many were taken by surprise and unable to comply by the time the by-laws were published.

But in all fairness, even those that already had a DR plan in place still have had to deal with a predominantly manual process spanning dozens of operatives, and hundreds, if not thousands of manual steps.

In this turmoil, a shining beacon of hope presented itself, and vCenter Site Recovery Manager (SRM) is its name. I know; a little overdramatic perhaps, but in this particular context the importance of this single piece of software should not be understated.

By now most of you are aware of the product’s capabilities, but to be quite blunt, at the time of its release, it revealed itself as quite the lifesaver; it was a perfect fit for this new but most pressing requirement.

VMware already accounted for more than 90 percent of the virtual Datacenter footprint, and the mere possibility of automating most (if not all) of the tedious DR-required tasks, had all these institutions (quite literally) scrambling to deploy the solution.

After all, it seemingly brought order to chaos and more importantly, allowed for testing and reporting against the success of each iteration. Prototyping an entire multi-tier recovery became almost as run-of-the-mill as any other vCenter operation.

One would think that by nature, such capabilities would entail a very complex process, but the truth of the matter is this: at its most basic, the building blocks of SRM are quite straightforward, simply requiring some form of storage replication between sites, and the configuration of logical containers and associated boot procedures within SRM’s user interface.

The software even catered to an array’s process automation, managing all the needed built-in replication procedures (i.e., snapshot creation and removal, LUN presentation to the hosts, replication reversal, etc.).

And that was it! The market demanded it, and VMware was front and centre with a very feasible and elegant solution to what was until then, quite a complex and time-consuming procedure.

Of course, nowadays, the software’s capabilities have been greatly extended, and we can, for instance, interface with Orchestrator. In doing so, the possibilities are practically boundless, but still and at its very core, SRM maintains the same simplicity of configuration that provided such an effective time-to-market as when originally released.

To illustrate this point, I’ll leave you with the following infographic. In it, I depict the “meager 5” main levels of SRM requirements needed to establish a full and effective DR plan for any virtual workload.

SSeabra_SRM Objects

Sergio Seabra is a Technical Account Manager based in Portugal. He has a background in Electronics and Telecommunications, and has been employed in the IT field in one form or another for the past 20 years working on some of Europe’s largest telco projects. Currently, he is a VMware TAM engaged mainly with enterprise accounts.