qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 06/11] QMP: Introduce asynchronous events infras


From: Daniel P. Berrange
Subject: [Qemu-devel] Re: [PATCH 06/11] QMP: Introduce asynchronous events infrastructure
Date: Tue, 23 Jun 2009 17:47:56 +0100
User-agent: Mutt/1.4.1i

On Tue, Jun 23, 2009 at 03:51:29PM +0200, Jan Kiszka wrote:
> Eduardo Habkost wrote:
> > On Tue, Jun 23, 2009 at 10:36:16AM -0300, Luiz Capitulino wrote:
> >> On Tue, 23 Jun 2009 11:32:51 +0100
> >> "Daniel P. Berrange" <address@hidden> wrote:
> >>
> >>>> +
> >>> If a client is not reading from the monitor channel quickly enough, then
> >>> would this cause QEMU to block once the FD buffer is full ? A QEMU level
> >>> buffer might give more leyway, but we don't want to grow unbounded, so
> >>> ultimately we'll end up having to drop events. At which point you'd want
> >>> to send an event to the client indicating that the event queue overflowed,
> >>> so it can take remedial action to re-sync its state.
> >>  Wouldn't a buffer flush right at the beginning of this function solve 
> >> this?
> >> At least for QEMU?
> > 
> > No, if the messages aren't being consumed fast enough by the other side.
> > If the consumer isn't consuming the messages fast enough, we would need
> > to either drop messages or block on the channel (that's the code code
> > above would do: block on write()).
> > 
> > I agree with Avi: if the system is so busy that the client doesn't
> > consume the monitor messages fast enough, we are already screwed.
> 
> Can't mgmt app and qemu also run on different hosts?

If you happened to run the monitor using a TCP backend, then yes the
mgmt app could be remote. This would be just  insane though, since
there's no security there whatsoever. I don't think the QEMU monitor
wants to be in the business of encrypting, authenticating & authorizing
monitor clients. Rather it should just be local only, and any mgmt tool
using QEMU can provide secure remote mgmt transports at a higher level.

Regards,
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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]