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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list