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

[Pavel Fux]

I agree, there is no harm in adding an option of configuration, different
setup configurations require different timeout values.
my setup was 8 servers booted with PXE boot and running on nfs rootfs, with
8 vms on each.
when I tried to start all of them together the bottle neck was the network
and it takes about 5 minutes till they all start.
I think a good solution will include changes in qemu's behavior, but the
solution that I suggested is much better than the current state.
we would be very happy not to manage our own version of libvirt.

Silence gives consent?


On Thu, Jan 16, 2014 at 5:49 PM, Martin Kletzander <mkletzan at redhat.com>wrote:

> Ping? Can we at least change the default [2/2] or should I send a v2
> for that one?
>
> Martin
>
> On Fri, Jan 10, 2014 at 04:27:40PM +0100, Martin Kletzander wrote:
> > 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
>
>
>
> > --
> > libvir-list mailing list
> > libvir-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/libvir-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140123/c6d24210/attachment-0001.htm>