Доступность инструкций процессора в зависимости от версии vHW

Ранее на бложике публиковались две статьи о разном поведении виртуальных машин при разном vHW и EVC

  1. Минимальная рекомендуемая версия vHW
  2. EVC Mode и vHW

Один из участников сообщества VMUG провел анализ доступных инструкций процессора в зависимости от версии виртуального железа с помощью утилиты /proc/cpuinfo. В результат появилась занимательная таблица:
vHW CPU flags
P.S. Комментарий автора:

После обсуждения CPUID решил проверить зависимость доступных инструкций от vHW, но основной вывод уже был сделан в КВ по процессорным уязвимостям: «безопасной» версией является 9, а тормозить оно перестаёт на 11. Также выяснилось:
1. vHW режет флаги не так сильно, как EVC. Например, на vHW=8 доступны fma и movbe (Haswell), а на vHW=13 доступны xsavec и xsaves (Skylake).
2. Между 13-16 версиями без NVDIMM и гостевой виртуализации нет разницы.

Рубрика: 4.0, 4.1, 5.0, 5.1, 5.5, 6.0, 6.5, 6.7, VMware, vSphere | 1 комментарий

Релиз платформы VMware vSphere 6.7 Update 3

Компания VMware выпустила обновление своей платформы виртуализации VMware vSphere 6.7 Update 3:

VMware ESXi 6.7 Update 3 Release Notes

VMware vCenter Server 6.7 Update 3 Release Notes

VMware vSAN 6.7 Update 3 Release Notes

vSAN 6.7 U3 Technical Overview

New Release: PowerCLI 11.4.0

Рубрика: 6.7, VMware, vSphere, Новости | Оставить комментарий

VCSA VAMI переключается на «Installation in progress»

При попытке обновления VCSA он завис на тексте:

"Installation in progress
22%
Staging in progress"

Подождав довольно долго, я понял, что ему так не помочь. Подключился по SSH и обновил через CLI.

Всё прошло гладко, но при подключении к VAMI каждый раз шло перенаправление на страницу /update/progress c тем же текстом:

"Installation in progress
22%
Staging in progress"

Робот в поддержке предложил статью Accessing the VAMI returns error «Update installation in progress» after recovering from a failed update (67179), советом из которой я и воспользовался:

  1. Подключить к VCSA по SSH
  2. Проверить содержимое файла «/etc/applmgmt/appliance/software_update_state.conf». Должно быть примерно такое содержимое:
    {
    
        "operation_id": "/storage/core/software-update/stage_install_operation",
    
        "latest_query_time": "2019-02-13T14:53:00Z",
    
        "state": "INSTALL_IN_PROGRESS",
    
        "version": "6.7.0.21000"
    
    }
  3. Сделать копию файла «/etc/applmgmt/appliance/software_update_state.conf»
  4. Остановить сервис applmgmt командой: service-control —stop applmgmt
  5. Удалить файл «software_update_state.conf»
  6. Запустить сервис applmgmt командой: service-control —start applmgmt
  7. Зайти на VAMI для проверки
Рубрика: Новости | Оставить комментарий

Проблемы с VMware HA после обновления vCenter

Майское обновление vCenter 6.0 (U3i) и 6.5 (U2d) вывело из строя несколько кластеров vSphere HA. Симптомы были одинаковые: часть узлов кластера не может связаться с мастером. Лечение, увы, отличалось:

  • части узлов хватило переконфигурировать HA-агента;
  • часть узлов пришлось выводить в режим обслуживания и перезагружать.

Увидеть ситуацию помогли Alarms, сработавшие на хостах.

P.S. Не все обновления одинаково полезны…

Рубрика: 6.0, 6.5, VMware, vSphere | Оставить комментарий

HPE iLO4 и HTML5

Последние 8 лет я администрирую преимущественно серверы HPE. Интерфейс удаленного управления серверами называется iLO, за эти годы он прошел по пути развития от iLO100 до iLO5.

Для работы с консолью сервера было всего два варианта: .NET-надстройка (Integrated Console), поддерживаемая только в Internet Explorer и Java, устанавливаемая дополнительно.

В силу определенных проблем, случающихся с Java, я не любитель использовать их на серверах.

Я как-то привык к IE за годы работы с iLO2, однако, в iLO4 открытия консоли необходимо было ждать порядка минуты.

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

