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@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 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
On Fri, Jan 10, 2014 at 04:27:40PM +0100, Martin Kletzander wrote: 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
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list