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

Если можете поведать еще о каких-то интересных фичах, не вошедших в этот обзор – пишите в комментариях со ссылками – обязательно добавлю…

vSphere 4.0 (раз, два)

Управляемость.

• Появилась новая версия продукта управления виртуальной инфраструктурой – VMware vCenter 4.0. Он круче, более масштабируемый и обладает крутым интерфейсом (Но за все нужно платить, он требует для себя больше ОЗУ, чем предыдущий vCenter 2.5). Кроме того, можно объединить в единую логическую структуру несколько vCenter Server с помощью технологии Linked Mode. В этой единой структуре проще управлять лицензиями и ролями виртуальной инфраструктуры;
• Появился функционал Host Profiles, позволяющий стандартизировать настройку хостов ESX/ESXi;
• Появился объект vApps, позволяющий управлять многоуровневыми приложениями за счет группировки в себе нескольких ВМ;
• Было централизовано лицензирование vSphere 4.0 (произведен отказ от файлов лицензий). Все лицензии (тип продукта и количество) обозначаются 25-символьным ключом;
• Расширился функционал событий и оповещений. Появилась возможность фильтрации в vSphere Client событий от конкретного хоста;
• Появилась возможность раздавать детализированные разрешения на доступ к хранилищам и сетям (порт-группам стандартного и распределенного коммутатора);
• Появилось централизованное управление хранилищами через представление Datastores;
• Появился vSphere Command Line Interface “vi-*”, совместимый с предыдущим VMware Infrastructure 3.5 Update 2 и выше. Появилась предустановленая виртуальная машина vMA, содержащая в себе vCLI и syslog-демона;
• Продолжилось развитие vSphere Host Update Utility;
• Улучшился компонент Guided Consolidations;
• Появилось представление со статусом служб vCenter Server;
• Появился vCenter Orchestrator, позволяющий автоматизировать рутинные операции;
• Произошел переход на 64-битные версии VMKernel и сервисной консоли ESX;
• Появилась поддержка технологий Intel SpeedStep и AMD PowerNow! для снижения энергопотребления ненагруженных серверов;
• Появилась поддержка IPMI и HP iLO в Dynamic Power Management. Ранее поддерживался только WoL;
• Включена поддержка новых ОС, а также возможность их кастомизации (sysprep или его аналог для линукс);
• Добавлен мониторинг хостов ESXi посредством CIM-модулей и отслеживание событий от модулей через vCenter. Ранее этот функционал был реализован только в ESX за счет установки дополнительных пакетов управления.

Доступность.

• Появилась отказоустойчивость Fault Tolerance, обеспечивающая нулевой простой при сбое железного сервера. Одно из главных ограничений – 1 vCPU в защищаемой виртуальной машине (не устранено и по сей день);
• Появилось “бесплатное” решение для резервного копирования виртуальных машин – VMware Data Recovery;
• Появился механизм EVC (Enhanced vMotion Compatibility), позволяющий осуществлять миграцию между хостами с разными поколениями ЦП;
• Был улучшен механизм HA Admission Control, появился режим обслуживания HA (HA Maintenance Mode);
• Была заявлена поддержка Windows 2000/2003 MSCS (кластеров) и Windows 2008 Failover Clustering (а вот этого в VI3,5 не было). В vSphere 4.0 Update 1 была заявлена поддержка MSCS/FC в кластерах VMware HA/DRS с ограниченным функционалом (в основном, ограничения касаются запрета на живую миграцию – vMotion).

Безопасность.

• Появился брандмауэр VMware vShield Zones с централизованным управлением;
• Появилась технология VMSafe, позволяющая централизовано защищать виртуальные машины с помощью антивирусных решений партнеров VMware. Справедливости ради можно заметить, что нормально работающие решения появились спустя несколько лет после появления этой технологии;
• Появилась защита кода VMKernel за счет поддержки TPM (Trusted Platform Module), использования динамической адресации, цифровой подписи драйверов и компонент. Также стала использоваться проверка четности при работе с памятью.

Масштабируемость и производительность.

