Новости Статьи VMware Veeam StarWind vStack Microsoft Nakivo Citrix Symantec События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Все самое нужное о виртуализации и облаках

Более 6160 заметок о VMware, AWS, Azure, Veeam, Kubernetes и других

VM Guru | Ссылка дня: Какие есть версии и номера билдов VMware vCenter, ESXi, Tools и Connection Server?

Ошибка апгрейда Windows 11 for ARM на платформе VMware Fusion


Как вы знаете, недавно платформа VMware Fusion стала бесплатной для некоммерческого использования. В том числе, теперь пользоваели Macbook и компьютеров на базе macOS с процессорами архитектуры ARM (Apple Silicon - M1/M2 и другие) могут устанавливать в виртуальной машине релизы Microsoft Windows 11 for ARM (пока в статусе Insider Preview).

Вильям Лам рассказал о том, что у некоторых пользователей при попытке апгрейда их гостевой ОС возникала следующая ошибка:

This PC doesn't currently meet Windows 11 system requirements

Также эта проблема была задокументирована вот тут, она связана с использованием нового механизма TPM и Secure Boot.

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

  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\Applicability : BranchName -> CanaryChannel
  • Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\UI\Selection : UIBranch -> CanaryChannel

После этого обновление пройдет успешно:


Таги: VMware, Apple, Fusion, Bug, Bugs, Upgrade, CPU

Апгрейд версии Disk Format в VMware vSAN 8 Update 2 при апгрейде с Update 1


Mateusz Romaniuk написал отличный пост о том, что делать, когда вы провели апгрейд решения для создания отказоуйстойчивых хранилищ с версии VMware vSAN 8 Update 1 на Update 2.

VMware vSphere 8.0 U2 вносит множество улучшений, исправляет несколько проблем и повышает стабильность. После обновления с vSphere 8.0 U1 на U2 происходят также некоторые изменения в vSAN. Если кластер vSAN работает в производственной инфраструктуре, вам необходимо проапгрейдить версию диска, когда вы используете самую новую версию vSphere.

В итоге у вас должна быть версия 19 для формата дисков кластера vSAN (Disk format version):

Итак, сам процесс обновления:

1. В клиенте vSphere выберите ваш кластер vSAN. Перейдите на вкладку Configure и в разделе vSAN выберите Disk Management. Если вы проверите один из хостов ESXi, работающих на vSAN, вы увидите, что текущая версия диска - 18.0.

2. Запустите процедуру предварительной проверки Pre-Check Upgrade, чтобы убедиться, что формат дисков может быть обновлен:

3. Если все в порядке, то нажимайте кнопку Upgrade:

4. После этого начнется процесс апгрейда формата дисков, продолжительность которого зависит от размера вашей инфраструктуры и количества дисков:

5. После апгрейда вы получите уведомление об успешном завершении, а в разделе Disk Management вы можете выбрать хост ESXi и нажать View Disks:

6. Там в разделе Disk group вы и увидите нужную вам информацию - Disk format version: 19

Ну а вот и сами диски дисковой группы:


Таги: VMware, vSAN, Upgrade, Update, Storage

Общие рекомендации при апгрейдах и накатывании обновлений в среде VMware vSphere


Администраторы платформы виртуализации VMware vSphere в рамках ежедневной рутины занимаются процессами обновлений виртуальной инфраструктуры и ее компонентов путем накатывания патчей или проведения апгрейдов (в том числе наиболее сложных - на новые мажорные версии). Наиболее удобный способ делать это - использовать решение vSphere Lifecycle Manager (vLCM), который автоматизирует этот процесс. Это следующее поколение продукта vSphere Update Manager (VUM), который ранее использовался для планирования и накатывания обновлений...


Таги: VMware, vCenter, Update, Upgrade, vSphere, ESXi

Новый метод апгрейда сервисов VMware vCenter Server Appliance 8.0 до Update 2 - Switchover


С выпуском обновления платформы виртуализации VMware vSphere 8 Update 2 компания VMware ввела еще один способ апгрейда сервисов управления виртуальной инфраструктурой vCenter Server Appliance 8.0 до Update 2, который теперь можно сделать методом Switchover. Это подразумевает развертывание нового экземпляра vCSA, на который по окончании апгрейда будет переключено управление виртуальной инфраструктурой vSphere.

Проапгрейдить на Update 2 вы можете vCenter 8 следующих версий (естественно, вы сможете апгрейдить и сам vCSA 8 U2 на последующие релизы в дальнейшем):

  • 8.0 GA 8.0 U2
  • 8.0 U1 8.0 U2
  • 8.0 P02 8.0 U2

Суть нового метода описана в KB 92659, мы приведем здесь лишь основные шаги:

1. Монтируем ISO-образ c vCenter Server Appliance 8.0 до Update 2

2. Делаем бэкап vCenter на уровне файлов (это обязательно)

3. Обновляем плагин vCenter Server Lifecycle Manager в Upgrade Planner

4. Настраиваем новый модуль vCenter Server Appliance 8.0 Update 2 (это можно делать и для минорных апдейтов)

5. Запускаем предварительную фазу апгрейда (Prepare upgrade stage) с установкой временного IP

6. Запускаем процесс Switchover, во время которого произойдет остановка предыдущего виртуального модуля vCenter Server, перебивка IP-адресации и переключение на новый экземпляр vCSA


Таги: VMware, vCenter, Upgrade

VMware выпустила Cloud Provider Lifecycle Manager 1.4


На днях компания VMware объявила о доступности обновленной версии решения Cloud Provider Lifecycle Manager 1.4 (VCPLCM). Напомним, что этот продукт предназначен для автоматизации рутинных операций жизненного цикла продуктов, для которых можно разрабатывать свои сценарии развертывания, обслуживания и списания систем, что позволяет сотрудникам сервис-провайдеров (VCPP) сосредоточиться на более высокоуровневых операциях. В прошлой версии этого средства появился графический интерфейс, о чем мы писали вот тут.

Основные нововведения Cloud Provider Lifecycle Manager 1.4 сосредоточены в трех областях:

1. Упрощенные операции

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

Также в графическом интерфейсе доступны новые Day-2 операции, чтобы выровнять функции API и GUI. Теперь вы можете управлять следующими вещами:

  • Апгрейд продуктов
  • Управление сертификатами
  • Управление узлами

Функция Discover была добавлена для отслеживания изменений и модификаций, которые были сделаны в развернутом продукте, и синхронизации их с репозиторием Lifecycle Manager Repository.

Теперь вы можете обнаружить изменения в развернутом продукте в окружении и в зарегистрированном датацентре. Более подробно об этом рассказано в документации.

2. Уменьшенное время исполнения задач

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

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

3. Улучшенный траблшутинг

В VCPLCM 1.4 вы можете получать логи и сообщения об ошибках через GUI или API, просто залогинясь на хост VCPLCM по SSH. Теперь отдельные лог-файлы создаются для каждой задачи с уникальным ID, чтобы упростить решение проблем.

Также появилась опция генерации бандла поддержки (support bundle), чтобы получить все необходимые конфигурационные файлы в архиве через API или GUI.

Кроме того, был упрощен процесс проверки и развертывания пакетов Interop Bundles. Теперь вы можете проверить доступность последнего interop bundle и обновить его через GUI. В разделе Administration доступны опции Check for Interop Bundle Update и Update Interop Bundle:

Также теперь при логине в GUI появляется баннер, который периодически проверяет доступность версий interop bundle и предлагает обновиться, чтобы ваш хост VCPLCM был всегда последней версии. Помните, что для работы функций VCPLCM нужен доступ к VMware Customer Connect.

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

Загрузить VMware Cloud Provider Lifecycle Manager 1.4 можно по этой ссылке. Документация доступна тут.


Таги: VMware, Cloud, VCPP, Update, Upgrade, Lifecycle

Стал доступен сценарий для автоматизированного развертывания тестовой лаборатории на базе VMware vSphere 8 и vSAN 8


Как вы знаете, на прошедшей конференции Explore 2022 компания VMware анонсировала новые версии платформы виртуализации vSphere 8 и решения для создания отказоустойчивых хранилищ vSAN 8. Недавно эти решения стали доступны для скачивания как Initial Availability (IA), поэтому сейчас самое время развертывать их в своих тестовых окружениях для проверки перед большим апгрейдом.

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

Для этой цели известный блоггер и инженер VMware Вильям Ламм создал на PowerCLI специальный сценарий Automated vSphere & vSAN 8 Lab Deployment, который автоматизирует развертывание компонентов виртуальной лаборатории на базе vSphere и vSAN восьмой версии.

Как видно на картинке, скрипт предназначен, чтобы развернуть три виртуальных сервера ESXi, создать на их базе кластер vSAN, а также развернуть виртуальный модуль управления vCenter Server Appliance (vCSA).

Итак для этого вам понадобятся:

  • Действующий vCenter Server не ниже седьмой версии
  • Компьютер Windows, Mac или Linux с установленным PowerShell Core и фреймворком PowerCLI 12.1 Core
  • Виртуальный модуль vCenter Server Appliance 8.0 Build 20519528 OVA
  • Виртуальный модуль Nested ESXi 8.0 IA OVA

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

Пример исполнения сценария показан ниже:

В итоге процесс будет выполняться пошагово до его завершения с информацией о каждом шаге:

Ну и после всего этого в vSphere Client вы увидите вашу созданную виртуальную тестовую лабораторию с тремя хостами ESXi и сервером управления vCenter / vCSA:

Скачать сценарий Automated vSphere & vSAN 8 Lab Deployment можно по этой ссылке, там же есть более подробная информация о том, как его использовать.


Таги: VMware, vSphere, Labs, ESXi, vCenter, Upgrade, PowerCLI

Вышло обновление VMware vRealize Suite Lifecycle Manager 8.8 - что нового?


На днях компания VMware обновила свое решение vRealize Suite Lifecycle Manager до версии 8.8, входящее в пакет решений vRealize Suite. Напомним, что оно предназначено для развертывания установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. Он пришел на смену решению VMware Update Manager (VUM), расширив его возможности. О версии 8.6 vRLCM мы писали вот тут.

Давайте посмотрим, что нового в vRLCM 8.8:

1. Управление жизненным циклом vRealize Orchestrator

Теперь Lifecycle Manager поддерживает решение по автоматизации операций vRealize Orchestrator, которое есть в составе пакета vRealize Automation (базовая версия), так и существует в виде отдельного продукта (полнофункциональная версия для производственной среды).

Теперь можно добавить существующий сервер vRealize Orchestrator, развернуть новый в составе vRealize Automation, либо создать отдельный инстанс vRO в рамках установки инфраструктуры vRA:

Помните, что vRealize Orchestrator нельзя установить без наличия в инфраструктуре сервисов vRealize Automation. Импорт существующего инстанса выглядит очень просто:

Для новой инсталляции vRO потребуется чуть больше шагов, но большинство параметров уже будут предзаполнены мастером установки:

После импорта иконка vRealize Orchestrator будет отображаться на карточке виртуального окружения:

Так как vRO ассоциирован с установленным vRA, то действия Day 2 для vRO появятся как подвкладка для продукта vRealize Automation:

Действия Day 2 для управления жизненным циклом доступны из меню в правом верхнем углу:

2. Улучшения для vRealize Automation

Раньше при снятии снапшота инфраструктуры vRealize Automation перед апгрейдом кластера требовалось около 10 минут на правильное выключение всех систем. Теперь это время было уменьшено в рамках улучшений рабочих процессов при создании онлайн-снапшота и откате к нему. Перед апгрейдом vRLCM проверяет нормальное функционирование vRealize Automation.

Второе улучшение в vRealize Automation Cloud - это поддержка развертывания Cloud Extensibility Proxy. Раньше карточка для прокси была, но доступна она была только для стандартных прокси. Теперь при создании нового прокси он будет развернут как extensibility service. На картинке ниже показано отличие от предыдущей версии:

3. Кластеры VMware Identity Manager

При развертывании или масштабировании трехузлового кластера VMware Identity Manager теперь можно развертывать новые узлы в разных датацентрах и кластерах. Это позволяет обеспечить высокую доступность на уровне разных кластеров и площадок.

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

Обратите внимание, что все узлы должны использовать одну сеть в рамках серверов vCenter Server.

4. Улучшенные нотификации

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

Это позволяет заранее позаботиться о лицензиях и сертификатах, которые актуальны в вашем окружении и выполнить соответствующее действие в службе Lifecycle Operations перед тем, как ваши лицензии/сертификаты устареют.

Еще одно улучшение - это дополнительный шаг валидации при добавлении webhook URL для Slack и Teams, чтобы сразу убедиться в том, что параметры указаны верно (отсылается тестовое сообщение).

5. Улучшения VMware Cloud Foundation

В этом релизе появилась автоматическая установка менеджмент паков VMware Identity Manager и SDDC Health как части развертывания vRealize Operations. Это нужные паки для мониторинга окружения VMware Cloud Foundation, которые раньше устанавливались вручную.

Начиная с VMware Cloud Foundation 4.4 и vRealize Suite Lifecycle Manager 8.6.2, развертывание продуктов семейства vRealize контролируется vRLCM. Это позволяет пользователям делать апгрейд продуктов, как только выходят их новые версии, без необходимости ждать, пока обновится список поддерживаемых систем VMware Cloud Foundation BOM.

Теперь пользователи могут проводить апгрейды продуктов vRealize в режиме поддержки VMware Cloud Foundation, что сокращает время самого апгрейда. Это поддерживается для продуктов vRealize, начиная с версии 8.1.

Также в этом режиме будет верифицирована совместимость компонентов vCenter Server, ESXi и NSX при любых типах апгрейдов. Это позволит убедиться в том, что вы всегда получаете поддерживаемую конфигурацию.

Еще одно улучшение тут - это обработка изменений пароля vCenter. Теперь SDDC Manager может регулярно менять пароли vCenter Server, которые автоматически обновляются в хранилище Realize Suite Lifecycle Manager.

6. Улучшения Content Management

В этом релизе исправлена ошибка, когда контент не удалялся из источника (например, GitHub) при обновлении.

Подробнее о VMware vRealize Suite Lifecycle Manager 8.8 можно узнать по этой ссылке. Release Notes на русском языке доступны тут.


Таги: VMware, vRealize, Lifecycle, Update, Automation, Orchestrator, Enterprise, Upgrade

Уже 5 дней VMware находится в состоянии экстренной починки VMware vSphere 7 Update 3


Многие из вас заметили, что на сайте VMware обновление vSphere 7 Update 3 пока не скачать. При входе на страницу загрузки VMware vSphere показывают красное предупреждение, которое говорит о том, что проблема нового апдейта весьма серьезная:

Скачать VMware vSphere 7 Update 3 и ее компоненты сейчас нельзя.

Ситуация продолжается уже 5 дней, а VMware не дает конкретных сроков устранения проблемы. При этом пользователям, которые уже провели апгрейд до vSphere 7 Update 3, 3a или 3b - неясно пока, что делать. Нам в комментариях уже писали о том, что сталкиваются с серьезными проблемами при апгрейде на U3 и после этого.

Основная информация о возникшей проблеме приведена в KB 86398. Там можно узнать, что вся линейка Update 3 была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281.

Прямо скажем - проблем этих много, и просто удивительно, как все это прошло выходной контроль при выпуске релизов третьего пакета обновлений. Это и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и другое:

Следим за развитием событий, FAQ в KB 86398 не дает никакой ясности по планируемому времени исправления проблемы. Пользователям, обновившимся до vSphere 7 Update 3, не рекомендуют откатываться до предыдущей версии, если они не сталкиваются с серьезными проблемами в функционировании инфраструктуры.

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


Таги: VMware, vSphere, Bug, Update, Upgrade, Bugs

Пропал доступ к томам VMFS, подключенным по iSCSI, при апгрейде VMware vSphere 7 Update 1 на Update 2


Дункан Эппинг обратил внимание на довольно частую проблему у пользователей VMware vSphere 7, которые делают апгрейд с Update 1 на Update 2. Если вы используете подключение к хранилищам по iSCSI и рандомные имена IQN для инициаторов, то после апгрейда хранилища могут перестать быть доступными, если вы используете контроль доступа на базе IQN.

Проблема проявляется, только если вы создавали подключения по iSCSI именно в vSphere 7 Update 1 на свежей установке. Причина проста - изменился стандарт случайного именования IQN для iSCSI-инициаторов. Если для Update 1 он выглядит так:

iqn.1998-01.com.vmware:labesx06-4ff17c83

То для Update 2 уже так:

iqn.1998-01.com.vmware:labesx07:38717532:64

Соответственно, после апгрейда имя инициатора у вас изменится. Чтобы сделать хранилища iSCSI вновь доступными, надо пойти на дисковый массив или виртуальный модуль (Virtual Appliance) и вбить туда новое имя инициатора. Либо вы можете сделать имя инициатора вручную и вбить его также и на массиве для нужных LUN.

Кстати, при апгрейде с версии vSphere 6.7 или vSphere 7 сразу на Update 2 проблема не возникает, так как настройки iSCSI корректно переезжают сразу в configstore.

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

$ esxcli iscsi adapter get -A vmhba67

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

vmhba67
Name: iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

И потом вот эту команду, чтобы задать новое имя:

$ esxcli iscsi adapter set -A vmhba67 -n iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

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

Get-VMHost |
ForEach-Object -Process {
    $HostHBA = $_ | Get-VMHostHba -Type iScsi | Select-Object Name,IScsiName
    $esxcli = get-esxcli -v2 -vmhost $_
    $CLIARG =  @{
        adapter = $HostHBA.Name
        name = $HostHBA.IScsiName
        skipifsessionactive = $false
        }
    $esxcli.iscsi.adapter.set.Invoke($CLIARG)
write-host "Setting host " $H  "adapter"  $HostHBA.Name "with IQN" $HostHBA.IScsiName
    }


Таги: VMware, vSphere, Upgrade, Bug, Bugs, iSCSI, Storage

Вышел VMware ESXi 7 Update 2a с исправлением ошибки апгрейда


Недавно мы писали о новой службе Virtual Machine Service, которая появилась в последней версии VMware vCenter 7 Update 2a, вышедшей несколько дней назад. Через некоторое время компания VMware обновила и свою основную платформу виртуализации до версии ESXi 7 Update 2a, обновив таким образом оба компонента VMware vSphere 7 до Update 2a.

Основным нововведением ESXi 7 Update 2a (он же билд 17867351) является исправление бага с апгрейдом с прошлых версий vSphere. Пользователи, у которых был настроен кастомный бейслайн vSphere Lifecycle Manager (vLCM), после апгрейда получали вот такую ошибку (для билда 17630552 в комплекте Update 2):

Failed to load crypto64.efi

Теперь старый билд Update 2 был убран из репозитория, а все обновления будут уже до версии 2a.

Также в U2a появилось немало нововведений для VMware vSphere with Tanzu:

  • Supervisor Cluster
    • Управление ресурсами Kubernetes через Virtual Machine Service. Об этом мы подробно писали тут.
    • Самостоятельное создание пространств имен со стороны разработчиков (по шаблону, заданному администратором, который определяет лимиты и права доступа).
  • Tanzu Kubernetes Grid Service for vSphere
    • Сервер Kubernetes metrics-server включен по умолчанию. Основные параметры узлов и Pod'ов можно смотреть командой kubectl top.
    • Система обработки webhooks теперь поддерживает dry-run mode. Теперь такие популярные утилиты, как, например, Terraform Kubernetes provider можно интегрировать с Tanzu Kubernetes Grid Service.
    • Кастомные классы виртуальных машин (Virtual Machine Classes), которые потребляются через службы VM Service. Это позволяет пользователям выделить различные параметры CPU и памяти, которая выделена виртуальным машинам в кластере Tanzu Kubernetes Cluster.

Обновить инфраструктуру на vSphere 7 Update 2a можно следующими командами в консоли:

esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -p ESXi-7.0U2a-17867351-standard \
-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
esxcli network firewall ruleset set -e false -r httpClient

Скачать VMware vSphere 7 Update 2a можно по этой ссылке. Release notes доступны тут.


Таги: VMware, ESXi, Update, Upgrade, vSphere, vCenter, Bug, Bugs, vLCM

Что такое и как работает техника Suspend-to-Memory при обновлении хостов VMware ESXi


Как вы знаете, при обновлении виртуальной инфраструктуры в части хостов ESXi с помощью vSphere Lifecycle Manager (vLCM), в кластере HA/DRS хост переводится в режим обслуживания (Maintenance mode), который предполагает эвакуацию виртуальных машин на другие серверы с помощью vMotion. После обновления хоста он выводится из режима обслуживания, и виртуальные машины с помощью DRS постепенно возвращаются на него. В зависимости от характера нагрузки этот процесс может занять от нескольких минут до нескольких часов, что не всегда соответствует ожиданиям администраторов.

Второй вариант - потушить виртуальные машины, обновить ESXi, а потом включить его - тоже не подходит, так как приводит к длительным простоям сервисов виртуальных машин (нужно не только время на обновление хоста, но и время на выключение и включение ВМ, либо их небыстрый Suspend на диск).

Поэтому VMware придумала технологию Suspend-to-Memory, которая появилась в VMware vSphere 7 Update 2. Суть ее в том, что при обновлении ESXi его виртуальные машины приостанавливаются, сохраняя свое состояние (Suspend) в оперативной памяти. Очевидно, что в таком состоянии перезагружать хост нельзя, поэтому данная техника используется только совместно с ESXi Quick Boot, которая подразумевает обновление гипервизора без перезагрузки сервера.

Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по поддержке этой технологии со стороны серверных систем приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:

По умолчанию настройка кластера Cluster Remediation для виртуальных машин выставлена в значение "Do not change power state" для виртуальных машин, что подразумевает их vMotion на другие серверы, поэтому чтобы использовать Suspend to Memory, надо выставить "Suspend to memory", как на картинке выше.

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

Надо сказать, что Suspend-to-Memory поддерживает vSAN и работает с такими продуктами, как vSphere Tanzu и NSX-T.

Ну и вот небольшое демо того, как это работает:


Таги: VMware, vSphere, Upgrade, Update, ESXi, VMachines, HA, DRS, Memory

Главные вопросы о системном хранилище VMware ESXi - FAQ


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

Давайте посмотрим, на какие вопросы там можно найти ответы:

  • Что изменилось в системном хранилище ESXi 7 по сравнению с прошлыми версиями? Мы об этом подробно писали тут.
  • Что случится с разметкой системного хранилища при апгрейде на vSphere 7? Ответ тут и на этой картинке:

  • Какое хранилище рекомендуется в качестве системного для ESXi?
  • Что насчет устройств USB/SD? Можно ли использовать SD-карту для системного хранилища? (Спойлер: лучше не надо).
  • Почему вы можете увидеть ситуацию, что хосты ESXi в "Degraded Mode"?
  • Что вообще означает Degraded Mode?
  • Можно ли добавлять локальное хранилище после апгрейда на ESXi 7? (Спойлер: да)
  • Что делать, если хост в Degraded Mode, а хранилища вообще не видно? (Спойлер: смотреть External Syslog, NetDump Collector или Core Dump Partition)
  • Если вы используете vSphere AutoDeploy, то как работает развертывание системного хранилища? Подробнее об этом вот тут

Таги: VMware, ESXi, Storage, FAQ, vSphere, Upgrade

Разная совместимость драйверов у VMware vSphere и vSAN


Интересно, что продукты VMware vSphere и VMware vSAN имеют разные списки совместимости оборудования (HCL - Hardware Compatibility Lists). Ronald de Jong в своем блоге описал ситуацию, когда у него драйвер SCSI-контроллера подошел для vSphere, но не подошел для vSAN.

После установки обновления драйвера для VMware vSphere через VMware Lifecycle Manager он получил вот такие ворнинги для vSAN в vSphere Client:

Драйвер smartpqi (70.4000.0.100-4vmw.701.0.0.17325551) уже подходит для vSphere, но еще не провалидирован для решения vSAN. В этом можно убедиться в списке совместимости для vSAN по этой ссылке, где есть только старый драйвер (3vmw):

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

Таким образом, нужно провести даунгрейд драйвера, чтобы он подходил и для vSphere, и для vSAN. Сначала идем на Patch Portal и находим там нужное обновление в виде VIB-пакета:

Вот этот драйвер:

После загрузки в консоли ESXi запускаем установщик VIB-пакета командой:

esxcli software vib install -d /vmfs/volumes/vsanDatastore/tmp/VMware-ESXi-7.0U1-16850804-depot.zip -n=smartpqi

После этого все ворнинги по совместимости драйвера исчезнут:

Но в Lifecycle Manager все еще будут висеть предупреждения о необходимости поставить последнюю версию драйвера и проапдейтить ESXi:


Таги: VMware, vSAN, vSphere, Compatibility, Hardware, Upgrade, Update

Как подготовиться к апгрейду виртуальной инфраструктуры VMware vSphere


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


Таги: VMware, vSphere, Upgrade, ESXi

Откат (rollback) к прошлой версии VMware ESXi после апгрейда, если что-то пошло не так


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

Для этого нужно во время установки выбрать пункт "Upgrade ESXi, preserver VMFS datastore". Под датастором тут имеется в виду, что на нем сохранится предыдущая установка ESXi:

Кстати, как видно из скриншота, можно сделать и свежую установку ESXi с возможностью отката к предыдущей версии.

Сделать апгрейд на ESXi 7 с сохранением предыдущей версии платформы не выйдет - в VMware vSphere 7 поменялась структура разделов гипервизора ESXi.

Итак, вы сделали апгрейд ESXi, но что-то пошло не так. Например, ваше железо больше не поддерживается (к примеру, CPU), и вам надо сделать откат к прошлой версии ESXi. Для этого во время загрузки вам нужно нажать комбинацию клавиш Shift + <R>:

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

Также можно делать бэкап и восстановление конфигурации VMware ESXi - об этом рассказано в KB 2042141.


Таги: VMware, vSphere, Upgrade, ESXi, Обучение, Storage

10 главных причин обновиться на VMware vSphere 7


Как вы знаете, компания VMware выпустила платформу VMware vSphere 7 в начале апреля этого года после громкого анонса месяцем ранее. В конце апреля VMware опубликовала интересную новость с результатами исследования среди пользователей, которые тестировали бета-версию vSphere 7 и потом прошли опрос, где одним из вопросов был "Почему бы вы хотели обновиться?". Собственно, вот его результаты...


Таги: VMware, vSphere, Upgrade, vCenter, ESXi

Вышел VMware vCenter 7.0 Update 0a и обновление vSphere with Kubernetes


Для платформы VMware vSphere 7 вышло первое обновление - стал доступен для скачивания апдейт управляющего сервера VMware vCenter 7.0 Update 0a.

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

Она заключалась в том, что vSphere Lifecycle Manager и службы vSAN File Services не могли быть одновременно включены в кластере. Если вы включали что-то из этого первым, то второй компонент не мог быть включен после этого (они не были совместимы между собой). Теперь это поправили - и они вполне работают вместе.

Скачать VMware vCenter 7.0 Update 0a можно по этой ссылке.

Помимо этого, были обновлены и службы VMware vSphere with Kubernetes, включающие в себя виртуальный модуль Tanzu Kubernetes clusters OVA. Из нового там появилось:

  • Службы Tanzu Kubernetes Grid Service for vSphere:
    • Пользователи могут накатывать последовательные обновления rolling upgrades на узлы worker nodes и control plane nodes для Kubernetes Grid Service for vSphere и апгрейдить службы pvCSI, Calico и authsvc. Также для этих компонентов предусмотрены процедуры пре-чеков перед апгрейдом.
    • Последовательные обновления rolling upgrades могут быть использованы для одновременного с апгрейдом изменения класса ваших узлов на больший или меньший по размеру.
  • Для Supervisor cluster поддерживаются новые версии Kubernetes с возможностью апгрейда:
    • Kubernetes 1.17.4
    • С версии Kubernetes 1.16.x можно обновиться на 1.17.x

Таги: VMware, vCenter, Update, vSphere, Kubernetes, Upgrade

Обзор процесса апгрейда хостов на VMware ESXi 7 средствами VMware Lifecycle Manager


Как все уже знают, в новой версии платформы виртуализации VMware vSphere 7 средство обновления виртуальной инфраструктуры VMware Update Manager (VUM) уступило место новому продукту - VMware Lifecycle Manager.

Ранее администраторы vSphere использовали VUM для обновлений серверов ESXi и драйверов, а утилиты от производителей серверов - для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.

На сайте buildvirtual.net появился обзор процесса апгрейда хост-серверов ESXi на версию 7.0, который мы приводим ниже, чтобы дать понимание того, что сам процесс, в плане накатывания апгрейда, от VUM почти ничем не отличается.

Итак, сначала надо импортировать ISO-образ в Lifecycle Manager. Запускаем его в vSphere Client и переходим в раздел Imported ISOs:

Нажимаем Import ISO и указываем ISO-образ ESXi 7.0, который скачали с сайта VMware:

После этого данный образ появится в списке:

Затем надо создать бейслайн с этим образом. Нажимаем ссылку New Baseline, где далее указываем тип содержимого Upgrade:

Выбираем образ, который мы хотим привязать к бейслайну:

После этого созданный бейслайн нужно привязать к хостам или кластеру. Для этого выбираем пункт Attach Baseline or Baseline Group:

После успешной привязки к кластеру, жмем кнопку Check Compliance, которая запускает проверку соответствия хостов заданному бейслайну. В итоге мы увидим, например, что 4 хоста находятся в статусе non-compliant, то есть им можно накатить апгрейд (в данном случае - с версии 6.7 на 7.0):

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

Если ничего критичного не нашлось, жмем на кнопку Remediate:

Это, собственно, запустит сам процесс апгрейда. Вам нужно будет лишь согласиться с EULA и запустить процедуру обновления. После успешного апгрейда будет показано, что все хосты были обновлены:

В консоли вы увидите, что ESXi 7.0 установлен:

То же самое будет и в vSphere Client:

Как видно из описаний шагов, процесс апгрейда с помощью Lifecycle Manager практически ничем не отличается от оного с помощью Update Manager.


Таги: VMware, vSphere, Upgrade, ESXi, Blogs, Обучение, vLCM, Lifecycle

Ошибка CPU_SUPPORT_ERROR при установке виртуального (Nested) VMware ESXi 7 - что делать?


При развертывании новой версии платформы VMware vSphere 7 в виртуальной машине (вложенные/nested ESXi) на серверах со старыми процессорами вы можете столкнуться с тем, что ваш CPU не поддерживается со стороны платформы:

CPU_SUPPORT ERROR

Такая ситуация, например, произошла у Rajesh Radhakrishnan на сервере HP 380 G7, где он развертывал виртуальный ESXi 7.0 на платформе vSphere 6.0 Update 3:

В этом случае вы все равно можете установить гипервизор ESXi седьмой версии. Для этого вам надо открыть настройки виртуальной машины:

В разделе CPUID Mask нажать ссылку Advanced и далее вбить в регистре eax для Level 1 следующие значения:

  • Для процессоров Intel CPU: 0000:0000:0000:0011:0000:0110:1100:0011
  • Для процессоров AMD CPU: 0000:0000:0110:0000:0000:1111:0001:0000

После этого включайте ВМ, где будет установлен ESXi 7, и проходите до конца установки:

После этого ваш ESXi 7 спокойно загрузится. Затем нужно откатить маскирование функций CPU к исходной чистой конфигурации, удалив значение регистра eax:

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


Таги: VMware, ESXi, Troubleshooting, vSphere, Hardware, CPU, Upgrade

Чего больше нет в VMware vSphere 7?


Мы много писали о том, что нового появилось в обновленной платформе виртуализации VMware vSphere 7, которая недавно стала доступной для загрузки. Сегодня мы поговорим о том, чего больше нет в vSphere, ведь многие администраторы привыкли использовать некоторые средства, поэтому, возможно, подождут с апгрейдом. Об этих запланированных изменениях мы писали еще в 2017 году.

1. Больше нет vSphere Web Client на базе Flash

Об этом говорили давно, долго задерживали снятие с производства тяжеловесного vSphere Web Client, но все откладывали из-за несоответствия функциональности клиенту нового поколения vSphere Client на базе технологии HTML5. Теперь в vSphere 7 этот переход окончательно завершен, и старого Web Client больше нет.

Клиент на HTML5 включает в себя не только все старые рабочие процессы Web Client, но и давно получил новые возможности, такие как, например, упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).

2. Больше нет внешнего PSC (Platform Services Controller)

Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).

С помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:

3. Больше нет VMware vCenter for Windows

Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь остался только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS. Многие привыкли к сервисам vCenter на базе Windows, теперь придется отвыкать.

VMware рекомендует выполнить 2 основных шага для миграции с vCenter на vCSA:

  • Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
  • Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.

