Где hyper v хранит файлы
Моментальные снимки: сложно о простом
Наверняка многие знакомы с достаточно полезной функцией многих продуктов виртуализации – моментальными снимками, в простонародье – «снапшоты» (snapshots). Снапшот виртуальной машины – это как сохранение в игре: в случае, если где-то сильно накосячил (патч Бармина применил, например) – можно вернуться назад и повторить все заново. В этой статье я попытаюсь более-менее подробно рассказать о работе моментальных снимках и о некоторых нюансах их применения. В статье речь пойдет о Microsoft Hyper-V, но с некоторыми натяжками материал статьи применим и для других систем виртуализации (в частности — VMWare).
Прежде, чем продолжать – вспомним, из каких компонентов состоит виртуальная машина:
Файл конфигурации – основа виртуальной машины, хранит все настройки, касающиеся виртуалки. Представляет собой XML-файл, имеющий, как ни странно, расширение XML. В VirtualPC/Virtual Server этот файл имел расширение VMC.
Файл виртуального диска. Обычно в качестве жесткого диска виртуальные машины используют специальные файлы-образы, имеющие расширение VHD. Этот формат, изначально разработанный фирмой Connectix, после приобретения ее корпорацией Microsoft стал использоваться в продуктах виртуализации, и не только в них: в частности, они используются в Microsoft Software iSCSI Target, а в ОС Windows 7 и Windows Server 2008 R2 с VHD-дисками можно работать на уровне ОС, вплоть до загрузки с них самой операционки.
Дифференциальные диски – основа технологии снапшотов. При создании снапшота запись в VHD-файл прекращается, и все последующие изменения записываются в отдельный файл, имеющий расширение VHD.
Сохранение состояния (Save State) – одна из полезных функций системы виртуализации. При сохранении состояния все содержимое памяти виртуальной машины, регистров процессора и т.д. сохраняется в специальные файлы, и виртуалка переходит в состояние «Выключено». После этого можно делать все что угодно, вплоть до перезагрузки хостовой машины, а потом снова запустить виртуалку – и она будет работать, как ни в чем не бывало, ровно в том же состоянии, в каком она была до сохранения. Примерно так же работает функция Hibernate в Microsoft Windows с единственным лишь отличием – сохранение состояния происходит на уровне самой виртуальной машины, а не на уровне гостевой ОС. В VirtualPC и Virtual Server для сохранения содержимого памяти использовался файл с расширением VSV, в Hyper-V же их стало аж целых два – BIN и VSV.
Файл экспорта. Если виртуальную машину Hyper-V нужно склонировать, или же перенести на другой хост – необходимо произвести операцию экспорта, а затем импорта. При экспорте конфигурационный XML-файл преобразуется в файл с расширением EXP. В VirtualPC и Virtual Server для этого достаточно просто скопировать файлы виртуальной машины, а в Hyper-V придумали импорт/экспорт – как они сами говорят, в целях безопасности.
Различают два типа моментальных снимков: онлайновый и оффлайновый. Онлайновым называют снапшот, сделанный на виртуальной машине с запущенной гостевой ОС. Соответственно, если виртуальная машина была в состоянии «выключено» — то снапшот будет называться оффлайновым. Для пользователя нет абсолютно никаких различий между онлайновыми и оффлайновыми снапшотами. Различаются они только по составу файлов, потому что при создании снапшота на запущенной виртуалке происходит операция Save State, и данные Save State включаются в состав снапшота
- Копия файла конфигурации
- Дифференциальный диск AVHD
- Файлы Save State – BIN+VSV
- Копия файла конфигурации
- Дифференциальный диск AVHD
Что можно и что нельзя делать с моментальными снимками?
Как уже было сказано, снапшоты виртуальных машин – это то же самое, что и сохранение в игре. И единственное их назначение – обеспечение точки возврата на случай возможных ошибок. Снапшоты – это не бэкап, и использовать их для аварийного восстановления не получится. Использовать моментальные снимки в production-среде не рекомендуется, потому что это может привести к падению производительности, почему это так – будет понятно далее из статьи. Если необходимо часто создавать резервные копии для защиты от ошибок пользователей – необходимо использовать другие средства, к примеру – инкрементные бэкапы или журналы транзакций, если речь идет о базах данных.
Помимо этого, необходимо помнить, что управлять снапшотами можно и нужно только через стандартные средства Hyper-V (оснастка MMC Hyper-V Manager, WMI-провайдеры, командлеты PowerShell) и сторонний софт, использующий такие средства – например Microsoft SystemCenter Virtual Machine Manager.
- Apply – возвратиться к точке создания снапшота, при этом все изменения, произошедшие с момента создания снапшота и до настоящего времени будут потеряны.
- Delete – точка возврата удалится, а все внесенные изменения сохранятся на веки вечные.
- Во-первых, удаляется копия файла конфигурации, и сам снапшот исчезает из списка.
- Если в данный момент виртуальная машина запущена – AVHD, связанный с этим снапшотом остается, и запись в него продолжается.
- Как только виртуальная машина останавливается (шатдаун или перезагрузка) – все данные из AVHD записываются в предыдущий AVHD, или в VHD, если мы удаляем первый снапшот, а сам AVHD удаляется. Эта операция называется «Объединение» (Merging). Операция объединения может занять определенное время (в зависимости от объемов данных), в течение которого запустить виртуалку нельзя.
Ну и теперь скажу несколько слов в заключение.
Во-первых – как я уже говорил, нужно помнить про «Delete means Apply, Apply means Delete», и думать перед нажатием кнопки, дабы не потерять ничего.
Во-вторых, если виртуальная машина содержит онлайновые снапшоты – ее крайне не рекомендуется экспортировать и переносить на другой сервер. Дело в том, что онлайновый снапшот содержит состояние регистров процессора и содержимое памяти, и применение такого снапшота в другом аппаратном окружении может привести к краху гостевой ОС.
В-третьих, как уже было сказано – снапшоты не рекомендуется использовать в производственной среде. Наверняка вам известно, что для продакшна рекомендуется использовать виртуальные диски фиксированного размера – для того, чтобы избавиться от фрагментации VHD-файла. Создавая же снапшоты, мы искусственно делим наш виртуальный диск на отдельные файлы – VHD и множество AVHD. На высоконагруженных системах это может привести к некоторому падению производительности. Кроме этого, при удалении снапшотов происходит операция объединения, которая тоже может сказаться на общей производительности системы, а к тому же может повысить время простоя при перезагрузках виртуальной машины. К примеру, если вы удалили один или несколько снапшотов на виртуальной машине, а потом потребовалось ее перезагрузить (к примеру – при установке апдейтов), то загрузка ОС не начнется, пока не завершится полностью операция объединения. Поэтому снапшоты можно использовать перед вводом в продакшн, для экономии времени при установке ПО и начальной настройке. После этого все снапшоты нужно удалить, дождаться окончания объединения, и только затем вводить в продакшн.
Еще один небольшой момент: в настройках Hyper-V можно задавать отдельно путь для размещения файлов виртуальных машин и путь для размещения VHD. По умолчанию и то и другое хранится на диске C:. Если для хранения VHD планируется использовать, к примеру, высокоскоростной RAID-массив – необходимо хранить на нем не только VHD, но и файлы виртуальных машин. Дело в том, что при создании снапшотов файлы AVHD будут храниться именно в том месте, которое было выбрано для хранения виртуальных машин. И может получиться так, что сам VHD будет храниться на отдельном дисковом массиве, а куча AVHD будет на диске С:, что не есть хорошо.
Если хаброобщественность не будет возражать – я могу дать ссылки на другие свои скринкасты и статьи про Hyper-V, дабы не кросспостить и не копипастить. Надеюсь, кого-то моя статья заинтересовала, в любом случае – спасибо заранее.
Как я уже обещал – продолжаю «евангелировать» и пишу очередную статью про Hyper-V. На этот раз речь пойдет о работе Hyper-V с устройствами хранения данных – сиречь жесткими дисками и всякими внешними СХД.
Где виртуальные машины могут хранить данные?
Диски виртуальных машин могут храниться как на локальных жестких дисках сервера, так и на внешних СХД (SAN).
На схеме используется DAS. На диске Disk2, смонтированном в хостовой системе как диск Y:, создан файл VM1.vhd, который, в свою очередь, смонтирован в виртуальной машине и используется ей в качестве диска C:. А Disk3 подключается к виртуальной машине напрямую, и в гостевой ОС с ним можно работать как с диском D:. В хостовой же ОС Disk3 находится в состоянии Offline, и зайти на него не получится.
Посмотрим теперь, какие варианты имеются при использовании SAN.
Самый «классический» вариант – LUN 1 презентуется серверу, монтируется в хостовой ОС, к примеру, как диск Z:, на нем уже создается VHD, который, в свою очередь, используется виртуальной машиной. Примерно как в сказке – «игла в яйце, яйцо в утке, утка в зайце, и т.д.».
Второй вариант – LUN 2 презентуется серверу, но в хостовой ОС он не монтируется, а подключается как pass-through-диск к виртуальной машине.
Кроме этого, если SAN построена на базе протокола iSCSI – LUN может быть смонтирован внутри виртуальной машины с помощью программного iSCSI-инициатора, запущенного внутри гостевой ОС. К сожалению, FibreChannel-LUN’ы присоединить подобным образом не получится – в Hyper-V нет виртуального FC-HBA.
Виртуальные контроллеры
Итак, начнем с того, что виртуальная машина, точно так же, как и настоящий компьютер, имеет свои виртуальные жесткие диски и виртуальные контроллеры жестких дисков. Контроллеры эти бывают всего двух типов: IDE и SCSI. В чем же разница между ними?
Во-первых, в отличие от IDE, SCSI-контроллер является полностью синтетическим устройством, и потому для своей работы требует установки компонент интеграции. Поэтому использовать его можно лишь в тех гостевых ОС, которые их поддерживают (напоминаю, что это – только MS Windows, а так же RHEL и SLES). По этой же причине гостевая операционная система может загружаться только с IDE-устройства. Основным отличием между виртуальными IDE и SCSI-контроллерами является количество устройств, способных через этот контроллер работать. IDE-контроллеров в виртуальной машине может быть два, и к каждому может быть подключено максимум по два виртуальных диска. SCSI-контроллеров может быть четыре, и к каждому контроллеру можно подключить до 64 виртуальных дисков, то есть всего виртуальная машина может иметь 260 виртуальных дисков (4 IDE + 4*64 SCSI). Надо так же помнить, что хотя реальные SCSI-диски работают быстрее, чем IDE — это не совсем верно для виртуальной среды. В среде Hyper-V R2 при установленных компонентах интеграции виртуальные IDE- и SCSI-диски работают одинаково быстро, и производительность определяется только физической дисковой подсистемой.
Виртуальные диски
Посмотрим теперь, какими могут быть сами жесткие диски у виртуальных машин. Начнем с того, что Hyper-V поддерживает как виртуальные жесткие диски, представляемые в виде файлов .VHD, так и прямое подключение дисков к виртуальной машине (так называемые pass-through-диски).
Виртуальные диски представляют из себя файлы особого формата (VHD). Формат этот первоначально был разработан компанией Connectix, а затем, после приобретения оной корпорацией Microsoft – начал использоваться в продуктах виртуализации от MS – VirtualPC, Virtual Server, а ныне – Hyper-V. На данный момент, в ОС Windows 7 и Windows Server 2008 R2 файлы VHD поддерживаются на уровне ОС и могут монтироваться в самой системе как диски. Более того, сама ОС может быть установлена на VHD и загружаться с него. Формат VHD в настоящее время полностью открыт, и существует множество стороннего ПО (например, от компании Paragon), позволяющая работать с VHD, а так же диски VHD поддерживаются в некоторых продуктах Citrix. Виртуальные диски бывают трех типов: фиксированного размера, динамические и дифференциальные.
Динамические виртуальные диски представляют из себя VHD-файл, который увеличивается в размере по мере записи на него. Динамический диск в процессе работы может быть сжат за счет удаления неиспользуемых блоков, которые остаются при удалении данных с VHD. Использование динамических дисков позволяет наиболее рационально использовать дисковое пространство, но использовать их в production-среде не рекомендуется из-за возможного падения производительности.
Виртуальные диски фиксированного размера представляют собой файл, содержащий набор блоков, представляемый виртуальной машине в качестве диска. Размер виртуального диска задается при его создании, и на жестком диске сервера создается файл VHD соответствующего размера. Процесс создания может занять некоторое время, в зависимости от размера диска. Использование дисков фиксированного размера предпочтительней, чем динамических по двум причинам. Во-первых, поскольку динамический диск расширяется постепенно, VHD-файл может фрагментироваться, что повлияет на производительность. VHD фиксированного размера сразу же занимает все необходимое ему пространство, и потому не фрагментируется в процессе работы. Во-вторых, может сложиться ситуация, что место на физическом диске закончится, и динамическим дискам будет некуда «расти», и это может привести к сбоям в работе виртуальных машин.
Дифференциальный диск — всегда имеет «родительский» VHD. Чтение при этом может осуществляться как с «родительского», так и с самого дифференциального VHD, но запись идет только в дифференциальный VHD, «родительский» остается при этом без изменений. Таковы, например, AVHD-диски, создаваемые при снапшотах виртуальной машины. Подробнее о снапшотах – см. мою предыдущую статью. Так же дифференциальные VHD можно использовать в тестовой среде, когда необходимо поднять несколько виртуальных машин с примерно одинаковым содержимым жестких дисков (к примеру – с установленной ОС). Использовать дифференциальные диски в production-среде не рекомендуется во-первых из-за снижения производительности (вместо чтения из одного VHD приходится читать из нескольких), а во-вторых – из-за снижения надежности (повреждение родительского VHD приводит к повреждению всех дифференциальных).
Максимальный размер виртуальных дисков, как фиксированных, так и динамических, равен 2 терабайтам (или 2040 гигабайтам).
Pass-through-диски – это подключение физических дисков напрямую к виртуальной машине без создания VHD-файлов. Это могут быть как разделы на локальных жестких дисках, так и презентованный серверу LUN от внешней системы хранения (SAN). Для хостовой же ОС диск, после монтирования к виртуальной машине, переходит в состояние «Offline», то есть прямой доступ к диску прекращается. В качестве pass-through-дисков не могут использоваться примонтированные VHD, а так же они не поддерживают снапшоты на уровне виртуальных машин.
Размер pass-through-дисков не ограничен 2 терабайтами.
Иногда возникают вопросы: что же лучше использовать – VHD или pass-through-диски? Некоторые считают, что VHD работают медленнее, но это неправда. Исследования показали, что в Winodws Server 2008 R2 VHD и pass-through-диски работают с одинаковой скоростью. Подробнее о замерах можно почитать официальный документ.
На этом я пожалуй закончу, следующая статья будет рассказывать о работе виртуальных машин с сетью. Если будут какие-либо вопросы по теме статьи — как обычно, милости прошу в комментарии.
Хочу поделиться с вами опытом о том, что у меня отняло море времени — о бэкапах виртуальных машин и обычных компьютеров. Как сделать дешево и красиво.
Пожалуй, начну с того, что если вы хотите бэкапы на VMWare, то готовьтесь платить. Бесплатный VMWare — это бесплатно до тех, пока речь не идет о миграциях, бэкапах и тому подобное. На этом месте можно начать бесконечный холивар, но без моего участия. Мои повествования будут только о Hyper-V на Windows Server 2012R2. Хотя часть статьи можно применить и к VMWare, но, вероятно, будут подводные камни.
Бэкапить на Hyper-V мы можем бесплатно, а точнее, теми средствами Windows, за которые мы уже заплатили, приобретая лицензии Windows Server. Для удобства работы с нашими бэкапами (к тому же за это мы тоже заплатили) будем использовать WDS и дедупликацию (может и групповые политики).
2. Бэкап файлов vhdx виртуальных машин
Производится легко и непринужденно:
Но с некоторыми особенностями. Эта команда должна выполняться в PowerShell и с предварительным получением списка виртуальных машин в переменную. За подробным примером обращаемся в Google.
Бэкап виртуальных машин в Windows Server 2012 R2 идет с помощью моментальных снимков Hyper-V. Также замечу, что происходят приостановка работы виртуальных машин, если на них ядро Linux или отсутствуют Hyper-V драйвера. Я лично отказался бэкапить виртуальные машины таким способом. Причина в том, что на Windows Server 2012 (не R2) требовалось останавливать виртуальные машины до бекапа. Да и сейчас на Windows Server 2012 R2 приостановки Linux меня не устраивают, когда есть первый неплохой способ бэкапа. (в комментариях к данной статье есть замечание). После очередного обновления в Windows Server 2012 R2 бэкап любых виртуальных машин проходит без приостановок. ОС Linux также можно бэкапить «изнутри» с помощь Dump (CentOS, Ubuntu), но это отдельная тема с puppet'ами и другим ПО в моем случае.
5. Групповые политики
Вот тут можно долго и по-разному реализовывать установку скрипта бэкапа с помощью GPO. Но хотелось бы обратить внимание на важные моменты:
27.07.2021
itpro
Hyper-V, PowerShell, Windows Server 2016, Виртуализация
комментариев 14
В Hyper-V в отличии от VMWare нет встроенной функции клонирования виртуальной машины (клонирование есть только в Virtual Machine Manager). Чтобы создать полную копию существующей ВМ придется использовать функцию импорта/экспорта. В этой статье мы рассмотрим, как клонировать виртуальную машину в Hyper-V через импорт/экспорт через графический интерфейс Hyper-V Manager, PowerShell и Windows Admin Center (WAC).
При клонировании виртуальных машин с Windows не забывайте о том, что после клонирования ВМ у ее копии будет такой же SID. Для сброса SID нужно использовать утилиту sysprep. Если вы создали эталонный образ Windows, то перед клонированием на нем нужно выполнить команду:
%WINDIR%\system32\sysprep\sysprep.exe /generalize /shutdown /oobe
ВМ будет выключена и при следующей загрузке как оригинальной ВМ, так и ее клона для Windows будет сгенерирован новый SID. Также нежелательно клонировать ВМ, включенные в домен Active Directory.
1.1. Бэкап сегодняшнего дня
Насколько мы знаем, любой Windows умеет делать бэкап. Причем, любые настройки бэкапа Windows через интерфейс сводятся, в конечном счете, к фоновому использованию утилиты wbadmin. А что, собственно, умеет wbadmin? А умеет она делать как бэкап образа с системным разделом, так и бэкап отдельных папок. В данной части статьи нас интересует только бэкап образ (системного раздела). Остальное — это специфичные данные виртуальных машин и бэкапить нужно отдельно. Отсюда вывод: Не храните на системном разделе виртуальных машин (и на обычных компьютерах тоже) никакой ценной информации и баз данных, отдельных приложений. MS SQL Server / MS Exchange / «Сервер приложений 1С» и другое ставим только на не системные разделы или на отдельные диски.
Итак, что же нужно, чтобы бэкап отработал? А нужна всего лишь одна команда:
На самом деле, для этой команды нужны особые права, но о них позже. Сейчас важно понять одну вещь. Данная команда делает не просто бэкап. Она делает инкрементальный бэкап. Причем, для серверных и настольных (клиентских) Windows бэкапы формируются разные. И разница заключается в том, что для серверных ОС у нас получатся снимки каждого бэкапа, а вот для настольных — снимок останется всегда только последний. Спросите, а что это за такой инкрементальный бэкап? А «инкрементальный» он остается, потому что бэкапим мы не весь образ, а только изменившуюся часть со времени последнего бэкапа (а значит и меньше трафика и быстрее создается бэкап).
Те, кто сталкивался с аналогичной ситуацией заметят, что бэкап всегда будет «инкрементальный» (полный). Так как бэкап происходит в нашем случае на сетевой диск. То есть для серверной Windows снимки остаются тоже только последние.
Позже, выявил, что нет никакой разницы в работе wbadmin на серверной и клиентской ОС. Разве, что разница есть в интерфейсе. wbadmin производит инкрементальный бэкап (кроме первого бэкапа), если указан жесткий диск в ключе -backupTarget (команда использует ключ по умолчанию -vssСopy). Или производит полный бэкап, если добавить ключ -vssFull.
4. Особенности дедупликации
Можно дедуплицировать работающие виртуальные машины. Можно дедуплицировать бэкапы сегодняшнего дня и можно дедуплицировать бэкапы с историей. Все это дает большой положительный плюс к объему жестких дисков (как для HDD, так и SSD). Но не стоит забывать о некоторых вещах:
- Если дедупликация будет работать с дисками с объемом более чем 1 ТБ, то оптимизатор дедупликации будет использовать очень много памяти.
- Если дедупликация будет работать с сжатыми данными, но с объемом сжатого более чем 10 ТБ, то длительность работы оптимизатора дедупликации будет слишком большим. Такое может получиться, если просто копировать данные ежедневно на дедуплицированный диск в разные папки.
- Бэкапы на HDD хранить можно и даже нужно, а вот рабочие виртуальные машины хранить на HDD в количестве больше 5-10 не стоит. К дедупликации это относиться с той лишь стороны, что дедупликация таких рабочих виртуальных машин сведет производительность HDD в ноль.
1.2. Бэкап с историей предыдущих снимков
На данный момент, мы сделали бэкап образов виртуальных машин. Но это же у нас бэкап снимков только сегодняшнего дня. Завтра он будет совершенно другой… Но что будет, если бэкапить бэкапы? Да и ещё по-настоящему инкрементально. Так и поступим.
Но мне было этого недостаточно и я сделал так:
Скрипт подключает виртуальный диск из сети. После бэкапа подобный же скрипт отключает диск. ОС помнит, что у диска определена буква E. Но не дай бог подсунуть чужой диск с той же буквой E, бэкап отработает уже по полной (не инкрементально и на чужой диск). Имейте это в виду и используйте, букву, ближе к концу алфавита (X, Y, Z)…
Замечу сразу, если бэкап сегодняшний будет производиться параллельно с бэкапом с историей, то получим в итоге бэкап, который невозможно поднять.
Чтобы достать бэкап предыдущих дней можно воспользоваться интерфейсом (GUI) сервера, на котором производятся бэкапы с историей. Более того, все запуски команды wbadmin в консоли Windows знает и помнит. Служба восстановления даст возможность вам выбрать нужный архив в бэкапах с историей.
Сторонние средства резервного копирования Hyper-V
При большом количестве хостов Hyper-V и виртуальных машин, использовать встроенный Windows Server Backup нереально. Вам в любом случае придется выбирать одно из сторонних решений. Однозначно говорить, что тот или иной продукт будет идеальным решением для резервного копирования Hyper-V нельзя, слишком много нюансов нужно учесть. Это и количество хостов, лицензионные ограничения, необходимый функционал, архитектура сети и т.д.
На рынке представлено большое количество коммерческих и бесплатных продуктов для резервного копирования, и запутаться в них очень сложно. Обычно для оценки лидеров ниши используется магический квадрант Gartner. Я нашел такую картинку, характеризующие основных игроков и лидеров на рынке резервного копирования для дата-центров.
Как вы видите, Гартнер среди лидеров решений по резервному копированию выделяет компании и продукты:
- Actifio
- Commvault
- Dell EMC
- IBM
- Rubrik
- Veeam
- Veritas Technologies (Symantec — Veritas Backup Exec)
- Acronis (Veritas Backup Exec)
- Symantec (Veritas Backup Exec)
В рамках одной статьи оценить и сравнить все продукты довольно сложно, поэтому попробуем рассмотреть возможности нескольких программ – лидеров рынка по резервному копированию Hyper-V.
- Veritas Backup Exec
- Commvault Backup
- Veeam Backup
- Acronis Backup
Я составил небольшую сравнительную таблицу с интересными мне возможностями этих средств резервного копирования (рассматривается функционал версий, актуальных на момент написания статьи).
Функционал/ Продукт | Veritas Backup Exec 20.2 | Commvault Backup and Recovery 11 | Veeam Backup & Replication 9.5 | Acronis Backup 12.5 |
Резервное копирование файловых систем | Windows / Linux | Windows / Linux / IBM AIX / HP-UX | Windows / Linux / IBM AIX / HP-UX. Агенты для физических систем автономны, не поддерживают совместное использование хранилищ групповые политики | Windows / Linux |
Передача резервных копий дисковых массивов по NDMP | + Поддержка NDMP v4+. Список поддерживаемых хранилищ есть на сайте veritas. Не поддерживается инкрементальное и дифференциально копирование, бэкап только LUN целиком и нельзя восстановить отдельные файлы. | + Поддержка прямого резервного копирования данных с файловых устройств NAS. На сайте Commvault есть список поддерживаемых версий файловых систем разных производителей. При использовании этого типа резервного копирования данные отправляются напрямую с NAS через MediaAgent (прокси сервер) на устройство хранения, минуя управляющий сервер CommServe. Поддержка бэкапов отдельных vmdk файлов. | + Поддержка NDMP (v4 и выше) появилась относительно недавно. Поддерживается бэкап только LUN целиком. Поддерживается до 10 точек восстановления (на NetApp до 30). | — |
Передача моментальных снимков ВМ по SAN | + На сайте Veritas в секции Hardware Compatibility List представлен список совместимых HBA адаптеров, SAN свичей | + Поддерживается бэкап по SAN как для ESXi так и для Hyper-V хостов | + Необходимо дополнительная физическая машина с ролью выделенного прокси сервера Veeam, подключенного к той же сети SAN и презентованными LUN | Поддержка моментальных снимков только в VMware vSphere для хранилищ NetApp с Data ONTAP |
Репликация резервных копий в несколько хранилищ (в том числе на удаленную площадку) | + | + | + | + |
Поддержка гранулярного восстановления приложений и БД | Microsoft SQL / Exchange / AD | Microsoft SQL / Exchange / AD / Domino / DB2 / MySQL / Oracle | Microsoft SQL / Exchange / AD / Oracle (только для виртуализированных приложений, не поддерживается на физических системах) | Microsoft SQL / Exchange / AD |
Управление аппаратными снимками СХД | + | + (IntelliSnap) | + (список поддерживаемых вендоров и моделей СХД ест ь на сайте, для некоторых необходима установка отдельного модуля интеграции) | + |
Лицензирование для сред виртуализации | Хост / сокет / Объем данных | Сокет / Объем данных | На сокет (процессор) | На хост |
Стоимость 1 лицензии (ориентировано) | От 85 тыс. р. | 190 тыс. р. | 70 тыс. р. (редакция Standard), 200 тыс. р. (редакция Enterprise Plus) | 45 тыс. р. (редакция Standard), 95 тыс. р. (редакция Advanced) |
Как вы видите, функционал и стоимость лицензий для каждого продукта довольно сильно отличается. Поэтому перед принятием решений о выборе того или иного решения стоит составить список требований к продукту резервного копирования Hyper-V, список имеющегося оборудования и необходимый функционал. У большинства известных продуктов резервного копирования есть бесплатные версии с некоторыми ограничениями, обычно их достаточно для оценки функционала.
Клонирование ВМ через экспорт/импорт в Hyper-V с помощью PowerShell
Рассмотрим, как клонировать виртуальную машину Hyper-V через импорт/экспорт из консоли PowerShell.
Для экспорта ВМ воспользуйтесь такой командой:
Export-VM -Name win10 -Path 'C:\VHD\export'
Если вы хотите экспортировать запущенную ВМ, вы можете использовать параметр CaptuteLiveState, в котором определяется как нужно копировать оперативную память ВМ. Доступны три опции
- CaptureSavedState – экспортировать оперативную память (по-умолчанию);
- CaptureDataConsistentState – экспортировать состояние ВМ из Production checkpoint;
- CaptureCrashConsistentState – не сохранять содержимое памяти.
Export-VM -Name win10 -Path 'C:\VHD\export' -CaptureLiveState CaptureCrashConsistentState
Если вы хотите экспортировать состояние ВМ в определеном снимке, нужно указать его имя.
Сначала выведите список снимков для указанной ВМ:
Get-VMSnapshot -VMName win10
Затем выполните экспорт нужного снимка по его имени:
Export-VMSnapshot -Name “win10 - (2/17/2021 - 9:52:20 PM) Standard” -VMName win10 -Path 'C:\VHD\export'
После завершения экспорта ВМ вы можете импортировать ее. Если нужно зарегистрировать ВМ по месту хранения файлов, выполните команду:
Import-VM -Path "C:\VHD\export\win10\Virtual Machines\1117A061-0B50-4BC2-850C-88CCD4C114FB.vmcx"
В параметре Path указываем расположение vmcx файла конфигурации ВМ (формат vmcx заменил XML формат конфигурационных файлов ВМ в Hyper-V Server 2016). Для копирования ВМ в другой каталог с тем же ID используйте параметр Copy. Чтобы сгенерировать нового идентификатор ВМ, используйте параметр GenerateNewId:
Import-VM -Path "C:\VHD\export\win10\Virtual Machines\1117A061-0B50-4BC2-850C-88CCD4C114FB.vmcx" -VhdDestinationPath "C:\VHD\win10_2" -VirtualMachinePath "C:\VHD\win10_2"
В параметре VhdDestinationPath указывается каталог, куда нужно скопировать VHDX файлы ВМ, а в параметре VirtualMachinePath — каталог конфигурационных файлов ВМ. Если эти параметры не задать, файлы ВМ будут скопированы в дефолтный каталог, указанный в настройках хоста Hyper-V (C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines\).
Также можно указать каталоги для хранения чекпоинтов ( SnapshotFilePath ) и файла подкачки ( SmartPagingFilePath ).
Обратите внимание, что клонированная ВМ появилась в консоли Hyper-V с оригинальным именем. Переименуем новую ВМ, но сначала нужно получить ее ID:
get-vm | select VMNAME,VMId
Как вы видите в консоли есть две ВМ с одинаковым именем и разными ID. Нужно переименовать ВМ с ID, который отличается от ID импортируемой ВМ. Скопируйте ID новой ВМ и переименуйте ее:
Затем для удобства можно переименовать виртуальный жесткий диск.
Get-VHD -VMId 24ad8934-f650-46f6-9caa-2a3b79b79bd5| Select Path | Rename-Item -NewName win10_2.vhdx
Remove-VMHardDiskDrive -VMName win10_2 -ControllerType SCSI -ControllerLocation 0 -ControllerNumber 0
Add-VMHardDiskDrive -VMName win10_2 -ControllerType SCSI -ControllerNumber 0 -ControllerLocation 0 -Path "C:\VHD\win10_2\win10_2.vhdx"
Изменим MAC адрес виртуального адаптера (можно указать новый статический MAC или настроить динамическое получение MAC адреса).
Set-VMNetworkAdapter -VMName win10_2 -DynamicMacAddress
Start-VM -Name win10_2
Прежде, чем подключить новую ВМ в сеть, желательно переименовать ее и изменить IP адрес на новый (если используется DHCP адресация, этот шаг можно пропустить). В данном случае мы можем подключиться к новой ВМ через PowerShell Direct с помощью командлета Invoke-Command или Enter-PSSession:
Enter-PSSession -ComputerName win10_2 -Credential (Get-Credential)
Rename-Computer win10_2
Remove-NetIPAddress -InterfaceAlias “Ethernet” -AddressFamily IPV4
New-NetIPAddress -IPAddress 192.168.31.50 -InterfaceAlias “Ethernet” -AddressFamily IPv4 -PrefixLength 24
Restart-Computer
3. Восстановление бэкапа и WDS
А теперь, по-моему мнению, самая полезная часть этой статьи про бэкапы.
WDS — это Windows Deployment Services (службы развертывания Windows) и часть функционала Windows Server 2012R2. Раньше эта служба называлась RIS, но я с ней не сталкивался. Вообщем, суть WDS проста. Прописались в DHCP (автоматически для DHCP Windows Server) в виде отдельных параметров и далее загружаем на компьютер по сети (такая настройка BIOS компьютера для загрузки по сети) через TFTP загрузчик WDS. Далее загрузчик WDS позволяет выбрать из доступных на ней образов «загрузчиков» Windows. Загрузчики бывают разные — это и образы загрузчиков установщика, и PE, и RE образы. Для загрузчика установщика ещё нужны образы самих Windows в WDS, но это в случае, если нужно установить Windows по сети. Нас интересуют RE образы, которые позволяют поднять машину из бэкапа.
Как и что работает в WDS подробно объяснять не буду. Но вот важные заметки:
- Если у вас загрузчик RE загружается на Hyper-V виртуальной машине по сети, но не работает клавиатура в ней. Поздравляю, ваш RE образ для WinXP или древнее и не знает о существовании Hyper-V драйверов.
- Если у вас система начинает восстанавливать бэкап, но останавливается. Удалите все разделы на жестком (на котором восстанавливается бэкап) и попробуйте заново. Только не забывайте, что бэкап может быть битый и после удаления всех разделов на жестком у вас может ничего не остаться от старой информации.
- Если бэкап с загрузкой UEFI, а вы хотите восстановить на комп без UEFI, то не стоит тратить время. Скорее всего развернуть бэкап не получится.
- Бэкап с загрузкой UEFI и разделами GPT можно восстанавливать на машины с другим процессором / материнкой, а вот с разделами MBR формата и с загрузкой обычного BIOS на другой машине развернуть вряд ли получится. Ну у меня точно не получалось.
- Если бэкап пытаться развернуть на диск с меньшим объемом, то сделать это не получится. Даже если диск в бэкапе был почти пуст. В этом случае помогает восстановление на виртуальную машину с динамическим диском. Далее уменьшение этого диска и создание нового бэкапа. Но такое можно только с загрузчиком UEFI в бэкапе (почему, читаем предыдущий пункт).
- Стоит перед восстановлением бэкапа отключить лишние диски, чтобы не затереть информацию на них.
Резервное копирование Hyper-V с помощью встроенного Windows Server Backup
Бесплатный способ организации системы резервного копирования ВМ на Hyper-V предполагает использование встроенного Windows Server Backup через графический мастер резервного копирования/восстановления или утилитой wbadmin (входит в состав WSB). Windows Server Backup поддерживает VSS и инкрементальное копирование, эта фича доступна как в полноценной редакции Windows Server 2012 и выше, так и в Hyper-V. Для установки данного компонента нужно воспользоваться консолью Server Manager или командой:
Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools
У WSB есть графическая консоль wbadmin.msc, которая позволяет создавать и управлять резервным копированием Hyper-V, создавать расписание резервного копирования и т.д. Для бэкапа ВМ достаточно запустить простой мастер, в котором нужно выбрать какие ВМ с сервера Hyper-V нужно бэкапить, куда, и указать расписание резервного копирования.
Совет. В предыдущих версиях Hyper-V до 2012 с помощью встроенных средств резервного копирования было нельзя создать резервную копию одной ВМ – бэкапились все виртуальные машины сразу.
Но обычно проще воспользоваться утилитой командной строки wbadmin для бэкапа ВМ Hyper-V. Тем более из графического интерфейса нельзя создать более одного задания резервного копирования ВМ, причем это задание всегда будет перезатирать предыдущие резервные копии.
Чтобы создать резервную копию ВМ с именем Server 1 в локальную папку на диске C: (не самая правильная, идея не так, ли), просто выполните команду:
wbadmin start backup –backupTarget:C: –hyperv:"Server 1"
Например, чтобы создать резервную копию двух ВМ и сохранить их в сетевую папку (допустим это внешнее NAS хранилище), достаточно выполнить команду:
wbadmin start backup -backuptarget:\\192.168.1.100\VMbackup: -hyperv:"TestVM01,TestVM 02" -allowDeleteOldBackups -quiet
Вы можете добавить эту команду в планировщик Windows (с помощью того же PowerShell) и тем самым настроить регулярное создание бэкапов ВМ (старые бэкапы при этом удаляются).
Например, при бэкапе ВМ с контроллером домена AD, вы можете по окончании бэкап сбросить транзакционные логи AD, чтобы база ADDS в резервной копии была в консистентном состоянии (аналогично можно сделать бэкап ВМ с Exchange или SQL Server:
wbadmin start backup -backuptarget:\\192.168.1.100\VMbackup: -hyperv:MSK-DC1 -vssFull
wbadmin get versions
Совет. Обратите внимание, что при резервном копировании ВМ Hyper-V на хосте с Windows 2012 и выше, ВМ не переводится в режим приостановки, если на ней установлены компоненты интеграции Hyper-V.
С восстановлением ВМ из такого бэкапа все также достаточно просто. Однако вы не можете восстановить из бэкапа один конкретный файл или папку, вам придется вручную смонтировать vhdx файл с резервной копией и также вручную скопировать нужный файл.
При всей своей простоте WSB достаточно надежное решение для резервного копирования ВМ Hyper-V, работает довольно быстро и позволяет управлять расписанием резервного копирования. Но конечно, у Windows Server Backup есть свои недостатки:
- Нет средств мониторинга выполнения бэкапов, проверки консистентности резервных копий ВМ и приложений в них;
- Сложно управлять резервным копированием в средних и крупных инсталляциях Hyper-V (подходит для небольших сред с 1-2 хостами Hyper-V);
- Нельзя автоматически восстановить конкретный файл или состояние приложения (вам придется вручную смонтировать vhdx файл с резервной копией и вручную скопировать нужный файл);
- При большой плотности и размерах виртуальных машин на хосте вам придется с помощью планировщика Windows настраивать порядок создания резервных копий, чтобы не вызвать перегрузки сервера, а также высокой нагрузки на сети LAN/SAN/ iSCSI в рабочие часы (если вы храните бэкапы на другом хранилище).
Как работает резервное копирование виртуальных машин Hyper-V?
Рассмотрим упрощенно схему работы любого современного средства для бэкапа виртуальных машин Hyper-V.
Примечание. Ранее резервное копирование серверов выполнялось за счет установки агента резервного копирования на каждый хост. В эпоху виртуализации точка создания бэкапа сместилась из гостевой ОС на сам Hyper-V хост, на котором запущены ВМ. Агентные сценарии резервного копирования применяются довольно редко, в основном для конкретных приложений, которые не поддерживают VSS.
Средство резервного копирования отдает команду хосту Hyper-V на создание снимка. После получения команды на создание снапшота гипервизор создает новые файлы (дельта-файлы) и ВМ продолжает свою работу, сохраняя изменения в этих файлах них. Теперь задача средства резервного копирования скопировать оригинальные файлы ВМ (изменения в них не пишутся) на носитель резервных копий и после этого удалить снапшот. При удалении снимка Hyper-V производит консолидацию (слияние) исходных и дельта файлов, работа ВМ при этом также не прерывается. В случае потери продуктивной ВМ, вы можете восстановить ее состояние на момент даты создания резервной копии.
Клонирование виртуальных машин Hyper-V через Windows Admin Center
Возможно клонировать ВМ Hyper-V напрямую без промежуточного экспорта/импорта появилась в Windows Admin Center v2009.
Запустите WAC, выберите раздел Virtual Machines, выберите ВМ -> Manage -> Clone.
Затем нужно указать имя новой ВМ и каталог, в который нужно поместить ее файлы.
Обратите внимание, что мастере клонирования есть опция “I have already run sysprep on my VM”. Если вы не выполнили генерализацию образа с помощью Sysprep, и не включили эту опцию, Hyper-V создаст снапшот исходной ВМ, выполните ее Sysprep и склонирует в новую (исходная ВМ будет несколько раз перезагружена и не доступна для работы). После этого исходная ВМ будет возвращена в первоначальное состояние, а снапшот удален.
Дождитесь окончания клонирования ВМ. Новой ВМ автоматически будет присвоен новый ID.
Предыдущая статья Следующая статья
Включаем поддержку SR-IOV для виртуальных машин Hyper-V
Низкая скорость сети на хосте Hyper-V с Windows Server 2019
Установка VMWare ESXi в виртуальную машину Windows Hyper-V
Маршрутизация между разными IP подсетями в Hyper-V
А какие есть бесплатные способы сделать клон ВМ из ESXi в Hyper-V?
Из приличных был StarWind V2V Converter, вроде это функционал там бесплатные. можно еще тулзой disk2vhd
«зарегистрировать ВМ по хранения файлов» — что это?
Отсуствие грамотного редактора для вычитки 🙂
речь про «по месту хранения файлов»
Copy и GenerateNewId вместе. Не ошибка?
Очень интересует последний способ, спасибо за него! Я поставил Windows Admin Center, она отлично встала на Windows Server 2022, я попробовал клонировать Windows 10 (заведено 2 юзера, оба админы).
Вот какую ошибку получаю:
Подробная информация об уведомлении
Ошибка
Не удалось клонировать виртуальную машину
00:43:25
Источник
Перейти в Виртуальные машины
Тип
Ошибка
Хотелось бы поинтересоваться, как можно победить следующую проблему. Из-за расплодившихся снапшотов, на физическом диске закончилось место и виртуалка не запустилась. Перенес один из виртуальных дисков на другой физический диск. Система запустилась, преждевременно спросив где тот самый диск. Теперь все работает, но место может закончиться.
Клонировать систему не дает, перенести не дает, и удалить снапшоты тоже не дает.
Подскажите как решить проблему? Можно ли скопировать всё на внешний диск и путем подмены букв дисков запустить виртуалку? И если можно, то как отключить службу hyper-v на время подмены букв?
Спасибо, надеюсь на ответ
Вот так не дает переместить файлы ВМ?
Move-VMStorage "VMname" -DestinationStoragePath "FullPathtothenewfolder"
Я так понимаю эту команду можно запустить при работающей машине? Или желательно отключить?
Ошибка выходит
Move-VMStorage: Не удалось выполнить операцию, так как файл не найден.
Move-VMStorage позволяет делать онлайн миграцию. другая проблема в том, что если виртуальный диск во времея миграции нагружен из гостевой ВМ, это может занять дополнительное время иил просто не хватит места для хранения изменнеия.
файл не найден — проверьте путь к файлам
Почему не видит работающую машину?
19.03.2019
itpro
Hyper-V, Резервное копирование
комментариев 17
Несмотря на то, что среда Hyper-V предоставляет довольно много технологий обеспечения высокой доступности и отказоустойчивости виртуальных машин (таких как кластера, Live Migration, репликация, и т.д.), администратору необходимо думать о классическом резервном копировании виртуальных машин. Все эти технологии позволяют минимизировать время недоступности ВМ в различных сценариях, но не обеспечивают возможность восстановления в случаях различных форс мажоров, таких как природные катаклизмы, ошибки персонала, хакерские или вирусные атаки, атаки конкурентов и подобные сценарии. В этой статье я постараюсь рассмотреть основные требования, которые предъявляются к системам резервного копирования Hyper-V, стратегии резервного копирования и возможности бесплатных и коммерческих продуктов резервного копирования.
Вы можете создавать резервные копии виртуальных машин, запущенных на хосте Hyper-V, с помощью встроенного Windows Server Backup (или скриптов на его основе, запускаемых через wbadmin), бесплатных или коммерческих продуктов. Всех эти способ объединяет то, что в основе резервного копирования виртуальных машин Hyper-V лежит технология снапшотов (или снимков). В снимке хранится как состояние виртуальных дисков, так и содержимое памяти и настройки виртуальной машины. Т.е. снапшот представляет собой состояние виртуальной машин на какой-то момент времени.
Основные требования к средствам резервного копирования ВМ Hyper-V
Это в общих чертах о резервном копировании Hyper-V, но на деле возникает куча нюансов и проблем. Попробую перечислить наиболее распространены проблемы:
- Чем дольше средство резервного копирования забирает снапшот (бэкап) к себе, тем больше изменений накапливается в дельта файлах. При достаточно большом количестве изменений внутри ВМ за время копирования файлов, процесс слияния файлов при удалении снапшота может вызывать высокую нагрузку на диски, Hyper-V хост и саму ВМ. Т.е. желательно максимально быстро забрать снимок. В Hyper-V Server 2016 для ускорения процесса резервного копирования используется технологий Resilient Changed Tracking, которая позволяет средству резевного копирования копировать только блоки данных, измененные с момент последнего бэкапа. При этом не нужно «забирать» ВМ целиком.
- При копировании данных снимка ВМ по LAN сети с хоста Hyper-V на хранилище резервных копий возможно вызвать высокую нагрузку на сеть. Поэтому для трафика резервного копировании желательно использовать отдельный интерфейс сервера, или же копировать данные через SAN сеть.
- Исходя из вышестоящих пунктов при использовании внешних систем хранения для хранения файлов ВМ, вы можете воспользоваться возможностями СХД по интеграции со средствами резервного копирования (аппаратные снапшоты).
- Изначально гостевая ОС не подозревает о том, что создается ее резервная копия. Соответственно при попытке восстановить ВМ из такого бэкапа, ОС пытается продолжить свою работу с момента создания снимка. В некоторых случаях это может вызвать проблемы как с самой ОС, так и с потерей данных в запущенными внутри нее приложениях (особенно в транзакционных, таких как Exchange, SQL, ADDS и т.п.). Для преодоления этой проблемы в Hyper-V 2016 появился новый тип снимков — Production Checkpoints (Microsoft рекомендуется применять обычные снимки — Standard Checkpoint только в тестовых и лабораторных средах, или для бэкапа остановленных виртуальных машин). Производственные снимки работают за счет наличия в гостевой ОС средств интеграции Hyper-V и основываются на технологии Volume Shadow Copy (Windows) или заморозки файловой системы fsfreeze (Linux). Однако состоянии памяти при этом не копируется. Т.е. Hyper-V уведомляет гостевую ОС о создании снимка, приложение с поддержкой VSS корректор завершает текущие транзакции, переходит в консистентное состояние и создается снимок ВМ. При восстановлении из такого снимка гостевая ОС выключена (т.к. состояние памяти не сохранялось), после включения она считает, что просто произошло аварийное отключение по питанию. Приложение (если оно поддерживает VSS) при этом начинает работу с сохранённого согласованного состояния.
- Для хранения бэкапов виртуальных машин нужно достаточно много места. Чем чаще вы делаете снимки и чем дольше должны хранится бэкапы, тем больше места вам нужно в хранилище резервных копий. Как правило вам на помощь может прийти технология дедупликации данных (встроенная в Windows Server) или собственная технология от вендора средства резервного копирования. Если вы используете дифференциальные диски, нужно чтобы средство резервного копирования поддерживало эту технологию. Иначе вы можете хранить одинаковые данные ВМ несколько раз.
Примечание. Есть даже средства восстановления конкретных хранилищ, ящиков и даже отдельных писем из резервной копии ВМ с Exchange.
Далее мы рассмотрим несколько популярных решений по организации резервного копирования ВМ на Hyper-V с точки зрения рассмотренных возможностей.
1. Бэкап изнутри виртуальных машин
Экспорт/импорт ВМ из консоли Hyper-V Manager
Сначала нужно экспортировать ВМ в отдельный каталог.
Запустите консоль Hyper-V manager, выберите ВМ и в контекстном меню выберите Export.
Начиная с версии Hyper-V в Windows Server 2012 R2 (в том числе в Free Hyper-V Server) вы можете экспортировать даже запущенные виртуальные машины без их остановки.
Укажите каталог, в который нужно экспортировать виртуальную машину.
Статус экспорта ВМ будет отображен в строке состояния ВМ в консоли Hyper-V.
Начиная с Hyper-V в Windows Server 2012 R2 вы можете экспортировать конкретный снимок (checkpoint) виртуальной машины. Для этого достаточно выбрать нужны снимок в дереве Checkpoints и выбрать Export.
Чтобы импортировать ВМ щелкните в консоли Hyper-V Manager по имени хоста и выберите Import Virtual Machine.
Затем нужно указать путь к каталогу, в котором находятся папки с файлами импортируемой ВМ. При импорте ВМ в Hyper-V предлагается 3 варианта регистрации ВМ на хосте:
- Register the virtual machine in-place (use the existing unique ID) —зарегистрировать ВМ в каталоге с импортируемыми файлами, ID ВМ сохраняется;
- Restore the virtual machine (use the existing unique ID) — скопировать файлы ВМ в другой каталог, сохранить исходный идентификатор ВМ;
- Copy the virtual machine (create a new unique ID) — скопировать ВМ в другую каталог и сгенерировать новый ID.
У каждой ВМ на хосте Hyper-V есть идентификатор ID, который должен быть уникальным в рамках хоста. Если вы импортируете, клонируете ВМ на другой хост, ID ВМ менять не обязательно.
Если вы попробуете импортировать ВМ с дублирующим ID, появится ошибка:
Чтобы создать клон ВМ с новым ID мы выбрали 3 вариант. Мастер предложит указать в каких каталогах нужно разместить файлы ВМ. По умолчанию, используются каталоги, заданные в настройках хоста Hyper-V.
Затем укажите каталог для хранения виртуальных дисков vhdx ВМ.
После этого новая клонированная виртуальная машина появится в консоли Hyper-V.
Читайте также: