Latest VMware tools package and version numbers

I was trying to figure out where can I find the latest VMware tools package and what build versions were released with what ESXi host build? And voila, all the information is already published by VMware.

The latest VMware tools package is always referenced at the following URL:

https://packages.vmware.com/tools/releases/latest/index.html

Where as if you need to know what VMware tools versions were released along with which ESXi host builds, then you can find that answer at the following URL:

https://packages.vmware.com/tools/versions

Advertisements

Windows 2003 VM Guest customization no longer supported

Today I deployed a Windows 2003 VM in a test infrastructure. I did not want to spend too much time installing and configuring the OS hence thought of using Windows 2003 instead of something like a Windows 10 or Windows 2016. ‘

Why  I still use and love to deploy Windows 2003 in my test environments? The reason is very simple:

  • Windows 2003 works very well in a nested environment
  • Windows 2003 virtual machine has a small  footprint does not require a lot of RAM nor does it require a lot of disk space.
  • Finally the important part; Windows 2003 was supported by VMware for guest customization under vCenter

Now here is twist in the story, I was trying the guest customization of Windows 2003 in vCenter 6.7 and guess what it failed. I did a bit of investigation why this was happening. I never expected VMware would stop supporting Windows 2003 guest customization under vCenter 6.7, but that’s exactly what the story is. VMware no longer supports Windows 2003 guest customization starting from vCenter 6.7

Here is the support document from VMware, that states Windows 2003 is no longer supported under vCenter 6.7:

https://partnerweb.vmware.com/programs/guestOS/guest-os-customization-matrix.pdf

 

 

Powercli oneliner for changing MTU to 9000

I wanted to set MTU on number of standard vSwitches across multiple ESXi hosts and Powercli made that job easier. Here’s a oneliner to get the job done across multiple vSwitches.

Get-VMHost My-ESXi-Host| Get-VirtualPortGroup "PG_SearchString*" | Get-VirtualSwitch | Set-VirtualSwitch -Mtu 9000 -Confirm:$false

 

 

Changing IP Address or hostname of the vCenter Server Appliance

A couple of days back during a discussion in a class, someone asked me if it is possible to change the IP Address of a vCenter Server appliance.

Short Answer:

Changing of IP Address is allowed. However changing of hostname (FQDN), also referred to as Primary Network Identifier (PNID) is not allowed.

Long Answer:

So the long answer, yes it is possible to change the IP Address of a vCenter server appliance after the deployment. (It is also possible to change the IP Address after a vCenter migration from a Windows instance to an server appliance.) One can change the IP Address by connecting to the Virtual Appliance Management Interface (VAMI) located at https://vcenter_server:5480.

Remember after changing the IP Address don’t forgot to update the forward and reverse DNS records.

There one corner condition when changing IP Address is does not work, this is specifically when one has configured a vCenter server appliance with an IP Address (without DNS records). In such cases it is not possible to change the vCenter server appliance IP Address.

However I don’t recommend changing IP Address of a vCenter instance after it has been deployed. Very simply there are many dependencies to take care of which can potentially break things in your environment. Hence always spend some time before deploying a vCenter instance and come up with a long term design strategy of  correct Hostname & IP IP Addressing policy.

Thumb rules for memory allocation across virtual machines

Here are some thumb rules (best practices) for capacity planning of memory (RAM) allocation within your virtual infrastructure. These rules typically work 90 times of 100, however there would be exceptions:

  1. If you have over committed your available physical memory on the hypervisor, then the maximum memory configured on any single virtual machine should ideally be less than 40% of the total physical memory. The total memory configured on a single virtual machine in exceptional cases may exceed up to 60%.
  2. Over commitment should typically be not more 30% of the total physical memory on aggregate virtual machine basis. Remember only powered on virtual machines are considered for over-commitment.
  3. On a per virtual machine basis never over commit more than the available physical memory on the hypervisor.
  4. Its a good idea to reserve 30% of virtual machine memory for server virtualization projects, or increase it to accommodate active memory.
  5. Ensure memory assigned is vNUMA balanced.

On physical machines its a good practice to buy all the physical RAM from one single vendor with identical specifications. Physical RAM should be purchased in configuration to populate all the DIMM slots across all the physical sockets.

What are Virtual Machine Templates?

In vSphere, Virtual Machine Templates are:

  • Virtual Machines that cannot be powered on
  • Virtual Machines that cannot be modified

Templates are like gold images, you create a template and deploy multiple VMs from them. Templates configuration files use an extension VMTX (virtual machines configuration files have an extension VMX). There are two easy ways to create a template:

  1. Clone an existing virtual machine (VM) to a template.
    – Creates a copy of an existing VM and registers it as a template.
  2. Convert an existing VM to a template.
    – Unregisters existing VM and registers it as a template.

Workflow for modifying a template:

  1. First convert the template to VM
  2. Optionally, make changes to the VM hardware (increase RAM, disk size etc.)
  3. Power-on the VM and install any new applications or updates
  4. After installing the application and updates, shutdown the VM
  5. Now convert the VM back to a template

Deploying Virtual Machines from Templates and Guest Customization:

When virtual machines are deployed from the template, they will identical to the template, things such as Windows-SID and hostnames would same. If using static IPs, those would also be same. This can create software and network conflicts.

To avoid such network or software conflicts, its recommended to customize the VM Guest during the deployment process. For Guest OS customization of virtual machines deployed from templates, vCenter requires the following:

  • If the guest OS is Windows, you need VMware Tools and Sysprep utils to be installed within the templates:
    • You will need to copy Sysprep tools to vCenter for Windows 2000, XP & 2003. Starting with Windows Vista onward, Sysprep tools are part of the base OS install. Where to copy Sysprep utils, read the following KB#1005593 article
  • For Linux VMs/Templates, along with VMware toools, you will also need Perl to be installed within your templates.

Best Practice: Always create templates for powered off virtual machines. Do not clone templates from a powered on virtual machines.

What is vCenter Single SignOn?

  • It is very similar to an Active Directory Domain Architecture
  • It is an authentication broker
  • It configures a vsphere.local domain (in vSphere 5.1 the local domain was called as “system-domain”)

The Single Sign-on (SSO) Architecture part of vCenter in vSphere 5.5 has following features:

  1. It uses a Kerberos type (token based) authentication mechanism
  2. It uses a Secure Token Protocol for Authentication
  3. You can create one-way trust relationships with existing Windows Active Directory Domains or OpenLDAP domains
  4. You can have multiple such trust relationships defined. Being able to define multiple trust relationships is very useful in a cloud enabled era.

One of the important things that you should remember is (and hopefully that would remove a lot a confusion) this vCenter Single Sign-on infrastructure is only used for authenticating users/groups to vSphere Infrastructure and applications that integrate with vCenter. It does not provide authentication services for desktops or other desktop/user applications. Or to say more correctly it is not a replacement for Active Directory Domain. In fact it works as a complementary solution to authenticate Active Directory users/groups to vSphere infrastructure.

In Single Sign-on infrastructure the default Single Sign-on administrator user is administrator@vsphere.local. This user is an administrator on both the vsphere.local Single Sign-on domain and the vCenter Server inventory.

  • On  a Windows based vCenter Server System, you set the password for this user  (administrator@vsphere.local) during the installation of Single Sign-on.
  • On a vCenter Server Appliance (Linux based virtual appliance) the administrator@vsphere.local get created and defined during the initialization/configuration of the appliance.