Automatic start up of network interface in CentOS 7

Today I installed CentOS 7 as a minimal install on my vSphere ESXi host. I had configured my virtual machine (VM) with a VMXNET3 network adapter. The good thing about this base minimal install of CentOS-7 is, that the network drivers are part of the base install. So essentially you don’t have to install VMware Tools to get the network adapter working. But the problem is the base minimal install of CentOS-7 by default only enables the loop-back adapter at boot. So the ens160 adapter does not (automatically) come up after boot.

This has nothing to do with the DHCP server not configured or the adapter requiring a static IP address. It’s a plain simple thing, that the ens160 adapter is disabled (probably for security reasons) on boot. To bring it up this network adapter you will need to login to the virtual machine and execute the following command:

ifup ens160

The interface will come up and get a DHCP IP address. However the interface will always need to be enabled manually after every reboot. If you want the interface to be automatically started after a reboot, then edit the following file:

vi /etc/sysconfig/network-scripts/ifcfg-ens160

and update the file to read as:


Keep all other settings as default, save the file and reboot. On the next boot the ens160 network adapter will automatically start with a DHCP IP address.



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
  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.