VMware User Group Russia

Уважаемые коллеги, хочу пригласить вас в группу VMware User Group Russia социальной сети LinkedIn.

VMware vExpert Award

Примерно месяц назад VMware объявила о программе vExpert. Звание vExpert присуждается за полезную активность, проявленную в сообществе, онлайн или оффлайн. Например, за ведение технических блогов соотв. тематики.

И было чрезвычайно приятно сегодня утром обнаружить поздравления Джона Тройера (John Troyer), менеджера программы, с присуждением этого почетного звания вашему покорному слуге. Всего в мире его получили около 300 человек.

Пользуясь случаем, хочу поздравить и главного российского vExpert Михаила Михеева :)



Upd: Разумеется, искренние поздравления и еще одному российскому vExpert'у, Александру Самойленко.

Upd2: Ура Дмитрию Мощалкову! :)

VI Toolkit 1.5: Quick Reference

Quick Reference by Virtu-Al, или попросту шпаргалка по VI Toolkit 1.5 - здесь.

ESX vs Hyper-V: цена

Хочется сравнить ESX и Hyper-V по цене. Разумеется, сравнивать будем варианты, интересные enterprise уровню, ибо в случае с SOHO и так все понятно, оба гипервизора бесплатны.

1) простой кластер из 3х хостов
ESX: $3624 (vCenter, VMFS, vSMP, VCB) - VMware Infrastructure Foundation Acceleration Kit (1 год поддержки включен)
Hyper-V: $0 ($505) - без и с SC VMM.

2) HA кластер из 3х хостов
ESX: $7254 + $3624 = $10878 - VMware Infrastructure Standard High Availability Acceleration Kit + VMware Infrastructure Standard
Hyper-V: $12000 + $505 = $12505 - 3*Windows 2008 Enterprise + SC VMM (в "комплекте" идут 12 лицензий на Windows 2008)
Hyper-V 2: $24000 + $505 = $24505 - 6*Windows 2008 Datacenter (исходя из предположения о 2х-процессорных серверах) + SC VMM

3) DRS+HA кластер на 6 хостов (или 2 по 3, что одно и то же)
ESX: $23218 + $20874 = $44092 - VMware Infrastructure Midsize Acceleration Kit + 3*VMware Infrastructure Enterprise
Hyper-V: $24000 + $5214 = $29214 - 6*Windows 2008 Enterprise + SC VMM (в "комплекте" идут 24 лицензии на Windows 2008)
Hyper-V 2: $48000 + $5214 = $53214 - 12*Windows 2008 Datacenter (исходя из предположения о 2х-процессорных серверах) + SC VMM

Казалось бы, все ясно и прекрасно - Hyper-V однозначно выигрывает по цене. Особенно с учетом того, что при использовании ESX необходимо еще и покупать лицензии на гостевые Windows Server. Но, как говорил Василий Иванович, "есть один нюанс". На самом деле нюансов куда больше.

1) В данном расчете не учитывается цена на иные гостевые ОС и продукты, работающие в этих ВМ. Таким образом, если мы создаем виртуальную инфраструктуру для Linux, то замечательные "бесплатные" лицензии на Windows Server нам попросту не нужны.
2) Hyper-V безоговорочно проигрывает ESX по возможностям и удобству настройки сетевого окружения ВМ.
3) Hyper-V в текущем релизе НЕ имеет Live Migration aka VMotion, поэтому сравнение номер 3 в известной мере некорректно.
4) Hyper-V в паре с SC VMM НЕ имеет средств резервного копирования ВМ, аналогичного VCB. И соотв. вместо $505 для рабочих групп (до 5 хостов) и $864 за хост (для SC VMM) придется брать уже SC SMSE по цене в $1500 за хост.
5) Hyper-V не умеет и даже неясно когда будет уметь Memory Overcommit, не говоря уже о Transparent Page Sharing. А эти технологии позволяют более плотно "упаковывать" ВМ на хост. Так что при кластере в 6 Hyper-V вполне может получиться, что на ESX достаточно кластера всего в 4 хоста для того же количества ВМ. В случае с VDI все станет совсем интересно.
6) Развивая пункт 1 - неправильно считать цены на гипервизоры, нужно считать TCO. А TCO - это TOTAL cost ownership, цена содержания всего хозяйства, начиная от серверных помещений и заканчивая зарплатой системных администраторов. Даже если ограничиться лишь стоимостью серверов и памяти, а так же лицензиями на софт, разница в цене виртуальной инфраструктуры на базе разных гипервизоров может оказаться попросту незаметной. И в итоге выбор вендора инфраструктуры основывается на уровне подготовки системных адимнистраторов и их знакомства с соотв. технологиями, либо необходимой функциональностью.

Впрочем, все это лирика :)

Вышел vCenter 2.5u4

Вышел vCenter 2.5u4.

Почему стоит ставить этот апдейт?

• Добавлена кастомизация Windows 2008
• Добавлена новыа вкладка "Performance" с расширенными настройками
• В 2.5u4 обещали наконец-то исправить проблему с постоянно выгружающимся плагином Update Manager.
  

ESX vs Hyper-V: снапшоты

Eric Gray в блоге vcritical.com часто затрагивает тему сравнения ESX и Hyper-V. На этот раз досталось снапшотам.

Чем же так отличается поведение ВМ со снапшотами при работе с разными гипервизорами?

ESX

Снапшоты можно удалять и накатывать "вживую", на работающей ВМ. И соотв. с нулевым временем простоя.

Hyper-V

Удаленные снапшоты накатываются только при выключении машины, что удваивает количество перезагрузок для обслуживания гостевых ОС (в среднем половина ВМ пезагружается по патч-вторникам).

ESX vs Hyper-V

Каждый администратор VMware знает, что виртуальная машина по сути лишь набор файлов, с котрым можно очень просто работать. Казалось бы, у других вендоров все то же самое, но не все так просто.

Предположим, у вас есть среда разработки, и там отсутствует HA, что в целом логично. И вот вдруг "вылетает" один из хостов. Вы восстанавливаете хост, переустанавливаете ESX(i) или просто хотите перенести машину на другой хост. Что для этого требуется? Да всего пара кликов мышкой. Открываете Datastore Browser, находите соответствующий .vmx файл, клик правой кнопкой и выбираете Add to Inventory.



Также одной простой командой это можно сделать из консоли ESX (но не ESXi):

vmware-cmd -s register $PWD/whatever.vmx

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

Восстановление виртуальных машин Hyper-V представляет собой более сложную задачу. Пока машину не "экспортировать" вручную, ее невозможно "импортировать". Не существует пути восстановления ВМ с умершего хоста, особенно если у нее есть снапшоты.



Хотя нет, существует один неподдерживаемый путь Шалтая-Болтая собрать, для задач восстановления данных. Если создавать вручную символические ссылки на xml файлы для вас нормально, то попробуйте.

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

Оригинал статьи.

Проблемы с HP ESXi Embedded

В HP признали, что возможны проблемы при обновлении конфигурационных файлов ESXi Embedded на серверах HP ProLiant. ESXi Embedded поставлялись на двух типах USB Flash дисков - затронуты только флэшки в зеленом алюминиевом корпусе.

Затронуты следующие модели серверов:

* ProLiant ML350 G5 Server
* ProLiant ML370 G5 Server
* ProLiant DL360 G5 Server
* ProLiant DL380 G5 Server
* ProLiant DL385 G2 Server
* ProLiant DL580 G5 Server
* ProLiant DL585 G2 Server
* ProLiant BL460c G5 Server Blade
* ProLiant BL465c Server Blade
* ProLiant BL465c G5 Server Blade
* ProLiant BL480c G5 Server Blade
* ProLiant BL680c G5 Server Blade
* ProLiant BL685c Server Blade

Решение проблемы:

Клиенты HP могут заказать замену USB Flash дисков по гарантии через HP Customer Support, запросив "Spares Kit 490749-001". HP также предоставит инструкции как получить образ диска восстановления ESXi.

Официальный документ от HP.

Новость! Срочно в номер!

Михаил Козлов, глава российского представительства VMware, неиллюзорно порадовал новостью: сайт cybersecurity.ru неожиданно обнаружил, что

