Недавно мы писали, что в начале года компания VMware выпустила обновления своей платформы виртуализации настольных ПК предприятия - VMware Horizon 7.4. Параллельно с апдейтом этого VDI-решения было проведено и обновление клиентов, в частности вышел VMware Horizon Client 4.7 for iOS, работающий на устройствах iPhone и iPad.

Давайте посмотрим, что нового появилось в Horizon Client 4.7:

• Улучшения восстановления соединения VMware Blast. Эта функция была улучшена в плане надежности механизмов пересоединения и повторной передачи при временных сбоях в сети. В большинстве таких случаев приложения продолжают работать после короткой паузы. Для приложений чувствительных ко времени отклика VMware Blast перезапускает сессию.
• Поддержка Derived credentials (аутентификация через одноразовые пароли) для аутентификации на удаленном десктопе. Для этого поддерживается решение Purebred.
• Драг энд дроп текста и картинок. Эта функция показана в видео ниже. Можно перетаскивать объекты из клиентского устройства в опубликованное приложение или в открытое приложение на виртуальном десктопе.

А вот так это работает с клавиатурой и мышью Swiftpoint GT:

• Генерация ярлыков и ссылок на сайты. Теперь можно перетащить ярлык сервера, десктопа или приложения на другое приложение, чтобы сгенерировать URI. Также можно перетащить имя сервера на страницу Servers, чтобы присоединиться к нему.

• Поддержка аутентификации Face ID. Теперь можно выбрать этот способ аутентификации на айфонах и других будущих устройствах с поддержкой Apple Face ID.

Как всегда клиент VMware Horizon Client 4.7 for iOS доступен на общей странице загрузки клиентов VMware Horizon.

Уважаемые коллеги!

Приглашаем на интереснейший вебинар «VMware vCloud Extender – новейший инструмент построения гибридных облаков для vSphere 6.5». Про vCloud Extender мы уже писали вот тут. Это бывший продукт vCloud Connector, сейчас vCloud Extender позволяет пользователям облачных инфраструктур бесплатно перенести свои онпремизные виртуальные машины в облако сервис-провайдеров IaaS.

Будет проведён краткий обзор функционала VMware vCloud Extender, существенно упрощающего и расширяющего возможности миграции сервисов в облако, а также решающий задачи обеспечения высокой доступности для ЦОД, рассмотрены наиболее характерные сценарии его применения. Кроме того, вас ждёт живая демонстрация продукта на платформе VMware vSphere 6.5 от Облакотеки.

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

Приходите - будет действительно интересно, живое демо продукта и разъяснение технических моментов по продукту vCloud Extender, о которых вы часто спрашиваете.

Присоединяйтесь к нам на нашем мероприятии, будем рады общению!

На днях мы писали о том, что компания VMware выпустила обновления VMware vCenter и ESXi, закрывающие потенциальную угрозу безопасности Spectre (она же Hypervisor-Assisted Guest Mitigation - CVE-2017-5715), которая недавно была обнаружена в процессорах Intel. Для закрытия уязвимости нужно обновить не только серверы ESXi и vCenter, но и микрокод (BIOS/Firmware) серверов (более подробная информация также приведена в KB 52085).

На днях наш читатель Сергей прислал ссылку на скрипт от Вильяма Лама, который позволяет провести проверку компонентов виртуальной инфраструктуры VMware vSphere на данную уязвимость. Этот PowerCLI-скрипт содержит две функции:

• Verify-ESXiMicrocodePatchAndVM
• Verify-ESXiMicrocodePatch

Первая функция позволяет проверить хосты ESXi и виртуальные машины и сгенерировать отчет в разрезе виртуальных машин. Если в колонке Affected стоит значение False - значит обновления и микрокода сервера, и хоста ESXi были применены, а сами ВМ и хост-сервер не подвержены уязвимости Spectre.

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

Функция Verify-ESXiMicrocodePatchAndVM может быть запущена тремя способами:

• Без параметров - проверяется все окружение VMware vSphere и все виртуальные машины в нем.
• С параметром - ClusterName - проверяется конкретный кластер и всего его хосты и ВМ.
• С параметром - VMName - проверяется только конкретная ВМ и ее хост, соответственно.

У функции Verify-ESXiMicrocodePatch также есть три способа вызова:

• Без параметров - проверяются все хост-сервера в инфраструктуре vCenter.
• С параметром - ClusterName - проверяется конкретный кластер и всего его хосты.
• С параметром - VMHostName - проверяется конкретный хост-сервер ESXi.

Скачать этот PowerCLI-сценарий можно по этой ссылке: VerifyESXiMicrocodePatch.ps1.

Кстати говоря, этот скрипт был добавлен в полезный скрипт vCheck, который перед Новым годом обновился до версии 6.25, скачать его можно вот тут - https://github.com/alanrenouf/vCheck-vSphere.

На днях компания VMware выпустила обновленную версию решения для виртуализации и доставки виртуальных ПК и приложений предприятия - VMware Horizon 7.4. Напомним, что предыдущее обновление этого продукта VMware Horizon 7.3.1 вышло осенью прошлого года.

Давайте посмотрим, что нового появилось в новой версии этой платформы для организации VDI-инфраструктуры:

1. Функция Session Collaboration.

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

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

Для работы этой возможности нужно включить ее на уровне пула виртуальных ПК или фермы серверов RDSH:

Требования к фиче Session Collaboration:

• Протокол VMware Blast Extreme.
• Клиент Horizon Client 4.7 (для Windows, Mac или Linux), а также HTML Access 4.7.
• Максимум 5 одновременных пользователей по умолчанию (это можно увеличить).
• Агент Horizon Agent 7.4 для VDI или RDSH.
• Сервер Horizon 7.4 Connection Server.
• Лицензия на издание Horizon 7 Enterprise Edition.

2. Instant Clones for Linux.

Теперь функция мгновенных клонов доступна и для Linux-систем. Для ее работы должны быть выполнены следующие требования:

• Плавающий (floating) пул десктопов Instant-clone.
• Версия Horizon 7.4 Connection Server и Linux Agent.
• Версия Ubuntu 14.04 или 16.04.
• Интеграция с Active Directory, предоставляемая Power Broker Identity Services Open (PBISO) v8.5.6 или более поздней версией.

3. Фермы RDSH Instant-Clone Farms с поддержкой vGPU.

Теперь фермы серверов RDSH могут быть с поддержкой технологии NVIDIA vGPU. Они могут в полной мере получить преимущества технологии Instant Clone.

На данный момент поддерживаются архитектуры графических карт NVIDIA M10, M60 и P40.

4. Улучшения RSDH Published Applications.

В этой категории были сделаны следующие улучшения:

• Поддержка Hardware GPU для Windows Server 2016.
• Функция USB AutoConnect: позволяет USB-устройствам автоматически подключаться при следующем запуске удаленного приложения.
• Улучшенная производительность запуска приложений - теперь время логина в published applications стало значительно меньше.
• Улучшенный механизм Empty-Session Timeout - теперь можно ставить нулевой таймаут при отключении RDSH-сессий.

5. Улучшенная точность цветов для кодирования H264.

Иногда в сессии кодека H.264 при работе схемы 4:2:2 chroma subsampling могут быть проблемы:

Для улучшения ситуации можно использовать цветовую схему YUV 4:4:4 вместо 4:2:2. Это дает большую ясность восприятия текста, как в примере слева на картинке выше. Включается это в настройках шаблона Blast Extreme ADMX (файл vdm_blast.admx).

5. Улучшения продукта Virtualization Pack for Skype for Business, Update 3.

Напомним, что о прошлых улучшениях мы писали вот тут и тут. Теперь из нового появилось следующее:

• Поддержка клиента Horizon 7 для Mac, включая HID-устройства и аппаратные камеры H.264.
• Интеграция с Microsoft Office - это включает в себя Microsoft SharePoint, Yammer, Microsoft Word и Microsoft Outlook.
• Функция Call Delegation - пользователи могут принимать звонки от имени кого-то или в дополнение к чьему-то вызову (также можно звонить от имени кого-то).
• Функция Call via X (из дома/работы) - пользователь может звонить как внутренний абонент, а также как внешний пользователь.
• Функция Active Speaker Identification - при конференц-звонках выводится видеопоток того, кто говорит в данный момент.
• Функция Volume Control from Remote Desktop - теперь пользователь может изнутри гостевой ОС регулировать громкость звонка.
• Группы ответа (Response Groups) - маршрутизация вызовов в группе пользователей (например, если кому-то звонят, то телефон звонит для всей группы).

6. Улучшения Horizon Client for Chrome OS.

Клиент для хромбуков получил следующие улучшения:

• Поддержка многомониторных конфигураций.
• Несколько одновременных сессий для десктопов и приложений Horizon 7 в бесшовных окнах.
• Drag and drop картинок и текста из телефонов Android в виртуальные машины.

Обо всех прочих улучшениях клиента Horizon Client 4.7 читайте в документации.

Скачать VMware Horizon 7.4 можно по этой ссылке. Release notes доступны тут. А клиентов как всегда можно скачать здесь.

Те из вас, кто следят за ИТ-новостями, наверняка слышали о последних уязвимостях, обнаруженных в процессорах Intel. Одной из таких уязвимостей стала Spectre - она потенциально позволяет локальным приложениям (локальному атакующему, при запуске специальной программы) получить доступ к содержимому виртуальной памяти текущего приложения или других программ.

На днях компания VMware опубликовала обновления для своей платформы VMware vSphere, которые устраняют потенциальные проблемы со Spectre (сама уязвимость описана вот тут).

Исправления для серверов VMware vCenter можно скачать по этим ссылкам:

• VMware vCenter Server 5.5 Update 3g - Release Notes - Загрузить
• VMware vCenter Server 6.0 U3d - Release Notes - Загрузить
• VMware vCenter Server 6.5 U1e - Release Notes - Загрузить

Вы можете скачать как установочный образ:

так и патч к vCenter с VMware Patch Portal (ищите обновление от 9 января):

Для серверов VMware ESXi надо пойти на VMware Patch Portal и загрузить оттуда обновление ESXi650-201801401-BG / ESXi650-201801402-BG. (номер билда 7526125). Подробная информация об обновлении приведена в KB 2151099.

Также данное исправление доступно и для настольных платформ виртуализации VMware:

• VMware Workstation 14.1.1 Pro for Linux - Загрузить
• VMware Workstation 14.1.1 Pro for Windows - Загрузить
• VMware Fusion 10.1.1 (для Intel-based Macs) - Загрузить
• VMware Fusion 8.5.10 (для Mac OS X) - Загрузить

Спасибо нашему читателю Стасу за новость об этих исправлениях.

В декабре прошлого года мы писали о том, что компания VMware выпустила обновление ESXi 6.5 Update 1 Patch 2, а также вскользь упомянули апдейт сервера управления - VMware vCenter 6.5 Update 1d. А вчера в нашей заметке про обновленный vSphere Client наш читатель обратил внимание на статью в блоге VMware, где рассказано о некоторых новых фичах vSphere Client, версия 3.21 которого была включена в состав vCenter 6.5 Update 1d.

Как обычно обновился и документ о различиях vSphere Client и vSphere Web Client на момент 18 декабря прошлого года (то есть до версии vSphere Client 3.31).

Давайте посмотрим, что за фичи есть в HTML5-клиенте, который поставляется с vCenter 6.5 Update 1d, по сравнению с его прошлой версией, включенной в vCenter.

1. Улучшенный вид интерфейса Clarity.

Благодаря новому подходу VMware за счет фреймворка Clarity интерфейс клиента стал более эстетичным и удобным в использовании. Давайте взглянем, например, на возможность переключения между Active и Consumed Memory в vSphere Client:

2. Настройка vSphere Proactive HA.

Ранее это можно было делать только через Web Client, теперь это выглядит удобно и красиво:

3. Появилась настройка Content Library.

Важная фича - добавление уже существующей библиотеки с контентом (например, с другого сервера vCenter):

4. Настройка Network IO Control (NIOC) на VDS.

Теперь это возможно через vSphere Client (вместе с настройкой LAGs и LACP) для vSphere Distributed Switch (VDS), включая изменение параметров шлюза на адаптерах VMkernel:

5. Настройка политик хранения (Storage Policies).

Ранее это было доступно только через Web Client (например, нельзя было создать новую политику в HTML5-клиенте), но теперь можно делать все операции в удобном рабочем процессе для vSphere Client, который, кстати, был упрощен.

6. Управление VIB-пакетами.

Очень удобный раздел, чтобы узнать, какие дополнения в виде VIB-пакетов установлены на хосте ESXi. Доступно по адресу Host –> Configure –> System –> Packages:

7. Управление настройками ВМ и шаблонами.

Теперь в VM Settings можно настраивать все параметры виртуальных машин, включая добавление новых виртуальных устройств, таких как NVMe, SCSI, USB Controller и Host-based USB Adapter. Кроме того, появилась возможность работы с шаблонами (VM Templates).

8. Настройка VM Guest Customization Specifications.

При развертывании ВМ из шаблонов с помощью HTML5-клиента теперь можно использовать спецификацию созданную с помощью встроенного мастера, либо указать уже существующий файл спецификации.

Скачать текущую версию VMware vSphere Client можно по этой ссылке. VMware vCenter 6.5 Update 1d доступен тут.

Компания VMware в первые дни нового года выпустила очередное обновление своего HTML5-клиента для управления виртуальной инфраструктурой - VMware vSphere Client 3.32.

Напомним, что ранее мы писали о возможностях клиента 3.30 и ниже, поэтому приведем новые возможности версий vSphere Client 3.31 и 3.32, где, в основном, из нового - это управление объектами vApp:

• Операции включить/выключить/перезагрузить/приостановить для виртуальных сервисов (vApp) - это показано на рисунке выше.
• Переименование/удаление сервиса vApp.
• Экспорт объекта vApp в шаблон виртуального модуля OVF.
• Отоносящиеся к объектам vApp вкладки VM, datatastore и networking.
• Действие Add Permission для шаблонов ВМ (templates).
• Выбранные счетчики производительности в разделе Performance Charts сохраняются для данного пользователя в локальном хранилище его браузера. Это позволяет не настраивать их заново при открытии новой сессии клиента.
• Исправлены некоторые ошибки.

Скачать VMware vSphere Client можно по этой ссылке.

На днях компания DoubleCloud, выпускающая средства для управления виртуальной средой, обновила свою главню бесплатную утилиту до второй версии - VMDeployer 2.0. Напомним, что это Java-приложение с графическим интерфейсом, позволяющее развернуть виртуальный модуль OVA/OVF с расширенными опциями.

Это удобно для тех администраторов виртуальной инфраструктуры VMware vSphere, у которых не получается развернуть модуль через vSphere Web Client или vSphere Client, либо не хватает его возможностей, а также возможностей консольной утилиты ovftool (кстати, для нее VMDeployer генерирует команды). О версии VMDeployer 1.4 мы писали вот тут.

Давайте посмотрим на новые возможности VMDeployer 2.0:

1. Поддержка VM Migration (только vCener). Теперь вы можете выбрать любую виртуальную машину из списка и переместить ее на любой другой хост ESXi и/или датастор. При этом GUI был сильно упрощен, что экономит время. Также добавилась панель основных операций с ВМ - включение, конфигурация, снапшот и т.п.

2. Панель Recent Tasks. Теперь появилась новая вкладка "Recent Tasks", которая отображает последние задачи целевого сервера, которые выполнялись последние 5 или 10 минут. Также вкладка отображает список похожих задач (similar tasks) - похожая панель существует в vSphere Client и Web Client.

3. Улучшенный Virtual Machine Cloning с поддержкой шаблонов. В прошлых релизах вы выбирали только папку назначения и все - утилита использовала тот же хост-сервер ESXi, пул ресурсов и датастор в качестве исходной виртуальной машины. Это хорошо работает с машинами, но не подходит для шаблонов. Другими словами, таким образом нельзя было развернуть новую ВМ из шаблона, так как у шаблонов нет опции выбора пула ресурсов.

Скачать VMDeployer 2.0 можно по этой ссылке.

От всего авторского коллектива VM Guru поздравляю вас, дорогие коллеги, читатели и партнеры, с Новым 2018 годом и Рождеством!

