Vmware workstation and hyper v are not compatible ошибка
Обновлено: 05.07.2024
Ошибка VMware Workstation and Device/Credential Guard are not compatible
При включении VMware Workstation на Windows 10 может возникнуть ошибка со следующим текстом:
Чаще всего эта ошибка возникает из-за того, что включено ПО Device Guard — оно помогает защитить систему от вредоносных файлов. Device Guard позволяет настроить список файлов, которые Windows будет считать безопасными. Если на компьютер попадут файлы, которые не входят в список, система автоматически удалит их. Работе VMware в таких случаях мешает компонент Hyper-V.
Чтобы отключить Hyper-V, необходимо внести изменения в реестр Windows. Перед отключением Hyper-V обязательно создайте резервную копию ОС. В поисковую строку введите «gpedit.msc» и нажмите Ок. Перейдите в раздел «Политика Локальный компьютер» — «Конфигурация компьютера» — «Административные шаблоны» — «Система» — «Device Guard». Дважды кликните на строку «Включить средство обеспечения безопасности на основе виртуализации». В новом окне выберите пункт «Отключено» и нажмите Ok. Перейдите в раздел «Панель управления» — «Программы и компоненты» — «Включение или отключение компонентов Windows». Отключите Hyper-V и нажмите Ок. Если система предложит перезагрузить компьютер, откажитесь от перезагрузки.Откройте командную строку от имени администратора. Поочередно выполните команды:
Затем перезагрузите компьютер.
Ошибка Cannot open the disk
Ещё одна распространенная ошибка при запуске виртуальной машины в VMware — Cannot open the disk. Её текст следующий:
На следующей строке будет указана одна из причин этой ошибки. Разберём, что означает каждая:
1) Failed to lock the file. Это значит, что процесс, который вы используете, не может открыть файл. При этом файл используется другим процессом. Что может привести к ошибке:
- при работе с ВМ вы пытаетесь запустить вторую ВМ, используя тот же VMX-файл,
- вы запустили ВМ с подключенным диском при помощи утилиты vmware-mount,
- вы добавили виртуальный диск к ВМ, которая уже используется.
2) The parent virtual disk has been modified since the child was created. Эта ошибка возникает, если повреждён снимок ВМ.
3) The destination file system does not support large files означает, что на целевом хранилище невозможно открыть файл ВМ того же размера.
4) Could not open/create change tracking file. Эта проблема может возникнуть, если файл filename-ctk.vmdk создавался ранее и не очищался перед созданием новой ВМ. Здесь filename — это название вашего файла.
5) Cannot allocate memory. Тот случай, когда в модуле VMFS не хватает места.
6) The file specified is not a virtual disk возникает в случаях, если повреждён .VMDK-файл дескриптора.
7) Insufficient permission to access file. Такая проблема может возникнуть при использовании хранилищ типа NFS. Она сообщает о том, что экспорт NFS работает неправильно, так как права на чтение и запись файла не даны либо даны некорректно.
Единого решения для этого типа ошибки нет. Чаще всего причина связана с локальными настройками компьютера. Рекомендации по исправлению ошибки описаны в официальной документации.
После очередных обновлений от Windows 10 у многих пользователей VM Ware Workstation при первом запуске созданной VM возникает вот такая ошибка. В окошке размещена ссылка на базу знаний WM Ware по этой проблеме. В базе знаний я нашел видео и ответы, как решить проблему, но все на английском языке.
Исправляем vmware workstation and device/credential guard are not compatible
На деле они просто продвигают свою Hyper-V, потому как получается, что вы будете пользоваться либо Hyper -V, либо VM Ware Workstation Pro. Хотя, не исключено,что в более поздних версиях разрабы учтут этот баг и гипервизор будет работать без ошибок. Итак, что нам рекомендуют в базе знаний? Сначала проверяем настройку групповых политик безопасности для виртуализации. Нажимаем Win+r и вводим команду gpedit.msc
Отключаем данную политику:
- bcdedit /create /d "DebugTool" /application osloader
- bcdedit /set path "\EFI\Microsoft\Boot\SecConfig.efi"
- bcdedit /set bootsequence
- bcdedit /set loadoptions DISABLE-LSA-ISO,DISABLE-VBS
- bcdedit /set hypervisorlaunchtype off
После всех манипуляций в вашей командной строке результаты должны быть такие:
Некоторое время назад появилось у меня желание потестировать Hyper-V, а подходящего железа под это дело не было. Я решил попробовать установить в качестве гостевой системы VMware Workstation 10 Windows Server 2012 и на нем поднять роль Hyper-V.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Сам конфиг живет в папке с виртуальной машиной и имеет расширение .vmx Находим этот файл, открываем блокнотом и дописываем в конец эти три строчки. У некоторых уже после этого роль Hyper-V добавляется. Я тоже решил попробовать, внес изменения, загрузил гостевую машину, добавляю роль Hyper-V, но получаю новую ошибку:
Тут я расстроился, решил что мой процессор не поддерживает подобную виртуализацию. Начал дальше разбираться, искать информацию. Для того, чтобы виртуализация работала в виртуальной среде, процессор должен поддерживать технологию Intel VT или AMD-V и EPT. У меня какой-то старенький i5, но я нашел к нему описание и убедился, что Intel VT и EPT он поддерживает. Как мне показалось, все современные i3-i5-i7 поддерживают эту технологию. Оказывается, нужно в настройках гостевой ОС принудительно указать процессору использовать эту технологию. Делается это вот где:
После изменения настроек запускаем гостевую систему и добавляем роль Hyper-V. Все должно получиться.
В итоге у нас получилось установить Windows Server 2012 с ролью Hyper-V в виртуальной машине под управлением VMware Workstation 10.
Промежуточный релиз Workstation Pro 15.5.5, вышедший на днях, в целом, ничем особенно примечательным не отличается, если ни считать одного важного нововведения, которого пользователи ждали очень и очень давно. Microsoft и VMware, наконец, смогли найти общий язык.
Теперь VMware Workstation может нормально работать на Windows-машинах с активированными функциями, которые используют Hyper-V.
Система виртуализации Hyper-V изначально появилась в Windows Server 2008, а затем стала одним из базовых компонентов всех последующих версий серверной ОС от Microsoft, попутно попав и в Pro- и Enterpise-редакции Windows 8/8.1/10, где заменила Windows Virtual PC. Hyper-V, помимо понятных функций вроде Windows Sandbox или WSL 2, используется и для компонентов безопасности на основе виртуализации (Virtualization-based Security, VBS), таких как Credential Guard и Device Guard.
VMware Workstation исторически использовала собственный Virtual Machine Monitor (VMM), работающий непосредственно с CPU и его функциями аппаратной виртуализации. Однако, как поясняют сами разработчики VMware, активация VBS приводит к появлению прослойки гипервизора Hyper-V между аппаратным обеспечением и самой Windows, что делает невозможным прямой доступ к аппаратной виртуализации CPU. Эта проблема касается не только VMware, но и аналогичных продуктов от других разработчиков.
Выходом стало использование нового набора API Windows Hypervisor Platform (WHP). Теперь VMware Workstation автоматически определяет, активен ли в системе Hyper-V. Если нет, то используется привычная работа напрямую с CPU, а если да — вся работа проводится посредством WHP. Для работы новой версии требуется процессор поколения Sandy Bridge/Bulldozer или более новый, а также Windows 10 20H1 (сборка 19041.264).
Читайте также: