On Wed, Jul 15, 2009 at 11:40:42AM +0200, Daniel Veillard wrote:
On Tue, Jul 14, 2009 at 06:22:42PM -0400, Cole Robinson wrote:
> Unlike the pty monitor (which we know exists since we scrape its path from
> stdout), we have no way of knowing that the unix monitor socket should exist/
> be initialized. As a result, some of my KVM guests randomly fail to start on
> F10 host.
>
> Try to open the unix socket in a 3 second timeout loop. Ignore EACCES (path
> does not exist if a first time run) and ECONNREFUSED (leftover socket from
> a previous run hasn't been removed yet). Fixes things for me.
It's always a bit annoying to end up with heuristics like this
but if we don't have any other way, okay, ACK
I don't like it much either, but this is no worse than what we had todo
to find the /dev/pts/XXX path where we waited ina loop for 3 seconds.
ACK to this patch
Long term we'll need to discuss with QEMU developers to find a better
way todo this without needing a timeout. One idea is actually instead
of passing a UNIX domain socket path to QEMU, actually create & bind
the socket in libvirt and then pass the pre-opened FD to QEMU. This
would guarentee that we can instantly connect to the monitor. Of course
then the job of waiting passes to the code that sends monitor commands.
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|