• Один сервер vCenter теперь поддерживает до 300 хостов и 3000 виртуальных машин. В режиме Linked Mode – в единой консоли можно видеть до 10000 ВМ;
• Поддерживаются хосты с 64 логическими процессорами, с 320 ВМ и до 512 vCPU на хост. Поддерживается до 1Тб ОЗУ;
• Появилась поддержка 8-процессорных виртуальных машин (VM Hardware version 7). Предыдущая версия – VM Hardware version 4 поддерживала только 4-х процессорные виртуальные машины. Справедливости ради отмечу, что максимальное количество vCPU было (и сейчас) доступно только на максимальной лицензии – vSphere Enterprise Plus. Появилась возможность предоставить ВМ до 255ГБ ОЗУ;
• Появилась функция Hot Add (горячее добавление различных устройств, а также ЦП/ОЗУ) для виртуальных машин;
• Появилась новое оборудование (SAS-контроллер для создания кластеров на Windows 2008, PVSCSI-адаптер для дисков, производительный сетевой адаптер VMXNET3). Подробнее о PVSCSI и VMXNET3 читайте в разделах СХД и сети;
• Появился функционал VMDirectPath – для прямого проброса в ВМ каких-либо устройств. Изначально этот функционал предназначался для проброса в ВМ LAN/FC-адаптеров, чтобы иметь быстрый ввод/вывод, но появление паравиртуального SCSI-контроллера и VMXNET3 свело на нет преимущества VMDirectPath по производительности;
• Улучшения в графиках производительности. Появились общие графики, показывающие загрузку основных ресурсов vSphere. Появились Storage Views и постройка топологии инфраструктуры;
• При установленных VMware Tools появилась интеграция счетчиков виртуального ЦП и ОЗУ внутри виртуальной машины с ОС Windows;
• Появилась детальная статистика по ЦП/ОЗУ для кластеров и пулов ресурсов;
• Переработан механизм планировщика, повысивший производительность многопроцессорных ВМ. До vSphere 4.0 существовала жесткая рекомендация – чем меньше vCPU, тем лучше;
• Появилась поддержка аппаратной виртуализации памяти;
• Оптимизация сетевого стека позволила повысить пропускную способность сети. Также было снижено время, затрачиваемое на vMotion и Storage vMotion, особенно для нагруженных ВМ. Управление Storage vMotion встроили в vClient, миграция стала работать между всеми видами СХД (iSCSI/NFS/FC);
• Появился интерфейс высокоскоростной связи между ВМ – VMCI. Вроде не используется в связи с поддержкой сетевым адаптером VMXNET3 скоростей 10Гбит/с, а на практике даже превышающих этот порог.

СХД.

• Появилась возможность использования тонких дисков в “продуктиве”, а также появились оповещения vCenter относительно их использования;
• Появился паравиртуализованный SCSI-контроллер (PVSCSI) для высоконагруженных ВМ. Данный контроллер оптимизирован для активного ввода/вывода, позволяя пропустить больший объем данных, создав при этом минимальную нагрузку на процессор хоста (в сравнении с LSI-адаптером);
• Появилась возможность увеличить VMFS-раздел на горячую (хотя в букварике дословно написано “сделайте бэкап и производите увеличение тома в момент низкой нагрузки на СХД”);
• Был переработан механизм доступа к данным и внедрена принципиально новая архитектура PSA (Pluggable Storage Architecture). Кроме прочего это позволило вендорам разрабатывать свои плагины для vSphere, позволяющие прыгать дальше и выше;
• Добавлена поддержка Jumbo Frames для NFS и software iSCSI-адаптера;
• Появилась поддержка ограниченного списка аппаратных FCoE-адаптеров;
• Появилась возможность легкого монтирования снапшотов VMFS с различными вариантами (со сменой сигнатуры или без смены);
• Оптимизация как программного, так и аппаратного iSCSI, позволила повысить производительность и значительно снизить нагрузку на ЦП хоста в случае использования программного iSCSI. Нагрузка на ЦП сравнялась с таковой при использовании NFS;
• Один хост стал поддерживать до 64 NFS-разделов;
• Заявлена поддержка Native SATA для VMFS;
• В vSphere 4.0 U2 изменен механизм удаления снапшотов при нажатии кнопки “Delete all snapshots”. До этой версии выполнение такой функции не рекомендовалось!

Сеть.

• Появился распределенный коммутатор. Также в нем появились PVLAN, Network vMotion и 3rd party DVS Support (Cisco Nexus 1000v etc);
• Появился сетевой адаптер VMXNET3 (поддержка MSI/MSI-X, если поддерживается гостевой ОС; Receive Side Scaling; IPv6 checksum и TCP Segmentation Offloading (TSO) over IPv6; VLAN off-loading; Large TX/RX ring sizes);
• Заявлена поддержка IPv6 для VMKernel, сервисной консоли и vCenter Server.

vSphere 4.1 (раз, два, ).

Управляемость.

• Поддерживается загрузка с СХД для ESXi;
• Появилась возможность использовать файлы ответов при установке ESX(i);
• Появилась поддержка Hyper-V в vCenter Converter – VCenter Converter позволяет пользователям указать на хост Hyper-V. Конвертер отобразит виртуальные машины, работающие на Hyper-V, пользователи смогут выбрать выключенные ВМ для импорта в VMware;
• Внесены улучшения в Host Profiles – новые Host Profiles позволяют соблюдать требования по смене пароля администратора. Кроме того, нововведения касаются Cisco Nexus 1000v и нумерации PCI-устройств;
• Добавлена интеграция ESX(i) с Active Directory – теперь хосты можно добавлять в домен и администрировать с помощью доменных учетных записей (членов группы ESX Admins). Также AD поддерживается и в vMA 4.1;
• Добавлены новые процессы для vCenter Orchestrator;
• Улучшено управление перевыпущенными патчами в Update Manager – теперь Update Manager отправляет оповещения о таких патчах, выводит список хостов, где они установлены и не даст установить старый патч;
• vCenter Update Manager поддерживает установку, внесение исправлений и обновление сторонних модулей;
• Появились правила зависимости между ВМ на хосте в DRS (Host affinity rule) – можно запретить DRS размещать ВМ на определенном наборе хостов. Это может понадобиться для соответствия политикам лицензирования или требованиям доступности;
• Появилась полная поддержка Tech Support Mode (локально и по SSH). Активность в Tech Support Mode посылается в Syslog. Вход в консоль и Tech Support Mode настраивается через vCenter;
• Появилась блокировка хоста ESXi – Lockdown mode;
• Улучшен механизм работы DPM (добавлен планировщик и автоматическое включение Standby-хостов при выключении DPM);
• vCenter 4.1 стал 64-битным;
• Улучшение работы Update Manager для отключения различных опций кластеров.

Доступность.

• Теперь HA постоянно отслеживает свой статус. В случае каких-то проблем можно настроить оповещение на изменение этого статуса;
• На вкладке Summary HA-кластера появилась ссылка на Cluster Operational Status, в котором имеется более подробная информация о текущих статусах и ошибках хостов кластера;
• Улучшения в FT – ВМ с FT полностью совместимы с DRS-кластером с включенным EVC. Теперь DRS может располагать первичные машины и “балансировать” как первичные, так и вторичные машины в FT. Механизм контроля версионности FT осуществляет проверку совместимости хостов, благодаря чему отпало требование совпадающих сборок ESX(i). vSphere 4.1 отличает события, которые генерирует первичная машина, от событий вторичной, а также может выдать отчет, почему хост не поддерживает FT. И наконец, вы можете отключить VMware HA на кластере, в котором развернуты машинки с FT;
• Поддерживается несколько одновременных сессий для управления VMware Data Recovery Appliance;
• Сделаны улучшения в EVC – третье поколение AMD Opteron работает в режиме EVC без технологии 3DNow!, что позволяет создать кластер, который будет совместим с новыми версиями процессоров AMD. Также улучшения в EVC коснулись указания режима EVC, более детализированных ошибок и снижения требования к перезагрузке ВМ;
• Появился интерфейс vStorage API for Data Protection и функционал Change Block Tracking для более быстрого резервирования/восстановления ВМ;
• HA научился работать совместно с DRS – теперь при нехватке ресурсов на хостах для перезапуска ВМ с резервациями DRS попытается сложить “пазл” и высвободить требуемое место;

Масштабируемость и производительность.

• В vSphere 4.1 Update 1 на один хост доступно до 160 логических процессоров;
• В кластере может быть до 3000 ВМ (было 1280). Один vCenter может управлять 1000 хостов (ранее 300). Запущенных ВМ (включая таковые с других vCenter в единой группе Linked Mode) до 10000.
• Сжатие памяти – новый уровень в иерархии экономии ОЗУ (Memory Overcommitment), находящийся между ОЗУ и жестким диском. Данная технология позволяет архивировать некоторый объем ОЗУ ВМ и помещать его в выделенный буфер этой ВМ;
• Улучшения в vMotion позволили значительно быстрее совершить перенос ВМ между хостами. Скорость переноса одной ВМ увеличилась до восьми раз, при переносе нескольких ВМ возможно мигрировать четыре или восемь ВМ одновременно (при скорости сети – 1ГБ/сек или 10ГБ/сек соответственно);
• Заявлена поддержка Fiber Channel 8Gbit/s;
• Реализован проброс USB с хоста внутрь ВМ. Естественно, ВМ нельзя мигрировать с этого хоста. В ВМ можно прокинуть до 20 устройств;
• Пользователь может задавать количество ядер на процессор ВМ через редактирование файла конфигурации. В vSphere 4.0 это количество было ограничено одним ядром (по крайней мере официально).

СХД.

• Появился функционал Storage I/O Control, позволяющий ограничивать количество дисковых операций отдельной ВМ, а также раздавать приоритет (shares) на использование СХД;
• Появилась более детальная статистика по пропускной способности и задержкам в среде SAN, хранилищам и VMDK. Появилась статистика по NFS. Все виды статистик доступны через vClient, (r)Esxtop, SDK;
• Появились программные интерфейсы vStorage API for Array Integration (VAAI) и vStorage API for Storage Awareness для лучшей интеграции с железными СХД.

