failed to lock the file vmware что делать

20.11.202312.07.2022 admin 0 Comments

Ошибка VMWare: Unable to access a file since it is locked

Очень часто при удалении снапшотов или консолидации дисков виртуальных машин на хостах VMWare ESXi, я сталкиваюсь с ошибкой “Unable to access a file since it is locked”. Это довольна частая проблема связана с ошибками в системе резервного копирования ВМ (я встречал проблему в Veeam, HP Data Protector, Veritas). Блокировка виртуального диска снапшота виртуальной машины не позволит вам выполнить консолидацию (Virtual machine disks consolidation is needed), Storage vMotion на другой дисковый массив, выполнить резервное копирование или удалить текущий снапшот. Иногда виртуальную машины с блокировками нельзя даже элементарно включить.

Ошибка с доступом к заблокированному файлу виртуального диска или снапшот в VMWare может выглядеть так:

Так же вы можете увидеть такую ошибку:

Чаще всего ошибка “Unable to access file since it is locked” появляется:

Чтобы найти источник блокировки и снять ее, сначала нужно определить заблокированные файлы.

В строке RO Owner указан MAC адрес сетевой карты хоста ESXi, который заблокировал данный файл снапшота (MAC адрес выделен на скриншоте). Также обратите внимание на значение Mode:

Чтобы по известному MAC адресу найти ESXi сервер, можно воспользоваться следующими командами в PowerCLI (преобразуйте полученный ранее MAC адрес в формат с двоеточиями):

Имя ESXi хоста будет указано в поле VMHost.

Также вы можете вывести ARP таблицу прямо с хоста ESXi и получить IP и MAC адреса всех соседних серверов ESXi в сети VMkernel:

esxcli network ip neighbor list

Чтобы снять блокировку с файла ВМ просто перезагрузите найденный ESXi хост (предварительно смигрируйте с него все ВМ с помощью VMotion). Если вы не можете перезагрузить хост, перезапустите службу Management Agent (hostd) в Maintenance Mode из SSH консоли хоста:

После этого попробуйте выполнить консолидацию или удалить снашот ВМ.

Чтобы исправить проблему, откройте параметры ВМ, на которой установлен прокси Veeam. Удалите из оборудования ВМ диск ВМ, файлы которой заблокированы.

Убедитесь, что вы выбрали опцию “Remove from virtual machine”, а не “Remove from virtual machine and delete files from disk”. Иначе вы можете случайно удалить ваш vmdk диск.

Источник

VMware

Бесплатный продукт VMware Server является довольно мощной платформой виртуализации, которая может быть запущена на серверах под управлением хостовых операционных систем Windows и Linux. Основное предназначение VMware Server – поддержка малых и средних виртуальных инфраструктур небольших предприятий. В связи с небольшой сложностью его освоения и установки, VMware Server может быть развернут в кратчайшие сроки, как на серверах организаций, так и на компьютерах домашних пользователей.

Ранее этот продукт распространялся по коммерческой лицензии и носил название VMware GSX Server 3, однако, с ростом возможностей и продаж мощной платформы виртуализации VMware ESX Server, компания VMware не увидела перспектив в продажах платформы VMware Server, сделав в конечном итоге продукт бесплатным. Стоит отметить, что в отношении этого продукта VMware рассчитывает в основном на доходы от продаж Virtual Center for VMware Server, эффективного средства для управления виртуальной инфраструктурой на основе VMware Server, который обладает широкими возможностями по взаимодействию с виртуальными машинами и консолидации виртуальных серверов.

Вот основные варианты использования продукта VMware Server:

VMware Server обладает широкими возможностями по работе с виртуальными машинами, включающими в себя:

VMDK (Virtual Machine Disk) это формат файла разработанный VMware для использования в качестве образа диска в своих виртуальных машинах. VMDK схож по структуре и содержанию с жестким диском, является открытым и документированным.

Инсталляция

VMware Server на Fedora

Для виртуализации будет использоваться бесплатный VMware Server.

Устанавливаем обновление, предварительно распаковав.

Запускаем с правами root vmware-server-2.0.x-kernel-2.6.3x-install.sh. Он будет искать в текущей директории дистрибутив VMware Server, который мы туда предварительно скопировали.

В случае успешного завершения установки VMware скрипт выведет:

VMware Server 2 управляется через WEB-интерфейс. Доступ к WEB-интерфейсу через HTTPS(https: :8333) или HTTP (http: :8222).

Лечим ее созданием константы с версией в исходниках ядра. Добавляем #define UTS_RELEASE «версия ядра» в конец файла.

или перепишем эту константу из файла utsrelease.h

VMware Server на CentOS

Для виртуализации будет использоваться бесплатный VMware Server.

VMware Server 2 управляется через WEB-интерфейс. Доступ к WEB-интерфейсу через HTTPS(https: :8333) или HTTP (http: :8222).

Установить плагин для просмотра консоли().

VMware Server и USB

К USB нужно подключить выход от ATC и источника бесперебойного питания.

Инструкция ниже не позволила увидеть эти устройства в гостевой Win XP

Для того чтобы VMware Server 2.0.2 разрешил гостевым системам подключать usb устройства, нужно:

Snapshot снимок состояния VM

Источник официальный server_faq.pdf: How many snapshots can I take with Server 2 hosts?

Server 2 hosts support a single snapshot per virtual machine. In order to take a new snapshot, the previous snapshot needs to be overwritten.

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

В силу существования снапшотов существуют различные режимы для работы виртуальных дисков. А именно существуют независимые диски (independent), на которые снапшоты никак не влияют. Независимые диски могут работать в persistent (все изменения немедленно записываются на диск, и не откатываются даже при возврате к snapshot) и nonpersistent (все изменения откатываются автоматически при выключении машины или возврате к снапшоту). Обращаю ваше внимание, что nonpersistent диск будет возвращен к тому состоянию, в котором находился, когда мы поставили соотв. галочку в свойствах диска, а не к состоянию на момент снапшота.

Работа с ВМ через интерфейс командной строки: vmrun

Утилита vmrun позволяет автоматизировать управление виртуальными машинами. Кроме управления питанием виртуальных машин, с помощью этой утилиты можно взаимодействовать с файловой системой гостевой ОС, а также организовывать обмен файлами посредством общих папок, либо копируя их напрямую. Синтаксис использования vmrun.exe следующий:

Утилита vmrun может использоваться не только для локального, но и для удаленного управления виртуальными машинами. Для этого в качестве дополнительных параметров необходимо указать следующие флаги аутентификации:

Источник

Failed to lock the file vmware что делать

Симптомы:
Внезапно пропал доступ к виртуалке на vmware, нет ни пинга, ни RDP.

В vCenter виртуалка vm-name в состоянии «недоступна», на вкладке Tasks&Events – ошибка «файл конфигурации недоступен». Состояние виртуалки меняется на разные степени недоступности (unknown/unaccessible) туда и обратно каждые секунд 10.

Лечение:
1) При попытке зайти в Browse Datastore – DS_name – каталог и файлы виртуалки есть. При попытке скопировать файлы виртуалки vm-name.vmx или vm-name.vmxf – тупит и говорит «ошибка копирования», без подробностей. Кроме того, есть файл блокировки vm-name.vmx

. Предполагая блокировку файлов, выводим в maintenance хост ESXi где она лежала (host13) – нормальные виртуалки с него съезжают, а эта так и остаётся. Перезагружаем, не дожидаясь завершения входа в режим обслуживания – результата нет. Видимо, это не тот хост.

2) Включаем (configuration – security profile – services) ssh и ESXi shell на произвольном хосте, в автостарт переводить не надо, просто запустить (options – start). Заходим на хост по ssh, смотрим что файлы точно есть:

# cd /vmfs/volumes/DS_name/vm-name/
/vmfs/volumes/549030ba-7ff1cf81-677b-002 5b5060a27/vm-name # ls
vm-name-9462c45b.hlog vm-name.vmxf
vm-name-9462c45b.vswp vm-name.vmx

vm-name-flat.vmdk vm-name_1-flat.vmdk
vm-name.nvram vm-name_1.vmdk
vm-name.vmdk vmware-1.log
vm-name.vmsd vmware-2.log
vm-name.vmx vmware.log
vm-name.vmx.lck vmx-vm-name-2489500763-1.vswp

Но все они заблокированы:

/vmfs/volumes/549030ba-7ff1cf81-677b-002 5b5060a27/vm-name # touch *
touch: vm-name-9462c45b.vswp: Device or resource busy
touch: vm-name-flat.vmdk: Device or resource busy
touch: vm-name.nvram: Device or resource busy
touch: vm-name.vmx: Device or resource busy
touch: vm-name.vmx.lck: Device or resource busy
touch: vm-name.vmx

: Device or resource busy
touch: vm-name_1-flat.vmdk: Device or resource busy
touch: vmware.log: Device or resource busy
touch: vmx-vm-name-2489500763-1.vswp: Device or resource busy

Последний набор цифр из длинного GUID – это mac-адрес заблокировавшего хоста, 00:25:b5:06:0a:0e. Причем это, похоже, адрес первого адаптера eth0 – он не обязательно вообще участвует в сетевом трафике. Если вместо GUID одни нули – файл не заблокирован.

