Представим себе: мы "сисадмин" (наше "сисадминское" величество - повелитель "юзеров") и освоили инсталляцию VMware Server на Windows, а может даже и на Linux (экстремально и излечимо только с возрастом - установили это на Ubuntu Linux). Накатили "контроллер домена", почтовый сервер и "прокси". Радуемся экономии средств, не затраченных на приобретение выделенных компьютеров. На источниках бесперебойного питания мы тоже сэкономили. Как же, предприятие коммерческое, "шефы" деньги считать умеют и на какие-то шалабушки без должного обоснования выделять средства не намерены.
Через неделю - "свет упс-с-с" и закономерный "холодный рестарт". После перезагрузки хостовой машины получаем не работающие виртуальные машины и в логах нечто вроде этого:
# cat /var/lib/vmware/machine0/vmware.log
...
vmx| DISK: OPEN ide0:0 './machine0.vmdk'
vmx| FILE: WaitForPossession timeout on './machine0.vmdk.lck/M39673.lck' due to a local process (2756)
vmx| FILE: FileIO_Lock on './machine0.vmdk' failed: Lock timed out
vmx| DISKLIB-LINK : "./machine0.vmdk" : failed to open (Failed to lock the file).
vmx| DISKLIB-CHAIN : "./machine0.vmdk" : failed to open (Failed to lock the file).
vmx| DISKLIB-LIB : Failed to open './machine0.vmdk' with flags 0xa (Failed to lock the file).
vmx| DISK: Cannot open disk "./machine0.vmdk": Failed to lock the file (16392).
vmx| Msg_Post: Error
vmx| [msg.disk.noBackEnd] Cannot open the disk './machine0.vmdk' or one of the snapshot disks it depends on.
vmx| [msg.disk.configureDiskError] Reason: Failed to lock the file.----------------------------------------
vmx| Module DiskEarly power on failed.
...
vmx| DISK: OPEN ide0:0 './machine0.vmdk'
vmx| FILE: WaitForPossession timeout on './machine0.vmdk.lck/M39673.lck' due to a local process (2756)
vmx| FILE: FileIO_Lock on './machine0.vmdk' failed: Lock timed out
vmx| DISKLIB-LINK : "./machine0.vmdk" : failed to open (Failed to lock the file).
vmx| DISKLIB-CHAIN : "./machine0.vmdk" : failed to open (Failed to lock the file).
vmx| DISKLIB-LIB : Failed to open './machine0.vmdk' with flags 0xa (Failed to lock the file).
vmx| DISK: Cannot open disk "./machine0.vmdk": Failed to lock the file (16392).
vmx| Msg_Post: Error
vmx| [msg.disk.noBackEnd] Cannot open the disk './machine0.vmdk' or one of the snapshot disks it depends on.
vmx| [msg.disk.configureDiskError] Reason: Failed to lock the file.----------------------------------------
vmx| Module DiskEarly power on failed.
...
Потыкав кнопку запуска виртуальной машины, получаем:
"Failed to lock the file! Cannot open the disk '*.vmdk' or one of the snapshot disks it depends on".
Не буду здесь продолжать в прежнем духе и приводить примеры рекомендаций из первых строк выдачи поисковиков, вроде пересоздания виртуальной машины или переустановки операционной системы.
Всё, что нужно - это удалить файлы ".lck" в директории сбоящей виртуальной машины, задача которых оповещать о текущей блокировке ресурсов для предотвращения повторного использования таковых приложениями. В нормальном рабочем состоянии эти файлы существуют только тогда, когда виртуальная машина запущена и используется. При корректном завершении работы виртуальной машины файлы ".lck" удаляются. После отключении электроэнергии или сбоя в работе файловой системы эти файлы, естественно, могут быть не уделены и, при последующем запуске, сервер VMware будет перестраховываться и отказываться запускать виртуальную машину, считая её уже работающей или заблокированной по факту наличия соответствующего флага.
Вообще-то, странно, что разработчики VMware не предусмотрели более толковой проверки на "занятость" виртуальной машины. Сбои подачи электроэнергии - обычное дело, и наличие файла ".lck" при старте системы после аварийного завершения явление не такое уж и редкое, чтобы по этому поводу приходилось бы каждый раз вручную удалять флаги блокировки. Так и подмывает на географически удалённых серверах создать скрипт, отрабатывающий при запуске операционной системы и удаляющий все файлы "*.lck" в местах расположения виртуальных машин до запуска таковых.
Для информации, прилагаю список расширений файлов ресурсов виртуальных машин, дабы не поудалять лишнего в панических попытках реанимировать "упавший" "контроллер домена" под телефонные звонки и стуки в запертую дверь пользователей сети:
*.vmx - Текстовый, главный конфигурационный файл виртуальной машины, содержащий описание аппаратного окружения;
*.vmdk - Двоичный, файл (или ссылка) виртуального диска (может быть достаточно большим, до 950 GB);
*.nvram - Двоичный, файл содержимого постоянной памяти RAM (содержит текущие настройки виртуальной BIOS);
*.vmem - Двоичный, файл подкачки виртуальной машины (этот файл существует, если установлено: TmainMem.useNamedFile = "true");
*.vmsn - Смешанный, файл содержимого текущего "снапшота", nvram и копию vmx-файла;
*.vmsd - Текстовый, содержит параметры текущего "снапшота";
*.vmss - Двоичный, содержит RAM приостановленной (suspended) виртуальной машины;
*.lck - Текстовый (нулевого размера), файл - флаг блокировки файлов ресурсов виртуальной машины.
*.vmdk - Двоичный, файл (или ссылка) виртуального диска (может быть достаточно большим, до 950 GB);
*.nvram - Двоичный, файл содержимого постоянной памяти RAM (содержит текущие настройки виртуальной BIOS);
*.vmem - Двоичный, файл подкачки виртуальной машины (этот файл существует, если установлено: TmainMem.useNamedFile = "true");
*.vmsn - Смешанный, файл содержимого текущего "снапшота", nvram и копию vmx-файла;
*.vmsd - Текстовый, содержит параметры текущего "снапшота";
*.vmss - Двоичный, содержит RAM приостановленной (suspended) виртуальной машины;
*.lck - Текстовый (нулевого размера), файл - флаг блокировки файлов ресурсов виртуальной машины.
14 августа 2011 в 03:42
14 августа 2011 в 20:42
23 августа 2011 в 13:29
25 августа 2011 в 21:11
14 февраля 2013 в 16:05
11 ноября 2013 в 03:54
16 декабря 2014 в 04:25
13 января 2015 в 11:25
13 января 2015 в 23:21
12 мая 2016 в 16:47
10 августа 2017 в 19:08
18 октября 2017 в 13:11