[libvirt] [RFD] Add/Modify some API functions about Host Information
Minoru Usui
usui at mxm.nes.nec.co.jp
Fri Jan 21 05:19:28 UTC 2011
Hi, Daniel.
Thank you for your advice.
On Thu, 20 Jan 2011 12:13:21 +0000
"Daniel P. Berrange" <berrange at redhat.com> wrote:
> On Thu, Jan 20, 2011 at 05:34:28PM +0900, Minoru Usui wrote:
> > Hi, everyone
> >
> > In an environment with multiple host machines, I want to select a suitable
> > host automatically on which I run a VM depending on machine's load.
> >
> > Libvirt has APIs to get host machine's information,
> > but I think these APIs aren't enough for above purpose.
> > So I suggest below changes. What do you think?
> >
> > * virNodeGetInfo()
> > This API can get "CPU frequency"(mhz member of virNodeInfo) from
> > "cpu MHz" of /proc/cpuinfo.
> > This value isn't constant, because it may be decrease by
> > power saving feature.(cf. cpuspeed on RHEL)
> >
> > This value is very useful for getting *present* cpu frequency, but I
> > want to get Maximum CPU frequency, too.
> > I want to add max_mhz member in struct virNodeInfo from
> > /sys/device/system/cpu/cpuXX/cpufreq/cpuinfo_max_freq.
>
> The 'cpu MHz' field should already be reporting the max frequency
> because the current scaled frequency is pretty much irrelevant
> for making decisions against. If it isn't reporting the max freq
> for some drivers, we should fix that.
OK.
I'll try to fix this problem.
> NB, you canot simply add extra fields to the virNodeInfo
> structure because that would break ABI compatibility.
I agree.
I don't want to break ABI compatibility.
> > * virNodeGetFreeMemory()
> > This API returns amount of free memory of the host machine's all
> > node, but this value doesn't include host's cache/buffer memory.
> > For above purpose, it would be more suitable to account cache/buffer
> > as free memory, because most of cache/buffer memory are reclaimable.
> > But I think virNodeGetFreeMemory()'s ABI should not change easily.
> >
> > I want to add function virNodeGetCacheBufferMemory(). It returns
> > amount of cache + buffer memory from /proc/meminfo.
>
> If we wanted to add API for this kind of information, I think
> we'd likely want to have a more flexible API which we can
> easily extend. eg something that looks like virDomainGetMemoryParameters
> but for the virConnectPtr instead of virDomainPtr.
OK.
I'll try to implement virNodeGetMemoryParameters() like virDomainGetMemoryParameters().
> > * virSysinfoRead()
> > This API is completely internal.
> > But DMI type1 information(dmidecode -t1) is useful for above
> > purpose, because it's one of the information which suppose to
> > processing capacity about host machine.
> >
> > I want to export virSysinfoRead() to user.
>
> I wouldn't want to export the API, because that would require
> us to expose some complex structures in the public ABI. I
> think we'd just want to expose the data in the host capabilities
> XML, or have an API to query the XML of just the sysinfo on its
> own.
>
> Regards,
> Daniel
--
Minoru Usui <usui at mxm.nes.nec.co.jp>
More information about the libvir-list
mailing list