Можно ли удалить файл hrl hyper v
Как старший программный менеджер в группе 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 можно не пользоваться, если вы меняете параметры виртуальной машины с помощью консоли диспетчера отказоустойчивых кластеров. Для изменения параметров виртуальной машины в этой консоли сделайте следующее:
- в консоли диспетчера отказоустойчивых кластеров откройте раздел Services and Applications, затем щелкните по виртуальной машине, для которой хотите изменить параметры;
- в окне Actions щелкните мышью на кнопке Settings, чтобы изменить параметры виртуальной машины.
Сбои в работе Hyper-V
В Windows Server 2012 появилось интересное решение, предназначенное для обеспечения высокой доступности и аварийного восстановления виртуальных машин. Это решение называется Hyper-V Replica и с его помощью можно осуществлять репликацию виртуальных машин между хостами или кластерами Hyper-V.
Суть Hyper-V Replica (HVR) состоит в наличии регулярно обновляемой копии (реплики) виртуальной машины. Технически это выглядит как две площадки с серверами Hyper-V — основная (primary site) и резервная (replica site). При возникновении проблем с основной площадкой (потоп, пожар, отключение электричества или ядерная война) реплику можно активировать, что дает возможность оперативно восстановить работоспособность виртуальной машины в случае аварии.
Hyper-V Replica может использоваться в различных сценариях, например для репликации виртуальных машин между головным офисом компании и ее филиалами, или между офисом клиента и датацентром провайдера. Для Hyper-V Replica абсолютно не важно местоположение серверов. Репликация возможна как между серверами Hyper-V в одной локальной сети, так и между датацентрами, расположенными в разных странах. При этом Hyper-V Replica фактически не зависит от хранилища и предъявляет минимальные требования к пропускной способности сети.
Архитектура
Архитектурно Hyper-V Replica состоит из следующих компонентов:
• Hyper-V Manager UI — интерфейс Hyper-V Manager;
• Failover Cluster Manager UI — интерфейс Failover Cluster;
• Scripting — модуль Hyper-V для управления репликацией с помощью PowerShell;
• Hyper-V Replica APIs — программный интерфейс, может использоваться сторонними управляющими приложениями;
• Remote Management — средства удаленного управления (RSAT).
Безопасность
Одним из плюсов технологии Hyper-V Replica является то, что нахождение основного сервера и сервера-реплики в одном домене/рабочей группе не является обязательным. Если вы используете репликацию между некластерными узлами, то членство в домене совсем не обязательно (для кластеров, естественно, домен необходим). В связи с этим стоит затронуть некоторые вопросы безопасности:
Примечание. По умолчанию трафик репликации не шифруется. Хотя в Kerberos и есть механизм шифрования, HVR его не задействует. Поэтому, если требуется шифрование, необходимо использовать аутентификацию на основе сертификатов.
Принцип работы
Сначала между основным сервером и репликой устанавливается соединение и производится первоначальная репликация (Initial Replication), в ходе которой на резервной площадке создается реплика виртуальной машины. Реплика находится в выключеном состоянии и по умолчанию не подключена к виртуальной сети.
Затем в дело вступает механизм Delta Replication. На основном узле все изменения, происходящие с VHD-дисками соответствующей ВМ отслеживаются и записываются в лог репликации (Hyper-V Replica Log file, HRL). Это файл с расширением .hrl, находящийся в той же директории, что и VHD. Каждому VHD ставится в соответствие свой HRL-файл, каждая операция записи в виртуальной машине соответствует записи на VHD и записи в HRL.
Примечание. Реплицируются лишь дисковые изменения, состояние памяти ВМ не затрагивается.
Периодичность передачи данных составляет 5 минут, изменить ее нельзя. Таким образом, в нормальном состоянии копия машины отстаёт от оригинала не более чем на пять минут. Если же в течение 5 минут не удалось передать изменения, то в состоянии репликации появится предупреждение. Попытки передать изменения будут продолжаться еще 25 минут, а затем репликация остановится и перейдет в аварийное состояние. После этого для восстановления работы репликации потребуется вмешательство администратора.
Вот так в общих чертах выглядит технология Hyper-V Replica в Windows Server 2012. Более подробно о настройке репликации я расскажу во второй части статьи.
In this article, we will show you how to remove lingering Hyper-V replica logfile from a Virtual Machine that was not properly removed after removing VM Replication on Windows Server 2016 Hyper-V.
The same will apply whether you are using Windows Server 2019 or a later release.
In This Article
Introduction
Sometimes things go wrong with Hyper-V Replica. There are many reasons for this, but one of the reasons is when you are running out of disk space on the replica side.
Are you monitoring your Hyper-V Replica infrastructure? If not, then make sure to check this article: .
A little bit of context on how Hyper-V replica works behind the scene, Hyper-V replica creates checkpoint (.avhdx) to handle the initial replication of the virtual machine (for example when getting the first copy of the virtual machine across the replica host). Hyper-V Replica will merge this disk out once it has successfully made a full copy of the virtual machine, virtual hard disk (which can take a while).
As you can see in the above screenshot, the replication is not enabled for this virtual machine, in fact, I removed all replication using the Remove-VMReplication cmdlet when the replication health was in a critical state.
If we look at the virtual hard disk files of the VM, we see the traces of a Windows Server 2012R2 Hyper-V replica (HRL Hyper-V replica log).
Did you notice the HRL file size is large 32 GB?
A quick overview of HRL
Once the initial replication of a VM is completed, Hyper-V Replica will start monitoring the changes of each selected virtual hard disk. This is done by mirroring the changes to a Hyper-V Replica Log (HRL) file. The HRL files are kept in the same directory where Virtual Machine VHDX files reside. Each VHDX file, which has been selected for the replication, has an associated HRL file. The changes are tracked at the Virtual Machine level e.g. any changes (write operations) to the virtual machine are tracked and stored in the Hyper-V Replication Log files.
Once the replicas/HRL files are ready, “Replication Manager” notifies “Replication Tracker” (RT) to send the copies to the Replica Server. The changes are tracked on the Primary Server and the Change Tracking component has no function on the Replica Server!
The question is why the size of the log file (.HRL) is growing from MBs to GBs? if you want to identify the guest processes that cause large log files, then make sure to download (Hyper-V Replica Identify Script) from TechNet and run it inside the guest OS, this script provides debugging information that will help you to identify what is going on in the guest that causes large log files in Hyper-V Replica.
As Best Practice, please make sure to create a new VHD(x) file, one for each VM, and move the paging files to those volumes. when you set up Hyper-V replication, do NOT select the box next to that volume.
Also, if you have any VM that hosts SQL Server, then move the TempDB files to a separate VHD(x) file as well, and don’t replicate that one, because every time you start a new server or new SQL instance, the paging files and Temp DBs are empty, so nothing is lost if you failover to the replica side.
If you look at all the remaining HRL files on the host, we can see around 81GB of disk space.
Remove Lingering Hyper-V Replica
You can delete each HRL log file manually as long as the VM replication is removed.
PowerShell to the rescue!
Here is another PowerShell snippet to delete older lingering HRL files due to past issues and keep the current ones so the Hyper-V replica won’t break:
As a side note: If you are backing up virtual machines running on Windows Server 2016 Hyper-V or later, you will see two new files, the MRT (Modified Region Table) file, and RCT (Resilient Change Tracking) which keep track of all the changed blocks and travel with each (VHDX/AVHDX) if a virtual machine is moved to another Hyper-V host or to another storage.
If you come across a scenario where you want to delete the MRT and RCT files, then you can use the same script described above to remove unused MRT/CRT files as well. However, in a normal situation, you should not touch those files as long as the virtual machine is protected by a backup application such as (DPM, VEEAM, etc.). The size of the MRT and RCT files is very small less than < 100 KB.
Conclusion
Keep monitoring your Hyper-V Replica / Backup and start removing the lingering HRL log files and free up some disk space.
Do you want to know more about RCT and MRT files in Windows Server 2016 Hyper-V including backup architecture and the difference between different versions? I strongly recommend checking my recent published book Windows Server 2016 Hyper-V Cookbook – Second Edition!
Добрый день!
Неконтролируемо разрастается жёсткий диск виртуальной машины сервера Exchange 2010.
Сам сервер стоит на win2008 r2. Hyper -V на win 2012r2.
За последние два дня диск вырос более чем на 100Gb, хотя почтовая база данных на данный момент весит 236Gb.
На диске C:\ почтовика, занято 365 Gb
А виртуальный диск почтовика весит 388 Gb
Есть ещё два файла .avhd по 19.4 и 51.2 Gb
И файл .hrl 64 Gb.
Судя по дате изменения разрастается именно он.
Кслову, квоты на ящики не установлены. На базу установлены огромные квоты, человеком который развернул сервер до меня.
Подскажите пожалуйста куда копать?
Ответы
Дико извиняюсь! Наврал в расширении.. Не vhdx файл а файл avhd! Файл снимка появляется при репликации и растёт.
Если у Вас была остановлена реплика, то avhd может создаваться , но после того, когда реплика повторно синхронизируется, то он сливается с vhd Вашей ВМ.
Если нет доп. настроек на Recovery points, то никаких доп-х файлов не должно быть. Если Recovery points настроены, то в папке реплики будут доп. файлы с расширением .hru
Если реплика не в "рабочем" статусе, то запустите:
Все ответы
avhd - это чекпойнты Вашей ВМ. можно их слить в VHD(x), если Вам откат не пригодится (в рамках Exchange - это маловероятно и не рекомендуемо,насколько знаю)
hrl - логи hyper-v replica
И всё же почему появился файл снимка если снимков нет, и почему он разрастается если идёт репликация только изменений?
Я удалил репликацию у этой виртуальной машины, запустилось слияние, и все файлы кроме самого диска исчезли.
Потом снова настроил репликацию на другой сервер, и в папке снова появился файл avhd, который по мере прогресса репликации растёт.
Recovery points для ВМ. У Вас при реплике только последний point делается или дополнительные настроены тоже? Можете посмотреть:
Это к Вашей теме особо не относится. Нужна реплика - делайте (хотя для Exchange обычно Full Backup делают, что, кстати, и сказывается на Transaction logs)
Растет ведь сам вирт.диск ВМ Exchange. Реплика - это hrl + avhd (дополнительные).
Настроены только последние точки, никаких дополнительныйх. Сначала отправляется начальная копия машины на сервер реплику, а потом туда капают изменения.
Появление и рост avhd и hrl файлов -это нормально в данной ситуации?
Командлет не выполняется не для одной машины, пишет что не удалось найти вм с именем **
Настроены только последние точки, никаких дополнительныйх. Сначала отправляется начальная копия машины на сервер реплику, а потом туда капают изменения.
Появление и рост Vhdx и hrl файлов -это нормально в данной ситуации?
Командлет не выполняется не для одной машины, пишет что не удалось найти вм с именем **
hrl файлы - это журнал транзакций (~1 hrl:1vhd), которые передаются на сервер реплики для объединения с VHD на "копии ВМ". Поэтому их появление - это by design.
Рост самого VHDX (основной вирт.диск для ВМ с Exchange не на сервере реплики) - уже предположил чуть выше. Логи у Exchange могут довольно много съедать (увы, я в нем не Pro , но на практике встречался).
Предыдущие версии гипервизора от MS (идущие в комплекте с Windows 2008 и Windows 2008 R2) обрабатывали удаление снимков виртуальных машин достаточно криво – необходимо было сразу после удаления снимка выключать виртуальную машину. В процессе выключения данные из снимка объединялись с родительским файлом vhd или avhd. Понятно, что после удаления снимка выключать виртуальную машину не всегда было возможно. В итоге могло быть несколько удалённых снимков, которые так и не были объединены в родительский файл. И вот в этот момент слияние всех этих оставшихся файлов превращалось в настоящий квест.
Относительно недавно стал доступен дистрибутив для разработчиков следующей версии Windows Server со следующей версией гипервизора на борту. Вот тут в комментариях Александр Станкевич задал интересный вопрос – “Раз уж появились различные “живые сценарии”, то и слияние (Merge) дисков, после удаления Snapshot’ов, теперь будет выполняться без необходимости выключения виртуальной машины?”
Вроде бы пока я не видел чтобы это утверждение кто-то проверил – так что, возможно, буду первым.
Что у нас имеется – свежеустановленная операционная система Windows Server 8 Developer Preview с ролью Hyper-V. Далее подключаем её в качестве хоста к VMM 2008 R2 (подключается!) и заливаем из библиотеки виртуальную машину. Так получилось, что это оказалась Windows 2003. Далее ставим разное ПО чтобы можно было сделать пару снимков, которые бы друг от друга немного отличались. В итоге получаем следующее. Имеется 2 снимка:
Физически они все три состояния виртуальной машины представляют три файла:
Первый файл – 2003std86.vhd – представляет собой состояние виртуальной машины на момент создания снимка “with Outlook”, второй файл представляет собой изменение состояния виртуальной машины на момент создания снимка “win2003test”, ну и в третьем файле находится изменение состояния виртуальной машины на текущий момент со времени предыдущего снимка.
Логично предположить, что если мы будем удалять второй снимок – то в его файл должно вставиться изменение состояния виртуальной машины из третьего файла. Если будем удалять только первый снимок – то второй файл будет объединён с первым. Попробуем удалить снимок “win2003test”. После удаления в поле статуса виртуальной машины появится текст “Merge in Progress”:
По завершении объединения в папке виртуальной машины у нас будут находиться следующие файлы:
Видно, что третий файл был объединён со вторым, за счёт чего последний стал чуть больше. Ну и для закрепления удалим оставшийся первый снимок “with Outlook”. Опять в поле статуса виртуальной машины появится “Merge in Progress” и по завершении у нас останется только один файл:
Уточню, что я виртуальную машину не выключал и процесс слияния файлов происходил во время работы виртуальной машины. На первый взгляд – виртуалка немного подтормаживала – но утверждать этого не буду, могу ошибиться.
Читайте также: