[libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
On Wed, 2009-04-08 at 13:34 -0500, Anthony Liguori wrote: > Right now only one monitor device can be enabled at a time. In order to > support > asynchronous notification of events, I would like to introduce a 'wait' > command > that waits for an event to occur. This implies that we need an additional > monitor session to allow commands to still be executed while waiting for an > asynchronous notification. Was there any consensus reached in this thread? I'm once again looking for ways to communicate qemu watchdog events to libvirt. With these patches, libvirt could open a second monitor connection to qemu, and in the second one execute "wait_event". When the watchdog triggers, the wait command would print the event, libvirt would get the fd "data available" notification, and create a domain event. Right? -- Hollis Blanchard IBM Linux Technology Center -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
On Wed, 2009-04-08 at 16:14 -0500, Anthony Liguori wrote: > Hollis Blanchard wrote: > > On Wed, 2009-04-08 at 14:35 -0500, Anthony Liguori wrote: > > > >> You're basically saying that if something isn't connected, drop them. > >> If it is connected, do a monitor_printf() such that you're never queuing > >> events. Entirely reasonable and I've considered it. > >> > >> However, I do like the idea though of QEMU queuing events for a certain > >> period of time. Not everyone always has something connected to a > >> monitor. I may notice that my NFS server (which runs in a VM) is not > >> responding, VNC to the system, switch to the monitor, and take a look at > >> the event log. If I can get the past 10 minutes of events, I may see > >> something useful like a host IO failure. > >> > > > > "10 minutes" is the red flag for me. Why not 5 minutes? 60 minutes? 24 > > hours? The fact that it's so arbitrary suggests it doesn't really > > belong. If you care, you can attach a logging daemon that keeps the last > > 10 minutes worth of data... > > > > It has to be some finite amount. You're right, it's arbitrary, but so > is every other memory limitation we have in QEMU. You could make it > user configurable but that's just punting the problem. > > You have to do some level of buffering. It's unavoidable. If you > aren't buffering at the event level, you buffer at the socket level, etc. If the socket will buffer it, why do you *also* want to buffer in qemu (adding code and complexity)? -- Hollis Blanchard IBM Linux Technology Center -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
On Wed, 2009-04-08 at 14:35 -0500, Anthony Liguori wrote: > You're basically saying that if something isn't connected, drop them. > If it is connected, do a monitor_printf() such that you're never queuing > events. Entirely reasonable and I've considered it. > > However, I do like the idea though of QEMU queuing events for a certain > period of time. Not everyone always has something connected to a > monitor. I may notice that my NFS server (which runs in a VM) is not > responding, VNC to the system, switch to the monitor, and take a look at > the event log. If I can get the past 10 minutes of events, I may see > something useful like a host IO failure. "10 minutes" is the red flag for me. Why not 5 minutes? 60 minutes? 24 hours? The fact that it's so arbitrary suggests it doesn't really belong. If you care, you can attach a logging daemon that keeps the last 10 minutes worth of data... -- Hollis Blanchard IBM Linux Technology Center -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Re: [PATCH] Hardware watchdog patch, version 6 (was: Re: [Qemu-devel] [PATCH] Hardware watchdog patch, version 5)
Hi Rich, your watchdog qemu patch is working fine for me (i6300esb, default reset behavior), but I was wondering... how should libvirt find out about the watchdog firing? At that point, I think the next step from libvirt is to send a VIR_DOMAIN_EVENT_STOPPED_CRASHED domain event, correct? -- Hollis Blanchard IBM Linux Technology Center -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] big-endian support for libvirt - introduce GUEST_HANDLE infrastructure ?
On Wed, 2007-07-11 at 15:48 +0200, Christian Ehrhardt wrote: > > >thanks a lot ! Does this fix all the libvirt proper platform issues > > (i.e. independantly of possible xen specific ones) ? > > > Yes it fixes them as far as they are currently known to me. > As I wrote before I had already a temporary workaround in the kernel, so > the libvirt on xenppc status I posted a few mails before is valid for > the patched libvirt&kernel scenario. Christian, I don't remember seeing your kernel patch; could you repost it? If we are munging something in the kernel because userspace calls us with improper parameters, I think it goes without saying that we should fix userspace... -- Hollis Blanchard IBM Linux Technology Center -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
