Новости Статьи VMware Veeam StarWind vGate! Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4140 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: Вышел VMware vCenter 6.5c - фикс уязвимости Apache BlazeDS

Интересная утилита для устранения проблем в инфраструктуре VMware vSphere - Runecast Analyzer.


Дункан Эппинг рассказал про довольно интересную штуку для среды VMware vSphere - Runecast Analyzer. Эта утилита, поставляемая в виде виртуального модуля, позволяет просканировать хост-серверы ESXi на предмет соответствия текущего состояния хостов (конфигурация, уровень обновлений) некоторым проблемным моментам, описанным в базе знаний VMware KB.

После развертывания модуля Runecast нужно указать параметры доступа к VMware vCenter, после чего просто нажать кнопку Analyze Now. В результате будет выведен отчет о проблемах, разделенных по разным уровням критичности:

На вкладке KBs discovered (куда можно "провалиться" по клику в соответствующую категорию на дэшборде) показан детальный отчет обо всех проблемах. Если конкретная KB не имеет к вашей инфраструктуре отношения, или вы готовы с этим жить - можно просто нажать кнопку Ignore:

Каждый элемент можно раскрыть в более детальном виде и увидеть все параметры хоста/виртуальных машин, относящиеся к проблеме:

Также есть представление, в котором можно производить анализов логов (Verbose Dashboards), там можно искать по ключевому слову в конкретном файле журнала, чтобы обнаружить источник возникшей проблемы:

Скачать пробную версию Runecast Analyzer 1.5 на 30 дней можно по этой ссылке.


Таги: VMware, vSphere, Troubleshooting, VMachines, ESXi

Настройка ESXi Dump Collector на VMware vCenter Server Appliance для удаленного сбора дампов.


Некоторые из вас знают, что в VMware vSphere есть механизм удаленного сбора дампов с серверов VMware ESXi, которые иногда выпадают в "розовый экран смерти" с диагностической информацией в случае критической ошибки.

Для сбора диагностической информации используется специальная служба ESXi dump collector service, которая принимает дамп хост-сервера по сети. Но сначала эту службу надо включить на сервере VMware vCenter (в частности, на vCenter Server Appliance). Для этого надо в vSphere Web Client пойти сюда:

Home > Administration > System Configuration > Services > VMware vSphere ESXi Dump Collector > Start

Кроме этого, нужно задать порт для приема дампов, а также надо сконфигурировать максимальный размер репозитория в гигабайтах, задав параметр Repository max size.

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

esxcli system coredump network get

Зададим сетевые параметры отправки дампов :

esxcli system coredump network set -- interface -name vmk0 -- server -ipv4 172.20.10.94 --server -port 6500

И включим службу сбора дампов:

esxcli system coredump network set --enable true

Проверим параметры отправки:

Теперь можно выполнить следующую команду для проверки параметров:

esxcli system coredump network check

Теперь, чтобы проверить, что vCenter Server Appliance принимает дампы, надо открыть следующий файл:

/var/log/vmware/netdumper/netdumper.log

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

Теперь принудительно отправим ESXi в розовый экран командой CrashMe и заглянем в этот же файл еще раз:

Мы видим, что теперь появилась запись о дампе var/core/netdumps/ffff/172/20/10/52/zdump_ffff.172.20.10.52-2017-01-05-09_53-0. Откроем этот файл и увидим содержание дампа, появляющегося при крэше ESXi:


Таги: VMware, ESXi, vCSA, Logs, Troubleshooting

Решение проблемы потери сетевого подключения у виртуальных машин VMware в облаке IaaS.


Представляем очередной гостевой пост компании ИТ-ГРАД, посвященный инфраструктуре VMware vCloud Director. Как часто вы сталкиваетесь с проблемами в облачном окружении, устранить которые можно обходными путями по причине отсутствия конечного решения? Одна из таких проблем – потеря сетевого подключения у виртуальных машин на базе ОС Windows Server 2012/R2 с сетевыми адаптерами E1000/E1000e в облаке IaaS.


Таги: IT-Grad, Cloud, Troubleshooting, Cloud Computing, IaaS, Blogs

Решение распространенных проблем в облаке IaaS на базе гипервизора VMware Часть 1. Буфер обмена.


Представляем очредную статью компании ИТ-ГРАД, посвященную решению проблем в облаке IaaS. Как часто компании сталкиваются с проблемами в виртуальном окружении? Ответ на этот вопрос зависит от многих факторов, в том числе и от уровня профессионализма пользователей и специалистов отдельно взятой организации. Каждый из вас наверняка знаком с понятием «дефолтная настройка», то есть опциями по умолчанию, которые, как известно, могут отключать определенный функционал системы.
Таги: VMware, IaaS, IT-Grad, Troubleshooting

Новое на VMware Labs - утилита HCIbench для организации тестирования производительности инфраструктуры хранилищ Virtual SAN и не только.


На сайте проекта VMware Labs появилась очередная утилита HCIbench, которая может оказаться полезной тем, кому требуется провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

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

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

Суть работы HCIbench проста - пользователь задает параметры работы скрипта, а утилита дает команду Vdbench, какие действия необходимо выполнить в кластере хранилищ.

Вводим число виртуальных машин и дисков, а также их размер:

Задаем тестовую конфигурацию:

Задаем параметры тестирования виртуальных дисков:

Решение состоит из двух компонентов:

  • Виртуальный модуль Controller VM, на котором установлены:
    • Ruby vSphere Console (RVC)
    • Утилита Virtual SAN Observer
    • Automation bundle
    • Файлы конфигурации
  • Тестовая виртуальная машина Linux, используемая как шаблон.

Ну и вот какие задачи может выполнять HCIbench:

  • Соединение с тестируемым окружением Virtual SAN. Утилита может быть в отдельной инфраструктуре vSphere, но нужно иметь доступ к целевому кластеру хранилищ.
  • Развертывание тестовых виртуальных машин с ОС Linux, основываясь на введенных параметрах пользователя (число машин и число виртуальных дисков на одну машину, а также их размер).
  • Опциональный запуск команды dd на каждом из виртуальных дисков, чтобы инициализировать хранилища и создать диски полного размера (thick).
  • Передача параметров VDbench на каждую из тестовых ВМ. В файле конфигурации описана целевая нагрузка и спецификация ее выполнения.
  • Запуск утилиты Virtual SAN Observer перед началом тестирования и генерация статистик по завершению тестов.
  • Удаление тестового окружения инфраструктуры виртуальных машин.
  • Сбор и агрегация данных VDbench.

В итоге мы получаем вот такие графики производительности в Virtual SAN Observer:

Утилита HCIbench поставляется в виде готового виртуального модуля и имеет веб-интерфейс конфигурации. Скачать HCIbench можно по этой ссылке. Инструкция по развертыванию и использованию доступна тут.


Таги: VMware, Labs, Performance, Troubleshooting, Virtual SAN, Storage

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


Многие администраторы VMware vSphere часто сталкиваются с необходимостью получить какие-то файлы конфигурации с VMware ESXi или заглянуть в логи хост-сервера. Для этих целей они используют SSH-клиенты, такие как WinSCP / Veeam FastSCP, либо копируют файлы еще каким-нибудь экзотическим образом.

Но есть простой способ - забрать файл конфигурации esx.conf либо другой конфиг-файл или лог через веб-браузер. Просто зайдите по ссылке:

https://<имя хоста ESXi>/host

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

Таким вот образом можно получить любой файл для целей траблшутинга - например, мы тут видим не только основной файл конфигурации хоста esx.conf, но и логи VMware HA (fdm.log) или агента vCenter (vpxa.log), а также основной лог службы хост-сервера ESXi (hostd.log).

Ну а известный многим William Lam написал на основе vSphere API (он как раз и используется для доступа к объектам хоста) сценарий PowerCLI, который позволяет быстро вывести основную конфигурацию ESXi, содержащуюся в esx.conf.


Таги: VMware, ESXi, API, VMachines, Logs, Troubleshooting