Особенно грустно было сравнивать скорость открытия консоли в iLO4 и iLO5.

Какова же была моя радость, когда после обновления прошивки iLO4 до версии 2.70, я увидел HTML5 консоль и там.

Чтение Release notes показало, что HPE любезно добавили в iLO4 этот вариант работы.

Рубрика: Hardware, HP | 2 комментария

Настройка разрешений на vCenter

Как-то потребовалось мне решить задачу «сосуществования» в рамках vCenter нескольких команд администраторов, обслуживающих свои кластера vSphere.

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

Читать далее

Рубрика: 5.5, 6.0, 6.5, 6.7, VMware, vSphere | Оставить комментарий

Данные о ВМ в vMotion Wizard

Про полезняшки в новых версиях vSphere мы уже писали ранее: о флешовом клиенте в статье  Фильтры, задания и снимки в VMware vSphere 6.7, о ESXi-ом клиенте в Просмотр логов на ESXi.

Сегодня заметка о новой фишке vMotion Wizard — VM origin.

Часто бывает, что запустил перемещение виртуальной машины со сменой хоста и хранилища и тут приходит мысль «а сейчас-то как машина размещена?».

Разработчики HTML5-клиента решили это дело упростить и сделали подсказку — достаточно щёлкнуть VM origin:

Рубрика: 6.5, 6.7, VMware, vSphere, Советы | Оставить комментарий

Видеозаписи докладов VeeamON Forum Россия 2019

Для тех, кто не смог посетить VeeamON Forum Россия 2019 доступны видеозаписи докладов

The Premier Forum for Cloud Data Management

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

Быстрое восстановление с PureStorage ObjectEngine. Пришли времена когда бэкапы заказчики сохраняют на флеши(!!!) и в облако, происходит переход от схемы disk2disk2tape на схему flash2flash2cloud. Доклад офигенно ломает стереотипы.

Тонкости проектирования комплексной платформы Veeam с более 25.000 виртуальных машин. Докладчик рассуждает о масштабируемости инфраструктуры VBR для гигантской виртуальной среды. Из доклада становится понятна логика — какого чёрта так много ресурсов нужно бэкапам.

Как минимизировать человеческий фактор при DR-сценарии? VAO 2.0 – новые возможности! Классика жанра — контрмеры при авариях надо планировать заранее, а не во время аварии!

Доступность данных. Ожидания и реальность. Довольно бизнесовый доклад, но для меня открыл существование методологии, о которой я догадывался интуитивно, Business Impact Analysis.

Также вам могут быть интересные и другие темы.

Рубрика: Backup&Replication, Veeam, Новости | Оставить комментарий

Развертывание виртуальной машины vSphere через PowerSHell часть 1

Стал задаваться вопросом — как автоматизировать выполнение рутинных операций в vSphere?

Лучше бы не задавался 🙂

Начал с задачи «развернуть виртуальную машину из шаблона с указанной кастомизацией гостевой операционной системы».

Основные проблемы, с которыми я столкнулся:

  • мною использовалась настройка кастомизации ОС «Prompt User», спрашивающая только IP-адрес (подразумевается, что развертывание происходит в одно и то же адресное пространство). Как оказалось, проще использовать передачу «всех» параметров IP в скрипте;
  • перемещение учетной записи сервера после ее развертывания для применения групповых политик в другой контейнер Active Directory;
  • поле «Notes» получает строку. Как передать ей несколько строк, если потребуется перевод строки, я пока не разбирался;
  • за кадром остались процессы дальнейшей настройки сервера — установка обновлений и дополнительного ПО. Это будет рассмотрено в следующих частях статьи.

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

А вот что получил:

Get-OSCustomizationSpec -Name windows | New-OSCustomizationSpec -Name temp1 -Type NonPersistent
Get-OSCustomizationSpec -Name temp1 | Get-OSCustomizationNicMapping | Set-OSCustomizationNicMapping -IpMode UseStaticIP -IpAddress '10.0.0.1' -SubnetMask '255.255.255.0' -DefaultGateway '10.0.0.254' -Dns '10.0.0.254','10.0.0.253'
New-VM -Name 'new-vm' -Template (Get-Template windows_template) -OSCustomizationSpec (Get-OSCustomizationSpec 'temp1') -ResourcePool (Get-ResourcePool -Name 'Resources'-Location 'Cluster_Name') -Datastore (Get-DatastoreCluster -Name 'Datastore_Cluster') -Notes "Zdes mogla by byt vasha reklama"
Start-VM -VM new-vm
Do {Get-ADComputer -identity new-vm -ErrorAction SilentlyContinue;write-host "." -nonewline -f red;sleep 3} until(Get-ADComputer -identity new-vm -ErrorAction SilentlyContinue -warningaction silentlycontinue)
Move-ADObject -identity (Get-ADComputer -identity new-vm).distinguishedname -TargetPath "OU=Servers,DC=DOMAIN,DC=COM"
Do {$tools=(Get-VM -Name new-vm).ExtensionData.Guest.ToolsStatus;write-host "." -nonewline -f red;sleep 3} until(($tools -eq "toolsOk") -or($tools -eq "toolsOld"))
Restart-VMGuest -VM new-vm -Confirm:$false
Start-Sleep -Seconds 10
Do {$tools=(Get-VM -Name new-vm).ExtensionData.Guest.ToolsStatus;write-host "." -nonewline -f red;sleep 3} until(($tools -eq "toolsOk") -or($tools -eq "toolsOld"))
Write-Host("Server is ready!")

Данный скрипт берет гостевую кастомизацию «windows» (Guest Customization OS) и создает на ее основе временную кастомизацию «temp1».

Затем скрипт задает настройки IP, которые должна будет получить новая ВМ.

Далее мы создаем виртуальную машину из шаблона «windows_template», используя подготовленную кастомизацию «temp1». Машина создается в кластере «Cluster_name» с примечанием о том, для чего нужна эта ВМ. Диски шаблона при этом клонируются на кластер хранилищ (Datastore Cluster) с названием «Datastore_Cluster».

Затем мы включаем виртуальную машину и ждем.

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

Как только мы этого дождались, мы перекладываем эту учетную запись ПК в соответствующую OU.

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

Затем ждем 10 секунд пока VMware Tools 100% остановятся в ходе перезагрузки, ждем пока они будут запущены и выводим на экран сообщение о том, что сервер готов.

Рубрика: 6.5, VMware, vSphere | Метки: | 1 комментарий

VMware PSC replication

Компонент Single Sign On, выполняющий проверку подлинности, появился в VMware vSphere 5.1. К vSphere 5.5 он стал «адекватнее» и стабильнее.

Его можно было поставить как на отдельный сервер, так и совместить вместе с vCenter Server.

В vSphere 6 этот компонент был объединен с другими сервисами в роли Platform Service Controller.

С тех пор и до vSphere 6.7 (или 6.7 Update 1) рекомендуемой схемой высокодоступного размещения PSC была следующая:

  1. Несколько внешних/отдельных PSC-серверов. Размещать PSC совместно с vCenter и реплицировать данные не некомендовалось.
  2. Требовался балансировщик между PSC и vCenter-серверами (хотя я видел скрипты, переключающие vCenter на резервный psc при недоступности основного).

Наверное, особенно круто было заниматься обновлением этого зоопарка из 4+ систем.

Особенно я прослезился со следующего KB — правила репликации PSC, рассказавшего о том, что репликация происходит в том порядке, в каком ранее добавлялись PSC (если развернули первый, на него нацелили второй, на второй — третий, то и репликация пойдет по такой схеме). Все связи между SSO-службами добавляются и удаляются только вручную.

Попутно узнал, что рекомендуемая топология — c центральным PSC.

Еще несколько KB:

А теперь к хорошим новостям: забудьте все, что только что прочитали 🙂

Начиная с vCenter 6.7 рекомендуемой топологией является встроенный PSC для любой топологии. Вы даже можете сделать vCenter HA (vCenter High Availability) для встроенного PSC, если хотите его защитить.

Ну и к вопросу резервной копии — в v6.7 появился ручной File-Based Backup, позволяющий сделать бэкап системы vCenter+PSC, восстанавливаемой с нуля с помощью этих файлов.

А в v6.7 Update 1 — возможность запуска бэкапа по расписанию.

В общем, администрирование нескольких vCenter-серверов в v6.7 стало значительно легче.

Рубрика: 5.1, 5.5, 6.0, 6.5, 6.7, VMware, vSphere | Оставить комментарий