Что такое snapshot виртуальной машины
Снапшоты дисков
Снапшоты — это слепки состояния диска. Они хранят разницу между изменяющимися данными на диске виртуальной машины и состоянием диска на момент создания снапшота. Это позволяет копировать диски для создания клона виртуальной машины и изменения типа диска. Снапшот не является резервной копией диска виртуальной машины, так как хранится на том же оборудовании и требует доступности основного хранилища для выполнения любой операции.
Просмотр снапшотов
Просмотр снапшотов в панели управления
Для просмотра снапшотов в разделе Диски в проекте раскройте карточку диска и перейдите на вкладку Снапшоты. Отобразится список существующих снапшотов этого диска с именем и датой создания.
Просмотр снапшотов с помощью CLI
Для просмотра списка всех снапшотов:
Ответ будет выглядеть следующим образом:
Для просмотра снапшотов конкретного диска введите команду:
Для просмотра информации о снапшоте:
Ответ будет выглядеть следующим образом:
Создание снапшота
Снапшоты создаются только для сетевых дисков. Для локальных дисков снапшот создать нельзя.
Для диска можно создать только один снапшот – большое количество снапшотов замедляет работу диска.
Создание снапшота в панели управления
Чтобы создать снапшот в панели управления:
Примечание: также вы можете создать снапшот в разделе Серверы. Для этого на странице сервера на вкладке Сетевые диски в меню (⋮) нужного диска нажмите Создать снапшот.
Создание снапшота с помощью CLI
Для создания снапшота введите команду:
Изменение параметров снапшота
Для снапшотов доступно только изменение имени.
Изменение параметров снапшота в панели управления
Для изменения имени снапшота в панели управления:
Изменение параметров снапшота с помощью CLI
Для изменения имени снапшота введите:
Создание облачного сервера из снапшота
Чтобы быстро клонировать облачный сервер, можно создать новый сервер из снапшота. Для этого:
Удаление снапшотов
После выполнения операций со cнапшотом рекомендуется его удалить, чтобы была возможность создать новый снапшот, а также из-за того, что большое количество снапшотов замедляет работу диска.
Для долговременного хранения состояния диска создайте диск из снапшота.
Удаление снапшота в панели управления
Для удаления снапшота в панели управления:
Удалить все снапшоты одного диска одновременно можно двумя способами:
VMware: «To quiesce or not to quiesce?», бэкапим вирутальные машины правильно
Про моментальные снимки (снапшоты) виртуальных машин было написано великое множество статей, где чрезмерно подробно описана теоретическая часть сего действа. В своей статье я сфокусируюсь на практической стороне вопроса и исключительно на платформе VMware vSphere.
Так зачем нужны «quiesced» * снапшоты, с чем их едят, и какие типичные проблемы с ними возникают? Взгляд на снапшоты будет представлен в первую очередь с точки зрения резервного копирования, но постараюсь в какой-то мере раскрыть и другие аспекты использования.
* Если кто готов подсказать подходящий русскоязычный термин — милости прошу в комментарии, будет хороший вариант — заменю в тексте англицизм.
Использование снапшотов для резервного копирования
Собственно, альтернативный вариант и есть наша вторая опция — quiescing. Она представляет намного больший интерес и суть её в том, чтобы подготовить гостевую операционную систему (файловую систему в первую очередь) к снятию бэкапа.
Что же представляет из себя quiescing?
«Это процесс приведения данных на виртуальном диске в состояние „подходящее“ для резервного копирования. Данный процесс может включать в себя операции по „сливу грязных буферов“ (flushing dirty buffers) из памяти операционной системы на диск или другие высокоуровневые операции специфичные для конкретных приложений.»
Из данного описания о том, что с виртуальномй машиной происходит на самом деле понятнее не стало. Давайте разбираться сами.
Сначала VMware Tools через свой сервис VMware Snapshot Provider инициируют создание VSS снапшота внутри гостевой ОС. Далее все зарегистрированные VSS writers (посмотреть их можно командой «vssadmin list writers«) в гостевой ОС получают запрос и подготавливают соответствующие приложения к бэкапу (происходит запись всех транзакций из памяти на диск). Когда все VSS writers заканчивают работу, они рапортуют об этом сервису VMware Tools (опять же, через сервис VMware Snapshot Provider), который, в свою очередь, говорит VMware о том, что снапшот можно снять.
Таким образом все приложения резервного копирования для VMware vSphere используют следующие комбинации при отдании команды на создание снапшота VMware (заметьте, что процесс непосредственно создания снапшота целиком и полностью контроллируется самой VMware):
Quiesced = ON, Memory = OFF
Quiesced = OFF, Memory = OFF
Вторую комбинацию мы рассматривать в данной статье не будем и сфокусируемся на процессе quiescing.
Зачем нужен quiescing?
Самый наглядный пример — это проблема USN rollback при восстановлении домен контроллера из бэкапа. Возникает она, если виртуализованный домен контроллер был забэкаплен без использования VSS (то есть без опции quiescing или других средств, которые обеспечивают запись транзакций на диск).
Никаких дополнительных действий и танцев с бубном производить не потребуется, если восстанавливать бэкап, сделанный с опцией quiescing. InvocationID будет корректно сброшен и вы увидите следующую запись в Event Log на загруженном после восстановления домен контроллере:
Event ID 1109: Active Directory has been restored from backup media, or has been configured to host an application partition. The invocationID attribute for this domain controller has been changed.
Поодобное корректное поведение можно наблюдать при использовании Acronis vmProtect 9. Собственно, его мы специально тестировали в рамках резервного копирования и восстановления виртуальных машин с домен контроллером внутри.
USN rollback, очевидно, не единственная возможная проблема при использовании «сырых» снапшотов и другие приложения (например Exchange/SQL — приложения в явном виде поддерживающие VSS) могут быть подвержены сбоям при восстановлении из таких снапшотов.
Как проверить, что снапшот создается корректно с использованием VSS?
Существует несколько способов определения корректности создания консистентного (до уровня приложения) снапшота:
Самый простой способ: войти в гостевую операционную систему и проверить «Просмотр Событий» (надо же было так перевести бедный Event Viewer). После создания снапшота с опциями quiesced=ON, snapshot memory=OFF (см скриншот в начале статьи) должны присутствовать события от соответствующих VSS writers в логах приложений:
Прим.: Ошибка от VSS с Event ID 12289, которую можно заметить на скриншоте, в реальности не является проблемой. Она относится к 3.5» диску и, чтобы от нее избавиться, достаточно убрать флопик из конфигурации виртуальной машины:
Способ посложнее: использовать компонент Datastore Browser из vSphere клиента: в папке виртуальной машины на датасторе после создания quiesced снапшота должен появиться файл***vss_manifests*.zip.
Внутри файла содержится backup.xml с описанием всех найденных VSS writers в гостевой системе + метаданные по каждому райтеру в writerX.xml.
ВАЖНО: если в vss_manifests.zip содержится только backup.xml — это как правило означает, что снапшот по факту был сделан без использования VSS. Таким образом мы плавно подходим к самому интересному: исследованию проблем со снапшотами. Ниже я перечислю основные причины неработающих снапшотов. Стоит отметить, что основную опасность представляют не неработающие снапшоты (их легко детектировать), а именно те, которые VMware рапортует как успешные, в то время как данные снапшоты не являются таковыми.
Требования к окружению
Если с полезностью опции quiescing все более менее понятно, то при практическом использовании часто возникают проблемы, как правило связанные с некорректностью изначальной конфигурации окружения. Официальное описание части требований находится здесь, и я попытаюсь раскрыть их более наглядно, чтобы было понятно куда смотреть, когда вы столкнетесь с проблемами на практике:
Во-первых, убедитесь, что ваша комбинация vSphere + гостевой ОСи поддерживается для снапшотинга с консистентностью на уровне приложений по данной табличке (взята отсюда).
Данные актуальны для vSphere 5.0 и выше. Как вы можете заметить, для самых популярных на данный момент ОС (Windows 2008 и выше) стоят звездочки — в них то и зарыта главная собака, раскопками которой мы сейчас займемся.
Во-вторых, для того, чтобы quiescing реально работал, необходимо убедиться, что VSS компоненты VMware Tools действительно установлены (и естественно VMware Tools должны быть самой актуальной версии).
На старых версиях vSphere (3.5 и ранее) для quiescing использовался в том числе Legato Sync Driver, который гарантировал консистентность на уровне файловой системы, но не на уровне приложений (для чего как раз и нужны VSS компоненты). В настоящее время этот драйвер практически не используется и повсеместно заменен на VMware Snapshot Provider. Корректность установки можно проверить в гостевой операционной системе (на виртуальной машине) по наличию сервиса VMware Snapshot Provider + соответствующего COM+ компонента.
Какие могут быть косяки на данном этапе?
Если сервис VMware Snapshot Provider отключен, либо совсем не установлен, то VMware при снятии снапшота с опциями quiescing = ON, snapshot memory = OFF отрапортует, что он успешен, однако по факту снапшот будет произведен без использования VSS внутри системы, то есть посредством Legato Sync драйвера.
Заметьте, что в случае Windows 2008 и выше поведение отличается — там подобных событий в логе не наблюдается, а просто сервис Volume Shadow Copy переходит в запущенное, а затем в остановленное состояние.
Эта настройка имеет смысл только для гостевых систем под управлением Windows 2008 и выше (для Windows 2003 настройка игнорируется). Дополнительной особенностью является тот факт, что данный параметр автоматически прописывается при создании новой виртуальной машины только начиная с vSphere 4.1. Другими словами если виртуальная машина была смигрирована с более старой версии vSphere, то настройки может и не быть.
При отсутствии параметра, или же если он выставлен в «false», поведение при создании снапшота будет аналогично предыдущему случаю: снапшот создастся успешно, но по факту VSS будет не задействован и в результате мы можем получить неконсистентный бэкап. Второй симптом отключенного параметра — это пустой backup.xml (без описания VSS райтеров) в vss_manifests.zip.
В-четвёртых, проверьте наличие динамических дисков внутри гостевой машины. Если внутри гостевой системы будет присутствовать хоть один динамический диск — не важно системный он или нет, то VSS задействован не будет. Снапшот будет создаваться успешно, но vss_manifests.zip будет пустым, как и логи событий внутри гостевой ОСи. Это правило действует для гостевых ОСей Windows 2008 и выше.
То же самое касается IDE дисков — их не должно быть в конфигурации виртуальной машины (но наличие IDE CD-ROM устройств допустимо и на снапшоты не влияет). При этом надо учитывать, что количество свободных SCSI слотов на одном SCSI контроллере должно быть равно количеству дисков. Например: если на SCSI1 уже присутствуют 8 SCSI дисков, то слотов не хватит.
Данная проблема была решена банальной перезагрузкой виртуальной машины, и хотя такой метод помогает очень часто, бывают запущенные случаи, когда VSS внутри сломан чуть менее, чем полностью. В этих случаях самый простой способ выяснить, действительно ли Microsoft виноват — это запустить Windows Backup и сделать резервную копию системного состояния (Backup of System State, если кто привык к английским терминам). Windows Backup (или NTBackup) работает — то проблема на стороне VMware, не работает — косяк Microsoft.
У VMware на эту тему есть несколько официальных статей: например тут и тут. Но есть интересная особенность — для упрощения себе жизни (возможно есть и какие-нибудь другие причины) во второй статье VMware в явном виде рекомендует выставить disk.EnableUUID в «false», что означает отказ от использования VSS при создании quiesced снапшота («quiesced-то не настоящий!»). В общем случае такой метод является не решением, а только временным обходным путем, так как последствия подобного подхода могут проявить себя при восстановлении, то есть именно тогда, когда консистентность приложений является ключевой (вспомнить хотя бы тот же USN rollback).
Подводим итоги
По моему опыту, самыми частыми проблемами при создании снапшотов (их неконсистентность) являются пункты 2, 3 и 5, в то время как IDE или динамические диски встречаются гораздо реже.
Конечно же, не исключены и совершенно мистические случаи: например снапшот не создавался (VMware рапортовала невнятную ошибку) по причине того, что iSCSI LUN (датастор), на котором располагалась проблемная виртуальная машина, был подключен физически через 2 сетевые карты в режиме teaming и при этом одна работала на 100MBit, а вторая на 1Gbit.
Тему quiesced снапшотов можно копать чуть ли не вечность — чего стоит хотя бы факт того, что Windows 2008 при создании quiesced снапшота создает не одну, а две дельты на датасторе и по факту пишет в уже созданный снапшот (это, кстати, одна из корневых причин звездочек напротив данных ОСей в табличке выше); или наличие возможности отключать определенные VSS райтеры через конфигурацию vmbackup.conf на гостевой системе. Мир чудесен и удивителен, но граблей хватит на всех. Если будет желание — я с радостью напишу что-нибудь ещё на эту тему. Как обычно, комментарии привествуются, уточнения — тоже, об ошибках и опечатках — в личку, на вопросы постараюсь ответить asap.
Не забывайте подписываться на наш Хаб, у нас запланировано огромное количество статей на тему бэкапа и восстановления данных, быть может, именно наши статьи помогут вам решить определённые проблемы (а лучше — избежать их). Спасибо за внимание. 🙂
Работа со снимками (SnapShots) состояния виртуальных машин в программе VMware Workstation 10
Процедура восстановления гостевых операционных систем (далее — ОС) из ранее созданных снимков состояния (их ещё называют снапшоты от англ. SnapShot) в программах виртуализации (гипервизорах) Hyper-V, VirtualBox и VMware Workstation – это своеобразный аналог различных механизмов отката системы. Вернуть основную ОС в прежнее состояние можно как с помощью штатного функционала, так и посредством сторонних программ в числе возможностей которых – восстановление системы из ранее сохранённой резервной копии. Гостевую ОС, установленную на виртуальной машине гипервизора, не обязательно переустанавливать, если эксперименты с системными настройками или с установкой сомнительного софта окажутся неудачными. В этих случаях, а также в случаях проникновения вредоносного ПО или возникновения прочих проблем с системой гостевую ОС можно откатить с помощью механизма воссоздания из ранее сохранённых снимков её состояния. Ниже рассмотрим специфику работы со снапшотами в программе для виртуализации ОС — VMware Workstation 10.
0. Оглавление:
1. Создание снимка состояния гостевой ОС в VMware Workstation 10
Создать снимок состояния гостевой ОС можно и тогда, когда она включена, и когда она выключена. В последнем случае гостевую ОС, естественно, нужно выбрать в списке библиотеки VMware Workstation 10.
Чтобы создать снимок состояния гостевой ОС, вверху в горизонтальном меню окна VMware Workstation 10 жмём «Виртуальная машина», а в перечне этого меню – «Снимок состояния». Появится выпадающий список возможных функций, среди которых выбираем первую — «Создать снимок состояния».
В появившемся небольшом окошке программа предложит задать снапшоту имя и придумать ему описание. Описание – необязательное требование, оно реализовано скорее для удобства работы с гипервизором, когда скапливается масса снимков состояния гостевой ОС. В принципе, можно прямо в названии кратко описать специфику снапшота – например, «До установки такой-то программы» или «До смены таких-то системных настроек». Далее жмём кнопку «Создать снимок».
VMware Workstation 10 создаст снимок состояния системы, и он появится в «Диспетчере снимков состояния» — программном разделе, где хранятся все снапшоты гостевой ОС. Попасть в «Диспетчер снимков состояния» можно через меню «Виртуальная машина» — «Снимок состояния».
Всё – точка возврата системы создана, и можем делать с ней всё что угодно – экспериментировать с настройками, в которых пока что не разбираемся, устанавливать различные программы с непроверенных интернет-ресурсов, внедрять всякие программные патчи и делать прочие исследовательские вещи.
Снимок состояния можно создавать после каждого серьёзного изменения гостевой ОС, затем возвращаться к предыдущему — который ещё без изменений. А в случае необходимости можно снова сменить снимок состояния без изменений на снимок с изменениями. Главное – иметь ту самую базовую точку невозврата в идеальном состоянии системы, к которой можно было бы постоянно возвращаться, перепрыгивая с не совсем удачных линий событийности системы. Кроме этого, возврат к снимку состояния системы – процедура, занимающая гораздо меньше времени, чем деинсталляция с зачисткой остатков удаляемых программ.
2. Восстановление гостевой ОС из снимка состояния в VMware Workstation 10
Чтобы восстановить гостевую ОС из сохранённого ранее снимка состояния, проходим тот же путь, что и для создания снимка – меню «Виртуальная машина» — «Снимок состояния». В выпадающем списке функций жмём «Вернуться к снимку:…». По умолчанию кнопка автоматически подставит к этой функции последний снимок состояния, чтобы действие можно было провернуть в один клик.
Если же автоматически установлен не тот снимок состояния, который нужен в данный момент, здесь же, в выпадающем списке нужный снимок можно выбрать из перечня «Диспетчера снимков состояния». В перечне отображаются названия снимков состояния и дата, когда они были созданы.
«Диспетчер снимков состояния» и вовсе можно открыть, чтобы выбрать нужный снапшот не только по названию и дате, но и исходя из заданных ранее описаний.
Определившись с нужным снимком состояния, кликаем его, чтобы восстановить гостевую ОС. Свои намерения подтверждаем, когда в появившемся окошке VMware Workstation 10 дополнительно запросит, действительно ли серьёзны наши намерения. Жмём «Да».
VMware Workstation 10 проведёт перезапуск гостевой ОС.
После этого система будет представлена в том состоянии, в котором ранее был создан снимок.
3. Работа с «Диспетчером снимков состояния»
Если постоянно создавать снимки состояния гостевой ОС, желательно периодически проводить работу с «Диспетчером снимков состояния». Большое количество снимков состояния будет захламлять дисковое пространство компьютера, да и работа в условиях хаоса файлов редко когда бывает эффективной. В уже знакомом меню «Виртуальная машина» — «Снимок состояния» жмём «Диспетчер снимков состояния».
Откроется окно с визуальным представлением имеющихся снимков состояния. Здесь снимки состояния можно:
4. Предостережения при работе со снимками состояния гостевой ОС
С последней функцией «Диспетчера снимков состояния» нужно обращаться предельно аккуратно, особенно, если файл виртуальной машины размещается на системном диске. Автоматически программа может создать огромное число снапшотов, которые будут занимать много места на диске.
В случае с системным диском это может привести к снижению производительности системы и к появлению надоедливых уведомлений Windows о нехватке дискового пространства.
Так что для полноценной работы со снапшотами файл виртуальной машины лучше перенести на несистемный диск. По умолчанию программа VMware Workstation 10 размещает файл виртуальной машины в папке пользовательского профиля:
«C:\Users\Имя_Пользователя\Documents\Virtual Machines\Имя_файла».
Желательно отсюда этот файл перенести.
И перенести, например, в специально созданную для хранения виртуальных машин папку на несистемном диске.
После переноса файл виртуальной машины нужно открыть для отображения и работы в главном окне VMware Workstation 10.
Смотрите также:
Ошибки в работе системы, её сбой, внедрение вирусов и шпионского ПО – всего этого и прочих неприятностей в работе с компьютером можно избежать, если обучаться и вести эксперименты со сторонним…
Для работы с виртуальными машинами на рынке десктопного софта существует, по сути, только две программы – это VMware Workstation и VirtualBox. Все остальные либо малоизвестны, либо с ограниченным функционалом, либо…
Виртуальные машины VirtualBox и VMware Workstation всем хороши для тестирования операционных систем и софта, только вот почему-то ни одна из этих программ-гипервизоров не предусматривает в нормальном юзабельном формате опцию загрузки…
3 Responses to Работа со снимками (SnapShots) состояния виртуальных машин в программе VMware Workstation 10
Отличный материал. Прекрасное изложение (если только чуть затянутое). Изумительные иллюстрации (лучшие видел только в МВТУ в исполнении Юрия Этумовича Шарикяна, единственной рукой чертившего эпюры начертательной геометрии цветными мелками). Во истину, знают многие, но научить, просто и доходчиво изложить дано далеко не каждому. Был учеником лучших преподавателей, по настоящему великих легендарных учёных, то есть имеется основа для сравнения. Благодарю Наташа, особенно за трудолюбие.
Спасибо за лестный отзыв. Была бы признательна, если бы вы уточнили, что именно затянуто или какие изложенные факты — это банальщина.