Новая утилита на VMware Labs - DRS Doctor для диагностики кластеров.


На сайте проекта VMware Labs, где очень часто появляются полезные штуковины для продуктов VMware, была выпущена очередная интересная утилита - DRS Doctor. Это средство позволяет проводить диагностику поведения DRS-кластера в рамках сервера VMware vCenter. DRS Doctor собирает такую информацию, как состояние кластера, распределение рабочей нагрузки, миграции DRS и многое другое. Все это объединяется в удобном и человекочитаемом формате логов.

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

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

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

Утилита поставляется в качестве средства командной строки для Linux. Для работы вам понадобится установленный Python. Инструкции по установке на CentOS доступны здесь, а скачать DRS Doctor можно по этой ссылке.


Таги: VMware Labs, DRS, Troubleshooting, vSphere

Новое на VMware Labs: средство Logon Monitor для решения проблем с логином пользователей в виртуальные ПК.


На сайте проекта VMware Labs появилась еще одна полезная утилита для траблшутинга инфраструктуры виртуальных ПК VMware Horizon View. Средство VMware Logon Monitor позволяет собирать необходимую для решения проблем и поддержки информацию с рабочих ПК пользователей во время их логина в свои десктопы.

По умолчанию Logon Monitor собирает следующие метрики:

  • Время логина
  • Время старта сессии
  • Время последней синхронизации профиля
  • Время загрузки командной оболочки (shell load)
  • Инициализация механизма Windows Folder Redirection
  • Инициализация групповых политик
  • Время старта процессов Windows
  • Время начала исполнения скрипта групповых политик
  • Время начала исполнения сценариев PowerShell
  • Использование памяти

Сопоставляя данные отметки времени, администратор инфраструктуры Horizon View может понять, на каком именно этапе возникает проблема, вызывающая задержку при начале работы пользователя со своим десктопом и приложениями. В качестве настольных ОС поддерживаются Windows 7 и Windows 10, в комментариях пишут также, что Windows 8.1 x64 не поддерживается.

В ближайшее время также ожидается поддержка утилиты VMware Logon Monitor такими продуктами VMware, как Horizon Agent, Horizon Persona Management и механизмом App Volumes.

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

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


Таги: VMware, Horizon, Troubleshooting, Labs, View

Онлайн-лабораторная работа по VMware vRealize Automation 7.


На сайте Hands-on-Labs (HOL), где компания VMware размещает практические задания для администраторов в виде онлайн-лабораторных работ, появилась лабораторка, посвященная VMware vRealize Automation 7. Кстати, не стоит путать Hands-on-Labs, где нужно выполнять определенные задачи в консолях, и демо продуктов VMware Feature Walkthrough, основная цель которых показать доступные фичи отдельных решений.

Лабораторная работа по "HOL-SDC-1633 vRealize Automation 7: What's New" доступна по этой ссылке:

Вы сможете самостоятельно узнать о новой архитектуре развертывания решения, новых мастерах и новой службе vIDM Identity Management service.

Лабораторная работа по VMware vRealize Automation 7 содержит в себе 6 модулей:

  • What's New Overview
  • Architecture, Installation and VMware Identity Manager
  • Converged Blueprint Basics - IaaS, NSX and Application Authoring
  • Converged Blueprints Advanced - XaaS, Dependencies and Parameters
  • Mission Extensible: Event Broker for Lifecycle Extensibility
  • Enhanced vRA Troubleshooting with Log Insight 3 

Все вместе они займут три с половиной часа вашего времени. Вы поработаете с Converged Blueprint Designer и создадите собственные NSX Micro-Segmented blueprints, а также интегрируете решение с такими продуктами для управления жизненным циклом систем, как Puppet. Кроме того, вы сможете самостоятельно создать рабочие процессы в Event Broker, поработаете с ITSM-утилитами и проведете поиск и решение проблем в виртуальной инфраструктуре с помощью Log Insight content pack.


Таги: VMware, Labs, vRealize, Update, Troubleshooting, Обучение, Automation

Сообщение No host data available на вкладке Hardware Status в VMware vCenter Server 6.0.


Интересная штука - при свежей установке или обновлении на VMware vCenter Server 6.0, если вы обычным пользователем без глобальных административных привилегий зайдете на вкладку Monitor -> Hardware Status -> Sensors для просмотра данных аппаратных сенсоров одного из хостов, вы увидите сообщение:

No host data available

Оказывается, это известная проблема, и описана она в KB 2112847. На данный момент для нее нет решения, кроме как добавить данному пользователю Global Permissions через Web Client.

Для этого нужно сделать следующее:

1. Зайти в Web Client под аккаунтом Administrator@vsphere.local или другим, у которого есть административные привилегии по управлению SSO.

2. Перейти на вкладку Administration > Global Permissions > Manage.

3. Нажать иконку + и добавить пользователю Global Permissions, выбрав его из соответствующего домена/группы.

Помните, что Global Permissions дают неограниченный доступ к просмотру и управлению объектами датацентра.


Таги: VMware, vCenter, Troubleshooting, VMachines, Monitoring

Скрипт PowerCLI для включения/отключения SSH на уровне кластера для всех хостов VMware ESXi.


Все администраторы знают, как включать и отключать доступ по SSH на хостах ESXi. Однако часто в административных целях требуется перещелкнуть этот сервис не только на одном хост-сервере, а в пределах целого кластера VMware HA/DRS для выполнения комплекса задач на нескольких хостах. В этом случае поможет скрипт PowerCLI, который написал David Ring.

Сначала вводите IP-адрес сервера vCenter, логин и пароль администратора, ну а потом сценарий запросит имя кластера в котором вы хотите включить/отключить доступ к серверам по SSH:

Когда вы закончите проведение необходимых операций в консоли хостов ESXi по SSH, запустите скрипт повторно для отключения SSH в целях безопасности:

Ну и, собственно, сам скрипт PowerCLI:

########### vCenter Connectivity Details ###########

Write-Host “Please enter the vCenter Host IP Address:” -ForegroundColor Yellow -NoNewline
$VMHost = Read-Host
Write-Host “Please enter the vCenter Username:” -ForegroundColor Yellow -NoNewline
$User = Read-Host
Write-Host “Please enter the vCenter Password:” -ForegroundColor Yellow -NoNewline
$Pass = Read-Host
Connect-VIServer -Server $VMHost -User $User -Password $Pass

########### Please Enter the Cluster to Enable SSH ###########

Write-Host “Clusters Associated with this vCenter:” -ForegroundColor Green
$VMcluster = ‘*’
ForEach ($VMcluster in (Get-Cluster -name $VMcluster)| sort)
{
Write-Host $VMcluster
}
Write-Host “Please enter the Cluster to Enable/Disable SSH:” -ForegroundColor Yellow -NoNewline
$VMcluster = Read-Host

########### Enabling SSH ###########

Write-Host “Ready to Enable SSH? “ -ForegroundColor Yellow -NoNewline
Write-Host ” Y/N:” -ForegroundColor Red -NoNewline
$SSHEnable = Read-Host
if ($SSHEnable -eq “y”) {
Write-Host “Enabling SSH on all hosts in your specified cluster:” -ForegroundColor Green
Get-Cluster $VMcluster | Get-VMHost | ForEach {Start-VMHostService -HostService ($_ | Get-VMHostService | Where {$_.Key -eq “TSM-SSH”})}
}

########### Disabling SSH ###########

Write-Host “Ready to Disable SSH? “ -ForegroundColor Yellow -NoNewline
Write-Host ” Y/N:” -ForegroundColor Red -NoNewline
$SSHDisable = Read-Host
if ($SSHDisable -eq “y”) {
Write-Host “Disabling SSH” -ForegroundColor Green
Get-Cluster $VMcluster | Get-VMHost | ForEach {Stop-VMHostService -HostService ($_ | Get-VMHostService | Where {$_.Key -eq “TSM-SSH”}) -Confirm:$FALSE}

}

