Re: [Qemu-block] [Qemu-devel] [PATCH v9 05/20] dirty-bitmap: Avoid size query failure during truncate

On Tue, 09/19 19:00, John Snow wrote: > > > On 09/19/2017 04:18 PM, Eric Blake wrote: > > We've previously fixed several places where we failed to account > > for possible errors from bdrv_nb_sectors(). Fix another one by > > making bdrv_dirty_bitmap_truncate() take the new size from the > >

Re: [Qemu-block] ping Re: [Qemu-devel] [PATCH v7 03/16] migration: split common postcopy out of ram postcopy

* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote: > ping for 1-3 > Can we merge them? I see all of them have R-b's; so lets try and put them in the next migration merge. Quintela: Sound good? Dave > 22.08.2017 02:34, John Snow wrote: > > > > On 07/11/2017 09:38 AM, Vladimir

Re: [Qemu-block] [PATCH v8 18/20] qcow2: Switch store_bitmap_data() to byte-based iteration

On 09/19/2017 07:44 AM, Kevin Wolf wrote: > Am 18.09.2017 um 20:58 hat Eric Blake geschrieben: >> Now that we have adjusted the majority of the calls this function >> makes to be byte-based, it is easier to read the code if it makes >> passes over the image using bytes rather than sectors. >> >>

[Qemu-block] [PATCH v9 09/20] qcow2: Switch sectors_covered_by_bitmap_cluster() to byte-based

We are gradually converting to byte-based interfaces, as they are easier to reason about than sector-based. Change the qcow2 bitmap helper function sectors_covered_by_bitmap_cluster(), renaming it to bytes_covered_by_bitmap_cluster() in the process. Signed-off-by: Eric Blake

[Qemu-block] [PATCH v9 00/20] make dirty-bitmap byte-based

There are patches floating around to add NBD_CMD_BLOCK_STATUS, but NBD wants to report status on byte granularity (even if the reporting will probably be naturally aligned to sectors or even much higher levels). I've therefore started the task of converting our block status code to report at a

[Qemu-block] [PATCH v9 08/20] dirty-bitmap: Change bdrv_dirty_bitmap_*serialize*() to take bytes

Right now, the dirty-bitmap code exposes the fact that we use a scale of sector granularity in the underlying hbitmap to anything that wants to serialize a dirty bitmap. It's nicer to uniformly expose bytes as our dirty-bitmap interface, matching the previous change to bitmap size. The only

[Qemu-block] [PATCH v9 06/20] dirty-bitmap: Change bdrv_dirty_bitmap_size() to report bytes

We're already reporting bytes for bdrv_dirty_bitmap_granularity(); mixing bytes and sectors in our return values is a recipe for confusion. A later cleanup will convert dirty bitmap internals to be entirely byte-based, but in the meantime, we should report the bitmap size in bytes. The only

[Qemu-block] [PATCH v9 11/20] dirty-bitmap: Change bdrv_dirty_iter_next() to report byte offset

Thanks to recent cleanups, most callers were scaling a return value of sectors into bytes (the exception, in qcow2-bitmap, will be converted to byte-based iteration later). Update the interface to do the scaling internally instead. In qcow2-bitmap, the code was specifically checking for an error

Re: [Qemu-block] [Qemu-devel] [PATCH v9 05/20] dirty-bitmap: Avoid size query failure during truncate

On 09/19/2017 04:18 PM, Eric Blake wrote: > We've previously fixed several places where we failed to account > for possible errors from bdrv_nb_sectors(). Fix another one by > making bdrv_dirty_bitmap_truncate() take the new size from the > caller instead of querying itself; then adjust the

Re: [Qemu-block] [PATCH 18/18] iotests: Add test for active mirroring

On Mon, 09/18 18:53, Max Reitz wrote: > >> + > >> +if sync_source_and_target: > >> +# If source and target should be in sync after the mirror, > >> +# we have to flush before completion > > > > Not sure I understand this requirements, does it apply to libvirt and

