Общее у всех этих продуктов - то, что они лицензируются не на базе процессоров (как vSphere), а на базе виртуальных машин. Эта особенность, с одной стороны, как бы ближе к облачной концепции - типа нам не важно где и как работают виртуальные машины, а важно сколько сервисов мы используем, соответственно, за них и платим.
Но с другой стороны, с этим возникают специфические проблемы, на которые обратили внимание в блоге компании VKernel. Суть проблем такова:
Когда организация использует модель лицензирования по физическим процессорам, ее основная цель - достичь максимальной консолидации виртуальных машин на хосте, поскольку она платит за инфраструктурные составляющие (стойки, питание, охлаждение, площади), а также за весьма недешевые лицензии на продукты для виртуализации. А вот когда лицензируются виртуальные машины - увеличение коэффициента консолидации не сказывается на стоимости лицензий, а значит нет и соответствующей мотивации у администраторов и менеджеров датацентра.
Когда используется лицензирование по числу виртуальных машин - это очень сложно учитывать. Виртуальные машины постоянно создаются, удаляются, развертываются в тестовых целях и забываются. Учитывать число лицензий в таких окружениях очень сложно и затратно.
Также автор обратил внимание на проблему, изложенную на одной из веток комьюнити, где у человека возникли проблемы с применением продукта CapacityIQ - он пытался строить отчеты о емкостях инфраструктуры не для всех виртуальных машин (поскольку некоторые не должны влиять на ее будущее состояние). Но оказалось в продукте нет такой возможности - он собирает информацию со всего окружения vCenter и нам рекомендуют лицензировать виртуальных машин столько, сколько нам реально нужно в анализе. Однако это очень неформализованное правило, которое нельзя отразить в EULA.
То есть, в данном случае совсем непонятно, какие виртуальные машины нам надо лицензировать (если она работает раз в году - надо?). Подобные проблемы в будущем будут возникать и в других продуктах (просто вышеозначенные - пока весьма не распространены). А это плохо, вот.
Компания VMware сделала очередной документ по сравнению своей платформы виртуализации VMware vSphere 4.1 с ближайшими конкурентами Microsoft Hyper-V R2 SP1 и Citrix XenServer 5.6 FP2 (то есть, с самыми последними релизными версиями вышеозначенных продуктов на сегодняшний день).
Мы представляем его адаптированную версию (кликабельно):
Надо сказать, что при всей необъективности подобных сравнений, они все же несут некоторую пользу. С помощью таких табличек удобно устраивать дискуссию со сторонниками и противниками тех или иных продуктов и технологий виртуализации. Они позволяют держать ключевые пункты в голове и на столе.
Кстати, обратите внимание, что появились новые пункты про облачные вычисления и IaaS. С Citrix OpenCloud, про который мы недавно писали, еще ничего не ясно.
В продолжение темы "Как сбросить пароль root на VMware ESX". У Dave Mishchenko есть отличная инструкция о том, как сбросить пароль пользователя root на хосте VMware ESXi в том случае, если вы его потеряли, забыли или съели. Работает эта инструкция и для VMware ESXi 4.1 (а также 4.0 и даже 3.5). Переведем ее вкратце.
1. Допустим хост VMware ESXi у вас сейчас работает и вы можете выполнять на нем команды локально или по SSH. Тогда имеет смысл выполнить команду:
cat /etc/shadow
Видим картинку с хэшем пароля рута:
Хэш пароля - это то, что написано после root : до следующего двоеточия (само двоеточие не включается). Хэш этот нужно записать на случай, если его понадобится восстановить назад.
2. Дальше нужен какой-нибудь Linux live CD. Предлагается использовать Slax Linux Live CD.
Далее просматриваем смонтированные разделы сервера ESXi командами:
fdisk -l (смотрим подходящие FAT16 разделы, где у нас размещен загрузчик)
ls -l /mnt/sda5/ (основной, при загрузке монтируется как /bootbank)
ls -l /mnt/sda6/ (резервный, при загрузке монтируется как /altbootbank)
В случае чистой установки ESXi, картина будет такова:
Нас интересует файл state.tgz - там все, что нам нужно. Если у вас ESXi Embedded то нужен файл local.tgz (который в первом случае находится внутри state.tgz).
Распаковываем сначала state.tgz, а потом local.tgz командами gzip и tar во временную директорию. Далее заходим в ней в папку /etc и открываем в ней файл shadow командой:
vi shadow
У вас откроется что-то вроде того:
Теперь посмотрите на картинку ниже, мы удаляем хэш пароля из этого файла:
То есть убираем все то, что между двумя двоеточиями. Выходим из файла, сохранившись.
Теперь все это упаковываем назад, для чего во временной папке (туда надо подняться из /etc) выполняем такую команду (апдейтим архив изменившейся папкой):
tar -czvf local.tgz etc
Если вы используете ESXi Embedded - кладете файл local.tgz на место, откуда брали. Если обычный ESXi - снова апдейтим архив:
tar -czvf state.tgz local.tgz
И также копируем туда, где он лежит:
Перезагружаем сервер и уже загружаемся в VMware ESXi. Видим такую картинку:
Это значит - все получилось. Теперь можем заходить в консоль под пользователем root с пустым паролем. Вот такой незамысловатый способ сброса пароля на хосте VMware ESXi.
Те, кто увлекается разработкой сценариев на PowerShell на фреймоврке PowerCLI, наверное помнят про бесплатную раздачу постеров на блоге VMware. Тогда не все успели забрать свой постер.
Сейчас они пишут, что раздача закончена. Но не беда - вы без проблем можете забрать свой постер по PowerCLI по этой ссылке. А вот еще версия для распечатки на листах А4.
Примите участие в форуме VMware, чтобы узнать, каким образом компания VMware, международный лидер в области виртуализации и облачной инфраструктуры, и наши партнеры предоставляют решения для облачной инфраструктуры и управления, которые значительно снижают сложность ИТ-среды, повышают уровень безопасности и ускоряют процессы создания, развертывания и запуска приложений.
Я уже, наверное, набил вам оскомину, но снова повторюсь - в версии VMware vSphere 5, которая выйдет в августе-сентябре (в подтверждение этому - посмотрите на книжку на Amazon, которая выходит 7 сентября), уже не будет платформы виртуализации VMware ESX. Останется только "тонкая" платформа VMware ESXi. Поэтому всем организациям необходимо планировать миграцию с ESX на ESXi. Об этом у нас есть серия постов:
В нем нам рассказывают о том, как нужно управлять виртуальной инфраструктурой VMware vSphere на базе VMware ESXi, и какие методики используются в сравнении с моделью управления на классическом ESX:
Для готовящихся к миграции и имеющих различные скрипты и агентов в сервисной консоли серверов ESX - читать обязательно.
На сайте проекта VMware Labs (о котором мы уже писали), появилась утилита для сохранения иерархии объектов и их конфигурации на VMware vCenter под названием VMware InventorySnapshot.
С помощью InventorySnapshot можно сохранить иерархию и параметры: папок датацентра (Datacenter folders), сами датацентры (datacenters), кластеры VMware HA/DRS и их настройки, пулы ресурсов (resource pools), виртуальные приложения (vApp), иерархию объектов, роли и пермиссии, а также настраиваемые поля объектов (custom fields).
Далее на основании снапшота генерируется PowerCLI скрипт, который потом можно выполнить на любом другом окружении vCenter. Это полезно, например, когда у вас есть тестовое окружение, конфигурацию которого вы хотите перенести в производственную среду на другом vCenter (вручную делать это может оказаться слишком нудным).
Как вы уже знаете, VMware vSphere 5 будет уже только на базе гипервизора ESXi, а выпуск продукта ESX прекращается (версия 4.1 - последняя на базе этой платформы). Поэтому тем, кто еще не перешел на VMware ESXi нужно задумываться о миграции.
Мы уже писали на тему того, как перейти с ESX на ESXi (тут, тут и тут), а сегодня расскажем в общих чертах о плане миграции таких хост-серверов и о том, что делать после установки нового ESXi (пост-миграционные процедуры).
Мы уже писали о семействе продуктов VMware vShield, которые позволяют организовать защиту вашего виртуального датацентра на базе VMware vSphere (еще и тут). Повторим вкратце:
vShield Endpoint - это мидлваре (то есть, само по себе для пользователя ничего не делающее ПО), которое построено поверх VMsafe API и позволяет сторонним производителям антивирусов интегрироваться с инфраструктурой виртуализации VMware vSphere.
vShield App - думайте об этом компоненте как о виртуальном распределенном коммутаторе (dvSwitch) с логикой фаервола с неограниченным количеством портов.
vShield Edge - это продукт для комплексной защиты периметра датацентра. Это уже более глобальный продукт, он включает в себя такие сервисы как Stateful firewall, VPN, DHCP, NAT, Web Load Balancing и другое. Он интегрируется с vCloud Director.
Есть еще vShield Zones, который идет в комплекте с изданиями vShphere, начиная с редакции Advanced. Это урезанная версия vShiled App.
Наши зарубежные коллеги затронули тему - а с какими же изданиями и версиями vSphere работают эти продукты? Тем более, что в документации об этом нигде не говорится.
Ситуация такова:
vShield Zones работает с vSphere 4.0 и более позними версиями, начиная с редакции Advanced (то есть, плюс Enterprise и Enterprise Plus).
vShield Endpoint работает только с vSphere 4.1 и выше, начиная с редакции Essentials Plus (то есть, еще и от Standard до Enterprise Plus).
vShield App работает, начиная с vSphere 4.0 и выше, с редакции Essentials Plus (то есть, еще и от Standard до Enterprise Plus). Несмотря на то, что Zones (работающий, начиная с Advanced) является частью App, все равно последний работает на младших изданиях vSphere.
vShield Edge работает, начиная с vSphere 4.0 и выше, с редакции Essentials Plus.
Поэтому в пролете от vShield остается только издание VMware vSphere Essentials.
Это, по-сути, средство сбора отчетности о виртуальной инфраструктуре VMware vSphere и виртуальных машинах, что-то вроде бесплатного Veeam Reporter Free.
В категории Performance мы можем увидеть следующую информацию:
Host/VM Utilization Heat Map - в этой категории представлены хосты и виртуальные машины с наибольшей загрузкой вычислительных ресурсов. Весьма полезно для развертывания новых ВМ.
Host Top CPU Ready Queue - параметры метрики производительности CPU Ready. Подробнее об этом счетчике тут.
Storage Access IOPS - здесь мы видим нагрузку на виртуальные хранилища по IOPs (на и из Datastore).
В категории Efficiency мы можем увидеть следующую информацию:
VM Over/Under Provisioning - показывает недогруз или перегруз по ресурсам для виртуальных машин на хост-серверах.
Storage Wasted Allocations - ранжированно показывает, где у нас на хранилище лежит непойми что (не относящееся к ВМ) и их недозаполненность.
Storage Allocated to Dormant VMs - показывает какие ВМ не используются и сколько выделено под них хранилища.
VM Rightsizing Recommendations - показывает рекомендации по сайзингу ВМ с точки зрения производительности (типа добавить или удалить vCPU).
Но этот продукт для небольшой инфраструктуры, а нормальные пацаны с табуном серверов ESX / ESXi скачивают и покупают продукт Veeam Reporter, который позволяет вести трекинг изменений виртуальной инфраструктуры VMware vSphere и получать отчетность обо всех ее аспектах. Тем более, что недавно вышел бесплатный аддон к нему - Capacity Planning Report pack for Veeam Reporter.
Скачать же бесплатный VMTurbo Performance and Efficiency Reporter можно по этой ссылке.
Нам подсказывают интересную утилиту - ThinApp Browser 1.4, которая позволяет с помощью графического интерфейса редактировать проект виртуализованного приложения VMware ThinApp:
Есть небольшое обзорное видео продукта:
Основные возможности ThinApp Browser 1.4:
Управление составом файлов и конфигурацией проекта VMware ThinApp (реестр и файлы приложения и системы)
Создание App-Links из графического интерфейса
Редактирование ini-файлов пакета (package.ini и attributes.ini)
Миграция virtual-to-physical для уже виртуализованного приложения
Опции по развертыванию виртуализованного приложения ThinApp
Утилита окажется весьма полезной всем тем, кто часто работает с проектами виртуализованных приложений VMware ThinApp. Скачать ThinApp Browser 1.4 можно по этой ссылке.
Как вы знаете, VMware vSphere 5 будет построена только на базе гипервизора VMware ESXi (а ESX больше не будет) и выйдет уже в этом году, поэтому мы публикуем серию заметок о том, как перейти на ESXi с ESX (вот тут - раз и два).
Сегодня мы поговорим о таком различии, как Scratch Partition в ESXi. Scratch Partition - это специальный раздел на хранилище для хост-сервера, который не обязательно, но рекомендуется создавать. Он хранит в себе различную временную информацию для ESXi, как то: логи Syslog'а, вывод команды vm-support (для отправки данных в службу поддержки VMware) и userworld swapfile (когда он включен). Он создается, начиная с vSphere 4.1 Update 1 автоматически, и, если есть возможность, на локальном диске.
Так как данный раздел является необязательным, то в случае его отсутствия вся перечисленная информация хранится на ramdisk хост-сервера (который, кстати, отъедает память - 512 MB). И, так как это ramsidk, после перезагрузки эта информация (если у вас нет scratch partition) очищается. Поэтому неплохо бы этот раздел, все-таки, создать.
По умолчанию, этот раздел создается в системе vfat и составляет 4 ГБ. Это много. Почему так много? Объяснение такое, что местечко оставлено под будущие версии ESXi. Этот раздел может размещаться локально или на SAN-хранилище. При этом его могут использовать несколько хостов ESXi одновременно, поэтому рекомендуется сделать его гигов 20. Но для каждого должна быть своя locker-директория на этом разделе.
Через vSphere Client scratch partition настраивается так:
Соединяемся с хостом ESXi из vSphere Client.
Переходим на вкладку Configuration.
Переходим в категорию Storage.
Нажимаем правой кнопкой на datastore и выбираем Browse.
Создаем уникальную директорию для хоста ESXi (например, .locker-ESXiHostname)
Закрываем Datastore Browser.
Переходим в категорию Software.
Нажимаем Advanced Settings.
Переходим в раздел ScratchConfig.
Устанавливаем в качестве значения ScratchConfig.ConfiguredScratchLocation директорию, которую только что создали, например:
/vmfs/volumes/DatastoreName/.locker-ESXiHostname
Нажимаем OK.
Перезагружаем ESXi.
Все это можно настроить и при автоматизированном развертывании VMware ESXi через kickstart. А можно и через vCLI и PowerCLI. О том, как это сделать, читайте в KB 1033696.
Лондон, 4 мая 2011 г. ? Компания VMware, мировой лидер в области виртуализации и облачных вычислений, опубликовала результаты комплексного исследования, рассматривающего распространение облачных вычислений среди предприятий малого и среднего бизнеса в Европе.
Слышали про такую проблему VDI Boot Storm? Вот у вас есть инсталляция системы виртуализации корпоративных ПК предприятия (например, на базе VMware View 4.x) на несколько десятков или даже сотен пользователей виртуальных ПК. В 8:00 у вас начинается рабочий день - пользователи приходят за свои рабочие места и одновременно включают свои виртуальные десктопы. В результате возникает серьезная нагрузка на систему хранения, где эти самые образы виртуальных ПК хранятся (десятки, сотни машин на сторадже).
И получается вот такой VDI Boot Storm - машины тормозят, сессии отваливаются, пользователи жалуются. Ведь при загрузке Windows 7 генерирует где-то 50-100 IOPS, а при обычной офисной работе это значение составляет 5-15 IOPS. Наглядно это выглядит так:
Что же делать с этим VDI boot storm?
Ну, во-первых, вы должны это обязательно учитывать при планировании развертывания инфраструктуры виртуальных ПК. Ваша инфраструктура хранения FC или iSCSI должна учитывать такие пиковые нагрузки, и начало рабочего дня - отличный способ это проверить. Есть также вот инструмент VDI Sizing Tool (VST) от нашего соотечественника, который позволяет мерить нагрузку для VDI-сценариев.
Во-вторых, SSD-диски. Да, дорого. Но иногда без них нельзя. Если вы используете VMware View с функциональностью View Composer для создания связанных клонов виртуальных ПК на основе базового образа - вам поможет концепция ярусного хранения данных, реализованная в продукте. На быстрые SSD-накопители можно помещать реплики пулов виртуальных ПК и Disposable-диски виртуальных машин. Сравните 150-200 IOPS у SAS-дисков с 5000 у SSD.
В-третьих, есть специализированные решения, такие как, например, NSS SAN Accelerator for VMware View. Эта штука представляет собой железку с SSD-дисками, которая ставится между хост-серверами VMware ESX / ESXi и системой хранения. Она умеет автоматически кэшировать наиболее часто используемые блоки и выравнивать нагрузку по хост-серверам.
В четвертых, есть мысль, что перед тем, как пользователь пришел на работу, его виртуальный ПК уже должен быть готов к работе и запущен. Мысль самая разумная, но почему-то нормальная настройка этого механизма в VMware View отсутствует. Вроде как даже из интерфейса View 4.5 убрали шедулинг запуска виртуальных ПК. А какого-то централизованного механизма вроде нет. Или есть? Может вы подскажете?
Мы уже много писали о таком документе как VMware vSphere Security Hardening (есть также и версия для VMware View), который описывает основные принципы и приемы обеспечения информационной безопасности VMware vSphere и виртуальных машин (без учета гостевых ОС).
Так вот, недавно компания VMware выпустила бесплатный продукт "VMware Compliance Checker for vSphere", который и проверяет вашу виртуальную инфраструктуру VMware vSphere на соответствие требованиям данного документа.
Основные возможности VMware Compliance Checker for vSphere:
Проверка соответствия нескольких серверов VMware ESX / ESXi в рамках одной сессии (поддерживается только соединение с vCenter).
Сканируются не только хост-серверы, но и vmx-параметры виртуальных машин.
Основан на VMware vSphere Security Hardening.
После того как обследование запущено, можно посмотреть пункты по виртуальным машинам и по типу категории обследования
Ну а теперь самое главное - у российской компании "Код Безопасности" есть бесплатный продукт vGate Compliance Checker, который не только объединяет в себе возможности сканирования виртуальной инфраструктуры на соответствие обоим видам требований по безопасности (Security Hardening и PCI DSS), но и поддерживает сканирование по различным версиям этих стандартов и руководящих документов. То есть, он круче, чем VMware Compliance Checker for vSphere.
Напоминаю, что будущая версия VMware vSphere 5, которая уже выйдет в этом году, будет полностью основана на "тонком" гипервизоре VMware ESXi и не будет иметь в своем составе платформы ESX. То есть, вам всем уже нужно готовиться к переходу на ESXi и все новые инсталляции компания VMware рекомендует делать именно на базе этой платформы.
Для многих администраторов, управляющих решением для виртуализации настольных ПК предприятия VMware View, могут оказаться полезными таблицы используемых различными компонентами View портов. Таблицы подготовил Christoph Harding, работник VMware и автор блога That's my View, на основе следующих документов:
На сайте проекта VMware Labs (о котором мы уже писали) появился новый интересный продукт - VMware PXE Manager for vCenter. Продукт позволяет настроить автоматизированное развертывание серверов VMware ESXi в виртуальной инфраструктуре.
Основные возможности VMware PXE Manager for vCenter:
Автоматизированное развертывание stateless и stateful хостов ESXi (без поддержки ESX)
Резервное копирование состояния ESXi (firmware), а также восстановление и архивирование в соответствии с политиками
Управление репозиториями билдов ESXi (stateless и statefull)
Управление патчами ESXi
Поддержка нескольких серверов vCenter
Поддержка сложных сетевых конфигураций за счет агентов (позже будет готов виртуальный модуль на базе Linux CentOS, который будет отвечать за развертывание хостов ESXi в своем сегменте датацентра)
Поддержка технологии WoL (Wake on Lan)
Выполнение тестирования памяти хостов ESXi (memtest)
Наличие плагина к vCenter
Развертывание систем в VMware Cloud Director напрямую
Развертывание серверов ESXi на блейд-системах Cisco UCS
Как обещают, эта утилита будет включена в состав платформы VMware vSphere 5. Сам PXE Manager состоит из нескольких компонентов (как и, например, Update Manager) - сервера, устанавливаемого на vCenter, и плагина к vSphere Client. Кроме того, в дочерних датацентрах (например, логических, под управлением Cloud Director) могут быть PXE-агенты в виде виртуальных модулей (это появится позже):
Обзорное видео по установке продукта:
Скачать VMware PXE Manager for vCenter можно по этой ссылке.
В новой версии появилось несколько дополнительных возможностей и параметров поиска по конфигурациям виртуальных систем. Кроме того, появился раздел VMware Aware Storage APIs (VASA, или он же VMware vStorage APIs for Storage Awareness), в котором можно будет найти информацию о поддержке данной технологии, связанной с интеграцией дисковых массивов с vCenter на платформе vSphere (это появится в пятой версии и может оказаться полезным для балансировки нагрузки на системы хранения Storage DRS).
Развитие информационных технологий часто ставит заказчиков перед непростым выбором. С одной стороны производители и поставщики предлагают потребителям повысить эффективность собственной ИТ-инфраструктуры, увеличить ее производительность и снизить расходы на эксплуатацию. С другой стороны провайдеры услуг утверждают, что уже сегодня можно отказаться от инвестиций в оборудование и ПО, выводя ИТ в аутсорсинг.
Не требуется никакого дополнительного ПО (виртуальные модули, VMware Mobile Access и т.п.). vmwClient соединяется с серверами VMware vSphere и vCenter напрямую как и vSphere Client.
Вменяемый и удобный интерфейс
Одновременное управление несколькими серверами vCenter и отдельными хостами ESX / ESXi. Не требуется logout при переключении к другому хосту.
vmwClient может хранить аккаунты для нескольких хостов и их настройки.
Клиент загружает только необходимую информацию из Inventory серверов vCenter или ESX / ESXi - что не требует большого объема трафика, передаваемого по сетям GPRS/3G/WCDMA.
Продукт развивается и постоянно обрастает функционалом.
Какие операции поддерживаются в vmwClient для работы с виртуальными машинами и хост-серверами:
Простейшие операции с хостами и ВМ: start, stop, reset, summary и т.п.
Просмотр событий (events) для объектов, просматриваемых в настоящий момент.
Как мы уже неоднократно писали, следующая версия платформы виртуализации VMware vSphere 5, которая выйдет в этом году, будет поставляться только на базе гипервизора VMware ESXi. Это означает, что всем пользователям VMware vSphere, которые работают с VMware ESX (а таких большинство), нужно уже сейчас задуматься о переходе на продукт ESXi.
Когда вышла VMware vSphere 4.1 в Release Notes мы могли прочитать подтверждение данного факта:
VMware vSphere 4.1 and its subsequent update and patch releases are the last releases to include both ESX and ESXi hypervisor architectures. Future major releases of VMware vSphere will include only the VMware ESXi architecture.
Сегодня мы поговорим о том, что нужно учитывать при неизбежной миграции на VMware ESXi c ESX, и почему можно сказать, что этот переход не будет особо болезненным. Для начала нужно посетить ресурс по переходу на ESXi на сайте VMware. Там есть много интересного, а в частности ESXi 4.1 migration guide, в котором описаны тонкости процесса миграции.
Если вы не хотите читать этот огромный 13-страничный гайд, то есть небольшая выжимка в виде презентации "Transitioning to the ESXi Hypervisor", где можно найти много полезной информации.
В частности, у каждого аспекта управления в VMware ESX есть свой аналог в VMware ESXi, совокупность которых справляется со всеми задачами, присутствующими в виртуальной инфраструктуре vSphere:
Кстати интересная фраза (август, 2010): "VMware users should put a plan in place to migrate to ESXi during the next 12 to 18 months".
Теперь вместо агентов в гостевой ОС (ESX), у нас есть партнерские модули Common Information Model (CIM) в ESXi:
В версии VMware ESX / ESXi 4.1 компания VMware свела различия в функциональности двух платформ к минимуму (красным выделено появившееся в 4.1):
Для диагностики и решения проблем у нас есть куча локальных и удаленных интерфейсов в ESXi. Tech Support Mode также поддерживается локально и по SSH, что делает настройку ESXi простым делом:
Через клиента vSphere Client или браузер мы проводим стандартные операции, в DCUI лезем, если что-то зависло, а TSM используем для глубокого копания.
К файлам настройки на ESXi мы можем ходить через браузер:
И к лог-файлам тоже:
Ну, то есть в ESXi есть то же, что и в ESX - поэтому переходить можно смело:
И, напоследок, для всех тех, кто хотел узнать, что за продукт такой vSphere Hypervizor:
VMware vSphere Hypervisor is the new name for what was formerly known as VMware ESXi Single Server or free ESXi (often abbreviated to simply “VMware ESXi”)
Автор сайта vdi-sizing.com, Василий, прислал нам ссылку на свою утилиту VDI Sizing Tool (VST), которая позволяет тестировать производительность и возможности консолидации виртуальных ПК (например, VMware View 4.x).
Эта утилита имитирует пользовательскую нагрузку в виртуальных ПК и измеряет время различных событий (старт приложений, создание RDP-сессии и т.д.), по результатам чего можно принять решение о выборе необходимого решения для виртуализации настольных ПК (сейчас их несколько, наиболее популярные - VMware View и Citrix XenDesktop).
VDI Sizing Tool содержит два компонента - user workload и loadmaster. User workload запускается в каждом тестируемом виртуальном ПК и симулирует обычные пользовательские действия - открытие документов MS Office, работу в браузере и т.п.
Loadmaster - запускается на стороне клиента виртуального ПК (например, там, где установлен VMware View Client) и тестирует соединение по RDP: собирает информацию о производительности при удаленной работе (latency), а также контролирует работу агентов LoadSlave, если используется мультиклиентное тестирование (в целях повышения объективности результатов).
Интересно, что в разделе Download можно найти документ "Sample measurements", где приведены результаты работы программы.
А в следующей версии VST автор обещает нам новые возможности:
Поддержка новых приложений в качестве нагрузки: PDF viewers, archivers и т.п.
Workload customization
Счетчики и метрики производительности для популярных VDI-решений: VMware, Microsoft и Citrix
Автоматизация развертывания виртуальных ПК (клонирование виртуальных машин и т.п.)
Скачать VDI Sizing Tool можно по этой ссылке. Можете в комментариях позадавать автору вопросы - я думаю, он постарается ответить.
Как вы знаете, в платформе виртуализации 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 доводится до конца. То есть, через этот буферный файл (несколько мегабайт) происходит обмен страницами между хостами в случае недоступности сети или высокоинтенсивной нагрузки. Естественно это все заметно влияет на производительность ВМ во время миграции, так как время доступа к памяти сильно увеличивается, зато все отрабатывает надежно.
Иногда бывает полезно произвести монтирование CD-ROM к консоли сервера VMware ESXi, но традиционные средства для монтирования CD-ROM в ESXi не работают. Этот трюк был обнаружен в блоге virtuallyGhetto. Он работает только для VMware ESXi 4.1 и более поздних версий, поскольку там появился модуль VMKernel iso9660.
Для начала загружаем данный модуль командой консоли:
vmkload_mod iso9660
Этот модуль поддерживает процедуры mount и unmount. Вы увидите вот такой результат:
Теперь нужно идентифицировать, какое из устройств ESXi есть ваш CD-ROM. Для этого выполняем команду:
esxcfg-mpath -b | grep "CD-ROM"
Вы увидите что-то подобное:
Нам нужен выделенный идентификатор для использования команды mount.
Теперь проверяем возможность монтирования CD-ROM в консоли командой:
vsish -e set /vmkModules/iso9660/mount mpx.vmhba32:C0:T0:L0
Если вывод команды отсутствует - значит все в порядке, модуль успешно загружен и CD-ROM смонтирован. Если не в порядке - вы увидите сообщение об ошибки синтаксиса команды.
После этого CD-ROM будет автоматически смонтирован по следующему пути: /vmfs/volumes/mpx.*
Kenny Coleman, один из блоггеров, пишущий о виртуализации VMware, выпустил пакет утилит для администраторов виртуальной инфраструктуры vSphere / ESX под названием VM Advanced ISO. Пакет содержит в себе набор необходимых программ для рутинных задач с виртуальными машинами:
Утилиты 1 - P2V Clean-up
01 - Resolution Resize (меняем разрешение гостевой ОС)
02 - HP ProLiant Cleaner (вычищаем софт HP после миграции в ВМ)
RSS
