У нас есть дерево из примерно 15 снимков виртуальной машины, на которой работает Win2k8, как вы, наверное, догадались, в нашем хранилище данных скоро закончится место. Моя цель - удалить все снимки, так как использование снимков для резервного копирования было большой ошибкой.
Теперь мой вопрос заключается в том, как удалить снимки, чтобы для процесса слияния использовалось наименьшее количество места в хранилище данных, так как осталось не так много места. Начинаем ли мы удалять дерево снизу вверх, т.е. начать с удаления самого последнего снимка и двигаться вверх, или мы начнем удалять самые старые снимки и двигаться вниз?
ЗАЧЕМ у вас есть «дерево из 15 снимков»? я тебя знаю жестяная банка но это не значит, что это разумный способ делать что-то, о клонах или резервных копиях когда-либо слышали - они предназначены для долгосрочного хранения копий виртуальных машин на определенный момент времени, снимки просто используются неподготовленными, как они думают, «свободны» - это не так.
В любом случае, это ваш беспорядок, и нет реального выхода из него, кроме как просто жить со временем, которое потребуется, чтобы удалить их все вручную, от самых новых до самых старых.
Чтобы минимизировать пространство, используемое во время консолидации:
Выключите виртуальную машину. Таким образом удаляется файл подкачки (размер настроенной зарезервированной ОЗУ), и вам не нужно беспокоиться о том, что временный файл моментального снимка, который создается при удалении моментальных снимков, съедает ваше свободное пространство, пока вы удаляете моментальные снимки.
Удалить из СТАРЫЙ снимок сначала. НАПРИМЕР. ближайший к базе. Как только этот снимок будет зафиксирован, вы увеличите свое дисковое пространство. Если вы начнете с самого нового снимка, самого дальнего от базы, вы перенесете изменения удаленного снимка в предыдущий снимок, и он будет увеличиваться по мере продвижения к базе. Если вы используете ESXi 4.0 с обновлением 2 или новее, он сделает это за вас. Если вы используете ESXi до версии 4.0 с обновлением 2, он будет выполнять противоположные действия. ПЛЮС поддерживает все моментальные снимки до его завершения. ПЛЮС поддерживает временный моментальный снимок для записи активности во время их удаления. Таким образом, если вы используете версию до 4.0 Update 2, это КРИТИЧЕСКИЙ что вы сначала вручную удаляете самые старые и постепенно переходите к новым.
Лично, когда я нахожусь в такой ситуации, я использую эту процедуру независимо от того, над какой версией ESXi я работаю:
Эта статья на сайте VMWare указывает, что лучше всего сначала удалить самый ранний снимок (если ниже ESX4.0U2) или не беспокоиться об этом:
Для версий, предшествующих VMware ESX 4.0 Update-2, задача консолидации всех снимков (задача «Удалить все снимки») вызвала копирование уникальных изменений, хранящихся только на втором дельта-диске снимков, вверх по цепочке снимков в первый снимок или его «родитель». Этот эффект рекурсивен для каждого предыдущего родительского файла.
Пример: у вас есть базовый диск размером 8 ГБ и 2 уровня моментальных снимков по 4 ГБ каждый. Во время выполнения задач «Удалить все моментальные снимки» первый файл дельта-диска моментального снимка может увеличиться, в худшем случае, до 8 ГБ, поскольку записываются все новые блоки из второго моментального снимка. Любые общие изменения, хранящиеся на обоих уровнях снимков, не требуют дополнительного места.
Начиная с версии ESX4.0 Update 2, механизм моментальных снимков изменился. VMware ESX теперь включает улучшенные процедуры консолидации, которые уменьшают потребность в свободном пространстве. Вы можете консолидировать дельта-диски виртуальных машин даже при минимальном свободном пространстве в хранилище данных.
Если вы удаляете только некоторые из снимков или вам нужно сделать это вручную, я бы рекомендовал сначала удалить самый ранний снимок, чтобы минимизировать использование диска, иначе вы можете получить ситуацию, возникающую в приведенном выше примере.
Другой вариант - клонировать виртуальную машину в другое хранилище данных, если оно у вас есть. При клонировании все снимки сворачиваются.
Если у вас закончилось место и вы не можете удалить все снимки, клонируйте виртуальную машину в другое хранилище данных (вы можете выбрать другое место назначения для каждого виртуального диска в мастере клонирования). Все снимки сохраняются на виртуальной машине клонирования.
Кроме того, я предлагаю это прочитать как обязательное для тех, кто отвечает за операция этих серверов. (Часто являясь разработчиками.)
Рекомендации по созданию снимков виртуальных машин в среде VMware
Для тех, кто попал в этот сценарий и нашел этот форум, я надеюсь, вы прочитали все ответы, потому что Чопперс ошибается - IT_Architect прав.
Вам необходимо удалить моментальные снимки, начиная с моментального снимка БЛИЖАЙШЕГО до базового диска ... то есть моментального снимка, ближайшего к началу списка в окне диспетчера моментальных снимков. Это минимизирует потребность в свободном пространстве во время процесса удаления снимка.
Если вы следовали методу Choppers, вам понадобится тонна свободного места для успешного удаления всех снимков - чего у вас, вероятно, нет, если вы смотрите на цепочку из 15 открытых снимков!
Подумайте об этом ... только диск меняется, поскольку базовый диск хранится в первом файле моментального снимка. Второй файл моментального снимка содержит изменения по сравнению с первым файлом моментального снимка. Третий снимок содержит только изменения, внесенные после второго файла снимка. Файл базового диска НИКОГДА не будет больше, чем выделенный ему размер. Каждый файл моментального снимка может увеличиваться до того же размера, что и базовый диск. См. Пример ниже
базовый диск (100 ГБ) - snap1 (5 ГБ) - snap2 (3 ГБ) - snap3 (15 ГБ)
Весь измененный дисковый блок, который был сохранен в snap1, содержится на базовом диске. Просто эти блоки изменились с момента запуска моментального снимка, поэтому они хранятся в файле snap1.
И наоборот, размер файла snap3 составляет 15 ГБ, и все его изменения не могут содержаться в меньшем файле snap2 размером 3 ГБ. Если вы сначала удалите снимок snap3, его изменения будут объединены в файл snap2. Наименьшее возможное значение для snap2 составляет 12 ГБ после этого процесса, и это при условии, что 3 ГБ изменений в файле snap3 являются точно такими же дисковыми блоками в файле snap2. Это лучший сценарий.
Что еще хуже, во время удаления снимка snap3 файл snap3 остается в хранилище данных до тех пор, пока снимок не будет успешно удален. Таким образом, в лучшем случае вы будете использовать как минимум 12 ГБ БОЛЬШЕ места на ДИСКЕ, чтобы удалить моментальный снимок snap3 ... но вам, вероятно, понадобится больше.
Вот почему вы начинаете удалять моментальные снимки, наиболее близкие к базовому диску, потому что файл базового диска никогда не станет больше (если только он не был настроен на тонкое выделение, но это другая банка червей).