Re: [Qemu-block] [PATCH 17/18] qemu-io: Add background write

On Mon, 09/18 19:53, Max Reitz wrote: > On 2017-09-18 08:46, Fam Zheng wrote: > > On Wed, 09/13 20:19, Max Reitz wrote: > >> Add a new parameter -B to qemu-io's write command. When used, qemu-io > >> will not wait for the result of the operation and instead execute it in > >> the background. > >

[Qemu-block] Dead code in cpu-models.h (was: block: Clean up some bad code in the vvfat driver)

On 19.09.2017 10:06, Paolo Bonzini wrote: > On 13/09/2017 21:08, John Snow wrote: [...] >> Farewell, bitrot code. >> >> Reviewed-by: John Snow >> >> Out of curiosity, I wonder ... >> >> jhuston@probe (foobar) ~/s/qemu> git grep '#if 0' | wc -l >> 320 > > $ git grep -c '#if 0' |

Re: [Qemu-block] [PATCH] block: Clean up some bad code in the vvfat driver

On 13/09/2017 21:08, John Snow wrote: > > > On 09/13/2017 06:21 AM, Thomas Huth wrote: >> Remove the unnecessary home-grown redefinition of the assert() macro here, >> and remove the unusable debug code at the end of the checkpoint() function. >> The code there uses assert() with side-effects

Re: [Qemu-block] [PATCH] nbd-client: Use correct macro parenthesization

On Mon, Sep 18, 2017 at 04:46:49PM -0500, Eric Blake wrote: > If 'bs' is a complex expression, we were only casting the front half > rather than the full expression. Luckily, none of the callers were > passing bad arguments, but it's better to be robust up front. > > Signed-off-by: Eric Blake

Re: [Qemu-block] [PATCH v2 3/7] block/nbd-client: refactor reading reply

18.09.2017 18:43, Paolo Bonzini wrote: On 18/09/2017 15:59, Vladimir Sementsov-Ogievskiy wrote: Read the whole reply in one place - in nbd_read_reply_entry. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/nbd-client.h | 1 + block/nbd-client.c | 42

Re: [Qemu-block] [PATCH v8 05/20] dirty-bitmap: Avoid size query failure during truncate

On Mon, 09/18 13:58, Eric Blake wrote: > We've previously fixed several places where we failed to account > for possible errors from bdrv_nb_sectors(). Fix another one by > making bdrv_dirty_bitmap_truncate() take the new size from the > caller instead of querying itself; then adjust the sole

[Qemu-block] [PATCH v9 18/20] qcow2: Switch store_bitmap_data() to byte-based iteration

Now that we have adjusted the majority of the calls this function makes to be byte-based, it is easier to read the code if it makes passes over the image using bytes rather than sectors. iotests 165 was rather weak - on a default 64k-cluster image, where bitmap granularity also defaults to 64k

[Qemu-block] [PATCH v9 17/20] qcow2: Switch load_bitmap_data() to byte-based iteration

Now that we have adjusted the majority of the calls this function makes to be byte-based, it is easier to read the code if it makes passes over the image using bytes rather than sectors. Signed-off-by: Eric Blake Reviewed-by: John Snow Reviewed-by: Vladimir

[Qemu-block] [PATCH v9 02/20] hbitmap: Rename serialization_granularity to serialization_align

The only client of hbitmap_serialization_granularity() is dirty-bitmap's bdrv_dirty_bitmap_serialization_align(). Keeping the two names consistent is worthwhile, and the shorter name is more representative of what the function returns (the required alignment to be used for start/count of other

[Qemu-block] [PATCH v9 04/20] dirty-bitmap: Drop unused functions

We had several functions that no one is currently using, and which use sector-based interfaces. I'm trying to convert towards byte-based interfaces, so it's easier to just drop the unused functions: bdrv_dirty_bitmap_get_meta bdrv_dirty_bitmap_get_meta_locked bdrv_dirty_bitmap_reset_meta

Re: [Qemu-block] [Qemu-devel] Dead code in cpu-models.h