4) Методом перебора руками по Configuration – Network Adapters по всем хостам ESXi находим нужный хост, бывший владелец виртуалки, который никак её не отпустит. У нас это оказался host16. По идее, можно было бы его тоже перезагрузить и виртуалку бы отпустило, но мы пойдём более правильным путём. Не всегда перезагрузка хоста возможна из-за других виртуалок с RDM и т.п.

6) Идём по статье дальше, включаем SSH и ESXi Shell на проблемном хосте – последнем владельце виртуалки host16, заходим на него по SSH. Смотрим, не осталось ли процессов, которые держат файлы виртуалки. Набор процессов конкретной виртуалки в терминологии VMware называется World. Запускаем:
esxcli vm process list
видим кучу запущенных виртуалок, в т.ч. нашу vm-name, здесь оно ещё помнит её по имени:

(…)
some-vm-1
World ID: 7100719
Process ID: 0
VMX Cartel ID: 7100718
UUID: 42 20 e7 a6 8b 37 ed 57-c8 c9 d5 1c 79 a1 c3 ba
Display Name: some-vm-1
Config File: /vmfs/volumes/549030ba-7ff1cf81-677b-002 5b5060a27/some-vm-1/some-vm-1.vmx

vm-name
World ID: 7100994
Process ID: 0
VMX Cartel ID: 7100993
UUID: 42 20 c4 55 06 c4 f6 a9-30 6e 61 a9 d2 39 d4 d5
Display Name: vm-name
Config File: /vmfs/volumes/549030ba-7ff1cf81-677b-002 5b5060a27/vm-name/vm-name.vmx

some-vm-2
World ID: 7100730
Process ID: 0
VMX Cartel ID: 7100727
UUID: 42 20 2d 16 90 d2 b1 4b-7d 79 d5 3c 38 48 45 ac
Display Name: some-vm-2
Config File: /vmfs/volumes/5490305f-51759a8e-fcd9-002 5b5060a27/some-vm-2/some-vm-2.vmx
(…)

процесс так сразу не убивается (soft), надо подождать пару минут.

7) После удаления процесса регистрируем виртуалку на проблемном хосте – последнем владельце виртуалки host16 через vSphere Client, подключенный напрямую к ней (регистрация на vCenter всё ещё заканчивается неудачей). Регистрация на хосте проходит успешно, виртуалку включаем (power on). Загружать ОС не обязательно, достаточно включить, дождаться начала загрузки (с предложением войти в Safe Mode) и выключить – это корректно снимет блокировки с файловой системы, которые никуда не делись с убиением процесса.

9) Готово, виртуалку можно включать, мигрировать и т.п. – теперь с ней всё хорошо. Не забываем остановить ESXi Shell и ssh где запускали.

Источник

VMWare Reason: Failed to lock the file.

I can’t get my VM to open. I get:

Reason: Failed to lock the file.

Cannot open the disk ‘vmfs/volumes/x/x/x.vmdk’ or one of the snapshot disks it depends on.

I have 5 other VMs on the ESX host that work. I have been trying to replicate this VM with Veeam. It worked for a few months and then stopped working (the replication, not the VM). I checked again today to see if there were snapshots and it showed nothing. I created a snapshot to see if it would reveal the Consolidated Helper and it did. I deleted my snapshot and not the Consolidated Helper and the VM crashed, which was also the vCenter Server.

When I pull it back up I get that error.

This KB has saved me from this problem before

I had to recreate the descriptor files

Step 1 should help you identify what the problem is before trying to fix

22 Replies

The initial error I received had Reason: 12 cannot allocate memory.

I removed (but did not delete) the disk that I use as the e:drive, since it is large, 1TB. After that, I could open the VM. I shut it down, reattached the disk, opened again and got the file lock error.

looks like you’re going to be doing a vmdk restore process. yuck!

unless you have a decent backup!

I don’t have a recent backup because of this problem. How do I do a vmdk restore?

hopefully other have had to do something recently. last time I was able to use a delta because I had done several snapshots. gave me at least a base even though I lost my changes..

vmdk restores have all sorts of options but there are a couple of vmware experts on here that might know a few more options before you have to go that route.

was just hoping they’d chime in.

This KB has saved me from this problem before

I had to recreate the descriptor files

Step 1 should help you identify what the problem is before trying to fix

I don’t have a recent backup because of this problem. How do I do a vmdk restore?

Do you have snapshots still open?

Also, Call support they will webex in and fix it.

B-C, Thanks for the quick reply and getting things going.

Daniel, I made the changes and relinked some broken CIDs, but still no.

John773, called VMWare. I hate waiting for them. I use them as my last resource because the trouble that I get into is usually too complex for the first guy that I get. I was hoping this would be relatively easy, but after all of the KBs that I’ve been through, I don’t know what to do.

