Среди анонсов VMworld 2013, о которых мы писали вот тут, помимо обновленной платформы виртуализации VMware vSphere 5.5, было также объявлено о выпуске средства единой аутентификации в виртуальной инфраструктуре - VMware vCenter Single Sign-On 5.5 (SSO).

На самом деле это всего лишь версия 2.0 компонента SSO, но она уже была полностью переписана по сравнению с первой версией, у которой наблюдались серьезные проблемы, а именно:

• Ограниченная интеграция с Active Directory
• Сложность управления инфраструктурой SSL-сертификатов
• Отсутствие четких инструкций и рекомендаций по развертыванию продукта
• Сложность развертывания решения, особенно для администраторов небольшой инфраструктуры

Надо отметить, что SSO версии 1.0 компания VMware оеэмила у сторонних разработчиков, но ввиду его неудобства решила написать его для себя с нуля.

Теперь Single Sign-On 5.5 лишен перечисленных проблем, архитектурно он стал проще - нет нужды в сторонней базе данных, все построено на базе внутренней модели хранения LDAP. Мастер установки стал очень простым и позволяет без труда развернуть SSO не несколько узлов vCenter 5.5:

Теперь архитектура построена на модели multi-master, что предполагает наличие идентичной конфигурации на каждом узле, между которыми происходит встроенная в решение репликация. Теперь можно создавать логические группировки зарегистрированных ресурсов, например, по географическому признаку.

Обновилась и утилита vCenter Certificate Automation tool, которая теперь позволяет простым образом обновлять сертификаты компонентов средств управления виртуальной инфраструктурой vCenter Server 5.5.

Помимо прочего, теперь нет и заморочек с master password, которые вводили в недоумение многих пользователей.

VMware рекомендует устанавливать SSO вместе с сервером vCenter, а один экземпляр SSO может работать в инфраструктуре до 1000 хостов ESXi и 10 000 виртуальных машин.

Из остальных функций Single Sign-On 5.5 можно отметить следующие:

• Поддержка односторонних и двусторонних AD-трастов
• Поддержка нескольких лесов
• Можно использовать локальную аутентификацию без домена, если это необходимо
• Появилось множество средств для траблшутинга и диагностики решения

VMware vCenter Single Sign-On 5.5 можно будет скачать в составе инфраструктуры VMware vSphere.

Некоторое время назад мы писали про технологию Virtual SAN (VSAN) компании VMware, которая позволяет объединить локальные дисковые ресурсы хост-серверов VMware ESXi в единый пул хранения для виртуальных машин, управляемый на базе политик. Этот продукт сейчас находится в стадии публичного бета-тестирования, и основан он на разработках купленной компании Virsto.

Однако многие из вас знают, что у VMware есть также продукт vSphere Storage Appliance (VSA), о котором мы также немало рассказывали на страницах VM Guru (например, тут, тут и тут). И этот продукт также предназначен для построения распределенных хранилищ на базе локальных дисков хостов, но уже для небольшой инфраструктуры.

Давайте посмотрим, чем же отличаются эти два продукта - VMware VSA и VMware VSAN:

Из таблички видно, что продукт vSphere Storage Appliance подходит для небольших компаний и начинающих в сфере виртуализации, а вот технология VSAN подойдет уже серьезным организациям с большой продакшен-инфраструктурой.

На самом деле, так как продукты делали разные компании (VSA - VMware, а VSAN - Virsto), то они имеют разные функции и не являются вариациями одного и того же решения, хотя многие понимают VSAN как развитие идеи VSA.

Некоторое время назад мы уже выкладывали интерактивные демо продуктов VMware, но с тех пор уже много воды утекло, и демки устарели. На прошедшей конференции VMworld 2013 компания VMware анонсировала новые версии своих продуктов, например, VMware vSphere 5.5 и vCloud Director 5.5, а к ним она приложила интерактивные демо, воспользоваться которыми в целях обучения может любой желающий.

Вот какие функции продуктов VMware можно посмотреть онлайн, не устанавливая их на свои серверы:

• vSphere Data Protection 5.5 (VDP) – резервное копирование виртуальных машин.
• vSphere 5.5 AppHA (AppHA) - мониторинг доступности приложений в виртуальных машинах (новая функция vSphere 5.5).
• vCloud Director 5.5 (VCD) - новая версия решения для управления облачной инфраструктурой.
• vSphere 5.5 Replication (VR) - техника репликации виртуальных машин.
• vSphere 5.5 vFlash Read Cache (VFRC) - новая возможность использования кэша на флэш-дисках, о которой мы писали вот тут.
• VMware Virtual SAN (vSAN) - возможности распределенного хранения виртуальных машин на локальных дисках серверов, о которых мы писали вот тут.

Традиционно, демо продуктов VMware - это графическая консоль с инструкциями куда нажимать и зачем. Очень удобно:

Как вы уже знаете, не так давно была выпущена обновленная версия платформы виртуализации VMware vSphere 5.5, которая получила немало новых возможностей. Вместе с тем была также выпущена бесплатная версия VMware vSphere Hypervisor 5.5 (free ESXi 5.5).

Самым главным улучшением VMware ESXi 5.5, бесспорно, стало отсутствие ограничений на физическую память хост-сервера. Если раньше мы могли использовать бесплатный ESXi только на серверах, где установлено до 32 ГБ RAM:

то теперь VMware ESXi 5.5 не имеет абсолютно никаких ограничений сверху по памяти физического сервера.

Это хорошая новость, но есть и немного плохая. Если ограничения сверху теперь отсутствуют, то ограничения снизу всегда будут - это системные требования. В версии ESXi 5.0 для запуска хоста требовалось минимум 2 ГБ оперативной памяти (если вы ставили его в кластер, то уже требовалось 3 ГБ, так как с двумя гигами хост вылетал в PSOD). В версии же ESXi 5.5 теперь официально требуют 4 ГБ RAM. Это значение важно, конечно же, не для физических хостов ESXi 5.5, а для виртуальных - которые используются для тестирования возможностей инфраструктуры виртуализации.

Отметим, что ограничение на 8 vCPU на одну виртуальную машину в бесплатном ESXi 5.5 осталось.

Ну а с точки зрения самого бесплатного гипервизора VMware ESXi 5.5 появились следующие новые возможности:

• Обновленная версия виртуального аппаратного обеспечения - Virtual Machine Hardware Version 10.
• Поддержка новых архитектур CPU.
• Совместимость ВМ в VMware ESXi 5.5 - теперь обеспечивается обратная совместимость ВМ с поддержкой различных возможностей, таких как LSI SAS для Oracle Solaris 11 OS и advanced host controller interface (AHCI).
• Максимальный объем RAM на хост - 4 ТБ (было 2 ТБ).
• Максимальное число vCPU на хост - 4096 (было 2048).
• NUMA-узлов на хост - 16 (было 8).
• Логических CPU на хост - 320 (было 160).
• Поддержка дисков VMDK до 62 ТБ.
• Поддержка адаптеров 16 GB Fibre Channel.
• Поддержка сетевых адаптеров до 40 GBps.
• До 64 ТБ хранилищ на один хост ESXi.
• Один SATA-контроллер поддерживает виртуальный диск и CD-ROM на одном контроллере.
• Поддержка до 30 устройств на контроллер, всего 4 контроллера - итого 120 устройств.

Ограничение на non-writable API все еще осталось, поэтому непонятно, как работают такие решения, как бесплатный Unitrends Enterprise Backup (UEB) - заявлено, что он может бэкапить виртуальные машины бесплатного ESXi.

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

Приведем здесь список того, что было анонсировано и где можно почерпнуть дополнительной информации:

• Обновилась платформа виртуализации - VMware vSphere 5.5. О новых возможностях vSphere 5.5 мы написали тут. Обратим внимание, что цены и издания продукта не изменились.
• Изменилась комплектация и стоимость некоторых продуктов VMware. Об этом мы писали вот тут.
• Обновился пакет VMware vCloud Suite 5.5, включающий в себя основные решения для организации частного облака на основе VMware vSphere 5.5. Мы писали об этом тут. А о новых особенностях версии 5.5 можно прочитать тут. В ближайшее время мы расскажем об этом подробнее.
• Вышла окончательная версия публичного облака от VMware - VMware vCloud Hybrid Service (vCHS) 1.0. О его особенностях мы уже писали тут и тут. Объявили также о выпуске vCloud Hybrid Service Marketplace (сам он находится тут). Скоро мы также напишем отдельную заметку об этом.
• Обновилось решение для автоматизации частного облака vCloud Director 5.5, подробнее об этом можно почитать тут. Скоро и здесь об этом будет.
• Обновились службы единого входа Single Sign On 2.0. Подробности приведены здесь.
• Был существенно улучшен механизм vSphere Replication 5.5. Некоторые детали приведены у нас тут. На английском можно почитать здесь.
• Обновилось решение для создания катастрофоустойчивой инфраструктуры VMware Site Recovery Manager 5.5. Скоро мы об этом здесь также напишем. Пока почитайте о нем вот тут.
• Обновилось решение vSphere Data Protection Advanced, которое входит в состав VMware vSphere для изданий, начиная с vSphere Essentials Plus (напомним, что выпущено оно было еще в начале года). Почитать можно тут.
• Была анонсирована доступность средства vCloud Planner 1.0 (он же бывший VMware Infrastructure Planner / VIP), предназначенного для финансовой оценки планируемой виртуальной инфраструктуры на базе дополнительных решений в рамках концепции Software Defined Datacenter на основе VMware vCloud Suite (то есть, что улучшится с точки зрения владения инфраструктурой, если закупить и развернуть последний). В качестве отправной точки для расчетов используется уже существующая инфраструктура на основе VMware vSphere. Подробнее об этом средстве можно узнать тут.
• Было анонсировано средство, предназначенное для виртуализации сетей в рамках концепции Software-defined networking (SDN) - VMware NSX, о котором мы писали вот тут. Немного дополнительной информации находится здесь. Скоро мы также опишем его несколько подробнее.
• Появилась новая линейка сертификации VMware Certified Associate. Для получения этой сертификации не требуется прохождения курсов (ура!), но требуется сдать экзамен. Вот, например, страничка сертификации "VMware Certified Associate - Data Center Virtualization (VCA-DCV)".
• Была анонсирована публичная бета-версия Virtual SAN (VSAN) 1.0. Об этой технологии мы уже писали вот тут. Скоро также расскажем подробнее.
• Была анонсирована новая версия vCenter Orchestrator 5.5. Подробнее об этом можно узнать тут.
• Анонсировали обновленную версию решения для комплексного мониторинга и защиты сетей
  vCloud Networking and Security 5.5 в составе vCloud Suite 5.5. Подробнее об этом тут.
• Выпустили новую минорную версию решения для высокой доступности сервисов vCenter - vCenter Server Heartbeat 6.6.
• Ну и (если кто не заметил) обновился сайт VMware. Теперь все так модно делать - в стиле Ленты.ру.

Скоро о многом из этого мы расскажем достаточно подробно. Заходите чаще!

Не так давно мы уже писали о планируемых новых возможностях VMware vSphere 5.5, однако большинство новых функций были описаны в общих чертах, кроме того, до последнего момента так и не было окончательно известно, что же еще нового появится в vSphere 5.5. На проходящей сейчас конференции VMworld 2013 компания VMware наконец-то объявила о выходе обновленной платформы VMware vSphere 5.5, которая стала еще более мощным средством для построения виртуальных инфраструктур.

Был тут случай недавно - пишет мне товарищ, дескать, что это мы пост разместили с инфой, которая под NDA. А откуда мы должны знать, что находится под NDA, а что не под NDA? И вообще с какой стати все эти заморочки с NDA? Я вообще на тему продуктов чьих-то NDA никогда не подписывал и подписывать не собираюсь. А если появляется утечка с новыми возможностями продукта или компании - это никакой нахрен не слив инфы под NDA, а самая обычная и уже набившая оскомину реклама - радуйтесь.

Или вот приходит нам рассылка про новую версию vCloud Director, а внизу написано:

***** Confidential Information ***** 
Do not forward information about this program or release to anyone outside of those directly involved with beta testing. This information is highly confidential.

Information contained in this email, including version numbers, is not a commitment by VMware to provide or enhance any of the features below in any generally available product.

Или вот NVIDIA пишет:

Обращаю ваше внимание, что информация брифинга находится под NDA до 17:00 по Москве вторника, 23-го июля.

И чо? А если я им в письме напишу, что им нельзя мыться 3 месяца - они будут этот наказ соблюдать?

Так что, уважаемые вендоры, надеюсь, вам понятна позиция VM Guru с вашими NDA. Если мы их не подписывали - не пишите нам ничего на эту тему, так как эти письма отправляются прямиком в трэш по ключевому слову "NDA".

