virsh snapshot-create <имя вм> - создать снапшот виртуальной машины
virsh snapshot-revert Parus <номер снапшота вм> - откатиться к нужному снапшоту
virsh snapshot-list <имя вм> - список снапшотов для данной ВМ
2. Работа с образами
Если Вы по какой то причине создали образ диска для ВМ в формате RAW, то снапшоты он не поддерживает. Перевести в формат qcow2 можно очень просто
Если Вы по какой то причине создали образ диска для ВМ в формате RAW, то снапшоты он не поддерживает. Перевести в формат qcow2 можно очень просто
не всегда правильное решение - RAW быстрее и легче в администрировании, и когда снепшоты не нужны - это лучший формат, как для файлов так и для томов LVM. более того, raw может служить основой для снепшотов, когда VM установлен на raw с него можно снять qcow2 снепшот.
кстати, снепшоты в постоянном использовании - не лучшая идея, причем это утверждают даже на курсах vmware. снепшот хорош как временная мера для снятия бекапа, после которого снепшот убирается, но в production чем длиннее цепочка снепшотов тем медленнее будет работать машина.
[quote="dyasny"]когда VM установлен на raw с него можно снять qcow2 снепшот.
Каким образом?[/quote]
Можно поступить так.
Создать например LVM том на хосте /virtual и туда кинуть виртуальный жесткий диск и уже с раздела /virtual снять snapshot lvm :) правда если там будут и другие виртуальные жесткие диски то при восстановление он их всех восстановит.
как это сделать через libvirtd? не совсем понятно.
qcow2 еще есть плюс что он имеет размер сколько использует виртуальная машина. А raw дашь 20 Гб он и будет занимать 20 хотя хостовая система его заполняет на 5 Гб.
никак, libvirtd это демон который за сторедж не отвечает.
средствами libvirt API, насколько я знаю, это не поддерживается, но это не значит что
1. форматы этого не умеют
2. qemu-img этого не умеет
более продвинутые системы управления чем простой либвирт это как раз умеют, и работают именно так из коробки.
"semperN" написал:
qcow2 еще есть плюс что он имеет размер сколько использует виртуальная машина. А raw дашь 20 Гб он и будет занимать 20 хотя хостовая система его заполняет на 5 Гб.
это называется sparse image, и тоже имеет ряд дополнительных минусов по сравнению с обычным raw - на оверхед лишней метадаты qcow2 (плюс COW алгоритм для работы собственно в снепшотах) накладывается надобность расширять диск когда он дорастает до нужного размера. по умолчанию "шаг" роста - 4к, что может очень сильно ударить по скорости записи когда большое кол-во информации надо быстро записать на sparse диск. Ну и конечно файловая система должна поддерживать sparse files.
на LVM вообще нет механизма, и приходится мониторить LV внешними средствами, и делать lvextend по мере надобности, а это операция не из "дешевых" в плане ресурсов.
Это опять же ограничение не конкретно qemu, но и любой другой системы, и qcow можно спокойно заменить на vmdk/vhd/etc...
поэтому "боевые" ВМ я всегда ставлю на raw и сразу определяю им именно столько места сколько им понадобится. Благо диски в наше время не дорогие. Если же ВМ тестовый, и важнее сэкономить место на диске чем обеспечить стабильность и скорость, то конечно можно работать на sparse
"XliN" написал:
Ага, и virsh с raw не умеет снимать снапшоты. Есть где то хавтушка с приведенным выше примером? Как это реализовать на практике.
text
[root@darth Virt]# qemu-img create -f raw base.raw 1024M
Formatting 'base.raw', fmt=raw size=1073741824
[root@darth Virt]# ls -lsa
0 -rw-r--r-- 1 root root 1073741824 May 15 13:43 base.raw
Если вм будет работать на образе формата raw и снапшоты с него делать путем переформатирования в qcow2 и потом с него снапшотить, не долго ли? В реальном времени не сделать, придется останавливать. А если сразу крутится на qcow2, то можно. Не ужели так скорость падает?
Если вм будет работать на образе формата raw и снапшоты с него делать путем переформатирования в qcow2 и потом с него снапшотить, не долго ли?
а где я предлагал переформатировать?
В реальном времени не сделать, придется останавливать. А если сразу крутится на qcow2, то можно.
live snapshot в апстриме qemu уже есть. Лигуори об этом писал. в стабильные дистры тоже скоро попадет - очень нужная фича.
Не ужели так скорость падает?
ну, смотря что делает ВМ, и насколько важна скорость его работы с диском. скажем для DB я бы за каждый процент прибавки к скорости боролся, а для VDI нет.
Не верно выразился. Получается он с raw снимает снапшот в qcow2 формате?
Обещают, но каогда будет хз. А хочется сейчас. На centos вообще можно не дождаться.
Мои вм использую как прокси и для администрирования домена.
Кстате база на Sql крутится под цитрикс, хз в каком там формате, но скорость устраивает.
Не верно выразился. Получается он с raw снимает снапшот в qcow2 формате?
ага, именно так. qcow2 это набор линков на каждый блок в предыдущем по цепочке снепшотов имидже. какая ему разница, держать указатели на блоки другого qcow2 или raw? блок есть блок :)
"XliN" написал:
Обещают, но каогда будет не знаю. А хочется сейчас. На centos вообще можно не дождаться.
фича очень нужна в RHEV, а значит ее пропихнут и стабилизируют в RHEL очень быстро. думаю не долго осталось
"XliN" написал:
Вот еще бы узнать как с citrix 6 мигрировать на kvm, давно убежал бы. Не люблю когда система не прозрачна.
посмотрите на virt-v2v, насколько я знаю xenserver там не поддерживается пока, но через промежуточный вариант должно быть возможно
Вроде как поддерживается на прямую. Правда в rhel 6.2 нет. Есть в бете rhel 6.3 и в fedora 16 может даже и в 15 есть.
погляди http://docs.redhat.com/docs/en-US/Red_H … ation.html
можно ссылку? я там xenserver не нашел, только RHEL5 с Xen
Мда. Все сложно, а так хочется хотябы линуксовые вм перетащить.
вспомнил как я таскал виртуалки до появления virt-v2v, еще на RHEL5.4 - просто грузил их с livecd ISO федоры, и гнал содержимое дисков через сеть простым dd if=/dev/hda | netcat ----- netcat -l | dd of=/dev/hda
