All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy
@ 2012-07-23 14:22 benoit.canet
  2012-07-23 14:22 ` [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy() benoit.canet
                   ` (4 more replies)
  0 siblings, 5 replies; 16+ messages in thread
From: benoit.canet @ 2012-07-23 14:22 UTC (permalink / raw)
  To: qemu-devel; +Cc: kwolf, stefanha, Benoît Canet, stefanha, pbonzini

From: Benoît Canet <benoit@irqsave.net>

This patchset is designed to avoid starting a live migration while any of
the block device is busy.

Tested with the following sequence:

QEMU 1.1.50 monitor - type 'help' for more information
(qemu) block_stream virtio0 1k
(qemu) migrate tcp:localhost:4444
migrate: Migration is blocked by streaming
(qemu)  block_job_cancel virtio0
(qemu)  migrate tcp:localhost:4444
migrate: Connection can not be completed immediately
(qemu) 
=> migration then succeed

in v2:
stefanha: Rename bdrv_have_block_jobs() to bdrv_are_busy() and make it return -EBUSY.
paolo: remove spurious bdrv_close()

in v3
pm215: rewrite confusing error message

in v4:
stefanha: make the error message more general

Benoît Canet (3):
  block: Add bdrv_are_busy()
  qerror: Add error telling that block dev usage prevents migration
  migration: block migration when streaming block jobs are running.

 block.c     |   13 +++++++++++++
 block.h     |    2 ++
 migration.c |    5 +++++
 qerror.c    |    4 ++++
 qerror.h    |    3 +++
 5 files changed, 27 insertions(+)