4. Больше нет Update Manager Plugin

На протяжении долгого времени это был плагин для vSphere Web Client. Теперь вместо продукта VMware Update Manager (VUM) в vSphere 7 есть более широкое по функциональности решение VMware Lifecycle Manager.

Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.

5. Больше нет VNC-сервера в ESXi

Ранее в ESXi был встроенный VNC-сервер, который был убран в последней версии VMware vSphere 7. Раньше можно было соединиться с консолью виртуальной машины с помощью VNC-клиента, добавив в конфигурацию параметр RemoteDisplay.vnc.enable.

Теперь такой возможности больше нет (ей пользовались администраторы систем, не использующих средства VMware). Для соединения с консолью виртуальной машины используйте vSphere Client, хостовый клиент ESXi Host Client или средство VMware Remote Console.

6. Мелочи, которых или уже больше нет или их не рекомендуется использовать (не будет потом)

В эту категорию попали:

  • VMware vSphere 7.0 и протокол TLS Protocol (TLS 1.0 и 1.1 отключены по умолчанию).
  • Нет поддержки резервного копирования на уровне образов (Image-Based Backup) для сервера vCenter.
  • Интерфейс VMKlinux API уже давно безнадежно устарел, вместо него используется архитектура нативных драйверов под vSphere, начиная еще с ESXi 5.5. vmkLinux - это такая прослойка между VMkernel и Linux-драйверами, которая позволяла транслировать команды от ядра (так как VMkernel - это НЕ Linux) к драйверам и обратно. Но теперь нативных партнерских драйверов устройств для ESXi накопилось достаточно, и старая архитектура Linux-драйверов ушла в прошлое.
  • Депрекация поддержки 32-bit Userworld. Ранее партнерам VMware была доступна возможность делать 32-битные драйверы, плагины и другие компоненты в VIB-пакетах. Теперь, начиная со следующих версий vSphere, такой возможности больше не будет.
  • Почти убрана поддержка Integrated Windows Authentication. В этой версии IWA еще работает, но в следующей версии уже не будет. Подробнее в KB 78506.
  • Депрекация аутентификации DCUI Smart Card Authentication. Пользователям со смарт-картами рекомендовано использовать vCenter, PowerCLI или API-вызовы, ну либо логин и пароль по-старинке.
  • Депрекация Core Partition Profile для функциональности Host Profiles. Вместо разделов Coredump Partitions пользователям нужно использовать файлы Coredump Files.

  • Таги: VMware, vSphere, Update, Upgrade, ESXi, vCenter, VMachines

    Особенности апгрейда управляющего сервера VMware vCenter 7 в составе платформы vSphere 7


    Недавно мы рассказывали о новых возможностях анонсированной платформы виртуализации VMware vSphere 7. В составе этого решения идет новая версия управляющего сервера VMware vCenter 7, особенности апгрейда на который мы сегодня рассмотрим.

    Основные нюансы этого процесса суммаризованы в видео ниже:

    Давайте посмотрим на это немного подробнее:

    1. Особенности развертывания

    Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).

    Напомним также, что теперь у вас нет установщика vCenter Server for Windows. Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь это только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS.

    Ранее мы писали, что с помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:

    Также установщик vCenter 7 производит апгрейд vCenter и перенос всех сервисов на Embedded PSC в рамках единой задачи, поэтому результат апгрейда будет сразу законченным. Установщик нового vCenter 7 не имеет опции по развертыванию внешнего PSC:

    2. Процесс миграции

    Если вы проходите путь миграции с vCenter Server for Windows на vCenter Server Appliance (VCSA), то схема будет точно такой же - в итоге вы получите vCenter 7 на vCSA в встроенным PSC:

    После того, как внешний PSC будет сконвертирован, он останется в консоли, и его удаление (decomission) - последующая задача администратора vSphere. Сделать это можно с помощью команды CMSSO-UTIL или из графического интерфейса клиента (в разделе System Configuration):

    3. Пути апгрейда

    Тут все просто. Апгрейд поддерживается согласно вот этой табличке:

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

    Перед апгрейдом нужно обязательно посмотреть документы VMware Product Interoperability Matrices и VMware Compatibility Guide. Но помните, что до официального выпуска vSphere 7, эти документы не содержат актуальной информации о седьмой версии.


    Таги: VMware, vCenter, Upgrade

    Диаграмма по логике миграции на VMware vCloud Director 10.0.


    Некоторое время назад мы писали о новых возможностях продукта VMware vCloud Director 10.0, которые раскрыл Daniel Paluszek. На днях он сделал еще очень полезную диаграмму, которая раскрывают логику миграции на vCD 10 с предыдущих версий.

    Daniel использовал утилиту MindNode для составления данной диаграммы апгрейда на vCD 10. Как видно на картинках, там описаны разные варианты исходной системы, например, вы решите пойти по пути обновления только Linux / External PostgreSQL (PgSQL) с раздельной инсталляцией vCD или сделаете интегрированные виртуальные модули vCloud Director.

    Диаграмма доступна как с фоном, так и с прозрачностью PNG-формата:

    Для Linux-систем Daniel отмечает следующие моменты:

    1. vCD 10.0 поддерживает только PostgreSQL, у него нет больше поддержки Microsoft SQL Server. Oracle уже прекратил поддерживаться ранее, поэтому все пути миграции ведут на PgSQL в данных диаграммах.
    2. Использование виртуального модуля vCD позволяет обеспечить высокую доступность PgSQL, но в случае сбоя нужно будет вручную переключаться на реплику.
    3. Использование внешнего экземпляра PostgreSQL полностью поддерживается. Но нужно внимательно следить за конфигурацией соединения к БД.
    4. VMware будет продолжать поставлять как установщик, так и виртуальный модуль vCD. Поэтому можно использовать оба варианта, в зависимости от нужд вашей команды.

    Более подробно о данных диаграммах можно почитать у Daniel Paluszek.


    Таги: VMware, vCloud, Director, Upgrade, Blogs, Enterprise, IaaS

    Анонсы VMworld 2019 - часть 7. Утилита VMware vSphere Assessment Tool для подготовки апгрейда виртуальной инфраструктуры.


    В рамках серии анонсов, представленных на прошедшей конференции VMworld 2019, компания VMware представила интересное средство, которое может оказаться полезным администраторам виртуальной инфраструктуры - vSphere Assessment Tool (vSAT).

    Главное назначение этой утилиты - помочь ИТ-специалистам перед миграцией инфраструктуры VMware vSphere на новую версию: заранее понять потенциальные проблемы с виртуальными машинами после апгрейда и проанализировать общую готовность инфраструктуры к обновлению. Также можно выявить возможные трудности в плане поддержки аппаратного обеспечения, что очень важно, когда у вас либо очень старое, либо очень новое оборудование.

    Утилита vSAT реализована двумя компонентами:

    • Десктопный клиент, который связывается с сервером vCenter и организует передачу данных.
    • Онлайн-портал vSphere Assessment Portal, обрабатывающий ваши данный и визуализующий результаты.

    Для начала работы просто нажимаете Get Started на первой странице портала:

    Десктопный клиент поддерживает ОС Windows, OS X и Linux. В клиенте вы просто добавляете сервер vCenter, который нужно проанализировать. Для этого либо потребуется использовать административный аккаунт, либо создать пользователя с кастомной ролью с привилегиями "Host Settings".

    После того, как в вашей инфраструктуре завершен сбор данных, есть 2 способа отправить их в облако:

    • Онлайн-отправка на vSphere Assessment portal с использованием vSAT passcode (чтобы его получить, можно использовать опцию клиента "Forgot Your vSAT passcode?").

    Также Passcode можно получить из меню аккаунта на vSAT Portal:

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

    Результатом анализа будет дэшборд, на котором представлена сводная информация по имеющимся проблемам для выбранного пути апгрейда. В левой панели можно выбрать нужный хост ESXi (по аналогии с vSphere Client).

    В представлении Summary вы найдете список всех версий vSphere, на которые вы можете выполнить миграцию, а также узнать, какие хосты ESXi рискуют оказаться в неподдерживаемой конфигурации. При клике на хост ESXi возникает панель host details, где можно увидеть текущую версию vSphere, модель сервера, сетевые адаптеры и контроллеры хранилищ. Для каждого компонента верифицируется поддержка соответствующей версией vSphere.

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

    Пользуйтесь!


    Таги: VMware, vSphere, Upgrade, Assessment, Tool, ESXi

    Как обновлять и апгрейдить инфраструктуру VMware vCenter HA?


    Многи администраторы VMware vSphere, особенно в крупных инфраструктурах, развертывают механизм VMware vCenter HA, обеспечивающий отказоустойчивость сервера VMware vCenter (а точнее виртуальной машины vCenter или vCenter Server Appliance, vCSA). Все понимают, что vCenter / vCSA - это важнейшая часть виртуальной инфраструктуры, ведь без нее не работают такие критичные сервисы, как Site Recovery Manager, NSX и Horizon View.

    Функции vCenter HA появились еще в VMware vSphere 6.5, но в vSphere 6.7 Update 1 они были существенно доработаны, а сам процесс обновления и апгрейдов vCenter упрощен. При этом управление механизмом vCenter HA полностью перешло в vSphere Client в рамках единого рабочего процесса (раньше были 2 воркфлоу - Basic и Advanced).

    Давайте посмотрим, какие пути апгрейда и обновления существуют для конфигурации vCenter HA. Для начала напомним, как это выглядит:

    Две машины с vCenter (активный узел и его клон - пассивный узел), а также компонент Witness образуют собой кластер, где Witness защищает от сценария Split Brain в среде vCenter HA (не путайте это с обычным vSphere HA). В случае отказа основного узла, его функции берет на себя резервный, что существенно быстрее по сравнению с восстановлением vCenter средствами стандартного HA (перезапуск на другом сервере). Это в итоге отражается на меньшем времени RTO для таких критичных сервисов, как SRM и NSX, в случае сбоев.

    Перед обновлением помните, что для vCenter HA не поддерживается создание снапшотов, а значит нужно обязательно сделать File-Based Backup основного сервера vCenter перед обновлением.

    Если у вас VMware vSphere 6.5, то при обновлении вы можете не разбивать кластер vCenter HA, а просто скачать ISO-образ с обновлениями (через VMware Patch Portal), либо ничего не скачивать и сразу инициировать процесс обновления из командной строки, если у вас есть доступ в интернет из компонентов кластера.

    Делается все это так:

    • Сначала кластер vCenter HA надо перевести в режим обслуживания (maintenance mode), что не прервет репликацию, но предотвратит автоматический запуск процесса восстановления (failover).

    • Затем заходим на компонент Witness по SSH и запускаем его обновление из командной строки. Если у вас есть доступ в интернет на этом экземпляре vCenter, то делается это простой командой:

    software-packages install --url --acceptEulas

    Если же вы скачали ISO-образ с обновлениями, то делается это следующей командой:

    software-packages install --iso --acceptEulas

    • Далее заходим на пассивный узел vCenter и там делаем то же самое.
    • Инициируем вручную процесс восстановления vCenter на пассивный узел (failover).
    • Обновляем активный узел vCenter.
    • Возвращаем конфигурацию в исходное состояние (failback).
    • Отключаем режим обслуживания (maintenance mode).

    Если же у вас vCenter 6.7, то опция обновления у вас одна - отключение и удаление конфигурации HA, после чего происходит накат обновления на активном узле и повторное развертывание HA-конфигурации (такая же опция доступна и для vCenter 6.5). Этот рабочий процесс обусловлен изменениями в схеме базы данных, которые происходят в vCenter 6.7.

    Начиная с vSphere 6.7 Update 1, установщик vCenter Server Upgrade installer может автоматически обнаружить присутствие кластера vCenter HA:

    Далее в процессе обновления он сохранит его конфигурацию, обновит активный узел vCenter, а потом развернет его реплики для пассивного узла и узла Witness.

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


    Таги: VMware, vCenter, HA, vSphere, Update, Upgrade

    Изменение дефолтной конфигурации виртуального модуля VMware vCenter Server Appliance 6.5/6.7.


    Многим администраторам знакома такая вещь: сначала для теста устанавливается виртуальная машина VMware vCenter Server Appliance в конфигурации tiny (минимальные аппаратные настройки), а потом она приживается, и хочется сделать из нее полноценную производственную среду управления (конфигурацию large). Только вот не хочется ее переустанавливать.

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

    Установщик vCSA использует фреймворк Electron, настраивая конфигурацию через JSON, и механизм JSON-Schema для установки и валидации параметров. Поэтому в ISO-образе вы сможете найти конфигурацию сервера vCenter по следующему пути:

    \vcsa-ui-installer\win32\resources\app\resources\layout.json

    Там как раз и находятся данные о типовых конфигурациях vCSA. Например, так выглядит размер xlarge:

    "xlarge": {
            "cpu": 24,
            "memory": 49152,
            "host-count": 2000,
            "vm-count": 35000,
            "disk-swap": "50GB",
            "disk-core": "100GB",
            "disk-log": "25GB",
            "disk-db": "50GB",
            "disk-dblog": "25GB",
            "disk-seat": "500GB",
            "disk-netdump": "10GB",
            "disk-autodeploy": "25GB",
            "disk-imagebuilder": "25GB",
            "disk-updatemgr": "100GB",
            "disk-archive": "200GB",
            "required-disk-space": "1180GB",
            "label": "X-Large vCenter Server with Embedded PSC",
            "description": "This will deploy a X-Large VM configured with 24 vCPUs and 48 GB of memory and requires 1180 GB of disk space will be updated for xlarge later. This option contains vCenter Server with an embedded Platform Services Controller for managing up to 2000 hosts and 35,000 VMs."
        }

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

    Теперь переходим, собственно, к изменению самой конфигурации:

    1. Увеличение CPU и памяти (RAM).

    • Остановите машину.
    • Хорошая идея - вывести ее ESXi-хост из кластера DRS.
    • Зайдите на ESXi через Host Client, после чего в настройках ВМ измените конфигурацию CPU и памяти, чтобы выставить ее в соответствии с нужной конфигурацией.

    2. Увеличение диска ВМ с сервером vCSA.

    • Об увеличении дискового пространства сервера vCSA 6.5 мы писали вот в этой статье. С тех пор ничего особо не изменилось. Некоторую дополнительную информацию вы также можете получить в KB 2145603 на случай если что изменится в процедуре vCSA 6.x.
    • Диски нужно настраивать не только по размеру, но и по корректной позиции в виртуальном слоте SCSI.

    Примерно так это выглядит для vCenter 6.7 Update 2:

    Назначение Позиция в фале JSON Номер VMDK Слот SCSI
    root / boot n/a 1 0:0
    tmp n/a 2 0:1
    swap 1 3 0:2
    core 2 4 0:3
    log 3 5 0:4
    db 4 6 0:5
    dblog 5 7 0:6
    seat 6 8 0:8
    netdump 7 9 0:9
    autodeploy 8 10 0:10
    imagebuilder 9 11 0:11
    updatemgr 10 12 0:12
    archive 11 13 0:13

    Помните, что иногда имя VMDK может не соответствовать его позиции в слоте SCSI. Например, встречаются случаи, когда VMDK0 смонтирован в слот SCSI(0:4), а VMDK2 - в слот SCSI(0:0). В этом случае реальным загрузочным диском будет VMDK2, а не VMDK0, несмотря на их названия.

    Также обратите внимание, что SCSI слот 0:7 не используется - не ошибитесь.

    После изменения этих параметров запустите vCenter и убедитесь, что все в порядке.


    Таги: VMware, vCenter, vCSA, Upgrade, Virtual Appliance, Blogs, VMachines

    Улучшенный интерфейс управления плагинами в VMware vSphere 6.7 Update 2.


    Не так давно мы писали о новых возможностях последней версии платформы виртуализации VMware vSphere 6.7 Update 2. Одним из нововведений стал улучшенный интерфейс управления плагинами (Plugin Management UI), который дает пользователю полный контроль над процессами обновления и развертывания плагинов к vSphere.

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

    В подразделе Client Plug-ins раздела Administrator теперь приведены все клиентские зарегистрированные плагины на любом из серверов vCenter в вашем окружении. Также у этих плагинов есть статусы: In Progress, Deployed, Failed или Incompatible.

    Статусы Failed и Incompatible являются кликабельными - при нажатии на них всплывет подсказка с возможной причиной возникновения подобных ошибок или причины несовместимости (при возможности будет также приведен участок лога):

    В процессе инсталляции плагин проходит через несколько фаз, которые отслеживаются сервером vCenter, также их можно получать через TaskManager API (его могут использовать и сторонние разработчики). Выполняемые задачи отображаются на сервере vCenter в 3 разделах:

    • Панель Recent Tasks в нижней части клиента
    • Консоль в разделе задач (Task Console)
    • Просмотр представления Tasks для выбранного объекта vCenter Server

    Задачи создаются и отслеживаются на сервере vCenter, к которому в данный момент подключен vSphere Client. Если же виртуальная среда работает в режиме федерации Enhanced Linked Mode, то задачи по развертыванию плагина создаются на всех подключенных серверах vCenter. Поэтому любой экземпляр vSphere Client будет видеть эти задачи.

    Как происходит работа с плагинами

    При логине пользователя в vSphere Client, все плагины vCenter загружаются в кэшированную папку самого клиента на сервере vCenter. Для отслеживания этого процесса создается задача "Download plug-in". Если загрузка плагина прошла успешно, то он становится доступным для развертывания, что видно в консоли задач. И это значит, что он был загружен в кэшированную папку.

    Следующая фаза - это задача "Deploy plug-in", которая стартует следующей. Если она завершается успешно, это значит, что плагин установлен и доступен для использования со стороны vSphere Client. Кстати, если задача Download plug-in прошла с ошибкой, то и задача Deploy plug-in будет пропущена.

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

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

    В случае апгрейда плагина этот процесс представляется набором из трех задач: "Download plug-in", "Undeploy plug-in" и "Deploy plug-in". После этого в vSphere Client появляется глобальная нотификация о новой версии развернутого плагина и с просьбой сделать рефреш в браузере, чтобы плагин начал работать.

    Один сервер vCenter может работать только с одной версией плагина, но в архитектурах Enhanced Linked Mode и Hybrid Linked Mode может быть несколько серверов vCenter, каждый из которых может содержать свою версию плагина.

    В этом случае vSphere Client обрабатывает плагины двумя способами:

    • Local plug-in architecture - в этом случае оперирование происходит с самой новой версией плагина, обнаруженной на всех доступных серверах vCenter. При этом все остальные версии плагина игнорируются. Если обнаруживается более новая версия плагина на одном из серверов vCenter - происходит ее апгрейд.
    • Remote plug-in architecture - она появилась в vSphere 6.7 Update 1. В этом случае происходит поддержка своей версии плагина на уровне того сервера vCenter, с которым происходит оперирование со стороны vSphere Client. Такое поведение используется, например, в среде Hybrid Linked Mode, где версии плагинов и серверов vCenter могут отличаться очень значительно. В этом случае все версии плагина скачиваются с соответствующих экземпляров vCenter и работа со стороны vSphere Client происходит с каждой версией как с независимым плагином.

    Ну и напоследок приведем статусы, которые могут возникать при развертывании и апгрейде плагинов:

    In progress

    Плагин находится в стадии развертывания.

    Deployed

    Плагин установлен и доступен для использования через интерфейс vSphere Client.

    Failed

    Показывается при невозможности скачать или установить плагин:

    • Download error
      • Установка из незащищенного места - используется http вместо https.
      • Невозможно получить URL плагина.
      • vSphere Client не авторизован для скачивания плагина.
    • Packaging error
      • Поврежден zip-пакет плагина.
      • Отсутствует файл манифеста.
      • Отсутствует папка plugins.
      • Отсутствуют необходимые бандлы в плагине.
    • Deployment error
      • Ошибка связей (Dependency error) при развертывании плагина на vSphere Client.
      • Собственная ошибка плагина (Runtime plug-in error).
    Incompatible

    Показывается когда плагин не поддерживается для данной версии vSphere Client. Возможные причины:

    • Плагин добавлен в черный список администратором.
    • В плагине прописано, что он поддерживает только конкретные версии vSphere Client (и вашей в списке нет).
    • Это плагин на базе флэш-интерфейса под старый клиент vSphere Web Client.

    Таги: VMware, vSphere, Plugin, Update, Troubleshooting, Client, Upgrade, vCenter

    Обновления, патчи, апгрейды и нумерация версий VMware vCenter на платформе vSphere - как это устроено?


    Очень часто администраторы платформы VMware vSphere задаются следующими вопросами о версиях продукта vCenter: какая разница между обновлением vCenter (он же update) и патчем (patch)? в чем отличие апгрейда (upgrade) и миграции (migration)? почему некоторые версии vCenter нумеруются как-то отдельно? Попробуем дать ответы на эти вопросы ниже, используя материал вот этой статьи в блоге VMware.

    Первое, что нужно понять - это нумерация версий vCenter. Она подразумевает 2 компонента - номер версии (например, vCenter 6.7 Update 2a) и номер билда (например, 13643870):

    Номер версии имеет также и цифровое обозначение. Если вы зайдете в интерфейс VMware Appliance Management Interface (VAMI), то увидите там номер билда (13643870), а также полный номер версии (6.7.0.31000):

    Если же вы зайдете в vSphere Client и перейдете там на вкладку Summary для вашего сервера vCenter (в данном случае vCenter Server Appliance, vCSA), то увидите там версию 6.7.0:

    В данном случае в поле Build указан номер билда клиента vSphere Client (13639324), и не стоит его путать с номером билда самого vCenter. Все это как-то более-менее соотносится между собой (VAMI дает более полную информацию о цифровом номере версии).

    Теперь, чтобы сложить все это в единую картину и соотнести с датой релиза конкретной версии vCenter, существует статья базы знаний KB 2143838, где есть полезная табличка:

    Обратите внимание на последнюю колонку - Client/MOB/vpxd.log. Это версия клиента vSphere Client, и именно она появится в лог-файле vpxd.log, поэтому не стоит удивляться, что она отличается от номера билда vCenter.

    Теперь перейдем к апдейтам и патчам. vCenter Server Update - это полноценное обновление платформы, которое может включать в себя новый функционал, исправления ошибок или доработки существующей функциональности. Выходит апдейт довольно редко и имеет свое строковое наименование (например, vCenter 6.7 Update 2a). Для апдейта всегда выпускается документ Release Notes, и его можно скачать через my.vmware.com.

    Патч - это постоянно выпускаемое небольшое обновление для vCenter, которое поддерживает уровень безопасности, закрывает критические уязвимости, исправляет фатальные ошибки и т.п. Он может относиться к вспомогательным компонентам vCSA, например, Photon OS, базе данных Postgres DB или фреймворку Java.

    Для патча нет выделенного документа Reelase Notes, но информация о нововведениях доступна в VMware vCenter Server Appliance Photon OS Security Patches. Патчи нельзя скачать через my.vmware.com, но они загружаются через VMware Patch Portal. Само собой, патчи включаются в апдейты, выпускаемые на какой-то момент времени. Патчи накатываются в рамках одного цифрового обновления. То есть 6.7 Update 1 не патчится напрямую на 6.7 Update 2b, сначала надо накатить апдейт 6.7 Update 2a, а затем уже пропатчиться на 6.7 Update 2b.

    Также на VMware Patch Portal вы можете найти ISO-образы vCenter Server, но их не надо использовать для новых развертываний, они нужны только для восстановления вашего vCenter Server Appliance, если вы используете резервное копирование на уровне файлов.

    Теперь перейдем к разнице между апгрейдом и миграцией. Апгрейд - это обновление мажорной версии сервера vCenter одного типа развертывания (например, вы делаете апгрейд vCenter Server Appliance 6.5 на vCenter Server Appliance 6.7). Миграция - это когда вы меняете тип развертывания vCenter, переходя, например, с Windows-платформы на Linux (к примеру, vCenter Server 6.5 for Windows мигрируете на vCenter Server Appliance 6.7).

    Если вы обновляете vCSA 6.5 на 6.7, то апгрейд идет как бы ненастоящий - развертывается новый виртуальный модуль vCSA 6.7, и на него переезжают все настройки (FQDN, IP, сертификаты и UUID), а также содержимое базы данных vCSA 6.5.

    Также надо упомянуть и back-in-time upgrade - это когда вы хотите обновить, например, vSphere 6.5 Update 2d на vSphere 6.7 Update 1. Прямое обновление тут не поддерживается, так как  Update 2d для версии 6.5 вышел позднее, чем Update 1 для версии 6.7. То есть Update 2d содержит код, которого нет в Update 1, а значит это может вызвать потенциальные конфликты.

    Поэтому для каждой новой версии vCenter выпускается раздел Upgrade Notes for this Release, где можно найти информацию о возможности апгрейда:


    Таги: VMware, vCenter, Update, Upgrade, vSphere

    Апгрейд на VMware vCenter 6.7 с прошлых версий - практические упражнения Feature Walkthroughs.


    Недавно компания VMware опубликовала очередной набор практических упражнений Feature Walkthroughs по апгрейду VMware vCenter 6.7 с прошлых версий управляющего сервера. Они рассказывают об обновлении с помощью интерфейса командной строки vCenter Server Appliance (vCSA) CLI, а также средствами графического интерфейса мастера установки.

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

    1. Апгрейд vCenter через через vCSA CLI.

    В рамках демо Upgrading vCenter Server 6.5 to vCenter Server 6.7 администратор может узнать, каким образом выглядит консольное обновление Embedded vCenter на последнюю версию. Вам покажут как создать и редактировать настроечный JSON-файл, а также правильно использовать параметры консольной утилиты vcsa-deploy.exe.

    Кстати, обратите внимание, что обновление vSphere 6.5 Update 2d на vSphere 6.7 все еще не поддерживается.

    2. Апгрейд через графический инсталлятор VMware vCSA.

    С помощью демо Upgrading vCenter Server 6.5 to vCenter Server 6.7 using the GUI вы можете пройти по шагам процесса обновления vCenter на последнюю версию в рамках vCSA Installer и его рабочего процесса Upgrade:

    Также советуем почитать наши посты о миграции с vCenter for Windows на виртуальный модуль vCSA:


    Таги: VMware, vCenter, Upgrade, Обучение, Walkthrough

    Апгрейд распределенного виртуального коммутатора (vSphere Distributed Switch) при обновлении VMware vSphere.


    Когда вы обновляете виртуальную инфраструктуру VMware vSphere, нужно также подумать и об обновлении виртуального коммутатора (vSphere Distributed Switch, VDS), который, в зависимости от версии, предоставляет те или иные возможности.

    Если вы хотите обновить VMware vSphere 5.5 на последнуюю версию VMware vSphere 6.7 Update 1, то, как вы уже знаете, прямого апгрейда нет. Вам нужно будет обновиться на одну из версий - vSphere 6.0 или 6.5 - и потом уже накатить апгрейд до версии 6.7.

    В этом процессе есть нюанс - если вы обновитесь с 5.5 на 6.x, то вам надо будет обновить и Distributed Switch, до того, как будете проводить апгрейд на версию 6.7. В противном случае процесс обновления до версии 6.7 завершится неудачно.

    Обновить распределенный коммутатор очень просто: в vSphere Client нужно зайти в Networking, выбрать там ваш VDS-коммутатор и на вкладке "Summary" кликнуть на ссылку, где написано "Upgrades available":

    Чтобы запустить процесс обновления VDS, нужно в меню "Actions" выбрать пункт "Upgrade":

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

    Обратите внимание, что соответствие версий VDS версиям vSphere следующее:

    • vSphere 6.0 = VDS 6.0
    • vSphere 6.5 = VDS 6.5
    • vSphere 6.7 = VDS 6.6 (да, вот так странно)

    После обновления убедитесь, что виртуальный коммутатор имеет ту версию, которую вы выбрали:

    И еще вам может оказаться полезной информация о потенциальных проблемах при обновлении на VDS 6.6, описанная в KB 52621.


    Таги: VMware, vSphere, VDS, Upgrade, Networking

    Обновленная книга Upgrading to VMware vSphere 6.7 доступна для скачивания.


    В начале года мы рассказывали о книге Upgrading to VMware vSphere 6.5, которая описывала процедуры апгрейда платформы виртуализации на версию 6.5. С тех пор были выпущены обновления vSphere 6.7 и 6.7 Update 1, поэтому документ потерял актуальность.

    В связи с этим VMware выпустила обновленную книгу Дэвида Стамена (David Stamen) Upgrading to VMware vSphere 6.7, которая стала доступна для скачивания на днях:

    В обновленную версию также включены все нововведения последних версий продуктов Site Recovery Manager и Horizon, которые работают в инфраструктуре vSphere. С точки зрения основной платформы, рассматриваются сценарии апгрейда с vSphere 6.0 и 6.5.

    В книге процесс обновления разбит на три фазы:

    • Фаза 1: Pre-upgrade – обозначает фронт работ и требований, которые должны быть выполнены перед началом процедуры апгрейда.
    • Фаза 2: Upgrade – описание шагов процесса обновления и иллюстрация их исполнения.
    • Фаза 3: Post-Upgrade – валидация результата в соответствии с изначально поставленными целями.

    Скачать книгу Upgrading to VMware vSphere 6.7 можно по этой ссылке.


    Таги: VMware, vSphere, Upgrade, Book

    1 | 2 | 3    >   >>
Интересное:





Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

26/08/2024:  VMware Explore 2024 Лас-Вегас
04/11/2024:  VMware Explore 2024 Барселона

Быстрый переход:
VMware VMachines Offtopic NAKIVO vStack Gartner Veeam Vinchin StarWind Nakivo IT-Grad Cloud Teradici VeeamON VMworld PowerCLI Citrix VSAN GDPR 5nine Hardware Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud DevOps Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs IDC Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V Aria Tanzu NSX EUC Private AI Update Avi Broadcom Workstation Community vSAN VCF Skyline HCX AI Host Client Explore Chargeback Horizon Labs SASE Workspace ONE Networking Backup Ransomware Tools Performance Lifecycle VCP Network AWS Intel API USB SDDC Fusion Whitepaper SD-WAN Mobile VMUG SRM ARM HCI Converter Photon OS Operations VEBA App Volumes Certification VMConAWS Workspace Imager SplinterDB DRS SAN vMotion Open Source iSCSI Partners HA Monterey Kubernetes V2V vForum Learning vRNI UAG Support Log Insight AMD vCSA NSX-T Graphics NVMe HCIBench SureBackup vCloud Обучение Web Client vExpert OpenStack UEM CPU PKS vROPs Stencils Bug VTL Forum Video Update Manager VVols DR Cache Storage DRS Visio Manager Virtual Appliance PowerShell LSFS Client Datacenter Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Encryption Nested XenDesktop VSA vNetwork SSO VMDK Appliance VUM HoL Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP iOS SC VMM VDP PCoIP RHEV vMA Award Licensing Logs Server Demo vCHS Calculator Бесплатно Beta Exchange MAP ONE DaaS Hybrid Monitoring VPLEX UCS GPU SDK Poster VSPP Receiver VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V KB VirtualCenter NFS ThinPrint ESA Troubleshooting Director Android Python Upgrade Stretched ML Hub Guardrails CLI VCPP Memory Driver Foundation HPC Orchestrator Optimization Bugs SVMotion Diagram Ports SIOC Plugin Helpdesk VIC VDS Migration Air DPM Flex Mac SSH VAAI Heartbeat MSCS Composer
Полезные постеры:

