VMware Server 2.0 занимает 30 минут для удаления снимка
Старый, но интересный материал.
Когда вы создаете моментальный снимок, происходит то, что исходный диск остается неизменным, и операции регистрируются или регистрируются в файле.
Когда вы создаете снимок. отменить этот снимок, операцию, которую следовало бы назвать «отменить возможность вернуться к более ранней версии этого диска», все содержимое этого журнала или журнала применяется (фиксируется) к фактическому диску (который сохранялся без изменений до сих пор), и это может занять очень много времени, особенно если снимок старый (т. е. много операций для фиксации). Даже дольше, если другие виртуальные машины выполняют дисковые операции, которые будут иметь приоритет.
Какой диск (диски) у Вас есть поддержка этого сервера? Удаление снимков является очень IO-интенсивными-действиями (особенно, если Вы, делают это, в то время как VM работает).
У Вас есть опция переключения на хост ESXI вместо VMware Server? Вы будете видеть намного лучшую производительность с VMware, работающим на чистом металле.
-
1дисковая подсистема плоха..., Вы говорите, что ESXI намного лучше? I' ve, отказывающийся использовать ESXI, с тех пор there' s никакой хороший вариант для резервного копирования, не свободный, по крайней мере, – galets 12 October 2009 в 02:55
-
2Производительность попытка быть лучше на ESXI вследствие того, что, путем удаления посторонней хостовой операционной системы, you' ре, избавляющееся от одного слоя абстракции между гостем VM и чистым металлом. Относительно резервных копий, если I' m ошибочный, ситуация isn' t какое-либо лучшее использование VMware Server, корректный? Для получения последовательных с катастрофическим отказом резервных копий на любой платформе необходимо приостановить VMs, затем скопировать файлы от vmfs. – EEAA 12 October 2009 в 03:39
-
3Я предполагаю что я don' t понимают, то, что точно является выполнением сервера VMware при удалении снимка, почему должно потребоваться так много ввода-вывода и время. Если ESXI отличается, это не может быть просто операционная система, мои выполнения сервера в соответствии с Linux с очень немногими дополнительными включенными подсистемами. Должны быть некоторые основные различия. И резервно-мудрый: это легче на стандартном Linux, существует rsync, rdiff-резервное-копирование и многое другое. Я понятия не имею, как поместить тех, которые на ESXI – galets 12 October 2009 в 07:32
-
4Я верю всем изменениям, которые были зарегистрированы к файлу снимка, должен быть применен к изображению фактической дисковой емкости. ESXI использует более сложную технологию снимков и не страдает таким образом. – Roy 13 October 2009 в 16:27
Относительно VMware, занимающего время для возвращения снимок:
Поскольку я понял, что это, удаляя снимок (т.е. сохраняя изменения и удаляя способность вернуться) является просто вопрос удаления файлов снимка.
Это указывает мне, что VMware использует изображение исходного диска, как он делает независимо от существования снимка или нет. Однако, когда снимок был взят, он также пишет "дельту" - данные к файлу снимка.
Это означает последнюю версию файлов, поскольку они замечены в VM, находится в изображении исходного диска, и различие между этими файлами и снимком находится в файлах снимка.
При возвращении снимка VMware затем "отменил" бы все изменения, поскольку они регистрируются в файлах снимка, достигая состояния того, когда снимок был взят, когда все изменения были отменены.
Я предполагаю этот способ, которым "оперативный" ввод-вывод может быть расположен по приоритетам по "созданию снимков" ввод-вывод.
Я уверен, что рытье вокруг в архивах VMware дало бы еще лучший ответ, но я живо, который это - то, как оно работает.
/H