Hi, Daniel. Thank you for your advice. On Thu, 20 Jan 2011 12:13:21 +0000 "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list