Remove from inventory vmware что это
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.
Another common cause is when vCenter server – or its database – is restored from a backup or a snapshot. In my case, this latter scenario is what prompted me to write this post. I recently had to revert a vCenter Server back to a snapshot after the VC database decided to call it a day. A few of the VMs deleted after the snapshot was first taken, found their way back in the inventory albeit marked as orphaned. Removing them, turned out to be an impossible task were it not for my trusty old friend PowerCLI
There are a number of ways to deal with orphaned VMs some of which I’ll be covering today where I’ll be targeting vSphere 6.5 and using the vSphere Web client throughout the post.
понедельник, 25 июня 2012 г.
Ошибка при обновление ESXi 5 сервера при помощи VMware Update Manager.
При обновлении одного из хостов получил следующую ошибку:
VMware vSphere Update Manager had an unknown error. Check the events and log files
Начал проверять, лог файл:
(Windows 2008 Server)
C:\ProgramData\VMware\VMware Update Manager\Logs\vmware-vum-server-8.txt
2012-06-25T23:17:01.336+04:00 [03588 warning 'Libs'] SSLVerifyIsEnabled: failed to read registry value. Falling back to default behavior: verification off. LastError = -2146885628
2012-06-25T23:17:01.336+04:00 [03588 warning 'Libs'] SSL_VerifyX509: Certificate verification is disabled, so connection will proceed despite the error
2012-06-25T23:17:01.336+04:00 [03588 warning 'Libs'] SSLVerifyIsEnabled: failed to read registry value. Falling back to default behavior: verification off. LastError = -2146885628
2012-06-25T23:17:01.336+04:00 [03588 warning 'Libs'] SSL_VerifyX509: Certificate verification is disabled, so connection will proceed despite the error
2012-06-25T23:17:01.336+04:00 [03588 warning 'Libs'] SSLVerifyIsEnabled: failed to read registry value. Falling back to default behavior: verification off. LastError = -2146885628
Похоже что какая-то проблема с проверкой SSL сертификатов, после этого решил отключить проверку, но получил ту же ошибку.
Далее решил с этого сервера виртуальных машин выполнить vMotion виртуальных машин вручную, и получил ошибку:
Currently connected network interface 'Network adapter 1' uses network "NAME", which is configured for different offload or security policies on the destination host than on the source host.
Настройка политик безопасности не привела к решению проблемы.
В общем, нужно заниматься выдачей SSL сертификатов при помощи openssl тулзы, а пока что отключил проверку сертификатов в Administration - vCenter Server Settings - SSL settings и выключил HA.
После этого обновление прошло успешно.
В результате нашел статьи в который говориться что у VMware есть проблемы с работой в таком режиме.
И обратно были выставлены default сертификаты.
Миграция виртуальных машин на новые серверы.
Итак все серверы готовы, обе фермы подключены к одному VMware vCenter, пытаемся переместить с одно сервера на другой при помощи vMotion и получаем следующую ошибку:
Host CPU is incompatible with the virtual machine's requirements at CPUID level 0x1 register 'eax'
Чтобы это обойти можно включить VMware EVC (Enhanced vMotion Compatibility)
Это позволит vMotion пройдет успешно.
После того как процесс перемещения закончен, нужно отключить EVC Mode.
Blue screen на виртуальной машине
При попытке обновить VMware tools виртуальная машина падает в синий экран.
Т.е. он жалуется на драйвер grbusb.sys
(0x00000050 (0xFFFFFFB8,0x000C0001,0xF5ED4228,0x00000000) ).
Данный файл расположен в C:\windows\system32\drivers и является драйвером Guardant (удалось определить путем просмотра - version - company в свойствах файла).
Guardant - электронный ключ для одного из приложений.
Проблема решилась просто - удалили драйвер - перегрузились - поставили VMware tools (все отлично поставилось) - обновили virtual hardware и далее накатили Guardant.
Ошибка при VMotion
При попытке сделать VMotion между хостами получил следующую ошибку:
Error Stack: Migration to host < >failed with error Connection closed by remote host, possibly due to timeout (195887167). vMotion migration [178462025:1340609815959379] failed to send init message to the remote host vMotion migration [178462025:1340609815959379] (0-71628780212520) failed to receive 68/68 bytes from the remote host : Connection closed by remote host, possibly due to timeout | |
Проверив, оказалось что IP_ADDR1 используется на двух VMkernel интерфейсах. FYI: В целом, после того как начал использовать Multinic vMotion, скорость миграции машин увеличилась примерно на 80-90 процентов. Тесты проводились на виртуальной машине с 24GB памяти |
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.
Figure 2 – Orphaned VMs as they appear listed in vSphere Web Client
If you’re pretty sure that an orphaned VM still exists on disk, then it’s just a matter of locating the parent datastore and folder and use its VMX file to properly add it back to inventory.
The following procedure will enable you to register an orphaned VM back to inventory.
Step 1 – Locate the VM folder on the respective datastore. If the VM has multiple hard drives spread across different datastores, chances are that the VMX file is to be found at the location set for Hard Disk 1 as shown in Fig. 3.
Figure 3 – Finding an orphaned VM’s primary folder on a datastore
Step 2 – Click on the datastore link. This launches the browser view which exposes the VM folder hierarchy for the specific datastore.
Figure 4 – Navigating the VM folder hierarchy in vSphere Web Client
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.
Note: It could also be the case that a VM exists as files on a datastore but is not registered anywhere. Although technically not an orphaned VM, it is important to keep this scenario in mind when troubleshooting. I’ve written a post on the subject that explores a PowerCLI script that should fix things for you.
Step 3 – Once you verify that the VM files exist and are the correct ones, right-click on the VMX file and select Register VM. However, before you do this, return to the VMs and Templates view in vSphere client, right-click on the orphaned VM and select Remove from inventory. The complete procedure is available here.
Figure 5 – Registering and removing a VM from inventory
The ESXi command line way
Additionally, you can use the ESXi command line to achieve the same result as follows:
Figure 6 shows an established SSH session on an ESXi host. You will find all the datastores under the /vmfs/volumes directory. In this example, I’m interesting in registering a VM called loginsight as per the commands captured in the screenshot.
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.
Figure 6 – Using vim-cmd solo/registervm on ESXi to register a virtual machine
The Easy Fix
The first remedial action you should take is as follows.
Step 1 – SSH to the ESXi host where the orphaned VM resides and run the following:
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.
Figure 1 – Restarting the ESXi management agents from the DCUI
Step 2 – Restart the vpxd service (vCenter Server service) on vCenter Server. The method used varies according to the vSphere release at hand and whether you have vCenter Server for Windows deployed or vCenter Server Appliance. Regardless, here are the relevant KB articles:
Как удалить orphaned в vCenter 6.5
Если сервер удален с дисков, но забыли удалить из инвентаризации, то снести ее можно таким методом. Открываем ваш vCenter сервер, нажимаем правым кликом по виртуальной машине и из контекстного меню выбираем пункт "All Virtual infrastructure Actions - More Uncategorized Actions - Remove from inventory". Вот аж куда ее запихали. Нажимаем кнопку и удаляем с концами из окружения ESXI, ваш orphaned сервер.
Что означает статус orphaned
Как я написал выше, статус orphaned (осиротевший), это статус виртуальной машины, которая в данный момент не может найти свои файлы. Очень часто такая ситуация происходит по роду причин:
- У вас стал недоступен ваш датастор на хосте, такое бывает если у вас подключение происходит по FC протоколу или ISCSI, на внешнее хранилище.
- Вы переместили файлы виртуальной машины в другое место или другую папку.
- У вас удалились или пропали файлы виртуальной машины, вы их удалили не из Inventory, а просто с датастора.
Если у вас проблема с датастором, то восстановите подключение к нему, если у вас были перемещены файлы виртуальной машины, то верните их на место. Если мы не хотим восстанавливать прежнее состояние базы, и задача быстро вернуть хосты со статусом orphaned в нормальное состояние делаем следующее:
Кликаем правой кнопкой мыши по машине со статусом orphaned и в меню выбираем – "Remove From Inventory". Машина из Inventory удаляется.
Файлы машины естественно продолжают лежать на дисках хранилища подключенного к хосту ESXi (перед удалением из Inventory не забываем посмотреть на какой машине лежит orphaned машина).
Далее идём в Inventory -> Hosts and Clusters, выбираем нужный нам хост ESXi и выбираем Summary. Смотрим, где у нас Datastore – там перечислены доступные хосту диски. Кликаем правой кнопкой мыши по диску, открываем контекстное меню и выбираем Browse Datastore.
Далее ищем папку с нашей виртуальной машиной, выбираем файл с расширением .vmx, кликаем по нему правой кнопкой мыши и выбираем – Add to Inventory, указываем родительские элементы (папка, хост и т.д.). Машина окажется в указанном нами месте. Unknown машины просто удаляем из Inventory.
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.
Figure 7 – An unmanageable orphaned VM
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.
Figure 8 – A list of orphaned VMs in vSphere
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.
Figure 9 – Removing orphaned VMs with the Remove-VM cmdlet in PowerCLI
Удаление виртуальной машины через vSphare или ESXI интерфейс
Данный метод по удалению виртуальной машины со всеми файлами является самым простым. Его суть заключается в том, что вы будите использовать веб-интерфейс вашего гипервизора. В vCenter переходите в раздел "Hosts and Clusters" и среди списка серверов находите нужный в моем примере, это будет виртуальная машина term82. Щелкаем по нему правым кликом мыши и из контекстного меню выберите пункт "Delete from disk"
- Delete from disk - Полностью удаляет всю виртуальную машину со всеми файлами с ваших датасторов, без возможности ее восстановления штатными средствами
- Remove from Inventory - Удаляет виртуальную машину из видимости "Hosts and Clusters", но сами файлы виртуальной машины будут все еще лежать на вашем датасторе, это используют например при переносе виртуальных машин между серверами vCenter, где файлы сервера просто добавляются в Inventory.
Пункт "Remove from Inventory" вы можете использовать еще при глюке, когда виртуальная машина в списке доступных имеет статус Invalid (Unknown)
Вас еще раз предупредят, что файлы виртуального сервера будут уничтожены, вам нужно подтвердить действие.
То же самое вы можете выполнить и на самом веб-интерфейсе отдельного ESXI хоста. Находите нужную виртуальную машину и так же через контекстное меню вы выбираете пункт "Delete", это более понятная формулировка, чем в vSphere.
Тут так же нужно подтвердить свое действие по удалению.
Conclusion
This pretty much sums up all I wanted to say about orphaned VMs. On rare occasions, orphaned VMs will find their way into your environment due to a number of reasons. The more complex your environment, the harder it will be to locate the exact cause but in general orphaned VMs are an easy fix as we’ve seen.
If you have any questions or would like me to add anything, by all means leave me a comment below.
Постановка задачи
В моей инфраструктуре есть система управления виртуализацией VMware vSphere 7 и кластер построенный на базе ESXI 6.5. Недавно я создавал новую отказоустойчивую терминальную ферму HA RDS на базе Windows Server 2016, состоящую из 50 виртуальных машин. RDS ферма работает без проблем и нареканий, поэтому старые виртуальные сервера от фермы на базе Windows Server 2012 R2 я могу смело удалять, но я хочу их удалить разными методами, чтобы напомнить что-то себе и научить чему-то вас.
Как массово удалить виртуальную машину через 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>
- Remove from Inventory – this option unregisters the VM from the host and the vCenter Server inventory, but the VM’s files remain on the datastore. You can later re-register the VM to the inventory.
- Delete from Disk – this option removes the VM from the inventory and delete its files from the datastore.
Here is how you can remove a VM from the inventory using vSphere Web Client:
1. To only remove a VM from the inventory, right-click the VM and select All vCenter Actions > Remove from Inventory:
2. Click Yes to confirm the removal:
3. The VM will no longer be present in the inventory:
You can re-register the VM back to the inventory:
1. Browse to the location of the VM’s .vmx file on the datastore. Right-click the file and select the Register VM option.
2. The Register Virtual Machine wizard opens. Select the inventory location:
3. Select the ESXi host on which the VM should run:
4. Review the settings and click Finish:
5. The VM should be back in the inventory:
1. Right-click the VM and select All vCenter Actions > Delete from Disk:
2. Click Yes to confirm the deletion:
3. The VM will no longer be present in the inventory or on the datastore. Note that this action is irreversible.
Перемещение шаблона виртуальной машины на другой сервер виртуальных машин (кластер)
Если попробовать переместить шаблон виртуальной машины при помощи vMotion, то появляется ошибка:
This operation is not supported on the object
Чтобы переместить шаблон есть три варианта:
Remove from Inventory (Самый быстрый способ)
Clone (Не сильно сложнее но дольше)
1. Щелкнуть правой кнопкой мыши по виртуальной машине, и сделать Clone
2. На забыть удалить оригинальную версию шаблона, чтобы не засорять место.
VMware vSphere PowerCLI
Есть команда Move-template, которая позволяет переместить шаблон
четверг, 21 июня 2012 г.
Настройка после установки VMware ESXi 5
- Нажимаем F2 и вводим Login/Password, указанные при установке ESXi
- Далее выбираем Configure Managment Network и нажимаем Enter
- Далее выбираем Network Adapter s и нажимаем Enter
Далее из списка выбираем нужные vmnic и подтверждаем выбор нажатием на пробел. После окончания выбора жмем enter.
- Далее выбираем IP configuration и прописываем настройки TCP/IP, после настройки жмем Enter
- Если необходимо, прописываем необходимый VLAN
- Выбираем DNS configuration - прописываем настройки DNS
- Выбираем Custom DNS Suffixes и прописываем нужные DNS суфиксы
- После этого Escape и Y для перезапуска Management interface
3. Произведение сетевых настроек
После подключения к виртуальной инфраструктуре необходимо произвести конфигурацию сетевых интерфейсов.
(П.с. сетевики должны заранее объединить интерфейсы к Link Aggrigation группы (802.3ad) (это позволит получить дополнительную производительность).
Соответственно они должны сделать Link aggrigation группы для виртуальных машин, для
vmkernel. (Для service console в этом нет смысла)
Итак, мы видим следующую картину:
В данном сервере 4 сетевых интерфейса, поэтому по-просьба сетевики сделали 2 линк аггригейшн группы:
vmnic1, vmnic2 - первая группа
vmnic0, vmnic3 - вторая группа
Конечная картина - два виртуальных свитча:
1. Свитч для двух VMkernel портов и для Managment Network - vmnic1, vmnic2
2. Свитч для Virtual Machine Port Group - vmnic0, vmnic3
Поскольку в новой версии VMware vSphere 5 есть поддержка выполнения vMotion через несколько сетевых интерфейсов одновременно, устанавливать Route based on IP hase на первом виртульном свитче нет смысла.
Поэтому в настройках свитча ставим:
- Отключаем на свитче во вкладке Security - Promiscuous Mode, MAC Address Changes, Forged Transmits (Рекомендовано в VMware Security hardering 5)
- Для Managment Network устанавливаем один из интерфейсов Avtive, другой Standby
- В настройках NIC teaming устанавливаем Use explicit failover order
- Далее создаем VMkernel Port Group 1 устанавливаем в ней Active первый интерфейс, а второй в Standby
- В настройках NIC teaming устанавливаем Use explicit failover order
- И VMkernel Port Group 2, в ней устанавливаем наоборот Active второй интерфейс, а первый в Standby
- В настройках NIC teaming устанавливаем Use explicit failover order
- Не изменять VMkernel Default gateway в настройках VMkernel Port Group - это приведет к изменению шлюза для Managent Network
- Включить в настройках VMkernel Port Group опцию Failback - иначе в случае восстановления после падения одного из аплинков, инфраструктура будет использовать только один сетевой интерфейс
Настройка свитча для вирутальных машин
- Далее создаем ещё один свитч для виртуальных машин и подключаем к нему vmnic0 и vmnic3
- В настройках vSwith порт группы, во-вкладке Security отключаем Promiscuous Mode, MAC Address Changes, Forged Transmits
- Во-вкладке NIC Teaming ставим следующие настройки:
- Ставим голочку NTP Celint Enabled
- General - Start and stop with host
- NTP setting - прописываем IP контроллеров домена
4. Ограничить доступ к виртуальной инфраструктуре путем удаления Domain Admins из списка администраторов VMware
Для этого необходимо чтобы на VMware VirualCenter сервис запускался из-под доменной учетной записи.
Нужно сделать учетную запись и в свойствах сервиса настроить Log On из-под созданной учетной записи. Плюс не забыть добавить её в локальные администраторы на vCenter сервере.
Если эту настройку не сделать, то появиться ошибка:
Call "UserDirectory.RetrieveUserGroups" for object "UserDirectory" on vCenter Server "VMware" failed.
среда, 20 июня 2012 г.
Оптимизация CPU в BIOS Dell перед установкой VMware vSphere 5
64bit - Yes
Logical Processor - (Включен/выключен Hyper-Traiding) вендор рекомендует использовать данную опцию включенной. Enabled
Virtualization Technology - Enabled (Давно всем известная вещь - аппаратная поддержка таблиц соответствий памяти)
Adjacent Cache Line Prefetch - Enabled (Механизм уже описан и в других местах, но вкратце, означает: Если был запрос на считывание 64Кб из памяти, процессор автоматически считает следующие 64Кб, что даст прирост производительности.
Данная опция теоретически может дать небольшое падение производительности если приложение использует очень маленький объем памяти или почему-то пишет в память не подряд, но для хостовой машины VMware vSphere это не актуально, поэтому всегда Enable )
Intel(R) QPI Bandwidth Priority - Compute. QPI позволяет получить производительность между PCI Express 2 и процессором скорость до 26GB full duplex в секунду.
Специальных требований касательно данной опции нет.
Execute Disable - Enable
Продолжение Windows DEP (Data Execution Prevention) не дает запускаться программам в области данных.
Number of Cores per processor - All (Тут точно комментарии излишни)
Turbo Mode - Enable (Данная опция позволяет автоматически разгонять ядро(а), если другие простаивают. При разгоне учитывается текущая нагрузка и проверяется что температура не превышает критические значения)
C1E - Disable
C-States - Disable
(Vmware рекомендует установить значение Enabled и управлять опцией из ESXi)
Данные опции управляют режимом экономии питания. Но для того чтобы получить наибольшую производительность данную опцию стоит отключить.
Как удалить виртуальную машину через 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, это позволит полностью с датасторов удалить виртуальный сервер.
У вас выскочит подтверждение ваших действия, если нажмете "Y", то файлы VM будут полностью удалены.
Если не хотите видеть подтверждения, то воспользуемся ключом -Confirm:$false
В веб интерфейсе вы увидите задание по удалению сервера.
Читайте также: