[Libvir] VCPU mapping into the XML
Daniel P. Berrange
berrange at redhat.com
Tue Feb 27 19:18:15 UTC 2007
On Tue, Feb 27, 2007 at 02:07:14PM -0500, Hugh Brock wrote:
> Daniel P. Berrange wrote:
> >
> >Libvirt is really just the lowest level is what I see as a stack of tools
> >for managing virtual machines. Above libvirt I'd expect to see some form
> >of 'policy manager' which defines/controls things such as VCPU mapping,
> >or schedular parameters, and even managing when a VM runs at all. One
> >simple policy manager might just apply a statically defined VCPU mapping
> >when a new guest starts up. A more advanced policy manager would collect
> >resource utilization data, perform some analysis on this data, and thus
> >apply changes to the VCPU mapping periodically over lifetime of a guest.
> >Such VM policy management tools can already just use the existing APIs
> >for setting VCPU mapping.
> >
> I'd be very excited if we could get to a first cut of a simple policy
> manager in the fedora 8 timeframe. At a minimum, I would think such a
> thing would need to be able to do the following:
>
> 1. Store policy information about a guest. At a minimum we would want to
> store cpu pin/weight/cap information; beyond that, dependency
> information (don't start me until some other VM is up and running).
>
> 2. Retrieve policy information on request. So for example we might want
> to tell libvirt to ask the manager for policy information before
> starting a guest, or before shutting one down.
>
> Just these features would be great for a first cut. Then going forward,
> we could start thinking about receiving monitoring information and
> responding to events. The tricky thing, it seems to me, is going to be
> designing the thing in such a way that it won't take forever to
> implement the simple part now, but can still be extended to do more later.
A couple of things
- This doesn't need to be at all related to libvirt release dates,
so if people want to experiment with policy management daemons
it can be done today....
- Expect to throw away the first few versions - policy management
is seriously non-trivial and I doubt anyone will get it right
first time. Better to prototype ideas quickly than to over design
it from the start.
- I expect it'll turn out that there a few different ways to approach
policy, and the idea of a single policy manager may well be impossible.
- There is no good way to collect, distribute & process resource
utilization data at this time - traditional monitoring systems
have all sorts of plugins for collecting data, but once collected
they are typically a black box - no formal API for external apps to
get at the data collected for analysis.
> Further thoughts, anyone?
I'd encourage anyone interested in it, to experiment / prototype any
ideas as a project in their own right. The core libvirt APIs needed for
such a system are all there....
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
More information about the libvir-list
mailing list