An error was received from the esx host while powering on vm

   Давно и плодотворно работаю с vMware, а вот вчера встретил преинтересную ошибку: На хосте в огромным количеством свободной памяти не запускались виртуальным машины, кроме того не выполнялись операции по миграции vMotion. Ошибка гласила. о нехватки памяти для запуска:

«An error was received from the ESX host while powering on VM W###.

Heap globalCartel-1 already at its maximum size of 7869288. Cannot expand.
Could not start VMX: msg.vmk.status.VMK_NO_MEMORY»

Особое внимание было обращено на то, что хоcты работали под кастомизированным образом ESX сервера от вендора поставщика аппаратной части (в данном случае HP).

Более того, не удавалось запустить даже элементарную службу SSH

Кроме того, подключившись к консоли  ESX можно увидеть следующею ошибку

Эта ошибка связана с утечкой памяти в драйвере, который отвечает за заполнение SWAP памяти на хосте VMware ESX. Именно из-за этого хост не смог выполнить простую команду по запуску SSH.

Как исправить:

Тут есть несколько вариантов: обновить версию  HP-AMS или удалить их)

Ввиду невозможности выполнить какие-либо манипуляции с хостом, его нужно будет перезагрузить, и только потом обновить версию HP-AMS.

1.  Первым делом рекомендуется обновить версию HP-AMS до последней, которую можно найти на соответствующем сайте.

Скачав дистрибутив пакета и разместив его на общедоступном хранилище установим соответствующее обновление

# esxcli software vib install -d /vmfs/volumes/<путь к обовлнеию>/hp-ams-esxi5.5-bundle-10.0.1-2.zip

После установки потребуется перезагрузка

Проверка установки:

# esxcli software vib list | grep hp-ams
hp-ams 550.10.0.1-07.1198610 Hewlett-Packard PartnerSupported 2014-12-08

Процедура удаления описана в KB2085618 и сводится к простым командам:

#  /etc/init.d/hp-ams.sh stop

# esxcli software vib remove -n -hp-ams

Как видно, исправить достаточно просто, но к сожалению работающие виртуальные машины не получится мигрировать на другие хосты, что повлечет к неприятной ситуации связанной с их остановкой)

Problem:

Unable to Power on Virtual Machine. It gives below Symptoms.

1. While attempting to power on giving below error.

«Power On virtual machine:Failed to lock the file

See the error stack for details on the cause of this problem.

Time: 10/9/2020 6:37:25 AM

Target: MYVM001

vCenter Server: MYVCENTER.MYDOMAIN.COM

Error Stack

An error was received from the ESX host while powering on VM MYVM001.

Failed to start the virtual machine.

Cannot open the disk ‘/vmfs/volumes/594d0000-d290000-500-00000000002/MYVM001/MYVM001-000002.vmdk’ or one of the snapshot disks it depends on. 

Failed to lock the file»

 Failed to open file ‘MYVM001-delta.vmdk’; Requested flags 0x4008, world: 1197120 [vmx-vthread-8], (Existing flags 0x4008, world: 43796 [unknown]): Busy

4. Command «vmkfstools -e vmfs/volumes/00000003-000230-000b-0123211000/VM001-000001.vmdk» shows below output.

Failed to open disk link /vmfs/volumes/5b4d1233-3e1234-1f5b-0123211000/VM001-000001.vmdk :Failed to lock the file (16392)Disk chain is not consistent : Failed to lock the file (16392) 

5. virtual machine disk descriptor file shows normal and CID chain is not broken.

Reason:

The VMDK or Delta VMDK is locked by one of the esxi in the cluster. Even if we move the VM in the particular Host, VM will fail to power on or consolidate disk.

To identify which disk is locked, refer the /var/log/vmkernal.log

Solution:

Identify the ESXI host which is currently have lock on the Delta vmdk or VMDK with below command. 

