WilliamLam.com

How to restrict vSphere UI access while maintaining vSphere API functionality?

by // 2 Comments

Although I come across a fair amount of interesting and challenging questions posed by our customers, I have to say this is certainly one of the more stranger question that continues to surface every so often. The question itself is fairly straight forward, but what I find strange is the reasoning and justifications for needing such a solution.

In case the title was not a give away, the question is having the ability to restrict a set of user(s) from the vSphere UI while still allowing access to the vSphere API for these same user(s). To be clear, the behavior of vSphere is that if you have vSphere UI access, then you also have vSphere API access which is all based on the permissions a user or group has been granted. There is no way to distinguish or limit access between these interfaces including any vSphere SDK or PowerCLI usage which also relies on vSphere API access.

There may be valid use cases for needing such a capability, however from my experience in talking with our customers and field, it feels like this is an attempt to solve organizational and/or process issues. Let give you a few examples that I have come across over the years:

  • I need to prevent [team|individual] from using the vSphere UI, because they are not using the internal provisioning tools we have built
  • I need to prevent [team|individual] from using the vSphere UI, because they need to learn how to automate using the vSphere API
  • I need to prevent [individual] in [team] from using the vSphere UI, because they are making changes to VMs without filing support tickets
  • I need to prevent [individual] on my [team] from using the vSphere UI, because they are bypassing our change control policies

[Read more...]

Quick Tip - Changing the size of vSphere Dump Collector for VCSA 6.7 & 7.0

by // 1 Comment

When an ESXi host crashes, the generated core dump can be sent over the network to a remote core dump server. The vCenter Server Appliance (VCSA) can be configured as a destination by enabling the built-in vSphere Dump Collector service. By default, the storage repository for the vSphere Dump Collector service is configured to 2GB and can be increased up to 10GB, which is the supported maximum.

In earlier vSphere releases, configuring the vSphere Dump Collector repository size could be done using the vSphere Web (Flash) Client as shown in the screenshot below.

Configure and test of ESXi Dump Collector – Notes from MWhite
Screenshot courtesy from Michael White's blog post https://notesfrommwhite.net/2016/01/20/configure-and-test-of-esxi-dump-collector/

However, as part of the vSphere (HTML5) UI Client transition, it looks like all general VCSA service configurations including the vSphere Dump Collector was not ported over. I can only assume the reasoning for this was due to the infrequency configuring or updating these settings. This has been a question that has come up a few times across both VCSA 6.7 and 7.0 environments and I was recently reminded of the solution and I realized I had not blogged about the solution.

[Read more...]

Why does Deploy OVF Template operation show vpxd-extension-[uuid]?

by // Leave a Comment

A question that I had received awhile ago from a customer was how to identify the specific user(s) who have deployed an OVF/OVA? Customers can easily do this by leveraging vCenter Serve Events, which are extremely rich with information that can help answer this and many other questions you might have in your vSphere enviornment.


The first challenge that you will find is that an OVF/OVA import operation is mapped to a generic vCenter TaskEvent, which will require some additional filtering. Secondly, depending on the method that was used to deploy the OVF/OVA such as the vSphere UI or using Automation tools like OVFTool or PowerCLI, you will also slightly diffrent behaviors in terms of the vCenter Server Events that are emitted.

If you deploy an OVF/OVA using the vSphere UI, you may have noticed there are actually two vCenter tasks which are displayed and running simultaneously as shown in the screenshot above. The first task is called "Import OVF package" and you will see that this task is associated with the actual user who initiated the import. The second task called "Deploy OVF template" is then associated with a vCenter system account that handles the actual deployment which will show up with a vpxd-extension-[uuid] username. This occurs because the user who is performing the import is not interacting directly with with vCenter Server, but rather through the vSphere UI which uses a system account to then communicate the operation to vCenter Server.

For this reason, when an OVF/OVA is imported through the vSphere UI, you will need to look at the TaskEvent and filter for the initial import operation. If an OVF/OVA is imported using the vSphere API using something like OVFTool, PowerCLI or any other vSphere SDK, then you will only see the Deploy OVF Template operation and the user associated with that operation is the person who initiated the import.

Using PowerCLI and the Get-VIEvent cmdlet, we can easily filter out these two types of TaskEvents.

Get-VIEvent | where {$_.GetType().Name -eq "TaskEvent" -and $_.FullFormattedMessage -eq "Task: Import OVF package"}

Get-VIEvent | where {$_.GetType().Name -eq "TaskEvent" -and $_.FullFormattedMessage -eq "Task: Import OVF package"}