On Mon, 27 Feb 2012 10:42:31 -0600
Anthony Liguori wrote:
> On 02/27/2012 10:33 AM, Federico Simoncelli wrote:
> > I'm all for the modularity of the commands (I suggested it since the
> > beginning),
> > but all this infrastructure goes way beyond what I'd need for oVirt now.
> >
> > When I subm
On 02/27/2012 05:58 PM, Anthony Liguori wrote:
>>
>> Jeff could rework his patches to work with transaction begin/commit
>> commands, and Federico can then add drive-reopen and drive-migrate on
>> top.
>
> Yes, maybe I lack imagination but I fail to see how it generalizes
> easily/nicely.
> From
On 02/27/2012 10:54 AM, Paolo Bonzini wrote:
On 02/27/2012 05:53 PM, Anthony Liguori wrote:
It looks like this is exactly
the case where the core infrastructure (transactions) is missing.
Batch requests are incredibly easy to add. I'm stuck in meetings for
the next couple days but I'm sure Lu
On 02/27/2012 10:51 AM, Paolo Bonzini wrote:
On 02/27/2012 04:24 PM, Anthony Liguori wrote:
Then you get an error with the block devices still frozen. You can
execute another command to reopen back to the old image to roll back the
transaction.
Pushing the rollback logic to the client does ma
On 02/27/2012 05:53 PM, Anthony Liguori wrote:
>> It looks like this is exactly
>> the case where the core infrastructure (transactions) is missing.
>
> Batch requests are incredibly easy to add. I'm stuck in meetings for
> the next couple days but I'm sure Luiz throw it together in no time at al
On 02/27/2012 10:33 AM, Federico Simoncelli wrote:
I'm all for the modularity of the commands (I suggested it since
the beginning),
but all this infrastructure goes way beyond what I'd need for oVirt
now.
When I submitted my patches we knew that my work wasn't the
definitive solution
(eg: the fu
On 02/27/2012 04:24 PM, Anthony Liguori wrote:
>
> Then you get an error with the block devices still frozen. You can
> execute another command to reopen back to the old image to roll back the
> transaction.
>
> Pushing the rollback logic to the client does make the client interface
> a bit more
;
> Sent: Monday, February 27, 2012 5:42:31 PM
> Subject: Re: [Qemu-devel] drive transactions (was Re: [PATCH 2/2 v2] Add the
> blockdev-reopen and blockdev-migrate
> commands)
>
> On 02/27/2012 10:33 AM, Federico Simoncelli wrote:
> > I'm all for the modularity o
On 02/27/2012 10:33 AM, Federico Simoncelli wrote:
I'm all for the modularity of the commands (I suggested it since the beginning),
but all this infrastructure goes way beyond what I'd need for oVirt now.
When I submitted my patches we knew that my work wasn't the definitive solution
(eg: the fu
On 02/27/2012 05:33 PM, Federico Simoncelli wrote:
>> >
>> > blockdev-begin-transaction
>> > drive-reopen device new-image-file
>> > drive-mirror streaming=false device dest
>> > blockdev-commit-transaction
>> >
>> > No strange optional arguments, no proliferation of commands, etc
- Original Message -
> From: "Paolo Bonzini"
> To: "Luiz Capitulino"
> Cc: "Federico Simoncelli" , kw...@redhat.com,
> mtosa...@redhat.com, qemu-devel@nongnu.org,
> arm...@redhat.com, "Jeff Cody"
> Sent: Monday, February 27, 2012 3:39:33 PM
> Subject: drive transactions (was Re: [PATCH
On 02/27/2012 09:17 AM, Kevin Wolf wrote:
Am 27.02.2012 15:59, schrieb Anthony Liguori:
On 02/27/2012 08:54 AM, Paolo Bonzini wrote:
On 02/27/2012 03:46 PM, Anthony Liguori wrote:
I think a better way to think of this is as a batch submission. It
would be relatively easy to model in QMP too (
Am 27.02.2012 15:59, schrieb Anthony Liguori:
> On 02/27/2012 08:54 AM, Paolo Bonzini wrote:
>> On 02/27/2012 03:46 PM, Anthony Liguori wrote:
>>> I think a better way to think of this is as a batch submission. It
>>> would be relatively easy to model in QMP too (just have a batch-command
>>> that
On 02/27/2012 09:03 AM, Paolo Bonzini wrote:
On 02/27/2012 03:59 PM, Anthony Liguori wrote:
The problem is that the current commands are not designed well. For
instance, multi-snapshot could look like:
block-freeze ide0-hd0
block-freeze ide1-hd1
block-reopen ide0-hd0 my-new-file0.qcow2
block-r
On 02/27/2012 03:59 PM, Anthony Liguori wrote:
> The problem is that the current commands are not designed well. For
> instance, multi-snapshot could look like:
>
> block-freeze ide0-hd0
> block-freeze ide1-hd1
> block-reopen ide0-hd0 my-new-file0.qcow2
> block-reopen ide1-hd1 my-new-file1.qcow2
On 02/27/2012 08:54 AM, Paolo Bonzini wrote:
On 02/27/2012 03:46 PM, Anthony Liguori wrote:
I think a better way to think of this is as a batch submission. It
would be relatively easy to model in QMP too (just have a batch-command
that has a list of commands as it's argument).
The difference b
On 02/27/2012 03:46 PM, Anthony Liguori wrote:
> I think a better way to think of this is as a batch submission. It
> would be relatively easy to model in QMP too (just have a batch-command
> that has a list of commands as it's argument).
>
> The difference between batch submission and a transact
On 02/27/2012 08:39 AM, Paolo Bonzini wrote:
On 02/27/2012 02:06 PM, Luiz Capitulino wrote:
IMHO, this is asking for two commands, where cases 1& 2 is one of them
and cases 3& 4 is the other one. Note how 'incremental' goes away and
'new_image_file' really becomes an optional.
I really would
On 02/27/2012 02:06 PM, Luiz Capitulino wrote:
> IMHO, this is asking for two commands, where cases 1 & 2 is one of them
> and cases 3 & 4 is the other one. Note how 'incremental' goes away and
> 'new_image_file' really becomes an optional.
I really would have no idea on naming except perhaps "dri
19 matches
Mail list logo
