Вход|Регистрация

Еще один унылый бложег
Записи с меткой vmware

Что делать, если пропал заголовочный VMDK-диск виртуальной машины VMware vSphere, но остался диск с данными (*-flat.vmdk).

Четверг, 3 апреля 2014, 02:01

Виртуальный диск виртуальной машины представляется как минимум в виде двух файлов:

  • <имя ВМ>.vmdk - заголовочный, он же индексный, он же файл-дескриптор виртуальго диска, который содержит информацию о геометрии диска, его тип и другие метаданные
  • <имя ВМ>-flat.vmdk - непосредственно диск с данными ВМ

Практика показывает, что нередки ситуации, когда администраторы VMware vSphere теряют заголовочный файл VMDK по некоторым причинам, иногда необъяснимым, и остается только диск с данными ВМ (неудивительно, ведь в него идет запись, он залочен).

Ниже приведена краткая процедура по восстановлению дескрипторного VMDK-файла для существующего flat-VMDK, чтобы восстановить работоспособность виртуальной машины. Подробную инструкцию можно прочитать в KB 1002511.

Итак, для тех, кто любит смотреть видеоинструкции:

Для тех, кто не любит:

1. Определяем точный размер в байтах VMDK-диска с данными (чтобы геометрия нового созданного дескриптора ему соответствовала):

ls -l <имя диска>-flat.vmdk

2. Создаем новый виртуальный диск (цифры - это полученный размер в байтах, тип thin для экономии места, lsilogic - контроллер):

vmkfstools -c 4294967296 -a lsilogic -d thin temp.vmdk

3. Переименовываем дескрипторный VMDK-файл созданного диска в тот файл, который нам нужен для исходного диска. Удаляем только что созданный пустой диск данных, который уже не нужен (temp-flat.vmdk).

4. Открываем переименованный дескрипторный файл VMDK и меняем выделенные жирным строчки:

# Disk DescriptorFile
version=1
CID=fb183c20
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 8388608 VMFS "vmdisk0-flat.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "4"
ddb.geometry.cylinders = "522"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"
ddb.thinProvisioned = "1"

То есть, меняем просто имя flat VMDK-файла и убираем строчку о том, что диск thin provisioned, если он у вас изначально был flat.

Все - машину можно запускать.

http://www.vmgu.ru/news/vmware-vsphere-esxi-restore-descriptor-vmdk

по теме http://wiki.vm4.ru/snapshot

Написать комментарий

***

Вторник, 18 марта 2014, 02:19

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007849

 

Написать комментарий

VMware VMotion — небольшой гайд

Четверг, 13 марта 2014, 01:20

 на официальном сайте VMware

Функционал VMotion доступен начиная с редакции  vSphere Advanced.

Для VMotion надо:

  • vCenter;
  • Кластер в vCenter (нужен для активации EVC, если EVC не используется, то можно и без кластера);
  • Общее хранилище ВМ (iSCSI, NFS, FC), необходимо чтобы все хосты в кластере с VMotion имели доступ к хранилищу;
  • Одинаковая конфигурация виртуальной сети на всех хостах в кластере с VMotion (название порт групп, VLAN ID и т.п.). Не обязательно идентичная должна быть конфигурация сетки. Главное чтобы совпадала конфигурация основных порт групп к которым привязаны мигрируемые ВМ. Ну и порт группы на хостах должны иметь одинаковый доступ к физической сети;
  • Процессоры на хостах должны иметь одинаковый набор инструкций и быть близкими друг к другу по функциям и инструкциям. В идеале один тип CPU или же одно поколение и один и тот же набор инструкций (например, линейка Intel Xeon 54XX). Это главное и главный подводный камень. Частота и другие параметры CPU не важны. Также важна основная архитектура и производитель, например, совместить хосты с Intel и AMD CPU не получится;
  • Интерфейс VMkernel с включенной опцией VMotion;

Теперь немного о CPU и совместимости.

О совместимости процессоров VMotion CPU Compatibility Requirements for Intel Processors и VMotion CPU Compatibility Requirements for AMD Processors.

Если у Вас одна линейка CPU с одинаковыми инструкциями на всех хостах, то проблем нет. А вот если разные, то тут будут проблемы. При миграции ВМ мастер сразу выдаст предупреждение на несовпадение масок CPU.  Это можно обойти при условии, что CPU находятся близко друг к другу по функциям и инструкциям.

Способ первый.

Официально поддерживаемый VMware — EVC (Enhanced VMotion Compatibility). Суть технологии в том, что EVC автоматически настраивает кластер для совместимости процессоров разных поколений. В разрезе совместимость достигается тем, что на хостах где CPU более новые с новыми инструкциями, отключаются (если быть точным и более правильно, то просто не используются) данные инструкции. Скажем, если есть два хоста с CPU Intel Xeon 54XX и Intel Xeon 55XX, при выборе правильного режима EVC, на хосте с CPU Intel Xeon 55XX не используются инструкции, которых нет в Intel Xeon 54XX. В данном примере просто в кластере ВМ не будут использовать инструкции SSE 4.2.

