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.

Advertisements

Space Reclamation in VMFS 6

VMFS6 file system was in vSphere 6.5. Of the many new features introduced with VMFS6, one of the notable features is Automatic Space Reclamation.

Automatic space reclamation, also sometimes referred to as UNMAP is a feature that allows the hypervisor (vmkernel) to reclaim space when files (data) are (is) deleted from a virtual machine with a thin provisioned disk. The following video from VMware Tech Pubs provides an ease way to understand the same.

 

vSphere Swap files

In a vSphere environment, when from the command line you list the virtual machines files in a virtual machine folder; you find that there are 2 files with an extension vswp. So what are these files?

They are the Swap files associated with your virtual machine. And on a default installation of vSphere there are 2 swap files per virtual machines. They are:

  1. VM Swap file:
    VM Swap is created when a virtual machine is powered on and deleted on power off the VM. By default this file is created in the location where the VM configuration file resides. If VMKernel fails to create this file the VM will fail to power on.For additional details read:
    VM Swap file
    KB#2146618
  2. VMX Swap File:
    The second vswap file is created with a prefix vmx. This is the swap file for the overhead memory reserved for the VMX process. These VMX Swap files help in reducing contention when memory is over-committed.For additional details read:
    VMX Swap file

Both these swap files are automatically created by the VMKernel (ESXi host).

 

Find aggregate allocated VM CPU and Memory per host basis

Here’s a quick and dirty one-liner to find the total allocated CPU & Memory per ESXi host basis. This is useful when you want to get a quickly get your over-commitment ratios.

$TotalMem=0; Get-VMHost myESXiHost1 | Get-VM | ?{$_.PowerState -match 'PoweredOn'} | %{$TotalMem=$TotalMem+$_.MemoryGB};Write-Host $TotalMem
$TotalCPU=0; Get-VMHost myESXiHost2 | Get-VM | ?{$_.PowerState -match 'PoweredOn'} | %{$TotalCPU = $TotalCPU+$_.numCPU};Write-Host $TotalCPU

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.