[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 1/2] qemu: Add support for changing timeout value to open unix monitor socket



On Fri, Jan 10, 2014 at 02:18:37PM +0000, Daniel P. Berrange wrote:
> On Thu, Jan 09, 2014 at 09:22:05AM +0100, Martin Kletzander wrote:
> > From: Pavel Fux <pavel stratoscale com>
> > 
> > Adding an option to change monitor socket opening timeout
> > the current default is 3 seconds and in some cases it's not enough
> > 
> > Signed-off-by: Pavel Fux <pavel stratoscale com>
> > Signed-off-by: Martin Kletzander <mkletzan redhat com>
> > ---
> > 
> > Notes:
> >     I modified the description in the config file, made the use of the
> >     opaque argument in qemuMonitorOpen and rebased it on current master.
> >     
> >     I also added the config options in augeas test to make the 'make
> >     check' pass.
> 
> IMHO we shouldn't add this config parameter. This kind of parameter is
> basically saying "our code doesn't work by default, set this to fix it"
> which is just horrible behaviour. Further more an admin won't even find
> out about this until the worst possible time. Just increase the default
> timeout if we need to. Even better would be to figure out how we can
> properly fix this to avoid any need for timeout at all.
> 

The same can be said about e.g. audio-related options in the config
file or (when going to extremes) debug logs.  Yes, there might be
problems and this is a way how admins/users can check where a
particular problem might be.  And the very fact that we need to change
this variable now does in fact proves that this might need another
change in the future.  Having this particular value configurable is
merely a _option_ for admins/users and I see no drawback at all in it.

As Rich suggested (and Cole copied), check out the number of hits for:
https://www.google.co.uk/search?q="monitor+socket+did+not+show+up";

Many of them are related to the domains having managed-save, but since
nobody looked for a root cause of it (as I know of), this might be
related to this very problem.

Does this mean ACK to [2/2] and NACK to [1/2] then?

Martin

P.S.: I also forgot to mention that this might most probably resolve
these bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=892273
https://bugzilla.redhat.com/show_bug.cgi?id=895901
https://bugzilla.redhat.com/show_bug.cgi?id=987088
https://bugzilla.redhat.com/show_bug.cgi?id=1051364

> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
> 
> --
> libvir-list mailing list
> libvir-list redhat com
> https://www.redhat.com/mailman/listinfo/libvir-list

Attachment: signature.asc
Description: Digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]