Charles Duffy wrote:
For existing QEMU, it might be sufficient to just put an arbitrary
'sleep(5)' before issuing 'cont', which would at least give it a
reasonable chance of avoiding the race condition.
Well -- I wasn't going to submit the patch I'm now using internally
(using and w
On Tue, Sep 29, 2009 at 4:16 AM, Daniel P. Berrange wrote:
> Yeah, I've been thinking much the same this morning. I think we should
> consider what the optimal setup is for our needs long term and try and
> do whatever we can for that in QEMU now. I think it'd definitely be
> worthwhile to have an
On Mon, Sep 28, 2009 at 09:03:37PM -0500, Charles Duffy wrote:
> Charles Duffy wrote:
> >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 t
Charles Duffy wrote:
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, libv
On Mon, Sep 28, 2009 at 6:43 AM, Daniel P. Berrange wrote:
> The flaw in QEMU is depressingly obvious
>
> static int stdio_pclose(void *opaque)
> {
> QEMUFileStdio *s = opaque;
> pclose(s->stdio_file);
> qemu_free(s);
> return 0;
> }
>
> Notice how it completely discards
On Fri, Sep 25, 2009 at 06:47:07PM -0500, Charles Duffy wrote:
> Howdy, all.
>
> I maintain a test infrastructure which makes heavy use of virDomainSave
> and virDomainRestore, and have been seeing occasional cases where my
> saved images are for some reason not restored correctly -- and, indeed
Howdy, all.
I maintain a test infrastructure which makes heavy use of virDomainSave
and virDomainRestore, and have been seeing occasional cases where my
saved images are for some reason not restored correctly -- and, indeed,
the incoming migration streams are not even read in their entirety.
