Here’s What’s New in VMware vSphere and vCenter 6.7

Widenet is VCP Certified for VMware Products.
In many Article, we talked about Tips & tricks, or to solve problems, like here, or here. Now we will talking about a big news from VMware.

vSphere 6.7, released today, includes an update to both its hypervisor (ESXi 6.7) and management console (vCenter Server 6.7). This release shows that VMware Inc. is not content to let its hypervisor become a commodity, and that it’s possible to make incremental, evolutionary changes to a proven product and, moreover, that VMware is still making substantial investments in its hypervisor. The vSphere 6.7 beta, though NDA-constrained, has been available to the public since October 2017. Despite the fact that a lot of new features were baked into the 6.5 release, this release does make some nice incremental changes. Following are some of the most important changes included with vSphere 6.7.

Hardware Caveat
An important hardware caveat to be aware of is VMware has released an HCL for vSphere 6.7 that excludes some older, yet popular CPUs. If you’re thinking about running this release on an older system for development or testing first before placing it into production on your newer servers, make sure to check the HCL to ensure compatibility.

Single Reboot Upgrade
vSphere upgrades can now be completed with one single reboot. Prior to vSphere 6.7, major version upgrades took quite a while (although they could be done without disruption by transferring workloads by using the Distributed Resource Scheduler [DRS]). vSphere 6.7, on the other hand, allows you to do a “quick boot” where it loads vSphere ESXi without restarting the hardware because it only restarts the kernel. This feature is only available with platforms and drivers that are on the Quick Boot whitelist, which is currently quite limited.

VMware Configuration Maximum Tool
The most visible configuration maximum change in vSphere 6.7 is the number of devices that can be attached to a host. VMware has increased some of the other maximums.

vSphere Client
vSphere 6.5 eliminated the vSphere Client that ran natively on Windows (also known as the C# Client or Thin Client) in favor of the vSphere Web Client, which was Flash-based. Also introduced in version 6.5 was the vSphere Client, which replaced Flash with HTML5. vSphere 6.7 further extends the capabilities of the vSphere Client and will eventually replace the vSphere Web Client. It looks like the vSphere Client can do about 90 percent that the vSphere Web Client can do. In vSphere 6.5, VMware had a list of the functionalities not yet supported in the vSphere Client; hopefully the company will do the same for vSphere 6.7.
Figure 1 shows the main menu of the vSphere Web Client, and Figure 2 shows the main vSphere Client menu. Although the new client looks cleaner, and does seem more responsive than the vSphere Web Client, the location of some items has changed and some workflows will have to be adjusted accordingly with these changes. I wrote an article on the vSphere Client when it first came out that explains why VMware is switching to an HTML5-based client.

[Click on image for larger view.]Figure 1. 
The vSphere Web Client main menu.
[Click on image for larger view.]Figure 2.

vCenter Server Appliance

Now that the vCenter Server Appliance (VCSA) is functionally equivalent to the Windows-based vCenter Server, it would take a lot to convince me to use the Windows-based one instead of VCSA. Overall, I have found that the VCSA embedded database (PostgreSQL) performs great. Furthermore, the VCSA is very easy to update, and the Linux OS (Photon OS) is rock solid. As a side note, the VCSA can easily be monitored using vimtop (be sure to read my recent articles on using vimtop). You can also read my article about migrating from a Windows-based vCenter Server to a VCSA, as well as another article on using the built-in VCSA backup tool. The built-in backup tool in vSphere 6.7 offers more scheduling options for its VCSA backup tool than in vSphere 6.5. The Backup Scheduler tool (Figure 3) can be accessed from the vCenter Server Appliance Management Interface (VAMI). VMware is also stating that there are “phenomenal” performance improvements in vCenter operations per second, in reduction of memory usage and DRS-related operations.

[Click on image for larger view.]Figure 3. 
The Backup Scheduler tool.

Suspend and Resume of vGPU Workloads
vGPU allows you to carve up a physical GPU into multiple virtual GPUs that can be used by VMs. Although vGPUs were introduced with vSphere 6.0, the VMs that used vGPUs there were limited in what you could do with a VM that was using a vGPU. vSphere 6.7, on the other hand, removes some of these barriers, and now you can suspend and resume a vGPU-enabled VM.

For quite some time vSphere has had the ability to mask off CPU features so that VMs that were running on systems with newer CPUs could be vMotion to servers with older CPUs. This is called Enhanced vMotion Compatibility, or EVC. In vSphere 6.7 VMware has extended this capability to allow you to do this on a per-VM, rather than on an ESXi-host basis. This means that if you have VMs that you want to take advantage of CPU-specific features, and are willing to limit those VMs to CPUs that only have those features in your cluster, you can configure them to do so.

A per-VM EVC is set from the vSphere client by selecting a VM, going to the Configure tab and selecting Edit (Figure 4).

[Click on image for larger view.]Figure 4. Setting up a per-VM EVC.


Instant Clone
I’ve been a fan of using instant clones with virtual desktops—they’ve proven to be a big space saver, to use only a fraction of the disk resources compared to a full clone, and to allow VMs to be provisioned in seconds from a parent image. With vSphere 6.7, VMware has exposed the APIs that can be used to create instant clones. It looks like a straightforward process and I suspect that many people will figure out some very interesting ways to use the instant clone API.

ESXi Quick Boot
vSphere 6.7 introduces the Quick Boot feature, which allows a system to reboot in less than two minutes as it does not re-initialize the physical server BIOS. This can speed up operations that require an ESXi system to be rebooted; however, Quick Boot is only supported on certain systems and does not work with systems that have ESXi Secure Boot enabled.

Figure 5 shows two hosts, one with Quick Boot enabled and another without it enabled. By default, Quick Boot is enabled if the system supports it.

[Click on image for larger view.]Figure 5. 
The New ESXi Quick Boot feature is enabled by default if the system supports it.

Persistent Memory (PMem) Devices
vSphere 6.7 now supports the next generation of storage devices that use persistent DRAM memory, known as non-volatile dual in-line memory module (NVDIMM) devices. This technology is still in its infancy, but applications that require the lowest possible latency regardless of the cost will find this feature invaluable. PMem is presented to vSphere as either as vPMemDisk, which is treated somewhat like a datastore, or as a virtual NVDIMM (vNVDIMM), which is presented directly to guest OSes that can use NVDIMM devices.

Virtual Hardware Version 14
Virtual hardware is the abstract version of physical hardware to a virtual machine or, in essence, a virtual motherboard. As physical hardware supports more features, VMware builds new virtual hardware accordingly to emulate the physical version. vSphere 6.7 comes with a new virtual hardware, version 14. Version 14 adds support for NVDIMM, as well as Trusted Platform Module (TPM), Microsoft Virtual-based Security (VBS) and I/O Memory Management.

VMFS Datastores
VMFS3 datastores have been around for a long time, but VMware is now phasing them out. To assist with this transition, vSphere 6.7 automatically upgrades VMFS3 datastores to VMFS5 when they’re mounted. If you want to upgrade VMFS5 datastores to VMFS6 datastores, you’ll need to upgrade the datastore with vSphere Storage vMotion because an in-place upgrade of a VMFS5 to VMFS6 datastore isn’t possible.

As a side note, vSphere 6.7 supports VMFS5 and VMFS6; however, vSphere 6.0 and earlier systems only support VMFS5 datastores. As such, if you have an environment that contains vSphere 6.0 or earlier systems, you’ll want to only use VMFS6 datastores on systems that won’t be accessed by them.

Upgrading to vCenter Server 6.7
A specific order must be used when upgrading to vSphere 6.7. Check the documentation for the latest order and caveats, but the basic procedure can be carried out by first upgrading the Platform Service Controller (PSC), then upgrading vCenter Server and, last, updating the ESXi hosts.

Because upgrading directly from vSphere 5.5 to 6.7 isn’t supported, you’ll need to first upgrade from vSphere 5.5 to vSphere 6.5, and then finally to vSphere 6.7. It needs to be noted that an ESXi 5.5 host cannot be managed by VCSA 6.7. On the contrary, upgrading from vSphere 6.0 to 6.7 is supported. If you’re still running a window-based vCenter Server rather than a VCSA, VMware does offer a tool to assist you in the migration; be sure to read my article on using this tool.

Upgrading to ESXi 6.7
As mentioned earlier, ESXi 6.5 doesn’t support all the CPUs that ESXi 6.0 does, so be sure to check the HCL to unsure that your system is supported. Roughly speaking, what you’ll typically find supported, at the minimum, is a 2 core CPUs that were released after September 2006 and have NX/XD enabled. You can use the VMware Update Manager (VUM) to do an orchestrated automated upgrade. Alternatively, you can manually update the ESXi systems using an ISO image or esxcli commands or, if you use stateless host, you can use vSphere Auto-Deploy to update your servers. To see how to update an ESXi system using esxcli commands, be sure to read my article.

Wrapping Up
If I’m forced to pick one single standout feature in vSphere 6.7, it would have to be the instant clone API. I see this feature as a great enabler for the VMware ecosystem and VMware developers because the ability to spawn hundreds of identical VMs that only use a small amount of space in minutes has some mind-boggling use cases. However, with great power comes greater responsibility, and it will be interesting to watch the development of tools to manage and orchestrate these VMs over time.

Yes, instant clones is the gee-wiz feature in this release, but the rest of the improvements in this release prove that the hypervisor has room for evolutionary growth—and that VMware is serious in maintaining its leadership position in this regard.

Related Article: Here’s What’s New in vSphere 6.7

How To Extend Datastore Capacity in the vSphere Client

Use one of the following methods to increase a VMFS datastore:

  • Add a new extent. An extent is a partition on a storage device. You can add up to 32 extents of the same storage type to an existing VMFS datastore. The spanned VMFS datastore can use any or all of its extents at any time. It does not need to fill up a particular extent before using the next one.
  • Grow an extent in an existing VMFS datastore, so that it fills the available adjacent capacity. Only extents with free space immediately after them are expandable.

If a shared datastore has powered on virtual machines and becomes 100% full, you can increase the datastore’s capacity only from the host with which the powered on virtual machines are registered.


Required privilege: Host.Configuration. Storage Partition Configuration


Log in to the vSphere Client and select a host from the Inventory panel.

Click the Configuration tab and click Storage.

From the Datastores view, select the datastore to increase and click Properties.

Extend Datastore ESXi
Extend Datastore ESXi
Click Increase.

Select a device from the list of storage devices and click Next.

Extend Datastore ESXi
Extend Datastore ESXi
Extend Datastore ESXi
Extend Datastore ESXi


To add a new extent – Select the device for which the Expandable column reads NO.

To expand an existing extent – Select the device for which the Expandable column reads YES

Review the Current Disk Layout to see the available configurations and click Next.

Select a configuration option from the bottom panel.

Depending on the current layout of the disk and on your previous selections, the options you see might vary.


Use free space to add new extent – Adds the free space on this disk as a new extent.

Use free space to expand existing extent – Expands an existing extent to a required capacity.

Use free space – Deploys an extent in the remaining free space of the disk. This option is available only when you are adding an extent.

Use all available partitions – Dedicates the entire disk to a single extent. This option is available only when you are adding an extent and when the disk you are formatting is not blank. The disk is reformatted, and the datastores and any data that it contains are erased.

Extend Datastore ESXi
Extend Datastore ESXi

Set the capacity for the extent.

The minimum extent size is 1.3GB. By default, the entire free space on the storage device is available.

Click Next.

Extend Datastore ESXi
Extend Datastore ESXi

Review the proposed layout and the new configuration of your datastore, and click Finish.

Extend Datastore ESXi
Extend Datastore ESXi

What to do next

After you grow an extent in a shared VMFS datastore, refresh the datastore on each host that can access this datastore, so that the vSphere Client can display the correct datastore capacity for all hosts.

Related Article: Increase VMFS Datastore Capacity in the vSphere Client

Troubleshooting importing OVF Template into VMware ESXi

This post shows how to adapt a VMWARE OVA exported from Virtual BOX for a Virtual Machine, compatible with ESXi.

When you try to open an OVA with the VMware format on an ESXi you get the following error:

 “The OVF package requires unsupported hardware
Details: Line 25: Unsupported hardware family ‘virtualbox2.2’.”
Details: Line 25: Unsupported hardware family ‘_unsupported_version’.”


Uncompresse OVA Archive :

First off all uncompress the OVA archive (with a zip extractor like 7-ZIP)

You will get a directory with 3 files on it like this :

Modify the OVF file :

Open the *.ovf file (with Notepad+)

Change the following line :


By this one :


Modify the *.mf file and calculate the SHA1 hash of the modified OVF file:

Open the *.mf file which contains the SHA1 hash of *.ovf file. So you need to replace the value specified by the new SHA1 hash of .ovf file.

SHA1(VMFile.ovf)= 48432f9cb8b0bfa97098006abb390805449303be
SHA1(VMFile.vmdk)= ffa3500bc379a2e040badce315d6b3b06876d5a9

To calculate this hash you can use a tool like FCIV from microsoft. You can download it there :

>D:\FCIV\fciv.exe -sha1 "VMFile.ovf"
// File Checksum Integrity Verifier version 2.05.
da39a3ee5e6b4b0d3255bfef95601890afd80709 VMFile.ovf

So, put the new hash in the *.mf file and save it

SHA1(VMFile.ovf)= da39a3ee5e6b4b0d3255bfef95601890afd80709
SHA1(VMFile.vmdk)= ffa3500bc379a2e040badce315d6b3b06876d5a9

Maybe you may encounter other errors while importing the OVF template like:

Line XX: OVF hardware element ‘ResourceType’ with instance ID ‘5’: No support for the virtual hardware device type ’20’

This is a problem of SATA controller, change settings in ovf like this:

From this

<rasd:Description>SATA Controller</rasd:Description>

With this
<rasd:Description>SCSI Controller</rasd:Description>

Other problems could happen if in the <Item> is listed an audio card, you should delete whole line starting from


Then save again OVF file.

Remember that every time you save the ovf file, and you what to try to import into ESXi, you must generate the hash, replace the hash in the .mf file, follow the steps above.

Deploy the new OVF :

Now, you can deploy directly the new OVF file on ESXi.
On VSPHERE select :

File > Deploy OVF Template
Select your OVF file :

The following WARNINGS are raised but you can move forward.


So now you can deploy and start your VM.

Related Article: VIRTUALBOX OVA TO VSPHERE OVF | Uncompress a VMWARE OVA and modify its VM version | File Checksum Integrity Verifier

ESXi 5.x host becomes unresponsive during vMotion

Suddenly somehow we got a virtual machine which couldn’t be powered on, or ESXi 5.x host becomes unresponsive after attempting to migrate a virtual machine from VMware vCenter Server or configuration change fails.


  • VMware ESXi 5.x host becomes unresponsive after attempting to migrate a virtual machine from VMware vCenter Server;
  • Making a configuration change to the ESXi host renders the host unresponsive;
  • Migration fails at 13%;
  • Some of the virtual machines in the inventory become invalid;
  • vpxa fails to start;
  • You are unable to power on a virtual machine.


  • Connect to the ESXi host using SSH.
  • Check if SNMP is creating too many .trp files in the /var/spool/snmp directory on the ESXi host by running the command:
    ls /var/spool/snmp | wc -l

Note: If the output indicates that the value is 2000 or more, this may be causing the full inodes.

vmware result_ls root disk full, esxi, host, vmotion, snmp, trap, maintenance
vmware result_ls

To be sure check che disk root usage running this command

vdf -h
vmware disk root_usage
vmware disk root_usage

If the available space is less than 3-4Mb (or usage ‘USE’ over 90%), it could be a problem.

  • Delete the .trp files in the /var/spool/snmp/ directory by running the commands:

# cd /var/spool/snmp
# for i in $(ls | grep trp); do rm -f $i;done

CLEAN_TRP_SNMP results root disk full problems snmp

Related Articles: VMware KB | Wh33ly’s Blog

No Guest OS Heartbeats are being received error

When performing a vMotion migration, this compatibility warning is displayed:

Migration from source_server: No guest OS heartbeats are being received. Either the guest OS is not responding or VMware tools is not configured properly.

No guest OS heartbeats are being received
No guest OS heartbeats are being received


This warning indicates that the VMware Tools are either not installed or are not running in the virtual machine.

This message is safe to ignore when performing a migration.

To workaround the warning, perform one of these options:

  1. Ensure that the VMware Tools are installed in the virtual machine before performing a migration;
  2. Ensure that the virtual machine has been running long enough for the operating system to be completely started before performing a migration.
  3. Restart the VMware Tools service.

For Linux virtual machine, open shell/terminal and run the command:

  • /etc/init.d/vmware-tools restart


  • /etc/vmware-tools/ restart


  • service vmware-tools {start|stop|status|restart|force-reload}

For Windows virtual machine, frm RDP session or directly on machine:

  1. Click Start > Run, type services.msc, and press OK.
  2. Right-click VMware Tools Service and click Restart.

You can execute a remote restart of the “VMtools” service from remotely using SC command from command prompt:

sc.exe config “[servicename]” obj= “[.\username]” password= “[password]”

SC Syntax

 SC is a command line program used for communicating with the
 Service Control Manager and services.
 sc <server> [command] [service name] <option1> <option2>...

The option <server> has the form "\\ServerName"
 Further help on commands can be obtained by typing: "sc [command]"
 query-----------Queries the status for a service, or
 enumerates the status for types of services.
 queryex---------Queries the extended status for a service, or
 enumerates the status for types of services.
 start-----------Starts a service.
 pause-----------Sends a PAUSE control request to a service.
 interrogate-----Sends an INTERROGATE control request to a service.
 continue--------Sends a CONTINUE control request to a service.
 stop------------Sends a STOP request to a service.
 config----------Changes the configuration of a service (persistent).
 description-----Changes the description of a service.
 failure---------Changes the actions taken by a service upon failure.
 failureflag-----Changes the failure actions flag of a service.
 sidtype---------Changes the service SID type of a service.
 privs-----------Changes the required privileges of a service.
 qc--------------Queries the configuration information for a service.
 qdescription----Queries the description for a service.
 qfailure--------Queries the actions taken by a service upon failure.
 qfailureflag----Queries the failure actions flag of a service.
 qsidtype--------Queries the service SID type of a service.
 qprivs----------Queries the required privileges of a service.
 qtriggerinfo----Queries the trigger parameters of a service.
 qpreferrednode--Queries the preferred NUMA node of a service.
 delete----------Deletes a service (from the registry).
 create----------Creates a service. (adds it to the registry).
 control---------Sends a control to a service.
 sdshow----------Displays a service's security descriptor.
 sdset-----------Sets a service's security descriptor.
 showsid---------Displays the service SID string corresponding to an ar
bitrary name.
 triggerinfo-----Configures the trigger parameters of a service.
 preferrednode---Sets the preferred NUMA node of a service.
 GetDisplayName--Gets the DisplayName for a service.
 GetKeyName------Gets the ServiceKeyName for a service.
 EnumDepend------Enumerates Service Dependencies.

The following commands don't require a service name:
 sc <server> <command> <option>
 boot------------(ok | bad) Indicates whether the last boot should
 be saved as the last-known-good boot configuration
 Lock------------Locks the Service Database
 QueryLock-------Queries the LockStatus for the SCManager Database
 sc start MyService


(check status of the service)
sc \\you_server_name_or_ip query “vmtools”

(Stop the service)
sc \\you_server_name_or_ip query “vmtools”

(Start the Service)
sc \\you_server_name_or_ip query “vmtools”

From another server on the domain open a command prompt and type the following.
From another server on the domain open a command prompt and type the following.


validation succeed
validation succeed

If your issue continues to exist, reinstall VMware Tools to ensure that you are on the latest version.