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

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

Create a snapshot with large virtual disk

Пятница, 16 сентября 2011, 14:19

Короткая заметка, в качестве напоминания.

В предыдущих версиях vSphere магическое число 2TB-512bytes ограничивало нас во всём: vmdk-файлы (для максимального размера блока), RDM, datastore size.

Для vSphere 5 и VMFS 5 ограничения несколько изменились:
    Max Volume size    — 64TB
    pRDM                    — 64TB
    vmdk-файл, vRDM — 2TB-512bytes (даже для датасторов, обновлённых с VMFS 3 на VMFS 5)

Так вот, нужно учитывать один момент, создавая диски размером ровно или близким к 2TB. Всё, что связано со снапшотами, для них может не заработать:



То есть, основная проблема может возникнуть при резервном копировании такого диска. И выясниться это может уже когда данные будут залиты а то и когда будут уже в продакшене :)

Полезные ссылки:

kb 1012384

vsphere-50-configuration-maximums.pdf

Вопрос в комьюнити

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

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. Рекомендую!

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

vSphere: 4.0 -> 4.1

Среда, 15 сентября 2010, 15:47

Обновление тестового кластера прошло неудачно :(

Мигрировал VC 4.0, win 2003 R2 32bit на VC 4.1, win 2008 R2 (SQL и там и там - локальный Express). Hostname и IP наследовались.

Datamigration tool сначала отказывалась видеть прежний SQL - помогла kb 1024490, последний пункт. После этого backup.bat и install.bat на обоих машинах браво отрапортовали что всё sucessfull, но после подключения клиентом, в inventory было пусто. При этом только что установленный vCenter ругался на окончание своего Evaluation period. В логах тоже ничего криминального не было найдено.

Далее обновил два ESXi c 4.0 до 4.1:

C:\Program files\VMware\VMware vSphere CLI\bin>vihostupdate.pl --server 10.10.10.104 --install --bundle c:\TEMP\upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip

Сразу после обновления оба хоста добавил в vCenter. Спустя какое-то время хост1 начал сыпать варнингами, а потом вообще перестал пинговаться. Разбираясь локально в чём дело, выяснил что после перезагрузки перепутались местами(!) и IP адресами vmknic'и :) Управляющий vmk0 поменялся портгруппой (и виртуальным свичём) с vmk1 (который был для NFS). NFS трафик у меня ходит в отдельной физической сети.

В довершении всего, через локальную консоль (ту. что на жёлтом фоне) не получалось не переопределить управляющий vmk, ни сменить ему IP. После подтверждения изменений всё оставалось прежним. Пришлось править всё руками в TechSupport Mode.

Источники:

vSphere 4.1 upgrade pre-installation requirements and considerations

Migrating an existing vCenter Server database to 4.1 using the Data Migration Tool

vSphere Upgrade Guide

Upgrading ESX 4.0 to ESX 4.1(video: UM, esxupdate, vihostupdate)

 

В итоге, подозреваю что сам виноват и мог где-то что-то упустить из виду. Я не стал детально прорабатывать план миграции и кое-где дочитывал "на ходу", потому что и задумывал в небоевых условиях пособирать раскиданные грабли.

Но даже по сравнению с предыдущим переездом с 3.5 на 4.0, количество найденного садового инвентаря несколько огорчает.

 

UPD: Как выяснилось, это не я налажал -- это известная ошибка, связанная с тем что datamigration tool некорректно обрабатывает локальный SQL Express. Подробности в kb.

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

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-я страница Раньше →