Основной плюсы EVC то что применяется сразу ко всему кластеру, т.е на все хосты при активации. Недостаток в том, что EVC должны поддерживать сами CPU. Если CPU не поддерживает EVC, тогда смотрим чуть ниже. Плюс ко всему если у вас в кластере были хосты с ВМ в которых идут операции с поддержкой неиспользуемых функций CPU, то их придется переносить в другой кластер.

O поддержке процессоров EVC и режимах прочитать можно тут.

EVC включить очень просто.

Идем в свойства кластера.

Далее в раздел VMware EVC. По умолчанию EVC выключена.

Жмем Change и выбираем нужный режим. Если брать предыдущий пример, то для него нужный нам режим Intel Xeon 45nm Core 2.

При выборе правильного режима и соблюдение всех условий появится подобная картинка

Кстати забыл написать. Главное перед включением EVC необходимо выключить ВМ, на том хосте, который по функциям будет выравниваться. Обычно хост с более новыми CPU выравнивается под более старые CPU другого хоста. Запутано,  возможно, простота в том, что мастер сам вам подскажет на каком хосте нужно вырубить ВМ.

После применения EVC можно спокойно мигрировать машины между хостами в кластере.

Способ второй.

Править вручную маску CPU и ВМ. Основным плюсом можно назвать, что конфигурировать можно более гибко. Например в кластере с разношерстными хостами по CPU и ВМ по функциям. Но и главный недостаток в том, что конфигурировать придется каждую ВМ по отдельности. Плюс ко всему данный способ официально не поддерживается VMware, так что скажем buy сапорту VMware.

И так как править маски CPU у ВМ.

Первое что нужно сделать это прочитать вот этот KB от VMware и еще на английском вот это.

Если с английским плохо, читаем дальше. Опишу, как изменить маску по примеру приведенному выше для CPU x5400 и x5500.

Из KB для Intel CPU дана вот такая таблица.

Отличие инструкций между семействами CPU x5400 и x5500 только в поддержки SSE 4.2 у последнего. Поэтому в маске нужно указать, чтобы не использовались данные инструкции. Все очень просто.

Выключаем нужную ВМ. Идем в ее свойства. Вкладка Options -> CPUID Mask.

Жмем Advanced. Далее исходя из таблички выше нам нужно подправить маску в уровнях 1, строку ecx  и 800000001, строку edx.

Кликаем на нужную строчку, в нашем случае edx строка  и пишем туда следующее —- 0— —- —- —- —- —- —-

Далее находим следующую строчку, и пишем как указано в таблице из KB —- —- 0—0 —- —- —- —- —-

Все применяем нужные изменения. Ждем когда закончится реконфигурация ВМ и запускаем ее. Все теперь данную ВМ можно спокойно мигрировать. Мастер VMotion не должен выдавать предупреждений по поводу несовпадения масок.

Способ третий.

Глобальное изменение масок в файле конфигурации vCenter’а. Если Вам не подходит EVC, а нужен VMotion, а также у Вас разные поколения CPU и много ВМ, то это именно то что доктор прописал. Описание способа доступо в этом KB и начинается с пункта Global Masking with ESX Server 2.x and Later.

Теперь о самой настройки VMotion.

Тут все просто. Выше я уже приводил что необходимо для работы VMotion.

И так у нас есть общий LUN с ВМ, кластере в vCenter. Также настройки сетевой конфигурации идентичны на всех хостах. На всех хостах идентичные CPU по инструкциям или же включено EVC/подправлены маски. Осталось малое, сконфигурировать VMotion для работы.

Первое что нужно сделать это добавить порт VMkernel и при конфигурирование поставить галочку VMotion на всех хостах. Подробно описывать сей процесс не буду, так как уже делал заметку о VMkernel ранее.

В принципе на этом и все с конфигурацией. Далее еще проще. Выбираем нужную ВМ в клиенте vSphere, клик правой кнопкой мыши — >Migrate.

Открывается мастер. Выбираем Change host.

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

Далее будут еще две странички мастера. Страничка приоритета VMotion, тут можно оставить то что предлагает мастер, и последняя страница со сводной инфой. Все жмем Finish и ждем когда ВМ мигрируется на новый хост.

Вот и все.

Ах да еще напишу основные рекомендации относительно VMotion.

  • Гигабитная сеть, как минимум;
  • Хороший коммутатор (физический :-) ) с поддержкой VLAN и хорошей пропускной способностью;
  • В идеале выделенный, как минимум один физический сетевой адаптер под нужды VMotion, а лучше два;
  • Отдельная сеть со своим VLAN для VMotion;
  • Отдельный vSwitch и отдельный порт VMkernel с VMotion. Но это не обязательно, просто я так обычно стараюсь конфигурировать;

сперто http://cloudgeek.me/2010/03/vmotion-guide/

Написать комментарий
Первое ⇥
← Позже 3-я (и последняя) страница Раньше →