Проблема: свежеподнятый домен, розданы permissions, а человек не может залогиниться для работы на VirtualCenter.
Резюме: для успешного логина необходимо, чтобы не стояло "сменить пароль при следующем входе" для пользователя.
вторник, 30 сентября 2008 г.
Грабли с ESXi Embedded
Есть ESXi на флэшке - был воткнут в один сервер, а потом в другой. А серверы соотв. воткнуты в разные коммутаторы. И начались проблемы. Сеть на том сервере, в который была флэшка воткнута сначала - не работает. И точка.
Проверяем с Cisco-водом - MAC адреса первого сервера каким-то образом оказались на втором по отчету коммутатора. А такое просто невозможно, поскольку там сетевые карты даже разных производителей. Гашу второй сервер - на первом сеть появляется и ходят пинги. Поднимаю - пропадает. В настройках сети на втором сервере MAC показываются правильные.
Резюме проблемы: при первом запуске ESXi съедает MAC адреса сервера и больше не интересуется железом, соотв. физические адаптеры он использует в качестве дырок в сеть, а вот пакеты и все остальное, формирует сам - со старыми MAC'ами. В итоге коммутаторам сносит крышу. Если требуется перенести ESXi на другой сервер, то производится страшное колдунство: сетевые интерфейсы в management network поочередно гасятся и поднимаются с сохранением настроек. Тогда ESXi съест новые адреса и будет жить долго и счастливо.
Проверяем с Cisco-водом - MAC адреса первого сервера каким-то образом оказались на втором по отчету коммутатора. А такое просто невозможно, поскольку там сетевые карты даже разных производителей. Гашу второй сервер - на первом сеть появляется и ходят пинги. Поднимаю - пропадает. В настройках сети на втором сервере MAC показываются правильные.
Резюме проблемы: при первом запуске ESXi съедает MAC адреса сервера и больше не интересуется железом, соотв. физические адаптеры он использует в качестве дырок в сеть, а вот пакеты и все остальное, формирует сам - со старыми MAC'ами. В итоге коммутаторам сносит крышу. Если требуется перенести ESXi на другой сервер, то производится страшное колдунство: сетевые интерфейсы в management network поочередно гасятся и поднимаются с сохранением настроек. Тогда ESXi съест новые адреса и будет жить долго и счастливо.
четверг, 11 сентября 2008 г.
Особенности раздачи permission в VMware VI
Ситуация.
Есть два кластера ESX-серверов. Есть человек с правами Virtual Machine Administrator на одном из кластеров. Новые виртуалки создаются от его лица без проблем, а вот клонировать или развернуть из шаблона не получается. При выборе Datastore возникает исключение "No permission".
Решение.
Создается роль "Browse Datastore" и применяется к "Main" БЕЗ наследования (Propagate = off).
Есть два кластера ESX-серверов. Есть человек с правами Virtual Machine Administrator на одном из кластеров. Новые виртуалки создаются от его лица без проблем, а вот клонировать или развернуть из шаблона не получается. При выборе Datastore возникает исключение "No permission".
Решение.
Создается роль "Browse Datastore" и применяется к "Main" БЕЗ наследования (Propagate = off).
Ярлыки:
permission,
VI,
VMware
Виртуальность от 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 нет, и необходимость конфигурирования всего этого счастья из командной строки как минимум сильно удручает.
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 нет, и необходимость конфигурирования всего этого счастья из командной строки как минимум сильно удручает.
среда, 10 сентября 2008 г.
Microsoft и Live Migration
Microsoft, как обычно, жжот. И все больше тряпки.
Только что они показали Live Migration, причем каким-то очень странным образом доказали, что это действительно Live. И сразу же отложили релиз на 2 года, до 2010.
Еще забавнее то, что Microsoft по странной совершенно прихоти относит Live Migration, оно же VMotion к разряду High Availability, решений высокой доступности. Что, собственно, заставляет задуматься - какую траву там курят?
High Availabity (HA) - решения, минимизирующие незапланированное время простоя. Т.е. сбой физического сервера, его неожиданное отключение. И к этому VMotion не имеет ровным счетом никакого отношения попросту потому что это решение для минимизации и, в некоторых случаях, вообще ликвидации запланированного простоя для технического обслуживания.
Напомню, что Microsoft не предоставляет кластерной файловой системы для общего хранилища, такую как VMFS у VMware. И по причинам марктетинговой гордости не собирается ее покупать на стороне. В результате мы имеем ситуацию, когда для каждой виртуальной машины необходимо нарезать отдельный LUN для монопольного доступа. Правда интересное решение, особенно в случае с большими VDI фермами в сотни и тысячи виртуальных десктопов? :)
Только что они показали Live Migration, причем каким-то очень странным образом доказали, что это действительно Live. И сразу же отложили релиз на 2 года, до 2010.
Еще забавнее то, что Microsoft по странной совершенно прихоти относит Live Migration, оно же VMotion к разряду High Availability, решений высокой доступности. Что, собственно, заставляет задуматься - какую траву там курят?
High Availabity (HA) - решения, минимизирующие незапланированное время простоя. Т.е. сбой физического сервера, его неожиданное отключение. И к этому VMotion не имеет ровным счетом никакого отношения попросту потому что это решение для минимизации и, в некоторых случаях, вообще ликвидации запланированного простоя для технического обслуживания.
Напомню, что Microsoft не предоставляет кластерной файловой системы для общего хранилища, такую как VMFS у VMware. И по причинам марктетинговой гордости не собирается ее покупать на стороне. В результате мы имеем ситуацию, когда для каждой виртуальной машины необходимо нарезать отдельный LUN для монопольного доступа. Правда интересное решение, особенно в случае с большими VDI фермами в сотни и тысячи виртуальных десктопов? :)
Ярлыки:
Hyper-V,
live migration,
Microsoft
Подписаться на:
Сообщения (Atom)