В этом году мы отпраздновали 11-летие портала, который как был с первого дня, так и остается главным источником информации о технологиях виртуализации и облаках в России. Мы пережили многих и продолжаем развиваться - в первую очередь благодаря нашим рекламодателям, таким как StarWind Software, Veeam Software, ИТ-ГРАД, 5nine Software, Код Безопасности и всем тем, кто поддерживал нас в этом году. Большое вам спасибо, дорогие спонсоры!

Ну и отдельную благодарность я хочу выразить нашим авторам (особенно Роману Гельману) и, конечно же, благодарю всех читателей за то, что остаетесь с нами.

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

С Новым годом и Рождеством 2018!

На сайте проекта VMware Labs появилась новая утилита Cross vCenter Workload Migration Utility, предназначенная для переноса виртуальных машин между виртуальными датацентрами под управлением разных серверов VMware vCenter (поддерживаются как единый SSO-домен, так и разные). Миграция машин происходит за счет возможности Cross-vCenter vMotion.

Основные возможности утилиты:

• Весь рабочий процесс миграции ВМ проводится в графическом интерфейсе.
• Предоставляется REST API для управления процессом миграции.
• Работает для перенесения машин на vCenter, находящийся в другом SSO-домене.
• Поддержка пакетного режима - миграция нескольких ВМ одновременно. Обратите внимание, что контрол называется Virtual Machine(s).
• Поддержка как горячей (vMotion), так и холодной миграции машин.
• Возможно выполнить операцию Storage vMotion, при этом общего хранилища между серверами vCenter не требуется.
• Гибкий маппинг сетей между исходной площадкой и целевой.

Также есть возможность реализации миграции с помощью сценариев PowerCLI (подробнее об этом тут):

Загрузить Cross vCenter vMotion Utility Fling можно по этой ссылке.

Дункан Эппинг и Кормаг Хоган решили сделать своим подписчикам подарок на Рождество - бесплатную книгу VMware vSAN Essentials, которая доступна всем желающим по этой ссылке. Книга, правда, о довольно старой версии vSAN 6.2, вышедшей в начале прошлого года, но большинство информации в ней по-прежнему актуально.

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

Содержание:

• Chapter 1 - Introduction to vSAN
• Chapter 2 - vSAN Prerequisites and Requirements for Deployment
• Chapter 3 - vSAN Installation and Configuration
• Chapter 4 - VM Storage Policies on vSAN
• Chapter 5 - Architectural Details
• Chapter 6 - VM Storage Policies and Virtual Machine Provisioning
• Chapter 7 - Management and Maintenance
• Chapter 8 - Stretched Cluster
• Chapter 9 - Designing a vSAN Cluster
• Chapter 10 - Troubleshooting, Monitoring, and Performance

Скачать книгу можно в разных форматах:

• vSAN 6.2 Essentials PDF
• vSAN 6.2 Essentials EPUB
• vSAN 6.2 Essentials MOBI

На днях компания VMware выпустила пакет обновления к VMware ESXi 6.5 Update 1, именуемый как Patch 02, добавляющий несколько новых возможностей к решению для создания отказоустойчивых кластеров хранилищ VMware vSAN. Более подробно об этом патче написано в KB 51891.

Новое обновление ESXi включaет в себя следующие фичи vSAN:

• Продукт vSAN Support Insight - эта фича показана в видео выше. Она позволяет пользователям, участвующим в программе CEIP (Customer Experience Improvement Program) получить доступ к расширенной аналитике vSAN в целях решения проблем. Средствами Support Insight сотрудники техподдержки VMware могут исследовать окружения пользователей, понимать их конфигурацию, статус исполнения, производительность и прочие детали в масштабе времени близком к реальному. Документация по этой фиче доступна тут.

Выглядит это примерно следующим образом:

• Технология Adaptive resynchronization – функция Adaptive Resync адаптивно изменяет долю полосы пропускания, выделенную для канала ресинхронизации Resync I/O, чтобы минимизировать негативное влияние на работу клиентского канала ввода-вывода. За счет этого в периоды меньшей загрузки (выходные) канал для ресинхронизации используется больше, а во время часов пик - меньше.
• Поддержка доступа по нескольким путям для SAS-систем. Теперь из коробки поддерживается multipathing для SAS c запасными путями. Пример такого хранилища - HPE Synergy.

Скачать VMware ESXi 6.5 Patch 2 можно c VMware Patch Portal по этой ссылке (надо выбрать релиз ESXi650-201712001 с номером билда 7388607).

Более детальная информация об обновлении приведена тут.

Также вышел и vCenter Server 6.5 Update 1d - там ничего нового, кроме обновлений отдельных компонентов.

Компания VMware после очень долгого перерыва выпустила новую версию своего главного продукта для перенесения физических серверов в виртуальную среду - VMware vCenter Converter Standalone 6.2. Напомним, что прошлая версия этого средства вышла почти два года назад (мы писали о vCenter Converter Standalone 6.1 вот тут) - и никто не переживал по этому поводу.

Давайте посмотрим, что нового VMware добавила в Converter за прошедшие почти 2 года:

• Поддержка целевых хостов VMware vSphere 6.5 Update 1.
• Поддержка новых ОС физических серверов - Windows Server 2016 и Ubuntu 16.
• Новая конфигурация для миграции Linux-серверов. Теперь можно указать путь ко временным файлам vmware-sysinfo, которые будут распакованы и запущены.
• Новая опция, позволяющая изменить дефолтный тип диска целевой виртуальной машины с thick ("толстого") на thin ("тонкий"). Для этого нужно отредактировать файл converter-worker.xml.

Не так уж и много, да? Похоже, конвертером особо никто не занимался... Таким образом, список поддерживаемых конвертеров операционных систем выглядит так:

• Windows Vista SP2 до Windows 10
• Windows Server 2008 SP2 до Windows Server 2016
• CentOS 6.x and 7.0
• Red Hat Enterprise Linux 4.x up to 7.x
• SUSE Linux Enterprise Server 10.x and 11.x
• Ubuntu 12.04 LTS, 14.04 LTS, and 16.04 LTS

Офлайн конверсия машин с Microsoft Hyper-V может быть проведена для следующих ОС:

• Windows Server 2008 R2 (64-bit)
• Windows Server 2012 (64-bit)
• Windows Server 2012 R2 (64-bit)
• Windows 10 (64-bit)
• Windows Server 2016 (64-bit)

Более подробно о новой версии VMware vCenter Converter Standalone 6.2 написано в Release Notes, скачать продукт можно по этой ссылке.

На днях компания VMware выпустила очередное обновление средства интеграции с гостевыми ОС виртуальных машин - VMware Tools 10.2.0. Напомним, что о прошлом релизе тулзов (10.1) мы писали вот тут. Кстати, у нас в последнее время было несколько интересных статей на тему этого пакета, например - раз, два и три.

Давайте посмотрим, что нового появилось в VMware Tools 10.2:

• Офлайн бандл VMware Tools VIB-пакета: его можно установить на vSphere 5.5.x, 6.0.x and 6.5.x через vSphere Update Manager.
• Поддерживаемые ОС:
  • windows.iso - поддерживает Windows Vista и более поздние.
  • linux.iso - поддерживает Red Hat Enterprise Linux (RHEL) 5 и более поздние, SUSE Linux Enterprise Server (SLES) 11 и новее, Ubuntu 10.04 и новее. Также поддерживаются дистрибутивы Linux - c glibc версии 2.5 и новее.
  • darwin.iso - поддерживает Mac OS X 10.11 и новее.
  • solaris.iso - для гостевых ОС Solaris.
• Улучшенное управление жизненным циклом VMware Tools: теперь Microsoft System Center Configuration Manager (SCCM) можно использовать для распространения и обновления VMware Tools. Для получения детальной информации смотрите статью Deploying VMware Tools using SCCM.
• Убрана поддержка FreeBSD. Это сделано для того, чтобы перенести ее в пакет open-vm-tools. Подробнее об этом читайте у нас тут.
• Поддержка ASLR (Address space layout randomization).
• Пофикшены ошибки. Для этого смотрите секцию Resolved Issues в Release notes.

Напомним, что для VMware Tools, начиная с версии 10.1, доступна подробная документация. Обновлять VMware Tools лучше через VMware Update Manager. Кстати, в онлайн-репозитории VMware версии 10.2 на момент написания заметки еще не было, но скоро он должен обновиться.

Часто администраторы виртуальной инфраструктуры VMware vSphere испытывают необходимость увеличить размер виртуального диска VMDK, который защищен технологией репликации VMware vSphere Replication. Если попытаться увеличить диск из vSphere Client, то вы получите вот такую ошибку:

vSphere Replication does not support changing the length of a replicated disk

Поэтому для увеличения реплицируемого VMDK-диска нужно сделать следующее:

• Переименуйте папку с виртуальной машиной и виртуальным диском на резервном сайте. Это нужно для того, чтобы при отключении репликации папка с ВМ на резервной площадке не удалилась.
• Запомните настройки репликации ВМ (RPO, датастор назначения и т.п.).
• Отключите репликацию виртуальной машины.
• Увеличьте размер виртуального диска на основной площадке из GUI vSphere Web Client через Edit Settings.
• Теперь увеличьте размер виртуального диска на резервной площадке с помощью утилиты vmkfstools. Для этого выполните команду:

vmkfstools –X 50G virtual_machine.vmdk

• Далее на резервном сайте переименуйте папку с ВМ обратно к исходному имени.
• Настройте репликацию ВМ заново, выбрав пункт Specify datastore folder и указав папку с ВМ, которую будете реплицировать. Появится сообщение:

A file with the name ‘[<datastore>] <folder>/<filename> already exists. Press Yes to use file as an initial copy.

• Нажимайте Yes и репликация должна завестись.

Если вы не увеличите размер виртуального диска на резервной площадке, то получите вот такое сообщение об ошибке:

The capacity of the seed disk does not match the capacity of the replication source disk. Create a new seed copy or verify that you selected the correct seed to use for this replication

Поэтому не пропускайте этот шаг. Также о процедуре написано в KB 2052883.

Недавно мы писали о полезных утилитах командной строки виртуального модуля VMware vCenter Server Appliance (vCSA), которые могут пригодиться при ежедневном администрировании виртуальной инфраструктуры VMware vSphere. А сегодня поговорим о сервисах vCSA - как они запускаются, и как ими управлять.

Первичный порядок загрузки служб vCenter Server Appliance выглядит следующим образом (приведены в порядке запуска):

• lwsmd (Likewise Service Manager)
• vmafdd (VMware Authentication Framework)
• vmdird (VMware Directory Service)
• vmcad (VMware Certificate Service)
• vmware-sts-idmd (VMware Identity Management Service)
• vmware-stsd (VMware Security Token Service)
• vmdnsd (VMware Domain Name Service)
• vmware-psc-client (VMware Platform Services Controller Client)
• vmon (VMware Service Lifecycle Manager)

А где же такие службы, как vmware-vpostgres, vpxd и прочие? Все просто - их запускает служба vmon. Это новый watchdog-сервис, который управляет службами vCSA в vSphere 6.5 и унифицирует доступ к ним через API.

Чтобы увидеть, в каком порядке она запускает прочие сервисы, выполним команды vmon-cli для остановки и запуска служб vmon на сервере vCSA:

/usr/lib/vmware-vmon/vmon-cli --batchstop ALL 

/usr/lib/vmware-vmon/vmon-cli --batchstart ALL

Вывод будет примерно таким:

root@vc01 [ /var/log/vmware/vmon ]# grep "Executing op START on service" vmon-sys 

17-12-12T09:44:23.639142+00:00 notice vmon Executing op START on service eam... 

17-12-12T09:44:23.643113+00:00 notice vmon Executing op START on service cis-license... 

17-12-12T09:44:23.643619+00:00 notice vmon Executing op START on service rhttpproxy... 

17-12-12T09:44:23.644161+00:00 notice vmon Executing op START on service vmonapi... 

17-12-12T09:44:23.644704+00:00 notice vmon Executing op START on service statsmonitor... 

17-12-12T09:44:23.645413+00:00 notice vmon Executing op START on service applmgmt... 

17-12-12T09:44:26.076456+00:00 notice vmon Executing op START on service sca... 

17-12-12T09:44:26.139508+00:00 notice vmon Executing op START on service vsphere-client... 

17-12-12T09:44:26.199049+00:00 notice vmon Executing op START on service cm... 

17-12-12T09:44:26.199579+00:00 notice vmon Executing op START on service vsphere-ui... 

17-12-12T09:44:26.200095+00:00 notice vmon Executing op START on service vmware-vpostgres... 

17-12-12T09:45:33.427357+00:00 notice vmon Executing op START on service vpxd-svcs... 

17-12-12T09:45:33.431203+00:00 notice vmon Executing op START on service vapi-endpoint... 

17-12-12T09:46:54.874107+00:00 notice vmon Executing op START on service vpxd... 

17-12-12T09:47:28.148275+00:00 notice vmon Executing op START on service sps... 

17-12-12T09:47:28.169502+00:00 notice vmon Executing op START on service content-library... 

17-12-12T09:47:28.176130+00:00 notice vmon Executing op START on service vsm... 

17-12-12T09:47:28.195833+00:00 notice vmon Executing op START on service updatemgr... 

17-12-12T09:47:28.206981+00:00 notice vmon Executing op START on service pschealth... 

17-12-12T09:47:28.220975+00:00 notice vmon Executing op START on service vsan-health...

Как мы видим, службы запускаются в следующем порядке:

• eam (VMware ESX Agent Manager)
• cis-license (VMware License Service)
• rhttpproxy (VMware HTTP Reverse Proxy)
• vmonapi
• statsmonitor
• applmgmt
• sca (VMware Service Control Agent)
• vsphere-client
• cm
• vsphere-ui
• vmware-vpostgres (VMware Postgres)
• vpxd-svcs
• vapi-endpoint
• vpxd (VMware vCenter Server)
• sps (VMware vSphere Profile-Driven Storage Service)
• content-library
• vsm
• updatemgr
• pschealth
• vsan-health

Утилиту vmon-cli можно использовать для запуска и остановки этих сервисов в следующем формате:

/usr/lib/vmware-vmon/vmon-cli -r ServiceName

Например, чтобы перезагрузить vSphere Client, можно использовать команду:

/usr/lib/vmware-vmon/vmon-cli -r vsphere-client

А вы знали, что резервные копии vCSA имеют срок годности? Вот и я тоже нет. Скажу вам больше, не все инженеры технической поддержки VMware GSS знают об этом! На самом деле то, что имеет срок годности — это пароль учётной записи root внутри OVF template на инсталляционном диске vCSA ISO! Я тоже был удивлён, но VMware называет это известной проблемой “known issue” в своей KB51124.

Известный своими скриптами блоггер Luc Dekens (LucD) опубликовал интересный сценарий PowerCLI для виртуальной инфраструктуры VMware vSphere, который позволяет вычистить права доступа на объекты, для которых уже существуют права на уровне родительских объектов.

Например, у вас есть такая картина:

Соответственно, нам нужно почистить пермиссии в папке Test1131 для пользователя Local\test, чтобы разрешения остались только на уровне родительского объекта Test1 (там, как мы видим, установлена опция применения разрешений вниз к дочерним объектам).

Собственно, сам скрипт:

<#
.SYNOPSIS
  Find and remove redundant permissions on vSphere objects 
.DESCRIPTION
  The function will recursively scan the permissions on the
  inventory objects passed via the Entity parameter.
  Redundant permissions will be removed.
.NOTES
  Author:  Luc Dekens
.PARAMETER Entity
  One or more vSphere inventory objects from where the scan
  shall start
.EXAMPLE
  PS> Optimize-Permission -Entity Folder1 -WhatIf
.EXAMPLE
  PS> Optimize-Permission -Entity Folder?
.EXAMPLE
  PS> Get-Folder -Name Folder* | Optimize-Permission
#>
 
  [cmdletbinding(SupportsShouldProcess=$true)]
  param(
    [parameter(ValueFromPipeline)]
    [PSObject[]]$Entity
  )
 
  Begin{
    function Optimize-iVIPermission{
      [cmdletbinding(SupportsShouldProcess=$true)]
      param(
        [parameter(ValueFromPipeline)]
        [VMware.Vim.ManagedObjectReference]$Entity,
        [VMware.Vim.Permission[]]$Permission = $null
      )
 
      Process{
        $entityObj = Get-View -Id $Entity
        $removePermission = @()
        $newParentPermission = @()
        if($Permission){
          foreach($currentPermission in $entityObj.Permission){
            foreach($parentPermission in $Permission){
              if($parentPermission.Principal -eq $currentPermission.Principal -and
                 $parentPermission.RoleId -eq $currentPermission.RoleId){
                $removePermission += $currentPermission
                break
              }
              else{
                $newParentPermission += $currentPermission
              }
            }
          }
        }
        else{
          $newParentPermission += $entityObj.Permission
        }
        if($removePermission){
          if($pscmdlet.ShouldProcess("$($entityObj.Name)", "Cleaning up permissions")){
            $removePermission | %{
              $authMgr.RemoveEntityPermission($Entity,$_.Principal,$_.Group)
            }
          }
        }
        $Permission += $newParentPermission
       
        if($entityObj.ChildEntity){
            $entityObj.ChildEntity | Optimize-iVIPermission -Permission $Permission
        }
      }
    }
  }
 
  Process{
    foreach($entry in $Entity){
       if($entry -is [System.String]){
        $entry = Get-Inventory -Name $entry
       }
       Optimize-iVIPermission -Entity $entry.ExtensionData.MoRef
    }
  }
}

Скрипт работает так, что пробегается по дереву объектов, обнаруживает избыточные разрешения и удаляет их. У скрипта есть удобный параметр WhatIf, который выводит операции по очистке разрешений, которые как бы применяются к дочерним объектам, но на самом деле не применяет их:

Optimize-VIPermission -Entity Test1 -WhatIf

Результатом будет список объектов, где разрешения будут очищены, в данном случае, если посмотреть на пример выше, это будет папка Test1131:

Можно запустить скрипт и на 2 папки сразу:

Optimize-VIPermission -Entity Test1,Test2 -WhatIf

Результат будет таким (в папке Test22 также есть дублирующиеся разрешения):

Также можно использовать и конструкции с масками, например:

Get-Folder -Name Test? | Optimize-VIPermission -WhatIf

Теперь неплохо было бы, если бы кто-то написал GUI к этой штуке, а также добавил туда функции поиска и удаления произвольных разрешений в выбранных объектах.

Недавно мы писали о том, что такое и как работает механизм отказоустойчивости VMware vCenter Server Appliance High Availability (vCHA), защищающий виртуальные модули vCenter Server Appliance (vCSA) в случае программных и аппаратных сбоев.

Там мы рассказывали, что vCHA - это Active/Passive кластер, который состоит из трех компонентов - активного узла, работающего под нагрузкой, пассивного, готового взять на себя нагрузку в случае сбоя активного, а также компонента Witness ("свидетель") - который защищает кластер от ситуации split-brain (оба узла считают себя активными в случае изоляции сети) и является кворумным узлом:

Напомним, что кворумный узел не может получить роль сервера vCenter, это лишь маленькая машина, реализующую функцию Witness в ситуациях изоляции и разделения сети.

Если посмотреть на архитектуру решения, то можно понять, что оно не использует сеть хранения для сигналов доступности и не рассчитано на множественные сбои, что позволит гарантированно сохранить или восстановить работоспособность только в случае отказа/изоляции лишь одного из компонентов. Если, например, вся сеть развалится между всеми тремя узлами - vCHA вас не спасет.

С точки зрения синхронизации, кластер vCHA использует синхронную репликацию PostgreSQL native replication для синхронизации базы данных (в случае отказа БД будет консистентная) и утилиту rsync для репликации файлов vCenter (например, файлов конфигурации):

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

Оба узла vCSA в кластере vCHA используют один публичный IP-адрес, который используется при доступе и к резервному узлу в случае сбоя основного. В условия восстановления работоспособности сервера vCSA заложен показатель RTO=5 минут. Это значит, что в случае сбоя основного узла, где-то 5 минут пользователи могут испытывать проблемы с доступностью vCenter через vSphere Client или vSphere Web Client. При этом API vCenter будет доступен уже где-то через 2-3 минуты.

Теперь давайте посмотрим, как обрабатываются механизмом vCHA различные варианты отказов:

• Отказ активного узла. В этом случае пассивный узел видит, что активный узел больше недоступен, при этом узел Witness работает и доступен. Пассивный узел назначает себя активным и начинает обслуживать запросы клиентов vSphere.
• Отказ пассивного узла. Поскольку активный узел и Witness чувствуют себя нормально, сервер vCenter продолжит обслуживание клиентов.
• Отказ узла Witness. В этом случае сохранится статус кво - активный узел продолжит обрабатывать запросы, а пассивный будет готов взять на себя нагрузку в случае сбоя активного.
• Изоляция или отказ более чем одного узла. В этом случае вполне может возникнуть ситуация, когда у вас сервисы vCenter не функционируют - например, оба узла vCSA могут посчитать себя изолированными (см. далее).

Поведение изолированного узла vCSA при изоляции

Как только узел себя считает изолированным, он сразу гасит все сервисы vCenter, чтобы второй узел мог взять на себя нагрузку по обслуживанию запросов (при этом неважно, видит ли второй узел компонент Witness). При детектировании события изоляции учитываются возможные короткие промежутки в доступности сети, которые могут иногда возникать при нормальном сетевом взаимодействии. Только когда все попытки достучаться до второго узла и Witness исчерпаны, узел vCSA считает себя изолированным.

Ну и, напоследок, порекомендуем документ "vCenter Server 6.5 High Availability Performance and Best Practices", о котором мы писали вот тут.

Как знают администраторы VMware vSphere, с выходом каждой новой версии платформы увеличиваются и максимумы для ее компонентов. Многие из этих максимумов трудно достижимы на практике, поскольку еще нет серверов такой возможности (например, для запуска такого количества машин в производственной среде), но некоторые аспекты требуют того, чтобы лимиты параметров были увеличены (например, число vNIC на одну машину иногда для тестирования нужно больше).

Давайте взглянем на эволюцию максимумов VMware vSphere в таблицах ниже, где отображены параметры версии 5.5, 6.0 и 6.5:

Максимумы виртуальных машин

Максимумы вычислительных мощностей VMware ESXi

Максимумы хранилищ VMware ESXi

Максимумы сетевого взаимодействия VMware ESXi

Мы часто пишем о виртуальном модуле VMware vCenter Server Appliance (vCSA), который представляет собой готовую виртуальную машину для управления виртуальной инфраструктурой VMware vSphere (напомним, что это полноценная замена vCenter for Windows).

Сегодня мы покажем несколько интересных утилит командной строки vCSA, которые могут помочь вам в ежедневной эксплуатации этого управляющего сервиса.

1. Просмотр журнала Cron.

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

ls -l /var/spool/cron/lastrun/

Для сравнения ниже приведен вывод этой команды совместно с выводом текущей даты:

vc:~ # date

Mon Dec 4 12:55:39 CET 2017

vc:~ # ls -l /var/spool/cron/lastrun/

total 0

-rw------- 1 root root 0 Dec 3 20:00 cron.daily

-rw------- 1 root root 0 Dec 4 12:15 cron.hourly

-rw------- 1 root root 0 Dec 1 20:00 cron.weekly

Как мы видим, крон успешно выполнялся для ежечасной задачи, ежедневной и еженедельной. Если же крон отвалился, то значит, скорее всего, устарел пароль root. Узнать это можно следующей командой:

grep "Authentication token is no longer valid; new one required" /var/log/messages.0.log | head

Если в выводе этой команды будет что-то вроде этого:

<timestamp> vcenter /usr/sbin/cron[<ID>]: Authentication token is no longer valid; new one required

значит пароль root устарел.

2. Смена устаревшего пароля root.

Если ваш пароль root устарел, и крон-таски vCSA не запускаются, то сменить его проще всего будет следующей командой (обратите внимание, что это НЕ слово change):

chage -l root

У вас запросят старый пароль и попросят задать новый:

Password change requested. Choose a new password.

Old Password:

New password:

После этого можно снова вывести срок действия пароля с помощью chage (тут видно, что он устареет через 99999 дней, то есть 274 года):

vc:~ # chage -l root

Minimum: 0

Maximum: 99999

Warning: 7

Inactive: -1

Last Change: Dec 27, 2016

Password Expires: Never

Password Inactive: Never

Account Expires: Never

3. Перезапуск служб vCSA.

Если вы хотите поправить странное поведение vCSA, которое может быть связано с некорректным поведением сервисов Linux внутри виртуального модуля, то можно перезапустить все службы:

service-control --stop --all

service-control --start --all

Можно перезапустить, например, только vSphere Client:

service-control --stop vsphere-client

Список запущенных служб узнается так:

service-control --list

А вот так узнается статус того или иного сервиса:

service-control --status

4. Работа с LVM

Если вам надо увеличить виртуальные диски VMDK, а потом расширить тома LVM, то можете прочитать вот эту нашу статью. Чтобы не использовать API Explorer или PowerCLI, можно выполнить следующую команду для просмотра томов LVM:

lsblk

Далее вы получите примерно следующее:

vc:~ # lsblk

NAME MAJ:MIN RM SIZE RO MOUNTPOINT

sda 8:0 0 20G 0

??sda1 8:1 0 132M 0 /boot

??sda2 8:2 0 1G 0 [SWAP]

??sda3 8:3 0 10.9G 0 /

sdb 8:16 0 1.4G 0

sdc 8:32 0 25G 0

??swap_vg-swap1 (dm-8) 253:8 0 25G 0 [SWAP]

sdd 8:48 0 50G 0

??core_vg-core (dm-7) 253:7 0 50G 0 /storage/core

sde 8:64 0 10G 0

??log_vg-log (dm-6) 253:6 0 10G 0 /storage/log

sdf 8:80 0 10G 0

??db_vg-db (dm-5) 253:5 0 10G 0 /storage/db

sdg 8:96 0 5G 0

??dblog_vg-dblog (dm-4) 253:4 0 5G 0 /storage/dblog

sdh 8:112 0 25G 0

??seat_vg-seat (dm-3) 253:3 0 25G 0 /storage/seat

sdi 8:128 0 1G 0

??netdump_vg-netdump (dm-2) 253:2 0 1016M 0 /storage/netdump

sdj 8:144 0 10G 0

??autodeploy_vg-autodeploy (dm-1) 253:1 0 10G 0 /storage/autodeploy

sdk 8:160 0 10G 0

??invsvc_vg-invsvc (dm-0) 253:0 0 10G 0 /storage/invsvc

fd0 2:0 1 4K 0

sr0 11:0 1 1024M 0

Для идентификации дисковых устройств и их типов можно выполнить следующее:

lsscsi

Вывод будет примерно таков:

vc:~ # lsscsi

[0:0:0:0] disk VMware Virtual disk 1.0 /dev/sda

