Для мониторинга инфраструктуры виртуализации VMware vSphere зачастую используется протокол SNMP (например, через серверы Open NMS , CACTI , PRTG и т.п.). До версии VMware vSphere 5.1 поддерживались только версии 1 и 2 протокола SNMP. С выпуском версии 5.1 была добавлена поддержка третьей версии этого протокола (SNMPv3), который имеет множество улучшений, в основном касающихся безопасности.
Также в процессе настройки SNMP на хостах ESXi можно выбрать способ приема агентом сообщений: от IPMI-сенсоров (как в прошлых версиях ESXi) или CIM-индикаторов. Кроме того, можно фильтровать отсылаемые на сервер мониторинга SNMP-сообщения.
Для настройки протокола SNMP версий 1 и 2 нужно сделать 4 простых шага:
1. Установить community string (по сути, это пароль) командой:
esxcli system snmp set –communities public
2. Установить сервер мониторинга (SNMP target), который включает адрес и порт, а также community string:
esxcli system snmp set –targets server.domain@161/public
3. Включить сервис SNMP на хосте ESXi:
esxcli system snmp set –enable true
4. Протестировать конфигурацию:
esxcli system snmp test
Для того, чтобы протестировать SNMP со стороны таргета можно использовать команду (для версии 2):
snmpwalk -v2c -c public esxserver.domain
Для настройки протокола SNMP версии 3 нужно сделать 8 шагов (не все обязательны):
1. Выставляем Engine ID для SNMP-агента (ID - это шестнадцатиричное значение от 5 до 32-х разрядов длиной):
esxcli system snmp set –engineid 766d77617265
2. Выставляем протокол аутентификации (SHA1, MD5 или none):
esxcli system snmp set –authentication SHA1
3. Устанавливаем протокол шифрования:
esxcli system snmp set –privacy AES128
4. Если мы включили протоколы шифрования в шагах выше, то нужно сгенерировать хэши для паролей аутентификации и шифрования (опция -r означает, что пароли вводятся прямо в команде):
esxcli system snmp hash -r -A pass1 -X pass2
5. Настраиваем пользователя SNMP, указывая хэши, полученные в предыдущей команде (user - ваш пользователь):
esxcli system snmp set –users user/f9f7311379046ebcb5d134439ee5b7754da8a90f/d300f16eec59fb3b7ada7844ff764cbf4641fe5f/priv
6. Устанавливаем SNMP-таргет:
esxcli system snmp set –v3targets server.domain@161/user/priv/trap
7. Включаем SNMP:
esxcli system snmp set –enable true
8. Тестируем настройки:
esxcli system snmp test
Точно так же, как и для версий 1 и 2, со стороны сервера можно проверить работоспособность настроек SNMP, указав введенные ранее пароли:
snmpwalk -v3 -u user -l AuthPriv -a SHA -A pass1 -x AES -X pass2 esxserver.domain
Все вышеперечисленное можно сделать и через vSphere CLI (нужно ставить на отдельную машину) в интерактивном режиме с помощью скрипта vicfg-snmp.pl:
Если вам не хочется заморачиваться с установкой vSphere CLI, то можно использовать скрипт configureSNMPv3.sh, с помощью которого настройка происходит легко и просто:
Недавно компания VMware разослала своим клиентам и партнерам письмо, в котором сообщалось об окончании поддержки линейки VMware vSphere 4.x, построенной, в том числе, на базе "толстого" гипервизора VMware ESX. Теперь эта новость доступна на официальном сайте VMware.
Дата окончания продаж vSphere 4.x: 15 августа 2013 г.
В связи с этим пользователям до 15 августа следующего года рекомендуется создать или сохранить резервную копию соответствующих дистрибутивов и сформировать необходимые лицензионные ключи на портале My VMware для поддержки или расширения сред на базе гипервизора vSphere ESX версии 4.x или vMA версий 1 и 4. Эти операции необходимо выполнить до 15 августа 2013 г. Компания VMware не будет предоставлять никакие двоичные файлы (дистрибутивы, утилиты и т.п.) и лицензионные ключи для гипервизора vSphere ESX 4.x и для vMA версий 1 и 4 после 15 августа 2013 г.
Касательно поддержки (SnS) и жизни после 15 августа:
Жизненный цикл поддержки гипервизора vSphere ESX 4.X и vMA.
Датой окончания поддержки остается 21 мая 2014 г. Подробнее о жизненном цикле поддержки VMware.
Возможность использования заказчиками гипервизора vSphere ESX 4.x или vMA версий 1 и 4 после 15 августа 2013 г.
Заказчики сохраняют возможность использования лицензированных копий продукта после даты окончания продаж и даты окончания поддержки. Тем не менее они не смогут загружать дистрибутивы и формировать новые лицензионные ключи после даты окончания продаж и получать техническую поддержку и подписку после даты окончания поддержки.
Продажа и поддержка vSphere ESXi 4.X — БЕЗ изменений.
Продажа vMA 4.1, 5 и 5.1 и поддержка всех версий — БЕЗ изменений.
Некоторые из вас, вероятно, видели документ, называющийся "VMFS File Locking and Its Impact in VMware View 5.1", доступный у нас вот тут. Он вкратце рассказывает о нововведении в VMware View 5.1 - теперь для пулов связанных клонов (Linked Clones) можно использовать кластеры до 32-х хостов, а не 8 как раньше. Но работает это только для тех окружений, где реплика базового образа размещена на NFS-хранилище, для VMFS же хранилищ ограничение осталось тем же самым - кластер из максимум 8 хостов. Давайте разбираться, почему это так.
Во-первых, посмотрим как выглядит классическая структура связанных клонов в инсталляции VMware View:
В пуле связанных клонов, который мы можем построить с помощью VMware View Composer, находится создаваемый и настраиваемый базовый образ (может быть со снапшотом), из которого создается реплика этой ВМ (Replica), на базе которой из дельта-дисков строятся уже конечные десктопы пользователей. При этом данные реплики используются одновременно всеми связанными клонами, которые располагаются на хост-серверах ESXi кластера.
Теперь напомним, что мы уже рассматривали типы блокировок (локов) в кластерной файловой системе VMFS. Однако там рассмотрены не все блокировки, которые могут быть применены к файлам виртуальных дисков. Мы рассматривали только эксклюзивную блокировку (Exclusive Lock), когда только один хост может изменять VMDK-файл, а все остальные хосты не могут даже читать его:
Такие блокировки используются в традиционном окружении инфраструктуры виртуализации для серверной нагрузки в виртуальных машинах. Очевидно, что такие блокировки не подходят для доступа к данным файла виртуального диска реплики VMware View.
Поэтому есть и другие типы блокировок. Во-первых, Read-Only Lock (в этом режиме все хосты могут читать один VMDK, но не могут менять его):
Во-вторых, Multi-Writer Lock:
В режиме такой блокировки сразу несколько хостов могут получить доступ к VMDK-файлу на общем хранилище VMFS в режиме Read/Write. При использовании инфраструктуры связанных клонов на хранилище применяются локи типа Read-Only Lock и Multi-Writer Lock, что требует одновременного доступа нескольких хостов ESXi к одному файлу. Естественно, где-то в локе должны храниться данные о том, какие хосты используют его.
А теперь посмотрим на внутренности лока. Они как раз и содержат все UID (User ID) хостов, которые работают с VMDK-файлом, в структуре "lock holders". Надо отметить, что для работы автоматической процедуры обновления лока необходимо, чтобы его размер был равен одному сектору или 512 байтам. А в этот объем помещается только 8 этих самых UID'ов, а девятый уже не влезает:
Напомню, что мы говорим про диск реплики, который необходим сразу всем хостам кластера с виртуальными ПК этого пула. Поэтому, как и раньше, в VMware View 5.1 нельзя использовать для реплики, размещенной на томе VMFS, кластер из более чем восьми хост-серверов VMware ESXi.
Однако можно поместить реплику на том NFS. По умолчанию протокол NFS не поддерживает file locking, однако поддерживает механизм Network Lock Manager
(NLM), который использует схему блокировок "advisory locking":
В этой схеме клиенты файла NFS могут координировать между собой совместный доступ к файлу (в нашем случае - VMDK). При этом никакого лимита на 8 хостов в этом механизме нет. Однако раньше в VMware View не позволялось использовать более 8 хостов в кластере для пула связанных клонов.
Теперь это сделать можно и, во многих случаях, даже нужно, выбрав NFS-хранилище для пула Linked Clone:
Некоторое время назад компания VMware открыла регистрацию пользователей для приема заявок на доступ к порталу лабораторных работ VMware Hands-On Labs (HOL), которая доступна по этой ссылке (нужно указывать корпоративный email). Эти лабораторные работы (которые в большом количестве проводились на конференциях VMware VMworld) позволяют приобрести практический опыт по управлению элементами инфраструктуры VMware vSphere и другими решениями (VMware View, vCloud Director), а также получить новые технические знания на достаточно глубоком уровне - и все это онлайн, бесплатно и без необходимости покупать серверы для обучения и настраивать там соответствующие компоненты.
Недавно компания VMware объявила о том, что публичная бета-версия Hands-On Labs уже запущена, а приглашения уже начали поступать некоторым пользователям. Если вы зарегистрировались ранее, то логины и пароли должны прийти в течение последующих нескольких дней. Для новых пользователей регистрация по-прежнему доступна.
Проводимые лабораторные работы будут полезны также и для тех пользователей, кто уже применяет VMware vSphere, так как там рассматриваются различные Enterprise-компоненты платформы, такие как распределенный коммутатор vSphere Distrinuted Switch (vDS), которые могут быть не развернуты или не использоваться в производственной среде предприятия. Кроме того, лабы HOL могут оказаться полезными при подготовке к экзаменам по линии сертификации VMware Certified Professional.
Для примера название лабораторной работы: HOL-INF-02 – Explore vSphere 5.1 Distributed Switch (vDS) New Features. Полное описание лабораторных работ доступно по этой ссылке.
На прошедшем VMworld Europe 2012 компания VMware рассказала об интересном решении VMware View Agent Direct-Connection Plugin, которое позволит пользователям виртуальных ПК соединяться с ними напрямую, минуя брокер соединений VMware View Connection Server. Делается это решение в партнерстве с различными компаниями, такими как Dell (+Quest) и Navisite, предлагающими DaaS-решения (Desktop-as-a-Service). Вот, например, интервью на эту тему с CEO компании Desktone, которая является провайдером DaaS:
Технически на данный момент View Agent Direct-Connection Plugin представляет собой DLL-ку, которая помещается в туже директорию, что и VMware View Agent, устанавливаемый на десктопе. После чего с ним можно соединяться напрямую, без брокера (т.е. просто вбив IP-адрес машинки или ее имя в клиенте):
Такую DLL мы помещаем в базовый образ, после чего при запуске агента во всех виртуальных ПК на базе этого образа происходит инициализация плагина View Agent Direct-Connection. Надо отметить, что при соединении пользователя из любого клиента (Windows, Mac, Android, iPad, Teradici Zero Clients и др.) через этот плагин, поддерживаются все необходимые функции VMware View: высокопроизводительный протокол PCoIP, перенаправление USB-устройств, поддержка 3D rendering, SSL-сертификаты, разделение GPU и так далее.
Кому такое может пригодиться? Я вижу такие варианты применения VMware View Agent Direct-Connection Plugin:
Использование со стороны DaaS-провайдеров для предоставления доступа отдельным пользователям, в том числе для тестирования сервисов.
Применение в небольших компаниях, которые не покупают VMware View, но используют виртуальные ПК на платформе VMware vSphere.
Интеграция в сторонних решениях, которые используют технологии VMware View и консоль виртуального ПК.
На данный момент VMware View Agent Direct-Connection Plugin работает только под Windows 7 и Windows 8 и доступен только партнерам VMware для собственных нужд. О публичной доступности продукта будет объявлено дополнительно.
Не так давно мы писали о планируемом VMware продукте VMware vCenter Multi-Hypervisor Manager (MHM), который позволяет управлять серверами и виртуальными машинами на платформе Hyper-V. На днях компания VMware выпустила первую версию плагина Multi-Hypervisor Manager, который, конечно же, не поддерживает Hyper-V 3.0 в Windows Server 2012 (конечно же - потому что VMware в последнее время взяла моду выпускать продукты без поддержки последних версий). Однако, вроде бы, в скором времени обещают версию и под новый Hyper-V.
VMware vCenter Multi-Hypervisor Manager поставляется в виде плагина к "толстому" клиенту vSphere Client (Web Client не поддерживается), который предоставляет доступ к дереву объектов Microsoft Hyper-V на базе следующих ОС:
Microsoft Hyper-V Server 2008
Microsoft Hyper-V Server 2008 R2
Напомним, что, согласно архитектуре решения, MHM имеет не только клиентскую часть, но и серверный компонент:
Для установки серверной части потребуются следующие вычислительные ресурсы:
2 CPU на частоте 2 ГГц или более
4 ГБ памяти
1 ГБ дискового пространства
Сетевой адаптер
Между всеми компонентами данной архитектуры осуществляется безопасная коммуникация по HTTPS.
Надо отметить, что серверная часть Multi-Hypervisor Manager - это Windows-приложение, поэтому если вы используете, например, виртуальный модуль VMware vCenter Server Appliance (vCSA), то придется устанавливать MHM на отдельную виртуальную или физическую Windows-машину и связывать его с сервисом vCenter. И да, надо отметить, что:
vCenter Multi-Hypervisor Manager is a fully-supported vCenter Server feature. VMware provides support for all vCenter Multi-Hypervisor Manager or vSphere related issues
Возможности vCenter Multi-Hypervisor Manager 1.0 для хостов Hyper-V:
Добавление/удаление хостов Hyper-V в окружение vCenter
Информация о конфигурации хостов Hyper-V (processor, memory, network)
Создание/удаление виртуальных машин на Hyper-V
Удаленная консоль как к самим хостам Hyper-V, так и к виртуальным машинам
Простейшие операции по управлению питанием хостов и виртуальных машин (power off, power on, suspend, shut down guest и reset)
Изменение настроек виртуальных машин: память, vCPU, диски, сетевые адаптеры и прочее виртуальное "железо"
Отображение задач для хостов Hyper-V и виртуальных машин на общей панели задач и событий vSphere Client
Интегрированная авторизация с vCenter, а также поддержка механизма пользователей и ролей
Скачать VMware vCenter Multi-Hypervisor Manager 1.0 можно по этой ссылке. Есть еще FAQ в KB 2037570.
Как знают пользователи решения для виртуализации настольных ПК VMware View, в данном решении для доступа пользователей к своим десктопам используется протокол PCoIP, разрабатываемый компанией Teradici при поддержке VMware. Мы уже писали о настройках протокола PCoIP, а также утилите, позволяющей их регулировать из графического интерфейса, а сегодня расскажем о калькуляторе для расчета необходимой полосы пропускания PCoIP.
Называется этот калькулятор "PCoIP Protocol Bandwidth Planning Calculator", он доступен для загрузки по этой ссылке (в форму можно забить ерунду - подтверждения через почту не потребуется).
Интересно то, что это уже четвертая версия калькулятора PCoIP, которая выглядит весьма навороченно и серьезно. Для планирования доступен как корневой датацентр компании, так и филиалы, для которых рассчитывается необходимая суммарная пропускная способность, которую нужно обеспечить при внедрении решений для виртуализации ПК.
Помимо, собственно, калькулятора в документе приведен детальный план по достижению оптимальной конфигурации инфраструктуры доступа VMware View. На последнем листе xls-файла доступна таблица с рекомендованными полосами пропускания, которые нужно выделять для различных типов нагрузок в виртуальных ПК, а также настройками параметров тонкой настройки протокола PCoIP:
Это краткая версия таблицы - при необходимости ее можно развернуть и получить, например, такую картинку.
В начале прошлого года мы рассказывали о средстве VMware vCloud Connector, которое позволяет мигрировать виртуальные машины на платформе VMware vSphere из частного облака предприятия в публичное хостинг-провайдера и обратно, что может пригодиться в условиях мгновенной нехватки аппаратных ресурсов. vCloud Connector представляет собой бесплатный плагин к VMware vCenter (управляется через Web Client), с помощью которого пользователь своей частной виртуальной инфраструктуры может перемещать свои виртуальные машины в облако, т.е. к провайдеру, который дает виртуальную инфраструктуру в аренду. Происходит это, в том числе, с использованием VMware vCloud API.
С момента нашей прошлой заметки продукт существенно изменился, а на VMworld Europe 2012 была анонсирована версия vCloud Connector 2.0 (надо отметить, что пока текущая версия vCloud Connector 1.5 не поддерживает vCloud Director 5.1). Теперь это решение разделено на 2 версии:
Free Edition
Advanced Edition (в составе комплекта vCloud Suite)
Какие возможности появились в бесплатном VMware vCloud Connector 2.0 Free:
Improved Workload Tranfer - улучшенные технологии передачи данных и совместимости, позволяющие мигрировать виртуальные машины между частным облаком VMware vSphere, vCloud Director и сертифицированными сервисами vCloud (всего более 15 провайдеров, но в ближайшей перспективе - более 160).
New User Interface and Features – улучшенный интерфейс, предоставляющий возможности кросс-облачного поиска (о как!) виртуальных машин или шаблонов по имени.
Multi-tenant vCloud Connector (VCC) node – улучшенные возможности для внедрения vCloud Connector в гибридных облаках.
В коммерческом издании VMware vCloud Connector 2.0 Advanced появились следующие возможности:
DataCenter Extention – возможность растягивания сети датацентра компании на ЦОД провайдера на уровне layer 2 через защищенный туннель SSL VPN (посредством VXLAN). Это позволяет переместить виртуальную машину в ЦОД сервис-провайдера, сохранив ее IP-адрес, и продолжать управлять ей так, как будто бы она исполняется в собственном датацентре.
Content Sync - позволяет иметь один централизованный каталог виртуальных сервисов (vApp), который будет реплицироваться на удаленные каталоги (например, у различных сервис-провайдеров), которые вы можете использовать для создания новых виртуальных машин. Эти каталоги могут быть "подписаны" на исходный каталог.
Обидно, конечно, что поддержка VXLAN доступна только в платной версии, ну да ладно. Скачать VMware vCloud Connector можно по этой ссылке.
Для осуществления делегирования административных задач пулы виртуальных десктопов отдельных клиентов, которым предоставляется услуга (возможно филиалов, других предприятий и т.п.) следует располагать в своей выделенной папке (folder) иерархии VMware View Manager. Пулы виртуальных десктопов различных типов также рекомендуется располагать в отдельных папках (folder) иерархии VMware View Manager...
Если вам требуется удобный поиск и навигация по большим созданным профилям хостов, созданным с помощью функций VMware vSphere Host Profiles, то можно сделать их экспорт в формат VPF (VMware Profile Format):
Затем в получившемся файле поменять расширение с *.vpf на *.xml и открыть его в своем любимом просмотрщике XML:
Мы уже не раз затрагивали тему vswp-файлов виртуальных машин (файлы подкачки), которые используются для организации swap-пространства гипервизором VMware ESXi. Эти файлы выполняют роль последнего эшелона среди техник оптимизации памяти в условиях недостатка ресурсов на хосте. Напомним, что в гипервизоре VMware ESXi есть такие техники как Transparent Page Sharing, Memory Ballooning, a также Memory Compression, которые позволяют разбираться с ситуациями нехватки памяти, необходимой виртуальным машинам.
Напомним также, что первым эшелоном оптимизации памяти является техника Memory Ballooning. Она работает за счет использования драйвера vmmemctl.sys (для Windows), поставляемого вместе с VMware Tools. Он позволяет "надуть" шар внутри гостевой ОС (balloon), который захватывает физическую память, выделенную этой ОС (если ее много), и отдает ее другим гостевым операционным системам, которые в ней нуждаются. Этот balloon не позволяет гостевой ОС производить работу приложений с данной областью памяти, поэтому если им потребуется дополнительная память - она будет уходить в гостевой своп. Это более правильный подход, чем свопировать гостевую ОС в файл подкачки vswp на томе VMFS, поскольку операционная система сама лучше разбирается, что и когда ей класть и доставать из свопа (соответственно, быстродействие выше).
Однако, когда памяти у всех виртуальных машин совсем мало или отдельной ВМ ее требуется больше, чем сконфигурировано, а также происходит постоянное обращение к памяти (особенно, если в гостевых ОС нет VMware Tools), гипервизор начинает использовать vswp-файл подкачки, который по умолчанию находится в папке с виртуальной машиной. Мы уже писали о том, что в целях повышения быстродействия можно положить vswp-файлы виртуальных машин на локальные SSD-хранилища серверов ESXi, а также о том, как удалять мусорные файлы vswp.
Ниже мы приведем 8 фактов о swap-файлах виртуальных машин, которые основаны на вот этой заметке Фрэнка Деннемана:
1. Хранение vswp-файлов на локальных дисках сервера ESXi (в том числе Swap to Host Cache) увеличивает время vMotion. Это очевидно, так как приходится копировать vswp-файл в директорию ВМ (или другую настроенную директорию), чтобы его видел целевой хост.
2. С точки зрения безопасности: vswp-файл не чистится перед созданием. То есть там лежат не нули, а предыдущие данные блоков. Напоминаем, что размер файла подкачки равен размеру сконфигурированной памяти ВМ (если не настроен Reservation). Если же у машины есть Reservation, то размер vswp-файла определяется по формуле:
То есть, если в настройках памяти машины ей выделено 4 ГБ, а Reservation настроен в 1 ГБ, то vswp-файл будет составлять 3 ГБ.
3. Как происходит копирование vswp-файла при vMotion? Сначала создается новый vswp-файл на целевом хосте, а потом копируются только swapped out страницы с исходного в целевой vswp-файл.
4. Что происходит при разнице в конфигурации размещения vswp-файлов в кластере и для отдельных хостов? Напомним, что в настройках кластера VMware vSphere есть 2 опции хранения vswp-файлов: в папке с ВМ (по умолчанию) и в директории, которая указана в настройках хоста:
Если на одном хосте настроена отдельная директория для vswp, а на другом нет (то есть используется папка ВМ), то при vMotion такой виртуальной машины vswp-файл будет скопирован (в папку с ВМ), несмотря на то, что целевой хост видит эту директорию на исходном.
5. Обработка файлов подкачки при нехватке места. Если в указанной директории не хватает места для свопа ВМ, то VMkernel пытается создать vswp-файл в папке с ВМ. Если и это не удается, то виртуальная машина не включается с сообщением об ошибке.
6. vswp-файл лучше не помещать на реплицируемое хранилище. Это связано с тем, что используемые страницы памяти, находящиеся в двух синхронизируемых файлах, будут постоянно реплицироваться, что может вызывать снижение производительности репликации, особенно если она синхронная и особенно при vMotion в недефолтной конфигурации (когда происходит активное копирование страниц и их репликация):
7. Если вы используете снапшоты на уровне хранилищ (Datastore или LUN), то лучше хранить vswp-файлы отдельно от этих хранилищ - так как в эти снапшоты попадает много ненужного, содержащегося в своп-файлах.
8. Нужно ли класть vswp-файлы на хранилища, которые развернуты на базе thin provisioned datastore (на уровне LUN)? Ответ на этот вопрос зависит от того, как вы мониторите свободное место на тонких лунах и устройствах своего дискового массива. При создании vswp-файла VMkernel определяет его размер и возможность его создания на уровне хоста ESXi, а не на уровне устройства дискового массива. Поэтому если vswp-файл активно начнет использоваться, а вы этого не заметите при неправильной конфигурации и отсутствии мониторинга тонких томов - то могут возникнуть проблемы с их переполнением, что приведет к сбоям в работе ВМ.
Как знают все администраторы VMware vSphere, версией 5.1 этой платформы виртуализации и виртуальными машинами можно управлять как через традиционный "толстый" клиент vSphere Client, так и через обновленный полнофункциональный "тонкий" vSphere Web Client.
При этом, как мы уже писали вот тут, версия толстого клиента VMware vSphere Client 5.1 - последняя и больше обновляться не будет, а дальше все администрирование инфраструктуры виртуализации будет полностью построено на базе веб-сервисов.
Однако, не все знают, что большинство новых возможностей vSphere 5.1 доступны только через Web Client, поэтому не стоит удивляться, не обнаружив их в стандартном клиенте. Основные возможности у обоих клиентов одинаковы, а ниже приведены различия в этих двух средствах управления виртуальной инфраструктурой VMware vSphere 5.1:
Функции, доступные только в vSphere 5.1 Web Client
Функции, доступные только в vSphere 5.1 (Desktop) Client
vCenter Single Sign-On - единый вход в сервисы виртуальной инфраструктуры (замена и расширение Linked Mode), включая аутентификацию и администрирование
VMware Desktop Plug-ins (Update Manager, SRM и т.п.) - возможность подключения плагинов различных продуктов VMware.
Навигация через списки Inventory Lists
Возможность подключения плагинов сторонних производителей
Добавление тэгов к объектам (Inventory Tagging) и их поддержка в поиске
Возможность постановки выполняемых задач на паузу (тут)
Возможность изменить вид гостевой ОС для существующей машины
Предлагаемые варианты при поиске объектов
Функции vCenter Server Maps (карты хостов, хранилищ, vMotion)
Сохранение вариантов поиска (Save Searches)
Возможность задания и изменения custom attributes для объектов
Улучшенная производительность при выводе списка объектов
Возможность соединения с хостом ESXi напрямую
Функции репликации виртуальных машин vSphere Replication (но не для VMware SRM)
Возможность раздувания тонкого диска (Inflate thin disk) до полного размера через Datastore Browser
Функции продукта Virtual Infrastructure Navigator (подробнее тут)
Функции Enhanced vMotion для горячей миграции виртуальных машин без общего хранилища (подробнее тут)
Интеграция с продуктом vCenter Orchestrator (vCO) в части рабочих процессов (расширенные меню)
Новые функции Virtual Distributed Switch (vDS)
Health Check
Export/Restore Configuration
Diagram filtering
Плагин для просмотра логов (Log Browser Plugin)
Резервное копирование средствами vSphere Data Protection (VDP)
Как мы видим, возможность прямого соединения с хостом и управления им есть на данный момент только у толстого клиента vSphere, поэтому без него трудно обойтись в случае недоступности сервисов vCenter.
Что касается функционала списков объектов (Inventory Lists), поиска по этим спискам, а также тэгирования объектов в vSphere Web Client, то на эту тему есть следующее видео:
Оказывается, еще в сентябре компания VMware обратила внимание пользователей на один интересный продукт - VMware vCenter Support Assistant. Он призван помочь пользователям в сборе и отправке диагностических данных о своей виртуальной инфраструктуре, а также обращении в техническую поддержку.
Продукт будет представлять собой виртуальный модуль (Virtual Appliance) для VMware vCenter и позволит грамотно оформлять Support Request'ы, а также взаимодействовать с инженерами техподдержки VMware в удобном интерфейсе. Сейчас он находится в стадии бета-тестирования.
vCenter Support Assistant позволит оформлять запросы в техподдержку не только для VMware vSphere, но для любого другого продукта VMware, для которого куплена поддержка на базе SnS или по инцидентам. На данный момент поддерживаются версии VMware vSphere 5.1, 5.0 и 4.1.
После установки, VMware vCenter Support Assistant появится как плагин к vSphere Client:
Дальше логинимся:
и создаем Support Request:
После детального описания проблемы (суть, критичность, категория, статьи KB) можно собрать и прикрепить диагностическую информацию:
После того, как запрос в техподдержку будет сформирован, а необходимые логи и конфиги загружены, можно посмотреть статус своего обращения:
В целом, должна быть удобная штука, особенно для больших компаний, где много администраторов, виртуальных машин и, соответственно, проблем. Для записи в бета-тестеры продукта VMware vCenter Support Assistant нужно использовать эту ссылку.
Не все знают, что у компании VMware есть некоторый набор курсов по своим продуктам, созданный на русском языке. Все они доступны на образовательном портале VMware eLearning:
Компания VMware недавно запустила новый проект в рамках своего направления по обучению пользователей - vmwarelearning.com.
В качестве обучающих материалов доступны видеозаписи о следующих продуктах VMware:
Site Recovery Manager
vCenter Operations Manager
vCloud
vFabric/Spring
vSphere
vSphere Storage Appliance
Пока на сайте всего 50 бесплатных обучающих видеозаписей, но их количество будет постоянно пополняться. Сайт является хорошим дополнением к VMware Mobile Knowledge Portal. Планируются также выпуски не только на английском языке, однако русский в ближайшие планы VMware, по-видимому, не входит.
Не так давно на многих блогах с подачи CRN появились слухи о том, что компании Apple и VMware работают над совместным решением по доставке составляющих пакета iWork на конечные устройства бизнес-пользователей, включая iPad, посредством технологий, имеющихся в VMware View.
Пакет iWork, включающий в себя приложения Pages (документы), Numbers (таблицы) и Keynote (презентации) - это конкурент офисного пакета Microsoft Office, который компания Microsoft планирует в скором времени выпустить и для iPad. Это будет настоящим спасением для iPad-пользователей, которым приходиться страдать, просматривая win-офисные документы и презентации через приложения множества косоруких разработчиков. Поговаривают даже, что пришествие Office на iPad состоится уже совсем скоро.
Поэтому Apple начала суетиться уже сейчас, чтобы обратить внимание на свои офисные решения, и в прессу начали просачиваться слухи о том, что iWork будет работать не только в iOS и Mac OS, но и на Windows-десктопах.
Apple уже сейчас предлагает использовать пакет iWork как для iOS, так и для OS X, которые доступны для покупки в App Store. Так что же планирует Apple? Очень просто - возможно, они хотят организовать доставку приложений пакета iWork посредством VMware View из датацентров Apple в корпоративные Windows-компьютеры через высокопроизводительный протокол PCoIP. Все это не будет связано с существующими сервисами iCloud. Хотя этого и не следует из статьи на CRN. В статье CRN вообще написано про какое-то iPad-приложение, которое сочетает в себе софт VMware View с компонентами iWork из облака:
According to sources with knowledge of the project, the iPad app combines VMware View virtual-desktop software with cloud-hosted versions of Pages, Keynote and Numbers -- known as the iWork suite -- running on Apple infrastructure.
Зачем такие извращения, если можно использовать обычный iWork для iOS в статье умалчивается. А может быть Apple хочет десктопы Mac OS доставлять в Windows-компьютеры из облака и думает, что это будет круто?
Напомним также, что у VMware есть продукт для создания облачного фронтэнда корпоративных пользователей Horizon Suite, который включает в себя решение Horizon Application Manager для федерации SaaS-сервисов пользователя. Может быть в конечном итоге iWork попадет на эту панельку?
Пока в этой теме вопросов больше чем ответов. Можете пока почитать Брайана на эту тему.
По умолчанию timeout сессии, в которой работает Web Client, составляет 30 минут. Не всем это удобно.
Некоторым пользователям в целях безопасности хочется сократить этот таймаут, а некоторым, в целях удобства - убрать совсем. Для этого существует специальная настройка на сервере, где установлен vSphere Web Client. Надо найти файл webclient.properties, который размещен в следующих местах, в зависимости от ОС:
Operating System
File path
Windows 2003
%ALLUSERPROFILE%Application Data\VMware\vSphere Web Client
Windows 2008
%ALLUSERPROFILE%\VMware\vSphere Web Client
vCenter Server Appliance
/var/lib/vmware/vsphere-client
Нужно будет отредактировать следующее значение:
session.timeout = value
где value - это время жизни сессии vSphere Web Client в минутах. Чтобы сессия не отваливалась совсем, следует указать значение равное 0. После этого нужно перезапустить vSphere Web Client service.
Представляем вам очередную статью нового автора VM Guru - Максима Федотенко. В первой части статьи Максима "Рекомендации по защите инфраструктуры виртуальных десктопов, созданных на базе платформы VMware View" было рассказано о сетевой инфраструктуре в контексте безопасности VDI-решения. Во второй статье цикла речь пойдет о некоторых рекомендациях по настройкам серверов и служб технологической инфраструктуры VMware View.
Мы уже писали о продукте VMware vCenter XVP Manager and Converter, который доступен с сайта проекта экспериментальных разработок VMware Labs и позволяет перенести часть базовых задач по управлению виртуальной средой Hyper-V на сторону vCenter. Делается это через vCenter XVP Manager plug-in для vSphere Client. Однако официально со стороны VMware это решение не поддерживается, поэтому представляло оно интерес только для тех, кому интересно покрутить Hyper-V в своей тестовой лаборатории.
После выпуска Microsoft Hyper-V 3.0 в составе Windows Server 2012, который, помимо прочего, позволяет управлять серверами VMware vSphere, компания VMware стала всерьез задумываться о том, как можно управлять гибридной средой гипервизоров ESXi и Hyper-V. Как результат - появилась информация о том, что в скором времени будет выпущен официальный VMware vSphere Multi-Hypervisor Manager (MHM) с поддержкой управления серверами Microsoft Hyper-V 3.0, поставляемый в виде плагина к vSphere Client.
Как мы видим из картинки, vCenter MHM 1.0 будет предоставлять следующие возможности по управлению сторонними гипервизорами:
Добавление/удаление хостов Hyper-V в окружение vCenter
Информация о конфигурации хостов Hyper-V (processor, memory, network)
Создание/удаление виртуальных машин на Hyper-V
Удаленная консоль как к самим хостам Hyper-V, так и к виртуальным машинам
Простейшие операции по управлению питанием хостов и виртуальных машин (power off, power on, suspend, shut down guest и reset)
Изменение настроек виртуальных машин: память, vCPU, диски, сетевые адаптеры и прочее виртуальное "железо"
Отображение задач для хостов Hyper-V и виртуальных машин на общей панели задач и событий vSphere Client
Интегрированная авторизация с vCenter
На прошедшем VMworld 2012 на тему vSphere Multi-Hypervisor Manager было не так много информации:
Архитектура решения:
Как сообщается, плагин MHM для vCenter будет доступен бесплатно для всех пользователей VMware vSphere, у которых есть vCenter Standard. Выпуск решения VMware vSphere Multi-Hypervisor Manager ожидается в самое ближайшее время.
Мы уже писали о том, что после выхода новой версии платформы виртуализации VMware vSphere 5.1, оказалось, что она несовместима с последней версией решения для виртуализации настольных ПК предприятия - VMware View 5.1 (а также и с некоторыми другими продуктами). Происходило это из-за новой возможности View Storage Accelerator, которая при использовании функционала Content Based Read Cache (CBRC) приводила к многочисленным запросам CBRC, из-за которых терялась связь с хост-сервером ESXi 5.1.
В конце прошлой недели компания VMware, наконец, решила эту проблему, выпустив релиз VMware vSphere 5.1.0a, полностью поддерживающий View 5.1 (обратите внимание, что версия ESXi 5.1 не изменилась, т.е. обновлять нужно vCenter, а на ESXi 5.1 можно просто накатить патч ESXi510-201210001):
Обновленный ISO-образ гипервизора ESXi: VMware-VMvisor-Installer-201210001-838463.x86_64.iso. Подробности доступны в KB 2035268. Для обновления VMware vCenter 5.1.0a доступны Release Notes, где указаны исправленные ошибки. Странно, что патч накатывается не на компоненты VMware View 5.1, а на вышедшую позже платформу vSphere 5.1.
И еще одна приятная новость - вышел VMware Converter 5.0.1 с поддержкой vSphere 5.1. Вышел он аккурат после выпуска Microsoft Virtual Machine Converter Tool 1.0, который vSphere 5.1 не поддерживает, что как бы намекает.
Но это еще не все. Обновились также и следующие продукты:
Не секрет, что продавать программное обеспечение сейчас - дело неблагодарное и низкомаржинальное, когда дело касается небольших сделок. Когда дело касается большой продажи - это, зачастую, лохотрон, потому как у многих вендоров есть пресловутый механизм "регистрации сделок", который уже давно прогнил и воняет как брошенный у деревенской остановки труп. Почему от него воняет? Очень просто - решение по регистрации сделок целиком лежит на аккаунте вендора, который может быть ангажирован со стороны одного из партнеров, который мотивирует первого разными способами, в том числе Чивасом в помпезном баре или квартальными бонусами. Об этом наши западные друзья, конечно же, знают, но закрывают на это глаза - продавать в Загнивающей как-то же надо.
Они-то знают, как тут строится бизнес и вынуждены работать по правилам, несмотря на то, что заставляют заполнять документы типа "Due Diligence Questionnaire", где сказано куда бежать, если заказчик вымогает взятку. Ну да ладно, речь не об этом.
У тех, кто отвечает за русский прайсинг в VMware - голоса в голове. Когда-то его сделали доступным, потом убрали, теперь он снова на арене, но в новом обличье! Давайте для сравнения заглянем в американский прайс:
И цены наших европейских братьев:
Ого-го, что мы видим. Всего-то мы видим воочию, своими собственными глазами, что:
У нас VMware в 2 раза дороже, чем в Америке.
И чуть поменьше, чем в 2 раза - по отношению к Европе. Это вам даже не Apple со своими Айпадами. Вы вот тут возмущались разнице в цене 30%? Теперь встаньте в стойло и кушайте разницу почти в 100%!
С чем же такое связано? Очень просто - прайс, который вы видите на русском сайте VMware - не совсем настоящий. Какой-то креативный человек в VMware решил провернуть инновационную штуку. А именно: повысить рекомендованные цены для пользователей в России, а для партнеров оставить их прежними (они хоть и не американские, но не в 2 раза же выше). Бедненькие партнеры же страдают со своей копеечной маржой. А тут - нате: давайте вместе считать пользователя мудотрясом и зарабатывать.
Скажу вам по секрету, что старая рекомендованная цена для российского пользователя - как и раньше на 30% выше американской. Поэтому мне ничего не остается, как сказать вам, какую цену вам требовать от партнера - прибавить 30% к американскому прайсу. Это будет адекватно. А этим пусть сама VMware пользуется.
P.S. Если вы донесете это до СМИ или напишете в Спортлото - будет хорошо.
Мы уже писали о виртуальном модуле VMware vCenter Server Appliance (vCSA), который представляет собой готовую к развертыванию виртуальную машину, содержащую сервисы управления виртуальной инфраструктурой VMware vSphere. Также мы уже писали о настройке vCSA для работы с внешней СУБД Oracle. В этом посте мы хотели бы обобщить актуальную информацию по VMware vCenter Server Appliance версии 5.1, который построен на базе 64-битного SUSE Linux Enterprise Server 11, а также привести полезные ссылки по работе с этим средством. Основные требования vCSA 5.1:
2 vCPU для виртуальной машины
8 ГБ памяти
Около 80 ГБ диска для нормальной работы
Итак, во-первых, небольшое видео по первичной установке и настройке vCSA 5.1:
Во-вторых, приведем причины, по которым вам может быть полезно использовать vCSA 5.1:
Простота развертывания и настройки виртуального модуля в тестовых окружениях
В некоторых наших статьях мы уже затрагивали приемы работы с утилитой vsish (VMkernel Sys Info Shell), которая есть в консоли хостов VMware ESXi, и которая предназначена для управления огромным числом обычных и скрытых настроек сервера и ядра VMkernel (то, что раньше управлялось с помощью команды esxcfg-advcfg). Например, мы уже писали про то, как с помощью vsish можно:
Однако, как вы уже догадались, эти три примера не являются исчерпывающими вариантами использования утилиты vsish. Напомним, что работать с ней нужно в следующем формате:
Запускаем утилиту:
~ # vsish
Далее узнаем значение параметра или настройки:
/> get <параметр, путь к файлу>
Устанавливаем новое значение:
/> set <параметр, путь к файлу> <значение>
Можно выполнить команду сразу, с опцией -e. Например:
~ # vsish -e get /power/hardwareSupport
Большинство параметров утилиты vsish, содержащие путь /config - это расширенные настройки хоста ESXi, которые вы можете редактировать в Advanced Settings через vSphere Client или vSphere Web Client. Вот, например, мы недавно писали о том, как административные привилегии на ESXi назначить пользователю из Active Directory:
Для этой настройки есть соответствующий путь для vsish. Выглядит он так:
/config/HostAgent/plugins/hostsvc/esxAdminsGroup
Однако vsish позволяет редактировать и скрытые настройки ESXi, которые недоступны для изменения через GUI. Полный список настроек vsish для хостов VMware ESXi 4.1 и выше приведен у Вильяма Лама:
Автор сайта v-front.de выпустил обновленную версию утилит ESXi5 Community Packaging Tools 2.0 (ESXi5-CPT), которые позволяют создавать пакеты для VMware ESXi в форматах VIB (VMware Installation Bundle) and ZIP (VMware Offline Bundle). Для VIB-файлов их статус (acceptance level) будет указан как Community Supported. Об этих утилитах от Andreas Peetz мы уже писали вот тут. Зачастую, эти утилиты необходимы пользователям для включения сторонних драйверов устройств в состав дистрибутива платформы ESXi, которые отсутствуют в стандартном комплекте поставки.
Новые возможности ESXi5 Community Packaging Tools 2.0:
Поддержка VMware ESXi 5.1.
Обновленный TGZ2VIB5.cmd 2.0:
Добавлены новые опции GUI с дополнительными настройками VIB и параметрами установки
Добавлено меню для загрузки шаблонов настроек для различных типов пакетов (например, "Hardware driver" или "Firewall rule")
Возможность не указывать контрольные суммы в дескрипторном XML-файле
Утилита VIB2ZIP не изменялась.
Скачать ESXi5 Community Packaging Tools 2.0 можно по этой ссылке.
Также, напомним, что на сайте проекта VMware Labs есть еще одно средство для создания VIB-пакетов для VMware ESXi, но работающее только в командной строке и под Linux - VIB Author.
Одна из дополнительных опций VIB Author - это возможность задания электронной подписи к VIB-файлу, однако это не требуется для пакетов уровня Community Supported. Кроме того, VIB Author позволяет редактировать далеко не все директории, поэтому ESXi5-CPT - наш выбор.
На прошедшей в октябре в Барселоне конференции VMworld Europe 2012 компания объявила о внесении существенных изменений в комплектность и условия поставки продукта vCenter Operations Manager Suite 5.6, о котором мы писали вот тут.
Напомним, что VMware vCenter Operations Manager Suite - это пакет продуктов для анализа и решения проблем производительности в датацентре компании, средства прогнозирования нагрузки, а также механизмы "осведомленности о приложениях", которые позволяют строить карты зависимости на уровне компонентов приложений для сервисов виртуальной инфраструктуры.
Вот что изменилось в пакете продуктов vCenter Operations Management Suite:
Самое главное - появилось бесплатное издание vCenter Operations Foundation, которое поставляется вместе с любой покупкой платформы виртуализации VMware vSphere. В этом продукте компания VMware использует так называемый "Freemium" подход, когда часть функций продукта доступна бесплатно, но для использования полного функционала надо обновиться на одно из коммерческих изданий vCenter Operations, либо на пакет vCloud Suite, который включает в себя vCO.
Старого издания Standard Edition больше нет - его функции переданы бесплатному изданию vCenter Operations Foundation.
Новое издание Standard Edition получило функции старого Advanced Edition. Продается, однако, оно по цене старого Advanced Edition ($125 за виртуальную или физ. машину по прайсу NAM).
Новое издание Advanced Edition получило функции старого Enterprise Edition и подорожало ($250 за виртуальную или физ. машину по прайсу NAM, раньше было $195).
Издания Enterprise Plus за $1 370/машина больше нет, вместо него есть издание Enterprise за $600/машина. В издании Enterprise отсутствуют адаптеры к сторонним продуктам, которые раньше были в Enterprise Plus. Они теперь продаются отдельно.
Шаблоны Regulatory Compliance теперь продаются отдельно по цене $295 за машину.
Итоговое сравнение изданий vCenter Operations Management Suite 5.6:
Как видно из таблицы, бесплатная версия умеет только мониторить производительность и жизнедеятельность виртуальной инфраструктуры VMware vSphere. Скачать пробную версию vCenter Operations Management Suite 5.6 можно по этой ссылке. Лицензия на версию Foundation должна прийти отдельным письмом от VMware после покупки vSphere.
Иногда при попытке вывести хост VMware ESXi из домена AD с помощью vSphere Client пользователь видит вот такую ошибку:
The operation is not allowed in the current state
В этом случае вам необходимо сделать "Clean up" конфигурации Active Directory. Для этого заходим в консоль хоста через DCUI или SSH и выполняем следующие команды:
1. Останавливаем демон lsassd:
/etc/init.d/lsassd stop
2. Удаляем папку db на хосте:
rm /etc/likewise/db/
3. Запускаем демон lsassd:
/etc/init.d/lsassd start
После этого выведение хоста ESXi из Active Directory должно пройти успешно.
Среди новых возможностей VMware vSphere 5.1 мы еще не упоминали о том, что теперь в подсистеме безопасности хост-серверов VMware ESXi 5.1 появились некоторые улучшения. Во-первых, учетным записям обычных пользователей (named user accounts) можно назначать полностью административные привилегии, чего раньше не было.
Это означает, что такие пользователи не нуждаются в использовании общего root-аккаунта при выполнении различных операций на хост-серверах ESXi (например, просмотр логов или выполнение команд esxtop и vmkfstools). То есть теперь не надо вополнять в консоли команду "su", а можно просто работать под своим административным аккаунтом. Раньше эта необходимость вызывала некоторые проблемы, так как важные операции, выполняемые несколькими администраторами, логировались как один аккаунт "root".
Для новых административных аккаунтов ESXi 5.1 нужно помнить, что:
Завести их можно только прямым соединением vSphere Client к хосту, а не через Web Client.
Для массового создания административных аккаунтов на хостах ESXi можно использовать функции Host Profiles.
Административные привилегии можно назначить пользователю (группе) из Active Directory. Для этого нужно создать группу администраторов серверов ESXi в AD, а потом добавить ее в расширенные настройки хоста ESXi. Для этого нужно зайти в Advanced Settings в vSphere Client, далее Config –> HostAgent и добавить нужную группу AD в параметр "Config.HostAgent.plugins.hostsvc.esxAdminsGroup":
Во-вторых, административные привилегии могут быть отобраны у встроенного аккаунта root, чтобы злоумышленник, в случае его получения, не мог им воспользоваться на хосте ESXi.
В-третьих, появилась возможность автоматически терминировать сущствующие неактивные сессии пользователей в консоли ESXi. Для настройки этого параметра нужно зайти Advanced Settings в vSphere Client, далее UserVars и выставить там следующее значение в секундах:
UserVars.ESXiShellInteractiveTimeOut
Как многие помнят, в vSphere 5 была расширенная настройка UserVars.ESXiShellTimeOut, которая задавала таймаут в секундах, по прошествии которого доступ к ESXi Shell или SSH, будучи включенным однажды - автоматически отключался:
То есть, по прошествии этого времени нельзя уже зайти на хост ESXi, и администратору не нужно заботиться об отключении сервиса. Однако все его сессии, если он их не прекратил продолжали работать, что может быть небезопасно.
Поэтому в ESXi 5.1 и появилась дополнительная настройка ESXiShellInteractiveTimeOut, которая определяет время, по истечении которого пользователь неактивной консоли (DCUI или SSH) будет автоматически разлогинен.
Данная статья посвящена аспектам защиты инфраструктуры виртуальных десктопов, построенной на базе программного обеспечения VMware View. На текущий момент у VMware отсутствуют рекомендации по обеспечению защиты инфраструктуры VMware View наподобие Hardening Guide для VMware vSphere. Точнее сказать они есть, но разрозненны и находятся в различных документах. В части 1 статьи попытаемся рассмотреть рекомендации, которые могут предъявляться к сетевой архитектуре инфраструктуры виртуальных ПК.
RSS
