On 01/20/2011 09:34 AM, 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. > > * 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. > > * 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. Hello, this is a great news. I was wondering if libvirt has anything like load balancing(or HA). I'm not sure if this is aim of yours resp. of this RF(C|D). Anyway, wouldn't it be better to count in total load, io-waits, idle etc. instead of just CPU freq? I agree with memory as being key element, still I would choose by more just than these two. I mean, machine can have "low" CPU utilization, perhaps even "a lot" of free RAM, yet high io-waits. I wouldn't want to migrate anything there.

It might be as well as gibberish/rubbish from my side, or plain misunderstanding. I beg for forgiveness! :)

Regards, Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla(a)turnovfree.net jabber: stybla(a)jabber.turnovfree.net

> * 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.

On 01/20/2011 05:13 AM, Daniel P. Berrange wrote: >> * 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. You are not the first person to request some way of getting at the host's sysinfo from a libvirt API, so the idea of exporting something makes sense (just not virSysinfoRead in its current form). Personally, I like the idea of: char *virConnectGetSysinfo(virConnectPtr) which returns just the XML <sysinfo> block for a given host. Also, including <sysinfo> in the larger XML of virCopnnectGetCapabilities() makes sense.