ESXi

vSphere 6.7 Configuration Maximums ESXi 6.7

VMware has updated some of the previous ESXi 6.5 maximums in the release of ESXi 6.7. Most of the usual CPU and memory specifications have stayed the same, but other changes are listed below.

For Example: Fault Tolerant VMs get another upgrade and can be now bumped to 8 vCPUs.

Virtual Machine Maximums 6.5 6.7
Persistent Memory – NVDIMM controllers per VM N/A 1
Persistent Memory – Non-volatile memory per virtual machine N/A 1024GB
Storage Virtual Adapters and Devices – Virtual SCSI targets per virtual SCSI adapter 15 64
Storage Virtual Adapters and Devices – Virtual SCSI targets per virtual machine 60 256
Networking Virtual Devices – Virtual RDMA Adapters per Virtual Machine N/A 1
ESXi Host Maximums 6.5 6.7
Fault Tolerance maximums – Virtual CPUs per virtual machine 4 8
Fault Tolerance maximums – RAM per FT VM 64GB 128GB
Host CPU maximums – Logical CPUs per host 576 768
ESXi Host Persistent Memory Maximums – Maximum Non-volatile memory per host N/A 1TB
ESXi Host Memory Maximums – Maximum RAM per host 12TB 16TB
Fibre Channel – Number of total paths on a server 2048 4096
Common VMFS – Volumes per host 512 1024
iSCSI Physical – LUNs per server 512 1024
iSCSI Physical – Number of total paths on a server 2048 4096
Fibre Channel – LUNs per host 512 1024
Virtual Volumes – Number of PEs per host 256 512

vSphere 6.5: OVF Import – The provided manifest file is invalid

Importing a template from vSphere 5.5 and importing to vSphere 6.5 the following error was encountered: The provided manifest file is invalidInvalid OVF checksum algorithm: SHA1

To get fix this error the following steps were taken:

Step 1 – is to extract your ova template (after all its only a zip)

You will notice 3 files once extracted

*.vmdk – is your disk containing all your data

*.ovf – is the configuration (also the file that we will edit)

*.mf – is a manifest containing a reference to the vmdk and ovf, also holding a SHA1 hash which ESXi will check for validation. This file needs to be deleted as we are making a change to the ovf and this will surely break that hash.

Example of what the contents of the .mf file looks like:

SHA1(template.ovf)= 908e804f140ffa58083b8bd154dace330b440c78
SHA1(template-disk1.vmdk)= 29c2d44d908d0207005360dabb58967f01a1

Step 2 – Delete the file with the *.mf extension. If this exists ESXi will attempt to validate and throw an error about the templates integrity being invalid. Once this has been deleted you can deploy your OVF Template.

Ref: http://jermsmit.com/unmount-local-iso-before-making-it-an-ovf-template/

Happy Importing

Cannot remediate host because it is part of HA Admission Control enabled Cluster

Recently my team and I ran into incident with and error while patching esxi servers using VMware Update Manager(VUM).  When attempting o remediate the following error message was shown:

“cannot remediate host because it is part of HA Admission Control enabled Cluster”

Cause:

vCenter Server uses admission control to ensure that sufficient resources are available in a cluster to provide failover protection and to ensure that virtual machine resource reservations are respected.

Admission control imposes constraints on resource usage and any action that would violate these constraints is not permitted. If an automated process needs to take actions, it might temporarily violate the failover constraints.

 

Solution:

Before patching of the ESXi Servers that are part of the HA Cluster, make sure you have disabled “Admission Control”. Once server has been patched you can re-enable Admission Control on the cluster.

 

Steps to disable Admission Control

  • Right-click the cluster and click Edit Settings.
  • Under Cluster Features, click VMware HA.
  • Under Admission Control, select Disable: Power on VMs that violate availability constraints.
  • Click OK

This can also be disabled in the VMware Update Manager remediation wizard. When you remediate check the option “Disable High Availability admission control if it is enabled for any of the selected clusters.

 

Tech Short: Modify vCenter Single Sign-On Password Policy

Warning:  I do not advocate that anyone to make modifications which extend outside of their organizations security policies. Doing so may put account security as risk.

By default, passwords associated with vSphere Single Sign-On expire every 90 days. As a user approaches this expiry point they will be reminded that their password is about to expire.

In my lab I wanted to avoid the need to change my password so frequently so I decided to extend the number of days required between password changes.

The steps below can be followed:

  1. Log in to the vSphere Web Client as a user with vCenter Single Sign-On administrator privileges
  2. Browse to Administration > Single Sign-On > Configuration
  3. Click the Policies tab and select Password Policies
  4. Click Edit
  5. Modify the “Maximum Lifetime”
  6. Click OK

Under the password policies you may take note of various options which can be modified based on your criteria or organization password policy.

Here are the password policy options:

 

Maximum lifetime:

Maximum number of days that a password can exist before the user must change it.

Restrict reuse:

Number of the user’s previous passwords that cannot be selected. For example, if a user cannot reuse any of the last six passwords, type 6.

Maximum length:

Maximum number of characters that are allowed in the password.

Minimum length:

Minimum number of characters required in the password. The minimum length must be no less than the combined minimum of alphabetic, numeric, and special character requirements.

Character requirements:

Minimum number of different character types that are required in the password. You can specify the number of each type of character, as follows:

  • Special: & # %
  • Alphabetic: A b c D
  • Uppercase: A B C
  • Lowercase: a b c
  • Numeric: 1 2 3

The minimum number of alphabetic characters must be no less than the combined uppercase and lowercase requirements.

In vSphere 6.0 and later, non-ASCII characters are supported in passwords. In earlier versions of vCenter Single Sign-On, limitations on supported characters exist.

Identical adjacent characters:

Maximum number of identical adjacent characters that are allowed in the password. The number must be greater than 0.

For example, if you enter 1, the following password is not allowed: p@$$word

 

Ref: ESXi and vCenter Server 5.1 Documentation > vSphere Security > vCenter Server Authentication and User Management > Configuring vCenter Single Sign On

Re: Why you should upgrade to vSphere 6.5 / ESXi 6.5

Recently I went to extend a volume on one of my guest systems and received an error requiring me to power off the system before extending the disk.

ErrorHot-extend was invoked with size (5368709120 sectors) >= 2TB. Hot-extend beyond or equal to 2TB is not supported. The disk extend operation failed: msg.disklib.INVAL

Good News – With vSphere 6.5 this is no longer a limitation.

Just one more reason why you should think about upgrading your VMware environment to the latest.