On 12/19/19 10:14 AM, Nir Soffer wrote:
1. Using disk name as a bitmap name is a bad behavior, as they are completely
different concepts. Especially keeping in mind that user already knows disk
name anyway
and no reason to write this export name inside metadata context of this export.
The dif
On 12/19/19 9:08 AM, Nir Soffer wrote:
Let's just fix qapi spec now.
But qapi documents a better behavior for users. We should fix the code instead
to mach the docs.
1. Using disk name as a bitmap name is a bad behavior, as they are completely
different concepts. Especially keeping in mind t
On 12/19/19 5:36 AM, Nir Soffer wrote:
When connecting to qemu NBD server during incremental backup, client needs to
register this meta context:
"qemu:dirty-bitmap:backup-sda"
To get dirty bitmap chunks in NBD_CMD_BLOCK_STATUS for export "sda".
This comes from libvirt code creating a back
On 12/18/19 4:48 AM, Max Reitz wrote:
There is no $SOCKDIR, only $SOCK_DIR.
Fixes: f3923a72f199b2c63747a7032db74730546f55c6
Signed-off-by: Max Reitz
---
tests/qemu-iotests/common.rc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Whoops. Thanks for the fix.
Reviewed-by: Eric Blak
On 12/19/19 8:38 AM, Max Reitz wrote:
fuse-export-add allows mounting block graph nodes via FUSE on some
existing regular file. That file should then appears like a raw disk
image, and accesses to it result in accesses to the exported BDS.
Right now, we only set up the mount point and tear all
On 12/20/19 6:50 AM, Kevin Wolf wrote:
Am 20.12.2019 um 11:30 hat Max Reitz geschrieben:
I placed it into block/ because that just seemed like the least bad
place to me (apart from creating a new top-level directory like nbd has)
– and also because we already have quite some few non-driver files
On 12/20/19 7:25 AM, Markus Armbruster wrote:
I suppose moving a field between a union base and all variants does
still result in different introspection even though the accepted inputs
are the same.
Correct. A common member (whether it's local or from the base) is in
SchemaInfoObject.member
Markus Armbruster wrote:
> Python 2 EOL is only a few days away[*]. We made configure bitch about
> it in commit e5abf59eae "Deprecate Python 2 support", 2019-07-01. Any
> objections to retiring it now, i.e. in 5.0?
>
> Cc'ing everyone who appears to be maintaining something that looks like
> a
On Fri, Dec 20, 2019 at 05:29:30PM +0100, Markus Armbruster wrote:
> Python 2 EOL is only a few days away[*]. We made configure bitch about
> it in commit e5abf59eae "Deprecate Python 2 support", 2019-07-01. Any
> objections to retiring it now, i.e. in 5.0?
Thanks for the reminder!
I'll be hone
Python 2 EOL is only a few days away[*]. We made configure bitch about
it in commit e5abf59eae "Deprecate Python 2 support", 2019-07-01. Any
objections to retiring it now, i.e. in 5.0?
Cc'ing everyone who appears to be maintaining something that looks like
a Python script.
[*] https://pythonclo
On 02.12.19 13:15, Andrey Shinkevich wrote:
> The compression filter driver is introduced as suggested by Max.
> A sample usage of the filter can be found in the test #214.
> Now, multiple clusters can be written compressed.
> It is useful for the backup job.
>
> v12:
> 01: Missed to change the
On 20/12/2019 17:52, Max Reitz wrote:
> On 02.12.19 13:15, Andrey Shinkevich wrote:
>> Allow writing all the data compressed through the filter driver.
>> The written data will be aligned by the cluster size.
>> Based on the QEMU current implementation, that data can be written to
>> unallocated
On 02.12.19 13:15, Andrey Shinkevich wrote:
> Allow writing all the data compressed through the filter driver.
> The written data will be aligned by the cluster size.
> Based on the QEMU current implementation, that data can be written to
> unallocated clusters only. May be used for a backup job.
>
On Wed, Dec 18, 2019 at 9:20 PM Philippe Mathieu-Daudé
wrote:
>
> Hi,
>
> After this chat on #qemu IRC:
> 13:20 so what is the difference between a IOReadHandler and
> IOEventHandler?
> 13:25 stsquad: one is in-band and the other out-of-band?
> 13:26 f4bug: ahh yes it seems so - connect/discon
Kevin Wolf writes:
> Am 20.12.2019 um 13:48 hat Markus Armbruster geschrieben:
>> Kevin Wolf writes:
>>
>> > Am 20.12.2019 um 11:48 hat Max Reitz geschrieben:
>> >> So if we kept writable and growable in the common base, then the schema
>> >> would give no information about what exports actuall
Am 20.12.2019 um 13:49 hat Markus Armbruster geschrieben:
> Kevin Wolf writes:
>
> > Am 19.12.2019 um 15:38 hat Max Reitz geschrieben:
> >> fuse-export-add allows mounting block graph nodes via FUSE on some
> >> existing regular file. That file should then appears like a raw disk
> >> image, and
Am 20.12.2019 um 13:48 hat Markus Armbruster geschrieben:
> Kevin Wolf writes:
>
> > Am 20.12.2019 um 11:48 hat Max Reitz geschrieben:
> >> So if we kept writable and growable in the common base, then the schema
> >> would give no information about what exports actually support them.
> >>
> >> O
Am 20.12.2019 um 11:30 hat Max Reitz geschrieben:
> I placed it into block/ because that just seemed like the least bad
> place to me (apart from creating a new top-level directory like nbd has)
> – and also because we already have quite some few non-driver files in
> block/ (io.c, the jobs (where
Kevin Wolf writes:
> Am 19.12.2019 um 15:38 hat Max Reitz geschrieben:
>> fuse-export-add allows mounting block graph nodes via FUSE on some
>> existing regular file. That file should then appears like a raw disk
>> image, and accesses to it result in accesses to the exported BDS.
>>
>> Right n
Kevin Wolf writes:
> Am 20.12.2019 um 11:48 hat Max Reitz geschrieben:
>> On 20.12.19 11:26, Kevin Wolf wrote:
>> > Am 19.12.2019 um 15:38 hat Max Reitz geschrieben:
>> >> fuse-export-add allows mounting block graph nodes via FUSE on some
>> >> existing regular file. That file should then appear
On 20.12.19 12:24, Kevin Wolf wrote:
> Am 20.12.2019 um 11:48 hat Max Reitz geschrieben:
>> On 20.12.19 11:26, Kevin Wolf wrote:
>>> Am 19.12.2019 um 15:38 hat Max Reitz geschrieben:
fuse-export-add allows mounting block graph nodes via FUSE on some
existing regular file. That file shoul
On 20.12.19 12:55, Vladimir Sementsov-Ogievskiy wrote:
> 20.12.2019 14:39, Max Reitz wrote:
>> On 13.12.19 12:18, Vladimir Sementsov-Ogievskiy wrote:
>>> 09.12.2019 17:43, Max Reitz wrote:
On 02.12.19 13:12, Vladimir Sementsov-Ogievskiy wrote:
> 11.11.2019 19:02, Max Reitz wrote:
>> Wh
20.12.2019 14:39, Max Reitz wrote:
> On 13.12.19 12:18, Vladimir Sementsov-Ogievskiy wrote:
>> 09.12.2019 17:43, Max Reitz wrote:
>>> On 02.12.19 13:12, Vladimir Sementsov-Ogievskiy wrote:
11.11.2019 19:02, Max Reitz wrote:
> While bdrv_replace_node() will not follow through with it, a spe
On 13.12.19 12:27, Vladimir Sementsov-Ogievskiy wrote:
> 11.11.2019 19:02, Max Reitz wrote:
>> Signed-off-by: Max Reitz
>> ---
>> tests/qemu-iotests/iotests.py | 59 +++
>> 1 file changed, 59 insertions(+)
>>
>> diff --git a/tests/qemu-iotests/iotests.py b/tests/
On 13.12.19 12:18, Vladimir Sementsov-Ogievskiy wrote:
> 09.12.2019 17:43, Max Reitz wrote:
>> On 02.12.19 13:12, Vladimir Sementsov-Ogievskiy wrote:
>>> 11.11.2019 19:02, Max Reitz wrote:
While bdrv_replace_node() will not follow through with it, a specific
@replaces asks the mirror job
20.12.2019 13:40, Peter Krempa wrote:
> On Fri, Dec 20, 2019 at 10:06:17 +, Vladimir Sementsov-Ogievskiy wrote:
>> 20.12.2019 12:56, Peter Krempa wrote:
>>> On Fri, Dec 20, 2019 at 09:39:17 +, Vladimir Sementsov-Ogievskiy wrote:
19.12.2019 18:55, Nir Soffer wrote:
> On Thu, Dec 19,
Am 20.12.2019 um 11:48 hat Max Reitz geschrieben:
> On 20.12.19 11:26, Kevin Wolf wrote:
> > Am 19.12.2019 um 15:38 hat Max Reitz geschrieben:
> >> fuse-export-add allows mounting block graph nodes via FUSE on some
> >> existing regular file. That file should then appears like a raw disk
> >> imag
On 20.12.19 11:26, Kevin Wolf wrote:
> Am 19.12.2019 um 15:38 hat Max Reitz geschrieben:
>> fuse-export-add allows mounting block graph nodes via FUSE on some
>> existing regular file. That file should then appears like a raw disk
>> image, and accesses to it result in accesses to the exported BDS
On Fri, Dec 20, 2019 at 10:06:17 +, Vladimir Sementsov-Ogievskiy wrote:
> 20.12.2019 12:56, Peter Krempa wrote:
> > On Fri, Dec 20, 2019 at 09:39:17 +, Vladimir Sementsov-Ogievskiy wrote:
> >> 19.12.2019 18:55, Nir Soffer wrote:
> >>> On Thu, Dec 19, 2019 at 5:17 PM Vladimir Sementsov-Ogiev
Sergio Lopez writes:
> Sergio Lopez writes:
>
>> Kevin Wolf writes:
>>
>>> Am 13.12.2019 um 21:59 hat Eric Blake geschrieben:
On 12/9/19 10:06 AM, Kevin Wolf wrote:
> Am 28.11.2019 um 11:41 hat Sergio Lopez geschrieben:
> > bdrv_try_set_aio_context() requires that the old contex
On 20.12.19 11:08, Stefan Hajnoczi wrote:
> On Thu, Dec 19, 2019 at 03:38:00PM +0100, Max Reitz wrote:
>> Preamble: This series is based on a combination of my (current) block
>> branch and “iotests: Minor fixes”. I’ve pushed it here:
>>
>> https://git.xanclic.moe/XanClic/qemu fuse-exports-v1
>>
Am 19.12.2019 um 15:38 hat Max Reitz geschrieben:
> fuse-export-add allows mounting block graph nodes via FUSE on some
> existing regular file. That file should then appears like a raw disk
> image, and accesses to it result in accesses to the exported BDS.
>
> Right now, we only set up the mount
From: Li Hangjing
When the number of a virtio-blk device's virtqueues is larger than
BITS_PER_LONG, the out-of-bounds access to bitmap[ ] will occur.
Fixes: e21737ab15 ("virtio-blk: multiqueue batch notify")
Cc: qemu-sta...@nongnu.org
Cc: Stefan Hajnoczi
Signed-off-by: Li Hangjing
Reviewed-by:
The .rst files outside docs/{devel,interop,specs} aren't built yet and
therefore a few syntax errors have slipped through. Fix them.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Daniel P. Berrangé
Message-Id: <2019094411.427174-1-stefa...@redhat.com>
Signed-off-by: Stefan Hajnoczi
---
docs
The Linux virtio_blk.ko guest driver is removing legacy SCSI passthrough
support. Deprecate this feature in QEMU too.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Paolo Bonzini
Reviewed-by: Christoph Hellwig
Reviewed-by: Thomas Huth
Message-id: 20191213144626.1208237-1-stefa...@redhat.com
Mess
The following changes since commit aceeaa69d28e6f08a24395d0aa6915b687d0a681:
Merge remote-tracking branch
'remotes/huth-gitlab/tags/pull-request-2019-12-17' into staging (2019-12-17
15:55:20 +)
are available in the Git repository at:
https://github.com/stefanha/qemu.git tags/block-pull
On 20.12.19 11:07, Kevin Wolf wrote:
> Am 20.12.2019 um 10:52 hat Max Reitz geschrieben:
>> On 20.12.19 10:32, Kevin Wolf wrote:
>>> Am 19.12.2019 um 19:36 hat Max Reitz geschrieben:
The "migration completed" event may be sent (on the source, to be
specific) before the migration is actual
On Thu, Dec 19, 2019 at 03:38:00PM +0100, Max Reitz wrote:
> Preamble: This series is based on a combination of my (current) block
> branch and “iotests: Minor fixes”. I’ve pushed it here:
>
> https://git.xanclic.moe/XanClic/qemu fuse-exports-v1
>
> (The base is on fuse-exports-v1-base.)
>
>
Am 20.12.2019 um 10:52 hat Max Reitz geschrieben:
> On 20.12.19 10:32, Kevin Wolf wrote:
> > Am 19.12.2019 um 19:36 hat Max Reitz geschrieben:
> >> The "migration completed" event may be sent (on the source, to be
> >> specific) before the migration is actually completed, so the VM runstate
> >> wi
20.12.2019 12:56, Peter Krempa wrote:
> On Fri, Dec 20, 2019 at 09:39:17 +, Vladimir Sementsov-Ogievskiy wrote:
>> 19.12.2019 18:55, Nir Soffer wrote:
>>> On Thu, Dec 19, 2019 at 5:17 PM Vladimir Sementsov-Ogievskiy
>>> wrote:
19.12.2019 17:59, Nir Soffer wrote:
> On Thu, Dec 19,
On Fri, Dec 20, 2019 at 09:39:17 +, Vladimir Sementsov-Ogievskiy wrote:
> 19.12.2019 18:55, Nir Soffer wrote:
> > On Thu, Dec 19, 2019 at 5:17 PM Vladimir Sementsov-Ogievskiy
> > wrote:
> >>
> >> 19.12.2019 17:59, Nir Soffer wrote:
> >>> On Thu, Dec 19, 2019 at 4:04 PM Kevin Wolf wrote:
> >>>
On 20.12.19 10:32, Kevin Wolf wrote:
> Am 19.12.2019 um 19:36 hat Max Reitz geschrieben:
>> The "migration completed" event may be sent (on the source, to be
>> specific) before the migration is actually completed, so the VM runstate
>> will still be "finish-migrate" instead of "postmigrate". So a
19.12.2019 18:55, Nir Soffer wrote:
> On Thu, Dec 19, 2019 at 5:17 PM Vladimir Sementsov-Ogievskiy
> wrote:
>>
>> 19.12.2019 17:59, Nir Soffer wrote:
>>> On Thu, Dec 19, 2019 at 4:04 PM Kevin Wolf wrote:
Am 19.12.2019 um 14:41 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Ahh, I s
Am 19.12.2019 um 19:36 hat Max Reitz geschrieben:
> The "migration completed" event may be sent (on the source, to be
> specific) before the migration is actually completed, so the VM runstate
> will still be "finish-migrate" instead of "postmigrate". So ask the
> users of VM.wait_migration() to s
19.12.2019 19:14, Nir Soffer wrote:
> On Thu, Dec 19, 2019 at 5:25 PM Vladimir Sementsov-Ogievskiy
> wrote:
>>
>> 19.12.2019 18:08, Nir Soffer wrote:
>>> On Thu, Dec 19, 2019 at 5:00 PM Vladimir Sementsov-Ogievskiy
>>> wrote:
19.12.2019 17:42, Nir Soffer wrote:
> On Thu, Dec 19, 201
19.12.2019 21:26, Max Reitz wrote:
> When dropping backup-top, we need to drain the node before freeing the
> BlockCopyState. Otherwise, requests may still be in flight and then the
> assertion in shres_destroy() will fail.
>
> (This becomes visible in intermittent failure of 056.)
>
> Cc: qemu-
46 matches
Mail list logo
