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
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 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
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
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 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
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
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'
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
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 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
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 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
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 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
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.
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
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
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/
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 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 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
>
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
23 matches
Mail list logo
