Серверная виртуализация

Клоны, шаблоны и снимки виртуальных машин: безопасная работа в vSphere

Чем клон, шаблон и snapshot VM отличаются на практике и как создать, проверить и удалить снимок в VMware vSphere без лишнего риска для данных.

14 минут
абстрактная иллюстрация состояний и копий виртуальной машины
Клон — отдельная копия VM, шаблон — эталон для развёртывания новых машин, а snapshot фиксирует состояние уже существующей VM на ограниченное время. В VMware vSphere снимок обычно создаёт зависимую цепочку файлов изменений, поэтому подходит для контролируемого обновления или теста с заранее назначенным сроком удаления, но не заменяет независимую резервную копию и проверку восстановления.

Выбор объекта зависит от цели, а не от схожих названий операций.

ОбъектНазначениеСамостоятельность файловТипичный срок жизниПример применения
Клон виртуальной машиныПолучить отдельную VM на основе существующейПолный клон обычно независим; связанный клон зависит от базового образаПостоянный или до окончания тестаИзолированная копия для разработки, теста обновления или новой роли
Шаблон виртуальной машиныПовторяемо разворачивать новые однотипные VMЭто эталонный объект платформы, а не рабочая копия запущенной VMПока образ актуаленРазвёртывание серверов с одинаковой ОС и базовой конфигурацией
Snapshot виртуальной машиныКратко зафиксировать точку перед контролируемым изменениемЗависит от базовых дисков VM и файлов измененийОт минут или часов до завершения операцииОбновление приложения с заранее определённой проверкой и откатом

Клон, шаблон и snapshot: что выбирать

Полный клон получает собственную конфигурацию и отдельные виртуальные диски. После завершения клонирования исходную VM можно изменять, выключать или удалять без штатной зависимости нового полного клона от её базовых дисков. Это подходящий вариант, когда копия должна жить отдельно: например, для тестовой среды или передачи новой команде.

Связанный клон хранит собственные изменения в разностном диске, а неизменённые блоки читает из общего базового образа. Он экономит место и ускоряет массовое развёртывание, но создаёт зависимость от исходного объекта и его хранилища. Такой механизм встречается, в частности, в сценариях VDI и специализированных средствах развёртывания; не следует ожидать, что обычная операция VMware cloning в любом выпуске vSphere предложит linked clone.

Шаблон не предназначен для возврата работающей VM в прошлое состояние и не является её резервной копией. Обычно из подготовленной VM создают template, а затем разворачивают из него новые экземпляры с отдельными именами, сетевыми параметрами и дисками. Для регулярно создаваемых серверов шаблон удобнее полного клонирования уже работающей и изменённой VM.

В VMware vSphere доступность clone, linked clone, template, snapshot и менеджера снимков зависит от выпуска платформы, типа управляемого объекта, состава подписки или редакции и наличия vCenter Server. Названия команд, состав экранов и порядок действий зависят от версии vSphere Client и способа управления — через vCenter Server или напрямую через ESXi. Поддержка самой операции также может зависеть от сборки ESXi, конфигурации VM, типа хранилища и совместимости оборудования. Перед операцией сверяйте сценарий с официальной документацией Broadcom для своего релиза; развёртывание vCenter описано отдельно в статье «VMware vSphere и vCenter Server: установка VCSA и добавление хостов».

Когда нужен клон, а когда шаблон

1. Когда нужен клон, а когда шаблон
Применение:Нужно создать пять одинаковых серверов для новой службы и отдельно проверить обновление существующей бухгалтерской VM.
Почему:Для новых серверов подготовьте и сопровождайте шаблон: это снижает различия между экземплярами. Для проверки обновления создайте полный клон либо используйте краткий snapshot исходной VM только при наличии окна работ, свободного места и плана удаления. Если проверка должна быть изолирована и продолжаться долго, предпочтителен полный клон.
Шаблон стандартизирует начальное состояние новых VM.Полный клон отделяет эксперимент от исходной VM.Краткий snapshot даёт точку возврата перед изменением, если срок его удаления назначен заранее и цепочка контролируется.

Что сохраняет snapshot виртуальной машины

Снимок в vSphere фиксирует конфигурацию VM и состояние её виртуальных дисков на момент создания. После этого новые записи на поддерживаемые виртуальные диски направляются в файлы изменений. Состав снимка зависит от выбранных параметров и конфигурации VM: некоторые диски и устройства могут не участвовать в операции.

