Hi, As far as I understand, currently there is no way to live migrate qemu VMs that have internal snapshots, because live migration works via qemu drive mirroring, which in turns mirrors only shallow block layer, effectively losing existing embedded snapshots. The problem could be fixed if we created an external delta for all disks with internal snapshots, live migrate such VMs and then auto merge them back into original images. That said, I would like to know very much your opinion on the matter and would also like to know if this approach is affordable. If so, I or one of my colleagues will send a pathset to fix this, otherwise what solution for this problem you will recommend?

Hi, As far as I understand, currently there is no way to live migrate qemu VMs that have internal snapshots, because live migration works via qemu drive mirroring, which in turns mirrors only shallow block layer, effectively losing existing embedded snapshots. The problem could be fixed if we created an external delta for all disks with internal snapshots, live migrate such VMs and then auto merge them back into original images. That said, I would like to know very much your opinion on the matter and would also like to know if this approach is affordable. If so, I or one of my colleagues will send a pathset to fix this, otherwise what solution for this problem you will recommend?

26.04.2016 13:00, Kashyap Chamarthy пишет: > On Tue, Apr 26, 2016 at 06:26:59AM +0300, Maxim Nestratov wrote: >> Hi, >> >> As far as I understand, currently there is no way to live migrate qemu >> VMs that have internal snapshots, because live migration works via >> qemu drive mirroring, which in turns mirrors only shallow block layer, >> effectively losing existing embedded snapshots. The problem could be >> fixed if we created an external delta for all disks with internal >> snapshots, live migrate such VMs and then auto merge them back into >> original images. That said, I would like to know very much your >> opinion on the matter and would also like to know if this approach is >> affordable. If so, I or one of my colleagues will send a pathset to >> fix this, otherwise what solution for this problem you will recommend? > There seems to be an old discussion here[1] on this topic: > > "You are not the first to request this - libvirt would > also like the ability to have read-only access into the contents of an > internal snapshot while the rest of qemu continues to write into the > image." (Eric Blake) > > When I asked if this was possible with today's QEMU, Kevin Wolf (QEMU > block layer maintainer) on #qemu IRC said: > > "No, this requires some non-trivial code design changes and was > never considered important enough. This would also require writes > to those snapshots on the destination, by the way (which wouldn't >be > impossible if the infrastructure for having multiple active > snapshots at the same time were there)" > > > [1] > http://lists.nongnu.org/archive/html/qemu-devel/2012-11/msg00402.html -- > live migration which includes previos snapshot > Hmm. Interesting. But what I'm talking about doesn't involve qemu much. We create an external temporarily delta for images with internal snapshots on libvirt side, then merge it on libvirt side thus, qemu shouldn't be affected at all as far as I understand.

Copying my colleagues to the thread.

On 04/26/2016 07:54 AM, Dmitry Mishin wrote: >> Hmm. Interesting. But what I'm talking about doesn't involve qemu much. >> We create >> an external temporarily delta for images with internal snapshots on >> libvirt side, >> then merge it on libvirt side thus, qemu shouldn't be affected at all as >> far as I >> understand. > Right now, we are trying the following workaround of this issue: > 1) create external snapshot (without metadata) > 2) undefine internal snapshots' metadata (because libvirt prohibits > migration if detects snapshots) > 3) copy metadata & backing file (primary data qcow2 file with internal > snapshots) to the destination > 4) migrate VM using libvirt > 5) define metadata back > 6) block-commit - to merge delta to original qcow2 image. Yes, that looks like a reasonable workaround. > Things would be much simpler, if they were in libvirt rather than in > management app on top of it. It would indeed be easier - but someone has to contribute the patches for it.