On 19.09.2017 20:54, John Snow wrote: > > > On 09/19/2017 04:14 AM, Thomas Huth wrote: >> On 19.09.2017 10:06, Paolo Bonzini wrote: >>> On 13/09/2017 21:08, John Snow wrote: >> [...] Farewell, bitrot code. Reviewed-by: John Snow Out of curiosity, I

[Qemu-block] [PATCH v9 03/20] qcow2: Ensure bitmap serialization is aligned

When subdividing a bitmap serialization, the code in hbitmap.c enforces that start/count parameters are aligned (except that count can end early at end-of-bitmap). We exposed this required alignment through bdrv_dirty_bitmap_serialization_align(), but forgot to actually check that we comply with

[Qemu-block] [PATCH v9 20/20] dirty-bitmap: Convert internal hbitmap size/granularity

Now that all callers are using byte-based interfaces, there's no reason for our internal hbitmap to remain with sector-based granularity. It also simplifies our internal scaling, since we already know that hbitmap widens requests out to granularity boundaries. Signed-off-by: Eric Blake

[Qemu-block] [PATCH v9 19/20] dirty-bitmap: Switch bdrv_set_dirty() to bytes

Both callers already had bytes available, but were scaling to sectors. Move the scaling to internal code. In the case of bdrv_aligned_pwritev(), we are now passing the exact offset rather than a rounded sector-aligned value, but that's okay as long as dirty bitmap widens start/bytes to

[Qemu-block] [PATCH v9 16/20] qcow2: Switch qcow2_measure() to byte-based iteration

This is new code, but it is easier to read if it makes passes over the image using bytes rather than sectors (and will get easier in the future when bdrv_get_block_status is converted to byte-based). Signed-off-by: Eric Blake Reviewed-by: John Snow

[Qemu-block] [PATCH v9 12/20] dirty-bitmap: Change bdrv_get_dirty_count() to report bytes

Thanks to recent cleanups, all callers were scaling a return value of sectors into bytes; do the scaling internally instead. Signed-off-by: Eric Blake Reviewed-by: John Snow Reviewed-by: Kevin Wolf Reviewed-by: Fam Zheng

Re: [Qemu-block] [Qemu-devel] [PATCH] block: Clean up some bad code in the vvfat driver

On 19.09.2017 21:01, John Snow wrote: > > > On 09/19/2017 04:06 AM, Paolo Bonzini wrote: >> On 13/09/2017 21:08, John Snow wrote: >>> >>> >>> On 09/13/2017 06:21 AM, Thomas Huth wrote: Remove the unnecessary home-grown redefinition of the assert() macro here, and remove the unusable

[Qemu-block] [PATCH v9 05/20] dirty-bitmap: Avoid size query failure during truncate

We've previously fixed several places where we failed to account for possible errors from bdrv_nb_sectors(). Fix another one by making bdrv_dirty_bitmap_truncate() take the new size from the caller instead of querying itself; then adjust the sole caller bdrv_truncate() to pass the size just

[Qemu-block] [PATCH v9 13/20] dirty-bitmap: Change bdrv_get_dirty_locked() to take bytes

Half the callers were already scaling bytes to sectors; the other half can eventually be simplified to use byte iteration. Both callers were already using the result as a bool, so make that explicit. Making the change also makes it easier for a future dirty-bitmap patch to offload scaling over

[Qemu-block] [PATCH v9 14/20] dirty-bitmap: Change bdrv_[re]set_dirty_bitmap() to use bytes

Some of the callers were already scaling bytes to sectors; others can be easily converted to pass byte offsets, all in our shift towards a consistent byte interface everywhere. Making the change will also make it easier to write the hold-out callers to use byte rather than sectors for their

Re: [Qemu-block] [Qemu-devel] [PATCH] block: Clean up some bad code in the vvfat driver

On 09/19/2017 04:06 AM, Paolo Bonzini wrote: > On 13/09/2017 21:08, John Snow wrote: >> >> >> On 09/13/2017 06:21 AM, Thomas Huth wrote: >>> Remove the unnecessary home-grown redefinition of the assert() macro here, >>> and remove the unusable debug code at the end of the checkpoint() function.

