Hyper-V, родная для систем Windows – в её серверных выпусках, а также в некоторых десктопных версиях и редакциях – среда для работы с виртуальными машинами и их гостевыми ОС не всегда работает без проблем. Одной из таких проблем может быть выскакивающее при запуске виртуальной машины уведомление, что, мол, Hyper-V не удаётся её запустить, поскольку не выполняется некая низкоуровневая оболочка.
Что это за ошибка, и как её исправить.
Окно с такой ошибкой является универсальной трактовкой, причина может крыться в нескольких вещах.
Системные требования
Если сама Windows не соответствует требованиям для работы с Hyper-V, а десктопные выпуски не все позволяют работать с этим компонентом, он попросту не активируется в системе. Но есть ещё аппаратные требования. Их несоответствие может не влиять на активацию гипервизора, но в дальнейшем стать причиной появления такой ошибки.
Для работы Hyper-V необходимо:
• Не менее 4 Гб RAM;
• 64-битный процессор с поддержкой SLAT и технологии виртуализации.
Хранилище BCD
Рассматриваемая ошибка может говорить о неверной конфигурации данных хранилища BCD. Компонент Hyper-V глубоко интегрирован в Windows и стартует до запуска ядра системы. Если в хранилище BCD вносились изменения для модификации запуска гипервизора, они могут быть неверными. Либо же запуск Hyper-V и вовсе был ранее намеренно отключён с целью временной оптимизации использования ресурсов компьютера. В таком случае конфигурацию BCD в части запуска гипервизора необходимо либо подкорректировать, либо вернуть дефолтное значение путём установки автозапуска Hyper-V. Для установки автозапуска открываем CMD от имени администратора (обязательно), вводим:
bcdedit /set hypervisorlaunchtype auto
После этого осуществляем перезагрузку.
AMD Bulldozer
Hyper-V не работает с процессорами компании AMD с архитектурой Bulldozer.
Технологии виртуализации
Для обеспечения жизнедеятельности среды виртуализации посредством любого гипервизора процессор должен быть обустроен технологией, обеспечивающей виртуализацию – Intel Virtualization, либо же AMD-V. О поддержке этих технологий можно узнать на страничке спецификаций процессора на сайтах, соответственно, Intel и AMD. И технология виртуализация, естественно, должна быть включена в BIOS.
Ещё один важный нюанс: для процессоров Intel в BIOS должны быть отключены специфические технологии Intel VT-d и Trusted Execution. С ними встроенный в Windows гипервизор не дружит. Вот примерно так должны выглядеть настройки BIOS для работы с Hyper-V: технология виртуализации включена, а специфические технологии – выключены.
Загрузка…
I had 2 VMs, and I could only get 1 to run at a time. When I booted the second VM, I got Event ID 18560, that says the VM “was reset because an unrecoverable error occurred on a virtual processor that caused a triple fault.”
System Configuration:
Hardware: Dell R710, 2xE5620 CPUs, 12x2GB UDIMMs, RAID1 via onboard controller
Host OS: Windows Server 2008 R2 Enterprise 64bit running the Hyper-V role, fully patched as of testing.
Guest OSes: 2 VMs both running Windows Server 2008 R2 Enterprise 64bit, 1CPU, 4GB RAM, 1 NIC, dynamic VHD on IDE Controller 0 (127GB max) each, fully patched as of testing.
Troubleshooting
Further troubleshooting using perfmon in Windows showed that VMs boot fine on cores 4-7, but not on 0-3. I had previously disabled logical processors in the bios so I didn’t have to troubleshoot 16 logical CPUs. At this point, I thought CPU0, or maybe just the hardware virtualization part of it, was bad.
I ran Prime95 (64bit) and the Intel Processor Diagnostic tool to test the CPU, but neither showed an issue with either CPU. I also ran Memtest86+ v4.20 which showed the memory to be fine. My line of thinking was that if Prime95 and the Intel CPU diag don’t access the hardware virtualization calls in the CPU, they may not find the fault I’m experiencing.
Resolution
After a brief online text chat with Greg Whiteman at Dell hardware support, he suggested that I disable Power Management (set it to Maximum Performance). That single change resolved the issue.
Conclusion
I changed the following setting from “Active Power Controller” to “Maximum Performance” and I was able to launch multiple VMs at once without Hyper-V crashing. I changed back to “Active Power Controller” and I could immediately reproduce the problem (Hyper-V crashing). I’m not sure where the bug lies (Windows Hyper-V implementation or hardware/firmware implementation), but this setting change fixed it.
Finally, to fully test, I set the following which I believe to be my final settings, and everything works fine.
Final Dell R710 BIOS Settings Used
Processor SettingsLogical Processor: “Enabled”
Processor SettingsVirtualization Technology: “Enabled”
Processor SettingsExecute Disable: “Enabled”
Processor SettingsTurbo Mode: “Disabled”
Processor SettingsC1E: “Disabled”
Processor SettingsC States: “Disabled”
Power Management: “Maximum Performance”
Full Event Details:
Log Name: Microsoft-Windows-Hyper-V-Worker-Admin
Source: Microsoft-Windows-Hyper-V-Worker
Date: 3/15/2011 5:50:02 PM
Event ID: 18560
Task Category: None
Level: Critical
Keywords:
User: NETWORK SERVICE
Computer: WIN-L4DCENF56H0
Description:
'testvm1' was reset because an unrecoverable error occurred on a
virtual processor that caused a triple fault. If the problem persists,
contact Product Support.
(Virtual machine ID 8CB72529-261D-4685-A118-F781F34CE986)
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Hyper-V-Worker"
Guid="{51DDFA29-D5C8-4803-BE4B-2ECB715570FE}" />
<EventID>18560</EventID>
<Version>0</Version>
<Level>1</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2011-03-15T22:50:02.132334800Z" />
<EventRecordID>370</EventRecordID>
<Correlation />
<Execution ProcessID="1148" ThreadID="3736" />
<Channel>Microsoft-Windows-Hyper-V-Worker-Admin</Channel>
<Computer>WIN-L4DCENF56H0</Computer>
<Security UserID="S-1-5-20" />
</System>
<UserData>
<VmlEventLog xmlns:auto-ns2="http://schemas.microsoft.com/win/2004/08/events"
xmlns="http://www.microsoft.com/Windows/Virtualization/Events">
<VmName>testvm1</VmName>
<VmId>8CB72529-261D-4685-A118-F781F34CE986</VmId>
</VmlEventLog>
</UserData>
</Event>
Are you stuck with hyper v error 18590? We can help you fix it.
This error occurs due to an interrupted power supply.
At Bobcares, we often get requests from our customers regarding Hyper-V errors as a part of our Server Management Services.
Today, let’s see how our Support Engineers help our customers resolve this error.
Why does Hyper V error 18590 occur?
A shutdown is triggered in the system without notifying the service in the server. During a clean shutdown, it works as by sending a signal to the service to turn off then Shutdown the machine.
If this process does not happen, the event is logged with the Event ID 18590.
One of the major reasons is because of the interrupted power supply. This can also occur due to hardware issues or due to server crash.
The logs in the Event viewer looks as:
Let’s discuss how our Support Engineers help our customers resolve it.
How we fix Hyper V error 18590
Recently one of our customers contacted us with this error. Now let’s discuss how our Support Engineers help our customers resolve it.
Power issue
One of the common reasons for the event ID in the log is because of the issue with the power supply.
When the power supply is down thus making the Virtual Machine Shutdown unexpectedly.
If the issue with the UPS attached to the Hyper-V servers, then we suggest our customers contact the UPS Manufacture. Also, we suggest them to make sure to use the UPS manufacture software correctly to handle the battery threshold level.
Firmware update for Hyper V error
Recently one of our customers contacted us saying that the server unexpectedly keeps shutting down and no power interruption is happening.
On further analyzing the issue, we found that Hyper-V servers are facing issues with a CPU microcode update. Thus to resolve the error we update the firmware to the latest one. Let’s discuss how our Support Engineers update the firmware for our customers.
1. Initially, we log in to the management interface. Then we go to Maintenance and select Firmware update.
2. Now we enable update mode by clicking the Enter Update Mode.
3. Then we upload the ZIP file. Now the screen will show the current and the newly added firmware. We confirm the version and click on Start Upgrade.
4. Once the update is complete the management interface will reboot. It will return back to the login screen.
After the firmware update, we monitored the servers. The Virtual Machine was stable after the update.
If the issue still persists we need to upgrade the Intel processors on the Hyper-V host server to resolve it.
Power control
Another solution to the error is to make changes to the power management settings in BIOS.
To make the changes in the settings we enter the BIOS. Then we select Power Management in BIOS.
We change all the systems from Active Power Controller to Maximum Performance.
Thus the CPU ready times drop to a normal level. This way we resolve the error.
[Need assistance to fix Hyper v errors – We can help you fix it]
Conclusion
In short, we have discussed the causes of the hyper v error 18590. Also, we have discussed how our Support Engineers help our customers fix it.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
GET STARTED
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;
Have you ever encountered the frustrating error message below when creating a Virtual Switch on Hyper-V?
Error applying Virtual Switch Properties changes
Failed while adding virtual Ethernet switch connections.
Attaching a virtual switch to an LBFO team is deprecated. Switch Embedded Teaming (SET) is an inbox replacement for this functionality. For more information on LBFO deprecation please see https://aka.ms/LBFODeprecation. To override this block, use the AllowNetLbfoleams option in New-VMSwitch.
If so, you’re not alone! This error can be a real headache for those looking to set up virtual switches using Hyper-V. But don’t worry; in this article, we’ll walk you through the steps to override this block and successfully create a virtual switch using Switch Embedded Teaming (SET) instead.
Let’s get started with the solution! First, we need to create a teaming of your network cards using the Server Manager. In my case, I’ll be using Switch Independent Teaming mode and Hyper-V Port Load balancing mode. By following these steps, we can ensure that our virtual switch is set up correctly and can provide the performance and reliability you need. Let’s dive in!
After completing the previous step, use the following PowerShell command to create a virtual switch based on the teaming you set up:
Code:
New-VMSwitch -Name "{Name your new vSwitch here}" -NetAdapterName "{NIC Team name you created previously}" -AllowNetLbfoTeams $true -AllowManagementOS $true
Next, navigate to the Virtual Switch Manager in the Hyper-V Manager to confirm that the vSwitch has been created successfully.
Congratulations, you’ve completed the steps to create a virtual switch using teaming in Hyper-V Manager! By following these simple steps, you’ll be able to improve the performance and reliability of your network connections. If you have any questions or encounter any issues along the way, don’t hesitate to reach out for assistance. Thanks for reading!
Ситуация следующая: виртуальная машина Hyper-V не может запуститься, выдавая при старте ошибку примерно такого содержания «VM failed to start. Synthetic SCSI controller (Instance ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx): Failed to Power on with Error ‘General access denied error’.».
Если развернуть окно и посмотреть детальную информацию об ошибке, то станет понятно, что проблема кроется в отсутствии доступа к файлу виртуального диска. Дело в том, что виртуальной машине (как и обычному пользователю) для работы с файлом необходимы NTFS-права на этот файл. В том случае, когда у виртуальной машины отсутствуют необходимые разрешения, то она не сможет стартовать и вывалится с ошибкой.
Как видно на рисунке, каждая виртуальная машина имеет свой уникальный идентификатор (Virtual machine ID). Для устранения ошибки надо взять этот ID и добавить его в список контроля доступа VHD-файла. Сделать это можно из командной строки, с помощью утилиты с неблагозвучным 🙂 названием Icacls. В нашем примере команда будет выглядеть так:
Icacls H:\Hyper-V\SRV1.vhdx /grant ″NT Virtual Machine\f72e624c-4cc2-4167-b852-a47d412de8440″:(F)
Этой командой мы выдали виртуальной машине права Full Control на файл. В этом можно убедиться, открыв свойства файла и перейдя на вкладку Security. Как видите, разрешения в порядке и теперь виртуальная машина должна успешно запуститься.
Примечание. Подобную операцию необходимо проделать для каждого vhdx, и, если у машины имеются моментальные снимки (checkpoint), то для каждого avhdx файла, имеющего отношение к данной ВМ.
В заключение опишу некоторые ситуации, которые могут привести к потере прав:
• Перенос файла виртуального диска в другое расположение. Напомню, что при переносе файла на другой диск разрешения файловой системы удаляются и заменяются наследуемыми. Избежать этого можно, перенося файлы виртуальных машин с помощью встроенных средств Hyper-V, таких как Storage migration или Export\Import;
• Копирование файла виртуального диска. Ошибка может возникнуть при попытке подсунуть виртуальной машине чужой диск. Поэтому для ″размножения″ лучше воспользоваться либо экспортом, либо, при наличии VMM, клонированием виртуальных машин;
• Восстановление ВМ из бэкапа. Некоторые программы резервного копирования, например тот же DPM, при восстановлении в другое расположение не выставляют на файлы нужные права.