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

Обновлено: 06.07.2024

Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal

Зависшая блокировка файлов виртуальной машины 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, смотрим что файлы точно есть:

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

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

: 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 и т.п.

5) Де-регистрируем (не удаляем. 11!1), т.е. Remove from inventory, проблемную виртуалку. Зарегистрировать назад через vCenter оно не даёт – правой на .vmx файл, Add to inventory – неактивно. Заходим на хост, где пытались виртуалку запустить host13 при помощи vSphere Client напрямую. В виртуалках присутствует Unknown (unavailble) – так и должно быть по статье, смело дерегистрируем её, но никаких результатов это не даёт, ничего не меняется и зарегистрировать её по прежнему нельзя. Заходим на хост – последний владелец виртуалки host16 при помощи vSphere Client напрямую. На нём (и только на нём, а не на другом хосте или vCenter!) виртуалку можно зарегистрировать, что мы и делаем. Однако она, вместо нормального имени, регистрируется как Unknown (unavailble), включить её не получается, потому дерегистрируем назад.

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
(…)

Видим идентификатор мира, по которому можно убить все процессы виртуалки, что мы и делаем:
vm process kill --type=soft --world-id=7100994

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

8) Де-регистрируем (Remove from inventory) виртуалку на проблемном хосте, теперь с ней всё ок и её надо зарегистрировать на vCenter, что мы и делаем, в этот раз правой на файл .vmx – Add to inventory там активно. При регистрации vCenter ругается, что виртуалка с таким именем уже была, но зарегистрировать даёт. При включении виртуалки оно предупреждает, что он такую уже знал когда-то – и что вы с ней сделали? Ответ Move, который надо выбрать, сохраняет ID виртуалки и какие-то связанные с ним события для Operations Manager и т.п., в то время как ответ Copy (который выбирать не надо) сгенерирует новый ID.

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

VMware Server - бесплатная и мощная платформа виртуализации для малого бизнеса.

Поддержка VMware Server закончилась 30 июня 2011 года. Пользователям рекомендуется перейти на другие продукты 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:

поддержка нескольких виртуальных серверов на одном физическом в продакшене компании поддержка нескольких виртуальных серверов в целях тестирования «в связке» в виртуальной сети хоста при разработке и поддержке программного обеспечения запуск готовых к использованию виртуальных машин (Virtual Appliances), выполняющих определенную серверную функцию обеспечение высокой доступности виртуальных серверов (виртуальные машины могут легко переноситься между физическими серверами) создание удобных к восстановлению резервных копий виртуальных серверов за счет получения мгновенных снимков текущего состояния системы («снапшотов»).

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

Поддержку любой стандартной архитектуры x86. У VMware Server нет особых требований к компонентам физического сервера – в отличие от VMware ESX Server, который накладывает весьма конкретные ограничения на оборудование сервера. Многоядерные процессоры также поддерживаются. Поддержку двунаправленного виртуального SMP (symmetric multi-processing). Если позволяет архитектура физического сервера, виртуальные машины, создаваемые в VMware Server, могут содержать два виртуальных процессора, что положительно сказывается на производительности гостевых систем. Поддержку большого числа хостовых и гостевых операционных систем, полный список которых всегда доступен на сайте VMware. Число хостовых операционных систем, на которых может быть установлен VMware Server, конечно же, меньше, чем число поддерживаемых гостевых систем. Между тем, в качестве гостевой может быть установлена практически любая известная операционная система. Даже если ее нет в списке поддерживаемых, это не значит, что ее нельзя установить. Поддержку 64-битных хостовых и гостевых операционных систем. В качестве хостовых 64-х битных систем могут использоваться 64-х битные ОС семейства Windows Server 2003, а также 64-х битные версии Linux-систем: Red Hat, SUSE, Mandriva и Хостинг VPS/VDS на Ubuntu. Список поддерживаемых гостевых ОС дополнен также еще и 64-х битными версиями Windows Vista, Sun Solaris и FreeBSD.

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

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

VMware Server. Регистрируемся и скачиваем версию: VMware-server-2.0.2-203138.x86_64.tar.gz. На почту приходит письмо с просьбой подтвердить регистрацию. После подтверждения на сайте станут доступны два лицензионных ключа для Windows и Linux. в файле для красоты отображения /etc/services заменим описание 902 порта TCP и UDP. Должно выглядеть так Оригинальный инсталлятор VMware не поддерживает ядро 2.6.35. В сети существует скрипт дающий возможность использовать это ядро VMware Server on 2.6.31 kernels. Скачиваем скрипт

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

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

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

Установка закончилось успешно, но перестал работать Web -интерефйс. В целом на 2011.01.31 связка Fedora 14 и VMware-server-2.0.2-203138.x86_64 не стабильна.

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

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

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

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

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

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

VMware Server 2 умеет делать только один snapshot. Старый snapshot перезаписывается.

Источник официальный 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.

Снапшот (Snapshot) - это снимок состояния виртуальной машины (содержимое памяти, настройки ВМ, содержимое дисков) в определенный момент времени. Возврат к снапшоту (revert to snapshot) восстанавливает текущее состояние виртуальной машины до сохраненного.

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

Выбирать точку для создания снапшота следует с осторожностью, и крайне желательно в момент, когда никакие процессы не ведут сетевой активности. Просто потому что если вы создадите снапшот в момент копирования файла по сети, то при откате до этого снапшота восстановится состояние виртуальной машины в момент копирования - и соотв. какие-то процессы могут упасть.

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

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

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

Я давно использую виртуальную машину и никогда не испытывал проблем с запуском, но теперь у меня проблема:

Всякий раз, когда я пытаюсь запустить, он показывает эту ошибку:

Я пытался удалить vmx.lck папки, но это не помогло.

я использую windows операционная система на локальном компьютере.

Кто-нибудь может мне помочь?

какие все файлы и папки? возможно ли такое же .vmx используется 2 ВМ? (Я полагаю, вы пытались оставить только .vmx а также .vmdk файлы)
@azbarcea у меня есть эти файлы и папки
1 Хорошо, удалите все, кроме .vmx а также .vmdk файлы и снова запустите машину. Это должно полностью стереть все поврежденное состояние машины. Сделайте резервную копию этих файлов, если вы считаете это небезопасным.

Хорошо, удалите все, кроме файлов .vmx и .vmdk, и снова запустите машину. Это должно полностью стереть все поврежденное состояние машины. Сделайте резервную копию этих файлов, если вы считаете это небезопасным. - азбарча

Приведенный выше комментарий от azbarcea - это то, что сработало для меня. Если вы не можете удалить файлы, потому что он говорит, что они используются, перезагрузите компьютер, а затем удалите файлы. Также не забудьте удалить любые папки с файлами lck

Это последствия обновления Windows. Я откатился на предыдущую версию, и у меня все заработало.

Попробуйте перезапустить вашу систему .. Я столкнулся с той же проблемой, решенной простым перезапуском системы.

Иногда какой-нибудь хост 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.

Утилита vmfsfilelockinfo поможет определить хост. Утилиту можно запускать, зная файл VMDK flat, delta, esparse для VMFS или .UUID. lck для vSAN.

Получаем MAC адрес хоста, который заблокировал виртуальную машину. По MAC адресу определяем хост. Можно вывести ARP таблицу и получить IP и MAC адреса всех соседних серверов ESXi:

Я же просто пробегаюсь глазами по всем хостам в vCenter:

На найденном хосте выполняем:

Блокировка с виртуальной машины снимается, теперь консолидация выполнится успешно.

Читайте также: