Приложению не удалось открыть удаленный браузер файлов hyper v

Обновлено: 08.07.2024

Как старший программный менеджер в группе Product Quality and Online (PQO), я особое внимание уделяю технологиям виртуализации, то есть продуктам Microsoft Hyper-V Server, System Center Virtual Machine Manager (SCVMM), Microsoft Application Virtualization (App-V), Microsoft Enterprise Desktop Virtualization (MED-V) и Windows Virtual PC. Совместно с командами разработчиков я работаю над решением проблем, о которых пользователи сообщают в службу поддержки Microsoft. Данные проблемы следует учитывать всем, кто планирует устанавливать Hyper-V или уже работает с ним

Исключения в антивирусе

Если на сервере Hyper-V установлено антивирусное программное обеспечение и файлы виртуальной машины Hyper-V не добавлены в список исключений компонента сканирования в реальном времени, то вы можете столкнуться со множеством трудностей. Наиболее распространенная проблема — администратор открывает консоль управления Hyper-V и обнаруживает, что виртуальные машины исчезли. Другие симптомы:

Чтобы избежать этих проблем, добавьте в список исключений компонента сканирования в реальном времени в своем антивирусе перечисленные ниже папки и файлы.

Папка, в которой по умолчанию хранятся настройки виртуальных машин (C:\ProgramData\Microsoft\Windows\Hyper-V).
Другие папки конфигураций виртуальных машин.
Папка, в которой по умолчанию хранятся VHD-файлы (C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks).
Другие папки, в которых хранятся VHD-файлы.
Папки, в которых хранятся снимки.
Vmms.exe (возможно, придется настроить как процесс-исключение в антивирусной программе).
Vmwp.exe (возможно, придется настроить как процесс-исключение в антивирусной программе).

Снимки и нехватка места на диске

Если снимки не могут быть объединены из-за нехватки места на диске (то есть error0x80070070), не удаляйте файлы с расширением. avhd (файлы снимков). В результате удаления файлов. avhd произойдет потеря данных, которая приведет к тому, что виртуальная машина перестанет запускаться. Если у вас нет возможности освободить необходимое дисковое пространство на томе, где хранятся файлы. avhd, требуется сделать следующее:

Экспортировать виртуальную машину на том, где достаточно свободного места на диске.
После завершения экспорта откройте консоль управления Hyper-V и удалите виртуальную машину, которую экспортировали.
Импортируйте виртуальную машину из нового места хранения. Если версия Hyper-V ниже Windows Server 2008 R2, включите виртуальную машину, а затем выключите ее, чтобы запустить процесс объединения в новом месте хранения.

Компоненты интеграции не обновлены

После того как исправление или обновление для Hyper-V установлено на сервер (Windows 2008 R2, Server 2008 или Microsoft Hyper-V Server), просмотрите документацию, связанную с исправлением, чтобы узнать, требует ли это исправление обновления компонентов интеграции виртуальной машины. Вы также можете просмотреть список обновлений Hyper-V на сайте TechNet, чтобы выяснить, включает ли обновление усовершенствованные компоненты интеграции.

Чтобы определить, какие виртуальные машины имеют устаревшие компоненты интеграции, можно просмотреть журнал событий Microsoft-Windows-Hyper-V-Integration/Admin. Если виртуальная машина использует устаревшие компоненты интеграции, то при ее запуске в журнал будет записано следующее событие:

Log Name: Microsoft-Windows-Hyper-VIntegration-Admin

Событие с идентификатором 4010 будет записано для каждой устаревшей службы интеграционного компонента виртуальной машины (экран 1).

Экран 1. Событие 4010 в журнале

Функция Refresh virtual machine configuration и кластер

Консоль управления Hyper-V не поддерживает кластеры, и это означает, что изменения настроек виртуальных сетей или виртуальных машин в данной консоли должны быть продублированы на другие узлы кластеров с помощью функции Refresh virtual machine configuration в консоли диспетчера отказоустойчивых кластеров.

Если не воспользоваться этой функцией, то виртуальная машина либо вообще не сможет перемещаться между узлами кластера, либо ее параметры (например, VLAN ID), которые были изменены, будут потеряны при перемещении виртуальной машины на другой узел кластера Hyper-V. Чтобы обновить настройки виртуальной машины, выполните следующие шаги.

В консоли диспетчера отказоустойчивых кластеров откройте раздел Services and Applications, а затем щелкните по виртуальной машине, для которой хотите обновить настройки.
В окне Actions прокрутите список вниз, щелкните мышью на кнопке More Actions, затем выберите функцию Refresh virtual machine configuration, как показано на экране 2.

Экран 2. Функция Refresh virtual machine configuration

В системе Server 2008 R2 функцией Refresh virtual machine configuration можно не пользоваться, если вы меняете параметры виртуальной машины с помощью консоли диспетчера отказоустойчивых кластеров. Для изменения параметров виртуальной машины в этой консоли сделайте следующее:

Сбой операции миграции виртуальной машины в исходном расположении миграции

Причины ошибок 0x8009030E и 0x8009030D

И та и другая ошибка связаны с тем что нужно входить на каждый сервер для выполнения определенной задачи (через локальный сеанс консоли, сеанс удаленного рабочего стола или удаленный сеанс Windows PowerShell) с сервера с которого осуществляется миграция либо настроить ограниченное делегирование для хостов.

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

Решения:

На вкладке Динамическая миграция, должна стоять галка Включить входящие и исходящие миграции.

Вторая причина у вас не включен Kerberos. Если у вас по CredSSp, не удается мигрировать выставляем тогда Kerberos, для большей безопасности, его мы еще поднастроим.

Так же если вы пытаетесь делать миграцию работающей виртуальной машины, может возникнуть ошибка VMM:

Для решения, удостоверьтесь, что у вас стоит галка в свойствах виртуалки, на вкладке Процессор (Выполнить перенос на физический компьютер с другой версией процессора). Данная галка нужна если у вас разные процессоры, так как не везде все сервера одинаковые.

Если вы выполняете миграцию с рабочей станции, через оснастку Диспетчер Heper-V вы опять словите данную ошибку 0x8009030E или 0x8009030D, так как данную операцию нужно производить с хоста Hyper-V, где лежит тачка подключенного по RDP, но не спешите расстраиваться, мы же не зря настраивали kerberos, делаем ниже инструкции и радуемся жизни

Все можно теперь мигрировать спокойно.

Если у вас SCVMM

Если у вас есть scvmm, то проверьте, что в свойствах хоста

Перейдите на вкладку Доступ к узлу и проверьте, что в Учетная запись запуска от имени не пуста, если там ничег онет, то через обор добавьте.

ИСПРАВЛЕНО: НЕ МОГУ УСТАНОВИТЬ HYPER-V В WINDOWS 10 - ИСПРАВЛЯТЬ - 2021

Видео: How to Install Ubuntu using Hyper-V on Windows 10 Pro in 10 Minutes 2021.

Windows 10 поддерживает клиент Hyper-V; надежная, высокопроизводительная и гибкая технология виртуализации клиентов, которая позволяет пользователям одновременно запускать несколько операционных систем на своем компьютере Windows. Вы можете включить функцию Hyper-V в разделе «Включение или отключение функции Windows» на рабочем столе. Вы также можете включить его из Windows PowerShell, а также из командной строки. Иногда вы можете столкнуться с проблемами при установке Hyper-V в Windows 10. Важно сначала проверить, поддерживает ли ваш компьютер Hyper-V.

Hyper-V - отличная функция, но иногда вы можете столкнуться с проблемами при ее установке. Что касается проблем, вот некоторые распространенные проблемы, с которыми столкнулись пользователи:

Решение 1. Проверьте требования к оборудованию

Hyper-V - отличная функция, но если вы хотите ее использовать, сначала вы должны соответствовать определенным требованиям к оборудованию. Чтобы использовать Hyper-V, ваш компьютер должен соответствовать следующим требованиям:

64-битная Windows
4 ГБ ОЗУ
Трансляция адресов второго уровня (SLAT), также известная как быстрая индексация виртуализации (RVI)

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

Если во всех записях раздела «Требования Hyper-V» указано «Да», это означает, что ваш ПК может поддерживать и использовать Hyper-V. С другой стороны, если некоторые функции недоступны, вам нужно включить их в BIOS.

Предотвращение выполнения данных и виртуализация, включенная в функции встроенного ПО, могут быть включены в BIOS. С другой стороны, такие функции, как расширения режима VM Monitor и функции трансляции адресов второго уровня, связаны с вашим оборудованием, и, если эти функции недоступны, вам потребуется обновить ваш ЦП.

Решение 2 - Обновите вашу систему

Симптом:

Hyper-V нельзя включить даже после выполнения чистой установки сборок Windows 10 10049 или после обновления со сборки, в которой не был включен Hyper-V.

Причина:

Оборудование не поддерживается. Старые машины могут не иметь возможности включать Hyper-V, если оборудование несовместимо. Следовательно, одна из причин, по которой вы не можете включить Hyper-V, заключается в том, что оборудование было признано недопустимым. В этом случае вам может потребоваться обновить процесс программного обеспечения или использовать другую систему с совместимым процессором.
Файл wstorvsp.inf не был правильно добавлен в хранилище драйверов во время онлайн-обслуживания драйверов.

Решение:

Если файл wstorvsp.inf не был правильно добавлен в драйвер, Microsoft предоставляет Центр обновления Windows для решения проблемы. Чтобы обновление работало, вы должны запустить Windows 10 Technical Preview build 10049. Вы также должны перезагрузить компьютер после установки обновления.

Найдите файл Windows ISO, который вы использовали для установки операционной системы. Щелкните правой кнопкой мыши и выберите «Mount».
Распакуйте файл Iso и найдите папку Sources sxs. Скопируйте эту папку на любой диск, который не является системным корневым диском, например, диск F :.
Теперь откройте Windows PowerShell или административную командную строку и введите следующую команду.

dism / online / enable-feature / имя_файла: Microsoft-hyper-v-all / All / LimitAccess / Source:

После появления запроса перезагрузите систему. Функция Hyper-V будет готова к использованию после перезагрузки.

Решение 3 - Удалить стороннее программное обеспечение

Hyper-V - это встроенное программное обеспечение для виртуализации в Windows 10, но, к сожалению, оно плохо работает со сторонними приложениями. Иногда стороннее программное обеспечение может устанавливать свои собственные драйверы, которые могут мешать работе Hyper-V.

Если Hyper-V не удается установить, обязательно удалите все сторонние программы виртуализации с вашего ПК. У многих пользователей были проблемы с VirtualBox, но после его устранения проблема была решена. В дополнение к VirtualBox пользователи сообщали о проблемах с Check Point Endpoint Security VPN, поэтому, если вы используете это приложение, обязательно удалите его.

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

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

Решение 4. Убедитесь, что вы не используете домашнюю версию

Hyper-V - отличная функция, однако не все версии Windows 10 поддерживают ее. Как вы знаете, существуют разные версии Windows 10, и у каждой версии разные цены и функции.

К сожалению, Hyper-V недоступен в домашних версиях Windows 10, поэтому, если вы используете домашнюю версию, вам не повезло. Единственный способ использовать Hyper-V - перейти на версию Professional, Education или Enterprise.

Решение 5. Используйте командную строку

Если вы не можете установить Hyper-V на ПК с Windows 10, возможно, в вашей системе есть небольшая ошибка, которая мешает вам установить его. Несколько пользователей сообщили, что они исправили этот сбой, просто запустив одну команду в командной строке.

Для этого просто выполните следующие простые шаги:

Запустите командную строку от имени администратора.
Запустите команду SC config trustinstaller start = auto .

После выполнения команды перезагрузите компьютер и попробуйте снова установить Hyper-V.

Решение 6 - Изменить ваш реестр

Несколько пользователей сообщили, что система EFI с включенной функцией безопасной загрузки может вызвать проблемы с Hyper-V и помешать его установке. Однако вы можете решить эту проблему, выполнив несколько команд в командной строке.

Имейте в виду, что эти команды изменят ваш реестр, но если вам это неудобно, вы можете пропустить это решение. Чтобы решить эту проблему, вам нужно сделать следующее:

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

reg delete HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ DeviceGuard / v Включить виртуализациюBasedSecurity
reg delete HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ DeviceGuard / v RequirePlatformSecurityFeatures
bcdedit / set loadoptions DISABLE-LSA-ISO, DISABLE-VBS

После выполнения этих команд проверьте, сохраняется ли проблема.

Решение 7. Установите компоненты Hyper-V отдельно

По словам пользователей, если вы не можете установить Hyper-V на свой ПК, вы можете обойти эту проблему, просто установив компоненты Hyper-V отдельно. Это довольно просто, и вы можете сделать это, выполнив следующие действия:

После перезагрузки компьютера проблема должна быть полностью решена, и Hyper-V будет установлен на ваш компьютер.

Решение 8 - Начать все с начала

В Windows 10 есть полезная функция «Свежий запуск», которая позволяет быстро и легко переустановить Windows 10. Перед началом «Свежего запуска» рекомендуется создать резервную копию файлов, чтобы не потерять их. Этот процесс удалит установленные вами приложения, поэтому вам придется установить их заново вручную.

Чтобы начать все сначала, вам нужно сделать следующее:

После завершения процесса у вас будет новая установка Windows 10, и Hyper-V сможет ее установить.

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

Примечание редактора : этот пост был первоначально опубликован в августе 2016 года и с тех пор был полностью переработан и обновлен для обеспечения свежести, точности и полноты.

Исправлено: не могу ничего установить на мой windows 10 pc

Если вы не можете ничего установить на свой компьютер с Windows 10, вот несколько быстрых решений, которые помогут вам решить эту проблему.

Исправлено: не могу установить icloud на Windows 10

Вы пробовали несколько раз, и клиент iCloud просто не установится на Windows 10, что бы вы ни делали? Проверьте решения, которые мы перечислили и заставьте это работать.

Исправлено: не могу установить динамику CRM на Windows 10

Вот три возможных решения, которые вы можете использовать, если не можете установить Dynamics CRM на свой компьютер с Windows 10.

Как бы круто это ни звучало - “Логдайвинг” - на самом деле ковыряние логов может быть не самым интересным занятием, а на первых порах даже вызывать фрустрацию (когда файлов куча, но не знаешь, куда смотреть). Но, этот навык очень хорошо развивается с опытом. По кусочку, по крупинке навык развивается, и в очередной раз открывая папку с логами, уже не нервничаешь, а хладнокровно ищешь информацию, зная, куда смотреть.

В то же время умение работать с логами - очень ценный и полезный навык. Я бы сравнил работу с логами с поеданием овсянки. Есть овсянку - полезно == уметь анализировать логи - полезно. Ну, а для того, чтобы овсянка стала вкуснее, в нее я добавлю топпинг - интересный сценарий. Чем более загадочной выглядит проблема, тем интереснее становится анализ логов, и ты смотришь уже не просто на строки текста, а распутываешь клубок из улик и доказательств, проверяешь или опровергаешь теории.

Ну что, наливаем чаек, сейчас мы будем расследовать - Детектив с Кластером Hyper-V

Дисклеймер: я привожу пример того, как я анализирую логи. Жесткого стандарта нет, и действия других инженеров техподдержки Veeam могут (и будут) отличаться. Скриншоты и логи взяты из моей лабы, так как логи клиентов никогда не публикуются и удаляются при закрытии кейса.

0. По традиции - все начиналось с ошибки.

Как и в любом детективе, начало весьма обычное: есть конкретная проблема. В этом случае выглядела она как тикет от клиента с примерно таким содержанием: "Помогите! Задание падает с ошибкой - Processing FS2 Error: Failed to get VM (ID: 6fb62d8a-4612-4106-a8e7-8030de27119e) config path. [WMI] Empty result."

Когда есть конкретная ошибка, это уже хорошо. Сразу понятно: что-то явно сломано – это как стук в двигателе машины. Мы видим, что это ошибка в работе Backup job - задании резервного копирования для нескольких виртуальных машин. В этой ошибке даже есть аббревиатура [WMI], а это уже зацепка!

Как говорит википедия: WMI — это одна из базовых технологий для централизованного управления и слежения за работой различных частей компьютерной инфраструктуры под управлением платформы Windows. А я бы сказал: WMI - это технология, используя которую Veeam B&R отправляет запросы на Hyper-V хост или кластер. Это могут быть такие запросы, как создание чекпоинта, удаление чекпоинта, создание коллекции, добавление VM в коллекцию и так далее.

Зная это, мы понимаем, что имеем дело с Hyper-V инфраструктурой. (Далее надо будет понять, кластер это или же одна нода). А проблема связана с WMI запросом, который вернул пустое значение. (Empty result)

Промежуточный вывод: задание резервного копирования для пяти виртуальных машин на гипервизоре Hyper-V завершилось успешно для трех машин, а для двух выдало ошибку - Failed to get VM (ID: 6fb62d8a-4612-4106-a8e7-8030de27119e) config path. [WMI] Empty result.

1. Приступаем к сбору логов

С чего же начинается анализ логов? - В первую очередь со сбора этих самых логов! В некоторых случаях собрать правильные логи - это уже полдела! Напоминаю, мы расследуем конкретное задание (Job), и портфель с логами нам нужен именно для этого задания.

Дело в том, что в задании помимо Veeam сервера задействованы другие компоненты. Это и Hyper-V ноды, на которых крутятся машины из задания, и репозиторий, на который пишутся файлы бэкапа, и прочие прокси. В общем случае таких серверов может быть достаточно много. И что же теперь? Нам лазать по всем серверам и копировать файлы? Нет, в нашей ситуации процесс сбора логов - полуавтоматический, благо в VBR есть встроенный помощник для таких дел. Есть даже статья с анимацией. Поэтому, в консоли Veeam переходим в Menu → Help → Support information

При выборе опции (Export logs for this job), Veeam B&R соберет файлы со всех компонентов (прокси = Hyper-V ноды), вовлеченных в задание. Также будет добавлен HTML отчет, который может очень сильно упростить анализ. Одним словом - песня, все логи в одном архиве, да ещё и отчетик прилагается.

2. Анализ собранной информации

Итак, распаковали архив и видим следующее:

Папка с логами, собранными с Veeam B&R сервера - storepc.dom1.loc

Папки с логами, собранными с двух Hyper-V нод - 19node1 и 19node2

Отчет по конкретному заданию - Critical FServers.html

Хммм, с чего же начать…..

А начинать, я считаю, надо от общего к частному. Общим в нашем случае будет HTML отчет - так как в нем мы видим общую информацию о выполнении задания за период времени, и можно прикинуть статистику. Ну и, конечно же, отчет более приятен человеческому глазу, чем сотни строк логов =)

2.1 Отчет задания, и зачем его смотреть

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

Что же мы видим в отчете?

Сервер FS4 падает с ошибкой;

Через несколько минут - успешный Retry для сервера FS4

Во время следующего штатного выполнения задания серверы FS2 и FS3 падают с этой же WMI-ошибкой

Через несколько минут - успешный Retry для серверов FS2 и FS3

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

Retry - специальная настройка задания, которая попытается повторить его выполнение только для тех VM, для которых не был создан бэкап. В настройках задания обычно указывается, сколько раз пробовать Retry и через какой промежуток времени после неудачи.

Теории о том, что:

есть проблемная машина или ряд проблемных машин;

есть проблемная Hyper-V нода ;

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

2.2 Логи задания: ищем стэк ошибки

Так как ошибка одна, но появляется для разных машин, то мы просто выбираем любое выполнение задания с ошибкой и анализируем его. Для начала идем в лог, который описывает обработку конкретной машины в задании - той, для которой вышла ошибка. Схема, по которой ищутся логи для задания - Veeam сервер\Backup\Название задания. В нашем случае это storepc.dom1.loc\Backup\Critical_FServers. Более подробно про структуру логов и где что лежит мы писали в отдельных статьях здесь и здесь.

В этой папке для задания резервного копирования можно встретить 3 типа логов:

Agent - логи компонента, который занимается передачей данных (Veeam Agent - Data mover). Если в названии есть слово Target, значит - это лог агента, который записывал данные на репозиторий. Если это задание репликации, то Target будет в папке на сервере, который использовался в качестве целевого прокси и писал данные на хранилище данных гипервизора (Datastore) куда реплицируем. Если в названии есть слово Source, значит - это лог агента, который читал данные с хранилища данных гипервизора (Datastore).

Job - это лог задания целиком. При общении с сапортом можно смело говорить просто “джоба”, и вас поймут.

Task - это лог подзадания (таски), из которого состоит задание (Job). Каждая виртуальная машина в задании обрабатывается отдельной таской, которая пишет свой отдельный лог.

Мы открываем файл, начинающийся с Task и содержащий название VM. В нем просто ищем ошибку. Обычно нажимаем CTRL+End - это перебрасывает нас в самый низ лога, и потом крутим колесико вверх, пока не увидим нужную нам ошибку.

Стэк выглядит вот так, и нам он говорит, что был WMI запрос HviGetVmConfigPath: - этот запрос попытался получить путь до конфигурации VM по ID и в ответ получил пустой результат. Круто! Запрос! А дальше-то что?

А дальше нужно смотреть логи компонента, отвечающего за запросы, анализировать их, чтобы наконец построить теорию.

2.3 Логи WMI запросов на Hyper-V ноду с сервера Veeam

Нам нужны логи Veeam компонента, который отправляет WMI запросы на Hyper-V ноде.

Подсказка: его мы видим в стеке с ошибкой который я показал выше :

Видим, что результатом запроса был конфигурационный файл виртуальной машины. Возникает вопрос: почему же для одной машины файл был успешно найден, а для другой нет? Мы знаем, что через несколько минут на ретрае проблемная машина была все же обработана. Идем анализировать ретрай…. (смотрим лог подзадания Task):

