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

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

Как вы знаете, в платформе виртуализации VMware vSphere 4.1 появилось несколько новых улучшений в плане производительности горячей миграции виртуальных машин vMotion между серверами VMware ESX / ESXi (об этом можно почитать тут и тут).

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

Duncan Epping, сотрудник VMware и известный блоггер, недавно раскрыл подробности работы Quick Resume. За счет этой техники виртуальная машна перемещаемая на целевой хост запускается еще до того, как все страницы полностью скопируются. Но в этом случае целевая машина может запросить страницу памяти, которая еще не скопировалась.

В этом случае Quick Resume обеспечивает доступ к странице с исходной виртуальной машины, продолжая при этом копирование страниц на целевой хост. Но что будет, если в этот момент сеть перестанет быть доступной, а целевой машине понадобится страница?

В этом случае Quick Resume для vMotion, также как и Storage IO Control, использует общее хранилище для хостов ESX / ESXi. На хранилище создается специальный файл, который используется как backup buffer, к которому имеют доступ оба хоста, и за счет которого миграция vMotion доводится до конца. То есть, через этот буферный файл (несколько мегабайт) происходит обмен страницами между хостами в случае недоступности сети или высокоинтенсивной нагрузки. Естественно это все заметно влияет на производительность ВМ во время миграции, так как время доступа к памяти сильно увеличивается, зато все отрабатывает надежно.

Ну и вспомните, если забыли, как работает Storage vMotion.

Как вы знаете, для виртуальных хранилищ (datastores) в VMware vSphere есть возможность задавать разные размеры блоков тома VMFS. Также вы, вероятно, знаете, что операция Storage vMotion позволяет перемещать виртуальную машину между хранилищами, превращая ее виртуальный диск из толстого (thick) в тонкий (thin).

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

Duncan Epping, известный технический эксперт VMware, обратил внимание на проблему, когда пользователь делает очистку блоков, затем Storage vMotion, а уменьшения диска не происходит. Почему так?

Очень просто, в составе VMware ESX / ESXi есть три типа datamover'ов ("перемещателей"):

• fsdm – это старый datamover, который представляет собой базовую версию компонента. Он работает сквозь все уровни, обозначенные на картинке. Зато он, как всегда, универсален.
• fs3dm – этот datamover появился в vSphere 4.0 и имеет множество оптимизаций. И вот тут данные уже не идут через стек работы с виртуальной машиной. То есть он работает быстрее.
• fs3dm – hardware offload – Этот компонент появился для поддержки технологии VAAI, которая позволяет вынести операции по работе с хранилищами виртуальных машин на сторону массива (hardware offload). Он, естественно, самый быстрый и не создает нагрузку на хост VMware ESX / ESXi.

Так вот основная мысль такова. Когда вы делаете миграцию Storage vMotion виртуальной машины между хранилищами с разными размерами блоков используется старый datamover fsdm, а когда с одинаковыми, то новый fs3dm (в программном или аппаратном варианте). Последний работает быстрее, но не умеет вычищать нулевые блоки на целевом хранилище у виртуального диска VMDK.

А вот старый fsdm, ввиду своей универсальности, это делать умеет. То есть, если нужно вычистить нулевые блоки не перемещайте ВМ между хранилищами с одинаковыми размерами блоков. Так-то вот.

Если вы используете пулы типа Linked Clone (на основе базового образа) в решении для виртуализации ПК VMware View 4.5, то знаете, что есть такая операция "Rebalance", которая перераспределяет виртуальные ПК пула по хранилищам VMFS / NFS. Но многие удивятся, как работает эта функция. Например, у вас есть несколько хранилищ различной емкости, и вы делаете Rebalance десктопов.

Получаете вот такую картину:

Слева - то, что вы ожидаете увидеть в результате балансировки, а справа - то, что получается на самом деле. В чем причина?

Все дело в том, что VMware View 4.5 использует для перемещения машин на хранилище параметр "weighted available space". У какого из хранилищ он больше - туда виртуальные машины и переезжают. Что это за параметр:

weighted_available_space = datastore_capacity * overcommit_factor – virtual_usage

Здесь:

datastore_capacity - это общая емкость хранилища VMFS / NFS.

virtual_usage - это максимально возможный объем, занимаемый виртуальными машинами на хранилище, который формируется из размера виртуальных дисков машин (номинального, а не реального) + размер памяти (для Suspend).

overcommit_factor - это настройка для Storage Overcommit, которую вы задавали для Datastore, когда выбирали, какие из них следует использовать для пулов Linked Clone. Там были такие значения:

• None - хранилище не является overcommitted.
• Default - это коэффициент 4 от размера хранилища
• Moderate - это коэффициент 7 от размера хранилища
• Aggressive - это коэффициент 15 от размера хранилища.

Теперь переходим к примеру и формуле. Есть у нас вот такая картинка (см. настройки overcommitment):

Счтиаем weighted available space:

• DS1 - 1000GB (Datastore Size) * 4 (Conservative Overcommitment) – 0 (No VM's deployed) = 4000
• DS2 - 1000GB (Datastore Size) * 4 (Conservative Overcommitment) – ((20GB + 130MB)x5) (5 VM's already deployed) = 3865
• DS3 - 1000GB (Datastore Size) * 7 (Moderate Overcommitment) – ((20GB + 130MB)x5) (5 VM's already deployed) = 6865

Теперь вот вам задачка - что будет в результате Rebalance виртуальных ПК?

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

И да, никогда не далейте Storage VMotion для виртуальных машин VMware View 4.5 вручную - это не поддерживается со стороны VMware.

Материал написан по мотивам заметки "VMware View 4.5: Rebalance" от Simon Long.

Максимальное число VMotion на серверах VMware ESX и ESXi.

Горячая миграция VMotion в составе пакета продуктов VMware vSphere позволяет переместить виртуальную машину с одного хоста ESX на другой без прерывания работы этой ВМ. При этом, по умолчанию на хосте ESX / ESXi доступно максимум 2 одновременных миграции VMotion. В некоторых случаях, этого может оказаться мало, и можно увеличить данное количество до 6 одновременных миграций на хост.

Давайте попробуем разобраться, как VMware vCenter рассчитывает количество доступных одновременных VMotion на хосте ESX / ESXi. Во-первых, есть такой конфигурационный файл vpxd.cfg для сервера VMware vCenter, который находится в папке:

%ALLUSERPROFILE%\Application Data\VMware\VMware VirtualCenter\

Что аналогично:

C:\ProgramData\VMware\VMware VirtualCenter\ (для Windows 2008 Server)

C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\ (для Windows 2003 Server)

Открываем файл vpxd.cfg и вставляем туда следующую секцию XML между тегами <vpxd> и </vpxd>:

<ResourceManager>
<maxCostPerHost>12</maxCostPerHost>
</ResourceManager>

Итак, мы видим параметр maxCostPerHost, который определяет максимально доступную "стоимость" на хост VMware ESX. Данная стоимость вычисляется просто - VMware VMotion "стоит" 4 единицы, а "холодная миграция" (Cold Migration) дает 1 единицу. Таким образом, значение 12 позволяет использовать либо 3 одновременных VMotion, либо 2 VMotion и 4 Cold Migration в один момент времени. Все очень просто. Максимальное значение данного параметра - 24 или 6 одновременных миграций VMotion на хост VMware ESX / ESXi.

В следующей версии VMware vSphere число одновременных миграций VMotion будет увеличено до 8, и данный параметр будет включен по умолчанию.

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

Максимальное число VMotion на хранилища VMFS и NFS.

Одно хранилище VMFS в VMware vSphere 4 поддерживает до 8 одновременных миграций VMotion виртуальных машин, расположенных на нем. То же касается и Storage VMotion - их также может быть 8 на одно виртуальное хранилище VMFS 3. Для NFS-хранилищ в данный момент поддерживается до 4 одновременных миграций VMotion / SVMotion на одно хранилище.

Для Storage VMotion надо помнить то, что данная операция задействует 1 доступ к исходному Datastore и 1 доступ к целевому Datastore, а на одно хранилище VMFS может быть до 8 доступов (то есть 8 миграций SVMotion с хранилища возможны только если на него ничего не перемещается в этот момент с помощью SVMotion).

Андрей Вахитов (vmind.ru) в своем блоге разместил просочившуюся информацию о новой функциональности готовящегося к выпуску релиза платформы виртуализации VMware vSphere 4.1, включая ESX 4.1 и vCenter 4.1.

Приблизительный список основных новых возможностей VMware vSphere 4.1:

• Поддержка развертывания тонкого гипервизора VMware ESXi по PXE.
• Контроль обмена трафиком с системой хранения Storage I/O Control в стиле QoS.
• Network I/O Traffic Management - более гибкое регулирование полосы пропускания сетевого взаимодействия виртуальных машин (в том числе сети VMotion, Fault Tolerance).
• VMware HA Healthcheck Status - автоматическая проверка работоспособности VMware HA, при этом в случае отклонения настроек кластера от требуемых выдается Alarm в VMware vCenter.
• Fault Tolerance (FT) Enhancements - теперь FT полностью интегрирован с VMware DRS, работает в кластерах EVC, а первичные и вторичные виртуальные машины корректно балансируются DRS. Кроме того, VMware FT может теперь работать без VMware HA.
• vCenter Converter Hyper-V Import - можно импортировать виртуальную машину на ESX с сервера Hyper-V
• DRS Virtual Machine Host Affinity Rules - возможность запрещать некоторые хосты к размещению на них ВМ. Пригодится для соблюдения лицензионной политики.
• Memory Compression - новый уровень абстракции оперативной памяти ВМ. Быстрее чем засвопированная на диск память, но медленнее, чем физическая.
• vMotion Enhancements - теперь VMotion работает быстрее (до 8 раз), и увеличено число одновременных миграций ВМ на хосте (с 4 до 8).
• 8GB Fibre Channel Support
• ESXi Active Directory Integration - теперь ESXi можно загнать в AD.
• Configuring USB Device Passthrough from an ESX/ESXi Host to a Virtual Machine - поддержка USB-устройств на хосте ESX / ESXi, пробрасываемых к виртуальной машине.
• User-configurable Number of Virtual CPUs per Virtual Socket - по-сути, многоядерные (не путать с многопроцессорными) виртуальные машины. Несколько виртуальных ядер в одном виртуальном vCPU.

Коллеги, после VMotion виртуальной машины на другой хост VMware ESX в vSphere я получил вот такое состояние работающей виртуальной машины, у которой справа от имени отображался статус Invalid. Кнопки выключения и редактирования свойств само собой загреены. Виртуальная машина продолжает прекрасно работать:

После недолгих изысканий была найдена статья KB "A virtual machine does not power on and displays in VMware Infrastructure Client as Invalid". Парадокс в том, что такое произошло с работающей виртуальной машиной на ESX, а KB про остановленную, которая при запуске выдает сообщение "A general system error occured: Not initialized". Эта ошибка говорит о том, что vmx-файл конфигурации виртуальной машины поврежден.

Итак, что нужно сделать, чтобы исправить статус Invalid у виртуальной машины:

О больших новых возможностях VMware vSphere / ESX 4 знают все, а вот знаете ли вы о новых маленьких приятных вещах для администраторов в vCenter и ESX?

Итак, что нового в VMware vSphere 4. Во-первых, это Storage View, где можно определить на каком типе СХД находится виртуальная машина, какие NAS-хранилища подключены к VMware ESX и т.п.

Во-вторых...
Таги: VMware, vSphere, ESX, vCenter, VMotion, Storage,

Компании VMware и Cisco работают над технологией Long Distance VMotion.

Как уже сообщалось на VM Guru, на предстоящем VMworld 2009 будет показана технология "горячей" миграции на большие расстояния Long Distance VMotion. Эта технология является ключевым аспектом концепции облачных вычислений (Cloud Computing) компани VMware, поскольку именно Long Distance VMotion будет являться основой распределения ресурсов между внутренним (Internal Cloud) и внешним (External Cloud) облаками. Концепция VMware отличается от концепции других вендоров - VMware считает, что должно быть внутреннее облако, а когда требуются срочно необходимые ресурсы, виртуальная машина может "переезжать" во внешнее облако для обеспечения заданных параметров SLA (соглашение об уровне сервиса)...

Таги: VMware, VMotion, Cisco, Cloud

Как работает Storage VMotion в VMware vSphere.

Одна из замечательных технологий, которая стала доступна из GUI в VMware vSphere, Storage VMotion позволяет перемещать хранилище виртуальной машины (ее виртуальные диски) на другой том VMFS / LUN без остановки работы служб и приложений.

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

Таги: VMware, vSphere, SVMotion, VMFS, VMotion

VMware VMotion падает на 90%.

Если при перемещении виртуальной машины между хостами VMware ESX средствами VMotion возникает такая ошибка для 64-битной гостевой ОС:

A general system error occurred: failed to resume on destination

Надо проверить, что Intel VT включена на целевом хосте в BIOS.
Таги: VMware, ESX, VMotion

Hyper-V подвергает риску приложения в виртуальных машинах при миграции (Quick Migration), а VMware VMotion - нет.

Как известно, возможности «быстрой» миграции гипервизора Hyper-V значительно уступают функциональности VMware VMotion. В очередной раз инженерами VMware было продемонстрировано как именно Hyper-V может аффектить приложения в виртуальной машине при миграции.

Суть опыта была такова: было 2 хоста Hyper-V, один с поддержкой инструкций SSE 4.1, другой - без. Виртуальную машину с запущенным Adobe Premier мигрировали между хостами Hyper-V. В результате, после миграции приложение «выполнило недопустимую операцию и было закрыто». После этого попробовали сделать VMotion – VMware ESX не позволил смигрировать виртуальную машину, сославшись на несовместимость процессоров.

Смотреть видео VMware...
Таги: VMware, VMotion, Hyper-V, Bugs

Полезные утилиты при управлении ESX Server - VMware CPU Host Info

Недавно обновилась еще одна полезная программа для определения совместимости процессоров серверов VMware ESX для VMotion в вашей виртуальной инфраструктуре.

VMware CPU Host Info

Скачиваем, устанавливаем, запускаем. Далее вводим параметры учетной записи VirtualCenter и получаем матрицу, в которой представлены возможности CPU серверов и их поддержка хостами ESX Server.
Таги: VMware, ESX, VMotion

VMware Storage VMotion: особенности работы и ограничения

Многие пользователи VMware Virtual Infrastructure 3.5 знают о возможности динамической миграции хранилищ виртуальных машин VMware Storage VMotion, позволяющей "на лету" перетаскивать виртуальные диски запущенных виртуальных машин между разными LUN.

Ниже приведем особенности использования данной технологии, которая может свести к 0 время запланированных простоев при обслуживании хранилищ.
Таги: VMware, ESX, VMotion, SVMotion, vStorage, Storage

Как проверить совместимость VMotion и влияет ли NX/XD bit?