Добрый день.
Моя виртуальная инфраструктура очень маленькая. На данный момент она содержит всего два хоста – DL380G5 и тестовый DL140G3. На одном из хостов стоит ESX3,5i update4, на втором – ESX4i update1. Тестовый держит на себе ESX4i и служит для проверки апдейтов от VMware (в будущем думаю от него отказаться).
После покупки пакета vSphere Essentials встал вопрос о миграции/апгрейде с ESX3,5i на четверку. Был изучен интернет, найдено несколько ссылок про обновление хостов (с Update Manager и с Host Update).
Category: vSphere
Сдача экзаменов VMware
VMware Training and Certification пишет, что продлена сдача апгрейда VCP3->VCP4:
До конца 31 января 2010 года возможна сдача экзамена для счастливых владельцев предыдущей версии VCP без обязательного прохождения курса. Сам экзамен по VCP3 можно сдавать до конца марта.
Там же рассказывается последовательность сдачи теста с учетом VMware Second Shot:
- 15 января 2010 = последний день для регистрации ваучера на пересдачу(до 17:00);
- 22 января 2010 = последний день для неудачной сдачи VCP4, если вам потребуется бесплатная пересдача;
- 31 января 2010 = последний день для бесплатной пересдачи экзамена
Все же я попробую сдать тест в январе…
Апгрейд виртуального железа в vSphere или смерть контроллера
Тут мы уже писали про то, как обновить виртуальные машины, созданные в ESX3,5. Обновление виртуального железа может понадобиться, если у вас есть нагруженные виртуальные машины.
Joshua Townsend делится негативным опытом по апгрейду виртуального железа на виртуальном контроллере домена.
Суть геморроя в том, что при апгрейде сетевого адаптера AD, DNS и DHCP остаются привязанными к старому сетевому адаптеру. Соответственно, рекомендуется:
- иметь несколько контроллеров домена;
- сразу после обновления зайти через консоль, удалить скрытый старый сетевой адаптер и перезагрузить сервер.
Или же вы можете оставить виртуальные контроллеры домена на “Virtual Hardware version 4”, vSphere пока поддерживает такое железо.
UPD: diz пишет “Удаление скрытых сетевых адаптеров: http://support.microsoft.com/kb/269155/ru “
Memory Overcommitment и Hyper-V
Антон недавно написал статью, объясняющую смысл “фичи” переиспользования памяти. Глубинный смысл в том, что вам может понадобиться меньшее количество физических серверов, если этот функционал задействован. 🙂
Согласен с Антоном и анонимусом в том, что нужно МНОГО ВМ, чтобы этот функционал начал окупаться.
Также вспомнил статью от Микрософта, в которой описывается, как 600+ серверов уместились на 22 хостах. Использовался гипервизор – Hyper-V v1.
Правда, статья – гольный маркетинг без технических деталей.
Ответ на “9 причин не в пользу Hyper-V”
Поклонники Hyper-V не сдаются и предлагают рассмотреть причины поглубже. James O’Neill в своем блоге написал ответ на статью “9 причин, из-за которых крупные предприятия не должны переключаться на Hyper-V“, пересказ который был опубликован на нашем сайте.
Итак, пересказ “Углубимся в те причины, которые против переключения на Hyper-V“: Continue reading “Ответ на “9 причин не в пользу Hyper-V””
Нужны ли нам SSD
Вот тут предлагают использование SSD-дисков в качестве хранения свопа для хостов с memory overcommitment (когда ВМ имеют больше памяти, чем есть на хосте). Используются три следующие конфигурации хранилища под своп:
- SSD: 32GB (local)
- FC: 4*146GB, 15K rpm FC drives configured as RAID-0 (SAN)
- SATA: 2*146GB SATA drives configured as RAID-0 (local)
Потери производительности у SSD по сравнению с оперативной памятью составляют ~15%, у FC ~75%, у SATA ~90%.
Вот так вот.
Рекомендации при использовании VMware VI
Портал VMGuru.nl выдает зачетные рекомендации для использования виртуальной инфраструктуры VMware.
Эти рекомендации особенно полезны при создании новой инфраструктуры, хотя и для существующей будут полезны. Переведем 😉
Рекомендации касаются:
– ESX(i);
– vCenter;
– Лицензирование;
– СХД;
– Сеть;
– Виртуальные машины.
Continue reading “Рекомендации при использовании VMware VI”
ESX4i поддерживает Jumbo Frames
Александр Самойленко делится шикарной новостью – оказывается ESX4i уже поддерживает Jumbo Frames. Воистину, отличная новость для владельцев iSCSI-стораджей. А Mister Nobody учит пользоваться гуглом:
– Залогиньтесь через SSH или локальную консоль на ESXi;
– $ esxcfg-vswitch -l … Смотрим текущие MTU
– $ esxcfg-vswitch -m 9000 vSwitch0 … Устанавливаем MTU на нулевом свитче (Jumbo Frames)
– $ esxcfg-vswitch -l … Проверяем корректность изменений
– … повторяем фокус с другими виртуальными свитчами …
– $ esxcfg-nics -l … Проверяем, что у каждого сетевого адаптера изменился MTU
Перезагружаем сервер.
Upd: Поддержку Jumbo Frame имеют ТОЛЬКО виртуальные адаптеры enhanced vmxnet (and vmxnet3) (kb). Например, e1000 будет просто откидывать пакеты с MTU>1500. За наводку спасибо.
Проблемы со Storage vmotion в VI3,5
Коллега столкнулся с граблями при использовании двух вещей:
– плагина storage vmotion к VI3,5;
– NFS-сервера на базе Windows Server 2003.
При перемещении ВМ создается снимок. И все бы ничего, но он содержит в имени файла символ “:”, который запрещен для использования в файловой системе NTFS. Сейчас у коллеги есть рабочий снимок весом в 200Мб, который отсутствует в Snapshot Manager.
Решаем проблему 😉
Предсказания 2010: VMware урежет цены, Citrix сбросит XenServer
Alex Barrett сделал парочку интересных прогнозов на 2010 год.
Во-первых, VMware уменьшит цены на свои продукты либо добавить функционал в существующие.
Во-вторых, Citrix откажется от дальнейшей разработки XenServer.