Failed to lock the file vmware что делать
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 может использоваться не только для локального, но и для удаленного управления виртуальными машинами. Для этого в качестве дополнительных параметров необходимо указать следующие флаги аутентификации:
Виртуализация vSphere, Hyper-V, Xen и Red Hat
Более 5540 заметок о виртуализации, виртуальных машинах 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
Дальше выполняем такую команду:
Те, кто хочет дальше изучать вопрос, могут проследовать в KB 10051.
Вебинары VMC о виртуализации:
Постер VMware vSphere PowerCLI 6.3: 
Постер VMware ESXi 5.1: 
Постер VMware Hands-on Labs 2015: 
Постер VMware Platform Services Controller 6.0: 
Постер VMware vCloud Networking: 
Постер VMware NSX (референсный): 
Постер VMware vCloud SDK: 
Постер VMware vCloud Suite: 
Постер VMware vCenter Server Appliance: 
Порты и соединения VMware vSphere 6:
Порты и соединения VMware Horizon 7: 
Порты и соединения VMware NSX: 
Управление памятью в VMware vSphere 5:
Как работает кластер VMware High Availability: 
Постер VMware vSphere 5.5 ESXTOP (обзорный): 
Постер Veeam Backup & Replication v8 for VMware: 
Постер Microsoft Windows Server 2012 Hyper-V R2: 
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 — unable to access file since it is locked
Иногда какой-нибудь хост ESXi может заблокировать виртуальную машину и «забыть» разблокировать. Причины бывают разные, но исправлять всё равно нам.
После неудачного резервного копирования виртуальная машина попросила выполнить консолидацию дисков.
Virtual machine disks consolidation is needed
Unable to access file since it is locked
Не работает примус. Нужно попасть в консоль гипервизора. Для удобства запускаю SSH.
Авторизируюсь по SSH на гипервизоре с «больной» виртуалкой.
По опыту уже знаю что могло послужить причиной запроса консолидации, блокировки виртуальной машины и описываемой ошибки. Банальная нехватка места в директории /tmp. Уже были статьи про такую проблему, но в каждом конкретном случае результат переполнения /tmp вызывал разные ошибки. Примеры устранения проблемы есть здесь:
Действительно, диск переполнен.
Прежде чем разбираться с заблокированной виртуалкой следует почистить /tmp.
Всё место занял файл ams-bbUsg.txt. Это известная проблема. Ошибка в пакете HPE Agentless Management (AMS) версии 11.4.0:
Сначала освободим место.
Место появилось. Но причина не устранена. Пробую обновить пакет AMS.
Причину проблемы устранили, правда, нужно будет запланировать перезагрузку гипервизора.
Теперь разберёмся с заблокированной виртуалкой. Нам нужно определить, который гипервизор эту виртуальную машину заблокировал и перезапустить на нём службы. Если виртуальная машина находится на локальном диске и доступ к ней имеет только один хост, то просто выполняем:
Если же хостов может быть несколько, то переходим в каталог с файлами виртуальной машины и смотрим vmware.log:
Нам нужно найти название заблокированного файла.
Заблокирован файл fs-office-000001.vmdk. Определим flat или delta файл.
Получили путь к файлу delta.
Получаем MAC адрес хоста, который заблокировал виртуальную машину. По MAC адресу определяем хост. Можно вывести ARP таблицу и получить IP и MAC адреса всех соседних серверов ESXi:
Я же просто пробегаюсь глазами по всем хостам в vCenter:
На найденном хосте выполняем:
Блокировка с виртуальной машины снимается, теперь консолидация выполнится успешно.
Failed to start the virtual machine. Failed to lock the file.
I just took on a new position and new to VMWare. One of my VSpheres has this error streaming:
I know failing to lock a file means its in use. How do I find out what’s using it?
I’m a little fuzzy (OK, a lot fuzzy) on the terms and their relation to each other. ESXi is the bit that makes the VMs on the physical box, and vCenter is the part that manages all the ESXi boxes? And then the vSphere Client connects to vCenter to let you administer all of it?? I have an app called VMWare Horizon Client. it seems to be something like Remote Desktop Manager?
vSphere Web Client: Version 6.0.0 Build 3617395
vSphere Client: Version 6.0.0 Build 14472085
VMWare vCenter Server: Version 6.0.0 Build Build 3634793
VMWare ESXi: Version 6.0.0 Build 4510822
VMWare Horizon Client: 4.5.0 build-5650915
16 Replies
The storage is a Nimble-HF20 AF-209660 (S/W Version:5.0.7.200), something else I am not very familiar with. I know it takes an hourly and a daily recovery point and replicates them to our other location. The circuit between the two locations is a super crappy 10mbps pipe, so the hourly snapshots never transfer. Their retention policy is only 24 hours. The daily ones queue up as well because it takes days to transfer one snapshot. If I’m looking at this correctly, our last valid backup is from 5-18. This is better than when I started 2 weeks ago; replication had stopped because only 1 of the 2 smaller Nimbles at the remote site was being used to store the two volumes from the main Nimble, and that machine was full.
Anyone else smell broken snapshot chain?
Your assumptions about ESXi, vCenter and vSphere client are right on. I’m wondering if those nimbles are using the built in vmware snapshotting to somehow replicate the VMs to the off-site Nimble? I bet you got snapshots, from within vSphere, can you check to see if this VM has any snapshots or needs consolidation?
The Needs Consolidation is a column that can be added to the view.
Looks like there is an active snapshot somewhere that needs to be consolidated. By the way, vSphere 6.0 is EOL and you need to migrate asap since there is no support (as long as your servers are on the VMware HCL for the current versions). Does the organisation you work for have an active support contract with VMware? It entitles you to upgrades of any paid VMware products you have.
The circuit between the two locations is a super crappy 10mbps pipe, so the hourly snapshots never transfer. Their retention policy is only 24 hours. The daily ones queue up as well because it takes days to transfer one snapshot. If I’m looking at this correctly, our last valid backup is from 5-18.
If I correctly understand what you are saying, your current situation is pretty dangerous in terms of possible data loss. Your ongoing replication isn’t working due to limited bandwidth between the sites, plus you should take care when using snapshots since they do not replace backups in any way http://www.vmwareblog.org/snapshots-checkpoints-alone-arent-backups/. Try to rethink your backup strategy first to mitigate data loss risks. After that, proceed to the DR/replication strategy to minimize downtime.
I looked at that VMWare article and tried running the commands they mention to find out what has the file locked. I see nothing
There are no lock files in the directory, so I proceeded to the article referenced in the one CrankyAvenger recommended to verify the integrity of the vm files. After following those steps and reregiistering the VM, I still have the same issue. 🙁
Looks like there is an active snapshot somewhere that needs to be consolidated. By the way, vSphere 6.0 is EOL and you need to migrate asap since there is no support (as long as your servers are on the VMware HCL for the current versions). Does the organisation you work for have an active support contract with VMware? It entitles you to upgrades of any paid VMware products you have.
The 3 servers are all Lenovo System X 3650’s, and they appear on the HCL, so *phew*!
No virtual machines need consolidation according to the Needs Consolidation column.
Fuu! Good catch! I should have copied and pasted.
Here’s the results of the correct command:
So the files aren’t locked by another process. but the VM won’t boot because it can’t lock the file. I unregistered and reregistered the VM, and that didn’t correct the issue, so the file itself must be hosed. This is one machine in a pool of machines. I don’t think there’s much about it that is unique from the other 9. If I can verify that is true, I’ll just dump this one entirely and clone one of the other 9 VMs as a new DSM_Basic10.
Edited Jun 24, 2020 at 20:56 UTC
Here’s what a section of VMX file from one of my test VM’s looks like with an active snapshot:
sata0:0.present = «TRUE»
scsi0:0.deviceType = «scsi-hardDisk»
scsi0:0.fileName = «xxxx-xxxx-000001.vmdk»
the ‘xxxx-xxxx’ is the actual VM name.
Here is the same section of the VMX file after removing the snapshot:
sata0:0.present = «TRUE»
scsi0:0.deviceType = «scsi-hardDisk»
scsi0:0.fileName = «xxxx-xxxx.vmdk»
If you are feeling gutsy, download the VMX file, edit the fileName entry appropriately, and upload it back to the datastore. See if there’s any change in power-on behavior.
«then you should take a look at the VMX file to see if there’s an entry in it for a snapshot delta file.» What you say makes sense. WinSCP and edittingb text files is something I think I can handle. 😉
Sadly, no dice. The vmx file makes no mention of an file with 000001 in the filename (or anything remotely close to that).
However, I also looked at the log file and saw that DSM_Basic10-flat.vmdk was having issues, so I ran VMFSfilelockinfo on it and found that it was locked. Now I just need to find the machine with that MAC address.
I’ve also learned that there is an ongoing issue with client getting a black screen on login. My googling suggests this is an issue with differing versions of VMView Horizon client. I think my bigger issue right now is upgrading all the components from version 6 to 6.7, then making sure all the Horizon clients are installed correctly.
I’ll circle back to this once that’s handled, until then thanks for all the help gents. It is greatly appreciated!
I’m a little fuzzy (OK, a lot fuzzy) on the terms and their relation to each other. ESXi is the bit that makes the VMs on the physical box, and vCenter is the part that manages all the ESXi boxes? And then the vSphere Client connects to vCenter to let you administer all of it??
Yes, all of this is correct, except vSphere = management of multiple vCenters (and yes, vCenter = mgmt of multiple ESXi hosts). I would personally use the term ESXi «host» and/or ESXi server instead of «box,» but yes, you have the concept of vSphere.
I have an app called VMWare Horizon Client. it seems to be something like Remote Desktop Manager?
Not exactly. The Horizon Client connects you to a VDI desktop, which is hosted on a Horizon View Connection Server (in conjunction with a VM in vSphere). Conceptually yes, it’s similar to Remote Desktop, but it’s very different from technical perspective in how it works. You could just google «VDI vs RDS» to get the overview.