[Qemu-devel] drive-backup locks VM if target has issues?

[Qemu-devel] drive-backup locks VM if target has issues?

[Wolfgang Richter]

I wanted to explore overhead with the new drive-backup command and I
noticed if I set the target to something like '/dev/null' the guest VM
starts having IO errors and loses write access to its root file
system.  Here is the qmp-shell command I'm using:

> drive-backup sync=none device=virtio0 target=/dev/null format=raw mode=existing

I have a guest running with a single virtio root disk (ext4, Ubuntu
guest).  After that command, the guest sees write errors to its root
block device (virtio0).

I didn't trace syscalls or dig deeper yet, but was wondering if you
had an idea on why '/dev/null' as a target in a block job would cause
the origin device to lockup/fail?

My overall goal is to drop the extra write traffic as early as
possible to measure overhead of the drive-backup command in a few
different scenarios, thus I was hoping /dev/null would help here.

-- 
Wolf

Re: [Qemu-devel] drive-backup locks VM if target has issues?

[Paolo Bonzini]

Il 30/09/2013 00:46, Wolfgang Richter ha scritto:
> I wanted to explore overhead with the new drive-backup command and I
> noticed if I set the target to something like '/dev/null' the guest VM
> starts having IO errors and loses write access to its root file
> system.  Here is the qmp-shell command I'm using:
> 
>> drive-backup sync=none device=virtio0 target=/dev/null format=raw mode=existing
> 
> I have a guest running with a single virtio root disk (ext4, Ubuntu
> guest).  After that command, the guest sees write errors to its root
> block device (virtio0).

All writes to the drive-backup source have to first copy the pre-write
data to the target.  Thus, drive-backup usually works best if you are
using werror=stop on the source.  That said, I would have expected the
job to be cancelled instead.  Looks like there are bugs in the handling
of on_target_error.

> I didn't trace syscalls or dig deeper yet, but was wondering if you
> had an idea on why '/dev/null' as a target in a block job would cause
> the origin device to lockup/fail?
> 
> My overall goal is to drop the extra write traffic as early as
> possible to measure overhead of the drive-backup command in a few
> different scenarios, thus I was hoping /dev/null would help here.

I think you need a "null" backend instead that drops writes at the QEMU
level.  Perhaps /dev/zero helps too.

Paolo

Re: [Qemu-devel] drive-backup locks VM if target has issues?

[Wolfgang Richter]

On Mon, Sep 30, 2013 at 3:41 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 30/09/2013 00:46, Wolfgang Richter ha scritto:
> All writes to the drive-backup source have to first copy the pre-write
> data to the target.  Thus, drive-backup usually works best if you are
> using werror=stop on the source.  That said, I would have expected the
> job to be cancelled instead.  Looks like there are bugs in the handling
> of on_target_error.

Yes, that makes sense and was what I thought as well: it should have been
canceled or ended in some bad state.  Instead my VM saw drive write errors
and remounted root read-only.  Not an issue for "real work" for me, just meant
my benchmark couldn't run.

>> My overall goal is to drop the extra write traffic as early as
>> possible to measure overhead of the drive-backup command in a few
>> different scenarios, thus I was hoping /dev/null would help here.
>
> I think you need a "null" backend instead that drops writes at the QEMU
> level.  Perhaps /dev/zero helps too.

Yeah, /dev/zero has the same issue.  I could make a null backend, or just make
my NBD server drop all the writes.  There will be extra overhead from TCP, but
it'll be good enough for me to measure (NBD is what I am using as a target
eventually anyways).

-- 
Wolf