Мы видим, что в этот раз запрос на получение конфигурационного файла машины уже шёл через другую Hyper-V ноду 19node2. Открываем лог HvWmiProxy со второй Hyper-V ноды и видим, что там WMI запрос отработал успешно.

Здесь я предлагаю сделать перерыв, не торопиться читать дальше, а попытаться самому построить теорию. Ведь в детективах самое интересное - это не просто дочитать до конца, а пытаться разгадать еще в середине, а потом просто проверить свои догадки.

2.4 Промежуточные итоги и наконец - теория!

Подводим промежуточные итоги анализа:

Запрос валится с пустым значением, когда выполняется на одной Hyper-V ноде, и через несколько минут отрабатывает корректно, когда выполняется на другой Hyper-V ноде.

Напрашивается резонный вопрос – почему на ретрае запрос стал выполняться на второй Hyper-V ноде? Как Veeam определяет, какая нода должна обрабатывать машину? Для обработки машины (создание снапшота и тд.) Veeam выбирает ту ноду, на которой находится машина (owner). В один момент времени у машины может быть только один владелец (owner). Получается, что в момент штатного выполнения машина числилась на одной ноде, а в момент ретрая уже на другой.

А такое вообще возможно?

Дело в том, что если Hyper-V ноды подключены к кластеру, то машины на них могут мигрировать с ноды на ноду в рамках кластера. Происходить это может по абсолютно разным причинам. Здесь можно выдвинуть предположение, что миграция машины с одной Hyper-V ноды на другую служила причиной такого поведения.

Эту теорию о миграции надо проверять….

2.5 Проверка теории

Идем смотреть лог самого задания, он же Job лог. Там находим таблицу, в которой прописан список Tasks (подзаданий) для каждой машины:

В таблице ясно видно на какой ноде находилась VM во время начала задания. Здесь мы видим, что FS4 была на первой ноде. Смотрим таблицу во время ретрая:

Lifehack: переключаться между выполнениями задания в логе (и штатными, и ретраями) очень удобно, нажав CTRL+f (поиск) и искать “new log”. Таким образом будешь “скакать” от выполнения к выполнению - только не забудь указать, куда хочешь мотать, вперед или назад.

Вуа-ля! Мы подтвердили, что машина мигрировала (смена ноды для машины и есть миграция). В случае необходимости можно запросить и глянуть Windows Events с ноды. Нужные события находятся в ветке Hyper-V-VMMS > Admin.

Элементарно, Ватсон!

Следовательно, такую, казалось бы, мистическую ситуацию можно объяснить достаточно просто – во время начала задания Veeam строит список машин, которые нужно будет обработать, и определяет на какой Hyper-V ноде какая машина находится. Когда дело доходит до машины, то обрабатывается именно та Hyper-V нода, на которой она была в момент начала задания.

В ситуации, когда в задании много машин, и некоторые ждут своей очереди несколько часов, вполне реальна ситуация, что машина мигрирует на другую ноду, и возникнет такая ошибка. На ретрае Veeam опять определяет Hyper-V ноду для машины, и все отрабатывает штатно. Это одна из причин, почему десять мелких бекапных заданий будут лучше, чем одно большое.

Возникает законный вопрос – почему бы не определять Hyper-V ноду для машины прямо перед началом её обработки, чтобы учесть возможность миграции? Дело в том, что такие ограничения связаны с шаренными снапшотами и оптимизациями для параллельной обработки виртуальных машин.

Шаренный снапшот - это когда создается теневая копия на уровне хоста, и в неё добавляются сразу несколько компонентов Hyper-V VSS райтера. Это необходимо, чтобы сделать одну теневую копию волюма, и с этой копии сделать бэкап нескольких виртуальных машин, расположенных на нем. В противном случае для каждой виртуальной машины будет создаваться заново теневая копия всего волюма, на котором расположено несколько машин.

Подробнее о том, зачем используется теневая копия (VSS) во время бэкапа, можно почитать здесь.

А сама опция называется - Allow processing of multiple VMs with a single volume snapshot

Таким образом, Veeam в самом начале задания анализирует все виртуальные машины, которые предстоит бэкапить, и в зависимости от разных факторов (например, расположение на одном волюме) может выбирать машины группами. Соответственно, ресурсы планируются в самом начале выполнения задания. И то, что машина мигрировала - это нештатная ситуация, которая успешно отрабатывается на повторе. Поэтому можно сказать, что возникновение такой ошибки - это ожидаемая и подконтрольная ситуация, как бы странно это ни звучало.

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

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