[libvirt] [RFD] Add/Modify some API functions about Host Information
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. -- Minoru Usui <usui@mxm.nes.nec.co.jp>
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@turnovfree.net jabber: stybla@jabber.turnovfree.net
Hi, Zdenek Thank you for your comment. On Thu, 20 Jan 2011 12:48:46 +0100 Zdenek Styblik <stybla@turnovfree.net> wrote:
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.
You are right. It's better to CPU utilization than CPU freq. I'll add new API which named virNodeGetCpuTime() about it. It returns cpu time of host machine from /proc/stat. How about this?
It might be as well as gibberish/rubbish from my side, or plain misunderstanding. I beg for forgiveness! :)
It is not necessary to mind it.
Regards, Zdenek
-- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla@turnovfree.net jabber: stybla@jabber.turnovfree.net
-- Minoru Usui <usui@mxm.nes.nec.co.jp>
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. NB, you canot simply add extra fields to the virNodeInfo structure because that would 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.
* 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
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. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Hi, Eric On Thu, 20 Jan 2011 08:20:20 -0700 Eric Blake <eblake@redhat.com> wrote:
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.
I think it's better than exporting virSysinfoRead(). I'll try to implement virConnectGetSysinfo(). But I have one question. Why do you think <sysinfo> block should include XML of virConnectGetCapabilities()? I think, virConnectGetSysinfo() returns just a hardware information about host machine. On the other hand, virConnectGetCapabilities() returns what support the host machine. These are little bit different, so I don't think virConnectGetSysinfo() needs virConnectGetCapabilities()'s information. Do I misunderstand? -- Minoru Usui <usui@mxm.nes.nec.co.jp>
On Thu, Jan 20, 2011 at 08:20:20AM -0700, Eric Blake wrote:
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.
If we've going to have a separate API, then I'd avoid also adding it to the capabilities XML. We have a max RPC message size of 256 KB, and the capabilities XML is growing all the time. So I think we could usefully avoid adding the sysinfo there to, if having a separate API. Daniel
Hi, Daniel. Thank you for your advice. On Thu, 20 Jan 2011 12:13:21 +0000 "Daniel P. Berrange" <berrange@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@mxm.nes.nec.co.jp>
participants (4)
-
Daniel P. Berrange -
Eric Blake -
Minoru Usui -
Zdenek Styblik