WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

Apple Mac Pro 6,1 PCIe SSD issue resolved w/ESXi 6.0 Update 2

03.15.2016 by William Lam // 6 Comments

Early last year, the new Apple Mac Pro 6,1 (aka black can design) was certified and fully supported on vSphere 6.0 which I had blogged about here. Several months later, customers discovered that some of the newer Mac Pro 6,1 units were shipping with different model of their PCIe SSD device than what was originally released at GA. This was problematic because ESXi was not aware of this newer device and could not detect during or after installation. Although a work around was identified for customers looking to install either ESXi 5.x or 6.x on the newer Apple Mac Pros, it definitely was not ideal.

It has taken a bit longer than expected, but the issue has now been resolved with the latest release of ESXi 6.0 Update 2. A similar fix will be available for customers running ESXi 5.5 in a future update. You can find the direct download for ESXi 6.0 Update 2 in link below which includes a pointer to the release notes in case you are interested in other fixes included in this release.

  • vSphere ESXi 6.0u2 - https://my.vmware.com/web/vmware/details?downloadGroup=ESXI60U2&productId=491&rPId=10348

Categories // Apple, ESXi, vSphere Tags // apple, ESXi, mac pro, ssd, vSphere 6.0 Update 2

Applying Custom Attributes beyond just Host & Virtual Machine Objects

03.09.2016 by William Lam // 5 Comments

I recently came to learn about a neat little tidbit from one of my readers, Ziad, regarding vSphere Custom Attributes. I had been a long time user of Custom Attributes when I was a customer and heavily used it in-conjunction with Automation. This is how many of our customers leveraged this capability, especially around provisioning and reporting use cases. Custom Attributes allows you to specify custom "keys" associated with either a Virtual Machine or an ESXi host object. Once these keys have been created, you can then assign object-specific metadata "values" to these objects. An example would be a Custom Attribute called "Application Owner" and for VM1 I can have a value of "Duncan Epping" and for VM2 I can have a value of "Alan Renouf".

Custom Attributes can be created using either the vSphere API or from the vSphere C# Client (currently not possible using the vSphere Web Client). The UI has already restricted Custom Attributes to either a Host, Virtual Machine or Global which means it applies to both objects as shown in the screenshot below. This has always been my understanding of how Custom Attributes work and has also been documented as such.

applying-custom-feilds-beyond-hosts-and-vms-0
Well, it turns out, this "restriction" was only a UI restriction. The actual Custom Attributes feature can actually be applied across variety of vSphere Objects and not just limited to Hosts and Virtual Machines when using the vSphere API. If we look at the Custom Attributes API which uses the customFieldsManager and specifically the AddCustomFieldDef() method which is used to create new custom fields. We can see that the moType property can accept any of the supported vSphere Objects such as the following:

  • ClusterComputeResource (Multi-ESXi host Cluster)
  • ComputeResource (Single ESXi host Cluster)
  • Datacenter
  • Datastore
  • DistributedVirtualSwitch
  • Folder
  • HostSystem
  • Network
  • ResourcePool
  • StoragePod (Datastore Cluster)
  • VirtualApp
  • VirtualMachine

I decided to quickly verify this by giving this a try in my lab and using PowerCLI (just one of the many options to the vSphere API) to exercise the Custom Attributes API against a Datacenter, Cluster, Datastore and Network object.

We start off by retrieving the CustomFieldsManager and then creating four new Custom Fields for each of the respective vSphere Objects that we want to associate with.

$customFieldMgr = Get-View ($global:DefaultVIServer.ExtensionData.Content.CustomFieldsManager)

# Custom Field Key names

$dcCFName = "DatacenterCF"
$clCFName = "ClusterCF"
$dsCFName = "DatastoreCF"
$netCFName = "NetworkCF"

# Create Custom Field Keys for Datacenter, Cluster, Datastore & Network objects

$customFieldMgr.AddCustomFieldDef($dcCFName,"Datacenter",$null,$null)
$customFieldMgr.AddCustomFieldDef($clCFName,"ClusterComputeResource",$null,$null)
$customFieldMgr.AddCustomFieldDef($dsCFName,"Datastore",$null,$null)
$customFieldMgr.AddCustomFieldDef($netCFName,"Network",$null,$null)

