<div class="gmail_quote">On Mon, Sep 28, 2009 at 6:43 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The flaw in QEMU is depressingly obvious<br>
<br>
   static int stdio_pclose(void *opaque)<br>
   {<br>
      QEMUFileStdio *s = opaque;<br>
      pclose(s->stdio_file);<br>
      qemu_free(s);<br>
      return 0;<br>
   }<br>
<br>
Notice how it completely discards the exit status returned by<br>
pclone() and just pretends everything always worked :-(<br>
<br>
If this was handling errors correctly, you'd at least see  QEMU<br>
exiting rather than hanging around broken.<br></blockquote><div><br></div><div>Ugh, indeed. I'll submit a patch for that later today, if nobody beats me to it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hmm, this does look problematic - we need the monitor to be responsive<br>
in order to do things like CPU pinning. We need the monitor to be<br>
non-responsive to ensure 'cont' doesn't run until migration has finished.<br>
We can't have it both ways, and the former wins since we need that to be<br>
done before ever letting QEMU start allocating guest RAM pages. So relying<br>
on 'cont' to block is not good.  Is the 'cont' even neccessary - I remember<br>
seeing somewhere that QEMU unconditionally started its CPUs after an<br>
incoming migraiton finished ?<br>
</blockquote><div><br></div><div>I've seen patches to change that behavior, so IMHO it's probably not to safe to depend on it being one way or the other throughout the versions of qemu libvirt supports.</div><div>
<br></div><div>What I'm tempted to do is add a command which sends a sigil to stderr to the end of the exec: migration lines specified by libvirt, and wait for either that sigil or an error to show up in the log for that domain before issuing the cont; if my memory is at all correct, libvirt should have some helper functions useful for that purpose already available.</div>
<div><br></div><div>Does this sound like a reasonable approach?</div></div>