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

[Martin Kletzander]

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 at 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 at stratoscale.com>
> > Signed-off-by: Martin Kletzander <mkletzan at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140110/955591e7/attachment-0001.sig>