Category: VMware

Posted on by — Leave a comment

Cannot delete file [Datastore] vmkdump.dumpfile

If you face an issue during the deletion of a dump file that reside on a Datastore, you should deactivate the dump on the host and then try to delete it.

You can get a list of used dumpfiles on your ESXi host by connecting with ssh and performing the below command:

esxcli system coredump file list

This will output the dumpfiles that are currently in use, which will have true on the active column.

In order to de allocate the dump file you should unset the dump file and then retry to delete either by command or with the GUI. 

esxcli system coredump file set -u

The command that will force the deletion is the below:

esxcli system coredump file remove -f /vmfs/volumes/volume/vmkdump/11111111-2222-3333-4444-555555555555.dumpfile
Posted on by — Leave a comment

Cisco switch flooded with MAC Addresses VMware Distributed switch

Recently a client had a problem with some VM’s on its infrastructure. In more detail it was detected that some packets were missing/not transmitting correctly to some virtual servers.

The investigation of the vendor (Cisco) showed that the problem was due to a hard limitation of MAC addresses on the switch. It seemed that a limitation of 70.000 MAC addresses created this problem. But how so many addresses have been created on VMware infrastructure?

In the infrastructure two new chassis with Flex nodes have been added. Those chassis contain around 20 servers each that were included in the virtual Distributed switch. In the vDS existed around 210 VLAN’s. Everytime a new chassis was active on the switch around 3000 new MAC addresses created. This number is approximately the number of VLANs x host number = 20 x 210 = 4200

The problem occurred due to Distributed switch health check mechanism. As VMware states:

vSphere Distributed Switch health check helps you identify and troubleshoot configuration problems with the vSphere Distributed Switch (VDS), and mismatched configurations between the VDS and your environment’s physical network. By default, health check is turned off. You can enable health check to identify and resolve network problems you might be experiencing. Depending on the options that you select, vSphere Distributed Switch health check can generate a significant number of MAC addresses for testing teaming policy, MTU size, and VLAN configuration. These MAC addresses result in extra network traffic, which can affect network performance.

Important:

Use health check to troubleshoot network problems, and then disable it after you identify and resolve the problem. After you disable vSphere Distributed Switch health check, the generated MAC addresses age out of your physical network environment according to your network policy. For more information, see Knowledge Base article KB 2034795.

As a result only enable virtual distributed switch health check mechanism for troubleshooting and disable on production environments as it may cause problems on your VM’s.

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-6D155482-0743-4252-A8DC-3F608AB3654A.html

Posted on by — Leave a comment

Update Manager not working with VAMI proxy VCSA 6.7

On previous versions of vcenter server as vsphere 6.5 you had to enable proxy settings through VAMI in order to apply updates on your infrastructure (for non internet facing subnets)

You can locate your appliance VAMI endpoint from https://ApplianceIP/FQDN:5480

However by following the same procedure download manager on vcenter 6.7 was not able to download updates.

By checking the logs I could determine the

Connecting to vapp-updates.vmware.com failed cannot assign requested address.

/var/log/vmware/applmgmt/applmgmt.log

It seems that download manager is a different component on newer versions and cannot get internet connection through VAMI. You can see below the location on which configuration files and settings are saved inside the vcsa appliance.

In order to resolve issue I added proxy on download manager as shown on the below screenshot and updates could be downloaded.

Posted on by — Leave a comment

Extend Raw Device Mapping Disk – virtual compatibility mode on VMware

You can follow the below procedure to extend an RDM disk with virtual compatibility mode on VMware. As described in the article attached on the bottom, you can accomplish that either by migrating the RDM or by shutting down the VM and performing the procedure below. The article implements the shut down way.

The first step is to extend the RDM disk from storage. Find the UUID descriptor and provide some additional space.

Then you need to locate the VMware disk that you want to extend and record the SCSI controller and SCSI ID because it is needed on a later stage.

on my case SCSI target is 8

Then you should delete the disk from virtual machine. You can also select (delete files from datastore) as only the RDM pointer will be deleted and not the actual disk data.

After that you should rescan storage devices and volumes on the ESXi host and locate if the device has identified the new capacity.

in my case the new storage capacity is 150G

Then edit virtual machine settings and select add new device that will be of type RDM Disk

The next dialog shows the new disk with the extended capacity.

Click OK and be careful in order to add the same SCSI ID and controller as previously.

Perform a rescan inside the Operating system and the capacity will be available for use

https://kb.vmware.com/s/article/1007021