Скачать скрипт можно по этой ссылке (уберите расширение doc и добавьте .ps1).


Таги: VMware, vSphere, PowerCLI, Security, Troubleshooting, ESXi

Очередное обновление RVTools 3.8 - новые возможности.


Те из вас, кто уже давно администрирует платформу VMware vSphere, знает о такой штуке RVTools, которая помогает в выполнении многих административных задач. О прошлой версии RVTools 3.7 мы писали где-то год назад, а совсем недавно вышел очередной апдейт утилиты - RVTools 3.8.

Давайте вкратце посмотрим на новые возможности RVTools 3.8 (полный их список доступен тут):

  • VI SDK изменился с версии 5.5 на 6.0.
  • Новые поля на вкладке vInfo:
    • ChangeVersion - уникальный идентификатор конфигурации
    • статус HA VM Monitoring
    • число поддерживаемых мониторов и видеопамяти в килобайтах
    • статус конфигурации (конкретные проблемы с конфигом видны на вкладке vHealth)
    • операционная система (то, что дает VMware Tools)
  • Новые поля на вкладке vTools:
    • App state, App heartbeat и статус Kernel crash
    • Доступность операций: поддержка изменения статуса и доступность интерактивных операций с гостевой ОС
  • На вкладке vHost появился статус NTPD.
  • Проблемы с NTP теперь видны на вкладке vHealth.
  • Новое поле Config status добавлено на вкладках vHost, vCluster и vDatastore
  • На вкладке vSC+VMK добавлены поля IP 6 Address и IP 6 Gateway.
  • Все вкладки, относящиеся к виртуальным машинам, теперь имеют колонки VM Object ID, VM UUID, powerstate и template. Колонки Custom Attributes упорядочены по алфавиту.
  • На всех вкладках появилась колонка vCenter UUID.
  • Множество исправлений ошибок.

Скачать RVTools 3.8 можно по этой ссылке. Документация доступна тут.


Таги: VMware, RVTools, Update, Blogs, Troubleshooting

Полезная утилита VMware ESXi SCSI Sense Codes Decoder для поиска проблем с хранилищами.


Интересная и полезная штука обнаружилась на одном из блогов, посвященных технологиям виртуализации - утилита VMware ESXi SCSI Sense Codes Decoder. Она позволяет декодировать сообщения, появляющиеся в файле журнала vmkernel.log, когда что-то идет не так при работе хост-сервера ESXi с хранилищами по протоколу блочного доступа SCSI.

Например, вы видите вот такое сообщение:

2011-04-04T21:07:30.257Z cpu2:2050)ScsiDeviceIO: 2315: Cmd(0x4124003edb00) 0x12, CmdSN 0x51 to dev “naa.[…]” failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.

Это, на самом деле, 6 статус-кодов (они выделены жирным выше), которые можно разложить следующим образом, подставив значения в форму ESXi SCSI Sense Codes Decoder:

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

Пользоваться утилитой ESXi SCSI Sense Codes Decoder можно только онлайн.


Таги: VMware, ESXi, SCSI, Storage, Troubleshooting

Ruby vSphere Console - пример использования для поиска проблем в кластере VMware Virtual SAN.


Некоторые из вас знают, что для поиска и решения проблем в виртуальной инфраструктуры, среди прочих интерфейсов командной строки, есть такой инструмент, как Ruby vSphere Console (RVC).

Используется она достаточно редко, но ниже мы покажем пример ее использования на базе вот этой заметки от Кормака Хогана.

Чтобы запустить Ruby vSphere Console, нужно набрать в командной строке ESXi команду в следующем формате:

rvc [options] [username[:password]@]hostname

Например:

# rvc administrator:vmware@192.168.1.100

После этого появится приглашение ко вводу различных команд:

login as: root
VMware vCenter Server Appliance
administrator@192.168.1.100's password:
Last login: Thu Jul 17 22:29:15 UTC 2014 from 10.113.230.172 on ssh
Last failed login: Fri Jul 18 06:31:16 UTC 2014 from 192.168.1.20 on ssh:notty
There was 1 failed login attempt since the last successful login.
Last login: Fri Jul 18 06:31:35 2014 from 192.168.1.20
vcsa:~ # rvc administrator:vmware@192.168.1.100
0 /
1 192.168.1.100/

Их можно выполнять в рамках следующих пространств имен (namespaces):

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

Допустим, вы увидели в кластере VSAN следующую ошибку в разделе Component Metadata Health:

Invalid state

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

В столбце "Component" указан component UUID диска, с которым возникла проблема - но как узнать, на каком хранилище он расположен, в консоли vSphere Web Client? Для этого мы и возьмем Ruby vSphere Console, а именно команду vsan.cmmds_find:

> vsan.cmmds_find 0 -u dc3ae056-0c5d-1568-8299-a0369f56ddc0
---+---------+-----------------------------------------------------------+
   | Health  | Content                                                   |
---+---------+-----------------------------------------------------------+
   | Healthy | {"diskUuid"=>"52e5ec68-00f5-04d6-a776-f28238309453",      |
   |         |  "compositeUuid"=>"92559d56-1240-e692-08f3-a0369f56ddc0", 
   |         |  "capacityUsed"=>167772160,                               |
   |         |  "physCapacityUsed"=>167772160,                           | 
   |         |  "dedupUniquenessMetric"=>0,                              |
   |         |  "formatVersion"=>1}                                      |
---+---------+-----------------------------------------------------------+
/localhost/Cork-Datacenter/computers>

Тут мы видим diskUuid, где расположен проблемный компонент. Найдем теперь символьное имя устройства:

> vsan.cmmds_find 0 -t DISK -u 52e5ec68-00f5-04d6-a776-f28238309453
---+---------+-------------------------------------------------------+
   | Health  | Content                                               |
---+---------+-------------------------------------------------------+
   | Healthy | {"capacity"=>145303273472,                            |
   |         |  "iops"=>100,                                         |
   |         |  "iopsWritePenalty"=>10000000,                        |
   |         |  "throughput"=>200000000,                             |
   |         |  "throughputWritePenalty"=>0,                         |
   |         |  "latency"=>3400000,                                  |
   |         |  "latencyDeviation"=>0,                               |
   |         |  "reliabilityBase"=>10,                               |
   |         |  "reliabilityExponent"=>15,                           |
   |         |  "mtbf"=>1600000,                                     |
   |         |  "l2CacheCapacity"=>0,                                |  
   |         |  "l1CacheCapacity"=>16777216,                         |
   |         |  "isSsd"=>0,                                          |   
   |         |  "ssdUuid"=>"52bbb266-3a4e-f93a-9a2c-9a91c066a31e",   |
   |         |  "volumeName"=>"NA",                                  |
   |         |  "formatVersion"=>"3",                                |
   |         |  "devName"=>"naa.600508b1001c5c0b1ac1fac2ff96c2b2:2", | 
   |         |  "ssdCapacity"=>0,                                    |
   |         |  "rdtMuxGroup"=>80011761497760,                       |
   |         |  "isAllFlash"=>0,                                     |
   |         |  "maxComponents"=>47661,                              |
   |         |  "logicalCapacity"=>0,                                |
   |         |  "physDiskCapacity"=>0,                               |
   |         |  "dedupScope"=>0}                                     |
---+---------+-------------------------------------------------------+
>

В параметре devName мы и видим имя устройства: naa.600508b1001c5c0b1ac1fac2ff96c2b2:2. Найти его можно в консоли vSphere Client можно вот тут:

Более подробно о командах и неймспейсах Ruby Virtual Console написано вот в этом документе.


Таги: VMware, vSphere, Ruby, Console, Troubleshooting, VSAN, Virtual SAN

Улучшения Maintenance Mode в VMware vSphere 6.0 Update 2.


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

Когда хост VMware ESXi входит в режим обслуживания (Maintenance Mode), происходит следующее: все виртуальные машины на хосте перемещаются ("эвакуируются") на другие хост-серверы ESXi для того, чтобы по окончании процесса временно вывести хост из состава виртуальной инфраструктуры для манипуляций с ним, без остановки сервисов в виртуальных машинах.