Сеть

• Появился функционал Network I/O Control (как надстройка над распределенным коммутатором), позволяющий гранулировано раздавать пропускную полосу сети различным видам трафика;
• Сделаны улучшения в IPv6 – теперь поддерживается Internet Protocol Security (IPsec) и Internet Key Exchange (IKEv2);
• В распределенном коммутаторе появился новый тип балансировки – “Physical NIC Load”;
• Виртуальный распределенный коммутатор (vDS) масштабируется до 350 хостов на один коммутатор (ранее 64 хоста).

vSphere 5.0 (раз)

Управляемость.

• vSphere 5.0 – первый релиз, где отказались от “толстого” гипервизора ESX. Отныне – только ESXi;
• Появился VMware Auto Deploy, позволяющий автоматизировано разворачивать и встраивать в инфраструктуру сервера ESXi;
• Появился новый унифицированный стек командной строки ESXCLI;
• vSphere 5.0 умеет отправлять CIM-события в SNMP-trap;
• Появился механизм Image Builder, позволяющий создавать кастомизированные сборки инсталлятора, содержащие не только дополнительные драйвера, но и пакеты;
• Появился функционал файлов ответов, позволяющий использовать Host Profiles в полностью автоматизированном окружении. Также расширен список настроек Host Profiles;
• Появился vSphere Web Client, позволяющий выполнять задачи, связанные и обслуживанием и использованием ВМ;
• Появился vCenter Virtual Appliance, являющийся альтернативой для Windows-реализации vCenter;
• Все журналы теперь поддерживают отправку на удаленный syslog-сервер;
• Появилась служба vCenter Inventory, предназначенная для хранения тэгов к любым объектам виртуальной инфраструктуры;
• Хост может отправлять свой дамп по сети. Работает, если управляющие интерфейсы хоста находятся на стандартном коммутаторе;

Доступность.

• Изоляция сбойной ОЗУ – на поддерживаемых серверах vSphere может исключать из использования ОЗУ с большим количеством корректируемых ошибок. При появлении невосстановимой ошибки ВМ, та будет перезагружена. Хост зависает только в случае попадания ошибки в область памяти гипервизора;
• Разработан новый HA-агент, обладающий принципиально новыми возможностями. Исключено узкое место с “Primary hosts”, исключена зависимость от DNS, добавлена возможность резервной коммуникации через хранилища. Поддерживается работа этого агента с хостами vSphere 4.x и VI 3.5 Update2++;
• Появилось средство резервного копирования VMware Data Recovery 2.0;

Масштабируемость и производительность.

• vSphere 5.0 – первый дистрибутив, поддерживающий установку в ВМ Windows 2012 /2012R2. Механизмы запуска этой ОС на vSphere 4.1 существуют, но тривиальными их не назвать;
• Появилась новая версия виртуального железа – v8. В данной версии поддерживается до 32 vCPU (причем до 8 vCPU даже в базовых редакциях);
• Также поддерживается до 1Тб виртуальной ОЗУ. Появилась программная поддержка 3D для работы Windows Aero;
• Появилась поддержка USB 3.0, а также возможность подключать такие устройства через vSphere Client/Web Client. Имеется поддержка устройств для чтения смарт-карт, причем их можно одновременно подключать к разным машинам;
• Появилась возможность вместо BIOS использовать UEFI;
• Из графического интерфейса стало возможно создавать vCPU с несколькими ядрами. Ранее такой функционал был доступен только через редактирование VMX-файла;
• VMware Tools от vSphere 4.x поддерживаются на хостах с vSphere 5.0. ВМ с VMware Tools от vSphere 5.0 могут работать на vSphere 4.x;
• На одном хосте можно запустить до 512ВМ, максимум 2048 vCPU;
• Поддерживаются сервера с 160 логическими процессорами и 2Тб ОЗУ;
• Появился функционал Host Swap, позволяющий складывать своп-файлы ВМ на локальное SSD-хранилище хоста ;

СХД.

• Один хост стал поддерживать до 256 NFS-хранилищ;
• Появился механизм балансировки нагрузки на СХД – Storage DRS;
• Появился механизм привязки профилей к СХД, чтобы облегчить управление множеством хранилищ. Также возможна привязка этого механизма к vSphere API Storage Awareness для автоматизированного получения характеристик хранилищ, также есть механизм назначения ручных тэгов (характеристик);
• Появилась новая файловая система – VMFS5. Поддерживает LUN большего размера (до 64Тб), поддерживаются physical RDM такого же (до 64Тб) размера, большее количество файлов;
• Появился графический интерфейс для привязки сетевых адаптеров к vmkernel-интерфейсам при использовании iSCSI;
• Появилась поддержка Storage I/O Control для NFS;
• Появилась поддержка тонких LUN с помощью VAAI: Thin Provisioning;
• Был переработан механизм Storage vMotion, теперь стало возможно мигрировать ВМ со снапшотами;
• Появился программный FCoE-инициатор. Требует поддержки в сетевом адаптере;
• При сбоях с удалением снапшота появилась операция Snapshot Commitment;