-- 
1.7.9.5

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy()
  2012-07-23 14:22 [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy benoit.canet
@ 2012-07-23 14:22 ` benoit.canet
  2012-07-23 17:15   ` Luiz Capitulino
  2012-07-23 14:22 ` [Qemu-devel] [PATCH V4 2/3] qerror: Add error telling that block dev usage prevents migration benoit.canet
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 16+ messages in thread
From: benoit.canet @ 2012-07-23 14:22 UTC (permalink / raw)
  To: qemu-devel; +Cc: kwolf, stefanha, Benoît Canet, stefanha, pbonzini

From: Benoît Canet <benoit@irqsave.net>

bdrv_are_busy will be used to check if any of the bs are in use
or if one of them have a running block job.

The first user will be qmp_migrate().

Signed-off-by: Benoit Canet <benoit@irqsave.net>
---
 block.c |   13 +++++++++++++
 block.h |    2 ++
 2 files changed, 15 insertions(+)

diff --git a/block.c b/block.c
index ce7eb8f..bc8f160 100644
--- a/block.c
+++ b/block.c
@@ -4027,6 +4027,19 @@ out:
     return ret;
 }
 
+int bdrv_are_busy(void)
+{
+    BlockDriverState *bs;
+
+    QTAILQ_FOREACH(bs, &bdrv_states, list) {
+        if (bs->job || bdrv_in_use(bs)) {
+            return -EBUSY;
+        }
+    }
+
+    return 0;
+}
+
 void *block_job_create(const BlockJobType *job_type, BlockDriverState *bs,
                        int64_t speed, BlockDriverCompletionFunc *cb,
                        void *opaque, Error **errp)
diff --git a/block.h b/block.h
index c89590d..0a3de2f 100644
--- a/block.h
+++ b/block.h
@@ -337,6 +337,8 @@ void bdrv_disable_copy_on_read(BlockDriverState *bs);
 void bdrv_set_in_use(BlockDriverState *bs, int in_use);
 int bdrv_in_use(BlockDriverState *bs);
 
+int bdrv_are_busy(void);
+
 enum BlockAcctType {
     BDRV_ACCT_READ,
     BDRV_ACCT_WRITE,
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [Qemu-devel] [PATCH V4 2/3] qerror: Add error telling that block dev usage prevents migration
  2012-07-23 14:22 [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy benoit.canet
  2012-07-23 14:22 ` [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy() benoit.canet
@ 2012-07-23 14:22 ` benoit.canet
  2012-07-23 17:09   ` Luiz Capitulino
  2012-07-23 14:23 ` [Qemu-devel] [PATCH V4 3/3] migration: block migration when any of the block device is busy benoit.canet
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 16+ messages in thread
From: benoit.canet @ 2012-07-23 14:22 UTC (permalink / raw)
  To: qemu-devel; +Cc: kwolf, stefanha, Benoît Canet, stefanha, pbonzini

From: Benoît Canet <benoit@irqsave.net>

Signed-off-by: Benoit Canet <benoit@irqsave.net>
---
 qerror.c |    4 ++++
 qerror.h |    3 +++
 2 files changed, 7 insertions(+)

diff --git a/qerror.c b/qerror.c
index 92c4eff..d2e76ca 100644
--- a/qerror.c
+++ b/qerror.c
@@ -283,6 +283,10 @@ static const QErrorStringTable qerror_table[] = {
         .desc      = "Could not set password",
     },
     {
+        .error_fmt = QERR_BLOCK_DEV_IN_USE_MIGRATION_PREVENTED,
+        .desc      = "Block device in use migration prevented",
+    },
+    {
         .error_fmt = QERR_TOO_MANY_FILES,
         .desc      = "Too many open files",
     },
diff --git a/qerror.h b/qerror.h
index b4c8758..2ef40b5 100644
--- a/qerror.h
+++ b/qerror.h
@@ -233,6 +233,9 @@ QError *qobject_to_qerror(const QObject *obj);
 #define QERR_SET_PASSWD_FAILED \
     "{ 'class': 'SetPasswdFailed', 'data': {} }"
 
+#define QERR_BLOCK_DEV_IN_USE_MIGRATION_PREVENTED \
+    "{ 'class': 'BlockDevInUseMigrationPrevented', 'data': {} }"
+
 #define QERR_TOO_MANY_FILES \
     "{ 'class': 'TooManyFiles', 'data': {} }"
 
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [Qemu-devel] [PATCH V4 3/3] migration: block migration when any of the block device is busy
  2012-07-23 14:22 [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy benoit.canet
  2012-07-23 14:22 ` [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy() benoit.canet
  2012-07-23 14:22 ` [Qemu-devel] [PATCH V4 2/3] qerror: Add error telling that block dev usage prevents migration benoit.canet
@ 2012-07-23 14:23 ` benoit.canet
  2012-07-23 14:58 ` [Qemu-devel] [PATCH V4 0/3] Block migration if " Stefan Hajnoczi
  2012-07-24  9:52 ` Kevin Wolf
  4 siblings, 0 replies; 16+ messages in thread
From: benoit.canet @ 2012-07-23 14:23 UTC (permalink / raw)
  To: qemu-devel; +Cc: kwolf, stefanha, Benoît Canet, stefanha, pbonzini

From: Benoît Canet <benoit@irqsave.net>

Signed-off-by: Benoit Canet <benoit@irqsave.net>
---
 migration.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/migration.c b/migration.c
index 8db1b43..3d68996 100644
--- a/migration.c
+++ b/migration.c
@@ -425,6 +425,11 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
         return;
     }
 
+    if (bdrv_are_busy()) {
+        error_set(errp, QERR_BLOCK_DEV_IN_USE_MIGRATION_PREVENTED);
+        return;
+    }
+
     s = migrate_init(&params);
 
     if (strstart(uri, "tcp:", &p)) {
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy
  2012-07-23 14:22 [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy benoit.canet
                   ` (2 preceding siblings ...)
  2012-07-23 14:23 ` [Qemu-devel] [PATCH V4 3/3] migration: block migration when any of the block device is busy benoit.canet
@ 2012-07-23 14:58 ` Stefan Hajnoczi
  2012-07-24  9:52 ` Kevin Wolf
  4 siblings, 0 replies; 16+ messages in thread
From: Stefan Hajnoczi @ 2012-07-23 14:58 UTC (permalink / raw)
  To: benoit.canet; +Cc: kwolf, pbonzini, Benoît Canet, qemu-devel, stefanha

On Mon, Jul 23, 2012 at 3:22 PM,  <benoit.canet@gmail.com> wrote:
> From: Benoît Canet <benoit@irqsave.net>
>
> This patchset is designed to avoid starting a live migration while any of
> the block device is busy.
>
> Tested with the following sequence:
>
> QEMU 1.1.50 monitor - type 'help' for more information
> (qemu) block_stream virtio0 1k
> (qemu) migrate tcp:localhost:4444
> migrate: Migration is blocked by streaming
> (qemu)  block_job_cancel virtio0
> (qemu)  migrate tcp:localhost:4444
> migrate: Connection can not be completed immediately
> (qemu)
> => migration then succeed
>
> in v2:
> stefanha: Rename bdrv_have_block_jobs() to bdrv_are_busy() and make it return -EBUSY.
> paolo: remove spurious bdrv_close()
>
> in v3
> pm215: rewrite confusing error message
>
> in v4:
> stefanha: make the error message more general
>
> Benoît Canet (3):
>   block: Add bdrv_are_busy()
>   qerror: Add error telling that block dev usage prevents migration
>   migration: block migration when streaming block jobs are running.
>
>  block.c     |   13 +++++++++++++
>  block.h     |    2 ++
>  migration.c |    5 +++++
>  qerror.c    |    4 ++++
>  qerror.h    |    3 +++
>  5 files changed, 27 insertions(+)
>
> --
> 1.7.9.5

Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 2/3] qerror: Add error telling that block dev usage prevents migration
  2012-07-23 14:22 ` [Qemu-devel] [PATCH V4 2/3] qerror: Add error telling that block dev usage prevents migration benoit.canet
@ 2012-07-23 17:09   ` Luiz Capitulino
  0 siblings, 0 replies; 16+ messages in thread
From: Luiz Capitulino @ 2012-07-23 17:09 UTC (permalink / raw)
  To: benoit.canet
  Cc: kwolf, stefanha, stefanha, qemu-devel, pbonzini, Benoît Canet

On Mon, 23 Jul 2012 16:22:59 +0200
benoit.canet@gmail.com wrote:

> From: Benoît Canet <benoit@irqsave.net>
> 
> Signed-off-by: Benoit Canet <benoit@irqsave.net>
> ---
>  qerror.c |    4 ++++
>  qerror.h |    3 +++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/qerror.c b/qerror.c
> index 92c4eff..d2e76ca 100644
> --- a/qerror.c
> +++ b/qerror.c
> @@ -283,6 +283,10 @@ static const QErrorStringTable qerror_table[] = {
>          .desc      = "Could not set password",
>      },
>      {
> +        .error_fmt = QERR_BLOCK_DEV_IN_USE_MIGRATION_PREVENTED,
> +        .desc      = "Block device in use migration prevented",
> +    },

Let's avoid an specific error. We have two options:

 1. Use QERR_MIGRATION_NOT_SUPPORTED

 2. Add QERR_MIGRATION_BLOCKED

> +    {
>          .error_fmt = QERR_TOO_MANY_FILES,
>          .desc      = "Too many open files",
>      },
> diff --git a/qerror.h b/qerror.h
> index b4c8758..2ef40b5 100644
> --- a/qerror.h
> +++ b/qerror.h
> @@ -233,6 +233,9 @@ QError *qobject_to_qerror(const QObject *obj);
>  #define QERR_SET_PASSWD_FAILED \
>      "{ 'class': 'SetPasswdFailed', 'data': {} }"
>  
> +#define QERR_BLOCK_DEV_IN_USE_MIGRATION_PREVENTED \
> +    "{ 'class': 'BlockDevInUseMigrationPrevented', 'data': {} }"
> +
>  #define QERR_TOO_MANY_FILES \
>      "{ 'class': 'TooManyFiles', 'data': {} }"
>  

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy()
  2012-07-23 14:22 ` [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy() benoit.canet
@ 2012-07-23 17:15   ` Luiz Capitulino
  2012-07-24 10:10     ` Benoît Canet
  0 siblings, 1 reply; 16+ messages in thread
From: Luiz Capitulino @ 2012-07-23 17:15 UTC (permalink / raw)
  To: benoit.canet
  Cc: kwolf, stefanha, stefanha, qemu-devel, pbonzini, Benoît Canet

On Mon, 23 Jul 2012 16:22:58 +0200
benoit.canet@gmail.com wrote:

> From: Benoît Canet <benoit@irqsave.net>
> 
> bdrv_are_busy will be used to check if any of the bs are in use
> or if one of them have a running block job.
> 
> The first user will be qmp_migrate().
> 
> Signed-off-by: Benoit Canet <benoit@irqsave.net>
> ---
>  block.c |   13 +++++++++++++
>  block.h |    2 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/block.c b/block.c
> index ce7eb8f..bc8f160 100644
> --- a/block.c
> +++ b/block.c
> @@ -4027,6 +4027,19 @@ out:
>      return ret;
>  }
>  
> +int bdrv_are_busy(void)
> +{
> +    BlockDriverState *bs;
> +
> +    QTAILQ_FOREACH(bs, &bdrv_states, list) {
> +        if (bs->job || bdrv_in_use(bs)) {
> +            return -EBUSY;
> +        }
> +    }

IMO, this should return true/false. The name is a bit misleading too, as it
gives the impression that are existing bdrvs are busy. I'd call it
bdrv_any_busy() or bdrv_any_in_use().

> +
> +    return 0;
> +}
> +
>  void *block_job_create(const BlockJobType *job_type, BlockDriverState *bs,
>                         int64_t speed, BlockDriverCompletionFunc *cb,
>                         void *opaque, Error **errp)
> diff --git a/block.h b/block.h
> index c89590d..0a3de2f 100644
> --- a/block.h
> +++ b/block.h
> @@ -337,6 +337,8 @@ void bdrv_disable_copy_on_read(BlockDriverState *bs);
>  void bdrv_set_in_use(BlockDriverState *bs, int in_use);
>  int bdrv_in_use(BlockDriverState *bs);
>  
> +int bdrv_are_busy(void);
> +
>  enum BlockAcctType {
>      BDRV_ACCT_READ,
>      BDRV_ACCT_WRITE,

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy
  2012-07-23 14:22 [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy benoit.canet
                   ` (3 preceding siblings ...)
  2012-07-23 14:58 ` [Qemu-devel] [PATCH V4 0/3] Block migration if " Stefan Hajnoczi
@ 2012-07-24  9:52 ` Kevin Wolf
  2012-07-24 10:04   ` Stefan Hajnoczi
  4 siblings, 1 reply; 16+ messages in thread
From: Kevin Wolf @ 2012-07-24  9:52 UTC (permalink / raw)
  To: benoit.canet; +Cc: stefanha, pbonzini, Benoît Canet, qemu-devel, stefanha

Am 23.07.2012 16:22, schrieb benoit.canet@gmail.com:
> From: Benoît Canet <benoit@irqsave.net>
> 
> This patchset is designed to avoid starting a live migration while any of
> the block device is busy.
> 
> Tested with the following sequence:
> 
> QEMU 1.1.50 monitor - type 'help' for more information
> (qemu) block_stream virtio0 1k
> (qemu) migrate tcp:localhost:4444
> migrate: Migration is blocked by streaming
> (qemu)  block_job_cancel virtio0
> (qemu)  migrate tcp:localhost:4444
> migrate: Connection can not be completed immediately
> (qemu) 
> => migration then succeed

Maybe I'm missing the obvious, but why? Migration will stop the
streaming if it isn't restarted explicitly on the destination, but I
think that's expected.

Also, there are migration blockers. Wouldn't it be better to use them
instead of adding more special-case code to migration.c?

Kevin

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy
  2012-07-24  9:52 ` Kevin Wolf
@ 2012-07-24 10:04   ` Stefan Hajnoczi
  2012-07-24 10:19     ` Kevin Wolf
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Hajnoczi @ 2012-07-24 10:04 UTC (permalink / raw)
  To: Kevin Wolf
  Cc: pbonzini, benoit.canet, Benoît Canet, qemu-devel, stefanha

On Tue, Jul 24, 2012 at 10:52 AM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 23.07.2012 16:22, schrieb benoit.canet@gmail.com:
>> From: Benoît Canet <benoit@irqsave.net>
>>
>> This patchset is designed to avoid starting a live migration while any of
>> the block device is busy.
>>
>> Tested with the following sequence:
>>
>> QEMU 1.1.50 monitor - type 'help' for more information
>> (qemu) block_stream virtio0 1k
>> (qemu) migrate tcp:localhost:4444
>> migrate: Migration is blocked by streaming
>> (qemu)  block_job_cancel virtio0
>> (qemu)  migrate tcp:localhost:4444
>> migrate: Connection can not be completed immediately
>> (qemu)
>> => migration then succeed
>
> Maybe I'm missing the obvious, but why? Migration will stop the
> streaming if it isn't restarted explicitly on the destination, but I
> think that's expected.

Hmm...maybe this is a policy decision.  I figure if you are running
image streaming and try to migrate, chances are you're migration will
break on the destination host because you were trying to do pre-copy
storage migration and never finished.

Stefan

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy()
  2012-07-23 17:15   ` Luiz Capitulino
@ 2012-07-24 10:10     ` Benoît Canet
  2012-07-24 12:55       ` Luiz Capitulino
  0 siblings, 1 reply; 16+ messages in thread
From: Benoît Canet @ 2012-07-24 10:10 UTC (permalink / raw)
  To: Luiz Capitulino, Anthony Liguori
  Cc: kwolf, benoit.canet, stefanha, stefanha, qemu-devel, pbonzini

Le Monday 23 Jul 2012 à 14:15:01 (-0300), Luiz Capitulino a écrit :
> On Mon, 23 Jul 2012 16:22:58 +0200
> benoit.canet@gmail.com wrote:
> 
> > From: Benoît Canet <benoit@irqsave.net>
> > 
> > bdrv_are_busy will be used to check if any of the bs are in use
> > or if one of them have a running block job.
> > 
> > The first user will be qmp_migrate().
> > 
> > Signed-off-by: Benoit Canet <benoit@irqsave.net>
> > ---
> >  block.c |   13 +++++++++++++
> >  block.h |    2 ++
> >  2 files changed, 15 insertions(+)
> > 
> > diff --git a/block.c b/block.c
> > index ce7eb8f..bc8f160 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -4027,6 +4027,19 @@ out:
> >      return ret;
> >  }
> >  
> > +int bdrv_are_busy(void)
> > +{
> > +    BlockDriverState *bs;
> > +
> > +    QTAILQ_FOREACH(bs, &bdrv_states, list) {
> > +        if (bs->job || bdrv_in_use(bs)) {
> > +            return -EBUSY;
> > +        }
> > +    }
> 
> IMO, this should return true/false. The name is a bit misleading too, as it
> gives the impression that are existing bdrvs are busy. I'd call it
> bdrv_any_busy() or bdrv_any_in_use().

Hello Anthony,

Stefanha is in favor of returning -EBUSY and Luiz Capitulino would prefer
the function to return a boolean.
Could you decide which option is the best ?

Regards

Benoît

> 
> > +
> > +    return 0;
> > +}
> > +
> >  void *block_job_create(const BlockJobType *job_type, BlockDriverState *bs,
> >                         int64_t speed, BlockDriverCompletionFunc *cb,
> >                         void *opaque, Error **errp)
> > diff --git a/block.h b/block.h
> > index c89590d..0a3de2f 100644
> > --- a/block.h
> > +++ b/block.h
> > @@ -337,6 +337,8 @@ void bdrv_disable_copy_on_read(BlockDriverState *bs);
> >  void bdrv_set_in_use(BlockDriverState *bs, int in_use);
> >  int bdrv_in_use(BlockDriverState *bs);
> >  
> > +int bdrv_are_busy(void);
> > +
> >  enum BlockAcctType {
> >      BDRV_ACCT_READ,
> >      BDRV_ACCT_WRITE,
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy
  2012-07-24 10:04   ` Stefan Hajnoczi
@ 2012-07-24 10:19     ` Kevin Wolf
  2012-07-24 11:12       ` Paolo Bonzini
  0 siblings, 1 reply; 16+ messages in thread
From: Kevin Wolf @ 2012-07-24 10:19 UTC (permalink / raw)
  To: Stefan Hajnoczi
  Cc: pbonzini, benoit.canet, Benoît Canet, qemu-devel, stefanha

Am 24.07.2012 12:04, schrieb Stefan Hajnoczi:
> On Tue, Jul 24, 2012 at 10:52 AM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 23.07.2012 16:22, schrieb benoit.canet@gmail.com:
>>> From: Benoît Canet <benoit@irqsave.net>
>>>
>>> This patchset is designed to avoid starting a live migration while any of
>>> the block device is busy.
>>>
>>> Tested with the following sequence:
>>>
>>> QEMU 1.1.50 monitor - type 'help' for more information
>>> (qemu) block_stream virtio0 1k
>>> (qemu) migrate tcp:localhost:4444
>>> migrate: Migration is blocked by streaming
>>> (qemu)  block_job_cancel virtio0
>>> (qemu)  migrate tcp:localhost:4444
>>> migrate: Connection can not be completed immediately
>>> (qemu)
>>> => migration then succeed
>>
>> Maybe I'm missing the obvious, but why? Migration will stop the
>> streaming if it isn't restarted explicitly on the destination, but I
>> think that's expected.
> 
> Hmm...maybe this is a policy decision.  I figure if you are running
> image streaming and try to migrate, chances are you're migration will
> break on the destination host because you were trying to do pre-copy
> storage migration and never finished.

Sure, if you're migrating without shared storage, you always need to
know what you're doing.

But you could be doing a post-copy storage migration and migrate to the
next host before it has completed. I think this is a completely
legitimate action that shouldn't be blocked.

Kevin

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy
  2012-07-24 10:19     ` Kevin Wolf
@ 2012-07-24 11:12       ` Paolo Bonzini
  0 siblings, 0 replies; 16+ messages in thread
From: Paolo Bonzini @ 2012-07-24 11:12 UTC (permalink / raw)
  To: Kevin Wolf
  Cc: Stefan Hajnoczi, benoit canet, Benoît Canet, qemu-devel, stefanha


> > Hmm...maybe this is a policy decision.  I figure if you are running
> > image streaming and try to migrate, chances are you're migration
> > will break on the destination host because you were trying to do
> > pre-copy storage migration and never finished.

Streaming is post-copy, and can be interrupted every time you want.

Mirroring is pre-copy.  That's another story, but even then the way
to "emulate" migrate -b/-i (and make it much more efficient, as you can
see from the last few patches I just posted) is exactly to run mirroring
in parallel to RAM migration.  This is relatively difficult to do by hand
(though I'd like to improve it in 1.3 if only to get rid of block-migration.c)
and requires giving the user a considerable amount of rope, but it is doable.

So, thinking about it a bit more, this patch looks like a good idea in principle,
but actually it is counterproductive.

Paolo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy()
  2012-07-24 10:10     ` Benoît Canet
@ 2012-07-24 12:55       ` Luiz Capitulino
  2012-07-24 13:29         ` Kevin Wolf
  0 siblings, 1 reply; 16+ messages in thread
From: Luiz Capitulino @ 2012-07-24 12:55 UTC (permalink / raw)
  To: Benoît Canet
  Cc: kwolf, Anthony Liguori, benoit.canet, stefanha, stefanha,
	qemu-devel, pbonzini

On Tue, 24 Jul 2012 12:10:39 +0200
Benoît Canet <benoit.canet@irqsave.net> wrote:

> Le Monday 23 Jul 2012 à 14:15:01 (-0300), Luiz Capitulino a écrit :
> > On Mon, 23 Jul 2012 16:22:58 +0200
> > benoit.canet@gmail.com wrote:
> > 
> > > From: Benoît Canet <benoit@irqsave.net>
> > > 
> > > bdrv_are_busy will be used to check if any of the bs are in use
> > > or if one of them have a running block job.
> > > 
> > > The first user will be qmp_migrate().
> > > 
> > > Signed-off-by: Benoit Canet <benoit@irqsave.net>
> > > ---
> > >  block.c |   13 +++++++++++++
> > >  block.h |    2 ++
> > >  2 files changed, 15 insertions(+)
> > > 
> > > diff --git a/block.c b/block.c
> > > index ce7eb8f..bc8f160 100644
> > > --- a/block.c
> > > +++ b/block.c
> > > @@ -4027,6 +4027,19 @@ out:
> > >      return ret;
> > >  }
> > >  
> > > +int bdrv_are_busy(void)
> > > +{
> > > +    BlockDriverState *bs;
> > > +
> > > +    QTAILQ_FOREACH(bs, &bdrv_states, list) {
> > > +        if (bs->job || bdrv_in_use(bs)) {
> > > +            return -EBUSY;
> > > +        }
> > > +    }
> > 
> > IMO, this should return true/false. The name is a bit misleading too, as it
> > gives the impression that are existing bdrvs are busy. I'd call it
> > bdrv_any_busy() or bdrv_any_in_use().
> 
> Hello Anthony,
> 
> Stefanha is in favor of returning -EBUSY and Luiz Capitulino would prefer
> the function to return a boolean.
> Could you decide which option is the best ?

Stefan's opnion certainly has precedence over mine on block layer stuff,
this was just an IMO.

Stefan, did you consider returning a boolean?

> 
> Regards
> 
> Benoît
> 
> > 
> > > +
> > > +    return 0;
> > > +}
> > > +
> > >  void *block_job_create(const BlockJobType *job_type, BlockDriverState *bs,
> > >                         int64_t speed, BlockDriverCompletionFunc *cb,
> > >                         void *opaque, Error **errp)
> > > diff --git a/block.h b/block.h
> > > index c89590d..0a3de2f 100644
> > > --- a/block.h
> > > +++ b/block.h
> > > @@ -337,6 +337,8 @@ void bdrv_disable_copy_on_read(BlockDriverState *bs);
> > >  void bdrv_set_in_use(BlockDriverState *bs, int in_use);
> > >  int bdrv_in_use(BlockDriverState *bs);
> > >  
> > > +int bdrv_are_busy(void);
> > > +
> > >  enum BlockAcctType {
> > >      BDRV_ACCT_READ,
> > >      BDRV_ACCT_WRITE,
> > 
> 

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy()
  2012-07-24 12:55       ` Luiz Capitulino
@ 2012-07-24 13:29         ` Kevin Wolf
  2012-07-24 14:37           ` Benoît Canet
  0 siblings, 1 reply; 16+ messages in thread
From: Kevin Wolf @ 2012-07-24 13:29 UTC (permalink / raw)
  To: Luiz Capitulino
  Cc: Benoît Canet, Anthony Liguori, benoit.canet, stefanha,
	stefanha, qemu-devel, pbonzini

Am 24.07.2012 14:55, schrieb Luiz Capitulino:
> On Tue, 24 Jul 2012 12:10:39 +0200
> Benoît Canet <benoit.canet@irqsave.net> wrote:
> 
>> Le Monday 23 Jul 2012 à 14:15:01 (-0300), Luiz Capitulino a écrit :
>>> On Mon, 23 Jul 2012 16:22:58 +0200
>>> benoit.canet@gmail.com wrote:
>>>
>>>> From: Benoît Canet <benoit@irqsave.net>
>>>>
>>>> bdrv_are_busy will be used to check if any of the bs are in use
>>>> or if one of them have a running block job.
>>>>
>>>> The first user will be qmp_migrate().
>>>>
>>>> Signed-off-by: Benoit Canet <benoit@irqsave.net>
>>>> ---
>>>>  block.c |   13 +++++++++++++
>>>>  block.h |    2 ++
>>>>  2 files changed, 15 insertions(+)
>>>>
>>>> diff --git a/block.c b/block.c
>>>> index ce7eb8f..bc8f160 100644
>>>> --- a/block.c
>>>> +++ b/block.c
>>>> @@ -4027,6 +4027,19 @@ out:
>>>>      return ret;
>>>>  }
>>>>  
>>>> +int bdrv_are_busy(void)
>>>> +{
>>>> +    BlockDriverState *bs;
>>>> +
>>>> +    QTAILQ_FOREACH(bs, &bdrv_states, list) {
>>>> +        if (bs->job || bdrv_in_use(bs)) {
>>>> +            return -EBUSY;
>>>> +        }
>>>> +    }
>>>
>>> IMO, this should return true/false. The name is a bit misleading too, as it
>>> gives the impression that are existing bdrvs are busy. I'd call it
>>> bdrv_any_busy() or bdrv_any_in_use().
>>
>> Hello Anthony,
>>
>> Stefanha is in favor of returning -EBUSY and Luiz Capitulino would prefer
>> the function to return a boolean.
>> Could you decide which option is the best ?
> 
> Stefan's opnion certainly has precedence over mine on block layer stuff,
> this was just an IMO.
> 
> Stefan, did you consider returning a boolean?

I'm with you in this point, Luiz (as well as with the rename to
bdrv_is_any_busy). And actually I think Benoît may have misunderstood
and Stefan is as well. What he said is:

> I think bdrv_have_block_jobs() is too specific and would use
> bdrv_in_use(bs) here to give basically an EBUSY-type error.

I don't think this was about bool vs. -errno, but more about checking
only block jobs vs. all kinds of things that can have a block device in use.

Anyway, I believe we came to the conclusion that even the intention of
the series is wrong, as in many cases migrating while an image is being
streamed is perfectly fine. So the details don't really matter any more.

Kevin

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy()
  2012-07-24 13:29         ` Kevin Wolf
@ 2012-07-24 14:37           ` Benoît Canet
  2012-07-24 14:42             ` Kevin Wolf
  0 siblings, 1 reply; 16+ messages in thread
From: Benoît Canet @ 2012-07-24 14:37 UTC (permalink / raw)
  To: Kevin Wolf
  Cc: Benoît Canet, Anthony Liguori, benoit.canet, stefanha,
	stefanha, qemu-devel, Luiz Capitulino, pbonzini

Le Tuesday 24 Jul 2012 à 15:29:11 (+0200), Kevin Wolf a écrit :
> Am 24.07.2012 14:55, schrieb Luiz Capitulino:
> > On Tue, 24 Jul 2012 12:10:39 +0200
> > Benoît Canet <benoit.canet@irqsave.net> wrote:
> > 
> >> Le Monday 23 Jul 2012 à 14:15:01 (-0300), Luiz Capitulino a écrit :
> >>> On Mon, 23 Jul 2012 16:22:58 +0200
> >>> benoit.canet@gmail.com wrote:
> >>>
> >>>> From: Benoît Canet <benoit@irqsave.net>
> >>>>
> >>>> bdrv_are_busy will be used to check if any of the bs are in use
> >>>> or if one of them have a running block job.
> >>>>
> >>>> The first user will be qmp_migrate().
> >>>>
> >>>> Signed-off-by: Benoit Canet <benoit@irqsave.net>
> >>>> ---
> >>>>  block.c |   13 +++++++++++++
> >>>>  block.h |    2 ++
> >>>>  2 files changed, 15 insertions(+)
> >>>>
> >>>> diff --git a/block.c b/block.c
> >>>> index ce7eb8f..bc8f160 100644
> >>>> --- a/block.c
> >>>> +++ b/block.c
> >>>> @@ -4027,6 +4027,19 @@ out:
> >>>>      return ret;
> >>>>  }
> >>>>  
> >>>> +int bdrv_are_busy(void)
> >>>> +{
> >>>> +    BlockDriverState *bs;
> >>>> +
> >>>> +    QTAILQ_FOREACH(bs, &bdrv_states, list) {
> >>>> +        if (bs->job || bdrv_in_use(bs)) {
> >>>> +            return -EBUSY;
> >>>> +        }
> >>>> +    }
> >>>
> >>> IMO, this should return true/false. The name is a bit misleading too, as it
> >>> gives the impression that are existing bdrvs are busy. I'd call it
> >>> bdrv_any_busy() or bdrv_any_in_use().
> >>
> >> Hello Anthony,
> >>
> >> Stefanha is in favor of returning -EBUSY and Luiz Capitulino would prefer
> >> the function to return a boolean.
> >> Could you decide which option is the best ?
> > 
> > Stefan's opnion certainly has precedence over mine on block layer stuff,
> > this was just an IMO.
> > 
> > Stefan, did you consider returning a boolean?
> 
> I'm with you in this point, Luiz (as well as with the rename to
> bdrv_is_any_busy). And actually I think Benoît may have misunderstood
> and Stefan is as well. What he said is:
> 
> > I think bdrv_have_block_jobs() is too specific and would use
> > bdrv_in_use(bs) here to give basically an EBUSY-type error.
> 
> I don't think this was about bool vs. -errno, but more about checking
> only block jobs vs. all kinds of things that can have a block device in use.
> 
> Anyway, I believe we came to the conclusion that even the intention of
> the series is wrong, as in many cases migrating while an image is being
> streamed is perfectly fine. So the details don't really matter any more.
> 

Just to be sure.

In case of a migration with shared storage the migration stops the streaming
when the switch between vm is done.
So starting a streaming after the begining of a migration is also right.
Is that correct ?

Benoît

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy()
  2012-07-24 14:37           ` Benoît Canet
@ 2012-07-24 14:42             ` Kevin Wolf
  0 siblings, 0 replies; 16+ messages in thread
From: Kevin Wolf @ 2012-07-24 14:42 UTC (permalink / raw)
  To: Benoît Canet
  Cc: Anthony Liguori, benoit.canet, stefanha, stefanha, qemu-devel,
	Luiz Capitulino, pbonzini

Am 24.07.2012 16:37, schrieb Benoît Canet:
> Le Tuesday 24 Jul 2012 à 15:29:11 (+0200), Kevin Wolf a écrit :
>> Am 24.07.2012 14:55, schrieb Luiz Capitulino:
>>> On Tue, 24 Jul 2012 12:10:39 +0200
>>> Benoît Canet <benoit.canet@irqsave.net> wrote:
>>>
>>>> Le Monday 23 Jul 2012 à 14:15:01 (-0300), Luiz Capitulino a écrit :
>>>>> On Mon, 23 Jul 2012 16:22:58 +0200
>>>>> benoit.canet@gmail.com wrote:
>>>>>
>>>>>> From: Benoît Canet <benoit@irqsave.net>
>>>>>>
>>>>>> bdrv_are_busy will be used to check if any of the bs are in use
>>>>>> or if one of them have a running block job.
>>>>>>
>>>>>> The first user will be qmp_migrate().
>>>>>>
>>>>>> Signed-off-by: Benoit Canet <benoit@irqsave.net>
>>>>>> ---
>>>>>>  block.c |   13 +++++++++++++
>>>>>>  block.h |    2 ++
>>>>>>  2 files changed, 15 insertions(+)
>>>>>>
>>>>>> diff --git a/block.c b/block.c
>>>>>> index ce7eb8f..bc8f160 100644
>>>>>> --- a/block.c
>>>>>> +++ b/block.c
>>>>>> @@ -4027,6 +4027,19 @@ out:
>>>>>>      return ret;
>>>>>>  }
>>>>>>  
>>>>>> +int bdrv_are_busy(void)
>>>>>> +{
>>>>>> +    BlockDriverState *bs;
>>>>>> +
>>>>>> +    QTAILQ_FOREACH(bs, &bdrv_states, list) {
>>>>>> +        if (bs->job || bdrv_in_use(bs)) {
>>>>>> +            return -EBUSY;
>>>>>> +        }
>>>>>> +    }
>>>>>
>>>>> IMO, this should return true/false. The name is a bit misleading too, as it
>>>>> gives the impression that are existing bdrvs are busy. I'd call it
>>>>> bdrv_any_busy() or bdrv_any_in_use().
>>>>
>>>> Hello Anthony,
>>>>
>>>> Stefanha is in favor of returning -EBUSY and Luiz Capitulino would prefer
>>>> the function to return a boolean.
>>>> Could you decide which option is the best ?
>>>
>>> Stefan's opnion certainly has precedence over mine on block layer stuff,
>>> this was just an IMO.
>>>
>>> Stefan, did you consider returning a boolean?
>>
>> I'm with you in this point, Luiz (as well as with the rename to
>> bdrv_is_any_busy). And actually I think Benoît may have misunderstood
>> and Stefan is as well. What he said is:
>>
>>> I think bdrv_have_block_jobs() is too specific and would use
>>> bdrv_in_use(bs) here to give basically an EBUSY-type error.
>>
>> I don't think this was about bool vs. -errno, but more about checking
>> only block jobs vs. all kinds of things that can have a block device in use.
>>
>> Anyway, I believe we came to the conclusion that even the intention of
>> the series is wrong, as in many cases migrating while an image is being
>> streamed is perfectly fine. So the details don't really matter any more.
>>
> 
> Just to be sure.
> 
> In case of a migration with shared storage the migration stops the streaming
> when the switch between vm is done.
> So starting a streaming after the begining of a migration is also right.
> Is that correct ?

Yes, starting streaming itself shouldn't be a problem. Usually streaming
is combined with doing a snapshot first, though, and that could become a
problem if the destination didn't already know the snapshot when it was
started. I believe it's already blocked today.

Kevin

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2012-07-24 14:45 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-23 14:22 [Qemu-devel] [PATCH V4 0/3] Block migration if any of the block device is busy benoit.canet
2012-07-23 14:22 ` [Qemu-devel] [PATCH V4 1/3] block: Add bdrv_are_busy() benoit.canet
2012-07-23 17:15   ` Luiz Capitulino
2012-07-24 10:10     ` Benoît Canet
2012-07-24 12:55       ` Luiz Capitulino
2012-07-24 13:29         ` Kevin Wolf
2012-07-24 14:37           ` Benoît Canet
2012-07-24 14:42             ` Kevin Wolf
2012-07-23 14:22 ` [Qemu-devel] [PATCH V4 2/3] qerror: Add error telling that block dev usage prevents migration benoit.canet
2012-07-23 17:09   ` Luiz Capitulino
2012-07-23 14:23 ` [Qemu-devel] [PATCH V4 3/3] migration: block migration when any of the block device is busy benoit.canet
2012-07-23 14:58 ` [Qemu-devel] [PATCH V4 0/3] Block migration if " Stefan Hajnoczi
2012-07-24  9:52 ` Kevin Wolf
2012-07-24 10:04   ` Stefan Hajnoczi
2012-07-24 10:19     ` Kevin Wolf
2012-07-24 11:12       ` Paolo Bonzini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.