[Qemu-block] [PATCH v9 10/20] dirty-bitmap: Set iterator start by offset, not sector

All callers to bdrv_dirty_iter_new() passed 0 for their initial starting point, drop that parameter. Most callers to bdrv_set_dirty_iter() were scaling a byte offset to a sector number; the exception qcow2-bitmap will be converted later to use byte rather than sector iteration. Move the scaling

[Qemu-block] [PATCH v9 07/20] dirty-bitmap: Track bitmap size by bytes

We are still using an internal hbitmap that tracks a size in sectors, with the granularity scaled down accordingly, because it lets us use a shortcut for our iterators which are currently sector-based. But there's no reason we can't track the dirty bitmap size in bytes, since it is (mostly) an

[Qemu-block] [PATCH v9 01/20] block: Make bdrv_img_create() size selection easier to read

All callers of bdrv_img_create() pass in a size, or -1 to read the size from the backing file. We then set that size as the QemuOpt default, which means we will reuse that default rather than the final parameter to qemu_opt_get_size() several lines later. But it is rather confusing to read

[Qemu-block] [PATCH v9 15/20] mirror: Switch mirror_dirty_init() to byte-based iteration

Now that we have adjusted the majority of the calls this function makes to be byte-based, it is easier to read the code if it makes passes over the image using bytes rather than sectors. Signed-off-by: Eric Blake Reviewed-by: John Snow Reviewed-by: Kevin

Re: [Qemu-block] [PATCH v2 6/7] block/nbd-client: early fail nbd_read_reply_entry if s->quit is set

19.09.2017 13:03, Paolo Bonzini wrote: On 19/09/2017 11:43, Vladimir Sementsov-Ogievskiy wrote: I'm trying to look forward to structured reads, where we will have to deal with more than one server message in reply to a single client request. For read, we just piece together portions of the

Re: [Qemu-block] [PATCH v2 3/7] block/nbd-client: refactor reading reply

On 19/09/2017 11:25, Vladimir Sementsov-Ogievskiy wrote: > 18.09.2017 18:43, Paolo Bonzini wrote: >> On 18/09/2017 15:59, Vladimir Sementsov-Ogievskiy wrote: >>> Read the whole reply in one place - in nbd_read_reply_entry. >>> >>> Signed-off-by: Vladimir Sementsov-Ogievskiy

[Qemu-block] [PATCH] nvme: fix cmbuf leak on exit

Cc: Keith Busch Signed-off-by: Stefan Hajnoczi --- hw/block/nvme.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/block/nvme.c b/hw/block/nvme.c index 9aa32692a3..513ec7065d 100644 --- a/hw/block/nvme.c +++ b/hw/block/nvme.c @@ -1057,6 +1057,7

Re: [Qemu-block] [PATCH v2 6/7] block/nbd-client: early fail nbd_read_reply_entry if s->quit is set

On 19/09/2017 11:43, Vladimir Sementsov-Ogievskiy wrote: >> >> I'm trying to look forward to structured reads, where we will have to >> deal with more than one server message in reply to a single client >> request. For read, we just piece together portions of the qiov until >> the server has sent

[Qemu-block] [PATCH v2 0/4] scsi, block: introduce persistent reservation managers

SCSI persistent Reservations allow restricting access to block devices to specific initiators in a shared storage setup. When implementing clustering of virtual machines, it is a common requirement for virtual machines to send persistent reservation SCSI commands. However, the operating system

Re: [Qemu-block] [PATCH v2 3/7] block/nbd-client: refactor reading reply

19.09.2017 13:01, Paolo Bonzini wrote: On 19/09/2017 11:25, Vladimir Sementsov-Ogievskiy wrote: 18.09.2017 18:43, Paolo Bonzini wrote: On 18/09/2017 15:59, Vladimir Sementsov-Ogievskiy wrote: Read the whole reply in one place - in nbd_read_reply_entry. Signed-off-by: Vladimir

