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.
>>
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
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
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
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
* 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
> ---
>
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
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 +
>
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.
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
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
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
>
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.
>>
>>
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
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:
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
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
17 matches
Mail list logo