VMware сегодня представила VMware Workstation 5
(14:38) 15.02.2009
Компания VMware сегодня представила VMware Workstation 5, новую версию настольного программного обеспечения для виртуализации. В официальном сообщении компании по данному поводу отмечается, что VMware Workstation 5 предоставляет разработчикам и администраторам новые возможности по работе с виртуализованными системами, а саму виртуализацию "поднимает на новый уровень"

Не прошло и 4х лет. Workstation 5.0 была представлена 7 апреля 2005 года.
Текущая версия VMware Workstation – 6.5.1

Первопричина проблем

Существует очень распространенная причина проблем. Она звучит как "нехватка места на диске".

Только что на форуме VMware случилось обсуждение очередной ее инкарнации: процесс апдейта падал с сообщением "failed to download". Не хватало места на диске под пакет.

Бывает, падает прокси, интернет кончается для всей конторы. А разгадка одна - кончилось свободное место на в разделе с лог-файлами. Можно два часа искать проблему с внешними каналами и ругаться с саппортом провайдера, а толку будет ноль.

Всегда, в первую очередь проверяйте при возникновении проблем, а осталось ли свободное место?

Целостность данных ВМ

Для тех, кто беспокоится за целостность данных, записываемых на виртуальный диск виртуальной машиной.

"Storage IO crash consistency with VMware products" (http://kb.vmware.com/kb/1008542)

VMware ESX acknowledges a write or read to a guest operating system only after that write or read is acknowledged by the hardware controller to ESX. Applications running inside virtual machines on ESX are afforded the same crash consistency guarantees as applications running on physical machines or physical disk controllers.

VMware ESX подтверждает гостевой ОС чтение или запись только после того, как чтение и запись подтверждено аппаратным контроллером ESX серверу. Поэтому запущенные в виртуальной машине приложения имеют тот же уровень защиты целостности данных при сбоях, что и приложения, запущенные на физических машинах или использующие физические контроллеры дисков

Грабли с виртуальными CD

1) Возможные грабли при работе с ВМ, у которой в качестве CD указан "client device"

В таком случае у нас появляется дополнительная кнопочка на панели.



Подключив один раз CD к .iso файлу или приводу, не забывайте его отключить. При закрытии окна консоли машины подключение останется активным до тех пор, пока не будет закрыт VI клиент. Со всеми вытекающими следствиями. А самое главное из них - невозможность VMotion. Особенно это актуально для тех, у кого администрированием VI занимаются несколько человек.

2) Вторые возможные грабли - подключение CD не на client device, а к файлу на одном из хранилищ (datastore). В отличие от client device, при закрытии клиента или выключении машины подключение никуда не денется. Если ВМ, не закрыв подключение, превратить в шаблон, то все развернутые из шаблона машины будут подключены все к тому же файлу.

VI4 Client Federation

Одна из интересных фишек клиента к "четверке" - федеративный клиент.

А конкретнее - для тех, у кого несколько vCenter'ов, ко всем ним можно будет одновременно подключиться из одного клиента.

Русскоязычный раздел сообщества VMware

"Кричали женщины ура и в воздух лифчики бросали!"

Ура, свершилось. Открылся таки официально русскоязычный раздел сообщества VMware.

http://communities.vmware.com/community/vmug/emea/russia

View client open-source

VMware выпустила версию клиента View с открытым исходным кодом. Коммерческая поддержка данного клиента не планируется.

Доступная функциональность:

• Безопасное подключение по SSL
• Поддержка двухфакторной авторизации RSA SecurID
• Novell SLETC Add-On RPM package
• Полная подержка командной строки

НЕдоступная функциональность:

• Перенаправление USB устройств
• Множественные сессии
• Перенаправление мультимедиа

Citrix XenApp любит ESX

Citrix XenApp (бывший Presentation Server) чрезвычайно популярная и технологически продвинутая платформа терминального доступа. Однако, при всем этом, в условиях современных многоядерных серверов XenApp демонстрирует не самую лучшую масштабируемость. В итоге тем более интересна работа XenApp в виртуальных машинах.

Было проведено тестирование XenApp под управлением Citrix XenServer и VMware ESX.

Конфигурация ВМ с XenApp: 14 GB 2-vCPU, Windows Server 2003 x64.
Гипервизоры: ESX 3.5 U3, XenServer 5.
В свойствах XenServer ВМ включена оптимизация для XenApp. Тесты в нативном режиме проводились при ограничении аппаратных ресурсов до уровня тестовых ВМ.
Аппартная часть: HP DL585, 4*4 2210 MHz Opteron (Barcelona), 64 GB. Rapid Virtualization Indexing (RVI) включено.




Горизонтальные линии с пометкой QoS показывают нативную задержку для 35 и 38 пользователей, при этом они соответствуют примерно 50% загрузке процессоров, что явяется общей практикой для XenApp. При большей загрузке задержки не только быстро растут, но и операции начинают завершаться неуспешно.



ESX дает уровень в 86% нативного, в то время как XenServer лишь 77%.

Загрузка процессоров измералась perfmon в нативном режиме, esxtop для ESX, xentop для XenServer.


XenApp под ESX поддерживает на 13% больше пользователей, чем под XenServer при сравнимой задержке отклика, потребляя при этом меньше процессорной мощности.

Источник.

Cisco Nexus 1000V

Brad Hedlund из Cisco Systems в своем блоге опубликовал некоторые подробности о новом продукте, замене стандартного vSwitch на ESX 4.0. Nexus 1000V пока из беты не вышел, но было бы странно его зарелизить раньше, чем VI4. Скорее всего это будет сделано одновременно.

А пока схема работы Nexus 1000V

• The Nexus 1000V software on the physical server acts like a line card of a modular switch, described as a VEM (virtual ethernet module)


• The Nexus 1000V VEM is a direct replacement of the VMWare vSwitch function


• The Nexus 1000V VSM (virtual supervisor module) acts like the supervisor engine of a modular switch


• One Nexus 1000V VSM instance manages a single ESX cluster of up to 64 physical servers


• The form factor of Nexus 1000V VSM can be a physical appliance or a virtual machine


• The network administrator manages the Cisco Nexus 1000V (from the VSM) as a single distributed virtual switch for the entire ESX cluster


• Each virtual machine connects to its own Virtual Ethernet (vEthernet) port on the Nexus 1000V providing the network administrator traffic visibility and policy control on a per virtual machine basis. Virtual machines can now be managed like physical servers in terms of their network connectivity.


• The network administrator defines Port Profiles which are a collection of network configuration settings such as the VLAN, any access lists, QoS policies, or traffic monitoring such as NetFlow or SPAN.

Производительность ESX под терминальной и VDI нагрузкой

Virtual Reality Check провели сравнение поведения Hyper-V, ESX, XenServer и железа под терминальной/VDI нагрузкой.

Желающие подробностей могут скачать 4 подробных документа по 5М здесь.

Я же освещу в русском варианте основные технические моменты, касающиеся VMware ESX.

Тесты проводились на серверах HP DL385 (2*Opteron 2356 (4 core), 32GB RAM, 8*146GB SAS 10k rpm RAID5).

VDI

На сервере с 32GB памяти и отключенной memory overcommitment (далее MO) удается запустить лишь 27 машин с Windows XP (1GB). При включении transparent page sharing (далее TPS) уже 70. Несмотря на то, что данные выбирались случайным образом для тестов, реальные показатели будут пониже, поскольку реальные пользователи VDI имеют тенденцию пользоваться разным софтом, причем более интенсивно нагружающим память, чем в тесте.

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

В данном пункте лично у меня возник вопрос почему ничего не говорилось про MO без TPS, посредством balloon-драйвера.

Terminal

Тестирование показало, что наиболее эффективный и экономичный вариант виртуализации терминальных серверов на ESX - использование 32битной Windows 2003 с двумя процессорами и 4GB памяти на 8-ядерных серверах с 20GB памяти (4*4GB + оверхед ESX) при выключенной TPS.

Оверкоммитинг процессоров (число vCPU > числа физ. ядер) рекомендуется только для виртуализации слабо загруженных серверов, поскольку при высокой загрузке может привести к падению производительности.

Отключение TPS снижает нагрузку на процессор и приводит к увеличению количества сессий на 5-10% при сохранении приемлемого времени отклика.

Не стало сенсацией и превосходство терминальных серверов над VDI по количеству сессий (108 против 69)