Сеть.

• Появился функционал SplitRX, призванный повысить производительность мультикаст-трафика;
• Расширился функционал Network I/O Control, позволяющий внедрять пользовательские пулы сетей, а также интегрировать QoS с физической инфраструктурой;
• Расширился функционал распределенного коммутатора за счет функционала Netflow, Port Mirroring, LLDP;
• Появился функционал Metro vMotion, позволяющий осуществить живую миграцию при сетевой задержке до 10 мсек (ранее было <5мсек);
• vMotion для миграции может использовать несколько физических адаптеров одновременно. Это достигается наличием нескольких VMKernel-интерфейсов;
• vCloud&vSphere представляют механизм WXLAN, позволяющий развертывать абстракцию layer-2 сети поверх маршрутизируемых сетей в разных ЦОД;

Безопасность.

• Сервер поддерживает интеграцию с технологией Intel Trusted Execution Technology (TPM/TXT);
• Драйвера и библиотеки располагаются в случайных областях памяти. Добавлена цифровая подпись к модулям и драйверам, загружаемым в VMKernel;
• На ESXi хостах появился брандмауэр;
• Появилась возможность указать название группы, которая будет администратором хоста после добавления в домен;

vSphere 5.1 (раз)

Управляемость.

• Появилась интеграция Storage DRS и Profile-Driven Storage с vCloud Director;
• Появился Operations Manager, позволяющий осуществлять мониторинг за виртуальной средой;
• Теперь vSphere Web Client является основным средством администрирования виртуальной инфраструктуры. “Толстый” клиент остался для обеспечения совместимости с ранее написанными плагинами. Веб-клиент оптимизирован и запрашивает только ту информацию, что отражается на экране в настоящий момент;
• Появился компонент vCenter Single Sign-On, направленный снизить издержки на администрирование (по факту, одно из самых отстойных нововведений на мой взгляд);
• Web Client обрел совместимость с vCenter Orchestrator;
• Переработанная служба vCenter Inventory научилась кэшировать запросы. Кроме того, появилась возможность установки этой службы на отдельный сервер, поближе к веб-клиенту. Тэги этой службы позволяют группировать объекты самым различным образом;
• Хост может отправлять свой дамп по сети. Работает на обоих типах коммутаторов (vSS, vDS);
• Появилась поддержка SNMPv3 для мониторинга. Компонент SNMP был выгружен из vmkernel в отдельный модуль;
• Произведено изменение версий виртуального железа на версию совместимости с vSphere (для большей понятности);
• AutoDeploy поддерживает два дополнительных режима: Stateless caching и Statefull Installs;

Доступность.

• Появился продукт резервного копирования VMware Data Protection, основанный на EMC Avamar;
• Появился функционал репликации ВМ через локальную сеть между абсолютно любыми хранилищами;
• После обновления до VMware Tools 5.1 количество перезагрузок при обновлении утилит снижено;

Масштабируемость и производительность.

• Появилась девятая версия виртуального железа. Поддерживается до 64 vCPU. Добавлено ускорение 3D графики с помощью vGPU (только для VMware View);
• Появился функционал Guest Storage Storage Reclamation;
• Появился функционал Virtualized Hardware Virtualization, позволяющий пробрасывать внутрь ВМ почти все функции ЦП и запускать внутри ВМ Hyper-V (например);
• Появилась поддержка до 300 одновременных сессий веб-клиента;
• Возможность выгружать в своп фоновые процессы, снижая тем самым использование ОЗУ хоста оверхедом виртуальных машин. Позволяет высвободить до 1 Гб ОЗУ при нехватке;
• В DRS появились дополнительные параметры, например, LimitVMsPerESXhost, позволяющий указать максимальное количество ВМ на хосте;

СХД.

• Количество хостов, читающих файлы на VMFS в режиме read-only (например, для “золотого” образа VMware View) увеличилось до 32 (ранее было 8);
• Добавлена загрузка с программного FCoE;
• Поддерживаются FC 16Gbit HBA (но подключение хост-коммутатор-СХД на такой скорости поддерживается только в vSphere 5.5);
• Добавлен мониторинг SSD;
• Storage I/O Control научился сам вычислять пороговое значение для “тормозов” хранилища. Также стала доступна суммарная статистика хранилища в режиме работы SIOC “stats only”;
• Добавлено определение связанности двух хранилищ при их нахождении на одном наборе дисков. В vSphere 5.0 это определялось с помощью VASA, в 5.1 – с помощью наблюдений за нагрузкой;
• Использование в Storage DRS новой метрики VMObservedLatency, измеряющей задержку от отправки команды к VMKernel до получения ответа от хранилища;
• Storage vMotion может осуществлять одновременную миграцию до 4х VMDK-дисков;
• Произведена оптимизация iSCSI&Jumbo frames, позволившая добиться увеличения скорости чтения на HWiSCSI на 88% (остальные цифры скромнее);

Сеть.

• Улучшения в распределенном коммутаторе, позволяющие осуществлять проверку конфигурации (health check), бэкап/восстановление конфигурации, откат (Rollback), поддержка LACP;
• Поддержка SR-IOV;
• Появилась возможность осуществлять vMotion без общего хранилища;
• Появилась возможность блокировки BPDU-пакетов, отправляемых ВМ. Это необходимо, чтобы скомпрометированные ВМ не осуществили атаку DoS;
• Увеличено количество распределенных коммутаторов на vCenter, портгрупп стандартного и распределенного коммутаторов, а также количество хостов в распределенном коммутаторе;
• Появилась настройка “Latency Sensivity”, позволяющая снизить задержку ВМ по сети;

Безопасность.

• Появился vSphield Endpoint API, позволяющий отказаться от антивирусных агентов внутри ВМ;
• Локальные пользователи с правами администратора автоматически получают shell-права на хосте. Это убирает необходимость в root’е;
• Административные права у root можно забрать, можно ограничить открытые сессии тайм-аутом;
• Логируется не только локальная консоль, но и действия в DCUI-интерфейсе;

vSphere 5.5 (раз)

Доступность.

• ESXi поддерживает технологию “reliable memory”. Теперь, если оборудование поддерживает эту технологию, гипервизор будет располагаться в тех областях памяти, которые считаются наиболее надежными;
• С помощью дополнительных агентов на хосте появилась возможность защищать приложения с помощью High Availability;
• HA научился смотреть на правила DRS VM affinity (находиться вместе на хосте или наоборот, никогда не собираться вместе) и при перезапуске ВМ учитывает эти правила;
• vSphere Data Protection был модернизирован (репликация на EMC Avamar, Emergency-восстановление, бэкап отдельных VMDK, продвинутый планировщик);

Масштабируемость и производительность.

• Вдвое увеличены лимиты хоста – до 320 логических процессоров и до 4 Тб ОЗУ (до 6 Тб в Update 2);
• Поддержка подключения SSD “на горячую”;
• Встроенная база в vCVA теперь поддерживает до 100 хостов и до 3000 ВМ;
• В vSphere 5.1 при использовании сбалансированной политики электропитания для экономии электричества использовалось P-State, отличающееся пониженным энергопотреблением. В vSphere 5.5 эта политика также использует C-state состояния, отличающиеся еще большим энергосбережением;
• Добавлен новый уровень виртуального железа (aka VMHardware v10), позволяющий обеспечить поддержку LSI SAS для Oracle Solaris 11, поддерживающий новые процессоры, контроллер AHCI. Увеличилось количество устройств на один SCSI-контроллер до 30 (всего до 120);
• Расширена поддержка 3D-устройств в виртуальной среде;
• Модернизирован механизм Single Sign-On, убрана необходимость во внешней SQL-базе;
• В веб-клиенте появился функционал Drag’n’Drop, фильтрация объектов, возможность доступа к “последним” редактируемым объектам;
• Появилась поддержка развертывания и управления Hadoop-кластерами (Big Data Extensions) из веб-клиента;
• Появился механизм кэширования СХД на локальных SSD-дисках – vSphere Flash Read Cache;
• Появились дополнительные параметры DRS, например, AggressiveCPUActive. Параметр позволяет выловить пики загрузки хоста, укладывающиеся в 5-минутный интервал проверки хостов;
• Появились дополнительные параметры DPM, например, MinPoweredOnCpuCapacity и MinPoweredOnMemCapacity.

СХД.

• Появилась поддержка больших VMDK-файлов – до 62Тб;
• Расширена поддержка кластеров до Windows 2012, политики балансировки Round Robin, в качестве общего хранилища поддерживаются iSCSI и FCoE (дополнительно к ранее поддерживавшемуся FC);
• Полностью поддерживается протокол FC 16Gbit от HBA до СХД;
• Добавлена опция PDL auto remove, позволяющая автоматически убирать с хостов более несуществующие устройства;
• Репликация ВМ нормально интегрировалась с vMotion/Storage vMotion (ранее после Storage vMotion требовалось полностью пересинхронизировать ВМ);
• Оптимизация Heap-пространства для снижения использования ОЗУ;
• Появился vSphere Virtual SAN (распределенное хранилище до 8 хостов);

Сеть.