Вон у Apple тоже, конечно, утечки бывают, но в целом-то - хрен узнаешь, когда этот новый айфон выйдет. Поэтому в этом посте мы с удовольствием расскажем о новых возможностях VMware vSphere 5.5 на основе информации, взятой из сети интернет (также об этом есть на блоге Андрея и Виктора - http://vmind.ru/2013/08/15/chego-zhdat-ot-vmware-vsphere-5-5/). Естественно, не все из этих фичей могут оказаться в релизной версии, и это, само собой, не полный их список.

New OS Support

Наряду с поддержкой Windows 8.1 (ожидается в VMware View 5.5) будут поддерживаться последние релизы гостевых ОС Linux: Ubuntu, Fedora, CentOS, OpenSUSE и другие дистрибутивы.

VMware Hardware Version 10

Теперь появится новое поколение виртуального аппаратного обеспечения версии 10. Это добавит новых возможностей виртуальным машинам с точки зрения динамических сервисов виртуализации. Для редакции vSphere Enterprise Plus будет поддерживаться до 128 vCPU.

Administrative UI (Web Client)

Новая версия веб-клиента vSphere Web Client теперь является единственным средством управления инфраструктурой виртуализации.

• Улучшенный интерфейс, большое количество фильтров и вкладка "recent objects", позволяющая получить быстрый доступ к объектам.
• Улучшения по времени отклика интерфейса и возможность управлять большим числом объектов.

vSphere Replication - теперь доступны следующие возможности по репликации виртуальных машин:

• Возможность репликации виртуальных машин между кластерами для машин не с общими хранилищами (non-shared storage).
• Поддержка нескольких точек для восстановления целевой реплицируемой машины. Это защищает сервисы от логических повреждений данных, изменения в которых реплицируются на резервную площадку.
• Storage DRS Interoperability - возможность реплицируемых машин балансироваться по хранилищам средствами технологии Storage vMotion без прерывания репликации.
• Simplified Management - улучшенная интеграция с vSphere Web Client, что позволяет мониторить процесс репликации в различных представлениях vCenter.
• Поддержка технологии VSAN (см. ниже) - теперь машины на таких хранилищах поддерживаются средствами репликации.
• vCenter Orchestrator - теперь это средство автоматизации существенно оптимизировано в плане масштабируемости и высокой доступности. Разработчики теперь могут использовать упрощенные функции диагностики в vCenter Orchestrator client.

Virtual SAN

О возможностях VMware Distributed Storage и vSAN мы уже писали вот в этой статье. Virtual SAN - это полностью программное решение, встроенное в серверы VMware ESXi, позволяющее агрегировать хранилища хост-серверов (SSD и HDD) в единый пул ресурсов хранения для всех хостов, что позволяет организовать ярусность хранения с необходимыми политиками для хранилищ.

Поддержка томов vVOL

Также мы писали о поддержке виртуальных томов vVOL - низкоуровневых хранилищ для каждой из виртуальных машин, с которыми будут позволены операции на уровне массива, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Проще говоря, VMDK-диск машины можно будет хранить как отдельную сущность уровня хранилищ в виде vVOL, и с ней можно будет работать отдельно, без влияния на другие ВМ этого массива.

VMware Virtual Flash (vFlash)

О возможностях VMware Virtual Flash (vFlash) мы уже писали вот в этой статье. vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.

Virtual Machine File System (VMFS)

Теперь VMware vSphere 5.5 поддерживает vmdk-диски объемом более 2 TБ. Теперь объем виртуального диска машины может быть размером до 64 ТБ. Несколько больших файлов теперь могут храниться в одном vmdk. Это поддерживается только для VMFS 5.

vCloud Director

Теперь продукт доступен как виртуальный модуль (Virtual Appliance) - можно использовать как встроенную так и внешнюю БД. Этот модуль по-прежнему не будет рекомендован для продакшен-среды. Рекомендуют использовать его для апробации решения.

Был существенно улучшен Content Catalog:

• Улучшена производительность и стабильность синхронизации
• Расширяемый протокол синхронизации
• Возможность самостоятельной загрузки элементов каталога (OVF)

Кроме того, для интерфейса управления теперь поддерживается больше браузеров и ОС (в том числе поддержка Mac OS).

vCloud Networking & Security

В составе vSphere 5.5 этот продукт будет иметь следующие улучшения:

• Улучшенная поддержка Link Aggregation Control Protocol (LACP) - теперь поддерживается 22 алгоритма балансировки и до 32 физических соединений в агрегированном канале.
• Улучшения производительности и надежности агрегированного канала.

Кроме того, вместо vCloud Networking and Security с октября выходит новый продукт VMware NSX.

Security Features

Теперь появится распределенный сетевой экран (Distributed Firewall), являющийся одним из ключевых компонентов концепции Software Defined Datacenter. Он работает на уровне гипервизора каждого из хостов VMware ESXi, а на уровне централизованной консоли доступен мониторинг проходящих пакетов от абсолютно каждой виртуальной машины.

Политики этого сетевого экрана определяются на уровне VXLAN, поэтому нет нужды оперировать с ним на уровне IP-адресов. Ну и так как поддержка этого распределенного фаервола реализована на уровне гипервизора - то политики перемещаются вместе с виртуальной машиной, если она меняет хост средствами vMotion.

Более подробно об этом можно прочитать тут.

vCenter Site Recovery Manager

Теперь vCenter SRM будет поддерживать технологию vSAN вместе с vSphere Replication, работать с технологиями Storage DRS и Storage vMotion. Кроме того, добавлена поддержка нескольких точек восстановления реплик (Multi-Point-In-Time snapshots) при исполнении плана аварийного восстановления.

VMware vCenter Multi-Hypervisor Manager (MHM) 1.1

Об этом продукте мы уже писали вот тут. Теперь он будет поддерживать гипервизор Microsoft Hyper-V 3.0 в Windows Server 2012 R2 (а также более ранние его версии). Также появилась возможность холодной миграции ВМ с хостов Hyper-V на VMware vSphere.

Single Sign-On 2.0 (SSO)

В новой версии единого средства аутентификации продуктов VMware теперь появится улучшенная и новая поддержка следующих компонентов:

• vSphere
• vCenter Orchestrator
• vSphere Replication
• vSphere AppHA (новый продукт, который будет анонсирован на VMworld)
• vCloud Director
• vCloud Networking and Security (vCNS)

Технология VMware vDGA для VMware Horizon View 5.5

О технологии NVIDIA VGX мы уже писали вот тут, тут и тут. Согласно этой презентации, уже скоро мы увидим возможности шаринга и выделение GPU отдельным виртуальным машинам:

Ну что знал - рассказал. В целом, ничего революционного. Поддержку Fault Tolerance для 4-х vCPU обещают в VMware vSphere 6.0.

Виктору спасибо за ссылки. Вот еще немного о предстоящем выходе обновленной платформы - http://vmind.ru/2013/08/13/vmware-vsphere-5-5/.

Как знают администраторы виртуальных сред и некоторые разработчики, на многих платформах виртуализации существует возможность запуска виртуальных машин в виртуальных машинах с установленным в них гипервизором - так называемая "вложенная виртуализация" (Nested Virtualization). Например, такие возможности есть в VMware vSphere (что позволяет запускать не только свой вложенный гипервизор ESXi, но машины на вложенном гипервизоре Hyper-V).

Компания Ravello нашла интересный способ использовать вложенную виртуализацию в своем продукте Cloud Application Hypervisor, который позволяет универсализовать развертывание ВМ разных платформ виртуализации в публичных облаках различных сервис провайдеров.

Основным компонентом этой системы является технология HVX - собственный гипервизор (на базе Xen), являющийся частью ОС Linux и запускающий вложенные виртуальные машины без их изменения средствами техник бинарной трансляции. Далее эти машины можно разместить в облаках Amazon EC2, HP Cloud, Rackspace и даже частных облаках, управляемых VMware vCloud Director (поддержка последнего ожидается в скором времени).

Продукт Ravello - это SaaS-сервис, а такие матрешки можно просто загружать на любой из поддерживаемых хостингов, вне зависимости от используемого им гипервизора. Виртуальная сеть между машинами создается через L2-оверлей над существующей L3-инфраструктурой хостера с использованием GRE-подобного протокола (только на базе UDP):

Сама механика предлагаемого сервиса Cloud Application Hypervisor такова:

• Пользователь загружает виртуальные машины в облако (поддерживаются машины, созданные на платформах ESXi/KVM/Xen).
• С помощью специального GUI или средствами API описывает многомашинные приложения.
• Публикует свои ВМ в одном или нескольких поддерживаемых облаках.
• Получившаяся конфигурация сохраняется в виде снапшота в облаке Ravello (потом в случае чего ее можно восстановить или выгрузить) - это хранилище может быть создано как на базе облачных хранилищ Amazon S3, CloudFiles, так и на базе собственных блочных хранилищ или NFS-томов.
• После этого каждый пользователь может получить многомашинную конфигурацию своего приложения по требованию.

Очевидный вопрос, который возникает первым: что с производительностью? Ну, во-первых, решение Cloud Application Hypervisor рассчитано на команды разработки и тестирования, для которых производительность не является критичным фактором.

А во-вторых, результаты тестов производительности таких вложенных матрешек показывают не такие уж и плохие результаты:

Для тех, кто заинтересовался технологией HVX, есть хорошее обзорное видео на рунглише:

Больше подробностей о продукте Cloud Application Hypervisor и технологии HVX можно узнать из этого документа.

Большинству администраторов VMware vSphere известно, что у виртуальной машины могут быть виртуальные сетевые адаптеры различных типов, которые выбираются как в зависимости от гостевой ОС, так и от настроек пользователя, которые можно прописать в vmx-файле конфигурации ВМ.

На эту тему компания VMware выпустила вот такое видео:

Опишем типы сетевых адаптеров (vNIC) для виртуальной машины (ранее мы писали о них тут):

• Vlance - этот адаптер эмулирует реально существующий старый адаптер AMD 79C970 PCnet32- LANCE NIC, он работает на скорости 10 Mbps, и для него есть драйверы в большинстве 32-битных ОС, за исключением Windows Vista и более поздних версий. Виртуальная машина с таким адаптером может сразу использовать сеть.
• VMXNET - такой адаптер уже не имеет физического воплощения, то есть он полностью виртуальный. Он оптимизирован с точки зрения производительности ВМ. Поскольку он виртуальный - ОС не может его использовать, пока не установлены драйверы, идущие в комплекте с VMware Tools.
  
• Flexible - это по-сути не адаптер, а способ его представления. Он ведет себя как Vlance при загрузке ВМ, но потом превращается (или нет - в зависимости от VMware Tools) в VMXNET.
• E1000 - это эмулируемая сетевая карта Intel 82545EM Gigabit Ethernet NIC. Драйвер для этого адаптера есть не во всех гостевых операционных системах. Обычно Linux с версиями ядра 2.4.19 или более поздними, Windows XP Professional x64 Edition и позднее, а также Windows Server 2003 (32-bit) и позднее включают в себя драйвер для этого устройства. Производительность его достаточно неплоха. Драйвер адаптера E1000 не поддерживает большие кадры jumbo frames до версии VMware ESXi/ESX 4.1.
• E1000e - этот адаптер эмулирует более продвинутую модель Intel Gigabit NIC (number 82574) в виртуальном аппаратном обеспечении (virtual hardware) виртуальной машины. Адаптер e1000e доступен только для virtual hardware версии 8 (и старше), начиная с VMware vSphere 5. Это дефолтный адаптер для Windows 8 и более новых гостевых ОС. Для гостевых ОС Linux e1000e не доступен для выбора из интерфейса (e1000, flexible, vmxnet, enhanced vmxnet и vmxnet3 - доступны для Linux).
• VMXNET 2 (Enhanced) - адаптер VMXNET 2 основан на устройстве VMXNET, но предоставляет несколько функций с улучшенной производительностью, таких как jumbo frames и hardware offloads (например, TCP Segmentation Offloading, TSO). Этот адаптер доступен только для хостов VMware ESX/ESXi 3.5 или выше. Устройство VMXNET 2 поддерживается только для следующих гостевых операционных систем:
  • 32- и 64-битные версии Microsoft Windows 2003 (Enterprise и Datacenter Edition). Можно использовать адаптер VMXNET 2 и на Microsoft Windows 2003, однако нужно прочитать статью в KB 1007195 (http://kb.vmware.com/kb/1007195  ).
  • 32-битная версия Microsoft Windows XP Professional
  • 32- и 64-битные версии Red Hat Enterprise Linux 5.0
  • 32- и 64-битные версии SUSE Linux Enterprise Server 10
  • 64-битные версии Red Hat Enterprise Linux 4.0
  • 64-битные версии Ubuntu Linux
  
  Кроме того, если такой адаптер недоступен для выбора в Windows 2003, то нужно почитать статью Enabling enhanced vmxnet adapters for Microsoft Windows Server 2003 (1007195).
  
  В ESX 3.5 Update 4 или более поздних версиях платформы следующие гостевые ОС также поддерживаются для этого адаптера:
  
  
  • Microsoft Windows Server 2003, Standard Edition (32-bit)
  • Microsoft Windows Server 2003, Standard Edition (64-bit)
  • Microsoft Windows Server 2003, Web Edition
  • Microsoft Windows Small Business Server 2003
  
  Jumbo frames также не поддерживаются для гостевых ОС Solaris с адаптером VMXNET 2.
  
  
• VMXNET 3 - это следующее поколение виртуальных сетевых карт, которое теперь паравиртуализовано. То есть часть того, что раньше полностью эмулиировалось, теперь передается напрямую в физическое устройство. Этот адаптер не является надстройкой над VMXNET или VMXNET 2, но включает в себя все доступные для них возможности. Например, к ним относятся: поддержка механизмов нескольких очередей (multiqueue - также известны как Receive Side Scaling в Windows), IPv6 offloads, а также прерывания MSI/MSI-X (подробнее - тут).
  VMXNET 3 поддерживается только для виртуальных машин с виртуальным аппаратным обеспечением уровня 7 или более поздним, при этом только для следующих гостевых систем:
  • 32- и 64-битные версии Microsoft Windows XP и более поздние (включая Windows 7, 2003, 2003 R2, 2008, 2008 R2 и Server 2012)
  • 32- и 64-битные версии Red Hat Enterprise Linux 5.0 и более поздние
  • 32- и 64-битные версии SUSE Linux Enterprise Server 10 и более поздние
  • 32- и 64-битные версии Asianux 3 и более поздние
  • 32- и 64-битные версии Debian 4/Ubuntu и более поздние
  • 32- и 64-битные версии Sun Solaris 10 U4 и более поздние
  
  Заметки:
  
  • В ESXi/ESX 4.1 и более ранних версиях jumbo frames не поддерживаются для гостевых ОС Solaris для адаптеров VMXNET 2 и VMXNET 3. Эта возможность поддерживается, начиная с ESXi 5.0 только для адаптеров VMXNET 3. Более подробно можно почитать в статье Enabling Jumbo Frames on the Solaris guest operating system (2012445).
    
  • Технология Fault Tolerance не поддерживается для ВМ с адаптером VMXNET 3 в vSphere 4.0, но поддерживается в vSphere 4.1 и более поздних версиях.
  • Windows Server 2012 поддерживается для адаптеров e1000, e1000e и VMXNET 3 на платформе ESXi 5.0 Update 1 и более поздни

О производительности устройства VMXNET3 можно почитать в документе "Performance Evaluation of VMXNET3 Virtual Network Device".

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

Также vNIC можно добавить с помощью добавления строчек в конфигурационный vmx-файл виртуальной машины:

• Для адаптера типа Flexible ничего добавлять не требуется.
• Ethernet[X].virtualDev = "e1000" - для добавления сетевого адаптера E1000.
• Ethernet[X].virtualDev = "vmxnet" - для добавления адаптера VMXNET 2 (Enhanced).
• Ethernet[X].virtualDev = "vmxnet3" - для добавления адаптера VMXNET3.

Вместо [X] необходимо подставить номер виртуального сетевого адаптера, начиная с 0.

Кстати, забыл тут про одну вещь. Не все администраторы VMware vSphere знают, что для того, чтобы зайти в черно-серое меню сервера VMware ESXi вовсе не обязательно использовать доступ через встроенную консоль типа HP iLO. Имеется в виду вот это меню настройки сервера (аналогично DCUI - Direct Console User Interface):

Все можно сделать прямо из SSH-сессии, если вы работаете под пользователем, имеющим локальную роль Administrator. Нужно просто выполнить команду:

# dcui

И вуаля - можно настраивать сервер без всяких iLO:

Само собой, это не работает в Lockdown mode, так как оно запрещает использование всех внешних интерфейсов, за исключением VMware vCenter Server (однако непосредственно в физическую консоль администратору залогиниться в этом режиме, конечно, можно).

Иногда, вследствие ошибки или отсутствия поддержки каких-либо функций, появляется необходимость обновить драйвер HBA-адаптера на сервере VMware ESXi - ведь ждать очередного обновления vSphere с обновленными драйверами можно очень долго.

Поэтому можно обновиться самим - это просто. Смотрим на свои адаптеры HBA, для чего выполняем команду:

# esxcfg-scsidevs -a

Здесь мы видим в каких слотах сервера размещены адаптеры (и производителя адаптера), но не видим версий их Firmware. Поэтому смотрим в девайсы, например для адаптера Qlogic (как смотреть остальные - тут):

# more /proc/scsi/qla2xxx/0

Здесь мы видим версию Firmware - 5.03.15 и метку версии драйвера.

Далее нужно посмотреть в KB 2030818 (Supported Driver Firmware versions for I/O devices) для того, чтобы определить поддерживаемые для ESXi драйверы адаптеров и рекомендации по текущей версии.

Например, для серверов HP идем в http://vibsdepot.hp.com/hpq/recipes/, где находим документ "HP-VMware-Recipe.pdf", в котором есть ссылки на необходимые драйверы:

Скачиваем нужный драйвер, например:

qla2xxx-934.5.6.0-887798.zip

Распаковываем архив и находим там .vib-файл:

scsi-qla2xxx-934.5.6.0-1OEM.500.0.0.472560.x86_64.vib

Теперь этот файл надо положить в папку:

/var/log/vmware

И запустить команду:

# esxcli software vib update -v scsi-qla2xxx-934.5.6.0-1OEM.500.0.0.472560.x86_64.vib

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

# more /proc/scsi/qla2xxx/0

Детальную информацию о VIB-пакете можно получить с помощью команд:

# esxcli software vib list | grep scsi
# esxcli software vib get -n scsi-qla2xxx

У некоторых виртуальных машин на платформе VMware vSphere может оказаться такая ситуация, что на одном виртуальном диске VMDK окажутся 2 логических раздела - например, диски C и D в Windows. Произойти это может вследствие P2V-миграции физического сервера в ВМ или изначальной конфигурации машины.

При этом, для каких-то целей вам может потребоваться эти логические диски разнести по двум файлам VMDK (например, для целей хранения дисков на разных "ярусах" хранения). Решить эту проблему весьма просто с помощью VMware vCenter Converter (мы писали о нем тут).

Делается так это все так:

• Начинаем процесс конвертации виртуальной машины
• Идем в мастере конверсии в Options
• Для раздела "Data to copy" выбираем "Edit"
• Выбираем опцию "Data copy type" и меняем ее на "Select volumes to copy".
• Далее на вкладке "Target Layout" в представлении "Advanced" настраиваем разнесение логических дисков по разным vmdk, как на картинке ниже.

Источник.

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

Недавно вышло очередное обновление схемы портов VMware vSphere 5.1. Схема уже является официальной и приведена в KB 2054806.

Приятно также и то, что теперь в этом же документе в виде таблицы приведены все порты различных компонентов VMware vSphere 5.x и назначение соединений:

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

На этот раз на VMware Labs появилась по-настоящему полезная штука - VisualEsxtop. Как можно догадаться из названия, эта утилита, написанная на Java, позволяет визуализовать данные о производительности в реальном времени, выводимые командой esxtop. Утилита кроссплатформенная и работает под Windows и Linux как .bat или .sh сценарий.

Возможности VisualEsxtop:

1. Соединение как с отдельным хостом ESXi, так и с vCenter Server.
2. Гибкий способ пакетного вывода результатов.
3. Загрузка результатов пакетного вывода и его "прогонка" (replay).
4. Возможность открыть несколько окон для отображения различных данных одновременно.
5. Визуализация в виде графика выбранных счетчиков производительности.
6. Гибкий выбор и фильтрация счетчиков.
7. Тултип на ячейках счетчиков, объясняющий их назначение (см. картинку).
8. Цветовое кодирование важных счетчиков.

Также VisualEsxtop можно заставить работать под Mac OS X - для этого почитайте вот эту статью.

Скачать VisualEsxtop можно по этой ссылке. Четырехстрочная инструкция доступна тут.

Продолжаем знакомить вас с багами VMware vSphere 5.1 - ведущей платформы виртуализации. На этот раз мы расскажем о баге VMware vSphere Client, для чего откроем вкладку редактирования пользователя и посмотрим на его свойства:

Такую картину мы увидим в том числе и тогда, когда пользователь VMware ESXi был создан автоматически, например, при использовании функций AutoDeploy и Host Profiles. Не очень понятно, почему это пользователю при создании по дефолту гарантируются права на доступ к консоли ESXi, а вот в списке групп, где он состоит, наблюдается пустота.

Все на самом деле просто: в vSphere 5.1 поменялся подход к безопасности, а вот сделать обновление vSphere Client забыли, так как сейчас идет переход на vSphere Web Client, и никому нет дела до толстого клиента. Соответственно, аспекты этого бага таковы:

• Галка "Grant shell access to this user" ни на что не влияет. Важно только, назначена ли роль Administrator пользователю (что позволит ему войти в консоль сервера).
• Поле Group пустое, так как ESXi больше не использует информацию из /etc/groups, а использует свою модель пользователей и групп:

• Поэтому вновь создаваемый пользователь с галкой "Grant shell access to this user" не сможет соединиться по SSH и зайти в консоль, то есть это баг UI:

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

Специально для таких случаев Graham French допилил скрипт на PowerShell / PowerCLI, который автоматизирует процессы Startup / Shutdown для виртуальных машин на ESXi. Грэхам подошел к задаче научно - он разделил все ВМ на 5 слоев, отражающих очередность выключения машин:

• Phase 1 - веб-серверы, балансировщики нагрузки, принт-серверы - то есть некритичные машины и машины на краю периметра датацентра.
• Phase 2 - серверы приложений и другие серверы, являющиеся фронтэнд-звеном в архитектуре многокомпонентных приложений.
• Phase 3 - серверы баз данных и кластеризованные серверы.
• Phase 4 - NAS-серверы и файловые серверы.
• Phase 5 - сервисы обеспечения инфраструктуры: Active Directory, DNS, DHCP, виртуальные модули (Virtual Appliances).

Соответственно, правильной схемой выключения виртуальных машин является последовательность Phase 1 -> Phase 5. Скрипт принимает на вход имена виртуальных машин в CSV-файлах, а также умеет выключать/включать и физические серверы:

Для включения машин используем обратную последовательность Phase 5 -> Phase 1:

Сам скрипт Startup / Shutdown и примеры CSV-файлов можно скачать по этой ссылке.

Недавно Duncan Epping опубликовал интересную статью о параметре Mem.MinFreePct, который есть в настройках сервера VMware ESXi из состава vSphere. По-сути, этот параметр определяет, какое количество оперативной памяти VMkernel должен держать свободным на хосте, чтобы всегда были доступные ресурсы под нужды системы, и хост не вывалился в PSOD.

В VMware vSphere 4.1 параметр Mem.MinFreePct составлял 6% и его можно было изменять с помощью следующей команды:

vsish -e set /sched/freeMemoryState/minFreePct <Percentage>

Например, вот так можно было установить Mem.MinFreePct в значение 2%:

vsish -e set /sched/freeMemoryState/minFreePct 2

Этак команда, кстати, не требует перезагрузки, но зато после перезагрузки значение Mem.MinFreePct не сохраняется. Поэтому данную команду, если требуется, нужно занести в /etc/rc.local (подробнее в KB 1033687).

Параметр этот очень важный, поскольку от него зависят пороги использования различных механизмов оптимизации памяти хоста ESXi. При этом, если памяти на хосте много (например, десятки гигабайт), то держать постоянно 6% свободной памяти может быть для кого-то расточительством. Поэтому, начиная с VMware vSphere 5.0, параметр Mem.MinFreePct является "плавающим" и устанавливается в зависимости от объема физической памяти на хосте ESXi.

Вот какие значения принимает Mem.MinFreePct в зависимости от того, сколько RAM есть на вашем физическом хост-сервере:

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

Интересно, конечно, но как-то бесполезно. Зачем загонять хост в такие лимиты? Лучше как минимум процентов 10 всегда держать свободными и своевременно покупать новые серверы.

Когда-то давно мы публиковали заметки о P2V-миграции физических серверов в виртуальные машины на платформе тогда еще VMware ESX Server (а также рассказывали о необходимых действиях после миграции). С тех пор многое изменилось, вышел VMware vCenter Converter Standalone 5.0, процесс миграции стал проще и стабильнее, а также накопилось пару моментов, о которых можно рассказать. Кроме того, появилась отличная статья на эту тему. Итак, есть 3 типа P2V-миграции...

Некоторые из вас, возможно, в курсе, что существует такой проект Google Authenticator, который позволяет организовать двухфакторную аутентификацию через телефон (как по СМС, так и через приложение), которая позволяет не только вводить свой постоянный пароль, но и дополнительно временно генерируемый код, что существенно снижает риски несанкционированного доступа. Возможно, кто-то из вас использует это для своей почты на GMAIL:

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

Компания VMware несколько доработала этот продукт, и на сайте проекта VMware Labs появился новый флинг - ESXi Google Authenticator, который позволяет организовать двухфакторную аутентификацию для доступа к консоли хост-серверов по SSH.

Для данного механизма обеспечения дополнительной безопасности поддерживаются хост-серверы ESXi 5.0 и 5.1, при этом допускается несколько администраторов одного сервера, использующих Google Authenticator (только ESXi 5.1).

Основные возможности ESXi Google Authenticator:

• Поддержка двухфакторной аутентификации как для ESXi Shell, так и для доступа через SSH.
• Поддержка нескольких логинов для ESXi 5.1 и одного (root) для ESXi 5.0.
• Поддержка 30-секундных кодов TOTP (меняются каждые полминуты).
• Поддержка кодов аварийного логина на случай, если телефон был украден (emergency scratch codes).
• Защита от атак с повторением запросов.

Технически аутентификация в ESXi Google Authenticator организована средствами модуля PAM (Pluggable Authentication Module) и специального приложения, доступного для платформ Android, iOS и Blackberry.

Устанавливается приложение одной командой:

esxcli software vib install -v --no-sig-check -f /path/to/the/vib

Далее нужно читать инструкции по использованию тут, а также в целом рекомендуется ознакомиться с проектом Google Authenticator.

Многие знают, что VMware vSphere версий 5.0 (начиная с Update 1) и 5.1 в полном объеме поддерживают Windows Server 2012 и Windows 8 в гостевых ОС виртуальных машин. Однако, еще далеко не во всех компаниях установлены последние версии гипервизора VMware ESXi - особенно в крупных организациях еще много где используют версию ESX/ESXi 4.x.

При попытке установить Windows Server 2012 и Windows 8 в виртуальной машине ESX/ESXi 4.x, выбрав в качестве гостевой ОС Microsoft Windows Server 2008 R2, администратор получит вот такую ошибку:

Your PC ran into a problem that it couldn't handle, and now it needs to restart

You can search for the error online: HAL_INITIALIZATION_FAILED

Решить эту проблему очень просто:

• Создаем новую ВМ в vSphere Client.
• В качестве типа гостевой ОС (Guest Operating System) выбираем Microsoft Windows Server 2008 R2 (64-bit).
• Скачиваем вот этот файл bios и кладем его в папку с виртуальной машиной

Далее в конфигурационный файл .vmx в папке с ВМ добавляем следующие строчки:

bios440.filename = "bios.440.rom"
mce.enable = TRUE
cpuid.hypervisor.v0 = FALSE
vmGenCounter.enable = FALSE

Теперь можно устанавливать и использовать Windows 8 и Windows Server 2012 в виртуальной машине на VMware ESXi 4.1.

Второй этап - это установка свежих VMware Tools в таких виртуальных машинах. Об этом мы писали в статье "Как обновить VMware Tools старых хост-серверов, не обновляя хостов VMware vSphere / ESXi".

Не так давно мы писали про средства управления питанием хост-серверов ESXi, которые имеются в VMware vSphere 5.1. Там мы рассматривали такую политику как Balanced - она разработана для того, чтобы максимально использовать переключения между состояниями P-states процессора в целях экономии энергии. Она обладает слегка большей инерционностью, чем обычное максимальное использование ресурсов процессора (High performance), но почти не влияет на производительность. Эта политика выставлена по умолчанию для серверов VMware ESXi 5.0 и более поздней версии.

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

Сравнивались три подхода к управлению питанием:

• Политика Performance - максимальное использование процессора за счет его поддержки в наивысшем P-state состоянии все время (то есть, по-сути политика энергосбережения отключена). При этом используются только 2 C-state состояния: С0 (running) и C1 (halted). Соответственно, данный режим выдает максимальную производительность, не имеет инерционности и потребляет больше всего энергии. Управляется эта политика BIOS'ом сервера.
• Политика Balanced - сбалансированное энергопотребление за счет переключения между P-states. Эта политика управляется хостом ESXi.
• Политика BIOS Balanced - функции энергосбережения, которые управляются на уровне BIOS сервера (например, Dell Active Power Controller).

Для тестирования производительности использовался стандартный подход VMmark, который предполагает создание возрастающих уровней нагрузки на хост-серверы (Tiles).

С точки зрения аппаратной платформы, использовалась следующая конфигурация:

• 4 сервера Dell PowerEdge R620
• CPUs (на сервер): один Eight-Core Intel® Xeon® E5-2665 @ 2.4 GHz, Hyper-Threading enabled
• Memory (на сервер): 96GB DDR3 ECC @ 1067 MHz
• Host Bus Adapter: два QLogic QLE2562, Dual Port 8Gb Fibre Channel to PCI Express
• Network Controller: один Intel Gigabit Quad Port I350 Adapter
• Версия гипервизора: VMware ESXi 5.1.0
• Дисковый массив: EMC VNX5700
• 62 флеш-диска (SSDs), RAID 0, сгруппированных в 3 x 8 SSD LUNs, 7 x 5 SSD LUNs и 1 x 3 SSD LUN
• Средства управления: VMware vCenter Server 5.1.0
• Версия VMmark: 2.5
• Power Meters: три устройства Yokogawa WT210

Итак, что получилось. График очков VMmark (чем выше столбики - тем лучше). Результаты нормализованы к BIOS Balanced на уровне Tile 1:

Как мы видим, худшие результаты показывает политика BIOS Balanced.

Теперь посмотрим на результаты тестов по новой методике VMmark 2.5, позволяющей измерять производительность сервера на киловатт питания:

Как мы видим, политика Performance показывает самые низкие результаты (это логично, так как энергии потребляется много, а столько мощности не всегда требуется процессору), политика ESXi Balanced показывает результат на 3% лучше, а вот политика BIOS Balanced - аж на 20% лучше.

Кстати, интересны измерения потребления мощности при простаивающем процессоре:

• Политика Performance потребляет 128 Вт
• ESXi Balanced - 85 Вт
• BIOS Balanced - тоже около 85 Вт

Казалось бы, почему тогда не использовать BIOS Balanced? А вот почему - при тестировании нагрузки приложений политика BIOS Balanced выдает огромные задержки (latency), негативно влияющие на производительность:

Таким образом, если снова вернуться к первому графику с обобщенными результатами, можно понять, что политика ESXi Balanced является наиболее оптимальной с точки зрения энергопотребления/производительности, поэтому-то она и установлена по умолчанию.

Не все администраторы платформы VMware vSphere в курсе, что на сервере VMware vCenter могут быть отключены различные фильтры хранилищ для хостов ESXi, что может оказаться полезным в нестандартных ситуациях.

Эти фильтры могут настраиваться через консоль vCenter в разделе расширенных настроек. Чтобы иметь возможность настраивать фильтры нужно выбрать пункт меню Administration > vCenter Server Settings. Далее в списке настроек нужно выбрать Advanced Settings.

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

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

Ну и видео для тех, кому удобнее воспринимать из визуального ряда:

Иногда попытка включить фильтр после его временного отключения приводит к ошибке. Тогда нужно на сервере vCenter в файле vpxd.cfg найти и поправить соответствующую строчку в конфигурационном xml-файле:

<filter>
<hostRescanFilter>true</hostRescanFilter>
</filter>

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

Как знают администраторы решения для виртуализации настольных ПК VMware Horizon View, есть 2 варианта кастомизации Windows-десктопов при их развертывании в рамках пулов - через утилиту QuickPrep компании VMware и с помощью Sysprep от Microsoft.

При этом иногда можно использовать только Sysprep (для полных клонов, Full Clones), а иногда обе утилиты (для связанных клонов, Linked Clones):

Когда же нужно использовать Sysprep, а когда QuickPrep? На это дает ответ KB 2003797. Приведем здесь основные моменты.

Итак, есть сравнительная таблица возможностей утилит для кастомизации ОС:

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

Что именно делает QuickPrep:

• Создает новый аккаунт в AD для каждого виртуального ПК
• Переименовывает десктоп в соответствии с заданными значениями
• Присоединяет компьютер к домену
• Монтирует том с профилем пользователя (если необходимо)

Если требуется что-то сверх этого, то необходимо использовать Sysprep. Начиная с Windows 7, он уже встроен в саму ОС от Microsoft, а если вы используете Windows XP, то придется использовать отдельный пакет Sysprep (его нужно загрузить на сервер VMware vCenter), как описано в KB 1005593 (мы также писали об этом вот тут).

На страницах vSphere Blog обнаружилась интересная статья Вильяма Лама про патчи, накатываемые на гипервизор VMware ESXi. Приведем здесь основные выдержки, которые могут оказаться полезными при обслуживании виртуальной инфраструктуры VMware vSphere.

Итак, для начала приведем структуру разделов на диске установленной копии ESXi:

Основное отличие от традиционной ОС в VMware ESXi - это то, что все файлы, необходимые гипервизору, хранятся в разделе фиксированного объема (Primary Boot Bank - 250 МБ). Альтернативный Boot Bank такого же размера необходим на случай отката к предыдущей версии ESXi, вне зависимости от того был ли произведен Update (накатывание патчей) или Upgrade (накатывание новой версии ESXi).

Если мы произведем апгрейд ESXi 5.0 на версию 5.1, то структура банков поменяется следующим образом:

Хотя это на самом деле даже и не так - ESXi 5.0 останется в прежнем банке, а загрузчик (Boot Loader) будет указывать уже на альтернативный банк, где разместится ESXi 5.1.

Когда происходит накатывание патча на ESXi - меняется весь банк (основной или альтернативный), поэтому патчи так много весят (по сути обновляется весь основной дистрибутив):

Но в этом есть и преимущество - размер раздела для банка фиксирован и установка ESXi не разрастается со временем при установке новых апдейтов и апгрейдах. Кстати, обратите внимание, что под патчем написано его влияние на систему после установки.

Следующий момент: являются ли патчи кумулятивными, то есть содержат ли они все предыдущие обновления ESXi? Да, все патчи содержат в себе предыдущие, поэтому нет необходимости накатывать их последовательно. Скачать патчи VMware ESXi можно с Patch Portal.

Далее, мы видим, что у патча есть список Bulletin List с суффиксом BG (Bug Fix). Есть также и SG-бюллетени обновлений по безопасности (Security). Оба этих типа бюллетеней могут обновлять как основной банк (base), так и пакеты VMware Tools (драйверы и прочее). Кроме того, в бюллетенях содержатся обновления драйверов устройств для самого сервера ESXi.

SG-бюллетень содержит только обновления подсистемы безопасности, а BG-бюллетени могут содержать новый функционал, исправления ошибок и, опять-таки, обновления, касающиеся безопасности.

Наконец, каждый бюллетень состоит из VIB-пакетов, о структуре которых Вильям хорошо рассказал вот тут. Список установленных VIB-пакетов на хосте ESXi можно узнать командой:

# esxcli software vib list

Будет выведено что-то вроде:

Name              Version                     Vendor Acceptance Level Install Date
----------------- --------------------------- ------ ---------------- ------------
ata-pata-amd      0.3.10-3vmw.500.0.0.469512  VMware VMwareCertified  2012-05-04
ata-pata-atiixp   0.4.6-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04
ata-pata-cmd64x   0.2.5-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04
ata-pata-hpt3x2n  0.3.4-3vmw.500.0.0.469512   VMware VMwareCertified  2012-05-04

О том, как накатывать патчи на ESXi из консоли мы уже писали вот тут, также об этом рассказано в KB 2008939.

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

Для начала отметим, что на платформе VMware Horizon View 5.2 появились следующие изменения по сравнению с предыдущими версиями в плане графических режимов виртуальных ПК:

• Horizon View 5.2 не позволяет установить 24-битную цветовую палитру, теперь используется только 32-битная.
• Horizon View 5.2 позволяет устанавливать разрешения только 1680×1050, 1920×1200 и 2560×1600. Дефолтным является 1920×1200.

Теперь о накладных расходах по памяти для виртуальных машин.

3D Software Rendering отключен

В этом случае расходы дополнительной памяти сервера на виртуальный ПК зависят от используемого разрешения и количества мониторов для виртуальной машины (значения приведены в мегабайтах):

Как вы знаете, в ESXi 5.0 появились возможности VMX Swap, которые позволяют создать swap-файл для сегментов данных процесса vmx, куда сбрасываются страницы памяти, но только в случае нехватки физической оперативной памяти на хосте. Он в разы уменьшает использование физической памяти на Overhead виртуальных машин в случае недостатка ресурсов.

Затраты хранилищ (в мегабайтах) на создание второго *.vswp файла для механизма VMX Swap рассчитываются следующим образом:

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

3D Software Rendering включен

Для виртуальных ПК отдельно или в пределах пула можно установить объем видеопамяти (VRAM, не путать с vRAM) доступный гостевой системе, что влияет на накладные расходы на виртуализацию.

В этом случае дополнительно требуемая физическая память будет рассчитываться как 64 МБ + 16 дополнительных МБ на каждый монитор.

Что касается SWAP-файла, то требуемый для него объем существенно выше, чем в первом случае. Он зависит от выделенной видеопамяти:

То есть, в некоторых случаях дополнительные затраты на хранилище отдельной виртуальной машины могут достигать 2 ГБ. Чтобы это все учитывать при планировании инфраструктуры виртуальных ПК, можно воспользоваться калькулятором от Andre Leibovici, по материалам которого и написана эта заметка.

Недавно мы писали про сетевой траблшутинг хостов VMware ESXi, где упоминали утилиту vmkping, с помощью которой можно пинговать какой-нибудь IP-адрес через  порт VMkernel. Но как быть если у вас 2 таких порта?

Через какой адаптер пойдет пинг?

Для этого случая есть параметр -I, который определяет через какой интерфейс пинговать (в нашем случае vmk1, а не vmk2):

# vmkping -I vmk1 IP-target

Источник, который рекомендует еще вот эту статью про vmkping с Jumbo Frames.

Время от времени мы пишем о графических материалах, позволяющих пользователям и партнерам VMware документировать виртуальную инфраструктуру VMware vSphere, VMware View, VMware SRM и прочее. Мы писали о наборе картинок для VMware vSphere 5 тут и тут, вот об этом наборе иконок, картинок и диаграмм, об этом, а также и об этом неофициальном наборе стенсилов Visio.

Последний как раз вчера и обновился в составе третьей части, которая теперь включает в себя картинки, графику и стенсилы для следующих компонентов:

• Orchestrator
• CapacityIQ
• Chargeback
• Appspeed
• Site Recovery Manager
• Studio
• vCloud Director
• VMware Server
• View
• ThinApp
• vCloud Director

Превьюшки некоторых наборов:

Скачать все это дело можно по следующим ссылкам:

Сделал этот полезный набор Maish Saidel-Keesing.

А вот актуальные на сегодняшний день официальные иконки, картинки и диаграммы от VMware Branding Team:

• VMware-Stencil2-vSphere.zip (16.7 MB)
• VMware-Stencil1-vSphere.zip (16.3 MB)

В формате Power Point:

• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_2_of_3.pptx  (2.6 MB)
• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_3_of_3.pptx  (2.9 MB)
• VMW_PPT_LIBRARY_Icons-Diagrams_2Q12_1_of_3.pptx  (17.4 MB)

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

Еще парочка интересных наборов:

• VMware View Visio Stencil Download (и в .VSX XML)
• VMware Icons Visio Stencil Shapes

Иконки там вот такие:

Есть еще вот такой набор картинок и стенсилов (некоторые уже устарели, некоторые еще в бою):

• VMware_VMGuru_stencil_v2.0

И вот такой:

• VMware Visio stencil pack 

Если в инфраструктуре есть продукты Veeam:

• Veeam Stencils for VMware and Hyper-V

Вроде все. Не благодарите.

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

Прежде всего, обычный пинг через стандартный Management-интерфейс:

# ping <IP хоста>

Пинг через порт VMkernel (в ESXi это тот же самый интерфейс, а в ESX - другой):

# vmkping 192.168.48.133

PING 192.168.48.133 (192.168.48.133): 56 data bytes
64 bytes from 192.168.48.133: icmp_seq=0 ttl=64 time=0.978 ms
64 bytes from 192.168.48.133: icmp_seq=1 ttl=64 time=1.009 ms

Для проверки соединения сервера VMware ESXi с хостом по какому-нибудь порту используется утилита netcat (nc). Telnet есть только на ESX. Формат использования netcat:

# nc -z <IP хоста> <порт хоста>

Например:

# nc -z 192.168.48.133 80
Connection to 192.168.48.133 80 port [tcp/http] succeeded!

С помощью netcat можно проверять только TCP-соединения, для UDP (флаг -uz) всегда будет статус succeeded (даже если порт заблокирован или закрыт), так как соединения по UDP не устанавливается. Для того, чтобы тестировать UDP-соединения можно воспользоваться утилитой tcpdump-uw.

Команда nc может быть использована для сканирования диапазона портов (будьте осторожны со сканированием, чтобы не навлечь гнев безопасников):

# nc -w 1 -z 192.168.48.133 20-81
Connection to 192.168.48.133 22 port [tcp/ssh] succeeded!
...
Connection to 192.168.48.133 80 port [tcp/http] succeeded!

Опция -w определяет таймаут между соединениями.

Для траблшутинга SSL-соединений может быть использована следующая команда:

# openssl s_client -connect <IP хоста>:<ssl-порт>

В результате, вы увидите нечно подобное:

# openssl s_client -connect 192.168.48.133:443
CONNECTED(00000003)

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

Для того, чтобы вывести список TCP/UDP-соединений на хосте, можно воспользоваться командами:

• На ESX 3.5/4.x – # netstat -tnp
• На ESXi 4.1 – # esxcli network connection list
• На ESXi 5.0 – # esxcli network ip connection list

Выводом будет что-то вроде:

# esxcli network connection list
Proto  Recv-Q  Send-Q    Local Address       Foreign Address     State        World ID
  tcp    0       52      192.168.48.136:22   192.168.48.1:55169  ESTABLISHED  0
  tcp    0       0       127.0.0.1:62024     127.0.0.1:5988      TIME_WAIT    0
  tcp    0       0       127.0.0.1:57867     127.0.0.1:5988      TIME_WAIT    0
  tcp    0       0       127.0.0.1:62196     127.0.0.1:5988      TIME_WAIT    0
  tcp    0       0       127.0.0.1:8307      127.0.0.1:52943     ESTABLISHED  5790
  tcp    0       0       127.0.0.1:52943     127.0.0.1:8307      ESTABLISHED  5790
  tcp    0       0       127.0.0.1:80        127.0.0.1:55629     ESTABLISHED  5785
  tcp    0       0       127.0.0.1:55629     127.0.0.1:80        ESTABLISHED  6613
  tcp    0       0       127.0.0.1:8307      127.0.0.1:56319     ESTABLISHED  5785
  tcp    0       0       127.0.0.1:56319     127.0.0.1:8307      ESTABLISHED  5785

Как многие из вас знают, в VMware vSphere 5.1 была введена возможность обновления пакета VMware Tools "без перезагрузки" гостевой ОС. Многие пользователи были удивлены - как же так, после обновления драйверов не нужно перезагружать сервер? На самом деле это небольшой маркетинговый обман - перезагружать ОС в некоторых случаях, все-таки, придется - чудес не бывает.

Просто исторически (до vSphere 5.1) обновление VMware Tools в любом из компонентов этого пакета требовало перезагрузки. При этом для Windows-систем ее можно было отложить используя опции установщика, например, такие (или так):

setup.exe /S /v"/qn REBOOT=R"

или

setup.exe /S /v"/qn REBOOTPROMPT=S"

Для ОС Unix/Linux драйверы и модули ядра отправлялись на стейджинг и активировались в системе после перезагрузки сервера.

Теперь же, в vSphere 5.1 обновление не всех компонентов VMware Tools требует перезагрузки, однако это применимо только к ОС Windows, для Linux все осталось по-прежнему. Перезагрузка требуется при обновлении следующих компонентов, входящих в состав пакета VMware Tools:

• Драйвер видеоадаптера VMware SVGA II. Он используется для ОС младше Windows Vista, однако может использоваться в некоторых случаях и для других ОС. Если в системе установлен драйвер VMware SVGA 3D, то его обновление, скорее всего, не потребует перезагрузки. Однако в KB 2015163 указано, что перезагрузка произойти, все-таки, может.
• Драйвер VMware Pointing Device Driver (PS/2). Этот драйвер используется по умолчанию для всех версий Windows, но обновляется крайне редко. В VMware vSphere 5.1 появился VMware USB Pointing Device driver, который не требует перезагрузки. Если это критично - можно использовать его.
• Драйверы VMware VMSCSI Controller и VMware PVSCSI Controller Driver. Обновление этих драйверов, скорее всего, потребует перезагрузки, но только в случае, если один из этих драйверов используется для системного диска (с папкой C:\Windows), либо для устройства, файловая система которого используется на момент установки. В других случаях (например, у вас нет дисков на контроллере PVSCSI) - перезагрузка не требуется.
• Опциональные компоненты. К ним относятся HGFS (функции shared folders) и ThinPrint, которые могут потребовать перезагрузки.

Какие особенности есть у процесса обновления VMware Tools без перезагрузки в VMware vSphere:

• Работает это для Windows Vista и выше.
• Работает только для ОС Windows.
• Для виртуальной машины требуется Virtual Hardware 9 или более поздней версии.

Также стоит прочитать статью о том, следует ли обновлять VMware Tools при апгрейде хостов VMware vSphere.

Многие из вас, кто использует кластеризацию MSCS в виртуальных машинах на платформе VMware vSphere, возможно, замечали, что когда используется кластер Across Boxes (т.е. между ВМ на разных хостах), то перезагрузка хоста VMware ESXi занимает весьма продолжительное время (иногда - до получаса).

При этом на экране консоли написано:

Loading module multiextent.

В логе VMkernel можно увидеть следующее:

Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:01:57.828 cpu0:4096)WARNING: ScsiCore: 1353:Power-on Reset occurred on naa.6006016045502500176a24d34fbbdf11
Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:01:57.830 cpu0:4096)VMNIX: VmkDev: 2122: Added SCSI device vml0:3:0 (naa.6006016045502500166a24d34fbbdf11)
Sep 24 12:25:36 cs-tse-d54 vmkernel: 0:00:02:37.842 cpu3:4099)ScsiDeviceIO: 1672:Command 0x1a to device "naa.6006016045502500176a24d34fbbdf11" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0

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

Избежать этого очень просто. Для этого:

• В ESX / ESXi 4.0 нужно выставить минимальное значение на число повторов операций при обнаружении конфликтов SCSI-резерваций (в Advanced Settings хостов):

Scsi.UWConflictRetries = 80

• Для ESXi 4.1 появилась дополнительная опция, которая уменьшает таймаут при загрузке в случае обнаружения конфликта. Это значение необходимо выставить в:

Scsi.CRTimeoutDuringBoot = 1

• Начиная с ESXi 5.0, опция Scsi.CRTimeoutDuringBoot больше не действует. Теперь нужно использовать команды множества esxcli storage. Для этого:

Сначала надо найти NAA-идентификатор устройства (физического LUN, на котором используется RDM). Для этого нужно зайти в управление путями до устройства (Manage Paths) и посмотреть на строчку, начинающуюся с naa...... - это и есть naa id.

Далее в консоли сервера ESXi нужно выполнить следующую команду (она пометит LUN как изначально зарезервированный):

esxcli storage core device setconfig -d naa.id --perennially-reserved=true

После этого хост ESXi, где были проведены данные манипуляции, будет загружаться быстро.

Более подробно о данной проблеме рассказано в KB 1016106.