Suspend vmware что это

Обновлено: 25.01.2025

A fault has occurred causing a virtual CPU to enter the shutdown state. If this fault had occurred outside of a virtual machine, it would have caused the physical machine to restart. The shutdown state can be reached by incorrectly configuring the virtual machine, a bug in the guest operating system, or a problem in VMware Workstation

так же в папке появились файлы

Windows 7-000001.vmdk
Windows 7-000001-s001.vmdk
Windows 7-000001-s002.vmdk
.
Windows 7-000001-s014.vmdk

так же присутсвуют файлы формата:

Windows 7-s001.vmdk
.
Windows 7-s014.vmdk

количество ядер уже менял. виртуализацию отключал. не помогает.
monitor_control.disable_longmode = TRUE добавлял. тоже не помогло.

- какая хостовая ОС?
- какая версия VMware Workstation?
- дополнения (VMware Tools) установлены?
- в настройках гостевой системы виртуализация настроена (закладка Processors-Virtualization Engine)?

1. Windows 7 ultimate x32
2. 12 pro
3. VMware Tools стандартные (шли внаборе с программой)
4. пробывал ставить автоматически и "Intel VT-x или AMD-V"

Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.

Если виртуальная машина выключена или находится в состоянии паузы (suspend), то ее можно мигрировать как между серверами, так и между хранилищами, между серверами и хранилищами одновременно.

Запуск миграции осуществляется перетаскиванием ВМ на нужный сервер или хранилище, или пунктом Migrate контекстного меню ВМ. Условий ни на ВМ, ни на серверы не налагается.

Если необходимо мигрировать ВМ без участия vCenter, то пункт Migrate или перетаскивание вам недоступно. Тогда можно сделать так:

1. Выключить ВМ или перевести в состояние паузы (suspend).

Рис. 6.56. Просмотр сработавших alarms

2. Удалить ВМ из иерархии объектов ESX(i) - пункт Remove from Inventory контекстного меню.

3. Перенести файлы ВМ на другое хранилище, если необходимо. Для этого можно воспользоваться встроенным файловым менеджером или любым другим.

4. Зарегистрировать ВМ на нужном сервере. Для этого через встроенный файловый менеджер найти ее файлы и выбрать Add to inventory в контекстном меню ее файла настроек (*.vmx).

Если есть необходимость перенести ВМ с сервера на сервер или на другое хранилище с минимальным простоем, но vMotion/Storage vMotion недоступен, то можно сделать так:

1. Для работающей ВМ создать снимок состояния (snapshot).

2. Скопировать все ее файлы, кроме файлов последнего снимка состояния, на новое хранилище.

3. Перевести ВМ в состояние паузы (suspend).

4. Перенести на другое хранилище оставшиеся файлы ВМ (это файлы последнего снимка и файл с памятью ВМ в состоянии паузы).

5. Через встроенный файловый менеджер найти скопированные файлы на другом сервере и выбрать Add to inventory в контекстном меню ее файла настроек (*.vmx). Если копирование на другое хранилище этого же сервера, то тогда исходную ВМ нужно удалить пунктом Remove from inventory, а скопированную добавить на этом же сервере.

6. Включить ВМ на новом месте, удалить снимок состояния, удалить исходную ВМ.

На просторах есть много статей о том, как настраивать PowerChute Business Edition, и как подключаться к VMWare из PowerShell, но как-то не встретилось все это в одном месте, с описанием тонких моментов. А они есть.

1. Вступление

Несмотря на то, что мы имеем некоторое отношение к энергетике, проблемы с электричеством иногда возникают. Тут в дело вступает ИБП, но и его батареи, увы, не долговечны. Что делать? Выключать!

Пока все серверы были физическими, дела шли неплохо, нас выручала PowerChute Business Edition. Бесплатная, на 5 серверов, чего вполне хватало. На одной машине был установлен агент, сервер и консоль. При приближении конца агент просто выполнял командный файл, в котором на соседние серверы посылалось shutdown.exe /s /m, а потом гасил свою ОС. Все живы.
Потом настало время виртуальных машин.

2. Исходные данные и размышления

Итак, что мы имеем? Всего ничего – один физический сервер с Windows Server 2008 R2 и один гипервизор с несколькими виртуальными машинами, среди которых есть и Windows Server 2019, и Windows Server 2003, и CentOS. И еще ИБП – APC Smart-UPS.

Про NUT мы слышали, но руки пока до его изучения не дошли, использовали только то, что было под рукой, а именно PowerChute Business Edition.

Гипервизор умеет сам завершать работу своих виртуальных машин, осталось только ему сообщить, что пора. Есть такая полезная штука VMWare.PowerCLI, это расширение для Windows Powershell, как раз позволяющее подключаться к гипервизору и сообщить ему все что надо. Про настройки PowerCLI тоже есть много статей на просторах.

3. Процесс

ИБП физически подключили к com-порту сервера 2008, благо он был. Хотя это не принципиально – можно было подключиться через преобразователь интерфейсов (MOXA) к любому виртуальному Windows серверу. Далее все действия производятся на машине, к которой подключена ИБП – Windows Server 2008, если явно не указано иное. На ней установили агента PowerChute Business Edition. Вот тут находится первый тонкий момент: службу агента нужно запускать не от системы, а от пользователя, иначе агент не сможет выполнить cmd-файл.

Далее установили PowerShell 5.1. Тоже требуется перезагрузка, даже если не просит.
Далее установка PowerCLI 11.5. Довольно свежая версия, от этого и предыдущие требования. Можно через интернет, об этом есть много статей, но у нас оно уже было скачано, так что просто скопировали все файлы в папку Modules.

Ок, видим, установили:

Да, консоль Powershell конечно запущена от Администратора.

Либо разрешить только игнорировать сертификаты скриптов:

Разрешить PowerCLI подключение к серверам с недействительными (просроченными) сертификатами:

Сохранить учетные данные пользователя для входа на хост VMWare, чтоб явно не светить их в скрипте:

Проверка покажет, кого мы сохранили:

Можно и подключение проверить: Connect-VIServer address.

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

4. Default.cmd

Тот самый командный файл, который запускается агентом APC. Лежит в “C:\Program Files[ (x86)]\APC\PowerChute Business Edition\agent\cmdfiles”, а внутри:

«C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe» -File «C:\. \shutdown_hosts.ps1»
Вроде все настроили и проверили, даже запустили cmd – отрабатывает правильно, выключает.

Запускаем из консоли APC проверку командного файла (там есть кнопка Test) – не работает.

Вот он, тот неловкий момент, когда вся проделанная работа ни к чему не привела.

5. Катарсис

Смотрим диспетчер задач, видим – промелькнуло cmd, промелькнуло powershell. Приглядываемся повнимательней – cmd *32 и, соответственно, powershell *32. Понимаем, что служба агента APC 32-разрядная, а значит она запускает соответствующую консоль.

Запускаем powershell x86 от администратора, проделываем еще раз установку и настройку PowerCLI из пункта 3.

По умолчанию все виртуальные машины, запущенные на сервере VMWare ESXi или VMware Hypervisor не запускаются автоматически после перезагрузки сервера. Это означает, что после перезагрузки хоста ESXi (плановой или неплановой, по питанию), администратору придется вручную запускать все виртуальные машины. Разберемся, как настроить автоматический запуск ВМ на сервере VMWare ESXi, чтобы ВМ загружались автоматом без участия администратора.

Итак, запустите браузер, откройте стартовую страницу VMware Web Client и авторизуйтесь. Затем в консоли Web Client выберите хост, на котором вы хотите настроить автозапуск ВМ. Затем перейдите в раздел Manage -> Settings -> VM Startup / Shutdown .

Совет . В том случае, если хост ESXI включен в кластер vSphere HA, настроить автозапуск ВМ таким образом не удастся, т.к. за доступность ВМ отвечает кластерная служба HA, которая учитывает и запоминает состояние ВМ.

Как вы видите все ВМ, расположенные на данном сервере ESXi, перечислены в списке Manual Startup . Это означает, что после перезагрузки сервера, их нужно включать вручную.

Чтобы они загружались автоматически, нужно вручную добавить в список Automatic Startup . Для этого нажмите кнопку Edit .

В диалоговом окне Edit VM Startup and Shutdown , поставьте чекбокс Autmatically start and stop the virtual machines with the system . Теперь можно настраивать параметры автозапуска ВМ.

Доступны следующие опции включения/выключения виртуальных машин:

Startup delay — задержка в секундах перед включением ВМ (по умолчанию 120 секунд). С помощью данной задержки можно дождаться загрузки других ВМ, запуска служб (например, AD, DNS, NTP и пр.), а также выполнения скриптов.
Shutdown delay –задержка перед выключением каждой ВМ (по умолчанию 120 секунд).
Shutdown Action –доступны четыре варианта действий, которые можно выполнить при выключении виртуальной машины: None, Power Off , Suspend или Guest Shutdown (с помощью возможностей VMTools). По умолчанию используется Power Off.

Можно поместить ВМ в одну из следующих секций:

Automatic Startup –все ВМ, помещенные в эту секцию запускаются автоматически после загрузки хоста ESXi. Администратор может изменить порядок загрузки виртуальных машин. Например, сначала должен запуститься контроллер домена, потом сервера Exchange и т.д.
Any Order – виртуальные машины загружаются в произвольном порядке
Manual Startup — администратор должен вручную включить данные ВМ

Выберите виртуальную машину и с помощью кнопок Вверх/Вниз переместите ее в секцию Automatic Startup . Аналогичную операцию выполните для всех ВМ.

Сохраните изменения, нажав ОК.

Совет . Если HA у вас не настроен, но возможна миграция ВМ между серверами с помощью vMotion, параметры автозапуска переезжают между серверами вместе с виртуальной машиной. Поэтому не придется настраивать автозапуск на всех хостах, где может быть запущена ВМ.

Кроме того, параметры автозапуска ВМ могут быть настроены с помощью PowerCLI. Выведем список ВМ на хосте с их настройками автозапуска:

Get-VM –VMname * | Select-Object VMname, AutomaticStartAction

Чтобы включить автозапуск для всех ВМ, чьё имя начинается с msk, выполните команду:

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