vCenter

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.

 

Backup of VMware vCenter Server Appliance 6.5

It’s always a good idea to backup your work to provide you a way to recovery if things go wrong with your environment. Running an home lab I have cause my own share of issues many of times which had forced me to reinstall and configure my vCenter environment. Moving forward I will be taking advantage of the backup features included with the vCSA.

Using The vCenter Server Appliance Management Interface (VAMI) an administrator uses the HTML5 web interface to perform administrative tasks to the appliance configuration. These tasks included changing the host name, the network configuration, NTP configuration, applying patches / updates and performing backups.

Once logged into the VAMI, under the Summary tab, Click on “Backup” to start the backup of the vCenter Sever appliance.

There are options allowing you to perform a backup using different protocols and location settings. These include the following: FTP, FTPS, HTTP, HTTPS, SCP.

Next specify the protocol of choice and then the credentials for accessing the remote location where the backup will be stored. As an added option, you can encrypt the backup data before transferring.

Click Next

 

A minimum set of data needed to restore the appliance will be backed up by default. This includes the data such as OS, VC services, vCenter Server database, inventory and configuration. Historical data such as tasks, events, and alarms.

Click Next

You get a final review before you click Finish to start the backup process

Depending on the data size of the vCenter server appliance, backups will take a few minutes to complete.

When completed, Click on OK

 

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

[SOLVED] Unable to migrate VM’s to other host

I had encountered the following issue when attempting to migrate a live VM to another host w/in my lab cluster.
The error received was: 

Currently connected network interface” ‘Network adapter 1’ cannot use network ‘VM Network’, because “the destination network on the destination host is configured for different offload or security policies than the source network on the source host”.

I was able to fix this by checking the configuration of the virtual switch (vSwitch0) on the ESXi host I was moving the virtual machine guest to.

  1. I click on each host went to the configure
  2. Under the Networking subsection located the virtual switch
  3. Selected edit on that virtual switch.
  4. Reviewed the settings in the Security tab and the Traffic Shaping tab between the hosts.

In my case the issue was with the Security tab.  The destination host did not match the source.
Just another reasons to use host profiles between systems so that settings all match.

 

VMware vCenter 6/6.5: Creating Host Profiles

This post describes how to perform the basic task of creating a host profile.
Description of Hos Profiles:

VMware Host Profiles are available through VMware vCenter Server and enable you to establish standard configurations for VMware ESXi hosts and to automate compliance to these configurations, simplifying operational management of large-scale environments and reducing errors caused by mis-configurations.

Prerequisites:

  1. You need to have a vSphere installation
  2. You need to have admin rights
  3. You need a configured ESXi host that acts as the reference model

Steps:

  1. In vCenter Navigate to the Host profiles view
  2. Click the Extract profile from a host icon
  3. Select the host that will act as the reference model host and click Next
  4. Enter the name and  a description for the new profile and click Next
  5. Review the summary information for the new profile and click Finish
  6. The new profile will appear in the profile list

Video:

Done!