По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье мы расскажем как решить проблему с блокировкой файлов в ESXi.
Проблема
Появляется ошибка при добавлении диска имеющейся виртуальной машины (VMDK) к виртуальной машине, которая не включается:
Failed to add disk scsi0:1. Failed to power on scsi0:1
Включение виртуальной машины зависает на 95%.
Не удается включить виртуальную машину после развертывания ее из шаблона.
Включение виртуальной машины выдает ошибки доступа к файлам, конфигурации виртуальной машины, или файла подкачки:
Unable to open Swap File
Unable to access a file since it is locked
Unable to access a file [filename] since it is locked
Unable to access Virtual machine configuration
В записях журнала появляются похожие записи:
WARNING: World: VM xxxx: xxx: Failed to open swap file [path]: Lock was not free
WARNING: World: VM xxxx: xxx: Failed to initialize swap file [path]
При открытии консоли для виртуальной машины может возникнуть ошибка:
Error connecting to [path][virtual machine].vmx because the VMX is not started
Виртуальная машина сообщает о конфликтных состояниях питания между центральным сервером управления vCenter Server и пользовательским интерфейсом ESXi хост.
При открытии файла .vmx с помощью текстового редактора (например, cat или vi) появляются похожие записи:
cat: can't open '[name of vm].vmx': Invalid argument
Решение
Цель блокировки файлов
Для предотвращения непредвиденных изменений в ценные системные файлы и файлы виртуальной машины, их необходимо заблокировать. В определенных обстоятельствах блокировка сохраняется, даже с выключенной виртуальной машиной. Таким образом, другие ESXi хосты не смогут получить доступ к заблокированным файлам, даже если виртуальная машина не запускается.
Файлы виртуальной машины, заблокированные во время выполнения, включают в себя:
VMNAME.vswp
DISKNAME-flat.vmdk
DISKNAME-ITERATION-delta.vmdk
VMNAME.vmx
VMNAME.vmxf
vmware.log
Быстрый первичный тест
Поставьте DRS (Планировщик Распределения Ресурсов) в режим обслуживания. С его помощью вы сможете выбрать хост, пока вы включаете виртуальную машину. Если DRS не используется, передайте ВМ другому хосту.
Если это не удается, попробуйте включить питание виртуальной машины на других узлах кластера.
Машина должна включиться, когда она окажется на узле, который заблокировал файлы.
Если ВМ по-прежнему не включается, рассмотрите действия, предложенные ниже.
Действия по устранению неполадок: поиск хоста заблокированного файла
Чтобы определить заблокированный файл, попробуйте включить виртуальную машину. Во время включения питания ошибка может отображаться или записываться в журналы виртуальной машины. Ошибка и запись в журнале идентифицируют виртуальную машину и файлы:
Чтобы найти блокирующий узел, запустите утилиту vmfsfilelockinfo с узла, который не может открыть заблокированный файл.
Чтобы узнать IP-адрес хоста, который заблокировал файлы, необходимо запустить утилиту vmfsfilelockinfo для файла VMDK flat, delta или sesparse для VMFS или для файла .UUID. lck для vSAN. Утилита vmfsfilelockinfo потребует следующий материал:
Заблокированный файл
Имя пользователя и пароль для доступа к VMware vCenter Server (при отслеживании MAC-адреса хостом ESX.)
Например:
Запустите команду:
~ # vmfsfilelockinfo -p /vmfs/volumes/iscsi-lefthand-2/VM1/VM1_1-000001-delta.vmdk -v 192.168.1.10 -u administrator@vsphere.local
Результат будет приблизительно такой:
vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['xx:xx:xx:xx:xx:xx']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : xx:xx:xx:xx:xx:xx
Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive
Total time taken : 0.27 seconds.
Примечание: в течение жизненного цикла работающей виртуальной машины ее файлы могут менять тип блокировки. Вид блокировки (mode) обозначает тип блокировки на файле. Список видов блокировки:
mode 0 = отсутствие блокировки
mode 1 = эксклюзивная блокировка (файл vmx работающей виртуальной машины, использует VMDK-диск (flat or delta), *vswp и т.д.)
mode 2 = блокировка «только для чтения» (read-only). (Например, для файла данных flat.vmdk работающей машины со снапшотами)
mode 3 = блокировка для одновременной записи с нескольких хостов (например, используется для кластеров MSCS или FTVMs)
Чтобы узнать название процесса, который заблокировал файл, запустите команду lsof на хосте, заблокировавшем файл, и укажите название нужного файла:
~ # lsof | egrep 'Cartel|VM1_1-000001-delta.vmdk'
Результат будет приблизительно такой:
Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/VM1_1-000001-delta.vmdk
Из результата вы узнаете Cartel ID заблокировавшей машины – например, 36202. Теперь, с помощью следующей команды, выведете на экран список активных Cartel ID:
~ # esxcli vm process list
Информация активных виртуальных машин сгруппирована по названиям машин. Формат приблизительно такой:
Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx
………
Найдя нужный вам VMX Cartel ID, вы узнаете название машины, заблокировавшей ваш файл. Если никакие процессы не отображаются, можете найти виртуальные машины с подключенным vmdk. Замените VMDKS_TO_LOOK_FOR на необходимый vmdk. В результате будет список всех зарегистрированных виртуальных машин, и VMDK отобразится под виртуальной машиной, которая заблокировала файл:
for i in $(vim-cmd vmsvc/getallvms | grep -v Vmid | awk -F "/" '{print $2}' | awk '{print $1}'); do echo $i && find ./ -iname $i | xargs grep vmdk | grep -Ei VMDKS_TO_LOOK_FOR ; done
Снятие блокировки
Машину, которая не включается, переместите на заблокировавший хост и снова попробуйте включить ее.
Чтобы снять блокировку, извлеките VMDK-диск или выключите машину, которая удерживает блокировку.
Перезагрузите хост, который заблокировал файл.
Обратитесь к VMware storage team, vSAN team или разработчику NFS за дальнейшей помощью, так как проблемы с метаданными могут мешать управлению блокировками.
Снятие блокировки .lck file (только для NFS)
Файлы на виртуальной машине могут быть заблокированы через NFS storage. Такие файлы заканчиваются на .lck-#### (где #### - значение поля fileid, которое можно получить из запроса GETATTR для заблокированного файла).
Внимание: для безопасного извлечения файлов машина должна быть выключена.
Примечание: Тома VMFS не имеют .lck файлов. Механизм блокировки для томов VMFS расположен в метаданных тома VMFS.
Проверка целостности файла конфигурации виртуальной машины (.vmx)
Если виртуальная машина не включается, причина может быть в наличие двух дисков в файле .vmx. Извлеките один из дисков и попробуйте включить машину снова.
Команда touch *, которая раньше использовалась для устранения неполадок с заблокированными снапшотами vmdk, теперь записывает время последнего изменения файла, который должен быть остановлен и запущен с помощью vmkfstools-D или chmod-s * или vmfsfilelockinfo * для идентификации блокировки.
В больших корпоративных сетях, которые занимаются обслуживанием клиентов важно вовремя получать уведомления о неполадках в сети и устранять их. В этом деле администраторам помогают системы мониторинга, которых сегодня в сети существует достаточно много, как платных, так и бесплатных.
Своего рода стандартом в ИТ является PRTG (Paessler Router Traffic Grapher), которая может отправлять уведомления о событиях через e-mail, SMS, Push-уведомлений. Сегодня сложно представить кого-то, кто не пользуется хоть одним мессенджером. Среди них особо выделяется Telegram, который пользуется популярностью благодаря своей безопасности и функционалу. Здесь можно создать своего бота, который будет выполнять все ваши команды исходя из поставленной задачи. В одном из материалов мы рассказывали уже о том, как использовать Telegram для управления "Умным домом".
Здесь же расскажем о том, как интегрировать Telegram в PRTG и получать уведомления не на почту, на Telegram. Принцип работы такой: система мониторинга, в нашем случае PRTG, отправляет сообщения боту, а тот в свою очередь выводит их группу.
Что нам нужно
Telegram аккаунт
Группа, куда будем добавлять нашего бота
Доступ с PRTG сервера на https://api.telegram.org/
Создание бота
Для начала нам нужно создать бота, в чем на поможет "The Botfather". Начинаем новый чат с ним в Telegram:
Командой /newbot под руководством Botfather начинаем создание бота. Задаем ему имя, которое будет отображаться и имя пользователя:
После этих несложных манипуляций получаем API токен нашего бота, который используем в будущем. По умолчанию, бот может быть добавлен в любую группу и может получать сообщения от кого угодно. Ограничить это можно в настройках приватности, которые доступны командами /setprivacy и /setjoingroups.
Далее добавляем бота в группу, где находятся администраторы и другой заинтересованный персонал.
Через группу посылаем боту сообщение /start, чтобы активировать его. Затем уже настраиваем политики приватности, о которых говорилось выше. С созданием бота закончили, теперь нужно настроить получение уведомлений
Настройка уведомлений
Помните, в конце создания бота нам выдали API ключ. Перейдите по следующей ссылке, предварительно подставив вместо <apikey> API ключ вашего бота:
https://api.telegram.org/bot<apikey>/getMe
Вы должны получить что-то подобное:
{ "ok": true, "result": { "id": 1234567890, "first_name": "PRTGNotiBot", "username": "PRTGNotificationBot" }}
Если вышли какие-то ошибки, убедитесь, что API ключ введён правильно. Далее открываем ту же ссылку, только вместо getMe подставляем getUpdates. Мы получим список чатов, в которые добавлен наш бот.
{ "ok": true, "result": [{ "update_id": 521075218, "message": { "message_id": 3, "from": { "id": 11512298, "first_name": "xxxxxxxxx", "last_name": "xxxxxxxxx", "username": "xxxxxxxxx" }, "chat": { "id":-12345690, "title": "[Paessler] IT", "type": "group", "all_members_are_administrators": true }, "date": 1493834122, "text": "/start", "entities": [{ "type": "bot_command", "offset": 0, "length": 6 }] } }]}
Из этого вывода нам нужен идентификатор чата, включая знак "-". Теперь мы готовы создать шаблон уведомления в PRTG. Переходим в Setup > Account Settings > Notifications.
Добавляем новый шаблон уведомления:
Выбираем вводим название шаблона, выбираем тип сенсора (рекомендуем pingsensor)
В качестве шаблона выбираем HTTP. Вводим ссылку https://api.telegram.org/bot<your-api-key>/sendMessage, подставив API токен вашего бота.
В строку Postdata вводим следующие строки:
chat_id=-<your-chat-id>&text=There's a *%status* sensor in your PRTG*Last Message* %lastmessage*Down since* %since*Device* %device*Group* %group&parse_mode=Markdown
chat-id идентификатор чата, который получили выше.
text текст сообщения, который будет отправлять бот. Текст можно изменять по вашему усмотрению.
%status переменная PRTG. Звездочки вокруг него это стиль редактирования Telegram API. Как именно обрабатывать стиль указано в конце текста параметром parse_mode=Markdown.
Если нужно, чтобы уведомление пришло если сеть поднялась, то нужно создать другой шаблон с соответствующим текстом:
chat_id=-123456890&text=%device% is *%status*!&parse_mode=Markdown
Хотя можно совместить это в одном шаблоне, но лучше сделать два отдельных шаблона, на случай если каждому шаблону нужно добавить разные переменные, как в нашем случае.
Затем можно отправить тестовое сообщение, в результате чего должны получить что-то подобное:
Если все прошло успешно, нужно привязать шаблон к конкретному сенсору. Чтобы система не бомбила ваш Telegram из-за незначительных событий, лучше привязать шаблон к сенсору PING. Для этого переходим на вкладку Devices, среди сенсоров нужного устройства наводим курсор мыши на сенсор PING и кликаем на иконку звоночка.
Открывается страница добавления уведомлений. Выбираем Add State Trigger заполняем поля согласно политике организации. Можно сделать как на скриншоте:
Как видно на скриншоте, мы отправляем уведомление только когда сеть упала и поднялась. Повторно не посылаем, чтобы не надоедало.
Вот и всё. Думаю материал окажется полезным для вас.
Вторая часть тут
Пересечение многочисленных дискуссий в мире сетевого инжиниринга, было одной из проблем, которая затрудняла принятие решения о том, является ли коммутация пакетов или каналов лучшим решением. Как следует вычислять loop-free пути в сети с коммутацией пакетов?
Поскольку сети с коммутацией пакетов на протяжении всей истории сетевой инженерии ассоциировались с распределенными плоскостями управления (control plane), а сети с коммутацией каналов -с централизованными плоскостями управления (control plane), проблема эффективного вычисления безцикловых (loop-free) путей оказала значительное влияние на принятие решения о том, являются ли сети с коммутацией пакетов жизнеспособными или нет.
На заре сетевой инженерии доступная вычислительная мощность, память и пропускная способность часто были в дефиците.
В 1984 году, когда происходили в основном своем эти дискуссии, любая разница в объеме процессора и памяти между двумя способами расчета безцикловых путей через сеть оказала бы существенное влияние на стоимость построения сети. Когда пропускная способность имеет первостепенное значение, уменьшение количества битов, требуемых плоскостью управления (control plane) для передачи информации, необходимой для вычисления набора loop-free путей через сеть, создает реальную разницу в объеме пользовательского трафика, который может обрабатывать сеть. Уменьшение количества битов, необходимых для работы элемента управления, также вносит большую разницу в стабильность сети при более низких полосах пропускания.
Например, использование формата Type Length Vector (TLV) для описания информации о плоскости управления (control plane), передаваемой по сети, добавляет несколько октетов информации к общей длине пакета-но в контексте канала 2 Мбит / с, усугубленного chatty control plane, затраты могут значительно перевесить долгосрочное преимущество расширяемости протокола.
Протокольные войны в некоторых моментах были довольно жаркими. Были организованы целые исследовательские проекты и написаны статьи о том, почему и как один протокол лучше другого.
Было предложено большое разнообразие механизмов для решения задач вычисления loop-free путей через сеть. В конечном счете были широко развернуты и использованы три общих класса решений:
Distance Vector protocols (протоколы вектора расстояния), которые вычисляют свободные от петель пути hop by hop на основе стоимости пути.
Link State protocols (протоколы состояния связи), которые вычисляют свободные от петель пути через базу данных, синхронизированную между сетевыми устройствами.
Path Vector protocols (протоколы вектора пути), которые вычисляют свободные от петель пути hop by hop на основе записи предыдущих прыжков.
Дискуссия о том, какой протокол лучше всего подходит для каждой конкретной сети и по каким конкретным причинам, все еще продолжается. И это, возможно, бесконечный спор, поскольку нет окончательного ответа на этот вопрос. Возможно, как и при подгонке сети под бизнес, всегда будет какая-то степень искусства, связанная с тем, чтобы заставить конкретную плоскость управления (control plane) работать в конкретной сети. Однако большая часть актуальности этого вопроса была вызвана ростом скорости сетей-вычислительной мощности, памяти и пропускной способности.
Четвертую часть цикла статей про QoS можно почитать по ссылке.