The numPorts value: <####> in spec exceeded maxPorts 8192


Today I was playing around with the vSphere Distributed Switch and trying to reach the configuration maximums of it by creating lots of dvPortgroups. But when I reached the port numbers above 8192, the dvPortgroup wasn’t created and I got the following error:

image

From KB1038193 I used the resolution to change the default max numPorts from 8192 to 20000. The 20000 value is also the one mentioned in the Configuration Maxium document: vsp_41_config_max.pdf so I don’t know why VMware used the 8192 max value. If anyone can explain why this extra limit if effective, please let me know.

The solution from KB1038193:

Symptoms
  • You cannot configure more than 8192 virtual ports in vCenter Server vNetwork Distributed Switch (vDS).
  • You see the error:
    The numPorts value : 8256 in spec exceeded maxPorts 8192.
Purpose

This article provides steps to increase the maximum number of vDS ports. 

Resolution
Changing the maximum number of vDS ports by using vSphere PowerCLI

vSphere PowerCLI can be used to automate the different virtual machine tasks. It provides an easy-to-use C# and PowerShell interface to VMware vSphere APIs. For more information, see the VMware vSphere PowerCLI Documentation.

To change the maximum number of vDS ports, you can use this PowerCLI snippet:

$dvs = Get-VirtualSwitch -Distributed -Name DVSName | Get-View
$cfg = New-Object -TypeName VMware.Vim.DVSConfigSpec
$cfg.MaxPorts = 20000
$cfg.configVersion = $dvs.config.configVersion
$dvs.ReconfigureDvs_Task( $cfg )

I have changed the code slightly to report the current configuration. you can use this script or the one from the KB article:

# dvSwitchName
$dvSwitchName = "dvSwitch01"

$dvs = Get-VirtualSwitch -Distributed -Name $dvSwitchName | Get-View
Write-Host "The current configuration of MaxPorts = $($dvs.Config.MaxPorts)" -for Yellow
$cfg = New-Object -TypeName VMware.Vim.DVSConfigSpec

# Org
#$cfg.MaxPorts = 8192

# New
$cfg.MaxPorts = 20000

$cfg.configVersion = $dvs.config.configVersion
$dvs.ReconfigureDvs_Task( $cfg ) | Out-Null

# Report new configuration
$dvs = Get-VirtualSwitch -Distributed -Name $dvSwitchName | Get-View
Write-Host "The new configuration of MaxPorts = $($dvs.Config.MaxPorts)" -for Green

Output:

image

Source: KB1038193

Advertisement

Release: vSphere 4.1 Update 1


Like many others already mentioned today: vSphere 4.1 Update 1 has been RELEASED!

I selected a couple of fixes from the release notes that made our life as a vSphere admin a lot better :

  • vCenter Storage Monitoring plug-in might not get enabled if vSphere Client 4.1 is connected to vCenter Server 4.0
    If you use vSphere Client 4.1 to connect to vCenter Server 4.0, and you then enable the vCenter Storage Monitoring plug-in, the Plug-in Manager Window might display an error similar to the following:
    The plug-in failed to load on server(s) vmvc38 due to the following error:
    Could not load file or assembly 'VpxClientCommon, Version=4.1.0.0, Culture=neutral, PublicKeyToken=7c8-0a434483c7c50' or one of its dependencies. The system cannot find the file specified.

    This issue is resolved in this release.


  • Performance Overview data might not display after upgrading to vCenter Server 4.1
    Performance Overview data for the past day, week, and month might not be displayed after upgrading to vCenter Server 4.1.

    This issue is resolved in this release.

  • Performance data might be missing for certain intervals after upgrading to vCenter Server 4.1
    After upgrading to vCenter Server 4.1 or every time that vCenter Server restarts, multiple threads might invoke the same stored procedure to process statistics in temporary tables (VPX_TEMPTABLE[1,2,3]) at the same time causing certain operations to not complete. This might lead to failure in collection of statistics. The performance data in the performance overview charts might be missing for certain intervals.

    This issue is resolved in this release.

  • Replacing SSL certificates in vCenter Server with custom certificates generated using OpenSSL 1.0.0 or later causes Storage Monitoring Service to fail
    For this issue, the following error is recorded in the sms.log files:
    Error constructing private key

    This issue is resolved in this release.
  • Search functionality might not display results if you use vSphere Client 4.1 to access vCenter Server 4.0
    If you use vSphere Client 4.1 to connect to a vCenter Server 4.0 system that is using vCenter Linked Mode, and you then perform a search function, the search results might not appear and might seem that the search function does not complete.

    This issue is resolved in this release.

  • vCenter Server alarm actions are triggered repeatedly even after the state of the alarm reverts to normal
    Some vCenter Server event and state-based alarm actions are triggered repeatedly even after the alert status reverts to green (normal).

    This issue is resolved in this release.

Grab your copy of vCenter Server 4.1 Update 1 here: VMware

 

I made also a short list of fixes in ESX:

  • Some virtual machines stop responding during storage rescan operation when any LUN on the host is in an all-paths-down (APD) state
    During storage rescan operation, some virtual machines stop responding when any LUN on the host is in an all-paths-down (APD) state. For more information, see KB 1016626 at http://kb.vmware.com/kb/1016626. To work around the problem in the KB, manually set the advanced configuration option /VMFS3/FailVolumeOpenIfAPD to 1 before issuing the rescan and then reset it to 0 after the completion of the rescan operation. The issue is resolved in this release. You need not apply the workaround of setting and not setting the advanced configuration option while starting the rescan operation. Virtual machines on non-APD volumes will no longer fail during a rescan operation, even if some LUNs are in an all-paths-down state.
  • Creation of large .vmdk files on NFS might fail
    When you create a virtual disk (.vmdk file) with a large size, for example, more than 1TB, on NFS storage, the creation process might fail with an error: A general system error occurred: Failed to create disk: Error creating disk. This issue occurs when the NFS client does not wait for sufficient time for the NFS storage array to initialize the virtual disk after the RPC parameter of the NFS client times out. By default the timeout value is 10 seconds. This fix provides the configuration option to tune the RPC timeout parameter using the esxcfg-advcfg -s <Timeout> /NFS/SetAttrRPCTimeout command.
  • Updates for the WDDM driver
    In this release, the Windows Display Driver Model (WDDM) driver is updated to fix some infrequent issues where a Windows virtual machine fails and displays a blue screen.
  • Cannot take quiesced snapshots of Microsoft Windows Server 2008 R2 virtual machine running vCenter Server 4.1
    When creating a snapshot of a Microsoft Windows Server 2008 R2 virtual machine that has vCenter Server 4.1 installed, the snapshot operation might fail to complete. This issue occurs on Microsoft Windows Server 2008 R2 virtual machines when the ADAM database is installed.

    The issue is resolved in this release.

Grab your copy of ESX(i) 4.1 Update 1 here: VMware

esxcfg-scsidevs–a output changed in vSphere 4.1


Last week I was busy converting one of my ks.cfg scripts which I use to install vSphere 4.0 update 2 to vSphere 4.1 and I found something, which I didn’t expect from VMware..

To find the iSCSI vmhba I use the following one-liner to save it into a variable VMHBA:

VMHBA=$(/usr/sbin/esxcfg-scsidevs -a |grep “Software iSCSI” |awk ‘{print $1}’)

But the this on-liner didn’t work anymore in vSphere 4.1. So I tried to run the script part by part and started with on a vSphere 4.1 host:

/usr/sbin/esxcfg-scsidevs -a

The following output was generated:

image

if you run the same command on a vSphere 4.0 update 2 host, you’ll see the difference:

image

So to fix this part of my ks.cfg I had to change the VMHBA one-liner and change the grep phrase to “iSCSI Software Adapater” instead of “Software iSCSI”:

VMHBA=$(/usr/sbin/esxcfg-scsidevs -a |grep “iSCSI Software Adapter” |awk ‘{print $1}’)

After changing this line, my ks.cfg script runs fine again. But the question remains unanswered; why did VMware change the output of esxcfg-scsidevs –a Winking smile.

How To: Configure vSphere 4.1 Active Directory Authentication


In this post I will show you how to setup Active Directory Authentication in vSphere 4.1.

What do we need tot do:

– Before you start. Please make sure that DNS and NTP are fully functional.
– Create an AD group called "ESX Admins" on a Windows Domain Controller
– Add users to that group
– Configure ESX/ESXi server’s "Directory Services"

If your ESX hosts and Active Directory Domain controllers are able to find each other via DNS, you’re ready to go to the next step of this setup. We need to create a group called “ESX Admins” and add the users with administrator permissions in vCenter to this group. When you choose a different name for the group, you will not be able to use Active Directory Authentication. I found this in the vsp_41_esx_server_config.pdf:

vCenter Server registers any selected Windows domain user or group through the process of assigning permissions. By default, all users who are members of the local Windows Administrators group on vCenter Server are granted the same access rights as any user assigned to the Administrator role. Users who are members of the Administrators group can log in as individuals and have full access.
Users who are in the Active Directory group ESX Admins are automatically assigned the Administrator role.

After creating the ESX Admins group it’s now time to join the ESX host to the Windows Domain. When you’re managing a small environment, you can do this with five a six mouse clicks per ESX host.

Continue reading “How To: Configure vSphere 4.1 Active Directory Authentication”