Vmware orphaned vm как восстановить
Файловая помойка в нашей организации крутится на виртуальной машине 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 гипервизора грохнутые файлы дисков были подключены к свеже-созданной виртуальной машине. Диски подхватились. Потери данных замечено не было.
Добрый день! Многие компании сейчас все чаще переносят свои ресурсы и сервисы к облачным провайдерам, таким как AWS, Azure или vCLoud Director. Сама миграция может происходить как создание в облаке нового сервера и ручной перенос сервисов, либо же миграция виртуальной машины, после P2V конвертирования. В момент переноса виртуальной машины в облако VMware vCLoud Director, я получал ошибку " The OVF package requires hardware version 13 but the selected VDC only supports hardware version 11". Из ошибки следовало, что моя версию виртуальной машины, более новая, чем поддерживает провайдер. Тут вариантов было несколько, увеличить версию поддержки, либо же понизить версию виртуального аппаратного обеспечения (Virtual Hardware Version / VM version). В данной заметке, я вам покажу, как можно быстро изменить версию VM version, на нужную вам.
Что такое уровень виртуального аппаратного обеспечения
Virtual Hardware Version или VM version - это версия виртуальной машины с поддержкой нового физического оборудования. Каждая версия виртуального оборудования имеет свою поддержку функционала, в самых свежих версиях исправляются различные баги и ошибки.
You cannot use the vSphere client to edit the settings of virtual machines of version 10 or higher. Use the vSphere Web Client to edit the settings of this virtual machine.
Как посмотреть версию виртуального оборудования, я вам уже показывал, можете ознакомиться. В моем примере есть тестовая виртуальная машина с Windows Server 2012 R2, как видите, у нее версия виртуальной машины (VM version) 13-я.
Методы понижения (downgrade) версии виртуального оборудования
Существует несколько методов, которые вам помогут уменьшить версию "VM version" у нужной вам виртуальной машины, среди них есть как официальные. так и не очень:
- Редактирование в файле название виртуалки.vmx параметра virtualHW.version, это самый быстрый способ, но он официально VMware не озвучивался.
- Создание новой виртуальной машины и подсовывание ей нужных виртуальных дисков от старой виртуалки.
- Конвертирование, через VMware vCenter Converter Standalone
Downgrade через редактирование virtualHW.version
Так как мне дорого мое время, то я использую для понижения версии виртуального оборудования на ESXI хостах, метод с редактированием параметра virtualHW.version в конфигурационном файле виртуальной машины. Вы скачиваете либо, через vSphere Web Client, либо через ssh конфигурационный файл формата *.vmx.
В веб-интерфейсе откройте вкладку "Datastores", и выберите там пункт "Browse Files", для просмотра содержимого на данном хранилище.
Найдите на вашем хранилище папку с вашей виртуальной машиной, откройте ее и найдите конфигурационный файл в формате .vmx и загрузите его, через кнопку "Download from Datastore". Как только внесете нужные настройки, через кнопку "Upload a file to the Datastore" с заменой.
Второй метод добраться до конфигурационного файла, это включить ssh доступ на ESXI хосте и подключиться, через WInSCP. Пройти по пути /vmfs/volumes/ваш датастор/имя вашей виртуальной машины. Скачиваете от туда файл .vmx.
Далее, когда вы получили конфиг-файл, вы редактируете его любым текстовым редактором. В файле находите параметр virtualHW.version = "13", в моем случае VM version имеет 13 версию, я поменяю ее на 11. Копируете фал обратно с заменой оригинального и проверяете результат, у вас при включении виртуальной машины должна понизиться версия виртуального оборудования.
В итоге когда я включил свой сервер, то лицезрел цифру 11.
Изменение версии оборудования, через VMware vCenter Converter Standalone
Этот метод, гораздо более время затратный, и потребует установки конвертера VMware vCenter Converter.
Открываете его и нажимаете кнопку "Convert machine".
Производите подключение к вашему vCenter серверу или Vmware ESXI хосту, убедитесь, что у вас стоит пункт "Power Off", означающий, что виртуальная машина отключена.
В пункте "Specify machine with" поставьте значение "VMs and Templates", в структуре датацентров, найдите вашу виртуальную машину.
Далее вам нужно подключиться к Vcenter серверу или ESXI хосту, куда будет конвертироваться виртуальная машина, у которой будет понижена версия VM version.
Задаете новое имя виртуальной машине и нажимаете "Next".
На следующем шаге выберите на каком ESXI хосте у вас будет располагаться ваша виртуалка и задайте ей нужную версию "Virtual machine version". После того, как задание будет выполнено, вы получите downgrade виртуального аппаратного обеспечения.
Пересоздание виртуальной машины
Далее вы создаете новую виртуальную машину, задаете ей другое имя отличное от старой. На шаге 2d Select compatibility вы выбираете версию виртуалки. Таблицу версий можно посмотреть вот тут.
На шаге 2f удалите все виртуальные диски и выберите пункт существующие диски "Exsisting Hard Disk".
Найдите ваши виртуальные диски на вашем датасторе и добавьте их.
Как видите данный метод, не менее трудоемкий, чем второй. Вы сами вправе выбирать любой из методов, подходящих именно вам. Если вы знаете другие, то напишите их в комментариях, буду вам признателен. Остались вопросы, так же готов их с вами обсудить, а пока вы пишите, я перевожу сервисы и ресурсы в VMware vCLoud Director.
From time to time, you may come across a virtual machine that is marked as orphaned in the vSphere inventory. What this means, in general, is that the VM exists as data in the vCenter server database but has either been deleted or is wrongly registered elsewhere. A number of factors can lead to this unwanted scenario. These include a failed host failover or a DRS migration gone wrong. It could also be the case of someone removing a VM from inventory when connected directly to ESXi instead of vCenter Server.
The Easy Fix
The first remedial action you should take is as follows.
This commands restarts all the host management services. Repeat this for every ESXi hosting orphaned VMs. The same can be carried out from DCUI by selecting Restart Management Agents from Troubleshooting Options as per Fig. 1.
Recovering Orphaned VMs (that still exist on disk)
The vSphere Way
An orphaned virtual machine will have the string (orphaned) appended to its name like so.
The following procedure will enable you to register an orphaned VM back to inventory.
Now, you might not be able to find the folder for the orphaned VM simply because the VM was renamed and the name change was not reflected in the folder name. I tackle how to solve this issue in my Fixing VM folder naming discrepancies post.
The ESXi command line way
Additionally, you can use the ESXi command line to achieve the same result as follows:
The vim-cmd throws an error if it finds that the VM is already registered. This was my case since the VM was correctly registered on ESXi but not on vCenter Server. Just to demonstrate command usage, I first removed the VM from inventory while connected to ESXi using the vSphere client.
After running the vim-cmd a second time, the VM registered and showed up properly in vCenter Server.
Removing Orphaned VMs from Inventory (those that do not exist on disk)
Going back to my primary issue, as mentioned, I came across an instance where I could not remove a number of orphaned VMS from the inventory after having reverted vCenter Server from a snapshot. I was 100% sure that the VMs no longer existed as files on any of the mounted datastores, meaning that I could just go ahead and delete them. The problem turned out to be one where the VM context menu offered no options to this effect.
This KB article suggests that one should create a VM folder and drag the offending VMs to it in vSphere Web client. Deleting the folder should supposedly delete the VMs as well. The problem with this, however, is that yet again all the VM menu options were either ghosted out or not available at all. Not really a good start! So, what to do?
On the command line, if you wish, you can also type this as a one-liner:
Figure 8 shows the result of the executed code.
A minor modification to the code will allow you to delete all the offending VMs in one go. To do this, we use the Remove-VM cmdlet. We just need to change the behavior of the If statement like so:
To suppress prompting, just add -Confirm:$false to the Remove-VM cmdlet.
Conclusion
If you have any questions or would like me to add anything, by all means leave me a comment below.
An Overview
The script I have in mind is loosely based on the following pseudo-code.
The information displayed under each column represent the following;
Figure 4 shows the generated output file. Though comma delimited, technically it is not a csv file but it can, regardless, be read with Excel or similar for filtering and what not.
Dissecting the script
The vars section
The datastore browsing section
The first 2 lines of the code snippet shown next are used to retrieve details about the datastore specified by $DSName via a View object. The 3rd line, while seemingly redundant, is required to ensure that the datastore name returned is correct since it is case-sensitive when used with the Copy-DatastoreItem cmdlet.
The next block of code instantiates an object of type HostDatastoreBrowserSearchSpec. We use the method or task SearchDatastoreSubFolders to perform a search on the datastore starting from its root. The complete list of folders and files contained therein is represented by $searchRes.
Dumping the contents of $searchRes to screen gives you something similar to Figure 6. You can see the path to every folder found on the datastore and its content (yet more objects) listed under the File column. Since this is basically an array of objects, we can list the files under each folder simply by invoking $searches[n].files as shown in the bottom part of Fig. 6 where n corresponds to the nth object in the array.
The loop block
This one, on the other hand, returns the path of the vmx file, if one exists.
An if-then statement verifies that a vmx file has indeed been found. If true, the vmx file is copied over to a local folder specified by $VMXFolder using the Copy-DataStoreItem cmdlet. This can be a painfully slow process especially if you have a significant number of VMs. Also, as the data channel is encrypted, extra baggage slows down the file-copy process. I have not found a better way to extract the displayname value from the vmx file which is why I copy vmx files over to a local folder.
Once the vmx file is transferred, it is read and parsed to extract the displayName value which is saved in $owningVM. This value corresponds to the VM name listed in vSphere client irrespective of the folder name on the datastore. Using these two pieces of information, we can map a folder name to a VM and determine if the VM is registered in the inventory or not. This is accomplished as follows;
Conclusion
So there you have it, one more compelling reason why you should learn PowerCLI. The script as it is, simply reports back on what it finds and does not take any remedial action. You can however easily adapt it to prompt users to add a VM back to the inventory and delete redundant folders.
Admittedly, there are probably shorter and smarter ways to achieve the same result however the whole idea, well most of it, is to come up with examples that emphasize the versatility and flexibility provided by both PowerShell or PowerCLI, something I hopefully achieved through this script.
Читайте также: