[libvirt] [PATCH] Use virDomainGetState in migration APIs

[Jiri Denemark]

On Thu, May 19, 2011 at 14:52:29 +0100, Daniel P. Berrange wrote:
> On Thu, May 19, 2011 at 03:36:30PM +0200, Jiri Denemark wrote:
> > We are only interested in domain state so no need to call
> > virDomainGetInfo for that.
> > ---
> >  src/libvirt.c |   18 +++++++++---------
> >  1 files changed, 9 insertions(+), 9 deletions(-)
> > 
> > diff --git a/src/libvirt.c b/src/libvirt.c
> > index ff16c48..3d1b314 100644
> > --- a/src/libvirt.c
> > +++ b/src/libvirt.c
> > @@ -3513,10 +3513,10 @@ virDomainMigrateVersion1 (virDomainPtr domain,
> >      char *uri_out = NULL;
> >      char *cookie = NULL;
> >      int cookielen = 0, ret;
> > -    virDomainInfo info;
> > +    int state;
> >  
> > -    ret = virDomainGetInfo (domain, &info);
> > -    if (ret == 0 && info.state == VIR_DOMAIN_PAUSED) {
> > +    ret = virDomainGetState(domain, &state, NULL, 0);
> > +    if (ret == 0 && state == VIR_DOMAIN_PAUSED) {
> >          flags |= VIR_MIGRATE_PAUSED;
> >      }
> >  
> 
> NACK to this, since it breaks migration compatibility. Much of the
> 'virDomainMigrate' code runs in the client app, and the source
> libvirtd it is talking to can't be expected to have virDomainGetState
> support. Only the v3 migration could be safely allowed to do this,
> and I don't think it is worth it. The reason for using GetState
> instead of GetInfo is to avoid calling the monitor, in case QEMU
> is deadlocked/blocked, but this isn't useful because the very
> next step in migration is going to use the monitor anyway.

Oops, right, I was brain dead and completely forgot about the fact these APIs
are on client side.

Jirka