Vmware не удаляется datastore

Обновлено: 07.07.2024

ОС Windows 10. Изначально я просто хотел обновить данную программу. Вылезло само окно с обновлением, я согласился, но что-то пошло не так и в общем программа не обновилась. Для того, чтобы её обновить, нужно было удалить предыдущею версию. Так вот, захожу я в Пуск --> Панель Управления --> Программы и компоненты, а там её попросту нет. Решил удалить вторым способом, а именно удалить корневую папку, но там удалились не все файлы. Вот на фотографии показано какие остались файлы и что выдает, когда пытаюсь их удалить (к примеру взял три файла, в других файлах всё аналогично). Что делать?

"захожу я в Пуск --> Панель Управления --> Программы и компоненты, а там её попросту нет"

Ручками редактировать реестр. Но в ваших Виндях нет учётной записи Администратор. Вернее, она там есть, но ума найти её нет.

А что конкретно делать? Я в этом плохо разбираюсь. Нужно искать что-то типо "vmware', "vmware workstation" и удалить это, я правильно понял? выгрузить её из процессов и удалять, реестр чистить. либо есть способ - надо заново установить программу а потом снести. //Не могу удалить// -- сначала кнопа Win+R → пишите services.msc → жмите Ок далее 2-щелчок на эти сервиси (службы) Остановить → Отключить и Применить и Ок и перезагрузите компьютер
•VMware Workstation Server
•VMware Authorization Service
и заходим в Безопасный режим и далее Мне уже помог другой способ, удаление процессов VMware из Диспетчера задач, но всё равно спасибо что попытались помочь! и заходим в Безопасный режим и далее в Безопасном режиме запустите RevoUninstallerPro [← ссылка] → Принудительное удаление → тип выбирайте Папки (не файл) и укажите папку где библиотеки expat.dll и итд

savoljavob Искусственный Интеллект (168019) //уже помог другой способ// -- искренне рад, впредь удалите вот этим RevoUninstallerPro [← ссылка] или В ручную (и записи в реестре и в папках AppData) HKEY_CURRENT_USER\Software HKEY_LOCAL_MACHINE\SOFTWARE HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node

Файловая помойка в нашей организации крутится на виртуальной машине VMware ESXi 6 под Windows Server 2016. И это не просто помойка. Это сервер файлового обмена между структурными подразделениями: тут и совместная работа, и проектная документация, и папки с сетевых сканеров. В общем, тут вся производственная жизнь.

Я впал в изумление и решил сходить в отпуск. Пока я был в отпуске — у помойки не было ни одного зависания. А когда в понедельник вышел первый день на работу — помойка висела. Вытерпела полное резервное копирование и аккурат по его окончании повисла. Такая теплая встреча из отпуска подтолкнула меня к решению физически перетащить диски с гостевой машиной в другой хост.

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

По окончании мастера свежий Datastore появился в списке… а вместе с ним и Datastores с остальных физических дисков.

Чтобы развеять сомнения, по-быстрому установил на пробу свежий ESXi, взял левый диск и, уже вчитываясь, прошелся по шагам мастера. Да. При добавлении Datastore с помощью мастера происходит потеря всех данных на диске без возможности отката операции и восстановления данных. Позже я прочитал на одном из форумов оценку такого дизайна мастера: shitsome crap. И прямо вот очень согласился.

Начиная с шестой — мысли потекли в более конструктивном русле. Ладно. Инициализация занимает считанные секунды даже для 3Tb-диска. Значит, это высокоуровневое форматирование. Значит, просто была переписана таблица разделов. Значит, данные все еще там. Значит, сейчас поищем какой-нибудь unformat и voila.

Гружу машину с загрузочного образа Strelec… И выясняю, что программы восстановления разделов знают все, кроме VMFS. Разметку разделов Synology, например, знают, а вот VMFS — нет.

Перебор программ не утешителен: в лучшем случае GetDataBack и R.Saver находят NTFS-разделы с живой структурой каталогов и живыми именами файлов. Но меня это не устраивает. Мне нужны два vmdk-файла: с диском системы и диском файлов помойки.

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

Снова гуглинг, форумы, KB'шки и снова плач Ярославны: VMware ESXi не предусматривает механизма восстановления данных. Все ветки обсуждений имеют два финала: кто-то восстановился с помощью не дешевой DiskInternals VMFS Recovery или кому-то помог активно продвигающий свои услуги специалист по vmfs-tools и dd. Вариант с покупкой лицензии DiskInternals VMFS Recovery за $700 — не вариант. Допуск постороннего лица с «территории потенциального противника» к корпоративным данным — тоже не вариант. Зато было нагуглено, что VMFS разделы умеет читать так же еще UFS Explorer.

DiskInternals VMFS Recovery

Была скачана и установлена триальная версия. Программа успешно увидела пустой VMFS раздел:

В режиме Undelete (Fast Scan) так же нашла и потертый Datastore c папками виртуальных машин с дисками внутри:

Предпросмотр показал, что файлы живые:

Монтирование раздела в систему было успешным, но по непонятной причине во всех трех папках была одна и та же виртуалка. Конечно, по закону подлости — не та, что требуется.

Предпринятая попытка бессовестно запиратить софтину закончилась провалом. Зато запиратился UFS Explorer.

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

Я находился в катастрофическом положении и вовсе не гордился теми мерами, к которым прибег.

UFS Explorer

Сканирование диска показало наличие 7 нод. Количество нод «удивительным образом» совпало с количеством *-flat.vmdk файлов, обнаруженных VMFS Recovery:

Сравнение размеров файлов и размеров нод показало так же совпадение до байта. Заодно были восстановлены имена *-flat.vmdk файлов и, соответственно, принадлежность их к виртуальным машинам.

Спустя 4 часа выгрузки 2,5Тб нода из UFS Explorer'a и 20 часов загрузки в Datastore гипервизора грохнутые файлы дисков были подключены к свеже-созданной виртуальной машине. Диски подхватились. Потери данных замечено не было.

Постановка задачи

В моей инфраструктуре есть система управления виртуализацией VMware vSphere 7 и кластер построенный на базе ESXI 6.5. Недавно я создавал новую отказоустойчивую терминальную ферму HA RDS на базе Windows Server 2016, состоящую из 50 виртуальных машин. RDS ферма работает без проблем и нареканий, поэтому старые виртуальные сервера от фермы на базе Windows Server 2012 R2 я могу смело удалять, но я хочу их удалить разными методами, чтобы напомнить что-то себе и научить чему-то вас.

Удаление виртуальной машины через vSphare или ESXI интерфейс

Данный метод по удалению виртуальной машины со всеми файлами является самым простым. Его суть заключается в том, что вы будите использовать веб-интерфейс вашего гипервизора. В vCenter переходите в раздел "Hosts and Clusters" и среди списка серверов находите нужный в моем примере, это будет виртуальная машина term82. Щелкаем по нему правым кликом мыши и из контекстного меню выберите пункт "Delete from disk"

Давайте я вам опишу чем отличается пункт "Delete from disk" и "Remove from Inventory":

Delete from disk - Полностью удаляет всю виртуальную машину со всеми файлами с ваших датасторов, без возможности ее восстановления штатными средствами
Remove from Inventory - Удаляет виртуальную машину из видимости "Hosts and Clusters", но сами файлы виртуальной машины будут все еще лежать на вашем датасторе, это используют например при переносе виртуальных машин между серверами vCenter, где файлы сервера просто добавляются в Inventory.

Пункт "Remove from Inventory" вы можете использовать еще при глюке, когда виртуальная машина в списке доступных имеет статус Invalid (Unknown)

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

То же самое вы можете выполнить и на самом веб-интерфейсе отдельного ESXI хоста. Находите нужную виртуальную машину и так же через контекстное меню вы выбираете пункт "Delete", это более понятная формулировка, чем в vSphere.

Тут так же нужно подтвердить свое действие по удалению.

Как удалить виртуальную машину через PowerCLI

Чем плохи графические методы, это отсутствием автоматизации и невозможностью массового удаления виртуальных машин. Предположим, что вам нужно бахнуть 50 серверов, сколько времени вы потратите на это и графики, а если вообще нужно выполнить удаленно. Поэтому вы должны использовать оболочку PowerCLI. Он устанавливается в систему отдельно, как это сделать я рассказывал вот тут.

Подключаемся к нашему vCenter серверу или ESXI хосту. Для этого введите в оболочке команду:

Далее есть такой командлет Get-VM, который может вам показать наличие нужных виртуальных машин. Мои виртуальные машины все называются term70-80. Зная это я могу вывести полный список.

Далее для удаления виртуальной машины есть командлет Remove-VM со своими ключами:

VM - Задает виртуальные машины, которые вы хотите удалить.
Confirm - Если значение равно $true, это означает, что командлет запрашивает подтверждение перед запуском. Если значение равно $false, командлет запускается без запроса подтверждения пользователя.
DeletePermanently - Указывает, что вы хотите удалить виртуальные машины не только из инвентаря, но и из хранилища данных.
RunAsync - Указывает, что команда немедленно возвращается, не дожидаясь завершения задачи. В этом режиме выходом командлета является объект Task. Для получения дополнительных сведений о параметре RunAsync запустите «help About_RunAsync» в консоли VMware PowerCLI.
Server - Указывает сервер vCenter Server, на котором вы хотите запустить командлет. Если этому параметру не задано значение, команда выполняется на серверах по умолчанию.
WhatIf - Указывает, что командлет запускается только для отображения изменений, которые будут внесены, и на самом деле никакие объекты не изменяются.

Давайте теперь для примера удалим виртуальную машину term79, для этого введите:

У вас появится подтверждение на удаление, говорим "Y".

Файлы сервера все также продолжают лежать на датасторе.

Давайте теперь используем ключ -DeletePermanently, это позволит полностью с датасторов удалить виртуальный сервер.

Remove-VM -VM term79 -DeletePermanently

У вас выскочит подтверждение ваших действия, если нажмете "Y", то файлы VM будут полностью удалены.

Если не хотите видеть подтверждения, то воспользуемся ключом -Confirm:$false

Remove-VM -VM term79 -DeletePermanently -Confirm:$false

В веб интерфейсе вы увидите задание по удалению сервера.

Как массово удалить виртуальную машину через PowerCLI

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

Удостоверимся, что в нее попадают наши два виртуальных сервера и произведем удаление $VMs.

Как видим при удалении переменной $VMs, у нас идет запрос на удаление двух виртуальных серверов, term72 и term73.

То же самое можно сделать имя файл со списком серверов, который так же помещается в переменную. Вам нужно заранее подготовить обычный txt файл, где каждый сервер будет находится на новой строке. Далее есть такой командлет Get-Content. Пишем:

Проверяем, что в переменную $VMs попали сервера из файла.

Далее выполняем команду по удалению виртуалок.

После выполнения команды, если вывести запрос по поиску всех серверов с именем term*, то мы ничего не обнаруживаем.

Если в этот момент посмотреть vCenter, то тут вы увидите массовые задания по удалению.

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

$VMs = (Get-Content servers.txt)
$vmObj = Get-vm $vms

foreach($delete in $vmObj) Remove-VM -VM $delete -DeleteFromDisk -Confirm:$false -RunAsync | Out-Null>

Как выглядит предупреждение Datastore usage on disk

Варианты решения проблемы

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

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

Щелкните по ним и измените значения на свои.

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

Посмотреть все политики оповещения связанные с датастором, можно вот так:

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:

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.

Читайте также: