VMWare и NFS

Как известно, гипервизоры VMWare умеют использовать как локальные диски - на сервере, где установлен сам гипервизор, так и сетевые хранилища по протоколу NFS.
Но есть одна неприятность: если сервер NFS какое-то время недоступен, например, перегружается, то прописанное хранилище может отвалиться: оно становится unmounted и реактивировать его не удается.

Нашелся только один способ исправления ситуации. Не самый лучший, но другого в VMWKB не предлагают...

1. разрешаем на гипервизоре SSH и логинимся туда

2. список имеющихся подключенных NFS-ресурсов

[root@rsk30hyp101:~] esxcfg-nas -l
NFS-srv102-ip130 is /media/4t2/nfs from rsk30srv102 unmounted unavailable

Видно, что ресурс NFS-srv102-ip130 недоступен, потому что сервер rsk30srv102 когда-то был перезагружен. Будем лечить


3. удаляем существующее соединение

[root@rsk30hyp101:~] esxcfg-nas -d NFS-srv102-ip130
NAS volume NFS-srv102-ip130 deleted.


4. пересоздаём подключение

[root@rsk30hyp101:~] esxcfg-nas -a -o 172.21.122.130 -s /media/4t2/nfs NFS-srv102-ip130
Connecting to NAS volume: NFS-srv102-ip130
NFS-srv102-ip130 created and connected.

Все ключи/параметры esxcfg-nas выдаются при запуске ее без параметров, конкретно для добавления подключения порядок такой:

-a - добавляем подключение
-o IP - адрес сервера NFS. Можно и FQDN, и даже, начиная с ESXi 4.1, список адресов/имен узлов
-s путь_на_сервере - точный путь к каталогу, прописанному в файле exports на NFS-сервере

Последним по порядку идет название ресурса, под которым он будет использоваться гипервизором. Никаких ключей для указания этого имени не требуется.

Не красиво, но на безбабье и рыбу раком... Как бы еще научить все гипервизоры анализировать эту ситуацию и автоматически подключать отвалившиеся ресурсы?

VMware ESXi 5.1.0 и зависания

Время от времени старый гипервизор, который вот-вот будет обновлен до ESXi 6, начинает вести себя по-хамски: то у него забивается под завязку виртуальный диск root, то VMwareTools на одной из ВМ теряют возможность обмена по RPC.

Порядок действий:

1. ssh до гипервизора (при необходимости - разрешить ssh с консоли)
2. логин подходящим пользователем с root-правами
3. проверяем место на дисках командой vdf -p
4. /etc/init.d/hp-ams.sh restart
этим убивается /var/log/hpHelper.log, который отъедает кучу места при долгом аптайме

Теперь по проблемным виртуальным машинам.

1. net stop "vmtools"
2. прибиваем, если сам не умрет, процесс vmtoolsd.exe
3. Удаляем или переименовываем плагин "C:\Program Files\VMware\VMware Tools\plugins\vmusr\unity.dll" - ESXi его не использует, но он, плагин, при этом имеет привычку гадить.
4. Создаем на всякий случай "C:\ProgramData\VMware\VMware Tools\tools.conf" с таким содержимым:

# http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2038263
[unity]
Pbrpc.enable=false

VMWare ESXi/VSphere: как остановить затянувшееся копирование

Понадобилось срочно сохранить данные с виртуальной машины (с сохранением прав и т.п.). Места на гипервизоре для создания копии диска нет, пришлось задействовать сетевое хранилище.

При всём удобстве GParted-a, он не умеет одну вещь, которую умеет Norton Ghost: он не умеет копировать разделы с уменьшением размера. То есть, если есть раздел размером 100 гигов и на нем занято только 5, то его нельзя GParted-ом скопировать на диск размером 50 гигов. И ладно, если бы это было ограничение файловой системы - 100 гигов ext4, например, мне не позволили ужать даже штатными средствами меньше чем, примерно, до 95.

Поэтому, чтобы не заниматься экстренным изучением других инструментов, создал на NFS аналогичный по размерам виртуальный диск и начал копировать туда раздел с существующего диска. Чёрт! Он собирается копировать 30+ гигов около 10 минут! Типа, очень долго, ага!

Решил, как умная Маша, скопировать целиком каталог этой виртуалки на сетевое хранилище. А что? Влёгкую! Открываем два браузера datastor-ов - местный и сетевой, copy/paste и вуаля! Вуаля? А хрен там! "Ожидаемое время копирования: 4 часа".

Не, ну меня это как-то не устраивает, причем совсем - у меня полчаса до окончания рабочего дня. Пытаюсь остановить копирование, но кнопка cancel не активна. Закрываю окошко копирования, но не помогает - в окне протокола вижу, что процесс продолжает идти своим ходом.

Перезагрузка гипервизора - не вариант, на нем крутятся еще несколько машин, которые нельзя просто так остановить. Что делать?

Решение нашлось здесь.

1. разрешаем административную консоль (подключение по SSH)
2. логинимся в нее
3a. (для ESX) перезапускаем клиентского демона

service mgmt-vmware restart

3b. (для Esxi) перезапускаем клиентского демона

/etc/init.d/hostd restart

Опосля ждем, пока клиент обнаружит, что потерял соединение и попробует переподключиться, либо просто закрываем клиента и запускаем его заново. Вот теперь вуаля!

Восстановление случайно убитой виртуальной машины

Чистили гипервизоры. Нашли каталог от ВМ с именем вм022, но самой машины не было. Нашли машину вм022_1 которая работала и хранила свои данные в datastore/vm022_1. Судя по описанию, вм022 ничего не делала и мы решили убить ее каталог.
Однако, процесс vmx зубами держался за четыре файла в этом каталоге. Списав всё это на глюк, перегрузили гипервизор. После чего отказалась запускаться машина вм023.
Которая, как оказалось, хранила свои данные в каталоге вм022, почему vmx и не давал их убить.

Ок. Выясняется, что уцелел только файл вм022-flat.vmdk, но нет файла вм022.vmdk. Игры с переименованием ничего не дали - подключить этот flat к ВМ не удавалось - браузер существующих виртуальных дисков его не видел.

Ответ нашел здесь:

http://whiteboardninja.wordpress.com/2012/03/05/recover-a-vm-from-the-vm-flat-vmdk-file/

Recover a VM from the vm–flat.vmdk file

Steps to recover a VM from just the flat.vmdk file:

1. Build new temp VM with EXACTLY identical vmkd file size
2. Connect via CLI
3. Rename temp-flat.vmkd file
4. Copy existing-flat.vmdk file and rename to temp-flat.vmkd
5. Power on temp VM

Что в переводе обозначает:

1. Создать новую ВМ с таким же оборудованием и ТОЧНО ТАКИМ ЖЕ размером диска (дисков)
2. Подключитесь к консоли гипервизора (стандартный браузер из vSphere Client не видит такие файлы вообще никак)
3. Переименуйте flat.vmdk новой ВМ во что-то другое (я использую дополнительное расширение ,org)
4. Скопируйте существующий flat.vmdk из убитой ВМ туда, где лежат файлы новой ВМ и переименуйте его соответственно
5. Запустите новую ВМ

После таких манипуляций w2008r2 потерял активацию, но ее подняли KMS-ключом. Дополнительно пришлось пере-пробросить usb-затычку с хаспом. Сделать это - добавить забытый USB-контроллер и "воткнуть" в него хасп - удалось не выключая новую ВМ.