Hi Daniel,
On Fri, Jan 30, 2009 at 11:37:35AM +, Daniel P. Berrange wrote:
> @@ -670,11 +674,17 @@ qemudReadMonitorOutput(virConnectPtr con
> _("Failure while reading %s startup
> output"), what);
> return -1;
> }
> +} els
On Fri, Jan 30, 2009 at 07:00:07PM +0100, Jim Meyering wrote:
> "Daniel P. Berrange" wrote:
> > The recent refactoring of the QEMU startup process now reads the monitor
> > TTY from the logfile. Unfortunately in this refactoring we lost the check
> > for the 'ret == 0' scenario in the read() retur
"Daniel P. Berrange" wrote:
> The recent refactoring of the QEMU startup process now reads the monitor
> TTY from the logfile. Unfortunately in this refactoring we lost the check
> for the 'ret == 0' scenario in the read() return value. So if QEMU quits
> at startup, eg due to missing disk image,
On Fri, Jan 30, 2009 at 04:20:59PM +0100, Guido Günther wrote:
> On Fri, Jan 30, 2009 at 11:37:35AM +, Daniel P. Berrange wrote:
> > diff -r 826e6ed70ee0 src/qemu_driver.c
> > --- a/src/qemu_driver.c Fri Jan 30 10:58:34 2009 +
> > +++ b/src/qemu_driver.c Fri Jan 30 11:00:43 2009 +00
On Fri, Jan 30, 2009 at 11:37:35AM +, Daniel P. Berrange wrote:
> diff -r 826e6ed70ee0 src/qemu_driver.c
> --- a/src/qemu_driver.c Fri Jan 30 10:58:34 2009 +
> +++ b/src/qemu_driver.c Fri Jan 30 11:00:43 2009 +
> @@ -355,10 +355,9 @@ qemudReconnectVMs(struct qemud_driver *d
On Fri, Jan 30, 2009 at 11:37:35AM +, Daniel P. Berrange wrote:
> The recent refactoring of the QEMU startup process now reads the monitor
> TTY from the logfile. Unfortunately in this refactoring we lost the check
> for the 'ret == 0' scenario in the read() return value. So if QEMU quits
> at
The recent refactoring of the QEMU startup process now reads the monitor
TTY from the logfile. Unfortunately in this refactoring we lost the check
for the 'ret == 0' scenario in the read() return value. So if QEMU quits
at startup, eg due to missing disk image, we loop forever on read() == 0
becau
