Protect VMs against storage problems using VMCP (VM Component Protection) on VMware vSphere 6.7

5. Testing the VM Component Protection (VMCP) feature

To test the VMCP functionality, we used a dedicated network for iSCSI (which is therefore separated from the management network).
If you wish to reproduce this test environment, refer to our tutorial: VMware vSphere 6.7 - Configure port binding (iSCSI traffic).
The management network used is "10.0.0.x" while the network dedicated to iSCSI traffic is "10.20.0.0".

The goal is to be able to cut the network connection between a specific VMware ESXi host and the iSCSI server where a virtual machine is running without cutting off access from the other hosts in the cluster to this same iSCSI server.

Here is a little overview of the configuration of our hosts so that you can better understand how they are configured for this VMCP test.
To start, we have the original standard virtual switch (vSwitch0) for the management network and that of the VMs.

Next, we created a new standard virtual switch with:

• 2 physical adapters that we added to the host
• 2 virtual networks to provide fault tolerance / load balancing for iSCSI traffic
• 2 VMkernel ports for iSCSI traffic between host and iSCSI server.

Given that the 2 dedicated VMkernel ports for iSCSI are located on the same subnetwork, a network port link must be configured (see tutorial cited previously).

As you can see, the datastore "iSCSI DS 1" is on our 1st iSCSI server "iscsi1" and there are 2 paths since there are 2 physical adapters assigned to our new virtual switch dedicated to traffic iSCSI.

The "iSCSI DS 2" datastore is on our 2nd iSCSI server "iscsi2" and there are again 2 paths for the same reason.

If you want to monitor your host's logs to see the different messages related to the APD status and the timer explained previously, do not forget to activate the "SSH" service on your host via the section: Configure -> System - > Services.

For the example, we ran our "VCSA" virtual machine stored on our "iSCSI DS 1" datastore via our "esxi1" host.

Then, we started our "Win 10 x64 v2004" virtual machine stored on our "iSCSI DS 2" datastore via our "esxi2" host.
Thus, we will be able to cut the network connection between our host "esxi2" and our ISCSI server 2 without VCSA being inaccessible and allowing VMCP to restart this VM on host 1 which will still be functional.

As you can see, at the moment the Windows 10 system properties window is displayed in this virtual machine.

Log in via SSH (using PuTTY, for example) as root to the host where you want to cut the connection for iSCSI traffic and type the command:

Bash

tail -f /var/log/vmkernel.log

To test if VMCP works, we virtually unplugged the network cable from the physical network cards dedicated to iSCSI traffic on host 2 (where our VM runs on Windows 10).
Note: in our case, we use VMware ESXi hypervisors virtualized on VMware ESXi.

On your cluster, you will see an error message appear for the host where you cut the network connection.

Plain Text

Lost network connectivity.

On the affected host, you will see the same error message, as well as the warning below.

Plain Text

The number of vSphere HA heartbeat datastores for this host is 1, which is less than the required number: 2.

Indeed, as explained in our tutorial "VMware vSphere 6.7 - Enable vSphere HA on a cluster", your cluster must have at least 2 datastores and at least 2 of these must be used for the heartbeat on storage.

On the page of the impacted virtual machine (in our case: Win 10 x64 v2004), you will see that an error has occurred on the affected host.

In the log file "/var/log/vmkernel.log", you will see this appear:

Plain Text

HBX: 6591: APD EventType: APD_START (3) for vol 'iSCSI DS 2'

Which indicates that an APD status has been detected for the specified datastore (in our case: iSCSI DS 2).