Is there an actual vmdk as well as the flat vmdk in the vm folders directory. Can you post the contents of the dirrectory as well as the VMX and the full datastore path. Are there any snapshot files (deltas) referenced within the base vmdk Orin the directory?

What is your storage (local, San NAS) have you rebooted the host/storage array that last had a lock. What is the backup system in use here?

trying to replicate this VM with Veeam. It worked for a few months and then stopped working (the replication, not the VM)

looks like Veeam primarily.

Daniel, I made the changes and relinked some broken CIDs, but still no.

Relinking the CIDs was only one of the possible fixes.

Since the machine can boot without the secondary vmdk, it sounds like the VMDK is corrupt of missing the descriptor (another possibility is the VMX file, but I would think removing and re-adding the vmdk would resolve that)

Recreating the VMDK descriptor

Recreating the VMDK descriptor for delta disks (Snapshot)

Validating the VMX

Would you mind posting the directory listing of your VM folder on the datastore and posting the contents of the VMX file?

De is write on for my thoughts. Make sure veeam doesn’t thing it still has the disk hot added to its VM

I appreciated all the help. I don’t know if any of the particular things added to the success, but ultimately, when I rebooted the host it worked. I have other production servers on it so I couldn’t take it down during the day, but I rebooted last night.

And Daniel, I went through some of the other things yesterday that were involved in that first shortcut that you sent. Nothing else seemed to be in error.

Standard IT response: Reboot!

PS. I do believe that the CID configuration helped a lot.

so Veeam is your primary backup for vm DR right?

I haven’t used it and have been looking at it but haven’t had the budget for a bigger install of esxi / vsphere just yet.

4-5k with veeam in the picture and essentials.

That said just wondering how it all works from a high level overview and what your total upgrade into the current SAN / NAS Solution

Costs were? (trying to asses budget for 2012/13

Also what you upgraded from?

I bought 3 HP DL180s. I have all 3 with VMWare ESX 4.1 (I’ve upgraded twice). Initially, I used vReplicator and vRanger for backup and replication. They combined the products and I was no longer able to use the products how I needed.

Veeam came highly recommended from 3 sources. It worked very well for months and then something happened that is causing it not to finish 2 of the machines. It keeps giving me snapshot errors. I haven’t contacted them about it yet, because it seemed to be a VMWare issue. Then yesterday happened. Looking at all of the KBs I read yesterday, everything points to 3rd party software, hence Veeam.

My servers were 3 TB each and cost me around 10 grand a piece (after software, etc. That is an average because I only have two quad processors in one of them.)

Each host is a complete set of our servers. I have the 2 hosts local, using some servers off of one and some off of the other to load balance, (but still, each one has the complete set of VMs). The third server is at another branch of ours, receiving regular replications.

Veeam has a good setup and feel to it. I’m not the best one to ask about reliability until I get the current problem resolved (I fixed one of the two problem VMs, but still haven’t fixed the final server, which was the cause of yesterday’s problem).

Is that too high level? I can get some functional details if you want.

Источник

Виртуализация vSphere, Hyper-V, Xen и Red Hat

Более 5530 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes

При эксплуатации виртуальной инфраструктуры VMware vSphere иногда случается ситуация, когда виртуальную машину нельзя включить из-за того, что ее какой-нибудь из ее файлов оказывается залоченным. Происходит это при разных обстоятельствах: неудачной миграции vMotion / Storage vMotion, сбоях в сети хранения и прочих.

Наиболее распространенная ошибка при этом выглядит так:

Could not power on VM: Lock was not free

Встречаются также такие вариации сообщений и ошибок при попытке включения виртуальной машины, которое зависает на 95%:

Ну а при попытке соединения с консолью ВМ получается вот такое:

Error connecting to

.vmx because the VMX is not started

Поиск залоченного файла ВМ

Хорошо если в сообщении при запуске виртуальной машины вам сообщили, какой именно из ее файлов оказался залоченным (как на картинке выше). Но так бывает не всегда. Нужно открыть лог vmware.log, который расположен в папке с виртуальной машиной, и найти там строчки вроде следующих:

Failed to initialize swap file : Lock was not free

За логом на экране можно следить командой (запустите ее и включайте ВМ):

tail /vmfs/volumes/ / /vmware.log

Проверка залоченности файла ВМ и идентификация владельца лока

После того, как залоченный файл найден, нужно определить его владельца. Сначала попробуем команду touch, которая проверяет, может ли бы обновлен time stamp файла, т.е. можно ли его залочить, или он уже залочен. Выполняем следующую команду:

# touch /vmfs/volumes/ / /

Если файл уже залочен, мы получим вот такое сообщение для него:

cannot touch: Device or resource busy

Дальше выполняем такую команду: