On 05/06/2012 05:35 PM, Anthony Liguori wrote: > On 05/06/2012 08:11 AM, Avi Kivity wrote: >> (copied qemu-devel) >> >> On 05/04/2012 10:10 PM, Corey Minyard wrote: >>> >>> Either way, is this interesting for including into KVM? >> >> Not kvm, but certainly it would make a good addition to qemu, which kvm >> then uses. >> >>> Does anyone have any >>> opinions on the possible ways to implement this? >> >> My preference would be the second alternative. The issue you raise is a >> good one. There are two ways we can approach it: >> >> - have the management system intercept IPMI requests, start up a qemu >> instance (if it's down), and let it handle the event. >> - change the whole system to keep a running qemu even when the guest is >> down. This is a much larger change; it involves reducing the memory >> footprint to almost nothing when the guest is down (deallocating memory >> and threads) so it doesn't impact guest density, but it allows for other >> minor features such as wake-on-LAN and RTC alarm wakeups. > > libvirt is essentially the BMC for a virtual guest. I would suggest > looking at implementing an IPMI interface to libvirt and exposing it > to the guest through a USB RNDIS device. > That's the first option. One unanswered question is what to do when the guest is down? Someone should listen for IPMI events, but we can't make it libvirt unconditionally, since many instances of libvirt are active at any one time. Note the IPMI external interface needs to be migrated, like any other. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
