Поскольку на виртуальном процессоре возникла неустранимая ошибка вызвавшая тройной сбой
В данной статье описывается проблема, которая возникает в основном приложении Windows 8.1 и Windows Server 2012 R2 Hyper-V. Доступно исправление для решения этой проблемы. Перед установкой данного исправления необходимо извлечь разделе требований .
Введение
Рассмотрим следующий сценарий:
У вас есть компьютер под управлением Windows Server 2012 R2, настроенный для одной или нескольких групп сетевого Адаптера с помощью адаптеров сетевого Адаптера Windows (LBFO).
Объединение сетевого Адаптера Windows (LBFO) реализована в коммутатор независимых объединение режиме с использованием порта Hyper-V или динамическая балансировка нагрузки. Кроме того правильно настроенные сетевые адаптеры для использования неперекрывающихся процессоров. (Дополнительные сведения см. в статье базы знаний ).
Виртуальный коммутатор Hyper-V привязано к одной из групп LBFO.
При запуске виртуальной машины на сервере Hyper-V или динамической миграции виртуальной машины с одного сервера на другой сервер.
В этом случае возникнуть одно или несколько из следующих проблем:
Выпуск 1: В журнале событий периодически регистрируется следующее событие ошибки 113:
Примечание. В случае описание, текст причины всегда является «OID ошибка.» Состояние изменяется текст на основании драйвер сетевого адаптера, который используется. Ниже приведены примеры других состояния:
Состояние = недопустимый параметр был передан службе или функции
Состояние = недостаточное существует системных ресурсов для завершения вызова API
Причина Эта проблема возникает, потому что VmSwitch предполагает, что обработчик по умолчанию для VMQ равно нулю (0), при выполнении VMQ распределения. В результате некоторые сетевые драйверы адаптера отклонение распределения и генерации ошибки 113.
Исправление данных После установки данного исправления, VmSwitch больше не предполагается, что обработчик по умолчанию для VMQ равно нулю (0).
Дополнительные сведения об этой проблеме содержатся в статье базы знаний .
Проблема 2: Что приводит к снижению производительности или система перестает отвечать на запросы.
Причина Эта проблема возникает, поскольку перегружает алгоритм сопоставления физических ресурсов LBFO узла. Эта проблема может также инициировать «Flapping MAC».
Исправление данных После установки данного исправления, rebalancing алгоритм оптимизирован и сделаны более масштабируемым.
Проблема 3: На узле, возникает неустранимая ошибка 0xD1 при динамической миграции.
Причина Эта проблема возникает после LBFO очищает собственные структуры, поскольку она предполагает, что гарантируется прямой ход идентификатор объекта (OID).
Исправление данных После установки исправления LBFO очищает его сопоставления только в том случае, если идентификатор Объекта выполнена успешно. Для сценариев сбоя LBFO передает состояние OID VmSwitch. VmSwitch получает статус ошибки и обрабатывает его через свою собственную логику.
4]Hyper-V не в состоянии принимать репликацию на Replica Server для виртуальной машины.
Когда на виртуальной машине включена репликация, процесс создает файлы виртуальной машины реплики, где все хранится. У каждой из этих папок есть имя, представляющее GUID. Он уникален для каждого исходного сервера. Если по какой-то причине мастер установки Hyper-V имеет такой же UID, потому что он уже был настроен один раз, вы получите эту ошибку. Поскольку процесс проверяет наличие дубликатов виртуальной машины перед завершением, появляется ошибка.
Альтернативой этому методу является отказ от использования GUID. Документы Microsoft предлагает следующее:
- Включите репликацию для виртуальной машины и убедитесь, что начальная репликация не запускается немедленно (вы можете запланировать начальную репликацию на более позднее время)
- После создания реплики виртуальной машины используйте мастер перемещения, чтобы переместить хранилище виртуальной машины по выбранному вами пути (миграция хранилища).
- После завершения миграции хранилища вы можете запустить начальную репликацию для виртуальной машины.
Метод 2: проверьте физические диски
Если описанный выше метод не работает за вас, проблема может быть связана с отказом физических дисков. Если вы недавно установили USB-устройство или изменили физические диски виртуальных машин, было бы полезно проверить, не подключены ли физические диски неправильно. Более простой способ убедиться, что все диски работают и перечислены только те диски, которые в данный момент подключены, — это перейти в окно настроек виртуальной машины. Для этого следуйте приведенным ниже инструкциям:
- В окне диспетчера Hyper-V щелкните правой кнопкой мыши проблемную виртуальную машину и выберите параметр «Параметры».
- В окне «Настройки» разверните список «Контроллер SCSI», чтобы увидеть используемые диски.Настройки виртуальной машины
- Если какой-либо диск больше не подключен, и виртуальная машина проверяет его, вы должны удалить его.
- Это должно решить проблему.
Статус
Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе "Относится к".
Ссылки
См. , которые корпорация Майкрософт использует для описания обновлений программного обеспечения.
Стал происходить регулярный сброс виртуальной машины Ubuntu 16.04 LTS под управлением Hyper-V 2008 R2 с регистрацией ошибки Event ID 18560: "Выполнен сброс "UBUNTUSRV", поскольку на виртуальном процессоре возникла неустранимая ошибка, вызвавшая тройной сбой..". Описание ошибки на MS.
Поиск информации
Другая статья MS говорит, что это нормальное поведение для виртуальной машины на Linux: "Все варианты Linux, которые поддерживаются в Hyper-V могут регистрировать событие об ошибке, описанное в данной статье. Это происходит независимо от установленной версии служб интеграции Linux". Далее предлагается безопасно проигнорировать ошибку. Это хорошо конечно, ну а сброс виртуальной машины по нескольку раз в день?
Тут вспомнил, что службы интеграции я не устанавливал/не активировал, влил ОС как она есть и сразу начал пользоваться. Значит нужно попробовать это сделать. Стал искать информацию дальше и вот что получилось.
Установка LIS
Все современные ОС Linux идут уже с дистрибутивом LIS (Linux Integration Services). MS конечно на аббревиатуры сильна, то у нее АДАМ, то ЛИС. Редактируем файл модулей:
Добавляем туда информацию:
После перезагрузки выполняем команду lsmod и находим там hv_vmbus - значит все успешно установилось.
Прошло порядка 5 дней, статью специально не выкладывал, хостовая ОС перезагружалась несколько раз, гостевая Ubuntu тоже, но ошибка больше не фиксируется и сброс виртуальной машины не происходит. Даже если ошибка снова появится, то частота её появления будет уже не несколько раз в день, что радует.
Добавление от 16.07.2016
Потребовалось установить еще одну виртуальную машину Ubuntu 16.04 LTS, ошибка стала фиксироваться снова, уже для этой виртуальной машины.
Теперь сразу запустил команду lsmod, в прошлый раз я этого не сделал. Все виртуальные устройства шины hv_vmbus оказались на своих местах, то есть вроде бы как заново их прописывать и не надо. Однако указанные выше манипуляции опять помогли избавиться от ошибки. Вот такое шаманство, другими словами и не скажешь.
Репликация ОС или Hyper-V экономит много времени. Однако репликация Hyper-V, также называемая «репликой Hyper-V», отличается. Процесс репликации позволяет выполнять репликацию с одной виртуальной машины в среду другой виртуальной машины. Проще говоря, он создает копию действующей виртуальной машины на автономной виртуальной машине. Обычно это полезно для стратегии аварийного восстановления. В этом посте мы расскажем об исправлении некоторых распространенных ошибок репликации Hyper-V.
Причин сбоя репликации Hyper-V может быть несколько. Это могут быть проблемы с сетью, устаревший хост, целостность или что-то еще. Ниже приведены некоторые из распространенных проблем и способов их решения:
- Репликация Hyper-V приостановлена для виртуальной машины из-за неисправимого сбоя. (Идентификатор виртуальной машины ).
- Hyper-V не позволил запустить виртуальную машину, потому что она подготовлена к аварийному переключению
- Hyper-V не удалось разрешить имя сервера реплики
- Hyper-V не в состоянии принять репликацию на сервере реплики для виртуальной машины
- Не удалось выполнить операцию. Hyper-V не находится в допустимом состоянии репликации для выполнения операции
Интересно отметить, что большинство ошибок Hyper-V возникает из-за проблем с синхронизацией между ними. Либо хост находится на обслуживании, либо сервер-реплика отключен или не готов.
Метод 3: изменить права доступа к папке
Оказывается, иногда проблему можно решить, изменив права доступа к папке на виртуальной машине. Об этом сообщил пользователь, который однажды сам столкнулся с этой проблемой. Если описанные выше методы не решают проблему, вы можете перейти в папку, в которой находится ваша виртуальная машина. Оттуда вам нужно будет изменить разрешение на Все.
Для этого следуйте инструкциям ниже:
- Проберитесь в папку зараженной виртуальной машины.
- Щелкните правой кнопкой мыши и выберите Свойства.
- В окне «Свойства» перейдите на вкладку «Общий доступ».
- Там нажмите на опцию Advanced Sharing.
- Как только вы окажетесь в окне Advanced Sharing, установите флажок Share this folder. Теперь вы должны иметь возможность нажать кнопку «Разрешения» внизу.Права доступа к папке
- Нажмите на него, а затем для всех отметьте все в разделе Разрешить.
- Наконец, нажмите кнопку «Применить», а затем нажмите «ОК». Проделайте то же самое с остальными окнами.
- Посмотрите, решена ли проблема.
1]Hyper-V приостановила репликацию для виртуальной машины из-за неисправимого сбоя. (ID виртуальной машины)
Полное описание включает следующее: Hyper-V не смог реплицировать изменения для виртуальной машины , потому что сервер реплики отклонил соединение. Это может быть связано с тем, что на сервере реплики есть отложенная операция репликации для той же виртуальной машины, которая занимает больше времени, чем ожидалось, или имеет существующее соединение. (Идентификатор виртуальной машины )
Чтобы решить эту проблему, проверьте следующие моменты:
- Щелкните правой кнопкой мыши виртуальную машину и выберите возобновление процесса репликации.
- Убедитесь, что сервер репликации находится в оперативном режиме.
- На сервере-реплике всегда должно быть достаточно места
- Достаточная пропускная способность сети, чтобы процесс репликации мог завершиться за один цикл.
5]Не удалось выполнить операцию, Hyper-V не находится в допустимом состоянии репликации для выполнения операции.
Это происходит по двум причинам. Первый — это когда сервер не настроен как сервер-реплика. Поэтому, когда источник инициирует процесс репликации, другой конец не знает, что нужно делать с вводом. Во-вторых, когда сервер блокирует доступ к Hyper-V на сервере Rep0lication.
Хотя первую причину можно устранить, подготовив сервер-реплику, вторая — это скорее проблема с брандмауэром, которую ИТ-администратор может решить за вас.
Надеюсь, вам удалось устранить эти распространенные ошибки репликации Hyper-V. Я уверен, что их может быть больше, поэтому, если вы столкнетесь с чем-либо, сообщите нам, и мы найдем решение.
Алмаз, или купить флешку с большим количеством циклов) В данном случае да, если флешка так себе, то лучше отключить, а с другой стороны как дебажить трабу не имея логов. в общем палка о двух концах.
Прошу помощи по Hyper-V. Пробую на компе с Win 10 Pro, гостевая система так же Win 10 Pro. Виртуальная машина периодически перезагружается. В логах пишет, что "Выполнен сброс, поскольку на виртуальном процессоре возникла неустранимая ошибка, вызвавшая тройной сбой". Что это за зверь такой?
Александр, а что помимо этого пишет ?
Какой код ошибки ?
У виртуалки место на харде норм ? В основной машине место на харде и кеш норм ?
Martin, больше никакого кода ошибки (ну или я журнал событий читать не умею). С местом нормально, виртуалка на SSD находится, правда у гостевой машины я указал динамический диск размером 120 гигабайт, а на физическом диске столько свободного места нет. Но фактический размер файла HDD всего 20 гигабайт.
Доброго времени суток . Свитч aruba 1930. В настройках snmp требует ip . Указывать тачку куда будет статистика направляться?
Всем привет. ProxMox 6 не может сделать бекап на XigmaNAS 12 (протокол NFS), ругается что не может переименовать бекап из расширения dat в нормальное обычное (LZO). При этом места на диске полно, если удалить одну предыдущую копию, он начинает делать нормально (не ручной, а автоматический режим). Пришёл к выводу что нужно примерно в 2 раза больше свободного места на НАСе, чем реально занимает архив с виртуальной машиной. И если это место чуть меньше (чем в 2 раза), то получаешь ошибку о невозможности переименовать файл (бекап не делается в итоге). Место ПроксМокс определяет не совсем корректно, но свободное видит примерно столько, сколько и есть на самом деле (полное неверное отображает).
Кто-то сталкивался с этим? Неприятно иметь 1 Тб места и не иметь возможности сделать бекап на 600 Гб. Гуглил, ничего не нашёл, кроме того что места надо больше. Да вот только нафига? Его достаточно, более чем.
Есть принтер на принт сервере, при добавлении его на комп, при печати документов они медленно печатаются. В настройках стоит "Тип бумаги: Бумага HP для брошур, матов 150г", если сменить на "обычная" или "не указано", то печатает нормально, однако после каждой печати слетает настройка. НА ПРИНТ СЕРВЕРЕ в настройках стоит "обычная", пробовал ставить "не указано" и переподключал его, ничего не помогает. Help
Сообщается, что виртуальные машины Hyper-V застревают в сохраненном состоянии. Это происходит в различных сценариях, например, когда вы выключаете виртуальные машины; одна из виртуальных машин может оставаться в сохраненном состоянии, если у вас несколько запущенных. Кроме того, при перезагрузке хост-сервера некоторые виртуальные машины переходят в сохраненное состояние. Теперь, как правило, это не проблема, если виртуальные машины снова включаются в обычном режиме, когда им приказывают сделать это. Однако этого не происходит, и вы остаетесь с виртуальной машиной, которая застряла в сохраненном состоянии.
Hyper-V часто использует сохраненное состояние как метод резервного копирования по умолчанию. Возможно, виртуальная машина застряла при выполнении резервного копирования. Причин, из-за которых это вызвано, не так много, но мы составили список возможных причин, в зависимости от вашего сценария, которые могут вызвать это. Это следующие.
- Мало места на диске. Как оказалось, одна из основных причин этой проблемы — недостаток места на диске. Это часто может произойти, если один из ваших физических дисков был ошибочно отключен. В таком случае вам придется проверить свои физические диски, чтобы убедиться, что все в порядке.
- Недоступные диски. Другой возможной причиной ошибки может быть диск, который вы установили ранее и больше не подключен. Это может часто происходить с USB-накопителями, которые были установлены в режиме сквозной передачи, и в этом случае виртуальная машина ищет диск, но не может его найти. Если этот случай применим к вам, вам придется удалить физический диск из настроек виртуальной машины.
- Системные ресурсы. Наконец, проблема, которая может вызывать эту проблему, иногда может быть связана с ресурсами вашей системы. Бывает так, что когда в вашей системе не хватает ресурсов, виртуальная машина навсегда застревает в сохраненном состоянии. Поэтому в таком случае решение — удалить виртуальную машину, но не волнуйтесь, вы не потеряете свои данные.
С учетом вышесказанного, теперь мы можем перейти к возможным решениям, которые помогут решить вашу проблему. Итак, приступим.
Решение
Метод 1: удалить сохраненное состояние
Первое, что вам нужно сделать в случае зависания сохраненных состояний, — это удалить сохраненное состояние и затем запустить виртуальную машину. Удаление сохраненных состояний не приведет к потере данных, так что вам не о чем беспокоиться. На самом деле он ведет себя так, как будто вы внезапно потеряли питание, и вы сможете сразу загрузиться. Удаление сохраненного состояния настолько просто, насколько это возможно. Следуйте инструкциям ниже, чтобы удалить сохраненное состояние:
- Прежде всего откройте диспетчер Hyper-V.
- Щелкните правой кнопкой мыши виртуальную машину, на которой возникла проблема, чтобы открыть раскрывающееся меню.
- Оттуда нажмите на опцию Удалить сохраненное состояние.Удаление сохраненного состояния
- После удаления сохраненного состояния попробуйте снова запустить виртуальную машину.
- Если вы столкнулись с ошибкой типа «Операция не может быть выполнена, пока объект используется», перезапустите физический хост, и все будет в порядке.
3]Hyper-V не удалось разрешить имя сервера реплики.
То же, что и выше, но это явная ошибка. Если Hyper-V не может разрешить имя сервера реплики, вам необходимо проверить, используете ли вы NetBIOS или полное доменное имя. Если вы используете правильный формат, это проблема DNS. Вы должны связаться с DNS-сервером, чтобы узнать, почему он не может разрешить ожидаемый адрес сервера.
Метод 4: удалить виртуальную машину
Если ни одно из вышеперечисленных решений не сработало для вас, единственный оставшийся у вас вариант — удалить виртуальную машину, а затем создать новую. Тем не менее, мы позаботимся о том, чтобы вы не потеряли никаких данных, поэтому это не будет просто избавление от виртуальной машины с данными. Для этого вам нужно сначала скопировать VHD-файл виртуальной машины и где-нибудь сохранить. Давайте рассмотрим всю процедуру поэтапно, чтобы ее было легче выполнить.
- Прежде всего, скопируйте файл VHD виртуальной машины, на которой возникла проблема, а затем сохраните его в другом месте.
- После этого откройте диспетчер Hyper-V и удалите виртуальную машину. Для этого щелкните указанную виртуальную машину правой кнопкой мыши и выберите параметр Удалить.
- После удаления виртуальной машины скопируйте файл VHD в его старое расположение.
- После этого создайте новую виртуальную машину и при запросе виртуального жесткого диска выберите вариант «Использовать существующий виртуальный жесткий диск».Создание новой виртуальной машины
- Там выберите расположение сохраненного VHD.
- Завершите процесс создания виртуальной машины, и все будет хорошо.
2]Hyper-V не позволил запустить виртуальную машину, поскольку она подготовлена к аварийному переключению.
При настройке страницы Replica Server вам необходимо ввести NetBIOS или FQDN сервера Replica. Если сервер реплики является частью отказоустойчивого кластера, введите имя брокера реплики Hyper-V.
Сведения об исправлении
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте данное исправление только в тех системах, которые имеют данную проблему.
Если исправление доступно для скачивания, имеется раздел "Пакет исправлений доступен для скачивания" в верхней части этой статьи базы знаний. Если этого раздела нет, отправьте запрос в службу технической поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание посетите следующий веб-узел корпорации Майкрософт:
Примечание. В форме "Пакет исправлений доступен для скачивания" отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Для установки этого исправления необходимо иметь , установленной в Windows Server 2012 R2 или Windows 8.1.
Сведения о реестре
Для использования исправления из этого пакета нет необходимости вносить изменения в реестр.
Необходимость перезагрузки
Может потребоваться перезагрузить компьютер после установки данного исправления.
Сведения о замене исправлений
Это исправление не заменяет ранее выпущенные исправления.
Глобальная версия этого исправления устанавливает файлы с атрибутами, указанными в приведенных ниже таблицах. Дата и время для файлов указаны в формате UTC. Дата и время для файлов на локальном компьютере отображаются в местном времени с вашим текущим смещением летнего времени (DST). Кроме того, при выполнении определенных операций с файлами, даты и время могут изменяться.
Сведения о файлах Windows 8.1 и Windows Server 2012 R2 и заметки
Важно. Windows Server 2012 R2 исправления и исправления Windows 8.1 включаются в тех же самых пакетов. Однако исправления на странице запроса исправлений перечислены под обеими операционными системами. Для получения пакета исправлений, который применяется к одной или обеих операционных систем, установите исправления, перечисленные в разделе «Windows 8.1/Windows Server 2012 R2» на странице. Всегда смотрите раздел "Информация в данной статье относится к следующим продуктам" статьи для определения фактических операционных систем, к которым применяется каждое исправление.
Файлы, относящиеся к определенному продукту, этапу разработки (RTM, SPn) и направлению поддержки (LDR, GDR) можно определить по номерам версий, как показано в следующей таблице.
Выпуски обновлений GDR содержат только те исправления, которые выпускаются повсеместно и предназначены для устранения распространенных критических проблем. В обновления LDR входят также специализированные исправления.
Файлы MANIFEST (.manifest) и MUM (.mum), устанавливаемые для каждой среды, указаны отдельно в разделе "Сведения о дополнительных файлах". MUM, MANIFEST и связанные файлы каталога безопасности (.cat) очень важны для поддержания состояния обновленных компонентов. Файлы каталога безопасности, для которых не перечислены атрибуты, подписаны цифровой подписью корпорации Майкрософт.
Читайте также: