Re: [Qemu-block] [PATCH v3 1/1] migration: disallow migrate_add_blocker during migration

2016-12-09 Thread John Snow
On 12/09/2016 12:39 PM, Dr. David Alan Gilbert wrote: > * John Snow (js...@redhat.com) wrote: >> If a migration is already in progress and somebody attempts >> to add a migration blocker, this should rightly fail. >> >> Add an errp parameter and a retcode return value to migrate_add_blocker. >>

Re: [Qemu-block] [PATCH 15/21] qcow2: add .bdrv_can_store_dirty_bitmap

2016-12-09 Thread Vladimir Sementsov-Ogievskiy
09.12.2016 20:28, Max Reitz wrote: On 22.11.2016 18:26, Vladimir Sementsov-Ogievskiy wrote: Realize .bdrv_can_store_dirty_bitmap interface. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/qcow2-bitmap.c | 40

Re: [Qemu-block] [PATCH 13/21] qcow2: add .bdrv_store_persistent_dirty_bitmaps()

2016-12-09 Thread Vladimir Sementsov-Ogievskiy
09.12.2016 20:05, Max Reitz wrote: On 22.11.2016 18:26, Vladimir Sementsov-Ogievskiy wrote: Realize block bitmap storing interface, to allow qcow2 images store persistent bitmaps. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/qcow2-bitmap.c | 451

Re: [Qemu-block] [PATCH 17/21] qmp: add autoload parameter to block-dirty-bitmap-add

2016-12-09 Thread Max Reitz
On 22.11.2016 18:26, Vladimir Sementsov-Ogievskiy wrote: > Optional. Default is false. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > Signed-off-by: Denis V. Lunev > --- > blockdev.c| 18 -- > docs/qmp-commands.txt | 4

Re: [Qemu-block] [Qemu-devel] [PATCH v3 0/1] migration: disallow migrate_add_blocker during migration

2016-12-09 Thread no-reply
Hi, Your series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] [PATCH v3 0/1] migration: disallow migrate_add_blocker during migration Type: series Message-id: 20161209172547.31550-1-js...@redhat.com === TEST SCRIPT BEGIN === #!/bin/bash

Re: [Qemu-block] [PATCH v3 1/1] migration: disallow migrate_add_blocker during migration

2016-12-09 Thread Dr. David Alan Gilbert
* John Snow (js...@redhat.com) wrote: > If a migration is already in progress and somebody attempts > to add a migration blocker, this should rightly fail. > > Add an errp parameter and a retcode return value to migrate_add_blocker. > > Signed-off-by: John Snow > --- >

Re: [Qemu-block] [PATCH 16/21] qmp: add persistent flag to block-dirty-bitmap-add

2016-12-09 Thread Max Reitz
On 22.11.2016 18:26, Vladimir Sementsov-Ogievskiy wrote: > Add optional 'persistent' flag to qmp command block-dirty-bitmap-add. > Default is false. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > Signed-off-by: Denis V. Lunev > --- > blockdev.c

Re: [Qemu-block] [PATCH 15/21] qcow2: add .bdrv_can_store_dirty_bitmap

2016-12-09 Thread Max Reitz
On 22.11.2016 18:26, Vladimir Sementsov-Ogievskiy wrote: > Realize .bdrv_can_store_dirty_bitmap interface. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > block/qcow2-bitmap.c | 40 > block/qcow2.c| 1 + >

[Qemu-block] [PATCH v3 0/1] migration: disallow migrate_add_blocker during migration

2016-12-09 Thread John Snow
As discussed on-list, this may be a necessary building block for a run-time flag that prevents us from getting into any situations where we configure a non-migratable QEMU. I'd like extra attention to be paid to the virtio-gpu, vhost, and ivshmem changes as I am not perfectly confident in those.

[Qemu-block] [PATCH v3 1/1] migration: disallow migrate_add_blocker during migration

2016-12-09 Thread John Snow
If a migration is already in progress and somebody attempts to add a migration blocker, this should rightly fail. Add an errp parameter and a retcode return value to migrate_add_blocker. Signed-off-by: John Snow --- block/qcow.c | 6 +- block/vdi.c

Re: [Qemu-block] [PATCH 14/21] block: add bdrv_can_store_dirty_bitmap

2016-12-09 Thread Max Reitz
On 22.11.2016 18:26, Vladimir Sementsov-Ogievskiy wrote: > This will be needed to check some restrictions before making bitmap > persistent in qmp-block-dirty-bitmap-add (this functionality will be > added by future patch) > > Signed-off-by: Vladimir Sementsov-Ogievskiy

Re: [Qemu-block] [PATCH 13/21] qcow2: add .bdrv_store_persistent_dirty_bitmaps()

2016-12-09 Thread Max Reitz
On 22.11.2016 18:26, Vladimir Sementsov-Ogievskiy wrote: > Realize block bitmap storing interface, to allow qcow2 images store > persistent bitmaps. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > block/qcow2-bitmap.c | 451 >

Re: [Qemu-block] [PATCH RFC 0/1] Allow storing the qcow2 L2 cache in disk

2016-12-09 Thread Alberto Garcia
On Fri 09 Dec 2016 03:18:23 PM CET, Kevin Wolf wrote: >> I have been making some tests with exactly that scenario and the >> results look good: storing the cache in disk gives roughly the same >> performance as storing it in memory. >> >>

Re: [Qemu-block] [PATCH RFC 0/1] Allow storing the qcow2 L2 cache in disk

2016-12-09 Thread Kevin Wolf
Am 09.12.2016 um 14:47 hat Alberto Garcia geschrieben: > Hi all, > > as we all know, one of the main things that can make the qcow2 format > slow is the need to load entries from the L2 table in order to map a > guest offset (on the virtual disk) to a host offset (on the qcow2 > image). > > We

Re: [Qemu-block] [PATCH 02/36] qdict: Add convenience helpers for wrapped puts

2016-12-09 Thread Alberto Garcia
On Wed 30 Nov 2016 08:44:20 PM CET, Eric Blake wrote: > Quite a few users of qdict_put() were manually wrapping a > non-QObject. We can make such call-sites shorter, by providing > common macros to do the tedious work. Also shorten nearby > qdict_put_obj(,,QOBJECT()) sequences. > > Signed-off-by:

[Qemu-block] [PATCH RFC 1/1] qcow2: Allow storing the qcow2 L2 cache in disk

2016-12-09 Thread Alberto Garcia
In scenarios where we have a large qcow2 file stored in a slow storage backend, we can save memory by storing its L2 cache in a faster drive rather than keeping it in RAM. Signed-off-by: Alberto Garcia --- block/qcow2-cache.c | 56

[Qemu-block] [PATCH RFC 0/1] Allow storing the qcow2 L2 cache in disk

2016-12-09 Thread Alberto Garcia
Hi all, as we all know, one of the main things that can make the qcow2 format slow is the need to load entries from the L2 table in order to map a guest offset (on the virtual disk) to a host offset (on the qcow2 image). We have an L2 cache to deal with this, and as long as the cache is big