On Wed, May 11, 2011 at 04:15:42PM +0300, Dan Kenigsberg wrote:
> On Wed, May 11, 2011 at 12:59:07PM +0100, Daniel P. Berrange wrote:
> >
> >
> > +/*
> > + * This is invoked when there is some kind of error
> > + * parsing data to/from the monitor. The VM can continue
> > + * to run, but no further monitor commands will be
> > + * allowed
> > + */
> > +static void
> > +qemuProcessHandleMonitorError(qemuMonitorPtr mon ATTRIBUTE_UNUSED,
> > + virDomainObjPtr vm)
>
> I'm all for being graceful and polite, so this sounds good.
>
> However, events are bound to be lost. The solution would be more robust
> if there was a way to query the state of the monitor (though I'm not
> sure it is worth the hassle).
That's certainly possible.
> PS, I wonder what VMM stands for in this context. Not virtual memory
> manager, I suppose.
As Jiri says its "Virtual Machine Manager" aka the hypervisor
emulation support infrastructure for a single VM. If someone
has a better suggestion, I'm open to change it.
I could just remove 'VMM' part and say 'qemuDomainEventErrorCallback'.
Or I could kill the 'type' field and call it
'qemuDomainEventControlErrorCallback'
and if we have other types of errors in the future, introduce
further events for them
> Since I've only read the comments, not the code, I wonder if the 'quit'
> command is still passed to the monitro even after an error occured.
> Without it, we'd have to resort to SIGTERM/SIGKILL, which is less
> graceful.
QEMU treats 'SIGTERM' in the same way as 'quit' monitor command. The
key thing is to give QEMU time to process SIGTERM before resorting
to SIGKILL.
NB, we don't actually use 'quit' at all ... yet :-)
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 :|