Но суть улучшения Update 2 состоит в следующем. До этого релиза сначала происходила миграция запущенных виртуальных машин, которая занимала несколько минут и более, в зависимости от нагрузки на них. Затем уже происходила миграция выключенных машин и шаблонов ВМ (VM Templates), перенести которые занимает несколько секунд (просто перерегистрировать их на других хостах).

Однако при вхождении хоста в Maintenance Mode операции с его объектами (в том числе шаблонами) недоступны, а значит сервисы, задействовавшие клонирование ВМ из шаблона (например, VMware View или vCloud Director), также не могут исполнять свои функции, и пользователям придется ожидать окончания процесса.

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


Таги: VMware, vSphere, Troubleshooting, Clones, ESXi, VMachines

А вы знали о полезном режиме утилиты esxtop - Replay Mode?


Интересную новость мы обнаружили вот тут. Оказывается утилита esxtop может работать в режиме повтора для визуализации данных о производительности, собранных в определенный период времени (многие администраторы знают это, но далеко не все). Это позволит вам собрать данные о производительности хоста, например, ночью, а в течение рабочего дня проанализировать аномальное поведение виртуальной инфраструктуры VMware vSphere. Называется этот режим replay mode.

Для начала запустите следующую команду для сбора данных на хосте VMware ESXi:

# vm-support -p -d 120 -i 10 -w /vmfs/volumes/your_datastore

Объяснение параметров:

  • -p - собирать только данные о производительности is to only gather performance data
  • -d - длительность сбора (здесь 120 секунд)
  • -i - интервал сбора данных (тут раз в 10 секунд)
  • -w - хранилище куда положить выходной файл

Файл по умолчанию создается сжатым, поэтому разжимаем его следующей командой:

# tar -xzf filename.tgz

Запускаем режим воспроизведения данных следующей командой:

# esxtop -R extracted_content_file_name

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

Если при запуске esxtop replay mode вы получите ошибку такого вида:

No such file or directory esxtop […] all vm-support snapshots have been used

То просто запустите предварительно скрипт reconstruct.sh, который будет находиться в папке с разархивированным содержимым после отработки tar:

# ./reconstruct.sh


Таги: VMware, esxtop, ESXi, Troubleshooting, vSphere

5 способов узнать время работы хоста VMware ESXi с момента последней загрузки.


Иногда системному администратору VMware vSphere требуется узнать, сколько тот или иной хост ESXi работает с момента последней загрузки (например, требуется проверить, не было ли внеплановых ребутов).

Есть аж целых 5 способов сделать это, каждый из них можно применять в зависимости от ситуации.

1. Самый простой - команда uptime.

Просто заходим на хост ESXi из консоли или по SSH и выполняем команду uptime:

login as: root
Using keyboard-interactive authentication.
Password: XXXXXX
The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools. Please
see www.vmware.com/go/sysadmintools for details.

The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.
~ # uptime
04:26:24 up 00:20:42, load average: 0.01, 0.01, 0.01

2. С помощью команды esxtop.

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

# esxtop

4. Время запуска хоста из лога vmksummary.log.

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

cat /var/log/vmksummary.log |grep booted

2015-06-26T06:25:27Z bootstop: Host has booted
2015-06-26T06:47:23Z bootstop: Host has booted
2015-06-26T06:58:19Z bootstop: Host has booted
2015-06-26T07:05:26Z bootstop: Host has booted
2015-06-26T07:09:50Z bootstop: Host has booted
2015-07-08T05:32:17Z bootstop: Host has booted

4. Аптайм в vSphere Client и Web Client.

Если вы хотите вывести аптайм сразу всех виртуальных машин на хосте в VMware vSphere Client, для этого есть специальная колонка в представлении Hosts:

5. Аптайм хостов через PowerCLI.

Конечно же, время работы хоста ESXi можно посмотреть и через интерфейс PowerCLI. Для этого нужно воспользоваться командлетом Get-VMHost:

Get-VMHost | Get-View | select Name, @{N="Uptime"; E={(Get-Date) - $_.Summary.Runtime.BootTime}}|fl

Напомним, что до выполнения этой команды надо соединиться с хостом ESXi или vCenter:

Connect-VIServer -Server XXX.XXX.XXX.XXX -User YYYYYYY -Password ZZZZZZZZ


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

Зачем нужна настройка VSAN.ClomMaxComponentSizeGB в кластере VMware Virtual SAN.


Если вы посмотрите в документ VSAN Troubleshooting Reference Manual (кстати, очень нужный и полезный), описывающий решение проблем в отказоустойчивом кластере VMware Virtual SAN, то обнаружите там такую расширенную настройку, как VSAN.ClomMaxComponentSizeGB.

Когда кластер VSAN хранит объекты с данными виртуальных дисков машин, он разбивает их на кусочки, растущие по мере наполнения (тонкие диски) до размера, указанного в данном параметре. По умолчанию он равен 255 ГБ, и это значит, что если у вас физические диски дают полезную емкость меньше данного объема (а точнее самый маленький из дисков в группе), то при достижении тонким диском объекта предела физической емкости вы получите вот такое сообщение:

There is no more space for virtual disk XX. You might be able to continue this session by freeing disk space on the relevant volume and clicking retry.

Если, например, у вас физический диск на 200 ГБ, а параметры FTT и SW равны единице, то максимально объект виртуального диска машины вырастет до этого размера и выдаст ошибку. В этом случае имеет смысл выставить настройку VSAN.ClomMaxComponentSizeGB на уровне не более 80% емкости физического диска (то есть, в рассмотренном случае 160 ГБ). Настройку эту нужно будет применить на каждом из хостов кластера Virtual SAN.

Как это сделать (более подробно об этом - в KB 2080503):

  1. В vSphere Web Client идем на вкладку Manage и кликаем на Settings.
  2. Под категорией System нажимаем Advanced System Settings.
  3. Выбираем элемент VSAN.ClomMaxComponentSizeGB и нажимаем иконку Edit.
  4. Устанавливаем нужное значение.

Надо отметить, что изменение этой настройки работает только для кластера VSAN без развернутых на нем виртуальных машин. Если же у вас уже продакшен-инфраструктура столкнулась с такими трудностями, то вы можете воспользоваться следующими двумя способами для обхода описанной проблемы:

1. Задать Object Space Reservation в политике хранения (VM Storage Policy) таким образом, чтобы дисковое пространство под объекты резервировалось сразу (на уровне 100%). И тогда VMDK-диски будут аллоцироваться целиком и распределяться по физическим носителям по мере необходимости.

2. Задать параметр Stripe Width в политиках VM Storage Policy таким образом, чтобы объекты VMDK распределялись сразу по нескольким физическим накопителям.

Фишка еще в том, что параметрVSAN.ClomMaxComponentSizeGB не может быть выставлен в значение, меньшее чем 180 ГБ, а значит если у вас носители меньшего размера (например, All-Flash конфигурация с дисками меньше чем 200 ГБ) - придется воспользоваться одним из этих двух способов, чтобы избежать описанной ошибки. Для флеш-дисков 200 ГБ установка значения в 180 ГБ будет ок, несмотря на то, что это уже 90% физической емкости.


Таги: VMware, Virtual SAN, Troubleshooting, Storage

Как изменить дефолтный порт в инфраструктуре StarWind Virtual SAN.


Продолжаем рассказывать о лучшем решении для создания отказоустойчивых программных хранилищ StarWind Virtual SAN, предназначенном для создания и поддержки инфраструктуры виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. В этом посте мы расскажем о том, как поменять дефолтные порты решения Virtual SAN, так как это один из самых часто задаваемых вопросов по продукту.

По умолчанию StarWind Virtual SAN использует порты 3260 и 3261 для взаимодействия виртуальных машин с программными хранилищами. Порт 3260 используется для передачи данных от ВМ к хранилищам и обратно. Однако этот порт, зачастую, оказывается занятыми программной реализацией iSCSI от компании Microsoft, если до этого на сервере использовался данный механизм.

