Re: [Qemu-devel] drive-backup locks VM if target has issues?
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?
On Mon, Sep 30, 2013 at 3:41 AM, Paolo Bonzini pbonz...@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
[Qemu-devel] drive-backup locks VM if target has issues?
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
