.avhdx Расширение файла
This file is saved in a binary format, which requires a specific program to read its contents.
.AVHDX вариант №
Файл AVHDX представляет собой контрольную точку образа диска, используемую Windows Server и ее технологией Microsoft Hyper-V, которая загружает виртуальные машины (VM) с использованием образов дисков. Он содержит конфигурацию состояния, данных и оборудования виртуальной машины во время создания файла. Файлы AVHDX создаются для сохранения определенного состояния виртуального жесткого диска .VHDX .
Больше информации
Файлы AVHDX называются ссылочными дисками, потому что они используют другие диски для создания разностной цепочки дисков. Каждый файл AVHDX содержит момент времени, который используется для составления временной шкалы с другими файлами AVHDX в цепочке. Эти файлы позволяют виртуальной машине вернуться к предыдущему состоянию, что позволяет создать определенное условие для устранения неполадки.
У вас может возникнуть проблема, когда контрольная точка не может быть применена в Windows Server для возврата в состояние сохранения. Это может быть связано с нарушенной цепочкой контрольных точек или поврежденным файлом. Вы можете вручную объединить файлы AVHDX, чтобы исправить эту проблему, хотя это должен быть ваш последний вариант. Один из вариантов — объединить контрольные точки, создав новую контрольную точку, а затем разделив ее, что вынуждает Hyper-V автоматически сортировать ваши контрольные точки. Вы также можете экспортировать свою виртуальную машину и импортировать ее обратно в Менеджер Hyper-V. Прежде чем пытаться объединить файлы, вы должны создать резервную копию.
Microsoft Hyper-V позволяет создавать и управлять виртуальной вычислительной средой с использованием технологии виртуализации, встроенной в Windows Server. Hyper-V поставляется с инструментами управления и любыми необходимыми компонентами.
Common AVHDX Filenames
[имя файла VHDX] _ (серия букв и цифр, разделенных тире] .avhdx — это соглашение об именах файлов AVHDX. Они начинаются с имени файла VHDX, из которого они созданы, и который они содержат контрольную точку. Файлы AVHDX находятся в той же папке, что и файл VHDX, который является папкой «Виртуальные машины».
Сольются ли в один .vhdx несколько снимков .avhdx после выключения ВМ в Hyper-V v10.0?
Имеется Hyper-V версии 10.0 с виртуальной машиной DATA. В папке, где лежит образ жесткого диска DATA.vhdx (размер 47 гб) создались файлы .avhdx (один размером 60гб, второй, который является последней контрольным снимком, 326 гб). Вкурсе, что это контрольные снимки ВМ. Очевидно они занимают достаточно много месте и при время бэкапа значительно увеличивается. Есть несколько вопросов по этому поводу, возможно кто-то с этим уже сталкивался на практике:
1. В одной статье вычитал, что при выключении виртуальной машины данные .avhdx файлы должны слится в один .vhdx. Данный процесс слияния будет как то отображаться в диспетчере Hyper-v в виде выполняющего прогресса?
2. От чего настолько «раздулась» последняя контрольная точка (которая 326гб)? Почти в 8 раз относительно размера .vhdx. Я думаю, что «раздулся» он из-за восстановления из бэкапов папок — копировал из сетевого хранилища в ВМ DATA.
3. После объединения vhdx и avhdx размер останется 326 гб?
4. Какими еще способами можно избавиться от avhdx файлов? То что просто их удалить нельзя — в курсе
- Вопрос задан более года назад
- 1819 просмотров
Комментировать
Решения вопроса 1
у админа три руки
То что просто их удалить нельзя — в курсе
Удалить-то можно, но с ними удалятся изменения. Получите состояние машины на какую-то давнюю дату.
От чего настолько «раздулась» последняя контрольная точка
Хранит не просто актуальное состояние, а все изменения с некоторой даты. Чем больше изменений в файловой системе, тем больше размер этого файла.
Какими еще способами можно избавиться от avhdx файлов?
Ответ написан более года назад
kosyak_47 @kosyak_47 Автор вопроса
Вопрос по поводу раздутия ВМ: я так понимаю все что я восстанавливал из бэкапа из сетевого хранилища, все эти гигабайты данных зафиксировались в виде изменений в avhdx. Данные хранятся в неком буфере ВМ? Если я перезапущу виртуалку, объем не уменьшится до исходного?
kosyak_47 @kosyak_47 Автор вопроса
Еще я заметил, что на ВМ появился непонятный нераспределенный том в 200гб, хотя никаких доп. виртуальных жестких дисков к ВМ не подключались
все что я восстанавливал из бэкапа из сетевого хранилища, все эти гигабайты данных зафиксировались в виде изменений в avhdx
Видимо да. Насколько я знаю, перезапуск не поможет, нужно вручную отдать команду на слияние дисков.
появился непонятный нераспределенный том в 200гб
посмотрите в параметрах виртуальной машины; по идее там должны быть указаны все задействованные виртуальные диски.
Объединение Snapshot в Hyper-V
Правильное объединение снимков осуществляется через их удаление в консоли управления Hyper-V от самого старого к самому новому и перезагрузкой виртуальной машины. Если по каким-то причинам сделать это не возможно, то потребуется объединять снимки вручную.
- Изменяем расширение снимков виртуальной машины с *.avhd на *.vhd;
- Щёлкаем правой кнопкой мыши по гипервизору в диспетчере и открываем оснастку «Изменить диск» / «Edit Disk»;
- Далее кнопкой «Обзор» выбираем снимок сделанный позже всего (самый свежий снимок);
- Указываем «Объединить» / «Merge»; Щёлкаем по «К родительскому виртуальному диску»;
- Потом открывается информационное окно, в котором будет виден родитель объединяемого файла.
- Нажимаем «Готово» и процесс слияния будет запущен.
Если снимков несколько — повторите теже самые действия.
SKY — IT-решения для бизнеса, 2012–2023 г.
Приложение A. Архитектура и компоненты Hyper-V
Виртуализация не является новым свойством или технологией, которую любой решил иметь в своей среде сегодня ночью. на самом деле она достаточно древняя. В середине 60-х имелся ряд компьютеров, которые применяли виртуализацию, например, такие как IBM M44/44X , в которых могли исполняться множество виртуальных машин с применением абстракций оборудования и программного обеспечения. Она известна как первая система с виртуализацией и прородительница самого термина виртуальная машина .
Хотя Hyper-V переживает свою пятую версию, технология виртуализации Microsoft очень зрелая. Всё началось в 1988 году в компании с названием Connectix . Она имела такие инновационные продукты как Connectix Virtual PC и Virtual Server , эмуляцию программного обеспечения x86 для Mac, Windows и OS/2.
В 2003 Microsoft приобрёл Connectix и годом позже выпустил Microsoft Virtual PC и Microsoft Virtual Server 2005 . После целого ряда улучшений в архитектуре на протяжении проекта Viridian, Microsoft выпустил в 2008 Hyper-V, вторая версия появилась в 2009 (Windows Server 2008 R2), третья в 2012 (Windows Server 2012), а годом позже в 2013 была выпущена четвёртая версия (Windows Server 2012 R2), текущая версия под номером пять появилась в 2016 (Windows Server 2016).
В последние годы Microsoft доказал, что Hyper-V является сильным, конкурентоспособным решением для виртуализации серверов и предоставляет масштабируемую, гибкую инфраструктуру, высокие доступность и надёжность. Чтобы лучше понять различные модели виртуализации и то, ак создаются и управляются сами ВМ в Hyper-V, очень важно ознакомиться с его ядром, архитектурой и компонентами. Осуществив это, вы поймёте как он работает; вы сможете сравнить его с прочими решениями и легко выявлять неисправности.
Microsoft давно заявляла клиентам, что центры обработки данных Azur получают всю мощь от Microsoft Hyper-V и грядущий Azur Stack на самом деле позволит нам исполнять Azur в наших собственных центрах обработки данных поверх Windows Server 2016 Hyper-V.
Для получения дополнительной информации воспользуйтесь, пожалуйста, ссылкой: https://azure.microsoft.com/en-us/overview/azure-stack/.
за прошедшие годы Microsoft Hyper-V доказал, что он является масштабируемой платформой виртуализации любой и располагающейся где угодно рабочей нагрузки без каких либо исключений.
Данное приложение содержит хорошее объяснение наиболее важных компонентов архитектуры Hyper-V и сравнивает их с прочими версиями.
Общее представление о гипервизорах
VMM ( Virtual Machine Manager , Диспетчер виртуальных машин), также известный как Hypervisor (Гипервизор), является тем программным обеспечением, которое отвечает за исполнение множества ВМ в одной системе. Он также отвечает за создание, сохранность, деление, доступ к системе и управление ВМ на уровне Гипервизора.
Имеются следующие типы Гипервизоров:
- VMM 1 типа
- Гибридный VMM
- VMM 2 типа
ВММ 2 типа
Данный тип Гипервизора исполняется поверх имеющейся ОС. В основании у нас имеется оборудование, сама ОС и затем Гипервизор, работающий поверх них, как это отображается на следующей схеме:
Рисунок 1
Microsoft Virtual PC и VMware Workstation являются примерами программного обеспечения, которое применяет VMM 2 типа .
ВМ передают аппаратные запросы в Гипервизор, оттуда в ОС хоста и затем они наконец достигают самой аппаратуры. Это влечёт за собой ограничения на производительность и управление, вызываемые ОС хоста.
Тип 2 обычен для сред тестирования — ВМ с ограничениями оборудования — для исполнения прикладных программных средств, устанавливаемых в ОС самого хоста.
Гибридный ВММ
Когда мы применяем Гибридный тип VMM , Гипервизор работает на том же самом уровне, что и ОС, как это отображено на схеме внизу. Поскольку и Гипервизор, и ОС имеют один и тот же доступ к общим аппаратным средствам, причём с одним и тем же приоритетом, это не так быстро и безопасно, как могло бы быть. Этот тип применялся в предшественнике Hyper-V с названием Microsoft Virtual Server 2005 :
Рисунок 2
ВММ 1 типа
VMM 1 типа является той разновидностью, которая имеет Гипервизор исполняющимся в тонком программном уровне между оборудованием и имеющимися разделами (partitions), а также управляет и координирует (orchestrating) доступ к аппаратным средствам. ОС самого хоста, называемая Родительским разделом (Parent Partition), работает на том же самом уровне, что и Дочерний раздел (Child Partition), называемый ВМ, что отображено на схеме внизу. Благодаря привилегированному доступу к аппаратным средствам, который имеется у Гипервизора, ему предоставляется большие безопасность, производительность и управление, нежели имеется у всех разделов. Данный тип применяется Hyper-V начиная с его первого выпуска:
Рисунок 3
Архитектура Hyper-V
Знание того как работает Hyper-V и как построена его архитектура сделает для вас более простым понимание его концепций и действий. Последующие разделы изучат наиболее важные компоненты в Hyper-V.
Windows до Hyper-V
Прежде чем мы погрузимся в подробности архитектуры Hyper-V, будет проще понять что произойдёт после установки Hyper-V, взглянув на Windows без Hyper-V, что отображено на схеме внизу:
Рисунок 4
В установленном обычным образом Windows доступ инструкция подразделяется на четыре уровня привилегий в процессоре, называемых Кольцами ( Ring ). Наиболее привилегированным является Ring 0 , имеющий прямой доступ к оборудованию и именно в нём располагается Ядро (Kernel) Windows. Ring 3 отвечает за размещение пользовательского уровня и именно в нём исполняется большая часть приложений с наинизшим уровнем привилегий доступа.
Windows после Hyper-V
После установки Hyper-V ему необходимы более высокие привилегии, чем имеются у Ring 0 . Помимо этого он должен иметь выделенный доступ ко всему оборудованию. Это возможно благодаря новым возможностям самых последних создаваемых Intel и Amd процессоров, называемых Intel-VT и AMD-V, соответственно, которые позволяют создание пятого кольца с названием Ring -1 . Hyper-V применяет это кольцо для добавления своего Гипервизора, имеющего более высокие привилегии и выполняющегося под Ring 0 , управляющим всем доступом к физическим компонентам, как это отображает следующая схема:
Рисунок 5
Сама архитектура ОС претерпевает некоторые изменения после установки Hyper-V. Сразу после первой загрузки, файл Начальной загрузки операционной системы ( Operating System Boot Loader , winload.exe ) проверяет используемый процессор и загружает образ Гипервизора в -1 Кольцо (применяя соответствующие файлы Hvix64.exe для процессоров Intel и Hvax64.exe для процессоров AMD. Затем Windows Server устанавливается для работы поверх Гипервизора и все ВМ работают в нём.
После установки Hyper-V Windows Server имеет тот же самый уровень привилегий, что и ВМ и отвечает за управление ВМ с использованием различных компонентов.
Компоненты архитектуры Hyper-V
Hyper-V имеет множество компонентов, которые отвечают за предоставление решения повсеместного управления ВМ и свою ОС управления (Management OS). Приводимая ниже схема показывает наиболее важные компоненты Hyper-V, которые будут объясняться в последующих разделах:
Рисунок 6
Гипервизор
Небольшой Гипервизор Hyper-V (почти 20 МБ) отвечает за управление, отделение и контроль доступа к разделам (Partitions). Кроме того он отвечает за изоляцию всех разделов друг от друга в высокой безопасностью и надёжностью.
Разделы
При наличии Hyper-V сама ОС хоста и все ВМ исполняются и разделяют одни и те же доступ и привилегии в Гипервизоре и все они носят название Разделов (Partitions). Однако ОС хоста исполняет последовательности компонентов для управления своими ВМ и по этой причине имеет название Родительского раздела (Parent partition) или ОС управления , а ВМ называются Дочерними разделами (Child partitions) или Гостевыми ОС .
Стек виртуализации
Создание и исполнение ВМ осуществляется последовательностью виртуальных устройств и программных компонентов, имеющих название Стека виртуализации , который исполняется в Родительском разделе. Эти последовательности компонент работают совместно со своим Гипервизором.
VSP ( Virtualization Service Provider Поставщик службы виртуализации) является компонентом, который управляет запросами ввода/ вывода в основании данной ВМ в её Родительском разделе. VMBus ( Virtual Machine Bus , Шина виртуальной машины) отвечает за обмен данными, обслуживание и доставку устройств между разделами Родителя и Дочерними через выделенные каналы, доступные между VSP и VSCs ( Virtualization Service Clients , Виртуальными службами клиентов). VSP применяет VMBus для взаимодействия с Дочерними разделами используя VSCs для предоставления синтетических (искусственных) драйверов, исполняющихся в Дочерних разделах.
Для каждой запущенной ВМ в её Родительском разделе создаётся рабочий процесс (Worker process). Рабочий процесс и VMMS ( Virtual Machine Management Service , Служба управления Виртуальными машинами) являются компонентами режима пользователя, которые предоставляют Родительскому разделу ту самую возможность создания, запуска, останова, сохранения и удаления ВМ. Все эти задачи координируются VID ( Virtual Infrastructure Driver , Драйвером виртуальной инфраструктуры), который управляет взаимодействием между Родительским и Дочерними разделами.
Сопоставление Информированного (высокая производительность) и Эмулированного (низкая производительность)
Доступ между разделами и Гипервизором осуществляется специальным интерфейсом, имеющим название Гипервызовов (Hypercall). Это обеспечивает то, что все ВМ могут осуществлять доступ к оборудованию с использованием таких компонентов как VID, VMBus, VSCs и VSPs. Эти механизмы предоставляются в процессе установки ICs ( Integration Components , Компонентов интеграции). Некоторые операционные системы Windows и Linux имеют уже установленные в их Ядрах (Kernel) пакеты компонентов интеграции. Имеющие эти компоенеты ВМ имеют название Информированных ВМ ( Enlightened VM ). Для старых ОС или ОС не имеющих такой поддержки, сам Родительский раздел перехватывает взаимодействие ВМ, эмулируя все Гипервызовы. Результатом является более низкая производительность, поскольку ОС управления требуется работать в качестве моста чтобы сделать возможным доступ всем ВМ к имеющемуся оборудованию. Именно поэтому очень важно чтобы все имеющиеся ВМ работали с самой последней версией IC.
Улучшения резервного копирования
В Windows Server 2016 Hyper-V, Microsoft сделал достаточно значительные изменения в имеющуюся архитектуру резервного копирования. Они дают Hyper-V такую поддержку, что любой, включая партнёров резервного копирования, может осуществлять запросы к WMI Hyper-V и запрашивать моментальные снимки VSS ( Volume Shadow Copy Service , Службы теневой копии тома) для любой ВМ, а затем двигаться далее и сделать независимым весь процесс резервного копирования.
В Hyper-V Windows Server 2016 вся архитектура резервного копирования выглядит аналогично приводимой ниже схеме:
Рисунок 7
Как вы видите на схеме, внизу у нас имеется наш хост Hyper-V; приложение резервного копирования вначале вызывает WMI Hyper-V для получения всех ВМ, для которых оно желает выполнить резервное копирование в любом Наборе бекапов и затем данное приложение резервного копирования вызовет VSS и VDS ( Virtual Disk Service , Службу виртуального диска) для организации (orchestrate) отдельного моментального аппаратного снимка в сервере хранения. Основная цель здесь состоит в получении модели, при которой вне зависимости от того, сколько у вас имеется ВМ, а ткаже вне зависимости от имеющегося у вас масштаба она не должна оказывать воздействие на вашу систему.
Если мы сравним резервное копирование с предыдущим редакциями Hyper-V, имелось два возможных варианта осуществления моментальных снимков:
- Первый состоял в моментальном снимке данной ВМ, а второй заключался в снимке на основании оборудования, причём эти две операции были тесно взаимосвязаны, поэтому вы не могли выполнять одну, не осуществляя другую. Однако в Hyper-V Windows Server 2016 все приложения резервного копирования затрачивают тот же самый промежуток времени, который необходим для получения Набора ВМ (Set of VM) с согласованными данными, а затем осуществлять аппаратный моментальный снимок как отдельную операцию, что является основным изменением в Windows Server 2016.
- Вторым улучшением, над которым работает Microsoft являпется новая технология с названием RCT ( Resilient Change Tracking , Эластичное отслеживание изменений) и MRT ( Modified Region Table , Таблица изменённой области).
Для RCT и MRT имеются две цели. Первая состоит в улучшении резервного копирования всех предыдущих архитектур Hyper-V, что имело результатом полное резервное копирование всех виртуальных жёстких дисков данных ВМ, что означает, что всякий раз, когда вы выполняете резервное копирование (ежедневное, выполняемое каждый час или какое- либо другое), все данные отправляются через сетевую среду всякий раз и всегда, причём эта архитектура не может достаточно хорошо масштабироваться. Следовательно, чтобы избежать отправки всех необходимых даныых через имеющуюся сетевую среду, все производители резервного копирования, в настоящее время, реализуют фильтрацию файловой системы для отслеживания изменений блоков в данном хранилище, однако наличие сторонних фильтров файловой системы в ядре ОС хоста является потенциально приводящей к крушению системы ошибкой, а вторая проблема будет воздействовать на профилирвоание производительности хранилища. В Windows Server 2016 Microsoft построил некоторую систему, в которой у вовсе вас нет нужды помещать какой- либо фильтр файловой системы, имеется расширенный период времени, в течени и которого все ВМ будут исполняться с файлами .avhdx , или дисками приращений, причём Microsoft старается подавить воздействие этого на производительность.
В Windows Server 2016, Microsoft предоставляет естественное отслеживание изменение блока как некоторую часть всей платформы. При помощи RCT и MRT он может получать таблицу размещения блоков, которая имеется в каждом файле виртуального жёсткого диска ( .VHDX ), а также хранить отслеживание всех изменённых блоков; однако они не записывают эти данные, поскольку конкретное приложение резервного копирования имеет ещё где-то копию первоначальных данных, что тем самым предотвращает двойное копирование таких данных. Величайшее достижение RCT и MRT состоит в том, что они тесно вплетены в файл VHDX; таким образом, где бы не существовал этот файл, они остаются вместе с ним, что очень очень удобно когда дело доходит до сценариев мобильности ВМ и устойчивости к разрушению файла VHDX.
Файл MRT записывается в режиме сквозной записи и применяет крупную грануляцию отслеживания; в то время как файл RCT имеет более тонкую грануляцию и применяет обычную запись. Режим сквозной записи (write-through) обеспечивает даже в случае внезапной утраты электропитания сам файл MRT всё ещё будет иметь надлежащую запись того, что было изменено на данном диске. Файл RCT имеет более тонкую гранулированность (16k)для лучшего соответствия сценарию, необходимому на протяжении обычных действий. Эти файли были разделены для улучшения общей производительности хранения. Весь файл RCT не будет превышать 6 МБ, а файл MRT не будет расти выше 76 кБ.
Следующий снимок экрана отображает отслеживание изменения блока в Hyper-V Windows Server 2016 в процессе операции резервного копирования:
Рисунок 8
Имеются два важных момента применения VHDX, о которых следует знать, если вы планируете исполнять ВМ с VHD вместо VHDX в Windows Server 2016, поскольку если ваша ВМ имеет версию 5.0, тогда вы не получите каких- либо преимуществ от поддержки RCT. Применение ВМ с настройкой версии 5.0 может иметь место на хостах, работающих под управлением Windows Server 2012 R2 и 2012 R2, которые не поддерживают RCT; поэтому если вы находитесь в любой из этих ситуаций, вы получите воздействие на производительность в процессе резервного копирования, поскольку Microsoft в данном случае не будет применять RCT и вместо этого будет использовать диск приращений (аналогично Windows Server 2012 R2). Microsoft также поддерживает резервное копирование для гостевых кластеров в Windows Server 2016 с применением инфраструктуры RCT, причём гостевые кластеры являются группами ВМ, совместно использующими виртуальные жёсткие диски. Однако, для того чтобы осуществлять это, Microsoft ввёл новый формат файла с названием VHDX (VHD Set) VHDS является очень маленьким файлом, который имеет целую пачку файлов .avhdx , сопровождающих его.
С введенирем файла набора VHD (VHD Set), Microsoft может получать преимущество такого хранения моментального снимка и затем обновлять все настройки ВМ чтобы соответствовать правильной конфигурации. Сам файл VHDS является файлом относительных ссылок и содержит метаданные контрольных точек. Никакие данные пользователей не хранятся в самом файле VHDS. Вы можете представлять себе файл VHDS как внешний файл совместно используемых между ВМ (гостевыми кластерами) настроек, поскольку в Windows Server 2012 R2, если у вас есть две ВМ, использующих совместно файл VHDX, тогда каждая ВМ имеет свой собственный файл настроек, что создаёт существенные проблемы при обновлении метаданных и повторной синхронизации всех имеющихся изменений. Однако, в Windows Server 2016, если у вас имеются две ВМ гостевого кластера, причём каждая имеет свою собственную конфигурацию, зависящую от совместно используемого файла VHDS, который является на самом деле файлом настроек, это делает для нас возможным иметь одно место для обновлений в случае, когда присутствуют изменения в лежащем в основе всего хранилище. Файл Набора VHD (VHD Set) позволяет решать проблемы, связанные с координацией обновлений во всех конфигурациях ВМ путём централизации всех путей файлов VHD в едином файле Набора VHD. Файл Набора VHD также предоставляет использование в GUI или в PowerShell некоторого дружественного имени файла. Файл Набора VHD может применяться аналогично любому прочему файлу VHD; он может запрашиваться, мигрировать и монтироваться. Первичной причиной для файла Набора VHD (VHDS) является наличие поддержки для резервного копирования в гостевых кластерах.
Отметим, что Миграция в реальном времени хранилища, Стандартные контрольные точки или Промышленные контрольные точки через Диспетчер Hyper-V или PowerShell пока не поддерживаются Набором VHD. Однако восстановление контрольных точек поддерживается только для резервного копирования и репликации.
Различия между Windows Server 2016 Hyper-V, Нано сервером, Сервером Hyper-V, Клиентом Hyper-V и VMware
Роль, которая устанавливается на Windows Server 2016 (Сервер ядра или Полный сервер), Роль, которую можно установить на Нано сервер, его свободно распространяемая версия с названием Сервер Hyper-V, а также Hyper-V, который поставляется с Windows 10 под названием Клиента Hyper-V, все они являются четырьмя различными версиями Hyper-V. Следующий раздел разъяснит различия между всеми этими версиями и сравнит Hyper-V с его конкурентом, VMwrae.
Улучшения ограничений Hyper-V
Начиная со своей первой версии, Hyper-V был сильно улучшен. Новые ограничения, в сравнении с предыдущей версией, повышены в 16 раз. Это достаточно выразительно для третьего выпуска.
Приводимая ниже таблица отображает улучшения на основе Hyper-V Windows Server 2008 R2: