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 t
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
>
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 foll
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 rerr
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/
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 rejecte
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.
On Fri, 18 May 2012 19:08:42 +0200
Paolo Bonzini 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 we've already settl
Am 21.05.2012 15:59, schrieb Luiz Capitulino:
> On Fri, 18 May 2012 19:08:42 +0200
> Paolo Bonzini 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 th
On 05/21/2012 08:59 AM, Luiz Capitulino wrote:
On Fri, 18 May 2012 19:08:42 +0200
Paolo Bonzini 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
On Mon, 21 May 2012 09:10:40 -0500
Anthony Liguori wrote:
> On 05/21/2012 08:59 AM, Luiz Capitulino wrote:
> > On Fri, 18 May 2012 19:08:42 +0200
> > Paolo Bonzini wrote:
> >
> >> Modified QMP commands
> >> =
> >
> > As we have discussed on the ML, we're not going to extend Q
On Mon, 21 May 2012 16:09:28 +0200
Kevin Wolf wrote:
> Am 21.05.2012 15:59, schrieb Luiz Capitulino:
> > On Fri, 18 May 2012 19:08:42 +0200
> > Paolo Bonzini wrote:
> >
> >> Modified QMP commands
> >> =
> >
> > As we have discussed on the ML, we're not going to extend QMP c
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 Bonzini 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 Bonzini wrote:
Modified QMP commands
=
As we have discussed on the ML, we're not going to extend QMP commands.
I understand your reasoning, a
On 05/21/2012 09:16 AM, Luiz Capitulino wrote:
On Mon, 21 May 2012 09:10:40 -0500
Anthony Liguori wrote:
On 05/21/2012 08:59 AM, Luiz Capitulino wrote:
On Fri, 18 May 2012 19:08:42 +0200
Paolo Bonzini wrote:
Modified QMP commands
=
As we have discussed on the ML, we'
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 schem
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 command
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 har
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
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, s
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:
comma
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
23 matches
Mail list logo