[PATCH] use qemudReadLogOutput (was: Re: [libvirt] can't install fedora guest)

Guido Günther agx at sigxcpu.org
Sat Feb 7 17:05:51 UTC 2009


On Fri, Feb 06, 2009 at 04:48:09PM +0000, Daniel P. Berrange wrote:
> On Fri, Feb 06, 2009 at 05:27:47PM +0100, Guido G?nther wrote:
> > On Fri, Feb 06, 2009 at 10:33:51AM +0100, Farkas Levente wrote:
> > >     if ret is None:raise libvirtError('virDomainCreateLinux() failed',
> > > conn=self)
> > > libvirtError: internal error unable to start guest:
> > I'm currently working around this with:
> > 
> > diff --git a/src/qemu_driver.c b/src/qemu_driver.c
> > index 09f69bf..b2f2b47 100644
> > --- a/src/qemu_driver.c
> > +++ b/src/qemu_driver.c
> > @@ -674,8 +674,6 @@ qemudReadMonitorOutput(virConnectPtr conn,
> >                                   _("Failure while reading %s startup output"), what);
> >                  return -1;
> >              }
> > -        } else if (ret == 0) {
> > -            return 0;
> >          } else {
> >              got += ret;
> >              buf[got] = '\0';
> > 
> > Didn't find the time to debug this properly yet.
> 
> That will cause libvirtd to spin 100% cpu forever, if a guest fails
> to start up. eg disk to mis-configured disk
> 
> The core problem here, is that ret == 0 has 2 possible implications
> 
>  - QEMU has exited, and no more data will be written
>  - QEMU is still starting up, and we have read all the data
>    written so far, but more may arrive soon.
> 
> The current code there is correct for the first scenario, but even
> removing it, is not entirely correct for the 2nd scenario. If we
> hit ret == 0, and QEMU is still running, we shouldn't spin 100%
> CPU in read - we should poll() to wait for more data.
> 
> As a quick fix though, we could probably detect whether QEMU has exited
> by doing  'kill(vm->pid, 0)' and check for errno == ESRCH - indicates
> that the process no longer exists.
> 
> eg,
> 
>    } else if (ret == 0) {
>        if (kill(vm->pid, 0) == -1) {
>           if (errno == ERSCH)
>              return 0;
>           else
>              return -1;
>        } else {
>          continue; /* should really go into poll() at this point */
>        }
>    } else {
The problem is that we're using this function for two purposes: To read
from a logfile where poll()'ing on POLLIN always returns "data readable"
which leaves us spinning (and EOF might get in our way) and also using
it on the monitor PTY itself where it works as expected. Why not simply
introduce qemudReadLogOutput? This at least allows us to usleep while
waiting for the log file to fill up with data. I couldn't make libvirtd
spin with this patch anymore. O.k. to apply?
Cheers,
 -- Guido

P.S.: I also changed the timeouts to be in seconds.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-usleep-to-wait-for-domain-logfile-to-fill-up.patch
Type: text/x-diff
Size: 4038 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20090207/a8ea662d/attachment-0001.bin>


More information about the libvir-list mailing list