• Произведена оптимизация LACP (больше групп, больше алгоритмов работы);
• Появилась возможность фильтрации трафика на основе ACL (MAC, IP, port, тип трафика) на распределенном коммутаторе;
• Дополнительно к поддержке QoS на уровне сети появилась поддержка DSCP (управление качеством на уровне IP-пакетов);
• Произведена некоторая оптимизация SR-IOV;
• Добавлена утилита перехвата трафика на хосте (аналог tcpdump в ESX);
• Поддерживаются сетевые адаптеры 40GBit/s;
• Распределенный коммутатор поддерживает авторасширение количества портов. В 5.1 на хост приходилось до 4096 портов (и ограничение примерно в 400ВМ на хост);

Итак, поехали.

1) Обновление vCenter до версии 5.1b.

vCenter у меня уже версии 5.1.

Вставляем диск с vCenter и по порядку выполняем обновление всех компонент.

Проблем никаких не увидел.

2) Обновляем хосты ESX 4.1 U3 до ESXi 5.1.

Обновление хостов я производил через Update Manager.

– Добавил дистрибутив с ESXi 5.1.

– Создал Baseline для апгрейда хостов

– Затем назначил этот Baseline на кластер и начал применять (Remediate) его на хосты.

Первый подвох был внезапен

VMkernel and Service Console interfaces are sharing the same subnet…

Пришлось удалять VMKernel-интерфейс из подсети управления хостами.

Также при обновлении хоста пришлось временно отключать Admission Control и давать разрешение на удаление стороннего ПО с хоста.

На выходе мы имеем несколько хостов ESXi 5.1 с оценочной лицензией. Теперь можно установить на них дополнительные патчи для ESXi 5.1 и продолжать настройку.

3) Так как я сижу на распределенном коммутаторе, мигрируем обратно на стандартный.

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

– Создаем стандартный коммутатор vSwitch0 на каждом хосте кластера и создаем портгруппы с корректными номерами VLAN

Get-Cluster -Name Cluster | Get-VMHost | %{
$vswitch=New-VirtualSwitch -Name vSwitch0 -vmhost $_
New-VirtualPortGroup -Name VLAN10 -VLanId 10 -VirtualSwitch $vswitch
New-VirtualPortGroup -Name VLAN20 -VLanId 20 -VirtualSwitch $vswitch
New-VirtualPortGroup -Name VLAN30 -VLanId 30 -VirtualSwitch $vswitch
}

– руками добавляем адаптер vmnic1 в стандартный коммутатор на каждом хосте

– заходим в сетевые настройки хоста и проверяем, что на распределенном коммутаторе остался один сетевой адаптер. Нажимаем ссылку “Manage Virtual Adapters…”

– в полученном окне выбираем интерфейс управления и нажимаем кнопку “Migrate” для его переноса на стандартный коммутатор

– укажем название стандартного коммутатора и корректный номер VLAN для управляющего интерфейса VMKernel

– после этого можно переносить виртуальные машины на стандартный коммутатор. Проще всего это делать из вкладки Home->Inventory->Networking (скриншот приведен выше), где представлены все порт-группы. Выбираете порт-группу на распределенном коммутаторе, там выделяете все ВМ с вашего хоста и перетаскиваете их на соответствующую порт-группу стандартного коммутатора (drag’n’drop). Осторожно, никаких подтверждений не требуется, вы легко можете перенести ВМ в другую порт-группу и создать инцидент. Данный перенос можно производить в рабочее время – доступ к ВМ не прекращается.

– теперь в сетевых настройках хоста нажмем ссылку “Manage Physical Adapters…” и удалим из распределенного коммутатора адаптер vmnic0

– для добавления этого адаптера к стандартному коммутатору переключимся на представление стандартного коммутатора и зайдем в его свойства

– переключимся на вкладку “Network Adapters” и добавим адаптер vmnic0

– теперь остается удалить хосты из распределенного коммутатора и указать для них лицензии vSphere 5.

P.S. Вся эта суматоха затеяна из-за компании VMware, которой влом поддерживать Windows 2012/Windows 8 на vSphere 4.1.

Достаточно подробное сравнение ESX (“толстый” гипервизор) и ESXi (“тонкий” гипервизор”) версии 4.1 сделано VMware. Стоит также отметить, что в vSphere 5/5.1 остался только ESXi. В рамках этой статьи я затрону два различия:

1) Для управления ESX извне используется подключение к виртуальному интерфейсу Service Console или vswif#. Для настроек из консоли сервера используется команда esxcfg-vswif. Для управления ESXi используется виртуальный интерфейс VMKernel или vmk#. Для настроек из командной строки – esxcfg-vmknic.

