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

Неразборчивое о виртуальном
Записи с меткой howto

Removing orphaned Nexus

Пятница, 16 ноября 2012, 20:35

Сегодня коллеги озадачили вопросом: "Как вычистить из инфраструктуры vCenter некорректно удалённый виртуальный коммутатор Nexus 1000v"?

Не знаю, почему так случилось, но аплинки и машины были перенесены на другие коммутаторы, модули VMS и VEM уже удалены, но в инфраструктуре объекты всё ещё существовали:



Когда-то я уже удалял из базы vCenter машину-призрака, поэтому решили пойти по тому же пути:

0. Делаем бекапы всего что необходимо!
1. Cтопим службу VMware VirtualCenter Server.
2. В Management Studio идём: <SQL север> ->Databases -> <имя БД для vCenter> -> Tables -> dbo.VPX_VDS. В контекстном меню Edit top 200 Rows. Удаляем строку с общими параметрами Nexus'а.
3. Аналогично удалению виртуалки необходимо удалить сам коммутатор и все всязанные объекты в таблице: Tables -> dbo.VPX_ENTITY. Ищем по имени объект самого свича и обращаем внимание на его ID. Далее в таблице находим все связанные объекты (с темже ID в колонке PARENT_ID) и удаляем сначала их. Последним удаляем строку с самим родительским объектом - коммутатором.


4. Ребутаем службу SQL Server для уверенности. И стартуем службы VMware VirtualCenter Server и все зависимые.

Учитывая, что вмешательство в данные базы часто приводит к срочному восстановлению из бекапа не совсем безопасно Frank Denneman предлагает более элегантный способ тогоже самого.

Источники:

http://kb.vmware.com/kb/1026009

http://frankdenneman.nl/networking/removing-orphaned-nexus-dvs/

Написать комментарий
howto  kb  vSphere 5  

Hyper-V inside ESXi 4.x

Пятница, 9 сентября 2011, 15:57

Уже широко известно, что недавно вышедщий ESXi 5 позволяет "полноценно" виртуализовать ESXi 4/5 и запускать в виртуальном гипервизоре вм с 64-битной ОС. Т.е. появилась удобная возможность создавать тестовые площадки для экспериментов и обучения в пределах одного железного сервера. Например, сейчас у меня такая создана для vShield App/Edge.

Кроме того, таким же образом в вм можно запускать и сторонние гипервизоры, например MS Hyper-V.

Предыдущие версии ESX(i) также могли виртуализовать сами себя с некоторыми дополнительными настройками. Но виртуализовать Hyper-V даже с ними не удавалось.

Ниже следует кусок из моей переписки как поднять роль Hyper-V в вм на ESXi 4.1.

Поднять роль Hyper-V оказалось не так сложно:

1. Создал вм из темплейта с установленной Win 2008 R2 Ent (в моём случае: 2 CPU, 3 GB MEM)

2. В выключенном состоянии выставил такую маску:

3. Стандартный Next>Next>Next мастера установки роли Hyper-V. Перезагрузка.

4. ...

5. PROFIT!!!

Обратите внимание, это чистой воды обман установщика и VMBus после ребута, естественно, не стартует. Хотя во всём остальном, насколько я могу судить, роль отрабатывает полноценно.

Большой практической ценность (особенно с выходом vSphere 5) этот хак не имеет, но для ознакомления с продуктом MS когда под рукой нет ESXi 5, думаю, вполне сойдёт.

PS: Вот тут обо всё этом более подробно на английском.

PPS: Очень полезная дока по запуску "чужих" гипервизоров в гипервизорах VMware. Рекомендую!

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

How to mount CD-ROM in ESXi

Среда, 30 марта 2011, 18:26

Задача редкая и несколько экстравагантная, но, возможно, кому-то будет полезно.

На сайте стоят хосты с ESXi 4.1. Загрузка с флешки. Внешного хранилища пока нет. Локальных дисков нет. Населена роботами. На всех хостах сейчас нужно перепрошить сетевые карты.

Подключаем CD-ROM в консоль ESXi:

1) esxcfg-mpath -l
   <...>
   ide.vmhba0-ide.0:0-mpx.vmhba0:C0:T0:L0
      Runtime Name: vmhba0:C0:T0:L0
      Device: mpx.vmhba0:C0:T0:L0
      Device Display Name: Local TEAC CD-ROM (mpx.vmhba0:C0:T0:L0)
   <...>
2) vmkload_mod iso9660

3) /sbin/vsish -e set /vmkModules/iso9660/mount mpx.vmhba0:C0:T0:L0

CD-ROM появится в списке /vmfs/volumes/

4) PROFIT!!!

Thx to: agodwin

PS: Можно, конечно, загрузиться с какой-нибудь liveCD, но мы же лёгких путей не ищем :)

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

Masking a LUN from ESX(i) 4.x

Пятница, 10 сентября 2010, 17:32

Начиная с версии ESX(i) 4.0, изменилась процедура маскирования LUN'ов на уровне гипрвизора. Вместо прописывания адресов LUN в Advance Settings -> Disk -> Disk.MaskLUNs, в vSphere для все путей переопределятся плагин PSA на специальный - MASK_PATH.

Для начала удаляем из инвентори все объекты, связанные со скрываемым LUN'ом. Далее:

1. esxcfg-scsidevs -l Первой строчкой описания каждого устройства идёт LUN_ID, запоминаем его для скрываемого LUN'а

2. esxcfg-mpath -L | grep <LUN_ID> Находим все пути для этого раздела. Запоминаем адрес ввиде: vmhba#:C#:T#:L#, в моём случае vmhba2:C0:T2:L0. При желание, это можно сразу посмотреть в vSphere Client.

3. esxcli corestorage claimrule add --rule 123 -t location -A vmhba2 -C 0 -T 2 -L 0 -P MASK_PATH Добавляем правило в конфигурационных файл. Выбираем любой незанятый номер правила, но обязательно из диапазона 101--200.

4. esxcli corestorage claimrule load Загружаем созданное правило в список активных

5. esxcli corestorage claimrule list Проверяем, что в списке есть два одинаковых правила с выбранным номером с параметрами file и runtime.

6. esxcli corestorage claiming reclaim -d <LUN_ID> Переопределяем текущие правила для путей раздела на только что созданные.

Всё. Считаем до 10 и LUN больше недоступен для добавления datastor'а. Все пути, помеченные MASK_PATH, переходят в состояние Dead.

По статье kb.

Для чего это нужно? Например, для процедуры корректного удаления LUN'а "на лету":

Удаляем всё с LUN'а-> маскируем его-> отменяем презентацию LUN'а хосту средствами стораджа-> удаляем правила маскирования.

Написать комментарий
howto  kb  vSphere 4  

"Неубиваемая" перезагрузками вм и чистка хвостов в БД.

Четверг, 9 сентября 2010, 16:33

Меня заинтересовал случай с "неубиваемой" перезагрузками хоста вм, и я попробовал смоделировать подобное у себя. Я не стал придумывать, как загнать машины в такое состояние, а просто после удаления записей о ней в БД и при выключенной службе vc server, удалил машину подключившись напрямую к хосту.

DISCLAIMER: Алгоритм приведён "как есть". Используйте всё ниже следующее на свой страх и риск!


1. Застопил службу VirtualCenter Server.
2. Для доступа к БД vCenter (дефолтная SQL2005 Express в моём случае) скачиваем и устанавливаем Microsoft SQL Server Management Studio Express.
3. Подключившись к SQL server, в его инвентори идём: <SQL север> ->Databases -> <имя БД для vCenter> -> Tables -> dbo.VPX_VM. В контекстном меню выбираем Open Table.
В таблице будет представлен список всех машин, зарегистрированных в vCenter. Ищем по названию и удаляем всю строчку с машиной-призраком.
4. Путём проб, ошибок и нестартующего вцентра выяснлось, что ВМ надо удалить ещё в одном месте: Tables -> dbo.VPX_ENTITY. В этой таблице собраны все объекты из Inventory, т.ч. аналогично ищем строчку с именем машины-призрака.

UPD: для версии SQL 2008 в меню надо выбрать пункт Edit top 200 Rows

5. Дальше запускаем службу VMware VirtualCenter Server и подключаемся к нему vSphere Client'ом - машины в инвентори нет.


 

ИМХО изменения, вносимые штатными средствами MS SQL, не должны сказаться на целостности самой БД. Но хочу ещё раз напомнить, что только актуальные бекапы в случае чего смогут спасти отца русской демократии :)

Написать комментарий
⇤ Последнее
← Позже 1-я страница Раньше →