[Qemu-block] qemu-img: Check failed: No space left on device

Hello, First post here, so maybe I should introduce myself : - I'm a sysadmin for decades and currently managing 4 oVirt clusters, made out of tens of hypervisors, all are CentOS 7.2+ based. - I'm very happy with this solution we choose especially because it is based on qemu-kvm (open source,

[Qemu-block] [PATCH 1/4] scsi, file-posix: add support for persistent reservation management

It is a common requirement for virtual machine to send persistent reservations, but this currently requires either running QEMU with CAP_SYS_RAWIO, or using out-of-tree patches that let an unprivileged QEMU bypass Linux's filter on SG_IO commands. As an alternative mechanism, the next patches

[Qemu-block] [PATCH 4/4] scsi: add persistent reservation manager using qemu-pr-helper

This adds a concrete subclass of pr-manager that talks to qemu-pr-helper. Signed-off-by: Paolo Bonzini --- v1->v2: fixed string property double-free fixed/cleaned up error handling handle buffer underrun scsi/Makefile.objs | 2 +-

[Qemu-block] [PATCH 3/4] scsi: add multipath support to qemu-pr-helper

Proper support of persistent reservation for multipath devices requires communication with the multipath daemon, so that the reservation is registered and applied when a path comes up. The device mapper utilities provide a library to do so; this patch makes qemu-pr-helper.c detect multipath

Re: [Qemu-block] [Qemu-devel] [PATCH] nvme: fix cmbuf leak on exit

Hi Stefan, On 09/19/2017 06:48 AM, Stefan Hajnoczi wrote: Cc: Keith Busch Signed-off-by: Stefan Hajnoczi --- hw/block/nvme.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/block/nvme.c b/hw/block/nvme.c index 9aa32692a3..513ec7065d 100644

Re: [Qemu-block] [PATCH v2 6/7] block/nbd-client: early fail nbd_read_reply_entry if s->quit is set

19.09.2017 01:27, Eric Blake wrote: On 09/18/2017 08:59 AM, Vladimir Sementsov-Ogievskiy wrote: Do not continue any operation if s->quit is set in parallel. Signed-off-by: Vladimir Sementsov-Ogievskiy --- block/nbd-client.c | 7 +++ 1 file changed, 3

Re: [Qemu-block] [PATCH 15/18] block/mirror: Add active mirroring

On Mon, Sep 18, 2017 at 06:26:51PM +0200, Max Reitz wrote: > On 2017-09-18 12:06, Stefan Hajnoczi wrote: > > On Sat, Sep 16, 2017 at 03:58:01PM +0200, Max Reitz wrote: > >> On 2017-09-14 17:57, Stefan Hajnoczi wrote: > >>> On Wed, Sep 13, 2017 at 08:19:07PM +0200, Max Reitz wrote: > This

Re: [Qemu-block] [Qemu-devel] [PATCH 15/18] block/mirror: Add active mirroring

On Tue, Sep 19, 2017 at 10:44:16AM +0100, Stefan Hajnoczi wrote: > On Mon, Sep 18, 2017 at 06:26:51PM +0200, Max Reitz wrote: > > On 2017-09-18 12:06, Stefan Hajnoczi wrote: > > > On Sat, Sep 16, 2017 at 03:58:01PM +0200, Max Reitz wrote: > > >> On 2017-09-14 17:57, Stefan Hajnoczi wrote: > > >>>

[Qemu-block] [PATCH 2/4] scsi: build qemu-pr-helper

Introduce a privileged helper to run persistent reservation commands. This lets virtual machines send persistent reservations without using CAP_SYS_RAWIO or out-of-tree patches. The helper uses Unix permissions and SCM_RIGHTS to restrict access to processes that can access its socket and prove

Re: [Qemu-block] [Qemu-devel] [PATCH 4/4] scsi: add persistent reservation manager using qemu-pr-helper

On Tue, Sep 19, 2017 at 03:23:09PM +0200, Paolo Bonzini wrote: > On 19/09/2017 15:12, Daniel P. Berrange wrote: > > On Tue, Sep 19, 2017 at 02:57:00PM +0200, Paolo Bonzini wrote: > >> On 19/09/2017 14:53, Daniel P. Berrange wrote: > +/* Try to reconnect while sending the CDB. */ > +

[Qemu-block] Block Migration and CPU throttling

Hi, I just noticed that CPU throttling and Block Migration don't work together very well. During block migration the throttling heuristic detects that we obviously make no progress in ram transfer. But the reason is the running block migration and not a too high dirty pages rate. The result

Re: [Qemu-block] [Qemu-devel] [PATCH 2/4] scsi: build qemu-pr-helper

On Tue, Sep 19, 2017 at 12:24:32PM +0200, Paolo Bonzini wrote: > Introduce a privileged helper to run persistent reservation commands. > This lets virtual machines send persistent reservations without using > CAP_SYS_RAWIO or out-of-tree patches. The helper uses Unix permissions > and SCM_RIGHTS

Re: [Qemu-block] [PATCH v8 18/20] qcow2: Switch store_bitmap_data() to byte-based iteration

Am 18.09.2017 um 20:58 hat Eric Blake geschrieben: > Now that we have adjusted the majority of the calls this function > makes to be byte-based, it is easier to read the code if it makes > passes over the image using bytes rather than sectors. > > Signed-off-by: Eric Blake >

Re: [Qemu-block] [PATCH v8 00/20] make dirty-bitmap byte-based

Am 18.09.2017 um 20:57 hat Eric Blake geschrieben: > There are patches floating around to add NBD_CMD_BLOCK_STATUS, > but NBD wants to report status on byte granularity (even if the > reporting will probably be naturally aligned to sectors or even > much higher levels). I've therefore started the

Re: [Qemu-block] [Qemu-devel] [PATCH 4/4] scsi: add persistent reservation manager using qemu-pr-helper

On Tue, Sep 19, 2017 at 12:24:34PM +0200, Paolo Bonzini wrote: > This adds a concrete subclass of pr-manager that talks to qemu-pr-helper. > > Signed-off-by: Paolo Bonzini > --- > v1->v2: fixed string property double-free > fixed/cleaned up error handling >

Re: [Qemu-block] [PATCH v2 7/7] block/nbd-client: do not yield from nbd_read_reply_entry

On 09/19/2017 05:00 AM, Vladimir Sementsov-Ogievskiy wrote: > 19.09.2017 01:36, Eric Blake wrote: >> On 09/18/2017 08:59 AM, Vladimir Sementsov-Ogievskiy wrote: >>> Refactor nbd client to not yield from nbd_read_reply_entry. It's >>> possible now as all reading is done in nbd_read_reply_entry and

Re: [Qemu-block] [Qemu-devel] [PATCH 4/4] scsi: add persistent reservation manager using qemu-pr-helper

On 19/09/2017 14:53, Daniel P. Berrange wrote: >> +/* Try to reconnect while sending the CDB. */ >> +for (attempts = 0; attempts < PR_MAX_RECONNECT_ATTEMPTS; attempts++) { > > I'm curious why you need to loop here. The helper daemon should be running > already, as you're not spawning it

Re: [Qemu-block] [Qemu-devel] [PATCH 2/4] scsi: build qemu-pr-helper

On 19/09/2017 15:33, Daniel P. Berrange wrote: > On Tue, Sep 19, 2017 at 12:24:32PM +0200, Paolo Bonzini wrote: >> Introduce a privileged helper to run persistent reservation commands. >> This lets virtual machines send persistent reservations without using >> CAP_SYS_RAWIO or out-of-tree patches.

Re: [Qemu-block] [PATCH v2 3/7] block/nbd-client: refactor reading reply

On 19/09/2017 13:03, Vladimir Sementsov-Ogievskiy wrote: >>> >> I disagree that it is easier to extend it in the future. If some >> commands in the future need a different "how do we read it" (e.g. for >> structured reply), nbd_read_reply_entry may not have all the information >> it needs

Re: [Qemu-block] [Qemu-devel] [PATCH 4/4] scsi: add persistent reservation manager using qemu-pr-helper

On Tue, Sep 19, 2017 at 02:57:00PM +0200, Paolo Bonzini wrote: > On 19/09/2017 14:53, Daniel P. Berrange wrote: > >> +/* Try to reconnect while sending the CDB. */ > >> +for (attempts = 0; attempts < PR_MAX_RECONNECT_ATTEMPTS; attempts++) { > > > > I'm curious why you need to loop here.

Re: [Qemu-block] [Qemu-devel] [PATCH 4/4] scsi: add persistent reservation manager using qemu-pr-helper

On 19/09/2017 15:12, Daniel P. Berrange wrote: > On Tue, Sep 19, 2017 at 02:57:00PM +0200, Paolo Bonzini wrote: >> On 19/09/2017 14:53, Daniel P. Berrange wrote: +/* Try to reconnect while sending the CDB. */ +for (attempts = 0; attempts < PR_MAX_RECONNECT_ATTEMPTS; attempts++)

Re: [Qemu-block] [Qemu-devel] [PATCH 4/4] scsi: add persistent reservation manager using qemu-pr-helper

On Tue, Sep 19, 2017 at 12:24:34PM +0200, Paolo Bonzini wrote: > This adds a concrete subclass of pr-manager that talks to qemu-pr-helper. > > Signed-off-by: Paolo Bonzini > --- > v1->v2: fixed string property double-free > fixed/cleaned up error handling >

Re: [Qemu-block] [PATCH] block/throttle-groups.c: allocate RestartData on the heap

Am 18.09.2017 um 22:25 hat Manos Pitsidianakis geschrieben: > RestartData is the opaque data of the throttle_group_restart_queue_entry > coroutine. By being stack allocated, it isn't available anymore if > aio_co_enter schedules the coroutine with a bottom halve and runs after >

Re: [Qemu-block] [Qemu-devel] image locking

On Tue, Sep 19, 2017 at 06:46:19PM +0300, Vladimir Sementsov-Ogievskiy wrote: > Hi Fam! > > I have a question about your image locking series: > > Can you please explain, why OFD locking is enabled by default and posix > locking is not? What is wrong with posix locking, what are the problems?

Re: [Qemu-block] [Qemu-devel] [PATCH] throttle-groups: update tg->any_timer_armed[] on detach

On 09/19/2017 10:50 AM, Stefan Hajnoczi wrote: > Clear tg->any_timer_armed[] when throttling timers are destroy during s/destroy/destroyed/ > AioContext attach/detach. Failure to do so causes throttling to hang > because we believe the timer is already scheduled! > > The following was broken

Re: [Qemu-block] [Qemu-devel] [PATCH 4/4] scsi: add persistent reservation manager using qemu-pr-helper

On 19/09/2017 15:26, Daniel P. Berrange wrote: > On Tue, Sep 19, 2017 at 03:23:09PM +0200, Paolo Bonzini wrote: >> On 19/09/2017 15:12, Daniel P. Berrange wrote: >>> On Tue, Sep 19, 2017 at 02:57:00PM +0200, Paolo Bonzini wrote: On 19/09/2017 14:53, Daniel P. Berrange wrote: >> +/*

Re: [Qemu-block] Block Migration and CPU throttling

* Peter Lieven (p...@kamp.de) wrote: > Hi, > > I just noticed that CPU throttling and Block Migration don't work together > very well. > During block migration the throttling heuristic detects that we obviously > make no progress > in ram transfer. But the reason is the running block migration

Re: [Qemu-block] Block Migration and CPU throttling

* Peter Lieven (p...@kamp.de) wrote: > Am 19.09.2017 um 16:38 schrieb Dr. David Alan Gilbert: > > * Peter Lieven (p...@kamp.de) wrote: > > > Hi, > > > > > > I just noticed that CPU throttling and Block Migration don't work > > > together very well. > > > During block migration the throttling

Re: [Qemu-block] Block Migration and CPU throttling

On 19/09/2017 15:36, Peter Lieven wrote: > Hi, > > I just noticed that CPU throttling and Block Migration don't work > together very well. > During block migration the throttling heuristic detects that we > obviously make no progress > in ram transfer. But the reason is the running block

[Qemu-block] RFC: Reducing the size of entries in the qcow2 L2 cache

Hi everyone, over the past few weeks I have been testing the effects of reducing the size of the entries in the qcow2 L2 cache. This was briefly mentioned by Denis in the same thread where we discussed subcluster allocation back in April, but I'll describe here the problem and the proposal in

[Qemu-block] image locking

Hi Fam! I have a question about your image locking series: Can you please explain, why OFD locking is enabled by default and posix locking is not? What is wrong with posix locking, what are the problems? -- Best regards, Vladimir

Re: [Qemu-block] image locking

On 09/19/2017 10:46 AM, Vladimir Sementsov-Ogievskiy wrote: > Hi Fam! > > I have a question about your image locking series: > > Can you please explain, why OFD locking is enabled by default and posix > locking is not? What is wrong with posix locking, what are the problems? POSIX locking

Re: [Qemu-block] Block Migration and CPU throttling

Am 19.09.2017 um 16:38 schrieb Dr. David Alan Gilbert: * Peter Lieven (p...@kamp.de) wrote: Hi, I just noticed that CPU throttling and Block Migration don't work together very well. During block migration the throttling heuristic detects that we obviously make no progress in ram transfer.

Re: [Qemu-block] [Qemu-devel] [PATCH v8 00/20] make dirty-bitmap byte-based

On Mon, 09/18 13:57, Eric Blake wrote: > There are patches floating around to add NBD_CMD_BLOCK_STATUS, > but NBD wants to report status on byte granularity (even if the > reporting will probably be naturally aligned to sectors or even > much higher levels). I've therefore started the task of >

[Qemu-block] [PATCH] throttle-groups: update tg->any_timer_armed[] on detach

Clear tg->any_timer_armed[] when throttling timers are destroy during AioContext attach/detach. Failure to do so causes throttling to hang because we believe the timer is already scheduled! The following was broken at least since QEMU 2.10.0 with -drive iops=100: $ dd if=/dev/zero of=/dev/vdb

Re: [Qemu-block] RFC: Reducing the size of entries in the qcow2 L2 cache

On 09/19/2017 06:07 PM, Alberto Garcia wrote: > Hi everyone, > > over the past few weeks I have been testing the effects of reducing > the size of the entries in the qcow2 L2 cache. This was briefly > mentioned by Denis in the same thread where we discussed subcluster > allocation back in April,

Re: [Qemu-block] [Qemu-devel] [PATCH] throttle-groups: update tg->any_timer_armed[] on detach

On Tue, Sep 19, 2017 at 11:07:53AM -0500, Eric Blake wrote: > On 09/19/2017 10:50 AM, Stefan Hajnoczi wrote: > > Clear tg->any_timer_armed[] when throttling timers are destroy during > > s/destroy/destroyed/ All your base are belong to us!

[Qemu-block] qemu-img: Check failed: No space left on device

Hello, First post here, so maybe I should introduce myself : - I'm a sysadmin for decades and currently managing 4 oVirt clusters, made out of tens of hypervisors, all are CentOS 7.2+ based. - I'm very happy with this solution we choose especially because it is based on qemu-kvm (open source,

Re: [Qemu-block] [Qemu-devel] Dead code in cpu-models.h

On 09/19/2017 04:14 AM, Thomas Huth wrote: > On 19.09.2017 10:06, Paolo Bonzini wrote: >> On 13/09/2017 21:08, John Snow wrote: > [...] >>> Farewell, bitrot code. >>> >>> Reviewed-by: John Snow >>> >>> Out of curiosity, I wonder ... >>> >>> jhuston@probe (foobar) ~/s/qemu> git