Невозможность создать VMFS Datastore

Бывает, при переключении уже использовавшихся где-то LUN'ов на дисковом массиве к ESX'ам возникает ошибка: "Unable to read partition information from this disk"

Решение:
[root@esx2 root]# esxcfg-vmhbadevs
vmhba0:0:0 /dev/cciss/c0d0
vmhba1:0:1 /dev/sda
...
vmhba2:2:13 /dev/sdt

[root@esx2 root]# fdisk /dev/sdt

Command (m for help): o
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


The number of cylinders for this disk is set to 36643.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Теперь можно создавать VMFS Datastore.

Бездисковый ESXi и HA

При попытке включения HA на бездисковом ESXi (который на флэшке), выдается ошибка "Host in HA Cluster must have userworld swap enabled".

Решение: установить параметр Configuration / Advanced Settings / ScratchConfig / ScratchConfig.ConfiguredScratchLocation
Следует указать путь до datastore, открытого на запись. Т.е. нечто вроде /vmfs/volumes/4815cfef-9846d1c6-3a4b-001b783137c8, и перезагрузить хост.

Там появится файлик uwswap. В случае нескольких хостов разумнее будет создать на datastore директорию для таких файлов, причем у каждого хоста директория должна быть уникальна. Т.е. /swap/host1, /swap/host2

Грабли с Virtual Center - не получается залогиниться

Проблема: свежеподнятый домен, розданы permissions, а человек не может залогиниться для работы на VirtualCenter.

Резюме: для успешного логина необходимо, чтобы не стояло "сменить пароль при следующем входе" для пользователя.

Грабли с ESXi Embedded

Есть ESXi на флэшке - был воткнут в один сервер, а потом в другой. А серверы соотв. воткнуты в разные коммутаторы. И начались проблемы. Сеть на том сервере, в который была флэшка воткнута сначала - не работает. И точка.
Проверяем с Cisco-водом - MAC адреса первого сервера каким-то образом оказались на втором по отчету коммутатора. А такое просто невозможно, поскольку там сетевые карты даже разных производителей. Гашу второй сервер - на первом сеть появляется и ходят пинги. Поднимаю - пропадает. В настройках сети на втором сервере MAC показываются правильные.

Резюме проблемы: при первом запуске ESXi съедает MAC адреса сервера и больше не интересуется железом, соотв. физические адаптеры он использует в качестве дырок в сеть, а вот пакеты и все остальное, формирует сам - со старыми MAC'ами. В итоге коммутаторам сносит крышу. Если требуется перенести ESXi на другой сервер, то производится страшное колдунство: сетевые интерфейсы в management network поочередно гасятся и поднимаются с сохранением настроек. Тогда ESXi съест новые адреса и будет жить долго и счастливо.

Особенности раздачи permission в VMware VI

Ситуация.
Есть два кластера ESX-серверов. Есть человек с правами Virtual Machine Administrator на одном из кластеров. Новые виртуалки создаются от его лица без проблем, а вот клонировать или развернуть из шаблона не получается. При выборе Datastore возникает исключение "No permission".

Решение.
Создается роль "Browse Datastore" и применяется к "Main" БЕЗ наследования (Propagate = off).

Виртуальность от Sun

Вчера вышел долгожданный Sun xVM Server.

Bare-metal гипервизор с очень серьзной заявленной функциональностью. Поддерживается DRS, HA и VMotion в терминах VMware. Интегрируется в xVM Ops Center для управления инфраструктурой. Все очень неплохо, но...
1. Работает только на x86 процессорах с аппаратной виртуализацией.
2. Пока поддерживается только RHEL 4.6/5.2, Windows 2003/2008 и, разумеется, Solaris в качестве гостевых ОС.
3. Просто так для попробовать его не скачаешь.

Но это в любом случае хороший удар по светлому будущему MS Hyper-V.

Для SPARC у Sun есть два решения: Solaris Containers и Logical Domains. О контейнерах расскажу позже, а вот LDoms ну очень сильно напоминают по архитектуре VMware ESX, с той лишь разницей, что работают поверх ОС. Но вот ничего аналогичного VI клиенту у Sun для LDoms нет, и необходимость конфигурирования всего этого счастья из командной строки как минимум сильно удручает.

Microsoft и Live Migration

Microsoft, как обычно, жжот. И все больше тряпки.

Только что они показали Live Migration, причем каким-то очень странным образом доказали, что это действительно Live. И сразу же отложили релиз на 2 года, до 2010.

Еще забавнее то, что Microsoft по странной совершенно прихоти относит Live Migration, оно же VMotion к разряду High Availability, решений высокой доступности. Что, собственно, заставляет задуматься - какую траву там курят?
High Availabity (HA) - решения, минимизирующие незапланированное время простоя. Т.е. сбой физического сервера, его неожиданное отключение. И к этому VMotion не имеет ровным счетом никакого отношения попросту потому что это решение для минимизации и, в некоторых случаях, вообще ликвидации запланированного простоя для технического обслуживания.

Напомню, что Microsoft не предоставляет кластерной файловой системы для общего хранилища, такую как VMFS у VMware. И по причинам марктетинговой гордости не собирается ее покупать на стороне. В результате мы имеем ситуацию, когда для каждой виртуальной машины необходимо нарезать отдельный LUN для монопольного доступа. Правда интересное решение, особенно в случае с большими VDI фермами в сотни и тысячи виртуальных десктопов? :)