Постер 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 (обзорный):

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Сравнение Oracle VirtualBox и VMware Workstation.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Работа с дисками виртуальных машин VMware.

Диски RDM (Raw Device Mapping) для виртуальных машин VMware vSphere и серверов ESX.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Подключение локальных SATA-дисков сервера VMware ESXi в качестве хранилищ RDM для виртуальных машин.

Где скачать последнюю версию VMware Tools для виртуальных машин на VMware ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Как перенести виртуальную машину VirtualBox в VMware Workstation и обратно

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Полезные ресурсы:

Последние 100 утилит VMware Labs

Новые возможности VMware vSphere 8.0 Update 1

Новые возможности VMware vSAN 8.0 Update 1

Новые документы от VMware

Новые технологии и продукты на VMware Explore 2022

Анонсы VMware весной 2021 года

Новые технологии и продукты на VMware VMworld 2021

Новые технологии и продукты на VMware VMworld 2020

Новые технологии и продукты на VMware VMworld Europe 2019

Новые технологии и продукты на VMware VMworld US 2019

Новые технологии и продукты на VMware VMworld 2019

Новые технологии и продукты на VMware VMworld 2018

Новые технологии и продукты на VMware VMworld 2017



Copyright VM Guru 2006 - 2024, Александр Самойленко. Правила перепечатки материалов.
vExpert Badge