Reset to green vmware что это
Reset to green vmware что это
Добрый день! Уважаемые читатели и гости популярного блога, о Vmware ESXI и настройке серверов pyatilistnik.org. Относительно недавно, я вам рассказывал, как создавать свои оповещения в vCenter 5.5 (тригеры). Там я показывал, как редактируются встроенные тригеры. Сегодня на одном из моих датасторов, выскочило предупреждение: Datastore usage on disk, сам LUN имеет размеры 4 ТБ и на нем было свободно более 800 гигабайт. Данное оповещение сообщает, что у меня начинает заканчиваться свободное место на дисковом массиве, но в виду того, что свободно 800 гигабайт, это оповещение мне кажется лишним. Я вам покажу, как его поправить в vCenter 6.5 сервере.
Как выглядит предупреждение Datastore usage on disk
Вот так вот на вкладке «Summary» выглядит предупреждение.
Если вы более подробно посмотрите сообщение, то вы увидите, что это стандартное оповещение (alarm) используемое в мониторинге гипервизоров.
Варианты решения проблемы
Данное уведомление очень полезное, так как системный администратор будет в курсе, что у него заканчивается место, хотя уверен, что он об этом узнает из другой системы мониторинга, например, Zabbix. Но если у вас ситуация как у меня, когда на датасторе полно место и вы не хотите, чтобы предупреждение мозолило вам глаза, то у вас два варианта, точнее три:
Для того, чтобы изменить параметры, нужного вам задания по мониторингу, выберите в корне ваш vCenter 6.5 сервер, раздел «Monitor«, вкладка Issues, в которой выберите пункт «Alarm Definitions«. В поисковой строке введите «Datastore usage on disk». В итоге у вас будет выполнен фильтр по данному имени.
Щелкните по нему правой кнопкой мыши и из контекстного меню выберите пункт «Edit», для его редактирования.
Откройте пункт «Triggers», в нем вы увидите значения при которых он будет срабатывать. По умолчанию, это 75% занятого места, это предупреждение и 85% это критический alarm.
Щелкните по ним и измените значения на свои.
Я выставил 85% для предупреждения и 95% для критического сигнала. Сохраняем изменения, и ручками очищаем текущие уведомления, через функцию «reset to Green».
Запросим текущее состояние политики с помощью команды:
Как видите она включена и имеет значение «True». Давайте ее отключим, для этого есть две команды, которые я подсмотрел на (https://kb.vmware.com/s/article/2076157):
Посмотреть все политики оповещения связанные с датастором, можно вот так:
Из графического интерфейса можно выключить тригер, сняв галку «Enable this alarm»
Старайтесь не доводить ваши датасторы, до уведомления «Datastore usage on disk»
Reset to green vmware что это
I created alarm for a host, and it rings as expected.
However, even after acknowledging the alarm, the red warning pointer on the host is still appearing. I have to manually click «Reset alarm to green» to make it go away.
Please also see the snapshot for more clarity
The acknowledge alarm action will make sure that the alarm doesn’t fire again until the status went to back to a green or gray state.
This is available to avoid that the same actions are fired over and over again.
To reset the status you will have to use the ReconfigureAlarm method.
The following script shows how to do this for a rather simple event alarm (I used the «VM being cloned event» for testing).
This seems to do the trick but I suspect it will require further testing.
Some features to be added:
*) it won’t handle situations where there is more than event on an entity
*) it doesn’t allow to specify which alarm should be reset
*) it doesn’t handle the same alarm being triggered for multiple entities
I feel a blog entry coming up 
VMWare ESXi: Перезапуск зависшей виртуальной машины
Иногда сталкиваюсь с тем, что определенная виртуальная машина на хосте VMWare ESXi зависает и ее нельзя никаким средствами выключить или перезагрузить из веб-интерфейса клиента vSphere. Перезагружать целиком ESXi сервер из-за одной виртуальной машины – не совсем целесообразно (особенно, если у вас всего один ESXi хост, или оставшиеся сервера в DRS кластере не потянут дополнительной нагрузки в виде виртуальных машин с перезагружаемого сервера). Рассмотрим основные способы принудительной остановки зависшей виртуальной машины в VMWare ESXi.
Если процесс виртуальной машины на сервере ESXi завис, она перестает реагировать на команды Reset / Power Off, и на любое действие выдает одну из ошибок:
В таких случаях вы можете вручную остановить процесс виртуальной машины на хосте ESXi из командной строки ESXi Shell или PowerCLI.
Теперь вы можете подключиться к этому ESXi хосту через SSH с помощью клиента putty.
Выведем список ВМ, запушенных на хосте ESXi:
esxcli vm process list
Скопируйте идентификатор нужной виртуальной машины (World ID).
Чтобы завершить процесс зависшей виртуальной машинына хосте ESXi используется следующая команда:
Как вы видите, есть три типа завершения процесса ВМ:
Попробуем мягко остановить ВМ с указанным ID:
ВМ должна выключиться.
Вы можете остановить зависшую виртуальную машину с помощью PowerCLI (это удобно, т.к. при подключении к vCenter вам не нужно искать хост, на котором запушена ВМ и включать SSH доступ). Проверим, что ВМ запушена:
get-vm “web2″ | select name,PowerStates
Принудительно остановите процесс ВМ командой:
Также вы можете остановить зависшую виртуальную машину с помощью утилиты ESXTOP.
В SSH сесиии введите команду esxtop, затем нажмите “c” для отображения ресурсов CPU и shift + V, чтобы отображать только процессы вириальных машин
Затем нажмите “f” (выбрать отображаемы поля), “c” (отобразить поле LWID- Leader World Id) и нажмите Enter.
В столбце Name найдите виртуальную машину, которую нужно остановить, и определите номер ее LWID по соответствующему столбцу.
Затем осталось нажать кнопку «k» (kill) и набрать LWID идентфикатор той виртуальной машины, которую нужно принудительно выключить.
Последний способ жёсткого выключения виртуальной машины – воспользоваться утилитой kill. Такой способ позволит остановить не только ВМ, но и все дочерние процессы.
Получим ID родительского процесса ВМ:
После такого “hard reset”, установленная ОС запустится в режиме восстановления. В случае гостевой Windows, скрин будет выглядеть так.
Опыт построения Infrastructure-as-Code в VMware. Часть 1: Обозначение проблемы
Приветствую, дорогой читатель. Я начинаю цикл статей о том, как мы искали решение для применения подхода Infrastructure-as-Code в нашем виртуальном окружении VMware VSphere.
У нас есть система управления конфигурациями Puppet для Linux, есть (на данный момент) DSC для Windows Server.
Что касается Linux — практически все автоматизированно. Мы заносим конфигурации машин в nodes.yaml, мы заносим роли в Hiera, строим модули (или берем готовые), у нас есть PXE, IP адреса раздаются из DHCP по MAC адресу.
То есть с момента как Linux виртуалка стартует, до момента, когда виртуалка готова к эксплуатации — никаких действий не нужно. Попробуйте угадать, что в этой цепочке делается вручную? Верно, создание самой виртуальной машины в VSphere.
Когда я впервые поднял этот вопрос, мне сказали, что искали решение, пробовали варианты, но ничего не получилось. “К черту!” — подумал я и поспорил на ящик пива, что найду решение, которое будет работать по следующему сценарию: разработчик или инженер делает Pull Request, в котором у нас находится конфигурация виртуальной машины (ядра, память, сеть, шаблон и т.д.) — далее некая магия обращается в VSphere и создает машину, согласно настройкам в файле.
Позволь рассказать немного о нашем окружении, чтобы ты понял с чем мне приходится иметь дело.
У нас в качестве On-Premise виртуализации используется VMware VSphere — парочка датацентров, datastore-кластер и несколько Resource Pool’ов (RP) под каждую команду. Члены команды имеют права на создание виртуальных машин в пределах RP, ребята-инфраструктурщики им в этом не мешают и просто занимаются обслуживанием всей платформы, периодически напоминая разработчикам и инженерам убирать за собой неиспользуемые машины (ресурсы-то не резиновые).
У нас есть Windows виртуалки, Linux виртуалки, масштаб задач огромен — веб серверы, реверс прокси, балансировщики, контроллеры домена, серверы приложений и баз данных и нет им конца и края.
Теперь я поведаю тебе, какие инструменты я пытался применять, и почему они мне не подошли.
Эмпирическим путем…
Ansible vsphere_guest
Как я уже писал в предыдущей статье, я очень люблю Ansible и в вопросах автоматизации я первым делом смотрю, можно ли его для этого использовать.
Согласно документации, есть хороший модуль vsphere_guest который может создавать и удалять виртуалки. То, что нужно. Вот так выглядит мой плейбук createvm.yaml
Я сознательно комментирую hostname esxi потому, что я создаю виртуалку непосредственно в RP, а не на хосте. DRS сам решит, куда виртуалку положить.
Если я запускаю плейбук, он ругается что необходимый параметр hostname не указан. Если я его раскоментирую, то он поругается на отсутствие прав на создание виртуалки на esx хосте (что очевидно, т.к. права у меня есть только на RP). Я создал соответствующий issue, так что надеюсь, ребята из Ansible это исправят, поскольку инструмент реально хороший.
Terraform
Иная тулза, которая умеет создавать виртуалки в VMware это Terraform, продукт от HashiCorp. Изначально он заточен под взаимодействие с Packer и деплоит в AWS, но наши задачи он тоже решает. Вот собственно файл с конфигурацией:
terraform plan работает прекрасно.
Что так же здорово, можно задать IP адрес, доменное имя — то есть задать полноценную кастомизацию машинки из шаблона. Пробуем запустить…
Хм, не найден datastore. Как я уже говорил, у нас кластер, так что я попробую сделать по-грязному указав одну из нод кластера.
Что ж… снова неудача. Позже выяснилось, что Terraform не умеет работать с datastore-кластерами. Соответственный issue был создан на GitHub моим коллегой, но успехов на этот поприще тоже, увы, нет.
PowerCLI
Претерпев неудачу в поисках рабочих инструментов от третьих лиц, я решил обратиться к вендорскому решению.
Вендор предлагает два решения — PowerCLI (надстройка над Powershell) и vmware-cli (командный интерфейс для *nix).
Заставить работать vmware-cli на CentOS 7 и OS X не удалось (один страдалец даже написал блог об этом), посему я решил сразу начать пользоваться инструментом, который работает.
Внимательный читатель может поинтересоваться, почему я потратил столько времени на Ansible и Terraform, в то время как PowerCLI уже давно используется. Причины просты — я не знаю Powershell на должном уровне, чтобы с наскоку начать пользоваться им, плюс это вынуждает меня использовать windows машину, которая будет заниматься чистым provision’ом. Впрочем, иных вариантов у меня и нет.
Беглое изучение документации дало мне достаточно навыков, чтобы написать простенький скрипт.
Этот скрипт рабочий и делает все необходимое. Запуск скрипта выглядит следующим образом:
Скрипт попросит меня предоставить логин и пароль, переиграет переменные и создаст машинку с помощью cmdlet’а new-vm. Читатель может поинтересоваться, почему присутствует вот эта строка:
Пусть меня поправят опытные powershell ребята, если я ошибаюсь. Get-Credential создает объект состоящий из логина, пароля и домена (если он есть). Пароль находится в состоянии SecureString. К сожалению, PowerCLI не умеет работать ни с объектом Get-Credential, ни с SecureString, потому приходится идти на подобные ухищрения, чтобы передать ему логин и пароль простой строковой переменной.
Выводы
Дорогой читатель, если у тебя однажды встанет задача автоматизировать создание виртуальных машин в VMware, то учти следующее:
Если же у тебя такая же сложная инфраструктура, как и у нас, то лучше не изобретай велосипед, а осваивай PowerCLI.
В следующей части я расскажу, как мы сделали наш скрипт умнее, и научили его делать проверки на кастомизацию, количество ядер и других ресурсов и naming convention.
datastore usage on disk vmware что это
Ошибка Datastore usage on disk в vCenter 6.5
Ошибка Datastore usage on disk в vCenter 6.5
Добрый день! Уважаемые читатели и гости популярного блога, о Vmware ESXI и настройке серверов pyatilistnik.org. Относительно недавно, я вам рассказывал, как создавать свои оповещения в vCenter 5.5 (тригеры). Там я показывал, как редактируются встроенные тригеры. Сегодня на одном из моих датасторов, выскочило предупреждение: Datastore usage on disk, сам LUN имеет размеры 4 ТБ и на нем было свободно более 800 гигабайт. Данное оповещение сообщает, что у меня начинает заканчиваться свободное место на дисковом массиве, но в виду того, что свободно 800 гигабайт, это оповещение мне кажется лишним. Я вам покажу, как его поправить в vCenter 6.5 сервере.
Как выглядит предупреждение Datastore usage on disk
Вот так вот на вкладке «Summary» выглядит предупреждение.
Если вы более подробно посмотрите сообщение, то вы увидите, что это стандартное оповещение (alarm) используемое в мониторинге гипервизоров.
Варианты решения проблемы
Данное уведомление очень полезное, так как системный администратор будет в курсе, что у него заканчивается место, хотя уверен, что он об этом узнает из другой системы мониторинга, например, Zabbix. Но если у вас ситуация как у меня, когда на датасторе полно место и вы не хотите, чтобы предупреждение мозолило вам глаза, то у вас два варианта, точнее три:
Для того, чтобы изменить параметры, нужного вам задания по мониторингу, выберите в корне ваш vCenter 6.5 сервер, раздел «Monitor«, вкладка Issues, в которой выберите пункт «Alarm Definitions«. В поисковой строке введите «Datastore usage on disk». В итоге у вас будет выполнен фильтр по данному имени.
Щелкните по нему правой кнопкой мыши и из контекстного меню выберите пункт «Edit», для его редактирования.
Откройте пункт «Triggers», в нем вы увидите значения при которых он будет срабатывать. По умолчанию, это 75% занятого места, это предупреждение и 85% это критический alarm.
Щелкните по ним и измените значения на свои.
Я выставил 85% для предупреждения и 95% для критического сигнала. Сохраняем изменения, и ручками очищаем текущие уведомления, через функцию «reset to Green».
Запросим текущее состояние политики с помощью команды:
Как видите она включена и имеет значение «True». Давайте ее отключим, для этого есть две команды, которые я подсмотрел на (https://kb.vmware.com/s/article/2076157):
Посмотреть все политики оповещения связанные с датастором, можно вот так:
Из графического интерфейса можно выключить тригер, сняв галку «Enable this alarm»
Старайтесь не доводить ваши датасторы, до уведомления «Datastore usage on disk»
Hi Guys,
I have a VMware cluster (3 ESXi Servers) and a vSAN configured using all the storage among these servers.
When I go to the vSAN Datastore summary usging the vSphere client it shows 8TB of free space.
But 2 events are happening that got me worried:
Event 1.
When I tried to extend a virtual hard disk in a VM the following error message happened: «The disk extend operation failed: msg.disklib.NOSPACE»
Event 2.
In the vSAN Datastore Alarms tab I have the message: «warning: Datastore usage on disk»
Why are these events popping up if according to the system I still have 8TB of free space?
How can I fix this issue?, preferable keeping all the space I have reserved for Virtual Disks on my VMs.
Background
I was doing an upgrade from 4.0 to 4.1 this week on a two node cluster. This cluster is owned by an SMB and its a fully contained VMware setup, basically it has two DL380 G6 servers each with 8 – 146GB 10k SAS drives, dual Nehalem processors, and 24GB of ram. We have HP’s P4000 VSA software installed on each node to form a redundant two node SAN, so each server has all 8 drives in a RAID5 and a single VMware VMFS volume on them. Inside of that volume we have a single virtual machine (the VSA) and it consumes about 90% of the space in that datastore. Inside of the VSA is where all of the production VM’s live, but the problem is that the local datastores are in an alarm state because they are above the threshold set at the vcenter level. I suppose I could just change that threshold to like 98% or something and the alarms would go away, but that wouldn’t let us much time to react if the VSA volume ever got full. So the better solution would be to somehow ignore alarms on local datastores but still keep the alarms for shared datastores. Below is what the problem looks like… Local datastores are in an alarm state… but the “real” data which is in “VM Storage Repository” is not full yet.
Solution
After doing a little research I was able to come by one other blog post that used this same method on ESX to fix the errors on the service console volume, but I could not find anything related to local and VSA shared volumes. The process is the same for both though, so I figured I would share.
The first step is to log into vcenter (or esxi, whichever your using) and goto the Datastore Inventory tab. Next create two folders, one for local datastores and another for shared. Then drag your local datastores to the local folder and your shared datastores to the shared folder.
Note that the pictures shows how it will look after we delete some alarms and recreate them.
After putting your datastores in the proper folders click on the vcenter, or esxi object (whichever is the top level) and go to the alarms tab (you will need to click on the Definitions button as well. Find the ‘Datastore usage on disk’ alarm and go into it and take some screen shots of how it is setup, we will use these later to recreate the alrm, then delete it. (Or at least disable it) Then go down to the shared datastore folder that you created, and then into the alarms tab again (then click Definitions). In here we will want to recreate a ‘Datastore Usage on Disk’ alarm so that we still get alarms for our shared storage. Right click and Add new. and then refer to the screenshots you took in order to create it properly. Just for reference here is what it looks like inside of the alarm definition:
Now you should have something that looks like the last screen shot… you will have a ‘Datastore Usage on Disk’ alarm that has been created in “This object” and your local datastores are no longer monitored. If you wanted to you could create a disk usage alarm for the local folder and set its thresholds much higher just to be safe.