2) Для управления из консоли сервера ESXi можно использовать черно-желтый интерфейс DCUI, либо командную строку. Для ESX доступна только командная строка. При использовании распределенного коммутатора совместно с ESXi в DCUI есть пункт меню по восстановлению стандартного коммутатора на сервере ESXi.

После миграции виртуальных сетей на распределенный коммутатор, у вас есть два варианта: мигрировать туда же сети управления, или оставить их на стандартном коммутаторе. Если “лишних” сетевых адаптеров нет, то и выбора, в общем-то, тоже

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

На скриншоте чуть ниже показано, что у хоста ESX случилась какая-то странная проблема с интерфейсом vswif0 – там пропал IP-адрес.

Для начала выполним команду esxcfg-vswitch -l. Нам необходимо узнать номер порта, к которому подключен тот аплинк, что мы будем отключать.

Теперь отключим с распределенного коммутатора аплинк

esxcfg-vswitch -Q vmnic0 -V 1599 dvSwitch

Создадим стандартный коммутатор и добавим к нему этот аплинк

esxcfg-vswitch -a vSwitch0

esxcfg-vswitch -L vmnic0 vSwitch0

Создадим на этом коммутаторе порт-группу для виртуальных интерфейсов и назначим ей VLAN сети управления

esxcfg-vswitch -A "Service Console" vSwitch0

esxcfg-vswitch -v 10 -p “Service Console” vSwitch0

Удаляем старый vswif0 интерфейс и создаем его заново на стандартном коммутаторе

esxcfg-vswif -d vswif0

esxcfg-vswif -a vswif0 -i 192.168.0.10 -n 255.255.255.0 -p “Service Console”

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

Передо мной была поставлена задача по миграции кластера VMware на распределенный свитч. Кластер состоит из нескольких хостов ESX 4.1. Для совмещения приятного с полезным было принято решение также перевести порты коммутаторов Cisco в режим транк для использования нескольких VLAN в виртуальной среде.

Порывшись в документации, я нашел два варианта решения задачи:

– руками через GUI;

– через функционал Host Profiles.

Так как второй вариант предусматривает простой в работе, мною был выбран вариант настройки руками.

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

1. Временно резервируем один IP-адрес серверного диапазона (из подсети сервисной консоли) для проверки транка на порту Cisco;
2. Освобождаем один сетевой адаптер хоста;
3. Добавляем его в распределенный свитч и переводим порт в режим транк;
4. Добавляем новый адаптер Service Console VMKernel с зарезервированным адресом и проверяем, идут ли пинги;
5. Мигрируем сервисную консоль со стандартного свитча;
6. 
7. Мигрируем виртуальные машины скопом в новую сеть (выделяем и перетаскиваем в нужную сеть. Внимание: если промахнетесь, они улетят в другую сеть, а мы получим простой;
8. 
9. Если все прошло удачно, радостно удаляем стандартный виртуальный свитч и добавляем освободившийся сетевой адаптер в распределенный свитч.

На этом эпопею можно было бы считать оконченной, если бы не правки в пункте №4. А именно, если вы для теста временно создадите вторую сервисную консоль в той же подсети, то словите (на хостах ESX 4.1 build 320*) глюк. У вас порушится маршрутизация для демона консоли виртуальных машин. Команда telnet host 903, используемая для проверки доступа к консоли ВМ, будет работать только из той же подсети, где находятся интерфейсы Service Console. Времени на разбирательства не было, поэтому был опробована перезагрузка хоста. Помогло.

Если все же не поможет, прямая дорога в kb.

Качать тут.

Для этого нам понадобится исправная клавиатура и физический доступ к серверу ESX

ESX Server 3.x:
1) Перезагружаем сервер.
2) Когда появится экран выбора ОС, нажмите пробел, чтобы прекратить загрузку VMware ESX Server.
3) Выберите пункт Service Console only (troubleshooting mode).
4) Нажмите любую клавишу для изменения параметров загрузки.
5) Введите single .

6) Нажмите Enter. Сервер начнет загружаться в однопользовательском режиме.
7) Когда увидите приглашение командной строки sh-2.05b#, наберите команду passwd и нажмите Enter.
8) Установите новый пароль для пользователя root.
9) Когда сменится пароль, перезагрузите сервер в обычном режиме.
ESX Server 2.x:
1) Перезагружаем сервер.
2) Когда появится экран LILO, нажмите пробел, чтобы прекратить загрузку VMware ESX Server.
3) В загрузчике LILO выберите пункт “linux” и добавьте -s в конец строки, так чтобы получилось: linux -s.
4) Нажмите Enter. Система загрузится в однопользовательском режиме.
5) Когда увидите приглашение командной строки sh-2.05b#, наберите команду passwd и нажмите Enter.
6) Установите новый пароль для пользователя root.
7) Когда сменится пароль, перезагрузите сервер в обычном режиме.

Море информации, не утоните.