РежимЧто означаетКогда выбиратьОграничения
Без памяти и без quiescingФиксируются конфигурация и состояние поддерживаемых виртуальных дисков, но не содержимое оперативной памяти работающей VMКогда допустим перезапуск или обычная загрузка гостевой ОС после откатаОткат не возвращает выполнявшиеся процессы в точку снимка; состояние дисков работающей VM обычно будет crash-consistent, то есть подобным состоянию после внезапного отключения
С памятью VMДополнительно сохраняются память и состояние питания работающей VM, поэтому после возврата выполнение может продолжиться с зафиксированной точкиДля короткого теста, в котором важно сохранить текущий сеансТребует дополнительного времени и места, не обеспечивает прикладную согласованность автоматически и в vSphere не совмещается с quiescing гостевой файловой системы
Без памяти, с quiescing гостевой файловой системыVMware Tools через поддерживаемый механизм гостевой ОС пытается привести файловую систему в согласованное состояние перед фиксацией дисковПеред краткой операцией над файловыми данными, если сочетание гостевой ОС, VMware Tools и конфигурации поддерживаетсяНе сохраняет выполнявшиеся процессы, не заменяет прикладное согласование СУБД и может быть недоступен для конкретной гостевой ОС или конфигурации

Параметр согласования гостевой файловой системы, часто называемый quiescing, требует установленных и работоспособных VMware Tools, совместимой версии инструментов и поддержки со стороны конкретной гостевой ОС. vSphere использует доступные гостевые механизмы, например VSS в поддерживаемых Windows-гостях. До операции проверьте состояние Tools и совместимость, а после неё — событие и статус задания. Если Tools отсутствуют или не работают, ОС не поддерживает согласование либо задание сообщает об ошибке quiescing, не считайте снимок согласованным: выберите процесс на уровне приложения или перенесите работы в окно остановки.

Согласованный снимок — не резервная копия приложения

Даже успешно созданный quiesced snapshot может не включать прикладную логику фиксации транзакций, внешние данные или состояние сервисов вне VM. Для СУБД и иных транзакционных систем порядок подготовки определяет документация приложения.

Поддержка snapshot зависит и от виртуального оборудования. Независимые диски обычно не включаются в снимки; физические RDM, отдельные режимы RDM, диски с совместным доступом и некоторые подключённые устройства могут ограничивать создание, применение или удаление снимка. Не пытайтесь обходить ограничение отключением или ручным перемещением файлов: проверьте тип каждого диска и устройств в официальной документации именно для используемого релиза vSphere. Допустимая глубина цепочки и рекомендуемый срок её жизни также нельзя переносить между релизами и конфигурациями как универсальное правило.

Безопасный сценарий создания и удаления snapshot в VMware vSphere

Перед началом проверьте, что базовая инфраструктура ESXi, VM и datastore уже подготовлена. Создание VM и хранилища рассмотрено в статье «Установка и первичная настройка VMware ESXi: хост, VM, datastore и vSwitch».

Создание, проверка и удаление snapshot

