On Tue, Oct 01, 2019 at 07:48:25PM +0200, Max Reitz wrote:
> Hi,
>
> While working on $IMGOPTS support for Python iotests, I noticed a minor
> bug. Let’s fix it, as you do with bugs.
>
>
> Max Reitz (2):
> block: Skip COR for inactive nodes
> iotests/262: Switch source/dest VM launch order
04.10.2019 11:33, Peter Krempa wrote:
> On Thu, Oct 03, 2019 at 19:34:56 -0400, John Snow wrote:
>> On 10/3/19 6:14 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> 03.10.2019 0:35, John Snow wrote:
On 10/2/19 6:46 AM, Peter Krempa wrote:
>>>
>
> [...]
>
> (I'm sorry if I ignored something
Some scripts check the Python version number and have two code paths to
accomodate both Python 2 and 3. Remove the code specific to Python 2 and
assert the minimum version of 3.6 instead (check skips Python tests in
this case, so the assertion would only ever trigger if a Python script
is executed
Signed-off-by: Kevin Wolf
Reviewed-by: Peter Krempa
Tested-by: Peter Krempa
---
tests/qemu-iotests/267 | 168
tests/qemu-iotests/267.out | 182 +++
tests/qemu-iotests/common.filter | 11 +-
tests/qemu-iotests/group
Running iotests is not required to build QEMU, so we can have stricter
version requirements for Python here and can make use of new features
and drop compatibility code earlier.
This makes qemu-iotests skip all Python tests if a Python version before
3.6 is used for the build.
Suggested-by:
Nodes involved in internal snapshots were those that were returned by
bdrv_next(), inserted and not read-only. bdrv_next() in turn returns all
nodes that are either the root node of a BlockBackend or monitor-owned
nodes.
With the typical -drive use, this worked well enough. However, in the
The following changes since commit 4f59102571fce49af180cfc6d4cdd2b5df7bdb14:
Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-oct-01-2019'
into staging (2019-10-01 16:21:42 +0100)
are available in the Git repository at:
git://repo.or.cz/qemu/kevin.git tags/for-upstream
for
On Thu, Oct 03, 2019 at 19:34:56 -0400, John Snow wrote:
> On 10/3/19 6:14 AM, Vladimir Sementsov-Ogievskiy wrote:
> > 03.10.2019 0:35, John Snow wrote:
> >> On 10/2/19 6:46 AM, Peter Krempa wrote:
> >
[...]
(I'm sorry if I ignored something which might require input in the
trimmed part but
04.10.2019 2:34, John Snow wrote:
>
>
> On 10/3/19 6:14 AM, Vladimir Sementsov-Ogievskiy wrote:
>> 03.10.2019 0:35, John Snow wrote:
>>> On 10/2/19 6:46 AM, Peter Krempa wrote:
>>>
>>> [ * poof * ]
>>>
I'd like to re-iterate that the necessity to keep node names same on
both sides
On 01.10.19 15:14, Vladimir Sementsov-Ogievskiy wrote:
> Drop write notifiers and use filter node instead.
>
> = Changes =
>
> 1. Add filter-node-name argument for backup qmp api. We have to do it
> in this commit, as 257 needs to be fixed.
>
> 2. There are no more write notifiers here, so
On Wed, Aug 07, 2019 at 02:49:51PM +0200, Julia Suvorova via Qemu-devel wrote:
> On Wed, Aug 7, 2019 at 2:06 PM Aarushi Mehta wrote:
> >
> >
> >
> > On Wed, 7 Aug, 2019, 17:15 Julia Suvorova, wrote:
> >>
> >> On Fri, Aug 2, 2019 at 1:41 AM Aarushi Mehta
> >> wrote:
> >> > +int
On 04.10.19 17:04, Vladimir Sementsov-Ogievskiy wrote:
> 04.10.2019 17:48, Max Reitz wrote:
>> On 04.10.19 15:22, Vladimir Sementsov-Ogievskiy wrote:
>>> 04.10.2019 15:59, Max Reitz wrote:
On 03.10.19 11:34, Vladimir Sementsov-Ogievskiy wrote:
> 02.10.2019 18:52, Max Reitz wrote:
>>
Important thing for bitmap migration is to select destination block
node to obtain the migrated bitmap.
Prepatch, on source we use bdrv_get_device_or_node_name() to identify
the node, and on target we do bdrv_lookup_bs.
bdrv_get_device_or_node_name() returns blk name only for direct
children of
From: Max Reitz
The commit and mirror block nodes are filters, so they should be marked
as such.
Signed-off-by: Max Reitz
Signed-off-by: Vladimir Sementsov-Ogievskiy
[squash comment fix from another Max's patch and adjust commit msg]
---
include/block/block_int.h | 8 +---
Hi all!
It's a continuation for
"bitmap migration bug with -drive while block mirror runs"
<315cff78-dcdb-a3ce-2742-da3cc9f0c...@redhat.com>
https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg07241.html
The problem is that bitmaps migrated to node with same node-name or
blk-parent name.
On 01.10.19 15:14, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> These series introduce backup-top driver. It's a filter-node, which
> do copy-before-write operation. Mirror uses filter-node for handling
> guest writes, let's move to filter-node (from write-notifiers) for
> backup too.
>
>
04.10.2019 17:21, Max Reitz wrote:
> On 01.10.19 15:14, Vladimir Sementsov-Ogievskiy wrote:
>> Hi all!
>>
>> These series introduce backup-top driver. It's a filter-node, which
>> do copy-before-write operation. Mirror uses filter-node for handling
>> guest writes, let's move to filter-node (from
04.10.2019 18:27, Max Reitz wrote:
> On 04.10.19 17:04, Vladimir Sementsov-Ogievskiy wrote:
>> 04.10.2019 17:48, Max Reitz wrote:
>>> On 04.10.19 15:22, Vladimir Sementsov-Ogievskiy wrote:
04.10.2019 15:59, Max Reitz wrote:
> On 03.10.19 11:34, Vladimir Sementsov-Ogievskiy wrote:
>>
Split out handling one bs, it is needed for the following commit, which
will handle BlockBackends in separate.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
migration/block-dirty-bitmap.c | 93 +++---
1 file changed, 51 insertions(+), 42 deletions(-)
diff --git
Test that dirty bitmap migration works when we deal with mirror.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
tests/qemu-iotests/194 | 14 ++
tests/qemu-iotests/194.out | 6 ++
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/tests/qemu-iotests/194
On 04.10.19 16:05, Peter Maydell wrote:
> On Fri, 4 Oct 2019 at 14:50, Max Reitz wrote:
>> On 04.10.19 15:16, Peter Maydell wrote:
>>> 'make check' does have the restriction
>>> that we don't want the tests to take too long to run, but in
>>> general the block layer should be running some
On 04.10.19 15:22, Vladimir Sementsov-Ogievskiy wrote:
> 04.10.2019 15:59, Max Reitz wrote:
>> On 03.10.19 11:34, Vladimir Sementsov-Ogievskiy wrote:
>>> 02.10.2019 18:52, Max Reitz wrote:
On 02.10.19 17:06, Vladimir Sementsov-Ogievskiy wrote:
> 02.10.2019 18:03, Vladimir
To be used for bitmap migration in further commit.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/block/dirty-bitmap.h | 1 +
block/dirty-bitmap.c | 13 +
2 files changed, 14 insertions(+)
diff --git a/include/block/dirty-bitmap.h b/include/block/dirty-bitmap.h
04.10.2019 17:48, Max Reitz wrote:
> On 04.10.19 15:22, Vladimir Sementsov-Ogievskiy wrote:
>> 04.10.2019 15:59, Max Reitz wrote:
>>> On 03.10.19 11:34, Vladimir Sementsov-Ogievskiy wrote:
02.10.2019 18:52, Max Reitz wrote:
> On 02.10.19 17:06, Vladimir Sementsov-Ogievskiy wrote:
>>
On 18.09.19 01:45, John Snow wrote:
> This series uses python logging to enable output conditionally on
> iotests.log(). We unify an initialization call (which also enables
> debugging output for those tests with -d) and then make the switch
> inside of iotests.
>
> It will help alleviate the
Am 02.10.2019 um 19:47 hat Max Reitz geschrieben:
> On 02.10.19 18:44, Kevin Wolf wrote:
> > Am 02.10.2019 um 13:57 hat Max Reitz geschrieben:
> >> It usually worked fine for me because it’s rather rare that non-block
> >> patches broke the iotests.
> >
> > I disagree. It happened all the time
On 01.10.19 15:14, Vladimir Sementsov-Ogievskiy wrote:
> Backup-top filter caches write operations and does copy-before-write
> operations.
>
> The driver will be used in backup instead of write-notifiers.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
> block/backup-top.h | 41
On 04.10.19 15:16, Peter Maydell wrote:
> On Fri, 4 Oct 2019 at 13:45, Max Reitz wrote:
>>> In the end, I don't care what code these patches touched. I do an
>>> innocent git pull, and when I finally see that it's master that breaks
>>> iotests and not my patches on top of it, I'm annoyed.
>>
>>
On Fri, 4 Oct 2019 at 14:50, Max Reitz wrote:
> On 04.10.19 15:16, Peter Maydell wrote:
> > 'make check' does have the restriction
> > that we don't want the tests to take too long to run, but in
> > general the block layer should be running some reasonable subset
> > of tests in the project's
On 03.10.19 17:19, Vladimir Sementsov-Ogievskiy wrote:
> 01.10.2019 22:46, Max Reitz wrote:
>> Signed-off-by: Max Reitz
>> ---
>> tests/qemu-iotests/iotests.py | 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/tests/qemu-iotests/iotests.py
On 03.10.19 11:34, Vladimir Sementsov-Ogievskiy wrote:
> 02.10.2019 18:52, Max Reitz wrote:
>> On 02.10.19 17:06, Vladimir Sementsov-Ogievskiy wrote:
>>> 02.10.2019 18:03, Vladimir Sementsov-Ogievskiy wrote:
02.10.2019 17:57, Max Reitz wrote:
> On 12.09.19 17:13, Vladimir
On Fri, 4 Oct 2019 at 13:45, Max Reitz wrote:
> > In the end, I don't care what code these patches touched. I do an
> > innocent git pull, and when I finally see that it's master that breaks
> > iotests and not my patches on top of it, I'm annoyed.
>
> Hm. Part of my point was that this still
On Wed, Oct 02, 2019 at 05:22:43PM +0300, Andrey Shinkevich wrote:
> Added possibility to write compressed data by using the
> blk_write_compressed. This action has the limitations of the format
> driver. For example we can't write compressed data over other.
>
> $ ./qemu-img create -f qcow2 -o
On 04.10.19 12:19, Kevin Wolf wrote:
> Am 02.10.2019 um 19:47 hat Max Reitz geschrieben:
>> On 02.10.19 18:44, Kevin Wolf wrote:
>>> Am 02.10.2019 um 13:57 hat Max Reitz geschrieben:
It usually worked fine for me because it’s rather rare that non-block
patches broke the iotests.
>>>
>>>
On 10/4/19 4:24 AM, Vladimir Sementsov-Ogievskiy wrote:
The way I see it, we know an auto-generated node name will never be
correct, but an explicitly specified one represents an explicit user
configuration.
It's wrong to use generated names for migration details, but it's never
wrong to use
04.10.2019 15:59, Max Reitz wrote:
> On 03.10.19 11:34, Vladimir Sementsov-Ogievskiy wrote:
>> 02.10.2019 18:52, Max Reitz wrote:
>>> On 02.10.19 17:06, Vladimir Sementsov-Ogievskiy wrote:
02.10.2019 18:03, Vladimir Sementsov-Ogievskiy wrote:
> 02.10.2019 17:57, Max Reitz wrote:
>> On
On 13.09.19 00:30, Maxim Levitsky wrote:
> Now you can specify which slot to put the encryption key to
> Plus add 'active' option which will let user erase the key secret
> instead of adding it.
> Check that active=true it when creating.
>
> Signed-off-by: Maxim Levitsky
> ---
> block/crypto.c
On 13.09.19 00:30, Maxim Levitsky wrote:
> Currently only for changing crypto parameters
Yep, that elegantly avoids most of the problems we’d have otherwise. :-)
> Signed-off-by: Maxim Levitsky
> ---
> block/qcow2.c| 71
>
On 12.09.19 17:13, Vladimir Sementsov-Ogievskiy wrote:
> This reverts commit 9adc1cb49af8d4e54f57980b1eed5c0a4b2dafa6.
> "mirror: Only mirror granularity-aligned chunks"
>
> Since previous commit unaligned chunks are supported by
> do_sync_target_write.
>
> Signed-off-by: Vladimir
23 Sep 2019 22:23 Eric Blake wrote:
On 9/17/19 12:13 PM, Vladimir Sementsov-Ogievskiy wrote:
> Implement reconnect. To achieve this:
>
> 1. add new modes:
>connecting-wait: means, that reconnecting is in progress, and there
> were small number of reconnect attempts, so all requests are
On 13.09.19 00:30, Maxim Levitsky wrote:
> This implements the encryption key management
> using the generic code in qcrypto layer
> (currently only for qemu-img amend)
>
> This code adds another 'write_func' because the initialization
> write_func works directly on the underlying file,
> because
On 13.09.19 00:30, Maxim Levitsky wrote:
> Signed-off-by: Maxim Levitsky
> ---
> block/Makefile.objs | 2 +-
> block/amend.c | 116 ++
> include/block/block_int.h | 23 ++--
> qapi/block-core.json | 26 +
> qapi/job.json
On 9/24/19 3:31 AM, Vladimir Sementsov-Ogievskiy wrote:
+def qemu_nbd_popen(*args):
+'''Run qemu-nbd in daemon mode and return the parent's exit code'''
+return subprocess.Popen(qemu_nbd_args + ['--persistent'] + list(args))
+
Should you also use a pid file here, and wait for the
On 12.09.19 17:13, Vladimir Sementsov-Ogievskiy wrote:
> Prior 9adc1cb49af8d do_sync_target_write had a bug: it reset aligned-up
> region in the dirty bitmap, which means that we may not copy some bytes
> and assume them copied, which actually leads to producing corrupted
> target.
>
> So
On 13.09.19 00:30, Maxim Levitsky wrote:
> This patch series is continuation of my work to add encryption
> key managment to luks/qcow2 with luks.
>
> This is second version of this patch set.
> The changes are mostly addressing the review feedback,
> plus I tested (and fixed sadly) the somewhat
On 13.09.19 00:30, Maxim Levitsky wrote:
> Note that currently I add tests 300-302, which are
> placeholders to ease the rebase. In final version
> of these patches I will update these.
>
> Signed-off-by: Maxim Levitsky
> ---
> tests/qemu-iotests/300 | 202 +
>
46 matches
Mail list logo