Next, we retrieve a Datacenter, Cluster, Datastore and Network object in our vSphere inventory and then call the setCustomValue() API which is used to set the value for a particular Custom Attribute that has been defined for that object.

# Set Custom Field for Datacenter, Cluster, Datastore & Network objects

$datacenterName = "Santa-Barbara"
$datacenterView = Get-View -ViewType Datacenter -Property Name -Filter @{"name"=$datacenterName}
$datacenterView.setCustomValue("$dcCFName","AB-123")

$clusterName = "Production"
$clusterView = Get-View -ViewType  ClusterComputeResource -Property Name -Filter @{"name"=$clusterName}
$clusterView.setCustomValue("$clCFName","BC-456")

$datastoreName = "datastore1"
$datastoreView = Get-View -ViewType Datastore -Property Name -Filter @{"name"=$datastoreName}
$datastoreView.setCustomValue("$dsCFName","CD-789")

$networkName = "VM Network"
$networkView = Get-View -ViewType Network -Property Name -Filter @{"name"=$networkName}
$networkView.setCustomValue("$netCFName","EF-012")

If we take a look at our vSphere Web/C# Client, we should see tasks being initiated on setting the custom value. So far, so good.

applying-custom-feilds-beyond-hosts-and-vms-1
Finally, it is time to retrieve these Custom Attributes to see if they were indeed properly set. We first need to build up a hash table of the key's name, so we can easily correlate the specific Custom Attribute name with the unique key ID. Next, we can then extract the Value property which extends CustomFieldStringValue and contains both the key which we can look up from our look up table and most importantly, the value which contains the data that we had set earlier.

# Retrieve Custom Field for Datacenter, Cluster, Datastore & Network objects

# Create Custom Field & Name lookup table
# Borrowed from my buddy Alan Renouf http://www.virtu-al.net/2009/05/29/powercli-on-steroids-custom-attributes/
$customKeyLookup = @{}
$customNameLookup = @{}
$customFieldMgr.Field | % {
$customKeyLookup.Add($_.Key, $_.Name)
$customNameLookup.Add($_.Name, $_.Key)
}

# Print the Custom Fields property for each vSphere Object

$datacenterView = Get-View -ViewType Datacenter -Property Name,Value -Filter @{"name"=$datacenterName}
Write-Host "`nDatacenter:" $datacenterName "has Custom Field:" $customKeyLookup[$datacenterView.Value[0].Key] "with value:" $datacenterView.Value[0].Value "`n"

$clusterView = Get-View -ViewType  ClusterComputeResource -Property Name,Value -Filter @{"name"=$clusterName}
Write-Host "`Cluster:" $clusterName "has Custom Field:" $customKeyLookup[$clusterView.Value[0].Key] "with value:" $clusterView.Value[0].Value "`n"

$datastoreView = Get-View -ViewType Datastore -Property Name,Value -Filter @{"name"=$datastoreName}
Write-Host "`Datastore:" $datastoreName "has Custom Field:" $customKeyLookup[$datastoreView.Value[0].Key] "with value:" $datastoreView.Value[0].Value "`n"

$networkView = Get-View -ViewType Network -Property Name,Value -Filter @{"name"=$networkName}
Write-Host "`Network:" $networkName "has Custom Field:" $customKeyLookup[$networkView.Value[0].Key] "with value:" $networkView.Value[0].Value "`n"

Here is a screenshot of running the above PowerCLI code and we can see the values match up with what we had set earlier. This is pretty awesome if you ask me!

applying-custom-feilds-beyond-hosts-and-vms-2
Some of you might be thinking, if Custom Attributes can be applied across different vSphere Objects, then why should I use vSphere Tags? Well, there are definitely some differences between the two today and I highly recommend you give this article a read first before continuing further. Although Custom Attributes may provide similiar behaviors to vSphere Tags, there is a lot of limitations that come with Custom Attributes. I do believe vSphere Tags is the future and when we bring vSphere Tags to parity with some of the use cases that Custom Attributes can only cover today only, it will be an even more powerful feature.

