virsh blockcommit VM, как сделать слияние snapshot с бэкапом виртуалки?

@disx · Регистрация: 26.02.2014

Студворк — интернет-сервис помощи студентам

Здравствуйте уважаемые!

пытаюсь научиться выполнять бэкап виртуальной машины без остановки в гипервизоре KVM, делаю все по примеру отсюда,

все вроде понятно но не понимаю отдного момента, после того как я сделал dumpxml и snapshot а так же скопировал виртуальную машину(работающую) в папку для бэкапа, как объединить snapshot с этой(скопированной) виртуалкой,

делается это командой:

PowerShell
1
virsh blockcommit VM vda --active --verbose --pivot

,

но что есть VM!?

vda - это диск на котором находится работающая виртуалка(файл),

а что есть VM это должен быть файл моего бэкапа или? немгу понять, помогите пожалуйста разобраться в этом нюансе кто делал такое?

Спасибо за помощь!

@_sg2 · 09.11.2022, 16:31

VM - это виртуальная машина.
вообще, пользуйтесь справкой, удобная вещь!

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
virsh # help blockcommit 
  NAME
    blockcommit - Start a block commit operation.
 
  SYNOPSIS
    blockcommit <domain> <path> [--bandwidth <number>] [--base <string>] [--shallow] [--top <string>] [--active] [--delete] [--wait] [--verbose] [--timeout <number>] [--pivot] [--keep-overlay] [--async] [--keep-relative] [--bytes]
 
  DESCRIPTION
    Commit changes from a snapshot down to its backing image.
 
  OPTIONS
    [--domain] <string>  domain name, id or uuid
    [--path] <string>  fully-qualified path of disk
    --bandwidth <number>  bandwidth limit in MiB/s
    --base <string>  path of base file to commit into (default bottom of chain)
    --shallow        use backing file of top as base
    --top <string>   path of top file to commit from (default top of chain)
    --active         trigger two-stage active commit of top file
    --delete         delete files that were successfully committed
    --wait           wait for job to complete (with --active, wait for job to sync)
    --verbose        with --wait, display the progress
    --timeout <number>  implies --wait, abort if copy exceeds timeout (in seconds)
    --pivot          implies --active --wait, pivot when commit is synced
    --keep-overlay   implies --active --wait, quit when commit is synced
    --async          with --wait, don't wait for cancel to finish
    --keep-relative  keep the backing chain relatively referenced
    --bytes          the bandwidth limit is in bytes/s rather than MiB/s
 
virsh #

Ну и документацию никто тоже не отменял

о! Полез и действительно, именно Ваш случай:
https://libvirt.org/kbase/live... ackup.html

Кхм. Извините, в Вашей статье тоже:

Конфигурационный файл виртуальной машины, можно скопировать следующей командой:
# virsh dumpxml VM > /backup/VM.xml
Где VM – это имя вашей виртуальной машины.
...
Для создания снапшота ВМ используется следующая команда:
# virsh snapshot-create-as --domain VM snapshot --disk-only --atomic --quiesce –no-metadata
Где VM — это имя виртуальной машины. Далее нужно создать бэкап файла диска:

@disx · 10.11.2022, 17:02 **[ТС]**

Сообщение от _sg2

Кхм. Извините, в Вашей статье тоже:

да-да, сам удивляюсь),

что не делаю(ну напр):

PowerShell
1
virsh blockcommit /home/user/vm1_backup/dock_ubuntu vda --verbose --pivot --active

один ответ:

PowerShell
1
error: failed to get domain '/home/user/vm1_backup/dock_ubuntu'

@_sg2 · 10.11.2022, 19:01

эээ....
а чего такое странное имя виртуальной машины-то?

поймите, надо указать ИМЯ. Не путь, а ИМЯ.
[--domain] <string> domain name, id or uuid

Если уж не помните, то
virsh list --all
Там будет имя ВМ. Его и надо передать.

Code
1
2
3
4
5
6
7
8
9
10
11
12
[sg@fedora ~]$ sudo virsh list --all
[sudo] password for sg: 
 Id   Name         State
-----------------------------
 1    gitlab       running
 -    almalinux8   shut off
 -    centos7.0    shut off
 -    rocky9       shut off
 -    srv1-rh      shut off
 -    srv2-rh      shut off
 -    srv3-rh      shut off
 -    srv4-deb     shut off

Вот второй столбец - это и есть имя ВМ (или домена, в термИнах libvrt'а ).

Вообще мне кажется проще начать с virt-manager, а потом уже под капот лезть, так сказать.

@disx · 14.11.2022, 16:15 **[ТС]**

_sg2, спасибо огромное за развернутые ответы,

Сообщение от _sg2

Вообще мне кажется проще начать с virt-manager, а потом уже под капот лезть, так сказать.

мы ж легких путей не ищем

но я правильно понимаю что если я указываю имя(а не путь как вы правильно заметили) для слияния со снапшотом, то как virsh поймет что эта виртуалка из бэкапа(из папки в которой лежит бэкап), а не работающая на этом же хосте виртуалка(оригинал) у которой идентичное имя,

т.е. в момент попытки слияния работающая называется dock_ubuntu и остановленная бэкап копия(в папке для бэкапов) имеет точно такое же имя

и слить со снапшотом нужно именно бэкапную версию а не работающую сейчас?

это не могу понять...

@_sg2 · 14.11.2022, 20:06

Извините, попробую завтра внимательно посмотреть статью, т.к. я попал в классическую ошибку - я знаю, значит все знают

При Вашем методе бэкапа, после xmldump должно вноситься изменение - меняться имя ВМ, после чего на основе изменённого xml следует определить новую ВМ: virsh --define. Ну или перед восстановлением надо это делать, при этом ещё и меняя в xml место хранения образов диска.

virsh edit almalinux8
...
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2'/>
<source file='/srv/kvm/cirros-0.3.5-i386-disk.img'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</disk>
...
Можно делать и без virsh, но тогда xml нужно будет класть в правильные места и делать перезапуск libvirtd.

Ну это в чистом виде "умничание", но чего-то вечером силов нет. Если не поможет, пишите, будем побеждать дальше

@disx · 15.11.2022, 14:49 **[ТС]**

_sg2, ООооо...

, закинули новую абстракцию в мою головушку теперь действительно что-то стало понятно...),
дай бог здоровья теперь это все автоматизировать...

т.е. получается что то, что написано в статье, подходит в случае если делать бэкап виртуалки автоматически(скриптом), то сливать со снапшотом нужно бэкапную версию только тогда, когда оригинал VM погиб или повредился,

а именно:

1. скопировать бэкап в папку где крутился оригинал
2. применить xml конфиг
3. virsh start VM + blockcommit бла-бла...

моя изначальная логика работала так:

делаем бэкап конфига и VM,
делаем слияние VM со снапшотом
и спокойно спим пока работает оригинал зная что готовый бэкап виртуалки которую можно потом просто скопировать запустить (с конфигом и состоянием на определенную дату) лежит себе в папочке на другом диске(или хосте).

лана, будем теперь что-то с этим всем теперь делать

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

@_sg2 1141 / 395 / 88 Регистрация: 30.08.2017 Сообщений: 2,440
	14.11.2022, 20:06
	Извините, попробую завтра внимательно посмотреть статью, т.к. я попал в классическую ошибку - я знаю, значит все знают При Вашем методе бэкапа, после xmldump должно вноситься изменение - меняться имя ВМ, после чего на основе изменённого xml следует определить новую ВМ: virsh --define. Ну или перед восстановлением надо это делать, при этом ещё и меняя в xml место хранения образов диска. virsh edit almalinux8 ... <devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/srv/kvm/cirros-0.3.5-i386-disk.img'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </disk> ... Можно делать и без virsh, но тогда xml нужно будет класть в правильные места и делать перезапуск libvirtd. Ну это в чистом виде "умничание", но чего-то вечером силов нет. Если не поможет, пишите, будем побеждать дальше 1

@disx 23 / 23 / 0 Регистрация: 26.02.2014 Сообщений: 684
	15.11.2022, 14:49 [ТС]
	_sg2, ООооо..., закинули новую абстракцию в мою головушку теперь действительно что-то стало понятно...), дай бог здоровья теперь это все автоматизировать... т.е. получается что то, что написано в статье, подходит в случае если делать бэкап виртуалки автоматически(скриптом), то сливать со снапшотом нужно бэкапную версию только тогда, когда оригинал VM погиб или повредился, а именно: 1. скопировать бэкап в папку где крутился оригинал 2. применить xml конфиг 3. virsh start VM + blockcommit бла-бла... моя изначальная логика работала так: делаем бэкап конфига и VM, делаем слияние VM со снапшотом и спокойно спим пока работает оригинал зная что готовый бэкап виртуалки которую можно потом просто скопировать запустить (с конфигом и состоянием на определенную дату) лежит себе в папочке на другом диске(или хосте). лана, будем теперь что-то с этим всем теперь делать 0

Опции темы