Сравнение производительности гипервизоров: хорошо это или плохо? Какой выбрать гипервизор


как это работает / Хабрахабр

В последнее время наша компания разрабатывала детектор руткитов на базе аппаратной виртуализации. Проект задумывался с целью разобраться, как можно использовать новые возможности процессоров Intel и AMD для информационной безопасности. После нескольких итераций мы остановились на вполне работоспособном методе детектирования руткитов. О нем и пойдет речь. Метод основан на технологии аппаратной виртуализации памяти (англ. nested paging или hardware assisted paging, общепринятого русскоязычного термина нет). Эта технология появилась в последних моделях процессоров Intel и AMD. Версия Intel называется Intel Extended Page Table (EPT) и поддерживается процессорами начиная с семейства Nehalem (Intel Core i3, i5, i7). Аналог AMD называется AMD Rapid Virtualization Indexing (RVI) и присутствует на процессорах, начиная с поколения AMD K10. Технологии схожи, поэтому все, что описывается далее об Intel EPT, применимо и к AMD RVI.
Теория
Итак, у нас есть гипервизор и работающая под его контролем гостевая операционная система (гость).

Переход управления из гипервизора в гостевую ОС называется VM Entry, обратный переход – VM Exit. Вся работа – это последовательность VM Entry и VM Exit, сменяющих друг друга. Гипервизор работает в изолированном адресном пространстве и «невидим» со стороны гостевой ОС. При этом он может изменять состояние гостевой ОС (виртуальный процессор, память, виртуальное аппаратное обеспечение и т.д.).

Читателю есть смысл ознакомиться с нашей предыдущей статьей, где речь шла о методе, основанном на теневой таблице страниц (shadow paging). Описываемый здесь метод – дальнейшее логическое его развитие.

Аппаратная виртуализация памяти, в противовес программной виртуализации в shadow paging, резко упрощает гипервизор и, как следствие, делает его надежнее. Кроме того, значительно повышается производительность и снижается расход памяти.

При обычной работе процессора любое обращение к физическому адресу немедленно ведет к его выставлению на адресной шине процессора (кроме таких случаев, как обращение к APIC, но мы их опустим для простоты изложения). В случае с nested paging любое обращение гостя к физическому адресу (он получает название «гостевой физический адрес») сперва транслируется через специальную таблицу страниц. Физический адрес, полученный из гостевого физического адреса, выставляется на адресной шине, после чего происходит обращение к памяти.

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

Таблица страниц четырехуровневая и напоминает таблицу страниц для преобразования виртуальных адресов в 64-битном режиме Intel 64. Основное отличие – строение записей таблицы. На рисунке приведено строение записи для нижнего уровня таблицы (PTE):

Нас интересуют три младших бита записей, которые определяют доступ к физической памяти. Если сброшены биты R, W, X (биты 0...2), то доступ к описываемой PTE памяти соответственно на чтение, запись и исполнение вызывает выход в гипервизор (EPT Violation по терминологии Intel).

Это дает возможность контролировать исполнение кода на процессоре и записи в память c кодом.

Суть метода
Полная виртуализация не является в нашем случае целью. Для контроля над выполнением и модификацией кода нам достаточно виртуализировать память и процессор.

Для виртуализации памяти нам нужно построить таблицу страниц EPT с отображением гостевых физических адресов в реальные физические адреса «один в один» (identity mapping). При этом в записях на нижнем уровне таблицы (PTE) мы сбрасываем биты W и X. Каждая такая запись описывает доступ к странице памяти размером 4 КБ.

Далее возможны два варианта выхода в гипервизор (VM Exit) с EPT Violation:

  1. Доступ к странице памяти на запись. При этом происходит выход в гипервизор, после чего он разрешает запись в страницу (устанавливает бит W), но запрещает выполнение (сбрасывает бит X).
  2. Доступ к странице памяти на выполнение. При этом гипервизор разрешает выполнение на странице (устанавливает X), но запрещает запись в нее (сбрасывает W).

Таким образом, страница памяти может быть либо только исполняемой, либо только записываемой. Запись и исполнение соответственно влекут выход в гипервизор (VM Exit) и переводят страницу из одного состояния в другое.

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

Практическая реализация
Мы реализовали детектор руткитов Hypersight Rootkit Detector, использующий вышеописанный метод. Он спроектирован так, чтобы его можно было загружать и выгружать по запросу пользователя. Это позволяет использовать его совместно с программами виртуализации, такими как VMware и VirtualBox.

