On Wed, Oct 07, 2009 at 04:54:27PM +0200, Paolo Bonzini wrote:
>
> > Excellent, sounds fine then, but we need the rebased version once
> >Dan patches are applied.
>
> Of course. But it sounds like Dan Berrange doesn't fancy 5/6 very much
> because he wants the "old virsh, new daemon" case to
Excellent, sounds fine then, but we need the rebased version once
Dan patches are applied.
Of course. But it sounds like Dan Berrange doesn't fancy 5/6 very much
because he wants the "old virsh, new daemon" case to work too. He also
didn't like the hack I posted (which I understand even
On Wed, Oct 07, 2009 at 03:09:17PM +0200, Paolo Bonzini wrote:
>
>>Sounds fine by me, but I wonder about the change of semantic for
>>client server not at the same version level. Could you explain what
>> might happen in those case ?
>
> Here is the result of my testing (source libvirtd is
On 10/07/2009 03:59 PM, Daniel P. Berrange wrote:
This hack means that it would be ignoring*all* deserialization errors,
which IMHO is just as bad.
These deserialization errors however do not include networking errors,
because libvirt calls xdr routines only after it has extracted the xdr
da
On Wed, Oct 07, 2009 at 03:52:10PM +0200, Paolo Bonzini wrote:
>
> >In the case of old server and new client, the client should get a RPC
> >error when trying to re-serialize the reply, because the data packet
> >it will be getting back from the server will be too small (ie missing
> >the new fiel
In the case of old server and new client, the client should get a RPC
error when trying to re-serialize the reply, because the data packet
it will be getting back from the server will be too small (ie missing
the new field this patch adds).
The RPC protocol should be considered ABI, and no exis
On Wed, Oct 07, 2009 at 03:09:17PM +0200, Paolo Bonzini wrote:
>
> > Sounds fine by me, but I wonder about the change of semantic for
> > client server not at the same version level. Could you explain what
> >might happen in those case ?
>
> Here is the result of my testing (source libvirtd i
On Wed, Oct 07, 2009 at 03:01:14PM +0200, Daniel Veillard wrote:
> On Thu, Oct 01, 2009 at 08:18:32PM +0200, Paolo Bonzini wrote:
> > A return code of say 1 from Perform is currently considered an error,
> > but it could also be passed simply to Finish. This makes the v2
> > protocol much more pow
Sounds fine by me, but I wonder about the change of semantic for
client server not at the same version level. Could you explain what
might happen in those case ?
Here is the result of my testing (source libvirtd is always new):
source virsh source method destination libvirtd
On Thu, Oct 01, 2009 at 08:18:32PM +0200, Paolo Bonzini wrote:
> A return code of say 1 from Perform is currently considered an error,
> but it could also be passed simply to Finish. This makes the v2
> protocol much more powerful.
>
> * src/remote/remote_protocol.x (remote_domain_migrate_perform
A return code of say 1 from Perform is currently considered an error,
but it could also be passed simply to Finish. This makes the v2
protocol much more powerful.
* src/remote/remote_protocol.x (remote_domain_migrate_perform_ret): New.
* src/qemu/qemu_driver.c (qemudDomainMigrateFinish2): Succeed
11 matches
Mail list logo
