Am 18.05.2012 19:08, schrieb Paolo Bonzini:
Hi all,
the current block job API is designed for streaming; one property of
streaming is that in case of an error it can be restarted from the point
where it was left.
In QEMU 1.2 I would like to add an implementation of mirroring (live
block
Il 21/05/2012 11:29, Kevin Wolf ha scritto:
* block-stream: I propose adding two options to the existing
block-stream command. If this is rejected, only mirroring will be able
to use rerror/werror.
The new options are of course rerror/werror. They are enum options,
with the following
Am 21.05.2012 12:02, schrieb Paolo Bonzini:
Il 21/05/2012 11:29, Kevin Wolf ha scritto:
* block-stream: I propose adding two options to the existing
block-stream command. If this is rejected, only mirroring will be able
to use rerror/werror.
The new options are of course rerror/werror.
Il 21/05/2012 12:32, Kevin Wolf ha scritto:
Am 21.05.2012 12:02, schrieb Paolo Bonzini:
Il 21/05/2012 11:29, Kevin Wolf ha scritto:
* block-stream: I propose adding two options to the existing
block-stream command. If this is rejected, only mirroring will be able
to use rerror/werror.
The
This makes sense given the generic nature of block jobs. If mirroring
was only for live migration, for example, then we could avoid all this
by choosing a single policy. As a generic operation it's nice to have
control over error policy.
Stefan
Am 21.05.2012 13:02, schrieb Paolo Bonzini:
Il 21/05/2012 12:32, Kevin Wolf ha scritto:
Am 21.05.2012 12:02, schrieb Paolo Bonzini:
Il 21/05/2012 11:29, Kevin Wolf ha scritto:
* block-stream: I propose adding two options to the existing
block-stream command. If this is rejected, only
On 05/21/2012 05:02 AM, Paolo Bonzini wrote:
Eric, is it a problem for libvirt if a pause or target error during
mirroring causes the job to exit steady state? That means that after a
target error the offset can go back from 100% to 100%.
Libvirt would really like to have events present. If
On Fri, 18 May 2012 19:08:42 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Modified QMP commands
=
As we have discussed on the ML, we're not going to extend QMP commands.
I understand your reasoning, and since the beginning I thought this was
something useful to do, but
Am 21.05.2012 15:59, schrieb Luiz Capitulino:
On Fri, 18 May 2012 19:08:42 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Modified QMP commands
=
As we have discussed on the ML, we're not going to extend QMP commands.
I understand your reasoning, and since the
On 05/21/2012 08:59 AM, Luiz Capitulino wrote:
On Fri, 18 May 2012 19:08:42 +0200
Paolo Bonzinipbonz...@redhat.com wrote:
Modified QMP commands
=
As we have discussed on the ML, we're not going to extend QMP commands.
I understand your reasoning, and since the beginning
On Mon, 21 May 2012 09:10:40 -0500
Anthony Liguori anth...@codemonkey.ws wrote:
On 05/21/2012 08:59 AM, Luiz Capitulino wrote:
On Fri, 18 May 2012 19:08:42 +0200
Paolo Bonzinipbonz...@redhat.com wrote:
Modified QMP commands
=
As we have discussed on the ML,
On Mon, 21 May 2012 16:09:28 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 21.05.2012 15:59, schrieb Luiz Capitulino:
On Fri, 18 May 2012 19:08:42 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Modified QMP commands
=
As we have discussed on the ML, we're not
Am 21.05.2012 16:10, schrieb Anthony Liguori:
On 05/21/2012 08:59 AM, Luiz Capitulino wrote:
On Fri, 18 May 2012 19:08:42 +0200
Paolo Bonzinipbonz...@redhat.com wrote:
Modified QMP commands
=
As we have discussed on the ML, we're not going to extend QMP commands.
I
On 05/21/2012 09:09 AM, Kevin Wolf wrote:
Am 21.05.2012 15:59, schrieb Luiz Capitulino:
On Fri, 18 May 2012 19:08:42 +0200
Paolo Bonzinipbonz...@redhat.com wrote:
Modified QMP commands
=
As we have discussed on the ML, we're not going to extend QMP commands.
I
On 05/21/2012 09:16 AM, Luiz Capitulino wrote:
On Mon, 21 May 2012 09:10:40 -0500
Anthony Liguorianth...@codemonkey.ws wrote:
On 05/21/2012 08:59 AM, Luiz Capitulino wrote:
On Fri, 18 May 2012 19:08:42 +0200
Paolo Bonzinipbonz...@redhat.com wrote:
Modified QMP commands
Il 21/05/2012 16:19, Anthony Liguori ha scritto:
I'm not against it in principle, just in practice. Today, checking
whether a command exists is:
commands = qmp.query_commands()
if 'block-stream' in commands:
# has block-stream
I have a hard time envisioning how schema
Il 21/05/2012 15:59, Luiz Capitulino ha scritto:
I understand your reasoning, and since the beginning I thought this was
something useful to do, but we've already settled for not doing this.
I also think that we shouldn't have exceptions, as in practice this means
we're extending commands
On 05/21/2012 09:26 AM, Paolo Bonzini wrote:
Il 21/05/2012 16:19, Anthony Liguori ha scritto:
I'm not against it in principle, just in practice. Today, checking
whether a command exists is:
commands = qmp.query_commands()
if 'block-stream' in commands:
# has block-stream
I have a
Il 21/05/2012 16:40, Anthony Liguori ha scritto:
On 05/21/2012 09:26 AM, Paolo Bonzini wrote:
Il 21/05/2012 16:19, Anthony Liguori ha scritto:
I'm not against it in principle, just in practice. Today, checking
whether a command exists is:
commands = qmp.query_commands()
if
Il 21/05/2012 15:07, Kevin Wolf ha scritto:
Am 21.05.2012 13:02, schrieb Paolo Bonzini:
Il 21/05/2012 12:32, Kevin Wolf ha scritto:
Am 21.05.2012 12:02, schrieb Paolo Bonzini:
Il 21/05/2012 11:29, Kevin Wolf ha scritto:
If source/target is really the distinction we want to have, should the
On 05/21/2012 09:47 AM, Paolo Bonzini wrote:
Il 21/05/2012 16:40, Anthony Liguori ha scritto:
On 05/21/2012 09:26 AM, Paolo Bonzini wrote:
Il 21/05/2012 16:19, Anthony Liguori ha scritto:
I'm not against it in principle, just in practice. Today, checking
whether a command exists is:
Il 21/05/2012 17:44, Anthony Liguori ha scritto:
It also gets very challenging if some options are backported and others
aren't.
It gets challenging anyway with backports. If qmp_block_stream_v1_2
knows of defaults and doesn't send them on the wire, it will work if you
only rely on the subset
Hi all,
the current block job API is designed for streaming; one property of
streaming is that in case of an error it can be restarted from the point
where it was left.
In QEMU 1.2 I would like to add an implementation of mirroring (live
block copy) based on the block job API and on dirty-block
23 matches
Mail list logo