Наш детектор руткитов может обнаруживать следующую активность в ядре:

  • Попытки перехода в режим гипервизора.
  • Модификации управляющих регистров кодом вне ядра и HAL.
  • Модификации невыгружаемого кода ядра, HAL и драйверов в памяти, модификации SSDT. В том числе модификации путем отображения виртуальной памяти.
  • Выполнение кода за пределами исполняемых секций драйверов, ядра и HAL. Так называемый «скрытый код», козырная карта руткитов, теперь легко обнаруживается.
Падение производительности при включенном мониторинге – в пределах одного процента и практически незаметно «на глаз». Потребление памяти гипервизором – около 40 МБ для четырехъядерного процессора. Это дает возможность использования метода на компьютерах с памятью от 1 ГБ, предназначенных для офисных задач и разработки.
Дальнейшая работа
Возможности гипервизора не ограничиваются лишь детектированием руткитов. Возможно также и блокирование вредоносной активности. Мы ведем исследования в этой области и надеемся представить результаты в скором будущем. Также на повестке дня стоит портирование на 64-битную архитектуру и процессоры AMD RVI.
Заключение
В последнее время антивирусные компании обратили внимание на гипервизоры и стали нанимать их разработчиков. Однако стоит заметить, что разработка гипервизора «с нуля» – достаточно трудоемкий и дорогостоящий процесс, несмотря на кажущуюся внешнюю простоту. Наша компания может предложить свой опыт в этой области, а также работающее решение.
Литература
Документация по процессорам Intel: www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html

Документация по процессорам AMD: developer.amd.com/documentation/guides/Pages/default.aspx

habr.com

Сравнение производительности гипервизоров: хорошо это или плохо?

Существует множество «зависимых» и независимых тестов, проводимых для выяснения чьи же яйца кто все-таки быстрее. Однако, болезнь «зависимых» тестов, проводимых производителем гипервизора, – их возможная пристрастность. Болезнь независимых – неготовность к сравнению такого рода.Например, на следующем рисунке вы можете видеть загрузку процессора для гостевой и родительской (хоста )операционных систем в Hyper-V R2.Пример №2 – программа для тестирования производительности HDD – HDTune. Я считал ее вполне адекватной, пока не установил на свой ноутбук Sun VirtualBox. Показанная мне скорость (виртуального) жесткого диска превышала физическую в три раза.Другая ошибка, которую часто допускают при сравнении гипервизоров – неверные предпосылки. Как правило, авторы выбирают изолированный (standalone) хост для тестирования производительности с помощью как синтетических, так и реальных нагрузок. Планируется, что результаты теста будут очень интересовать клиентов из малого или среднего бизнеса, поскольку для уровня Enterprise более интересен именно функционал гипервизора. Так ли это?Допустим, я средний заказчик, имеющий 20 Windows Server на отдельных физических серверах и примерно 500 клиентских машин. Я думаю, что в 90% случаев такому заказчику вполне хватит трех физических серверов с двумя 4-ядерными процессорами Intel Xeon, 32 (если не 16) гигабайтами оперативной памяти и полки на двенадцать SAS-дисков 15k. Причем я вполне смогу выбрать для себя любой из гипервизоров и успешно реализовать на нем консолидацию серверов. По сути, выбор гипервизора в таких компаниях зачастую зависит от предпочтений системного администратора либо того, кто первым найдет общий язык с директором по ИТ. В результате мы видим, что для малого бизнеса функционал, как ни странно, важнее, чем большая производительность гипервизора.В то же время, крупным заказчикам жизненно необходимы такие технологии, как vMotion или Fault Tolerance. Необходимы, пожалуй, в большей степени чем большая производительность. Получается, что всем нужны технологии, а сравнивается обычно производительность 🙂Сравнивать гипервизоры по технологиям тоже не совсем корректно. Возьмем в пример тот же High Availability (высокая доступность виртуальных машин). Решение, доступное в бесплатном Hyper-V Server R2 и в платных Xen/vSphere. При этом, коллега Leo из солнечной Австралии делится, как настроить High Availability на БЕСПЛАТНЫХ ESXi.Давайте сравним Live Migration (перенос виртуальной машины на другой хост без ее остановки), который будет у Microsoft и уже есть у Citrix, VMware. Не буду говорить за Citrix, но у Microsoft есть значительное ограничение – хост может участвовать только в одном процессе Live Migration одновременно. Если у вас на хосте 30 виртуальных машин, процесс миграции затянется.Получается, производительность вообще никому не нужна, так? Нет не так. Например, Михаил Михеев приводит пример банка, консолидировавшего большую часть своих серверов. Его виртуальные машины генерируют нагрузку примерно в 30000 IOPS. Пусть я покажусь неграмотным, но представим, что каждая операция чтения/записи использует кусок данных в 16 килобайт. Требуемая пропускная способность в этом случае примерно 3,67 гигабит/сек. Как вы понимаете, еще нужно протестировать, какие гипервизоры и на каком оборудовании смогут выдавать столько IOPS.Другой пример – все хорошие функции платные и лицензируются либо по процессорам, либо по хостам. При лицензировании гостевых операционных систем Windows Server есть интересная возможность – покупая на физический сервер Windows Server Datacenter, вы можете запускать в виртуальной среде неограниченное количество виртуальных серверов. Соответственно, если у вас 600 виртуальных машин с Windows Server, то для вас есть разница, покупаете вы лицензии на 20 хостов или на 30. Даже если это 20 хостов vSphere Enterprise Plus или 30 хостов с XenServer Essentials, например (в обоих случаях рассматриваются 2-процессорные сервера). Кстати, в приведенном примере гипервизор VMware вроде бы получается дороже по лицензиям примерно на $16000. Но в итоге может оказаться дешевле за счет меньшего количества серверов!Какие же выводы можно сделать? Производительность важнее все-таки для средних/крупных клиентов. Мелким же интересен максимум функционала за минимум денег или лучшее соотношение цены/качества. А качественно сравнить функционал — это вам не попугаев мерить!

vmind.ru

Выбираем гипервизор

 Задача

  В один из моментов развития компания появилась задача одновременного поднятия пяти различных серверов с различным набором приложений и различными ОС. Какие то сервера уже существовали до этого момента, какие то ставились с нуля в силу необходимости, факт оставался фактом, сервера - нужны, и причем сервера которые  судя по всему в ближайшее время нагружены очень сильно по современным меркам не будут. Имеем два варианта выбора: купить 5 недорогих rack/tower серверов или купить один производительный сервер, установить на него гипервизор и поднять под ним сервера. Пришли к выводу что экономически целесообразнее второй вариант:Теперь решаем задачу какой гипервизор использовать. Для этого взяли три известных продукта: Citrix XenServer 6.0, VMware ESXi 5.0, Hyper-V Server 2008 R2 и протестировали их с помощью трех ОС:Все продукты тестировались как есть, без тюнинга систем и сборки узкозаточенных ядер. Задача стояла в том, чтобы выяснить какой продукт для нас предпочтительнее использовать, тонкие настройки и прочее будут позже. Мы не агитируем за использование того или иного решения, но настаиваем, чтобы когда вы делали свой выбор, вы прошли эти шаги сами и со своими условиями. Тесты не особо трудозатратные, требуют только определенного запаса во времени. Все продукты, в том числе и гипервизоры АБСОЛЮТНО БЕСПЛАТНЫ как для тестирования, так и для использования.

Окружение

  • Сервер: DL160
  • Гипервизоры:Citrix XenServer 6.0, VMware ESXi 5.0, Hyper-V Server 2008 R2
  • ОС: Linux Fedora 15, FreeBSD 8.2 i386, FreeBSD 8.2 amd64
  • Тестовая программа: UnixBench 5
  • Каждой гостевой системе выделялось: 2 процессорных ядра, 1 ГБ оперативной памяти, 100 ГБ дискового пространства

FreeBSD 8.2 amd64

Тест Citrix XenServer 6.0 VMware ESXi 5.0 Hyper-V Server 2008 R2
Dhrystone 2 using register variables (lps) 27826818.0 14233956.1 -
Double-Precision Whetstone (MWIPS) 5617.5 2847.2 -
Execl Throughput (lps) 1584.9 2354.8 -
File Copy 1024 bufsize 2000 maxblocks (KBps) 28934.5 45394.0 -
File Copy 256 bufsize 500 maxblocks (KBps) 12289.4 29638.9 -
File Copy 4096 bufsize 8000 maxblocks (KBps) 38708.0 89137.2 -
Pipe Throughput (lps) 2831366.1 1380266.4 -
Pipe-based Context Switching (lps) 339534.3 258037.7 -
Process Creation (lps) 3275.5 6673.1 -
Shell Scripts (1 concurrent) (lpm) 4616.8 443.3 -
Shell Scripts (8 concurrent) (lpm) 551.3 67.5 -
System Call Overhead (lps) 1922530.4 1165278.1 -
System Benchmarks Index Values
  BASELINE RESULT INDEX RESULT INDEX RESULT INDEX