[0:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb

[0:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc

[0:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd

[0:0:4:0] disk VMware Virtual disk 1.0 /dev/sde

[0:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf

[0:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg

[0:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh

[0:0:10:0] disk VMware Virtual disk 1.0 /dev/sdi

[0:0:12:0] disk VMware Virtual disk 1.0 /dev/sdj

[0:0:14:0] disk VMware Virtual disk 1.0 /dev/sdk

[1:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0

Когда вы поймете, какой том нужно увеличить, выполните команду:

vpxd_servicecfg storage lvm autogrow

Надо помнить, что это сработает только для томов под управлением LVM (например, для disk 1 (sda) с разделом / - не сработает).

5. Поиск "загрязняющих" файлов.

Чтобы найти логи, которые могут засорить корневой раздел или раздел /storage/log, выполните одну из следующих команд:

du -a /var | sort -n -r | head -n 10
du -a /storage/log | sort -n -r | head -n 10

6. Изменение режима ротации логов (Log Rotation).

Сначала перейдем в папку с логами:

cd /etc/logrotate.d

Далее сделаем бэкап настроек:

cp dnsmasq ./dnsmasq.old

Затем откроем настройки:

vi dnsmasq

И поменяем слово "weekly" (еженедельно) на "daily" (ежедневно), например:

/var/log/dnsmasq.log {

daily

missingok

notifempty

delaycompress

sharedscripts

postrotate

[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 cat /var/run/dnsmasq.pid

endscript

create 0640 dnsmasq dnsmasq

После этого можно удалить старый большой лог следующими командами:

cd /var/log

rm dnsmasq.log

7. Удаление файлов, которые не удалились.

Бывает так, что вы удалили большой файл, а дисковое пространство не высвободилось - и это видно командой df -h. Это происходит потому, что какой-то из процессов в памяти еще держит файл (при этом не обязательно использует его). Чтобы узнать, что это за процесс выполняем команду:

lsof | grep deleted

Вывод будет примерно таким:

postgres 8860 vpostgres 10u REG 253,4 16777216 16395 /storage/dblog/vpostgres/pg_xlog/000000010000011900000041 (deleted)

Видим, что это Postgres держит файл, поэтому если он нам сейчас не нужен, убиваем процесс:

kill -9 <PID>

После этого вы увидите, что свободного дискового пространства на сервере vCSA стало больше.

С начала ноября мы не писали про тонкий клиент на базе HTML5 для управления виртуальной инфраструктурой - VMware vSphere Client (тогда он был версии 3.27). На днях компания VMware выпустила его версию 3.30, поэтому давайте рассмотрим новые возможности, которые появились в последних трех версиях клиента - VMware vSphere Client 3.28-3.30.

Итак, что нового:

• Просмотр имеющихся лицензий (Host/Cluster/функции Solutions) - пока работает в режиме Read-Only.
• Доступны детали лицензированных продуктов и их фичей.
• Детали лицензий сервера vCenter и хостов ESXi (Host License) - доступно в разделе Configure > Licensing.
• Проверки состояния vSphere Distributed Switch (vDS health checks).
• Настройка фильтрации трафика и правил его маркировки на уровне распределенных порт-групп.
• Экспорт и импорт распределенных виртуальных коммутаторов (vDS) и распределенных порт-групп.
• Настройка политик распределенных порт-групп внутри мастера создания новой порт-группы.
• Настройка CPU Identification Mask в разделе Advanced.
• Выбор паравиртуализованного сетевого адаптера PVRDMA для сети виртуальных машин.

Скачать последнюю версию VMware vSphere Client 3.30 можно по этой ссылке.

Cormac Hogan написал занимательный пост о об использовании дискового пространства в кластере VMware vSAN. Всех интересует - умеет ли vSAN возвращать дисковое пространство хранилищу при удалении файлов в гостевой ОС виртуальной машины? Ответ - пока нет, но над этим работают.

Cormac провел вот какой эксперимент: взял виртуальную машину в кластере vSAN с гостевой ОС Windows Server 2012 R2, у которой было 386.7 ГБ занятого места (сама ВМ была развернута на тонких дисках):

Затем он скопировал туда данные на 800 МБ, после чего увидел, что занятое место увеличилось до 388.37 ГБ, то есть выросло на 1,6 ГБ. Это логично, так как vSAN работал в режиме RAID-1 (зеркалированные VMDK-диски):

Далее он удалил только что скопированные файлы и убедился, что занятое дисковое пространство осталось тем же самым (то есть, в vSAN нет поддержки UNMAP/TRIM изнутри гостевой системы):

Между тем, он снова скопировал те же 800 МБ и к радости администраторов заметил, что дисковое пространство увеличилось лишь на 20 МБ (в совокупности на 40 МБ с учетом RAID-1).

То есть занятые после прошлого копирования блоки были использованы повторно:

Такая штука есть у Windows Server, но у Linux в файловой системе ext4 такой трюк не прокатит - все равно при повторном копировании блоки разместятся в другом месте, и пространство будет использовано повторно. Но это особенность файловой системы ext4, об этом подробно написано тут и тут. Для ФС ext3 и XFS это не актуально, там блоки тоже будут переиспользоваться.

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

Недавно компания VMware опубликовала интересный документ, описывающий референсную архитектуру решения для виртуализации и доставки виртуальных ПК и приложений - "Horizon 7 Enterprise Edition Multi-Site Reference Architecture". Он предназначен для тех Enteprise-администраторов, которые планируют построение распределенной VDI-инфраструктуры для VDI-пользователей на базе двух географически разделенных площадок.

Цель подобных документов (Reference Architecture) - показать на высоком уровне возможные сферы применения продукта для построения указанной архитектуры (в данном случае - отказо и катастрофоустойчивости), а также валидировать ее дизайн и соответствие его решаемым задачам.

Вот какие кейсы раскрываются и сравниваются в документе:

С точки зрения рассматриваемых архитектур, в документе приводятся следующие варианты использования:

1. Архитектура Active/Active и Active/Passive для сервисов.

Тут Windows-сервис пользователю доставляется в виде терминальной сессии на RDS-хосте, либо через виртуальную машину, которая реплицируется на другой хост. Приложения, которые развертываются в ВМ в виде подключаемых виртуальных дисков App Volumes, также реплицируются. Опционально настраивается также репликация профилей пользователей и их данных.

В этом случае пользователи могут получить доступ к своим данным и приложениями через любую площадку, которая ему географически ближе:

А вот так выглядит в этом случае архитектура Active/Passive, которая берет на себя нагрузку только с случае отказа основной площадки:

2. Архитектура Active/Active и Active/Passive для приложений через App Volumes.

В этом случае можно использовать хосты RDS и подключать к ним тома App Volumes напрямую с приложениями при загрузке серверов, либо при логине пользователей. Пользователь может использовать свои приложения при соединении с любой площадкой:

А так выглядит отказоустойчивая архитектура Active/Passive для AppVolumes:

3. Архитектура Active/Active для профилей пользователей.

В этом случае можно обеспечить отказо и катастрофоустойчивость данных пользователей и их профилей при использовании доставляемых через RDSH-сервисы приложений.

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

4. Резервирование рабочего пространства Workspace ONE.

Workspace ONE - это веб-портал, через который пользователь корпоративной ИТ-инфраструктуры посредством SSO получает доступ к своим приложениям. Здесь используется решение VMware Identity Manager и репликация баз данных этого продукта средствами SQL AlwaysOn:

Ну и главное, что рассматриваются все аспекты переключения VDI-инфраструктуры на резервную площадку в контексте хранилищ, сетей и серверов:

Ну а все технические подробности и детали настройки конфигураций приведены в интересном 136-страничном документе.

Некоторое время назад мы писали о том, как делать резервное копирование и восстановление базы данных сервера vCenter Server и виртуального модуля vCenter Server Appliance (vCSA). А сегодня мы поговорим о том, как сделать бэкап всей виртуальной машины vCSA с помощью средств PowerCLI.

Для начала напомним, что простейший способ бэкапить сервер vCSA - это сделать его резервную копию в графическом интерфейсе на вкладке Summary:

Но если вам нужно резервное копирование и восстановление с помощью сценариев PowerCLI, то для этого можно использовать функцию Backup-VCSAToFile, о которой Brian Graf рассказывал вот тут. Бэкап может проводиться в следующие хранилища назначения:

• FTP
• FTPS
• HTTP
• HTTPS
• SCP

Для управления процессом резервного копирования можно использовать следующие функции:

• Backup-VCSAToFile
• Get-VCSABackupJobs
• Get-VCSABackupStatus

Отрабатывает Backup-VCSAToFile следующим образом:

Некто Magnus Andersson на базе функции Backup-VCSAToFile создал вот такой скрипт попроще, который позволяет забэкапить сервер vCSA, задав в заголовке сценария несколько параметров:

• Сервер бэкапов и директория
• Имя пользователя и пароль на хранилище назначения
• Тип бэкапа - Fullbackup (полный) или Seatbackup (только конфигурация vCSA)
• Пароль к файлу бэкапа, который понадобится при восстановлении
• Тип хранилища бэкапа
• Комментарий

Пользоваться скриптом просто, вот он:

# Script to backup vCenter Server Appliance
# Author: Magnus Andersson - Sr Staff Solutions Engineer @Nutanix
# Version 1.0
# Created 2017-11-15
# Kudos to Brian Graf for creating the Backup-VCSAToFile function, used in this script, which can be found here Backup-VCSAToFile Function Created By Brian Graf - https://www.brianjgraf.com/2016/11/18/vsphere-6-5-automate-vcsa-backup/
#
#--------------------------------------------
# User Defined Variables Sections Starts Here
#
# Specify vCenter Server, vCenter Server User name and vCenter Server Password
$vcsa="vcsa01.vcdx56.local"
$vcsauser="vcsabkpuser@vsphere.local"
$vcsapasswd="TopSecret76!"
# 
# Backup location
$bkpserver="10.10.100.199/vcsabackups/"
$bkpdir=get-date -uformat %Y-%m-%d
$bkpLocation=$bkpserver+$bkpdir
#
# Specify backup location user and password
$LocationUser="ftps-user"
$LocationPasswd="TopSecret67!"
#
# Specify backup type where Fullbackup is 1 and Seatbackup is 2
$BackupType=2
#
# Specify backup password - needed when performing restore
$bkpPassword="TopSecret68!"
#
# Specify backup localtion type where you must specify HTTP, HTTPS, SCP, FTP or FTPS
$LocationType="FTPS"
#
# Specify Backup Comment
$Comment="vCenter Server Appliance vcsa01.vcdx56.local backup"
#
# User Defined Variables Sections Ends Here
#--------------------------------------------
#
# Import Module VMware.VimAutomation.Cis.Core
Import-module VMware.VimAutomation.Cis.Core
#
# #--------------------------------------------
# Import Backup-VCSAToFile Function
Function Backup-VCSAToFile {
    param (
        [Parameter(ParameterSetName=’FullBackup’)]
        [switch]$FullBackup,
        [Parameter(ParameterSetName=’SeatBackup’)]
        [switch]$SeatBackup,
        [ValidateSet('FTPS', 'HTTP', 'SCP', 'HTTPS', 'FTP')]
        $LocationType = "FTP",
        $Location,
        $LocationUser,
        [VMware.VimAutomation.Cis.Core.Types.V1.Secret]$LocationPassword,
        [VMware.VimAutomation.Cis.Core.Types.V1.Secret]$BackupPassword,
        $Comment = "Backup job",
        [switch]$ShowProgress
    )
    Begin {
        if (!($global:DefaultCisServers)){ 
            [System.Windows.Forms.MessageBox]::Show("It appears you have not created a connection to the CisServer. You will now be prompted to enter your vCenter credentials to continue" , "Connect to CisServer") | out-null
            $Connection = Connect-CisServer $global:DefaultVIServer 
        } else {
            $Connection = $global:DefaultCisServers
        }
        if ($FullBackup) {$parts = @("common","seat")}
        if ($SeatBackup) {$parts = @("seat")}
    }
    Process{
        $BackupAPI = Get-CisService com.vmware.appliance.recovery.backup.job
        $CreateSpec = $BackupAPI.Help.create.piece.CreateExample()
        $CreateSpec.parts = $parts
        $CreateSpec.backup_password = $BackupPassword
        $CreateSpec.location_type = $LocationType
        $CreateSpec.location = $Location
        $CreateSpec.location_user = $LocationUser
        $CreateSpec.location_password = $LocationPassword
        $CreateSpec.comment = $Comment
        try {
            $BackupJob = $BackupAPI.create($CreateSpec)
        }
        catch {
            Write-Error $Error[0].exception.Message
        }
            

        If ($ShowProgress){
            do {
                $BackupAPI.get("$($BackupJob.ID)") | select id, progress, state
                $progress = ($BackupAPI.get("$($BackupJob.ID)").progress)
                Write-Progress -Activity "Backing up VCSA"  -Status $BackupAPI.get("$($BackupJob.ID)").state -PercentComplete ($BackupAPI.get("$($BackupJob.ID)").progress) -CurrentOperation "$progress% Complete"
                start-sleep -seconds 5
            } until ($BackupAPI.get("$($BackupJob.ID)").progress -eq 100 -or $BackupAPI.get("$($BackupJob.ID)").state -ne "INPROGRESS")

            $BackupAPI.get("$($BackupJob.ID)") | select id, progress, state
        } 
        Else {
            $BackupJob | select id, progress, state
        }
    }
    End {}
}
#
#--------------------------------------------
# Create passwords
[VMware.VimAutomation.Cis.Core.Types.V1.Secret]$BackupPassword=$bkpPassword
[VMware.VimAutomation.Cis.Core.Types.V1.Secret]$LocationPassword=$LocationPasswd
#
# Connect to vCenter Server Appliance
Connect-CisServer -Server $vcsa -User $vcsauser -Password $vcsapasswd 
#
# Start the backup
If ($BackupType -eq 1) {
	Backup-VCSAToFile -BackupPassword $BackupPassword -LocationType $LocationType -Location $bkpLocation -LocationUser $LocationUser -LocationPassword $locationPassword -Comment $Comment -Fulbackup ShowProgress
	}
	Else {
	Backup-VCSAToFile -BackupPassword $BackupPassword -LocationType $LocationType -Location $bkpLocation -LocationUser $LocationUser -LocationPassword $locationPassword -Comment $Comment -Seatbackup -ShowProgress
	}
#
# Disconnect from vCenter Server Appliance
disconnect-CisServer $vcsa -confirm:$false
#

Надо сказать, что для скрипта нужно использовать пользователя, определенного на уровне SSO, так как если вы возьмете пользователя из AD, но с правами группы SSO Administrators - сценарий все равно работать не будет.

Скачать сценарий можно с репозитория на GitHub по этой ссылке.

Восстановить бэкап vCSA можно через vCenter Server Appliance Installer, выбрав опцию Restore:

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

Специально для таких администраторов, активист Neil Anderson выпустил руководство по лабораторным работам на 350 страницах (!), которое поможет сдать экзамены на сертификацию Cisco CCNA (Cisco Certified Network Associate). В частности, в нем раскрываются детали лаб последних версий экзаменов 200-125 CCNA, 100-105 ICND и 200-105 ICND.

Содержимое документа по разделам (в целом, это самые нужные азы, что будет полезно и тем, кто экзамен сдавать не планирует):

• The IOS Operating System
• The Life of a Packet
• The Cisco Troubleshooting Methodology
• Cisco Router and Switch Basics
• Cisco Device Management
• Routing Fundamentals
• Dynamic Routing Protocols
• Connectivity Troubleshooting
• RIP Routing Information Protocol
• EIGRP Enhanced Interior Gateway Routing Protocol
• OSPF Open Shortest Path First
• VLANs and Inter-VLAN Routing
• DHCP Dynamic Host Configuration Protocol
• HSRP Hot Standby Router Protocol
• STP Spanning Tree Protocol
• EtherChannel
• Port Security
• ACL Access Control Lists
• NAT Network Address Translation
• IPv6 Addressing
• IPv6 Routing
• WAN Wide Area Networks
• BGP Border Gateway Protocol
• Cisco Device Security
• Network Device Management 

Скачать документ можно по этой ссылке: Free CCNA Lab Guide. Штука-то очень нужная для тех, кто сдает на CCNA, так что качайте.

Те из вас, кто следит за новостями VMware, знают, что некоторое время назад компания отказалась от развития своего публичного облака (ранее оно называлось vCloud Air и было продано в OVH) в пользу партнерских решений на стороне облаков сервис-провайдеров. Главным и первым из таких партнеров стала компания Amazon, которая совместно с VMware предлагает IaaS-услугу аренды виртуальных машин на базе AWS.

В мае этого года случилось невероятное: два заклятых конкурента - VMware и Microsoft - предложили совместную услугу VMware Horizon Cloud on Microsoft Azure, позволяющую получить в аренду виртуальные десктопы и приложения.

Но главная новость пришла в конце ноября - теперь две компании, жестко борящиеся за рынок серверной виртуализации, будут давать в аренду серверы VMware vSphere на оборудовании облака Azure.

Как оказалось, VMware не очень-то довольна этим фактом, но рынок есть рынок - VMware проиграла войну за публичные облака и теперь IaaS-сервисы VMware будет предлагать в том числе Microsoft.

Пока технология находится в стадии технологического превью, но есть уже первые новости от Microsoft. Вкратце они заключаются в следующем:

• Microsoft предоставит средства миграции рабочих нагрузок частного облака в инфраструктуру VMware в облаке Azure. Эти средства позволят вам обнаружить виртуальные машины VMware vSphere и связи между ними (как показано на картинке выше), а потом смигрировать их на платформу Azure. При этом заранее будут посчитаны требуемые ресурсы и, главное, примерная стоимость месячной аренды ресурсов Azure. Решение Azure Site Recovery (ASR) позволит обеспечить правильный порядок миграции и минимальное время простоя. Azure Database Migration Service позволит перенести БД SQL Server и Oracle на PaaS-платформу Azure SQL Database.
• Microsoft обеспечит интеграцию сервисов Azure и VMware. Это включает в себя такие решения, как Azure Backup, Azure Site Recovery (для Disaster Recovery-решений), управление апдейтами и конфигурациями, Azure Security Center и средства аналитики Azure Log Analytics. Кроме этого, можно будет управлять инфраструктурой и средствами VMware - с помощью консоли vRealize Automation.
• Microsoft будет развивать средства эксплуатации гибридных облаков. Это позволит создать единую гибридную инфраструктуру между онпремизным облаком VMware vSphere и виртуальными машинами на платформе Azure. Заявляется, что ВМ в облаке будут запущены на оборудовании датацентров Microsoft и ее партнеров (про загадочных партнеров очень интересно написано тут), но на серверах ("на колокейшене") как bare-metal гипервизоры будет установлен полный стек решений VMware vSphere.

Такие дела, Microsoft победила:) Несколько полезных ресурсов на почитать:

• Azure Migration Center - там утилиты, документ и описания технологий миграции, в том числе от партнеров, таких как Turbonomic, Movere и Cloudamize.
• Дополнительная информация о сценариях миграции с VMware на Azure.
• Бесплатный курс Azure for VMware vSphere Admins.

Пока идет обкатка технологического превью, а полностью сервисы VMware из облака на платформе Azure будут доступны в 2018 году.

Мы часто пишем о встроенной утилите на хосте ESXi - esxtop, которая позволяет отслеживать все основные аспекты производительности хост-серверов и виртуальных машин (процессор, память, диски и сеть). Напомним, что наши последние посты о esxtop расположены тут, тут, тут, тут, тут и тут.

А недавно вышло весьма полезное образовательное видео "Using esxtop to Troubleshoot Performance Problems", в котором показано на практическом примере, как именно использовать esxtop для решения проблем производительности (хотя голос и весьма уныл):

Ну и напомним, что у esxtop есть графический интерфейс - это утилита VisualEsxtop.

Довольно давно мы уже рассказывали о механизме применения политик для хранилищ при развертывании виртуальных машин - VMware vSphere Storage Policy Based Management (SPBM). А недавно Кормак Хоган опубликовал интересную заметку, касающуюся возможности выбора политик SPBM конкретным пользователем во время развертывания новой виртуальной машины.

Прежде всего, в vSphere нет механизма назначения прав доступа пользователей на конкретную политику SPBM - все пользователи видят все политики. Но сам механизм разграничения прав существует - его можно реализовать на уровне прав доступа к хранилищам.

Например, пользователю ben мы даем доступ Read-only к хранилищу VVols1, то есть создавать виртуальные машины он на нем не может:

А на хранилище VVols2 делаем его администратором:

В итоге, при развертываниии виртуальной машины пользователь ben видит оба хранилища - VVols1 и VVols2 и все доступные политики хранилищ (комбобокс VM storage policy):

Однако, обратите внимание, что при выборе хранилища VVols1 в разделе Compatibility написано о том, что пользователь не имеет достаточных привилегий, чтобы создать машину на этом датасторе.

You do not hold the privilege to allocate space on the selected datastore

Между тем, кнопка Next активна. Но если нажать ее, мастер все равно дальше не пустит:

Вверху мы увидим:

Specify a valid location

Ну а если выбрать VVols2, то все проверки пройдут успешно, и пользователь сможет там создать виртуальную машину:

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):