[root@I-MY-ESXI-01:/vmfs/volumes/152525252-26252526122-ED3455555555/MYVM001] vmfsfilelockinfo -p MYVM001-000001-delta.vmdk -v 172.11.13.3 -u administrator@vsphere.local

### -v  <vcenter IP>

### -u  <vCenter credential>

Output:

vmfsfilelockinfo Version 1.0

Looking for lock owners on «MYVM001-000001-delta.vmdk»

«MYVM001-000001-delta.vmdk» is locked in Exclusive mode by host having mac address [’00:20:b2:01:10:01′]

——————————————————————

Found 2 ESX hosts from Virtual Center Server.

——————————————————————

Searching on Host MY-ESXI-01.MYCOM.MYDOMAIN.COM

Searching on Host MY-ESXI-02.MYCOM.MYDOMAIN.COM

    MAC Address : 00:20:b2:01:10:01

Host owning the lock on the vmdk is MY-ESXI-02.MYCOM.MYDOMAIN.COM, lockMode : Exclusive

Total time taken : 0.38 seconds.

   Above output saying, disk is locked by MY-ESXI-02.MYCOM.MYDOMAIN.COM with MAC Address 00:20:b2:01:10:01.

Steps to Clear ESXi Lock:

1. Put the host in maintenance.

2. reboot the host.

Lock will be cleared during ESXi reboot and we will be able to power on or consolidate snapshot of VM.

В этой статье мы расскажем о возможных причинах, по которым не запускается виртуальная машина VMware Workstation. Мы рассмотрим самые распространённые ошибки, а также разберём, почему они возникают и как их исправить.

Ошибка VMware Workstation and Device/Credential Guard are not compatible

При включении VMware Workstation на Windows 10 может возникнуть ошибка со следующим текстом:

VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential Guard. Please visit http://www.vmware.com/go/turnoff_CG_DG/ for more details

Чаще всего эта ошибка возникает из-за того, что включено ПО Device Guard — оно помогает защитить систему от вредоносных файлов. Device Guard позволяет настроить список файлов, которые Windows будет считать безопасными. Если на компьютер попадут файлы, которые не входят в список, система автоматически удалит их. Работе VMware в таких случаях мешает компонент Hyper-V.

Как исправить

Чтобы исправить ошибку, отключите Hyper-V с помощью функционала «Выполнить».

Ошибка Cannot open the disk

Ещё одна распространенная ошибка при запуске виртуальной машины в VMware — Cannot open the disk. Её текст следующий:

An unexpected error was received from the ESX host while powering on VM.

На следующей строке будет указана одна из причин этой ошибки. Разберём, что означает каждая:

1) Failed to lock the file. Это значит, что процесс, который вы используете, не может открыть файл. При этом файл используется другим процессом. Что может привести к ошибке:

• при работе с ВМ вы пытаетесь запустить вторую ВМ, используя тот же VMX-файл,
• вы запустили ВМ с подключенным диском при помощи утилиты vmware-mount,
• вы добавили виртуальный диск к ВМ, которая уже используется.

2) The parent virtual disk has been modified since the child was created. Эта ошибка возникает, если повреждён снимок ВМ.

3) The destination file system does not support large files означает, что на целевом хранилище невозможно открыть файл ВМ того же размера.

4) Could not open/create change tracking file. Эта проблема может возникнуть, если файл filename-ctk.vmdk создавался ранее и не очищался перед созданием новой ВМ. Здесь filename — это название вашего файла.

5) Cannot allocate memory. Тот случай, когда в модуле VMFS не хватает места.

6) The file specified is not a virtual disk возникает в случаях, если повреждён .VMDK-файл дескриптора.

7) Insufficient permission to access file. Такая проблема может возникнуть при использовании хранилищ типа NFS. Она сообщает о том, что экспорт NFS работает неправильно, так как права на чтение и запись файла не даны либо даны некорректно.

Как исправить

Единого решения для этого типа ошибки нет. Чаще всего причина связана с локальными настройками компьютера. Рекомендации по исправлению ошибки описаны в официальной документации.

Unable to power on a virtual machine on an ESXi 5.0 host with the error: Unable to create a swap file. The value of ‘sched.swap.dir’ specified in the VM’s configuration file is invalid. (2119464)

Symptoms

The virtual machines datastore was migrated prior to the issue.Migrating the virtual machine to the original datastore resolves the issue.Unable to power on virtual machine with error:

An unexpected error was received from the ESX host while powering on VM vm-xxxxx.

1. Failed to power on VM.

2. Unable to create a swap file. The value of ‘sched.swap.dir’ specified in the VM’s configuration file is invalid.

Cause

This issue is caused after the migration of a virtual machine to a new datastore when the sched.swap.dir path is not updated in the virtual machine’s .vmx file.

Resolution

To resolve this issue manually updated the sched.swap.dir to the new datastore:

1. Connect to the ESXi host with an SSH session using root credentials.  For more information,  see Using ESXi Shell in ESXi 5.x and 6.0 (2004746)Navigate to the virtual machines directory on the ESX host with this command:

cd /vmfs/volumes/datastore/virtual_machine

2. Open the .vmx file with a text editor:

vi virtual_machine.vmx

3. Find the sched.swap.dir entry and update it the path to match were the virtual machine is currently located.

For Example:

sched.swap.dir = /vmfs/volumes/datastore1/testvm/

4. Reload the virtual machine on the ESXi host.  For more information, see Reloading a vmx file without removing the virtual machine from inventory (1026043).

5. Power on the virtual machine.

VMware KB: Unable to power on a virtual machine on an ESXi 5.0 host with the error: Unable to create a swap file. The value of ‘sched.swap.dir’ specified in the VM’s configuration file is invalid..

Introduction

This document describes a problem encountered on a Unified Computing System (UCS) platform with an E7 processor where the Open Virtualization Archive (OVA) template loads but the host does not boot.

Problem

Systems that run a UCS platform with an E7 processor sometimes experience a problem where the host fails to boot after the OVA template loads. This failure produces this error message:

    An error was received from the ESX host while powering on VM VaderServer1.
    Failed to power on VM.
    Could not power on VM : CPU min outside valid range.
    Group host/user: Invalid CPU allocation requested for VM vmm0:VaderServer1.
    (min: 5060 mhz, max: -1, minLimit: -1, shares: -3)

Solution

In Release 8.6(2) and later, Central Processor Unit (CPU) reservations are contained in the OVA. CPU reservation numbers are based on the Xeon 7500 processor which, when run on the E7 processor, are higher than the cycles available on a virtual CPU. Lab tests have determined that the 2.4 GHz E7 processor has the same performance as a 2.53 GHz Xeon 7500 processor; therefore, you can manually change the reservation numbers for 5,000, 10,000, or 20,000 deployment options on a virtual machine that runs on an E7 processor.

1. In the VMware vSphere Client, select the host on which the virtual machine was created.
2. Click the Summary tab under CPU chore. Note the available CPU cycles, in GHz, for one virtual CPU.
3. Power off the virtual machine on which you deployed the OVA template.
4. In the left pane of the  vSphere Client, right-click the name of the virtual machine and select Edit Settings.
5. In the Virtual Machine Properties dialog box, select the Resources tab.
6. In the Settings column, select CPU.
7. Under Resource Allocation, in the Reservation text box, enter the new reservation value (the number of CPUs multiplied by the available CPU cycles, in GHz, for one virtual CPU as determined in step 2).
8. Click OK to close the Virtual Machine Properties dialog box.
9. Power on the virtual machine.

Related Information

• Unity Connection Release 8.6.2
• Unity Connection Release 9.x
• OVA Template Details for Unity Connection Release 8.6.2
• Technical Support & Documentation — Cisco Systems