Re: [Qemu-devel] [Bug 1362635] Re: bdrv_read co-routine re-entered recursively

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

On Mon, Sep 01, 2014 at 07:55:22AM -0000, senya wrote:
> I'm trying to reanimate github.com/jagane/qemu-kvm-livebackup
> there is a separate thread which connects with client through socket and sends disk blocks to it.

Regarding your original question about threads: it is possible to do
block I/O from threads but there are rules about how to do that safely.
The natural way to do things in QEMU is not with threads, this was
always an issue with Jagane's patches (I guess he didn't want to spend
time integrating it into QEMU's main loop when prototyping the code but
it's not a good long-term solution).

More about livebackup:

There has been more recent work by Fam Zheng to achieve the same thing.
The advantage of Fam's approach is that it reuses existing QEMU
primitives instead of adding special case livebackup code.

Fam has moved on to other work but his latest patches are from May so
picking them up again shouldn't be that hard.

It consists of two things: image fleecing and dirty bitmap commands.

Image fleecing gives cheap access to a point-in-time snapshot of the
disk (over NBD).  Internally it uses the run-time NBD server and the
block-backup command to export a point-in-time snapshot.

The dirty bitmap provides what Jagane did but the plan is to also
persist bitmaps across QEMU shutdown.  This will make incremental
backups easy.

Please see Part IV of the "Block layer status report" presentation for
an overview:
http://www.linux-kvm.org/wiki/images/4/41/Kvm-forum-2013-block-layer-status-report.pdf

Here are Fam's patch series:
https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg03880.html
https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg05250.html

The first step is getting the image fleecing code merged.  Then the
in-memory dirty bitmap can be merged.  Finally, persistent dirty bitmap
support can be written.

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]