There are several major benefits to vSphere Tags over Custom Attributes. One they are multi-vCenter Server aware when joined to the same SSO Domain, which means existing Tags/Tag Categories are automatically made available versus Custom Attributes which are bounded by a single vCenter Server. vSphere Tags is also deeply integrated with VM Storage Policy and Content Library for provisioning which is lacking with Custom Attributes and require custom Automation to leverage its metadata. A single vSphere Tag can support one or more groupings to a given vSphere Object, where as Custom Attribute must be tied to a single object. Lastly, being able to globally search across various tagged vSphere Objects is trivial with vSphere Tags. For Custom Attributes, you would need to first identity the object which means you must search through all objects unless you know the one you are looking for first and then iterate through the list of Custom Attributes looking for the specific key and then finally the value. There is definitely still room for improving vSphere Tags, but I think it is definitely the more superior metadata system that customers should be looking at going forward.

One final note which I thought was interesting is that PowerCLI also provides a few cmdlets for managing Custom Attributes and it looks like they did in fact support different vSphere Object types as documented here. The only issue is that it does not cover all vSphere Objects that is possible and if you still may want to consider calling into the vSphere API from PowerCLI and by-passing the default cmdlets.

Categories // Automation, vSphere Tags // custom attributes, metadata, PowerCLI, tag, tagging

How to limit the number "Logical" CPUs in ESXi?

02.09.2016 by William Lam // 13 Comments

Last week I received a very strange customer inquiry in which they would like to limit the number of physical CPU sockets seen by ESXi. As you can imagine, my interest was piqued as this is usually not the type of request you hear from customers looking to actively reduce the overall computing power of their underlying hardware, especially if they have paid for it. After digging into the details a bit more, it turns out this is related to licensing.

The customer is running an application on a VM which is licensed by the total number of underlying physical CPU sockets of the server, regardless if they are actively being used by the application or not. The vendor shall be left nameless but I am sure some of you can make some educated guesses 🙂 The customer was in the process of performing a hardware refresh where they would be moving from a 4 socket CPU to an 8 socket CPU and they would be negatively impacted by this change from a licensing standpoint. I can understand their concerns, they have now just doubled their application licensing cost without actually benefiting from the actual hardware update.

Unfortunately, after a bit more research, I found that it is not possible to reduce or limit the number of physical CPU sockets from ESXi. The only capability that we do have today around this topic is to limit the number of Logical CPUs that ESXi can see. This capability is exposed as an ESXi Advanced Setting called VMkernel.Boot.maxPCPUS and by default, this is set to unlimited as you would expect. What this setting does is takes the total number of logical CPUs that you wish to expose to ESXi and then evenly distributes that across your physical CPU Sockets as best as it can.

You can change this setting using a variety of methods including the vSphere Web Client, vSphere C# Client, ESXi Embedded Host Client, vSphere API which includes ESXCLI & PowerCLI. One alternative which I have seen some postings online about which is the ability to turn off specific CPU sockets for certain hardware platforms by using the system BIOs, having said that, I have not actually seen any real confirmation that this is in fact possible.

Below are screenshots using the vSphere C# & ESXi Embedded Host.

limit-maximum-physical-cpu-in-esxi-0

limit-maximum-physical-cpu-in-esxi-1
If you prefer to to use the CLI either locally or remotely, you can run the following ESXCLI commands:

List the current configurations

esxcli system settings kernel list -o maxPCPUS

Set a new configuration

esxcli system settings kernel list -s maxPCPUS -v 4

limit-maximum-physical-cpu-in-esxi-2

Categories // ESXi, vSphere Tags // core, CPU, ESXi, maxPCPUS, socket

  • « Previous Page
  • 1
  • …
  • 67
  • 68
  • 69
  • 70
  • 71
  • …
  • 109
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Automating the vSAN Data Migration Pre-check using vSAN API 06/04/2025
  • VCF 9.0 Hardware Considerations 05/30/2025
  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...