Порядок применим к типичной операции перед обновлением одной VM. Команды интерфейса ищите в действиях выбранной VM и в менеджере снимков своего vSphere Client; точные названия зависят от релиза.

  1. 1
    Определите цель, окно и точку остановки
    Запишите, какое изменение выполняется, кто отвечает за проверку, когда снимок будет удалён и при каком результате нужен откат. Согласуйте окно работ: создание и особенно объединение изменений могут повысить задержки VM. Ожидаемый результат — есть конкретное изменение, время начала и условие завершения. Если нельзя назвать срок удаления, не создавайте snapshot как «страховку на потом».
  2. 2
    Проверьте независимую копию и возможность восстановления
    Убедитесь, что существует актуальная независимая резервная копия и известен результат её последней проверки восстановления. Снимок на том же datastore не защитит от потери самого хранилища или базовых файлов VM и сам по себе не обеспечит доступность при отказе хоста. Ожидаемый результат — зафиксированы время последней успешной копии и процедура обращения к ней. Если такой копии нет, оцените риск отдельно либо перенесите изменение.
  3. 3
    Проверьте VM и свободную ёмкость datastore
    Проверьте отсутствие старых снимков и активных задач с дисками VM, состояние datastore, скорость роста данных VM и запас свободного места. Учитывайте не только рост нового delta-файла во время работ, но и место, которое потребуется для объединения изменений. Ожидаемый результат — datastore имеет контролируемый запас для ожидаемого роста и консолидации. При дефиците места сначала освободите или расширьте ёмкость штатным способом; не удаляйте файлы VMDK или snapshot вручную.
  4. 4
    Выберите параметры состояния
    Решите, требуется ли память VM и поддерживаемое согласование гостевой файловой системы. Для quiescing проверьте VMware Tools, поддерживаемость гостевой ОС и отсутствие ошибок службы Tools. Ожидаемый результат — выбранный режим соответствует цели: без памяти для обычного краткого отката либо с памятью, если важен текущий сеанс. Если согласование недоступно, не интерпретируйте обычный crash-consistent снимок как согласованный.
  5. 5
    Создайте снимок и зафиксируйте его время
    Запустите штатную операцию создания snapshot для нужной VM, задайте понятное имя и описание с причиной, временем удаления и номером изменения. Дождитесь завершения задачи и проверьте события VM и состав цепочки в менеджере снимков. Ожидаемый результат — задача завершена без предупреждений, снимок виден в интерфейсе, а время создания записано в журнале работ. При ошибке не повторяйте операцию многократно: сохраните текст события и проверьте datastore, совместимость дисков и Tools.
  6. 6
    Выполните одно запланированное изменение
    Не объединяйте под одним снимком несвязанные обновления. После изменения проверьте запуск нужной службы, прикладную функцию, журналы и доступность данных в объёме, определённом планом. Ожидаемый результат — изменение принято либо принято решение об откате. Если результат неясен, остановите расширение работ: время жизни snapshot продолжает увеличивать цепочку изменений.
  7. 7
    Удалите snapshot после успешной проверки
    После подтверждения результата штатно удалите конкретный снимок либо всю цепочку, если это соответствует плану. Дождитесь окончания задачи, наблюдая за событиями VM и свободным местом datastore. Ожидаемый результат — операция завершена успешно, а нужные снимки исчезли из менеджера. Возможны временные задержки VM: они зависят от объёма изменений, производительности хранилища и свободной ёмкости.
  8. 8
    Проверьте необходимость консолидации
    После удаления убедитесь, что vSphere не показывает предупреждение о необходимости консолидации и что на datastore не осталось несведённых файлов изменений по данным платформы. Ожидаемый результат — цепочка снимков отсутствует и предупреждений нет. Если появляется требование consolidation, не удаляйте файлы вручную: оцените свободное место, блокировки и события, затем запускайте штатную консолидацию.

Почему snapshot занимает много места и замедляет операции

После создания снимка базовый виртуальный диск становится точкой отсчёта, а последующие изменённые блоки записываются в зависимые delta-файлы. Чем дольше VM активно пишет данные — обновляет ОС, журналы, базы, почту, временные файлы, — тем больше может стать delta. Размер определяется объёмом изменённых блоков, а не только длительностью существования снимка: малоактивный snapshot может расти медленно, а интенсивная VM способна быстро исчерпать место datastore.

Длинная цепочка увеличивает число уровней, по которым платформа сопоставляет данные при чтении и записи, усложняет миграции, обслуживание и удаление. Позднее удаление крупного snapshot требует применить накопленные изменения к родительскому диску или элементам цепочки; это создаёт заметную нагрузку на хранилище. Поэтому ошибка «snapshot занимает много места» — повод не удалять файлы из datastore вручную, а остановить неконтролируемый рост, проверить запас места и выполнить штатную операцию в согласованное окно.

Delete snapshot, Delete All и консолидация snapshot VMware

ОперацияЧто делаетЧто проверить после
Delete snapshotУдаляет выбранный снимок из цепочки и применяет его изменения к соответствующему родительскому элементуСтатус задачи, свободное место, отсутствие новых предупреждений
Delete AllУдаляет все снимки VM и запускает объединение накопленных изменений по цепочкеЗавершение всех задач, производительность VM и состояние datastore
ConsolidateСводит оставшиеся файлы изменений с базовыми или родительскими дисками, когда снимки уже не отображаются либо их очистка ранее завершилась не полностьюИсчезновение предупреждения о необходимости консолидации и успешное завершение задачи

Удаление snapshot — это не всегда мгновенное исчезновение всех файлов. Сначала платформа должна объединить данные цепочки. Предупреждение о необходимости консолидации обычно появляется, когда операция со снимком не смогла полностью очистить или объединить связанные файлы, хотя в интерфейсе может уже не быть ожидаемого снимка. Консолидация не является альтернативой плановому Delete snapshot: это штатное завершение оставшейся дисковой работы.

Проблема

Консолидация snapshot VMware не завершается

Возможные причины

  • Недостаток свободного места для объединения изменений.
  • Высокая нагрузка VM или хранилища.
  • Блокировка файлов, параллельная задача либо недоступность части хранилища.
  • Конфигурация дисков или устройств, не поддерживающая ожидаемую операцию.

Решение

Зафиксируйте точный текст ошибки и время события. Проверьте свободную ёмкость datastore, состояние хоста и хранилища, активные задачи, типы дисков и предупреждения VM. При необходимости остановите несрочные записи в госте и согласуйте окно работ, затем повторите штатную консолидацию по документации своего релиза. Не переименовывайте, не перемещайте и не удаляйте вручную VMDK, delta-файлы и файлы конфигурации. Если причина неочевидна, продолжите по маршруту статьи «Диагностика проблем виртуальных машин и гипервизоров: запуск, сеть, диски и миграция».

Как избежать

Не держите снимки дольше согласованного окна, контролируйте их возраст и рост, а перед удалением или Delete All проверяйте запас datastore.

Не удаляйте файлы snapshot вручную

Файлы базовых дисков и delta-файлы образуют зависимую цепочку. Ручное удаление из datastore может повредить VM или лишить её данных. Для удаления и восстановления используйте только штатные операции vSphere и документированный план устранения ошибки.

Почему snapshot не заменяет резервную копию

Snapshot обычно хранится вместе с файлами VM или на связанном с ними хранилище и зависит от базовых виртуальных дисков и остальных элементов цепочки. При недоступности или повреждении этого хранилища снимок не становится независимым источником восстановления. Он полезен как краткая точка возврата перед известной операцией, но не заменяет отдельное хранение копии, определённые цели восстановления и периодическую проверку, что из копии действительно поднимается нужная служба.

Откат snapshot также не отвечает сам по себе на вопрос, будут ли согласованы данные приложения: это зависит от режима снимка, гостевой ОС, VMware Tools и поведения приложения. Вопросы выбора системы резервного копирования, хранения копий и проектирования восстановления выходят за рамки этой инструкции; общие границы защиты VM разобраны в статье «Серверная виртуализация: что это, как работает и зачем нужна».

Hyper-V и Proxmox VE: похожие слова, разные механизмы

В Hyper-V используется термин checkpoint. Standard checkpoint сохраняет состояние конфигурации, дисков и памяти работающей VM, тогда как production checkpoint ориентирован на согласованное дисковое состояние через поддерживаемые гостевые службы. Доступность production checkpoint зависит от версии Windows Server, гостевой ОС и интеграционных компонентов. Не следует механически приравнивать любой checkpoint к каждому режиму VMware snapshot; создание VM и настройка Hyper-V описаны в статье «Установка и настройка Hyper-V на Windows Server: роль, VM и сеть».

В Proxmox VE доступность snapshots и linked clones зависит от типа объекта — VM или LXC — и выбранного storage. Поэтому экспорт виртуальной машины Proxmox, клон, шаблон и snapshot нельзя считать взаимозаменяемыми операциями: экспорт создаёт переносимый результат в поддерживаемом формате, а snapshot обычно остаётся зависимым от хранилища исходного объекта. Требования конкретных storage и подробный порядок работы с VM, LXC и встроенной защитой приведены в статье «VM, LXC, кластер, HA и резервное копирование в Proxmox VE: порядок настройки».

Термины в статье

Виртуальное оборудование — логическая аппаратная платформа, которую гипервизор предоставляет ВМ: виртуальные процессоры, память, устройства и системную прошивку.
Создание копии виртуальной машины как отдельной ВМ; полный клон независим от исходной ВМ, а связанный использует её базовые виртуальные диски.
Консолидация снимков — операция объединения оставшихся файлов изменений снимка с базовыми или родительскими дисками ВМ после удаления снимка либо сбоя очистки.
Полный клон — независимая копия виртуальной машины, в которой виртуальные диски и конфигурация создаются отдельно от исходной ВМ и не требуют её базового диска.
Производственная контрольная точка — контрольная точка Hyper-V, создаваемая с помощью служб согласования гостевой ОС для фиксации дисков ВМ в состоянии, пригодном для резервного копирования.
Процесс — экземпляр выполняемой программы в Linux с PID, виртуальным адресным пространством, состоянием и связанными с ним ресурсами.
Разностный диск — дочерний виртуальный диск, хранящий только блоки, изменённые относительно неизменяемого родительского диска; чтение обращается к обоим слоям.
Связанный клон — виртуальная машина, которая читает неизменённые блоки из общего базового образа, а собственные изменения хранит в отдельном разностном диске.
Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
Подготовленный объект платформы виртуализации с образом ОС и заданной конфигурацией для повторяемого развертывания новых виртуальных машин.
Контрольная точка Hyper-V — сохранённое состояние конфигурации и виртуальных дисков ВМ для отката; стандартная точка также сохраняет память работающей ВМ.
Логический контейнер хранилища в VMware для размещения файлов виртуальных машин (диски, конфигурации, логи)
Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
Платформа виртуализации Microsoft с гипервизором типа 1, доступная как роль Windows Server и компонент Windows 10/11 Pro, Enterprise и Education.
LXC — набор инструментов и библиотек для создания и запуска системных Linux-контейнеров, изолирующих процессы, сеть и файловую систему при общем ядре с хостом.
Открытая платформа серверной виртуализации на базе Debian, использующая QEMU/KVM для виртуальных машин и LXC для системных Linux-контейнеров.
Централизованная система управления инфраструктурой VMware для администрирования множества ESXi хостов из единого интерфейса
VDI — архитектура, в которой пользовательские рабочие столы выполняются в виртуальных машинах на централизованной инфраструктуре, а пользователи подключаются к ним удалённо.
VMDK — формат виртуального диска VMware, в котором данные блочного устройства гостевой ОС хранятся в одном или нескольких файлах.
VMware — бренд Broadcom и семейство продуктов виртуализации; серверная платформа vSphere объединяет гипервизор ESXi и средства управления vCenter Server.
VMware ESXi — гипервизор типа 1, устанавливаемый непосредственно на совместимый физический сервер для запуска и управления виртуальными машинами.
Набор гостевых драйверов и служб VMware, улучшающий интеграцию виртуальной машины с гипервизором и средствами управления.
Платформа виртуализации VMware, включающая гипервизор ESXi и средства управления vCenter для корпоративной инфраструктуры

Вопросы по теме

Все вопросы и ответы

Можно ли использовать шаблон VM для отката работающей машины?

Нет. Шаблон — это эталон для развёртывания новых однотипных виртуальных машин, а не точка возврата для уже работающей VM. Из template создают новые экземпляры с отдельными именами, сетевыми параметрами и дисками. Для краткого отката перед известным изменением используют snapshot, а для независимой копии — полный клон.

Можно ли удалить исходную VM после полного клонирования VMware?

Да, после успешного создания полного клона исходную VM можно изменять, выключать или удалить: новый полный клон имеет собственную конфигурацию и отдельные виртуальные диски. Это не относится к связанному клону: он читает неизменённые блоки из общего базового образа и зависит от исходного объекта и его хранилища.

Чем Hyper-V production checkpoint отличается от standard checkpoint?

Production checkpoint ориентирован на согласованное состояние дисков через поддерживаемые гостевые службы, а standard checkpoint сохраняет конфигурацию, диски и память работающей VM. Доступность production checkpoint зависит от версии Windows Server, гостевой ОС и интеграционных компонентов. Его не следует механически приравнивать к каждому режиму snapshot в VMware vSphere.

Почему snapshot виртуальной машины занимает много места?

Потому что после создания snapshot все изменённые блоки виртуальных дисков записываются в зависимые delta-файлы. Их размер зависит не только от времени жизни снимка, но и от интенсивности записи: обновлений, журналов, баз данных и временных файлов. При удалении крупного snapshot также нужно место и ресурсы хранилища для объединения изменений.

Что делать, если vSphere требует консолидацию snapshot?

Требование консолидации означает, что vSphere не смогла полностью очистить или объединить связанные файлы изменений после операции со снимком. При этом snapshot может уже не отображаться в интерфейсе, но дисковая цепочка ещё требует штатного завершения.

Сначала проверьте запас свободного места на datastore: его нехватка может сорвать объединение изменений. Также оцените нагрузку VM и хранилища, наличие параллельных задач, предупреждения VM, доступность хранилища и возможные блокировки файлов. Уточните типы виртуальных дисков и подключённых устройств, поскольку отдельные конфигурации могут ограничивать ожидаемую операцию.

Если возможно, снизьте несрочные записи в гостевой ОС и выполняйте консолидацию в согласованное окно. После штатного запуска Consolidate дождитесь завершения задачи и убедитесь, что предупреждение исчезло. Не переименовывайте, не переносите и не удаляйте вручную VMDK, delta-файлы или файлы конфигурации: это может повредить VM и её данные.

Можно ли удалить snapshot VMware вручную из datastore?

Нет. Базовые VMDK и delta-файлы snapshot образуют зависимую цепочку, и ручное удаление или перемещение файлов может повредить виртуальную машину либо привести к потере данных. Удаляйте снимки только штатными операциями Delete snapshot или Delete All, а при остаточных файлах используйте Consolidate.