Видаліть знімок "сирота"


11

Я намагаюся зробити знімок у прямому ефірі за допомогою KVM відповідно до цієї процедури .

Я, мабуть, заплутався в якийсь момент, тому що я перебуваю в стані, якого я не розумію.

Моя ВМ називається prod. Він створений у файлі /srv/vm/prod.qcow2.

Мабуть, немає запущеного знімка: я працюю над базовим файлом. Я можу здогадатися, оскільки дата /srv/vm/prod.qcow2зміни файлу змінюється щохвилини або близько того. Крім того, ця команда підтверджує це:

# virsh domblklist prod
Target     Source
------------------------------------------------
vda        /srv/vm/prod.qcow2

І нічого не можна блокувати:

# virsh blockcommit prod vda --active --pivot
error: invalid argument: top '/srv/vm/prod.qcow2' in chain for 'vda' has no backing file

Однак libvirt відслідковує старий знімок:

# virsh snapshot-list prod
 Name                 Creation Time             State
------------------------------------------------------------
 snap                 2015-06-09 12:11:33 +0200 disk-snapshot

Файл дескриптора /var/lib/libvirt/qemu/snapshot/prod/snap.xml:

<domainsnapshot>
  <name>snap</name>
  <state>disk-snapshot</state>
  <creationTime>1433844693</creationTime>
  <memory snapshot='no'/>
  <disks>
    <disk name='vda' snapshot='external' type='file'>
      <driver type='qcow2'/>
      <source file='/srv/vm/snap.qcow2'/>
    </disk>
  </disks>
[...]

Вихідний файл /srv/vm/snap.qcow2видалено.

З огляду на метод, який я намагаюся реалізувати, цілком ймовірно, що цей знімок був створений за допомогою наступної команди:

virsh snapshot-create-as --domain prod snap --diskspec vda,file=/srv/vm/snap.qcow2 --disk-only --atomic

Я не можу його видалити:

# virsh snapshot-delete prod snap
error: Failed to delete snapshot snap
error: unsupported configuration: deletion of 1 external disk snapshots not supported yet

Тож я перебуваю в стані, коли створений знімок, мабуть, більше не використовується і його неможливо видалити.

Чи я можу щось з цим зробити?

Чи мені все одно, чи я можу просто проігнорувати це?

Редагувати

Я щойно видалив дескриптор файлу знімка.

# systemctl stop libvirt
# mv /var/lib/libvirt/qemu/snapshot/prod/snap.xml /home/jerome
# systemctl start libvirt

Мій VM знову працює, і я більше не бачу посилання на знімок.

# virsh snapshot-list prod
 Name                 Creation Time             State
------------------------------------------------------------

Нічого також у virt-менеджера.

Я добре, чи є ще якесь господарство?

Редагувати 2

Мабуть, перехід -–no-metadataдо virsh snapshot-create-asцього пункту дозволить уникнути цієї проблеми, не створюючи .xml-файл, таким чином, не залишаючи слідів знімка.


1
Після того як ви видалите дескриптор файлу знімка, у самому зображенні VM залишиться деякий доказ існуючого знімка, який можна перевірити qemu-img info /srv/vm/prod.qcow2. Але я не впевнений, як самому видалити цей слід ...
sdittmar

@sdittmar Ви можете звернутися до списку розсилки користувачів libvirt (див. мою відповідь), щоб отримати точну відповідь на це.
Jérôme

Відповіді:


16

Правильний метод був

virsh snapshot-delete prod --metadata snap

(Цю команду можна знайти на wiki . Я спробував її, перш ніж запитати тут, але вона не вдалася через помилку, яку виправили.)

Я не знаю, що це робиться, що не охоплюється видаленням .xml-файлу, поки libvirtd не працює. Можливо, єдина відмінність полягає в тому, що зупиняти лібвіртд не потрібно. Навіть так, можливо, це може розвинутися в майбутньому. У будь-якому випадку рекомендується використовувати API libvirt, а не грати з файлами безпосередньо.

Цей дзвінок справді не потрібен, якщо знімок був створений з --no-metadataаргументом.

Я отримав це роз'яснення у цій темі на Libvirt-користувачів в список розсилки .

Кожен, хто бажає робити резервні копії за допомогою знімків у прямому ефірі, повинен прочитати вищезгадану сторінку вікі та може зацікавити тему форуму, яка відповідає на мої запитання щодо нобу, та вказує на слайди Еріка Блейка , а також цю публікацію в блозі та наступні коментарі.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.