Hello, I want to add the info of VCPU mapping into the XML, because we cannot manage VCPU mapping automatically when a domain starts or reboots. But in the following patch, the function written in "TODO" which I wanted has not been accepted. https://www.redhat.com/archives/libvir-list/2006-August/msg00015.html If I provided the patch managing VCPU mapping in the XML, do you accept it?

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.

Further thoughts, anyone?

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. The features I would want to implement now is essentially included in the above mentioned contents. More correctly, I would particularly want to implement the following 3 features. - New domain started by libvirt is set the policy information (cpu pin/weight/cap) by policy manager. - A domain rebooted by libvirt keeps configuration of policy information. - Some domains can use specified pCPUs by occupancy and the other domains are configured not able to use the pCPUs by policy manager. Are these proposed futures enough for your first step? If you agreed, I will start design & implementation. Regards, Yuzuru Asano.