Dhrystone 2 using register variables 116700.0  27826818.0   2384.5   14233956.1   1219.7  - -
Double-Precision Whetstone 55.0  5617.5   1021.4   2847.2   517.7  - -
Execl Throughput 43.0  1584.9   368.6   2354.8   547.6  - -
File Copy 1024 bufsize 2000 maxblocks 3960.0  28934.5   73.1   45394.0   114.6  - -
File Copy 256 bufsize 500 maxblocks 1655.0  12289.4   74.3   29638.9   179.1  - -
File Copy 4096 bufsize 8000 maxblocks 5800.0  38708.0   66.7   89137.2   153.7  - -
Pipe Throughput 12440.0  2831366.1   2276.0   1380266.4   1109.5  - -
Pipe-based Context Switching 4000.0  339534.3   848.8   258037.7   645.1  - -
Process Creation 126.0  3275.5   260.0   6673.1   529.6  - -
Shell Scripts (1 concurrent) 42.4  4616.8   1088.9   443.3   104.6  - -
Shell Scripts (8 concurrent) 6.0  551.3   918.8   67.5   112.5  - -
System Call Overhead 15000.0  1922530.4   1281.7   1165278.1   776.9  - -
Score 493.6 353.3 -

FreeBSD 8.2 i386

Тест Citrix XenServer 6.0 VMware ESXi 5.0 Hyper-V Server 2008 R2
Dhrystone 2 using register variables (lps) 9615658.3 9850225.0 9477838.2
Double-Precision Whetstone (MWIPS) 1878.9 1947.7 1862.1
Execl Throughput (lps) 1920.0 2082.3 2622.9
File Copy 1024 bufsize 2000 maxblocks (KBps) 134859.8 64569.5 33493.0
File Copy 256 bufsize 500 maxblocks (KBps) 76466.6 44704.9 40473.1
File Copy 4096 bufsize 8000 maxblocks (KBps) 48098.7 93736.8 36371.4
Pipe Throughput (lps) 956045.5 988610.6 991008.8
Pipe-based Context Switching (lps) 259850.3 266016.2 293947.2
Process Creation (lps) 5080.5 5893.8 9933.6
Shell Scripts (1 concurrent) (lpm) 4748.6 444.7 1753.5
Shell Scripts (8 concurrent) (lpm) 1040.9 54.2 253.8
System Call Overhead (lps) 556110.9 576492.0 585685.0
System Benchmarks Index Values
  BASELINE RESULT INDEX RESULT INDEX RESULT INDEX
Dhrystone 2 using register variables 116700.0  9615658.3   824.0   9850225.0   844.1   9477838.2   812.2 
Double-Precision Whetstone 55.0  1878.9   341.6   1947.7   354.1   1862.1   338.6 
Execl Throughput 43.0  1920.0   446.5   2082.3   484.2   2622.9   610.0 
File Copy 1024 bufsize 2000 maxblocks 3960.0  134859.8   340.6   64569.5   163.1   33493.0   84.6 
File Copy 256 bufsize 500 maxblocks 1655.0  76466.6   462.0   44704.9   270.1   40473.1   244.6 
File Copy 4096 bufsize 8000 maxblocks 5800.0  48098.7   82.9   93736.8   161.6   36371.4   62.7 
Pipe Throughput 12440.0  956045.5   768.5   988610.6   794.7   991008.8   796.6 
Pipe-based Context Switching 4000.0  259850.3   649.6   266016.2   665.0   293947.2   734.9 
Process Creation 126.0  5080.5   403.2   5893.8   467.8   9933.6   788.4 
Shell Scripts (1 concurrent) 42.4  4748.6   1120.0   444.7   104.9   1753.5   413.6 
Shell Scripts (8 concurrent) 6.0  1040.9   1734.8   54.2   90.3   253.8   423.0 
System Call Overhead 15000.0  556110.9   370.7   576492.0   384.3   585685.0   390.5 
Score 498.9 314.2 371.3

Linux Fedora 15

Тест Citrix XenServer 6.0 VMware ESXi 5.0 Hyper-V Server 2008 R2
Dhrystone 2 using register variables (lps) 14113056.3 14501636.6 13296297.1
Double-Precision Whetstone (MWIPS) 2360.1 2357.6 2206.6
Execl Throughput (lps) 1213.1 2002.6 805.5
File Copy 1024 bufsize 2000 maxblocks (KBps) 325306.0 321239.2 319335.1
File Copy 256 bufsize 500 maxblocks (KBps) 83834.4 85595.2 77606.0
File Copy 4096 bufsize 8000 maxblocks (KBps) 883735.8 1006921.4 841943.4
Pipe Throughput (lps) 521378.9 600665.9 542979.3
Pipe-based Context Switching (lps) 115997.2 126159.0 121250.5
Process Creation (lps) 3482.2 4862.6 3689.8
Shell Scripts (1 concurrent) (lpm) 2662.8 2723.8 1902.8
Shell Scripts (8 concurrent) (lpm) 770.2 773.0 708.5
System Call Overhead (lps) 607433.6 1380867.3 1255297.5
System Benchmarks Index Values
  BASELINE RESULT INDEX RESULT INDEX RESULT INDEX
Dhrystone 2 using register variables 116700.0  14113056.3   1209.3   14501636.6  1242.6    13296297.1   1139.4 
Double-Precision Whetstone 55.0  2360.1   429.1   2357.6   428.7   2206.6   401.2 
Execl Throughput 43.0  1213.1   282.1   2002.6   465.7   805.5   187.3 
File Copy 1024 bufsize 2000 maxblocks 3960.0  325306.0   821.5   321239.2   811.2   319335.1   806.4 
File Copy 256 bufsize 500 maxblocks 1655.0  83834.4   506.6   85595.2   517.2   77606.0   468.9 
File Copy 4096 bufsize 8000 maxblocks 5800.0  883735.8   1523.7   1006921.4   1736.1   841943.4   1451.6 
Pipe Throughput 12440.0  521378.9   419.1   600665.9   482.9   542979.3   436.5 
Pipe-based Context Switching 4000.0  115997.2   290.0   126159.0   315.4   121250.5   303.1 
Process Creation 126.0  3482.2   276.4   4862.6   385.9   3689.8   292.8 
Shell Scripts (1 concurrent) 42.4  2662.8   628.0   2723.8   642.4   1902.8   448.8 
Shell Scripts (8 concurrent) 6.0  770.2   1283.6   773.0   1288.3   708.5   1180.8 
System Call Overhead 15000.0  607433.6   405.0   1380867.3   920.6   1255297.5   836.9 
Score 563.2 669.4 552.4

Выводы:

Выводы для себя каждый сделает сам в зависимости от задачи, конкретно нам были интересны тесты в большей степени Dhrystone/Whetstone и скорости межпроцессного сообщения, свой выбор мы сделали. Подробнее о том что из себя представляет каждый тест описано тут: byte-unixbench и CSA. Из явных плюсов сразу бросающихся в глаза хотелось бы отметить: Citrix XEN - очень простая и удобная работа с NFS хранилищами, ESXi - удобный и информативный интерфейс управления и мониторинга, и огромный плюс Hyper-V - failover "из коробки и бесплатно", правда для этого придется поднимать контроллер домена если у вас его нету.

www.jitsys.ru

Что такое виртуализация, гипервизр, VMWare ESXi/Hypervisor - и как начать работать

Опубликовано ISSystems.kz

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

Гипервизор ( например, VMWare ESXi, VMware Hypervisor, Microsoft Hyper-V ) - такая хитрая прослойка между «железом» сервера ( аппаратным уровнем ) и уровнем операционых систем. Гипервизор обычно инсталлируется на голое железо сервера ( в этом случае он называется «bare metal»), а для операционных систем ( они в этом случае называются гостевыми ) эмулирует доступ к аппаратному серверу.

Бывают гипервизоры, которые работают как приложение на обычной операционной системе ( в этом случае он называется "hosted" и прослойка получается совсем не тонкая, а очень толстая, и виртуальные машины работают уже не на втором уровне, а на третьем от железа ).

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

Каждая гостевая ОС виртуализированного сервера будет считать что она одна такая, и никак не будет связана с другими виртуальными серверами, которые «крутятся» на том же физическом сервере ( кроме, естественно, как через Ethernet сеть ).

Гостевая ОС никак не сможет определить, работает ли она на физическом железе или на виртуальном ( кроме как по разбору МАК-адресов и ID устройств ).

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

Преимуществ у такого подхода ( виртуализации ) масса.

Например, ( «лежит на поверхности») , экономия на железе. Существует множество приложений, которые требуют под себя отдельный сервер ( не могут работать совместно с другими приложениями ), но при этом не загружают ресурсы сервера полностью ( VMWare называет цифру использования ресурсов 5-15% ) => можно на 1 физическом сервере разместить 5-10 виртуальных серверов.

Одновременное использование Linux, Windows и еще множества других ОС на одном физическом сервере.Решается проблема с устаревшими приложениями ( legacy applications ).

Поскольку получается, что «виртуальная машина» - это некий набор файлов, лежащий на диске, а гипервизоры, работающие на физическом железе предоставляют в виртуальное использование одинаковое «виртуальное железо», то отсюда следует далеко идущий вывод - следующее ( важнейшее ) преимущество:

Происходит полная «отвязка» от железа.- Если виртуальная машина – это «папка» файловой системы, то backup сервера превращается в копирование папки.- Если какому-то виртуальному серверу потребовалось больше ресурсов ( процессора, памяти, дисков ) – то для этого становится достаточным переместить мышкой ползунок.- Если же недостаточно ресурсов физического сервера – происходит простое копирование этой виртуальной машины на более мощное железо с гипервизором, и виртуальная машина поднимается на новом физическом железе, как на родном.- в случае полного выхода из строя аппаратного сервера поднять все сервисы на другом становится минутным делом.

И т.д. и т.п. –На основе этого фундамента – гипервизора – компания VMWare построила целое здание.

Теперь есть возможность- перемещать виртуальные машины между физическими серверами «на горячую», т.е. без перерыва в обслуживании- автоматически перераспределять ВМ между серверами по расписанию или по нагрузке- автоматически “поднимать” и “гасить” виртуальные машины, например, вслучае выхода из строя физического сервера- автоматически «гасить» ( например на ночь ) часть физических серверов с переносом виртуальных машин на другие физические серверы- организовывать кластеры ( fault tolerance ) для обеспечения непрерывности бизнеса- автоматически предоставлять виртуальные машины разработчикам без участия ИТИ т.п.

У VMWare есть конвертор, который умеет преобразовывать ( переносить ) ряд операционных систем, инсталлированных на физическом железе – в виртуальные машины.

Кроме серверов, VMWare аналогичным образом умеет виртуализировать системы хранения данных ( storage ), сети ( virtual network ).

Всё это у VMWare входит в линейку продуктов Vsphere. Эти функции и множество других покрываются различными продуктами из линейки vSphere – vCenter, vMotion, и т.п. ( см. http://www.vmware.com/ru/products/ ).

Продукты сгруппированы в выпуски, подходящие для предприятий различного размера –От VMware vSphere Essentials - до VMware vSphere Enterprise PlusСм. Подробнее тут - http://www.vmware.com/ru/products/vsphere/editions.html

На основе виртуализированных дата-центров можно строить "облачные" инфраструктуры - частные, общественные или гибридные облака. Инструмент VMware для построения и управления облачными инфраструктурами - VMware vCloud.

Вообще абсолютно всеми продуктами VMWare можно воспользоваться в триальном режиме ( 60 дней с полным функционалом ), зарегистрировавшись и скачав их с сайта. При скачивании они там дают ( показывают ) ключи, которые понадобятся для тральной активизации продукта. Позже, если клиент примет решение о покупке, достаточно будет ввести купленный ключ, сохранив все настройки продукта. Триальный ключ клиенту может предоставить партнёр.

На сайте VMWare очень хорошо расписаны основы виртуализации - http://www.vmware.com/ru/virtualization/

Подробнее о гипервизоре ESXi – тут - http://www.vmware.com/products/esxi/

Управлять гипервизорами ESX можно с помощью бесплатного ПО «VMware vSphere Client», его можно скачать по ссылке с установленного гипервизора.

Как устанавливать ESXi, как настраивать  и как им управлять – хорошо расписано тут – http://www.vmgu.ru/articles/vmware-esxi-4-vsphere-setup.

Ещё к продуктам VMWare существует множество платных и бесплатных дополнений/утилит сторонних расзработчиков.

Например, бесплатные можно посмотреть тут - http://www.vmgu.ru/articles/vmware-vsphere-esx-free-4.

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

Обращайтесь.

www.issystems.kz