On Mon, Apr 04, 2011 at 14:24:37 -0400, Dave Allan wrote:
> On Mon, Apr 04, 2011 at 03:37:32PM +0200, Jiri Denemark wrote:
> > On Mon, Apr 04, 2011 at 14:23:59 +0100, Daniel P. Berrange wrote:
> > > On Mon, Apr 04, 2011 at 03:18:59PM +0200, Jiri Denemark wrote:
> > > > Failure to extract version info (e.g., because qemu binary is so ancient
> > > > that it doesn't even support -help) shouldn't be considered fatal since
> > > > we only need it to detect whether qemu supports bootindex option.
> > > > ---
> > > > src/qemu/qemu_capabilities.c | 7 ++++---
> > > > 1 files changed, 4 insertions(+), 3 deletions(-)
> > >
> > > What version QEMU doesn't support -help ?
> > >
> > > We only aim to work with QEMU >= 0.9.0 and I'm fairly sure
> > > that has -help support.
> >
> > An ancient one, 0.6.0. But that was just an example. Extracting version info
> > may fail for a bunch of reasons. The main thing is that it shouldn't fail qemu
> > driver startup since that results in libvirtd startup failure.
>
> Why does driver startup failure result in libvirtd startup failure?
> Shouldn't it only result in the lack of availability of the driver?
IIUC, driver startup is supposed to fail only on serious errors, such as
ENOMEM. But it doesn't really matter anymore since I realized there's a better
fix for this issue. Instead of not adding deviceboot flag to guest
capabilities, we should rather ignore qemu binary for which we are not able to
extract version info and don't put it into guest capabilities at all. I've
sent a patch for that, which obsoletes this patch.
Jirka