++
tests/qemu-iotests/051 | 13 ++
tests/qemu-iotests/051.out | 13 ++
util/hbitmap.c | 19 ++
15 files changed, 1230 insertions(+), 27 deletions(-)
create mode 100644 docs/block-replication.txt
--
2.1.0
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
that covers at least
static filters?
Paolo
.
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Paolo Bonzini (pbonz...@redhat.com) wrote:
On 23/04/2015 14:05, Dr. David Alan Gilbert wrote:
As presented at the moment, I don't see there's any dynamic reconfiguration
on the primary side at the moment
So that means the bdrv_start_replication and bdrv_stop_replication
callbacks
to bring up a new secondary
and get that new secondary an image of the primaries current disk.
Dave
Paolo
Anyway, even if we move it to a second step, it looks like we need to
design something rather soon now.
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
/fast enough to set up a new Secondary.
I'd assumed that a higher level management layer would do the allocation
of a new secondary after the first failover, so no human need be involved.
Dave
Stefan
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
On Tue, May 05, 2015 at 04:23:56PM +0100, Dr. David Alan Gilbert wrote:
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
On Fri, Apr 24, 2015 at 11:36:35AM +0200, Paolo Bonzini wrote:
On 24/04/2015 11:38, Wen Congyang wrote
* Peter Lieven (p...@kamp.de) wrote:
Hi David,
Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert:
Any particular workload or reproducer?
Workload is almost zero. I try to figure out if there is a way to trigger
it.
Maybe playing a role: Machine type is -M pc1.2 and we set
* Peter Lieven (p...@kamp.de) wrote:
Am 07.04.2015 um 17:29 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
Hi David,
Am 07.04.2015 um 10:43 schrieb Dr. David Alan Gilbert:
Any particular workload or reproducer?
Workload is almost zero. I try to figure out
bdrv_connect.
I can see that you want to do a disconnect at failover, however you need
to take care because if the network is broken at the point of failover
you need to make sure nothing blocks.
Dave
Thanks
Wen Congyang
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
-see.
--js
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Markus Armbruster (arm...@redhat.com) wrote:
Dr. David Alan Gilbert dgilb...@redhat.com writes:
* John Snow (js...@redhat.com) wrote:
On 05/21/2015 09:19 AM, Kevin Wolf wrote:
The floppy controller spec describes three different controller phases,
which are currently
* Kevin Wolf (kw...@redhat.com) wrote:
Am 29.05.2015 um 10:33 hat Dr. David Alan Gilbert geschrieben:
* Markus Armbruster (arm...@redhat.com) wrote:
Dr. David Alan Gilbert dgilb...@redhat.com writes:
* John Snow (js...@redhat.com) wrote:
On 05/21/2015 09:19 AM, Kevin
* Peter Maydell (peter.mayd...@linaro.org) wrote:
On 29 May 2015 at 11:34, Dr. David Alan Gilbert dgilb...@redhat.com wrote:
It's the destination I'm worried about here, not the source; lets say
you have two devices, a b. 'a' gets serialised, but then 'b' finds
it has to wait, so we
* Kevin Wolf (kw...@redhat.com) wrote:
Am 29.05.2015 um 11:38 hat Dr. David Alan Gilbert geschrieben:
* Kevin Wolf (kw...@redhat.com) wrote:
Am 29.05.2015 um 10:33 hat Dr. David Alan Gilbert geschrieben:
* Markus Armbruster (arm...@redhat.com) wrote:
Dr. David Alan Gilbert dgilb
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 07/01/2015 04:11 PM, Dr. David Alan Gilbert wrote:
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 07/01/2015 03:01 AM, Dr. David Alan Gilbert wrote:
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 06/27/2015 03:03 AM, Dr. David Alan Gilbert
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 07/01/2015 03:01 AM, Dr. David Alan Gilbert wrote:
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 06/27/2015 03:03 AM, Dr. David Alan Gilbert wrote:
snip
Ah, I hadn't realised you could do that; so do you just do
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 07/02/2015 02:42 AM, Dr. David Alan Gilbert wrote:
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 07/01/2015 04:11 PM, Dr. David Alan Gilbert wrote:
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 07/01/2015 03:01 AM, Dr. David Alan Gilbert
. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Wen Congyang (ghost...@gmail.com) wrote:
At 2015/7/3 23:30, Dr. David Alan Gilbert Wrote:
* Wen Congyang (we...@cn.fujitsu.com) wrote:
Block replication is a very important feature which is used for
continuous checkpoints(for example: COLO).
Usage:
Please refer to docs/block
prefer if it wasn't
broken upstream except where really hard.
Dave
-- PMM
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Max Reitz (mre...@redhat.com) wrote:
> On 09.10.2015 18:42, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 08.10.2015 08:15, Markus Armbruster wrote:
> >>> Max Reitz <mre...@redhat.com> writes:
> >>>
t a/include/block/block_int.h b/include/block/block_int.h
> index 2f2c47b..64cbc55 100644
> --- a/include/block/block_int.h
> +++ b/include/block/block_int.h
> @@ -288,6 +288,11 @@ struct BlockDriver {
> */
> int (*bdrv_probe_geometry)(BlockDriverState *bs, HDGeometry *geo);
>
> +void (*bdrv_add_child)(BlockDriverState *parent, BlockDriverState *child,
> + Error **errp);
> +void (*bdrv_del_child)(BlockDriverState *parent, BlockDriverState *child,
> + Error **errp);
> +
> QLIST_ENTRY(BlockDriver) list;
> };
>
> --
> 2.4.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
, and that are
> easy to implement with the interface that we want. It's what I call a
> “macro function”.
>
> > A secondary question is whether the incompleteness of the implementation
> > demands an x- to warn users.
>
> We don't want to shoehorn generality into these two functions, but add a
> new one anyway. We might want to add optional parameters later on (e.g.
> changing the threshold), but that would be a compatible change.
>
> >> (My point is that with such an experimental interface, management tools
> >> cannot use it, even though it'd be a very nice functionality to have)
> >
> > How much work is it to finish the job? Unless it's a substantial chunk,
> > debating x- is much ado about nothing: just finish the job already :)
>
> We have proven in the past to need a significant amount of time for even
> for non-substantial chunks. Often, non-substantial chunks turn out to be
> substantial when actually tackling them.
>
> It basically comes down to whether the COLO authors are willing to wait
> for us to do the job. And frankly, if I were them, I wouldn't be.
>
> Max
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 10/08/2015 03:00 AM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >> In some cases, we want to take a quorum child offline, and take
> >> another child online.
> >
> >
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 07/09/2015 05:16 PM, Dr. David Alan Gilbert wrote:
* Wen Congyang (we...@cn.fujitsu.com) wrote:
I have sent the v8. But the usage is not changed. You can setup the
environment according to the wiki.
When we open nbd client, we need
.
+ *
+ * Do block checkpoint on the specified job.
+ */
+void block_job_do_checkpoint(BlockJob *job, Error **errp);
+
#endif
--
2.4.3
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 07/08/2015 11:49 PM, Michael R. Hines wrote:
On 07/07/2015 08:38 PM, Wen Congyang wrote:
On 07/08/2015 12:56 AM, Michael R. Hines wrote:
On 07/07/2015 04:23 AM, Paolo Bonzini wrote:
On 07/07/2015 11:13, Dr. David Alan Gilbert wrote
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 07/09/2015 06:37 PM, Dr. David Alan Gilbert wrote:
* Wen Congyang (we...@cn.fujitsu.com) wrote:
On 07/09/2015 05:16 PM, Dr. David Alan Gilbert wrote:
* Wen Congyang (we...@cn.fujitsu.com) wrote:
I have sent the v8. But the usage
qmp-commands.hx | 61 +++++++
> 10 files changed, 329 insertions(+), 5 deletions(-)
>
> --
> 2.4.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Eric Blake (ebl...@redhat.com) wrote:
> On 12/17/2015 03:47 AM, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
> >
> > x-blockdev-change has no HMP equivalent, so add x_block_change.
> >
> >
econds?) to
sync Host 3 back in when you add it after a failover and the aim would
be not to have distrubed the application for that long, so it should
already be running on Host 2 during that resync.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
ication_remove(BlockReplicationState *brs);
> >
> > The replication block driver would add/remove itself. The quorum block
> > driver probably doesn't need to be modified (I think in your current
> > patches you modify it just to forward the start/stop/checkpoint calls to
> > a particular quorum child).
>
> Yes, it is the major purpose. We also do some check in the quorum driver:
> we don't allow more than one child support block replication.
>
> Thanks
> Wen Congyang
>
> >
> > Stefan
> >
>
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
+++
> blockjob.c | 11 +
> docs/block-replication.txt | 227 +++
> include/block/block.h | 9 +
> include/block/block_int.h | 15 ++
> include/block/blockjob.h | 12 +
> qapi/block-core.json | 34 ++-
> 11 files changed, 1093 insertions(+), 4 deletions(-)
> create mode 100644 block/replication.c
> create mode 100644 docs/block-replication.txt
>
> --
> 2.5.0
>
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
block/io.c | 12 +-
> block/mirror.c| 290
> +++---
> include/block/block_int.h | 1 +
> 3 files changed, 229 insertions(+), 74 deletions(-)
>
> --
> 2.5.0
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert (git)" <dgilb...@redhat.com> writes:
>
> > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
> >
> > x-blockdev-change has no HMP equivalent, so add x_block_ch
* Changlong Xie (xiecl.f...@cn.fujitsu.com) wrote:
> On 02/01/2016 09:18 AM, Wen Congyang wrote:
> >On 01/29/2016 06:47 PM, Dr. David Alan Gilbert wrote:
> >>* Wen Congyang (we...@cn.fujitsu.com) wrote:
> >>>On 01/29/2016 06:07 PM, Dr. David Alan Gilbert w
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 01/29/2016 06:07 PM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >> On 01/27/2016 07:03 PM, Dr. David Alan Gilbert wrote:
> >>> Hi,
> >>> I've got a block error if I
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 01/27/2016 07:03 PM, Dr. David Alan Gilbert wrote:
> > Hi,
> > I've got a block error if I kill the secondary.
> >
> > Start both primary & secondary
> > kill -9 secondary qemu
> > x_colo_lost_heartbeat
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 01/29/2016 06:47 PM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >> On 01/29/2016 06:07 PM, Dr. David Alan Gilbert wrote:
> >>> * Wen Congyang (we...@cn.fujitsu.com) wrote:
>
but
new connections made by what is now the primary dont need to do anything
special.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 01/23/2016 03:35 AM, Dr. David Alan Gilbert wrote:
> > Hi,
> > I've been looking at what's needed to add a new secondary after
> > a primary failed; from the block side it doesn't look as hard
> > as I'd expected, per
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 01/22/2016 11:14 PM, Dr. David Alan Gilbert wrote:
> > Hi,
> > I can trigger a segfault if I wire in the block replication together with
> > a quorum instance; it only triggers with both of them present but,
> >
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 01/22/2016 11:14 PM, Dr. David Alan Gilbert wrote:
> > Hi,
> > I can trigger a segfault if I wire in the block replication together with
> > a quorum instance; it only triggers with both of them present but,
> >
/jan-2016/qemu/block/io.c:2122
.
So I guess acb->child_iter is wrong, since we only have one child on that
quorum?
and we're trying to do a destroy on the second child.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 03/17/2016 07:25 PM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >> On 03/17/2016 06:07 PM, Alberto Garcia wrote:
> >>> On Thu 17 Mar 2016 10:56:09 AM CET, Wen Congyang wrote:
>
* Max Reitz (mre...@redhat.com) wrote:
> On 29.03.2016 17:50, Dr. David Alan Gilbert wrote:
> > * Eric Blake (ebl...@redhat.com) wrote:
> >> On 03/29/2016 09:38 AM, Max Reitz wrote:
> >>> On 17.03.2016 10:56, Wen Congyang wrote:
> >>>> On 03/1
* Max Reitz (mre...@redhat.com) wrote:
> On 29.03.2016 17:54, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 29.03.2016 17:50, Dr. David Alan Gilbert wrote:
> >>> * Eric Blake (ebl...@redhat.com) wrote:
> >>>
* Eric Blake (ebl...@redhat.com) wrote:
> On 03/29/2016 09:38 AM, Max Reitz wrote:
> > On 17.03.2016 10:56, Wen Congyang wrote:
> >> On 03/17/2016 05:48 PM, Dr. David Alan Gilbert wrote:
> >
> > [...]
> >
> >>> The children.0 notation is really co
guest detects it?
If the primary's local disk (children.0) fails then if we can failover
at that point then the guest carries running on the secondary without
ever knowing about the failure.
Dave
>
> Thanks
> Wen Congyang
>
> >
> > Berto
> >
> >
> > .
> >
>
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Wen Congyang (we...@cn.fujitsu.com) wrote:
> On 03/17/2016 05:48 PM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (we...@cn.fujitsu.com) wrote:
> >> On 03/17/2016 05:10 PM, Alberto Garcia wrote:
> >>> On Thu 17 Mar 2016 02:22:40 AM CET, Wen Congyang <w
* Max Reitz (mre...@redhat.com) wrote:
> On 29.03.2016 18:03, Dr. David Alan Gilbert wrote:
> > * Max Reitz (mre...@redhat.com) wrote:
> >> On 29.03.2016 17:54, Dr. David Alan Gilbert wrote:
> >>> * Max Reitz (mre...@redhat.com) wrote:
> >>>> On 2
ine, and use drive_add even at startup. It solves a lot of the ordering
problems with getting COLO booted.
Dave
>
> > And the "filling up quorum's children" topic then makes me notice that
> > (x-)blockdev-change should probably be transaction-able (so you can
> &g
ated pending.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> ---
> migration/ram.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/migration/ram.c b/mi
qemu-iotests/169 | 134
> tests/qemu-iotests/169.out | 5 +
> tests/qemu-iotests/group | 2 +
> tests/qemu-iotests/iotests.py | 21 +-
> util/hbitmap.c | 8 +
> vl.c | 1 +
> 25 files changed, 1055 insertions(+), 54 deletions(-)
> create mode 100644 migration/block-dirty-bitmap.c
> create mode 100755 tests/qemu-iotests/169
> create mode 100644 tests/qemu-iotests/169.out
>
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
t; they do add to the quoting mess.
>
> I'm having a hard time deciding which one I like less :)
>
> Opinions? Other ideas?
Dave
>
>
>
>
> [1] [PATCH v14 00/21] QAPI/QOM work for non-scalar object properties
> (actually v15)
> Message-Id: <1475246744-29302-1-git-send-email-berra...@redhat.com>
> http://lists.gnu.org/archive/html/qemu-devel/2016-09/msg08238.html
>
> [2] [RFC PATCH] block: Crude initial implementation of -blockdev
> Message-Id: <1485968933-9162-1-git-send-email-arm...@redhat.com>
> http://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00182.html
>
> [3] Message-ID: <87h989ncse@dusky.pond.sub.org>
> http://lists.gnu.org/archive/html/qemu-devel/2016-10/msg04046.html
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> = Introduction =
> >>
> >
> >
> >
> >> = Structured
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> 24.01.2017 22:53, Dr. David Alan Gilbert wrote:
> > * Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> > > 24.01.2017 12:24, Juan Quintela wrote:
> > > > Vladimir Sementsov-Ogievskiy &l
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> 01.02.2017 14:06, Vladimir Sementsov-Ogievskiy wrote:
> > 24.01.2017 22:53, Dr. David Alan Gilbert wrote:
> > > * Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> > > > 24.01.2
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes:
>
ate_complete_precopy(s->to_dst_file, false);
> +s->block_inactive = true;
> }
> }
> qemu_mutex_unlock_iothread();
> @@ -1758,6 +1769,8 @@ fail_invalidate:
> bdrv_invalidate_cache_all(_err);
> if (local_err) {
> error_report_err(local_err);
> +} else {
> +s->block_inactive = false;
> }
I think the fe904 commit also add the problem that this
bdrv_invalidate_cache_all
is done outside the big lock (Stefan and Kevin tell me bdrv_* calls generally
need the lock).
Dave
> }
>
> --
> 1.8.3.1
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Hailiang Zhang (zhang.zhanghaili...@huawei.com) wrote:
> On 2017/1/23 21:40, Dr. David Alan Gilbert wrote:
> > * zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:
> > > commit fe904ea8242cbae2d7e69c052c754b8f5f1ba1d6 fixed a case
> > > which migration aborted QE
@redhat.com>
> >
> > conditioned that Dave agrees with this.
>
> These parameters are unrelated if ram postcopy is disabled. So, I should be
> better to have a possibility of skipping them, then to send unneeded numbers
> and write separate code to read them from the str
e_all() in
> qmp_migrate_cancel()
> directly if we find images become inactive.
>
> Besides, bdrv_invalidate_cache_all() in migration_completion() doesn't have
> the
> protection of big lock, fix it by add the missing qemu_mutex_lock_iothread();
>
> Signed-off-by: zhanghail
T64_MAX);
> qemu_savevm_state_complete_precopy(s->to_dst_file, false);
> +s->block_inactive = true;
> }
> }
> qemu_mutex_unlock_iothread();
> @@ -1755,10 +1766,14 @@ fail_invalidate:
> if (s->state == MIGRATIO
) passes a null @endptr. No functional
> change there, because its conversion consumes the string.
>
> Simplify callers that use @endptr only to fail when it doesn't point
> to '\0' to pass a null @endptr instead.
>
> Cc: Dr. David Alan Gilbert <dgilb...@redhat.com>
> Cc: Eduardo H
* Markus Armbruster (arm...@redhat.com) wrote:
> This makes qemu_strtosz(), qemu_strtosz_mebi() and
> qemu_strtosz_metric() similar to qemu_strtoi64(), except negative
> values are rejected.
>
> Cc: Dr. David Alan Gilbert <dgilb...@redhat.com>
> Cc: Eduardo Habk
* Markus Armbruster (arm...@redhat.com) wrote:
> This will permit its use in parse_option_size().
>
> Cc: Dr. David Alan Gilbert <dgilb...@redhat.com>
> Cc: Eduardo Habkost <ehabk...@redhat.com> (maintainer:X86)
> Cc: Kevin Wolf <kw...@redhat.com> (supporter:Block
his patch..
>
> If I'm not mistaken, libvirt can be patched to explicitly set the same node
> names in the QEMU command line, but that is some extra work to do there. My
> point is if device names are used during migration, when available, this patch
> and the libvirt change is not necessary.
Always best to check with libvirt guys to see what makes sense for them;
ccing in jdenemar.
Dave
> Fam
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
gt; +};
> +
> +void dirty_bitmap_mig_init(void)
> +{
> +QSIMPLEQ_INIT(_bitmap_mig_state.dbms_list);
> +
> +register_savevm_live(NULL, "dirty-bitmap", 0, 1,
> + _dirty_bitmap_handlers,
> + _bitmap_mig_state);
> +}
> diff --git a/migration/migration.c b/migration/migration.c
> index 179bd04..edf5623 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -122,6 +122,9 @@ MigrationIncomingState
> *migration_incoming_get_current(void)
> QLIST_INIT(_current.loadvm_handlers);
> qemu_mutex_init(_current.rp_mutex);
> qemu_event_init(_current.main_thread_load_event, false);
> +
> +init_dirty_bitmap_incoming_migration();
> +
> once = true;
> }
> return _current;
> diff --git a/migration/savevm.c b/migration/savevm.c
> index 54572ef..927a680 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -1651,6 +1651,8 @@ static void loadvm_postcopy_handle_run_bh(void *opaque)
>
> trace_loadvm_postcopy_handle_run_vmstart();
>
> +dirty_bitmap_mig_before_vm_start();
> +
> if (autostart) {
> /* Hold onto your hats, starting the CPU */
> vm_start();
> diff --git a/migration/trace-events b/migration/trace-events
> index 0212929..38fca41 100644
> --- a/migration/trace-events
> +++ b/migration/trace-events
> @@ -222,3 +222,17 @@ colo_vm_state_change(const char *old, const char *new)
> "Change '%s' => '%s'"
> colo_send_message(const char *msg) "Send '%s' message"
> colo_receive_message(const char *msg) "Receive '%s' message"
> colo_failover_set_state(const char *new_state) "new state %s"
> +
> +# migration/block-dirty-bitmap.c
> +send_bitmap_header_enter(void) ""
> +send_bitmap_bits(uint32_t flags, uint64_t start_sector, uint32_t nr_sectors,
> uint64_t data_size) "\n flags:%x\n start_sector: %" PRIu64 "\n
> nr_sectors: %" PRIu32 "\n data_size:%" PRIu64 "\n"
> +dirty_bitmap_save_iterate(int in_postcopy) "in postcopy: %d"
> +dirty_bitmap_save_complete_enter(void) ""
> +dirty_bitmap_save_complete_finish(void) ""
> +dirty_bitmap_save_pending(uint64_t pending, uint64_t max_size) "pending %"
> PRIu64 " max: %" PRIu64
> +dirty_bitmap_load_complete(void) ""
> +dirty_bitmap_load_bits_enter(uint64_t first_sector, uint32_t nr_sectors)
> "chunk: %" PRIu64 " %" PRIu32
> +dirty_bitmap_load_bits_zeroes(void) ""
> +dirty_bitmap_load_header(uint32_t flags) "flags %x"
> +dirty_bitmap_load_enter(void) ""
> +dirty_bitmap_load_success(void) ""
> diff --git a/vl.c b/vl.c
> index b4eaf03..f1ee9ff 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4405,6 +4405,7 @@ int main(int argc, char **argv, char **envp)
>
> blk_mig_init();
> ram_mig_init();
> +dirty_bitmap_mig_init();
>
> /* If the currently selected machine wishes to override the units-per-bus
> * property of its default HBA interface type, do so now. */
> --
> 1.8.3.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
V_DONTNEED)
and we need the semantics of madvise - i.e. it's guaranteed to throw
away the pages, where as posix_madvise *may* throw away the pages if
the kernel feels like it.
Dave
> Kevin
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
_MADV_INVALID) {
> errno = EINVAL;
> return -1;
> }
> #if defined(CONFIG_MADVISE)
> return madvise(addr, len, advice);
> #elif defined(CONFIG_POSIX_MADVISE)
> return posix_madvise(addr, len, advice);
> #else
> errno = EINVAL;
> return -1;
> #endif
> }
>
> >
> > And this is the same case.
> >
> > Berto
> >
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
t;
> I'm pretty sure we need the nasty hack, but I'm also Ccing David for
> his opinion.
Hmm I don't understand enough about pflash to understand the change here;
but generally if you need to keep something unchanged for older
machine types, add a property and then set that property in
the compatib
s outer parameter, it should not stay in global migration state
> after
> + * this function finished */
> + ms->to_dst_file = NULL;
> +
> return ret;
> }
>
> --
> 2.11.1
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> 24.02.2017 16:26, Dr. David Alan Gilbert wrote:
> > * Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> > > Postcopy migration of dirty bitmaps. Only named dirty bitmaps,
> > > associated w
grate_set_speed) will use it after it was freed.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> ---
> migration/savevm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a
early.
In the case where postcopy was never enabled (!migrate_postcopy_ram())
we can move the COMPLETED transition into the lock as well; so I think
then we kind of become safe.
In the case where postcopy was enabled I think we can do the COMPLETED
transition before waiting for the return path to close - I think but
I need to think more about that.
And there seem to be some dodgy cases where we call the invalidate
there after a late postcopy failure; that's bad, we shouldn't reactivate
the source disks after going into postcopy.
So, in summary; this function is a mess - it needs a much bigger
fix than this patch.
Dave
> Kevin
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Hailiang Zhang (zhang.zhanghaili...@huawei.com) wrote:
> Hi，
>
> On 2016/12/6 23:24, Dr. David Alan Gilbert wrote:
> > * Kevin Wolf (kw...@redhat.com) wrote:
> > > Am 19.11.2016 um 12:43 hat zhanghailiang geschrieben:
> > > > commit fe904ea8242cbae2d
p; s->postcopy_after_devices;
> > }
> >
> > +bool migration_is_idle(MigrationState *s)
> > +{
> > +if (!s) {
> > +s = migrate_get_current();
> > + }
> > +
> > +switch (s->state) {
> > +case MIGRATION_STATUS_NONE:
> > +case MIGRATION_STATUS_CANCELLED:
> > +case MIGRATION_STATUS_COMPLETED:
> > +case MIGRATION_STATUS_FAILED:
> > +return true;
> > +case MIGRATION_STATUS_SETUP:
> > +case MIGRATION_STATUS_CANCELLING:
> > +case MIGRATION_STATUS_ACTIVE:
> > +case MIGRATION_STATUS_POSTCOPY_ACTIVE:
> > +case MIGRATION_STATUS_COLO:
> > +return false;
> > +case MIGRATION_STATUS__MAX:
> > +g_assert_not_reached();
> > +}
> > +
> > +return false;
> > +}
> > +
> > MigrationState *migrate_init(const MigrationParams *params)
> > {
> > MigrationState *s = migrate_get_current();
> > @@ -1086,9 +,15 @@ MigrationState *migrate_init(const MigrationParams
> > *params)
> >
> > static GSList *migration_blockers;
> >
> > -void migrate_add_blocker(Error *reason)
> > +int migrate_add_blocker(Error *reason, Error **errp)
> > {
> > -migration_blockers = g_slist_prepend(migration_blockers, reason);
> > +if (migration_is_idle(NULL)) {
> > +migration_blockers = g_slist_prepend(migration_blockers, reason);
> > +return 0;
> > +}
> > +
> > +error_setg(errp, "Cannot block a migration already in-progress");
> > +return -EBUSY;
> > }
> >
> > void migrate_del_blocker(Error *reason)
> > diff --git a/stubs/migr-blocker.c b/stubs/migr-blocker.c
> > index 8ab3604..a5ba18f 100644
> > --- a/stubs/migr-blocker.c
> > +++ b/stubs/migr-blocker.c
> > @@ -2,8 +2,9 @@
> > #include "qemu-common.h"
> > #include "migration/migration.h"
> >
> > -void migrate_add_blocker(Error *reason)
> > +int migrate_add_blocker(Error *reason, Error **errp)
> > {
> > +return 0;
> > }
> >
> > void migrate_del_blocker(Error *reason)
> > diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> > index f62264a..8abb54d 100644
> > --- a/target-i386/kvm.c
> > +++ b/target-i386/kvm.c
> > @@ -961,7 +961,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
> > error_setg(_mig_blocker,
> > "State blocked by non-migratable CPU device"
> > " (invtsc flag)");
> > -migrate_add_blocker(invtsc_mig_blocker);
> > +r = migrate_add_blocker(invtsc_mig_blocker, NULL);
> > +if (r < 0) {
> > +fprintf(stderr, "migrate_add_blocker failed\n");
> > +goto efail;
> > +}
> > /* for savevm */
> > vmstate_x86_cpu.unmigratable = 1;
> > }
> > @@ -969,12 +973,12 @@ int kvm_arch_init_vcpu(CPUState *cs)
> > cpuid_data.cpuid.padding = 0;
> > r = kvm_vcpu_ioctl(cs, KVM_SET_CPUID2, _data);
> > if (r) {
> > -return r;
> > +goto fail;
> > }
> >
> > r = kvm_arch_set_tsc_khz(cs);
> > if (r < 0) {
> > -return r;
> > +goto fail;
> > }
> >
> > /* vcpu's TSC frequency is either specified by user, or following
> > @@ -1001,6 +1005,12 @@ int kvm_arch_init_vcpu(CPUState *cs)
> > }
> >
> > return 0;
> > +
> > + fail:
> > +migrate_del_blocker(invtsc_mig_blocker);
> > + efail:
> > +error_free(invtsc_mig_blocker);
> > +return r;
> > }
> >
> > void kvm_arch_reset_vcpu(X86CPU *cpu)
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
e 'reason' here as well; otherwise you get this
message about blocking a migration but don't know what wanted to block it.
So perhaps set errp from reason and then use error_prepend to add that
extra message?
Dave
> +return -EBUSY;
> }
>
> void migrate_del_blocker(Error *reason)
> diff --git a/stubs/migr-blocker.c b/stubs/migr-blocker.c
> index 8ab3604..a5ba18f 100644
> --- a/stubs/migr-blocker.c
> +++ b/stubs/migr-blocker.c
> @@ -2,8 +2,9 @@
> #include "qemu-common.h"
> #include "migration/migration.h"
>
> -void migrate_add_blocker(Error *reason)
> +int migrate_add_blocker(Error *reason, Error **errp)
> {
> +return 0;
> }
>
> void migrate_del_blocker(Error *reason)
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index f62264a..8abb54d 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -961,7 +961,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
> error_setg(_mig_blocker,
> "State blocked by non-migratable CPU device"
> " (invtsc flag)");
> -migrate_add_blocker(invtsc_mig_blocker);
> +r = migrate_add_blocker(invtsc_mig_blocker, NULL);
> +if (r < 0) {
> +fprintf(stderr, "migrate_add_blocker failed\n");
> +goto efail;
> +}
> /* for savevm */
> vmstate_x86_cpu.unmigratable = 1;
> }
> @@ -969,12 +973,12 @@ int kvm_arch_init_vcpu(CPUState *cs)
> cpuid_data.cpuid.padding = 0;
> r = kvm_vcpu_ioctl(cs, KVM_SET_CPUID2, _data);
> if (r) {
> -return r;
> +goto fail;
> }
>
> r = kvm_arch_set_tsc_khz(cs);
> if (r < 0) {
> -return r;
> +goto fail;
> }
>
> /* vcpu's TSC frequency is either specified by user, or following
> @@ -1001,6 +1005,12 @@ int kvm_arch_init_vcpu(CPUState *cs)
> }
>
> return 0;
> +
> + fail:
> +migrate_del_blocker(invtsc_mig_blocker);
> + efail:
> +error_free(invtsc_mig_blocker);
> +return r;
> }
>
> void kvm_arch_reset_vcpu(X86CPU *cpu)
> --
> 2.9.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
ioContext *aio_context;
> >
> > +if (runstate_check(RUN_STATE_FINISH_MIGRATE) ||
> > +runstate_check(RUN_STATE_POSTMIGRATE) ||
> > +runstate_check(RUN_STATE_PRELAUNCH))
> > +{
> > +bdrv_invalidate_cache_all(_err);
> > +
* Kevin Wolf (kw...@redhat.com) wrote:
> Am 28.03.2017 um 12:55 hat Dr. David Alan Gilbert geschrieben:
> > * Kevin Wolf (kw...@redhat.com) wrote:
> > > Am 25.02.2017 um 20:31 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > > > After migration all drives are
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 28/03/2017 15:16, Vladimir Sementsov-Ogievskiy wrote:
> > 28.03.2017 15:09, Kevin Wolf wrote:
> >> Am 28.03.2017 um 13:13 hat Dr. David Alan Gilbert geschrieben:
> >>> * Kevin Wolf (kw...@redhat.com) wrot
->cur_dirty = sector;
> > +
> > break;
> > }
> > sector += BDRV_SECTORS_PER_DIRTY_CHUNK;
> > --
> > 1.8.3.1
> >
>
> Nice catch above all, thank you!
>
> Reviewed-by: Fam Zheng <f...@redhat.com>
Are you taking that via a block pull?
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
;ops/sec"
> +
> +echo
> +echo === Do postcopy migration to destination ===
> +echo
> +
> +# Slow down migration so much that it definitely won't finish before we can
> +# switch to postcopy
> +silent=yes
> +_send_qemu_cmd $src 'migrate_set_speed 4k' "(qemu)"
&
* Juan Quintela (quint...@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilb...@redhat.com> wrote:
> > * Kevin Wolf (kw...@redhat.com) wrote:
> >> Am 18.04.2017 um 16:47 hat Stefan Hajnoczi geschrieben:
> >> > On Wed, Apr 12, 2017 at 11:18:19AM +
migration is that is uses a BlockBackend
> > > name to identify which device is migrated. However, there can be images
> > > that are not attached to any BlockBackend, or if it is, the BlockBackend
> > > might be anonymous, so this doesn't work. I suppose changing the field
> > > to "device name if available, node-name otherwise" would solve this.
> >
> > Yes, that sounds good and is backwards compatible.
>
> Kevin
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
t;
Thanks, and fixes problem with vmxnet3 migration.
Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
Dave
> ---
> migration/vmstate.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/migration/vmstate.c b/migration/vmstate.c
> index 78b
thout KVM. Basically, S390CPU.irqstate is unused
> if we do not use KVM, and thus no buffer is allocated.
>
> IMHO this is a missing field and the cleaner way to handle such
> missing fields is exist. However this used to work, and I recommended
> QuiFeng Hao to discuss the problem upstream.
>
> By the way, I think, if we want to go back to the old behavior
> and support VMS_VBUFFER with size 0 and nullptr, a much
> cleaner way to do the fix is to change the assert to:
>
> assert(first_elem || !n_elems || !size)
>
> Obviously the other clean way to fix is to implement exists.
>
> I think the migration maintainers (Juan and Dave) should make a
> call regarding if the described usage of VMS_BUFFER is a legal
> or an illegal one.
So is it this code in target/s390x/machine.c ?
VMSTATE_VBUFFER_UINT32(irqstate, S390CPU, 4, NULL,
irqstate_saved_size),
it should be legal for that to be zero length.
It also makes sense that if that's zero length it should be OK for
the pointer to be NULL.
I think it's best if you do change that assert.
Dave
> Regards,
> Halil
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
b/tests/qemu-iotests/175.out
> @@ -0,0 +1,5 @@
> +...
> +----------
> +Ran 3 tests
> +
> +OK
> diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
> index 985b9a6a36..1f4bf03185 100644
> --- a/tests/qemu-iotests/group
> +++ b/tests/qemu-iotests/group
> @@ -167,3 +167,4 @@
> 172 auto
> 173 rw auto
> 174 auto
> +175 auto quick
> --
> 2.11.1
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
d vmstate_save_state(QEMUFile *f, const
> > VMStateDescription *vmsd,
> > int64_t old_offset, written_bytes;
> > QJSON *vmdesc_loop = vmdesc;
> >
> > +if (size == 0) {
> > +field++;
> > +continue;
> > +}
> > trace_vmstate_save_state_loop(vmsd->name, field->name,
> > n_elems);
> > if (field->flags & VMS_POINTER) {
> > first_elem = *(void **)first_elem;
>
> This is really a live migration fix, so I'm adding Juan and Dave to CC.
>
> I suspect the real question is why a field with size 0 was even stored
> in the vmstate to begin with.
Yes; which field is it that's failing?
Dave
> Kevin
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
e source is definitely valid. I'm only questioning if
> 'savevm' (and by extension, any other command that modifies the VM or
> its images) should automagically regain control of the VM, or whether
> that should be more explicit.
How many things other than 'cont' and 'savevm' are there?
We should definitely fix it so a savevm there doesn't assert,
but I'm also unsure if it's worth a separate explicit command.
Dave
> Kevin
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Fri, Aug 11, 2017 at 01:26:00PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrange (berra...@redhat.com) wrote:
> > > The existing QIOChannelSocket class provides the ability to
> > > listen on a single s
listener, (GDestroyNotify)object_unref);
> +}
> +}
> +
> +return data.sioc;
> +}
> +
> +void qio_net_listener_disconnect(QIONetListener *listener)
> +{
> +size_t i;
> +
> +if (listener->disconnected) {
> +return;
> +}
> +
> +for (i = 0; i < listener->nsioc; i++) {
> +if (listener->io_tag[i]) {
> +g_source_remove(listener->io_tag[i]);
> +listener->io_tag[i] = 0;
> +}
> +qio_channel_close(QIO_CHANNEL(listener->sioc[i]), NULL);
> +}
> +listener->disconnected = TRUE;
> +}
> +
> +
> +gboolean qio_net_listener_is_disconnected(QIONetListener *listener)
> +{
> +return listener->disconnected;
> +}
> +
> +static void qio_net_listener_init(Object *obj)
> +{
> +QIONetListener *listener = QIO_NET_LISTENER(obj);
> +
> +listener->disconnected = TRUE;
> +}
> +
> +static void qio_net_listener_finalize(Object *obj)
> +{
> +QIONetListener *listener = QIO_NET_LISTENER(obj);
> +size_t i;
> +
> +qio_net_listener_disconnect(listener);
> +
> +for (i = 0; i < listener->nsioc; i++) {
> +object_unref(OBJECT(listener->sioc[i]));
> +}
> +g_free(listener->io_tag);
> +g_free(listener->sioc);
> +g_free(listener->name);
> +}
> +
> +static const TypeInfo qio_net_listener_info = {
> +.parent = TYPE_OBJECT,
> +.name = TYPE_QIO_NET_LISTENER,
> +.instance_size = sizeof(QIONetListener),
> +.instance_finalize = qio_net_listener_finalize,
> +.instance_init = qio_net_listener_init,
> +.class_size = sizeof(QIONetListenerClass),
> +};
> +
> +
> +static void qio_net_listener_register_types(void)
> +{
> +type_register_static(_net_listener_info);
> +}
> +
> +
> +type_init(qio_net_listener_register_types);
> --
> 2.13.3
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
on it being RAM.
(These first few are pretty much a separable series).
Note a few things below I'd prefer if you reroll:
Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> ---
> migration/migration.c | 39 ++-
> migration/migration.h | 2 ++
than Mebibytes. Add a comment explaining
> that.
>
> Signed-off-by: Markus Armbruster <arm...@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> ---
> hmp.c | 78
> ---
> 1 file
arkus Armbruster <arm...@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
> ---
> hmp.c | 6 --
> migration/migration.c | 4 ++--
> qapi-schema.json | 11 +--
> 3 files changed, 11 insertions(+), 10 deletions(-)
>
d': 'qmp_capabilities' }
>
> ##
> +# @StrOrNull:
> +##
> +{ 'alternate': 'StrOrNull',
> + 'data': { 's': 'str',
> +'n': 'null' } }
> +
> +##
> # @LostTickPolicy:
> #
> # Policy for handling lost ticks in timer devices.
> @@ -1098,8 +1105,8 @@
> '*decompress-threads': 'int',
> '*cpu-throttle-initial': 'int',
> '*cpu-throttle-increment': 'int',
> -'*tls-creds': 'str',
> -'*tls-hostname': 'str',
> +'*tls-creds': 'StrOrNull',
> +'*tls-hostname': 'StrOrNull',
> '*max-bandwidth': 'int',
> '*downtime-limit': 'int',
> '*x-checkpoint-delay': 'int',
> --
> 2.7.5
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> Sizes should use QAPI type 'size' (uint64_t). balloon parameter
> >> @value is 'int'
d = qdict_get_int(qdict, "bps_rd"),
> -.bps_wr = qdict_get_int(qdict, "bps_wr"),
> +.bps = qdict_get_uint(qdict, "bps"),
> +.bps_rd = qdict_get_uint(qdict, "bps_rd"),
> + .bps_wr = qdict_get_uint(qdict, "bps_wr"),
> .iops = qdict_get_int(qdict, "iops"),
> .iops_rd = qdict_get_int(qdict, "iops_rd"),
> .iops_wr = qdict_get_int(qdict, "iops_wr"),
> --
> 2.7.5
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
1 - 100 of 482 matches
Mail list logo