В этом случае при развертывании StarWind Virtual SAN имеет смысл настроить другой порт вместо 3260. Делается это следующим образом:

1. Открываем папку с решением StarWind, по умолчанию это C:\Program Files\StarWind Software\StarWind.

2. Ищем файл StarWind.cfg и открываем его.

3. Находим значение параметра <Port value="3260"/>, меняем его на нужное и сохраняем файл.

4. Перезапускаем службы StarWind на сервере для применения изменений.

Ну или в качестве альтернативного способа можете отключить службы MS iSCSI Target.


Таги: StarWind, iSCSI, Microsoft, Troubleshooting

Как сбросить (восстановить) пароль root в VMware vRealize Operations 6.x.


Не так давно мы писали о полезном дэшборде для продукта VMware vRealize Operations, а сегодня расскажем, как восстановить забытый пароль от виртуального модуля vRealize Operations 6.x (vROPs).

Если вы не помните пароль, нужно просто перезагрузить Virtual Appliance и в меню загрузки в раздел Boot Options добавить после всех параметров следующую строчку:

init=/bin/bash

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

# passwd

После этого у нас запросят создать новый пароль пользователя root, далее перезагружаем модуль командой:

# reboot

Затем неплохо бы включить сервис SSH управлять модулем уже через putty:

Чтобы SSH работал постоянно, нужно выполнить команду:

# chkconfig sshd on

Обратите внимание, что это не только способ восстановить/сбросить пароль на vROPs, но и большая дыра в безопасности, так как любой, кто имеет доступ к консоли модуля, может провернуть это.


Таги: VMware, vROPs, Enterprise, Troubleshooting, Security

vCenter Server Watchdog - сервисы контроля и восстановления доступности vCenter.


На блоге vSphere появилась отличная статья о сервисах семейства vCenter Server Watchdog, которые обеспечивают мониторинг состояния различных компонентов vCenter, а также их восстановление в случае сбоев. Более подробно о них также можно прочитать в VMware vCenter Server 6.0 Availability Guide.

Итак, сервисы Watchdog бывают двух типов:

  • PID Watchdog - мониторит процессы, запущенные на vCenter Server.
  • API Watchdog - использует vSphere API для мониторинга функциональности vCenter Server.

Сервисы Watchdog пытаются рестартовать службы vCenter в случае их сбоя, а если это не помогает, то механизм VMware перезагружает виртуальную машину с сервером vCenter на другом хосте ESXi.

PID Watchdog

Эти службы инициализируются во время инициализации самого vCenter. Они мониторят только службы, которые активно работают, и если вы вручную остановили службу vCenter, поднимать он ее не будет. Службы PID Watchdog, контролируют только лишь наличие запущенных процессов, но не гарантируют, что они будут обслуживать запросы (например, vSphere Web Client будет обрабатывать подключения) - этим занимается API Watchdog.

Вот какие сервисы PID Watchdog бывают:

  • vmware-watchdog - этот watchdog обнаруживает сбои и перезапускает все не-Java службы на сервере vCenter Server Appliance (VCSA).
  • Java Service Wrapper - этот watchdog обрабатывает сбои всех Java-служб на VCSA и в ОС Windows.
  • Likewise Service Manager - данный watchdog отвечает за обработку отказов всех не-Java служб сервисов platform services.
  • Windows Service Control Manager - отвечает за обработку отказов всех не-Java служб на Windows.

vmware-watchdog

Это шелл-скрипт (/usr/bin/watchdog), который располагается на виртуальном модуле VCSA. Давайте посмотрим на его запущенные процессы:

mgmt01vc01.sddc.local:~ # ps -ef | grep vmware-watchdog
root 5767 1 0 16:20 ? 00:00:00 /bin/sh /usr/bin/vmware-watchdog -s rhttpproxy -u 30 -q 5 /usr/sbin/rhttpproxy -r /etc/vmware-rhttpproxy/config.xml -d /etc/vmware-rhttpproxy/endpoints.conf.d -f /etc/vmware-rhttpproxy/endpo root 7930 1 0 16:21 ? 00:00:00 /bin/sh /usr/bin/vmware-watchdog -s vws -u 30 -q 5 /usr/lib/vmware-vws/bin/vws.sh root 8109 1 0 16:21 ? 00:00:11 /bin/sh /usr/bin/vmware-watchdog -s syslog -u 30 -q 5 -b /var/run/rsyslogd.pid /sbin/rsyslogd -c 5 -f /etc/vmware-rsyslog.conf root 8266 1 0 16:21 ? 00:00:11 /bin/sh /usr/bin/vmware-watchdog -b /storage/db/vpostgres/postmaster.pid -u 300 -q 2 -s vmware-vpostgres su -s /bin/bash vpostgres -c 'LD_LIBRARY_PATH=/opt/vmware/vpostgres/curre root 9422 1 0 16:21 ? 00:00:00 /bin/sh /usr/bin/vmware-watchdog -a -s vpxd -u 3600 -q 2 /usr/sbin/vpxd root 13113 1 0 16:22 ? 00:00:00 /bin/sh /usr/bin/vmware-watchdog -s vsan-health -u 600 -q 10 su vsan-health -c '/opt/vmware/bin/vmware-vsan-health /usr/lib/vmware-vpx/vsan-health/VsanHealthServer.py -p 8006' root 28775 19850 0 20:42 pts/0 00:00:00 grep vmware-watchdog

В понятном виде это можно представить так:

Служба Имя процесса Перезапускать ВМ? Минимальный аптайм Число перезагрузок
Reverse Proxy rhttpproxy Нет 30 секунд 5
vCenter Management Web Service vws Нет 30 секунд 5
Syslog Collector Syslog Нет 30 секунд 5
vPostgres Database vmware-vpostgres Нет 5 минут 2
vCenter Server vpxd Да 1 час 2
VSAN Health Check vsan-health Нет 10 минут 10

Давайте разберем эти параметры на примере наиболее важной службы VPXD:

-a
-s vpxd
-u 3600
-q 2

Это означает, что:

vpxd (-s vpxd) запущен (started), для него работает мониторинг, и он будет перезапущен максимум дважды в случае сбоя (-q 2). Если это не удастся в третий раз при минимальном аптайме 1 час (-u 3600 - число секунд), виртуальная машина будет перезагружена (-a).

Полный список параметров представлен ниже:

-d = DAEMONIZE
-n = QUIET
-b = BG_PROC-s = START
-k = STOP
-r = QUERY
-a = REBOOT_FLAG
-u = MIN_UPTIME
-q = MAX_QUICK_FAILURES
-t = MAX_TOTAL_FAILURES
-i = IMMORTAL
-c = CLEANUP_CMD
-f = EXIT_CLEANUP_CMD

Java Service Wrapper

Он основан на Tanuki Java Service Wrapper и нужен, чтобы обнаруживать сбои в Java-службах vCenter (как обычного, так и виртуального модуля vCSA). Вот какие службы мониторятся:

mgmt01vc01.sddc.local:~ # ps -ef | grep tanuki
cm 6331 6324 0 16:20 ? 00:00:37 /usr/java/jre-vmware/bin/vmware-cm -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -Dlog4j.configuration=cm-log4j.properties -Dxml.config=ht root 6876 6869 0 16:20 ? 00:00:50 /usr/java/jre-vmware/bin/vmware-cis-license -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dorg.apache.catalina.startup.EXIT_ON_INIT_FAILURE=TRUE -XX:+ForceTimeHighRe root 7267 7258 1 16:21 ? 00:03:45 /usr/java/jre-vmware/bin/vmware-sca -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/lo root 7634 7627 0 16:21 ? 00:00:29 /usr/java/jre-vmware/bin/vmware-syslog-health -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -DlogDir=/var/log/vmware/syslog -Dlog4j.config 1002 7843 7836 0 16:21 ? 00:01:08 /usr/java/jre-vmware/bin/vmware-vapi-endpoint -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -Dlog4j.configuration=file:/etc/vmware-vapi//e root 8453 8433 1 16:21 ? 00:02:55 /usr/java/jre-vmware/bin/vmware-invsvc -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dvim.logdir=/var/log/vmware/invsvc -XX:+ForceTimeHighResolution -XX:+ParallelRefP root 10410 10388 0 16:22 ? 00:00:54 /usr/java/jre-vmware/bin/vmware-sps -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -Dxml.config=../conf/sps-spring-config.xml -Dpbm.config=../conf/pbm-spring-config.xml 1007 11099 11088 0 16:22 ? 00:01:27 /usr/java/jre-vmware/bin/vmware-vpx-workflow -Dorg.tanukisoftware.wrapper.WrapperSimpleApp.waitForStartMain=FALSE -XX:+ForceTimeHighResolution -ea -Dlog4j.configuration=conf/workflow.log4j.p root 23423 19850 0 20:41 pts/0 00:00:00 grep tanuki

Если Java-приложение или JVM (Java Virtual Machine) падает, то перезапускается JVM и приложение.

Likewise Service Manager

Это сторонние средства Likewise Open stack от компании BeyondTrust, которые мониторят доступность следующих служб, относящихся к Platform Services среды vCenter:

  • VMware Directory Service (vmdir)
  • VMware Authentication Framework (vmafd, который содержит хранилище сертификатов VMware Endpoint Certificate Store, VECS)
  • VMware Certificate Authority (vmca)

Likewise Service Manager следит за этими сервисами и перезапускает их в случае сбоя или если они вываливаются.

mgmt01vc01.sddc.local:~ # /opt/likewise/bin/lwsm list | grep vm
vmafd running (standalone: 5505)
vmca running (standalone: 5560)
vmdir running (standalone: 5600)

Вместо параметра list можно также использовать start и stop, которые помогут в случае, если одна из этих служб начнет подглючивать. Вот полный список параметров Likewise Service Manager:

list          List all known services and their status
autostart Start all services configured for autostart
start-only <service> Start a service
start <service> Start a service and all dependencies
stop-only <service> Stop a service
stop <service> Stop a service and all running dependents
restart <service> Restart a service and all running dependents
refresh <service> Refresh service's configuration
proxy <service> Act as a proxy process for a service
info <service> Get information about a service
status <service> Get the status of a service
gdb <service> Attach gdb to the specified running service

А вот таким образом можно узнать детальную информацию об одном из сервисов:

mgmt01vc01.sddc.local:~ # /opt/likewise/bin/lwsm info vmdir
Service: vmdir
Description: VMware Directory Service
Type: executable
Autostart: yes
Path: /usr/lib/vmware-vmdir/sbin/vmdird
Arguments: '/usr/lib/vmware-vmdir/sbin/vmdird' '-s' '-l' '0' '-f' '/usr/lib/vmware-vmdir/share/config/vmdirschema.ldif'
Environment:
Dependencies: lsass dcerpc vmafd

Помните также, что Likewise Service Manager отслеживает связи служб и гасит/поднимает связанные службы в случае необходимости.

API Watchdog

Этот сервис следит через vSphere API за доступностью самого важного сервиса vCenter - VPXD. В случае сбоя, этот сервис постарается 2 раза перезапустить VPXD, и если это не получится - он вызовет процедуру перезапуска виртуальной машины механизмом VMware HA.

Эти службы инициализируются только после первой загрузки после развертывания или обновления сервисов vCenter. Затем каждые 5 минут через vSphere API происходит аутентификация и опрос свойства rootFolder для корневой папки в окружении vCenter.

Далее работает следующий алгоритм обработки отказов:

  • Первый отказ = Restart Service
  • Второй отказ = Restart Service
  • Третий отказ = Reboot Virtual Machine
  • Сброс счетчика отказов происходит через 1 час (3600 секунд)

Перед рестартом сервиса VPXD, а также перед перезагрузкой виртуальной машины, служба API Watchdog генерирует лог, который можно исследовать для решения проблем:

  • storage/core/*.tgz - на виртуальном модуле VCSA
  • C:\ProgramData\VMware\vCenterServer\data\core\*.tgz - не сервере vCenter

Конфигурация сервиса API Watchdog (который также называется IIAD - Interservice Interrogation and Activation Daemon) хранится в JSON-формате в файле "iiad.json", который можно найти по адресу /etc/vmware/ на VCSA или C:\ProgramData\VMware\vCenterServer\cfg\iiad.json на Windows-сервер vCenter:

mgmt01vc01.sddc.local:/ # cat /etc/vmware/iiad.json
{
"requestTimeout": 20,
"hysteresisCount": 4,
"remediatedHysteresisCount": 6,
"rebootShellCmd": null,
"restartShellCmd": null,
"maxTotalFailures": 50,
"needShellOnWin": true,
"watchdogDisabled": false,
"vpxd.watchdogDisabled": false,
"createSupportBundle": true,
"automaticServiceRestart": true,
"automaticSystemReboot": false,
"maxSingleRestarts": 3,
"maxSingleFailures": 2
}

Вот что это значит:

  • requestTimeout – дефолтный таймаут для запросов по умолчанию.
  • hysteresisCount – позволяет отказам постепенно "устаревать" - каждое такое значение счетчика при отказе, число отсчитываемых отказов будет уменьшено на один.
  • rebootShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском ВМ.
  • restartShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском сервиса.
  • maxTotalFailures – необходимое число отказов по всем службам, которое должно случиться, чтобы произошел перезапуск виртуальной машины.
  • needShellOnWin – определяет, нужно ли запускать сервис с параметром shell=True на Windows.
  • watchdogDisabled – позволяет отключить API Watchdog.
  • vpxd.watchdogDisabled – позволяет отключить API Watchdog для VPXD.
  • createSupportBundle – нужно ли создавать support-бандл перед перезапуском сервиса или рестартом ВМ.
  • automaticServiceRestart – нужно ли перезапускать сервис при обнаружении сбоя или просто записать это в лог.
  • automaticSystemReboot – нужно ли перезапускать ВМ при обнаружении сбоя или просто записать в лог эту рекомендацию.
  • maxSingleRestarts – верхний лимит попыток перезапуска упавшего сервиса.
  • maxSingleFailures – число отказов, требуемой для срабатывания действия по перезапуску сервиса.

Также сервис IIAD перед перезапуском сервисов или виртуальной машины генерирует лог по адресу:

  • /var/log/vmware/iiad/* - на виртуальном модуле VCSA
  • %VMWARE_LOG_DIR%/iiad/* - в ОС Windows

Вот такой небольшой deep dive в службы доступности сервисов vCenter:)


Таги: VMware, vCenter, HA, Troubleshooting, vSphere

Когда esxtop может тормозить работу сервера VMware ESXi.


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

Но оказывается, что использование esxtop само по себе может тормозить работу сервера VMware ESXi!

Это может произойти в ситуации, если у вас к ESXi смонтировано довольно много логических томов LUN, на обнаружение которых требуется более 5 секунд. Дело в том, что esxtop каждые 5 секунд повторно инициализирует объекты, с которых собирает метрики производительности. В случае с инициализацией LUN, которая занимает длительное время, запросы на инициализацию томов будут складываться в очередь. А как следствие (при большом числе томов) это будет приводить к возрастанию нагрузки на CPU и торможению - как вывода esxtop, так и к замедлению работы сервера в целом.

Выход здесь простой - надо использовать esxtop с параметром -l:

# esxtop -l

В этом случае данная утилита ограничит сбор метрик производительности только теми объектами, которые были обнаружены при первом сканировании. Соответственно, так лучше всего ее и использовать, если у вас к серверу VMware ESXi прицеплено много хранилищ.


Таги: VMware, esxtop, ESXi, Performance, Troubleshooting

Как найти хост ESXi с виртуальными машинами VMware vCenter и SQL Server, когда они выключены?


Если вы администратор VMware vSphere со стажем, то наверняка попадали в такую ситуацию: по какой-то причине отключается сервер VMware vCenter (он может работать, но не отвечать на подключения), а с ним вместе недоступна и его база (на том же хосте или на отдельном) - и вам нужно искать хост ESXi с этими ВМ, чтобы поднять всю виртуальную инфраструктуру. А хостов ESXi в кластере у вас может быть несколько десятков.

Можно, конечно, сделать правило DRS для vCenter, чтобы он не перемещался по хостам, но в случае срабатывания аварийного восстановления VMware HA, сервер vCenter вполне может поменять хост, так как HA забивает на правила DRS.

В этом случае может оказаться полезным интерфейс PowerCLI, который позволит найти нужную ВМ по ее имени. Но сначала вам нужно разрешить множественные соединения к нескольким хостам. Делается это следующей командой:

Set-PowerCLIConfiguration -DefaultVIServerMode Multiple -Scope Session

Теперь можно соединиться со всеми серверами одновременно и найти там vCenter. Делается это следующей командой:

connect-viserver @("esx1","esx2","esx3") -user root -password password

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

Далее просто ищем нужную виртуальную машину по ее имени:

(get-vm vCenter01).vmhost
(get-vm SQL01).vmhost

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


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

Как найти причину "розового экрана смерти" (PSOD) для сервера VMware ESXi.


Каждый администратор VMware vSphere рано или поздно сталкивается с тем, что хост VMware ESXi выпадает в "Pink Screen of Death" (PSOD - розовый экран смерти):

Причина этого - как правило, аппаратные проблемы сервера (барахлящее оборудование, битые блоки памяти, проблемы с драйверами, в том числе виртуальных устройств, и т.п.). В этом случае полезно погуглить ошибку, но сначала нужно получить дамп ядра (core dump), где сохраняются подробности о причине PSOD.

В VMware vSphere Web Client в представлении Hosts and Clusters нажимаем правой кнопкой на сервере vCenter, далее в контекстном меню выбираем пункт "Export System Logs...":

Далее выбираем интересующий нас хост VMware ESXi:

Затем отчекиваем все галки, кроме CrashDumps:

После экспорта файла открываете его в текстовом редакторе и ищете строчку "@bluescreen":

Ниже вы увидите подробности о произошедшей ошибке:

В данном случае мы видим, что имеет место проблема с драйвером виртуального сетевого адаптера (vNIC) E1000. Можно заменить его на VMXNET3 (как описано в KB 2059053), и проблема уйдет. Ну и прочие подобные ошибки можно гуглить, по PSOD ESXi уже есть много информации на форумах.


Таги: VMware, vSphere, ESXi, PSOD, Troubleshooting

Как обнаружить, какая виртуальная машина на VMware ESXi залочила VMDK-файл, и разлочить его.


Время от времени у пользователей VMware vSphere возникает ошибка, связанная с тем, что виртуальный диск VMDK виртуальной машины оказывается залоченным (то есть эксклюзивно используемым процессом VMX одного из хостов ESXi). В этом случае виртуальная машина не отвечает на попытки включить ее или переместить на другой хост-сервер средствами VMware vMotion. При этом процесс vmx вполне может быть запущен не на том хосте ESXi, на котором машина отображается в VMware vSphere Client или Web Client. Такое может случиться при падении хоста ESXi, массовом отключении питания или неполадках в сети SAN, а также и в некоторых других случаях.

Например, может быть вот такое сообщение об ошибке при включении машины:

Could not power on VM: Lock was not free

Для решения проблемы вам нужно найти хост ESXi, который исполняет vmx-процесс машины, и убить ВМ, которая не отвечает. После этого можно будет использовать VMDK-файл этой машины, а также включить ее, если она не работает.

Делается это следующим образом:

1. Находим хост, исполняющий vmx-процесс виртуальной машины с залоченным VMDK.

Для этого заходим по SSH на один из серверов ESXi (эта процедура работает для версий vSphere 5.5 P05 и 6.0, а также более поздних) и переходим в папку /bin:

#cd /bin

С помощью утилиты vmfsfilelockinfo ищем владельца лока нужного VMDK-файла:

~ # vmfsfilelockinfo -p /vmfs/volumes/iscsi-lefthand-2/VM1/vm1.vmdk -v 192.168.1.10 -u administrator@vsphere.local

Здесь vm1.vmdk - наш залоченный виртуальный диск, а 192.168.1.10 - IP-адрес сервера VMware vCenter. Вам потребуется ввести пароль его администратора.

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

vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['00:50:56:03:3e:f1']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : 00:50:56:03:3e:f1

Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive

Total time taken : 0.27 seconds.

Из вывода можно понять 2 важные вещи:

  • MAC-адрес хоста, залочившего VMDK
  • IP-адрес хоста, залочившего VMDK
  • Тип лока - Exclusive

Кстати, лок может быть нескольких типов:

  • mode 0 - нет лока
  • mode 1 - эксклюзивный лок (vmx-процесс машины существует и использует VMDK-диск)
  • mode 2 - лок только для чтения (например, для основного диска, в случае если у него есть снапшоты)
  • mode 3 - лок для одновременной записи с нескольких хостов (например, для кластеров MSCS или ВМ, защищенных технологией VMware Fault Tolerance).

Более подробно об этом написано в KB 2110152.

2. Точно определяем хост, машина которого держит VMDK.

Если IP-адрес показан - хост определен. Если, мало ли, по какой-то причине его нет, можно ориентироваться на MAC-адрес. Выяснить его можно следующей командой на хосте ESXi:

# vim-cmd hostsvc/net/info | grep "mac ="

3. Обнаруживаем процесс VMX, который держит VMDK.

Выполняем на найденном ESXi команду:

# lsof | egrep 'Cartel|vm1.vmdk'

Получаем что-то вроде этого:

Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/vm1.vmdk

Мы нашли Cartel ID нужного процесса VMX (36202). Теперь выполняем команду, чтобы найти ее World ID:

# esxcli vm process list

Получаем такой вывод:

Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx

Alternate_VM20
World ID: 36207
Process ID: 0
VMX Cartel ID: 36206
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a5 dc 94 5f
Display Name: Alternate_VM20
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM20/Alternate_VM20.vmx
...

Видим, что World ID нашей машины - 36205.

4. Убиваем VMX-процесс, залочивший VMDK.

Ну и убиваем зависший процесс VMX следующей командой:

# esxcli vm process kill --type force --world-id <ID>

После этого с машиной и ее диском можно делать уже что требуется.

Также для более ранних версий VMware vSphere посмотрите нашу статью вот здесь.


Таги: VMware, VMDK, Troubleshooting, vSphere, ESXi, Storage, VMachines

Вышел Citrix Receiver Diagnostics Tool v1.1 - новые возможности.


На днях компания Citrix обновила свою утилиту Receiver Diagnostics Tool до версии 1.1. Эта утилита позволяет администраторам решений Citrix XenDesktop и XenApp собрать с рабочих ПК пользователей необходимую диагностическую информацию, касающуюся работы клиента Citrix Receiver и окружения. В частности, это информация о конфигурации систем, а также различного рода логи, которые позволят вам узнать о причинах ошибки.

Возможности Citrix Receiver Diagnostics Tool v1.1:

  • Упрощенная активация и настройка работы механизма Citrix Diagnostic Facility (CDF)
  • Сбор информации в один клик о:
    • Системе на пользовательском ПК
    • Конфигурации Receiver
    • Логах Application и System Events
    • Результатах вывода Microsoft DxDiag Tool
    • Логах Always-On
    • Логах, созданных при инсталляции
  • Возможность упаковки и отправки диагностических данных в на сторону сервиса Citrix CIS (далее через MyCitrix можно получить поддержку)

Утилита очень полезна, когда у пользователя что-то не работает, а вы не можете понять что.

Как пользоваться утилитой:

  1. Скачать и запустить
  2. Нажать Start Receiver Tracing
  3. Затем надо воспроизвести проблемную ситуацию
  4. Далее жмем Stop Receiver Tracing и нажимаем Collect & Upload, если хотим отправить данные на сторону CIS, либо жмем Save, чтобы сохранить данные у себя.

Скачать Citrix Receiver Diagnostics Tool v1.1 можно по этой ссылке.


Таги: Citrix, XenDesktop, XenApp, Troubleshooting

Как уменьшить размер тонких дисков (Thin disks) или преобразовать в них обычные диски с удалением нулевых блоков и уменьшением VMDK.


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

Многие из вас знают следующий способ уменьшения тонкого диска (Thin disk): надо сначала почистить блоки утилитой sdelete, а потом сделать миграцию машины средствами Storage vMotion на другое хранилище. Тогда thin-диски и уменьшатся до реального размера данных в нем.

Но, во-первых, SVMotion есть не у всех (так как в начальные издания vSphere эта технология не входит), а, во-вторых, есть более простой способ. Итак:

1. Давайте сначала "раздуем" исходный тонкий диск с помощью утилиты sdelete.

Было (18,74 ГБ):

Запускаем в гостевой ОС Windows утилиту:

sdelete -c

Стало (41,8 ГБ):

2. Очищаем удаленные блоки в гостевой ОС, заполняя их нулями.

Для этого запустим команду:

sdelete -z

3. Уменьшаем размер виртуального диска с помощью утилиты vmkfstools.

Делается это с помощью ключа -K (можно также использовать ключ --punchzero) в консоли сервера ESXi:

vmkfstools -K Test.vmdk

Вот и все, смотрим на получившийся размер:

Надо отметить, что утилита vmkfstools, запущенная с ключом -K, еще и может преобразовать обычный диск (zeroedthick или eagerzeroedthick) в thin disk с вычищением нулевых блоков и, соответственно, уменьшением размера vmdk.


Таги: VMware, vSphere, VMDK, Storage, Troubleshooting

Как бороться со снапшотами в VMware vSphere - утилита Snapwatcher Enterprise Edition.


Мы уже упоминали компанию opvizor на нашем сайте - она тогда называлась еще Icomasoft. Она время от времени делает утилитки для виртуальной инфраструктуры. Оказалось у нее есть могущая оказаться полезной многим утилита Snapwatcher Enterprise Edition.

Как знают администраторы VMware vSphere, снапшоты виртуальных машин в большой виртуальной инфраструктуре - это просто беда. Они плодятся неаккуратными пользователями и администраторами, создаются пачками в тестовых системах и почему-то иногда не удаляются средствами резервного копирования. Для решения таких проблем и предлагается использовать Snapwatcher:

Что умеет Snapwatcher:

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

Как это работает:

Сам продукт Snapwatcher платный ($200 за лицензию на пользователя), но у него есть триальная версия. А так как в большинстве случаев проблема со снапшотами в виртуальной среде - разовая, то можно скачать Snapwatcher бесплатно и все пофиксить.


Таги: opvizor, Snapshots, vSphere, VMware, VMachines, ESXi, Troubleshooting

Где находятся логи VMware vSphere и других продуктов VMware [ССЫЛКИ].


Ниже приведем ссылки на статьи VMware Knowledge Base (взято отсюда), где можно узнать о расположении и назначении файлов журнала (логов) для различных продуктов, включая компоненты решения VMware vSphere.

vSphere Suite

vCenter Server:

ESX(i):

vSphere Data Recovery:

vSphere Storage Appliance:

Site Recovery Manager

vCloud Suite

vCloud Director:

vShield/vCloud Networking and Security (vCNS):

VMware vCloud Automation Center 6.x:

vCenter Orchestrator:

Desktop Computing

View and Horizon View:

Horizon Mirage (formerly Mirage):

VMware Workstation:


Таги: VMware, Logs, Troubleshooting, vSphere, ESXi, Director

Анонсирован VMware vRealize Log Insight 2.5 - новые возможности.


Вчера мы писали про анонсированный в рамках VMworld Europe 2014 пакет продуктов VMware vRealize Operation Management Suite 6.0, который содержит в себе множество решений семейства vRealize. Один из таких продуктов - VMware vRealize Log Insight 2.5 был также обновлен на VMworld и анонсирован к выпуску в конце 2014 года (у него очень бодрый темп обновлений). После проведенного ребрендинга продуктов, Log Insight - это часть большого семейства vRealize.

Напомним, что решение Log Insight предназначено для автоматизированного управления файлами журналов, а также сбора различных данных, их анализа и поиска. Кстати, о прошлой версии VMware Log Insight 2.0 мы писали вот тут.

Поработать с решением Log Insight можно и не устанавливая его, для этого можно выполнить одну из лабораторных работ:

Основные новые возможности VMware vRealize Log Insight 2.5:

  • Доступ на базе ролей (Role Based Access Control).

  • Интеграция инвентори продукта с решением vCenter Operations Management Suite (про это мы немного писали тут).
  • Внутренний балансировщик для масштабирования нагрузки.
  • Расшираение пакета Universal Collection Framework for Linux.
  • Интернационализация и локализация на основные языки (напомним, что русский к ним не относится).
  • Режим представления дэшборда, в котором все изменяется в режиме реального времени.

На специальном портале Content Pack Marketplace можно найти десятки модулей интеграции Log Insight со сторонним программным обеспечением:

Скачать новую версию VMware vRealize Log Insight 2.5 пока нельзя, но можно зарегистрироваться для оповещения о доступности по этой ссылке.


Таги: VMware, vRealize, Log Insight, Update, Logs, Troubleshooting

1 | 2 | 3    >   >>
Реклама

Advertisement

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

Быстрый переход:
VMware IT-Grad StarWind Microsoft VMFS RVTools Citrix PowerCLI Veeam 5nine VM Guru Oracle Red Hat Parallels Azure KVM vGate VeeamOn Security Code 1cloud Cloud Docker Storage Offtopic NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo Nutanix vRealize VirtualBox Symantec Gartner Softline EMC Login VSI Xen Enterprise Teradici Amazon NetApp VDI Linux Hyper-V IBM Cisco Google VSI HP Security Windows vCenter VMachines Webinar View VKernel Events Hardware Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell vSphere IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V SSO vSAN DRS Horizon LSFS Workspace Client Host Client VMDK App Volumes vROPs VTL vCloud Update iSCSI Labs IaaS SDDC vCSA NSX Virtual Appliance Backup VSA Whitepaper PowerShell Fusion Appliance VUM Manager VVols V2V Tools Workstation Cache VMworld SRM Support Обучение XenDesktop Web Client Mobile OpenStack Automation Replication Desktop Log Insight Fault Tolerance DR Photon Vanguard SaaS Connector HA Event Free Datacenter SQL VSAN Lifecycle Sponsorship Finance FT Cloud Computing Converter XenApp esxtop Snapshots VCP Auto Deploy SMB RDM Mirage XenClient MP Video Operations SC VMM Certification SSD VDP Partners PCoIP RHEV Performance Award Network AWS USB Licensing Logs Server Demo Visio Intel vCHS Calculator Бесплатно Nested vExpert Beta SAN Exchange MAP ONE DaaS Networking vNetwork Monitoring VPLEX UCS SDK Poster VSPP SDRS Receiver vMotion VDI-in-a-Box Deduplication Forum Reporter vShield ACE Go nworks iPad XCP Data Recovery Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint Plugin Troubleshooting DPM Director Book Memory Upgrade API SIOC Flex Mac Bug Open Source SSH Air VAAI Chargeback Heartbeat Android MSCS Ports SVMotion Storage DRS CLI Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

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

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

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

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

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

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

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

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

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

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

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

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

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

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

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

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

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

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Отличия VMware ESXi 4 free (бесплатного), ESXi 4 и ESX 4 в составе VMware vSphere.

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

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

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


Купить:

VMware vSphere 6


Veeam Backup 8


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


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


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