Re: VCPU mapping into the XML

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

 



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  -=| 


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]