[Libvir] [PATCH] Block device and network stats
This is the implementation (currently Xen, local only). It includes a couple of virsh commands if you want to play with looking at the stats. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Fri, Aug 10, 2007 at 03:35:08PM +0100, Richard W.M. Jones wrote:
This is the implementation (currently Xen, local only).
It includes a couple of virsh commands if you want to play with looking at the stats.
The network interface stuff isn't quiet correct +/* Paths have the form "virbr\d+" or "xenbr\d+". On Linux we open + * /proc/net/dev and look for the device called vif<domid>.<n>. + */ +int +xenHypervisorDomainInterfaceStats (virDomainPtr dom, + const char *path, + struct _virDomainInterfaceStats *stats) The virbrN / xenbrN devices are bridges so see all traffic from any guest attached. We need to look at ths individual vifN.N or vnetN devices which are per-guest. This info isn't included in the XML though. If we can figure out a efficient way to export vif name in the XML we could use that, otherwie the API should probably take the MAC address on the device and use that to resolve the underlying VIF. The former is nicer though if we can do it. That all said, it could be nice to also have a getStats method for the virNetworkPtr objects to get cummulative bridge data - the backend impl would be near identical. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Daniel P. Berrange wrote:
On Fri, Aug 10, 2007 at 03:35:08PM +0100, Richard W.M. Jones wrote:
This is the implementation (currently Xen, local only).
It includes a couple of virsh commands if you want to play with looking at the stats.
The network interface stuff isn't quiet correct
+/* Paths have the form "virbr\d+" or "xenbr\d+". On Linux we open + * /proc/net/dev and look for the device called vif<domid>.<n>. + */ +int +xenHypervisorDomainInterfaceStats (virDomainPtr dom, + const char *path, + struct _virDomainInterfaceStats *stats)
The virbrN / xenbrN devices are bridges so see all traffic from any guest attached. We need to look at ths individual vifN.N or vnetN devices which are per-guest. This info isn't included in the XML though. If we can figure out a efficient way to export vif name in the XML we could use that, otherwie the API should probably take the MAC address on the device and use that to resolve the underlying VIF. The former is nicer though if we can do it.
Yuk, but yes I'll take a look.
That all said, it could be nice to also have a getStats method for the virNetworkPtr objects to get cummulative bridge data - the backend impl would be near identical.
Yup. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Daniel P. Berrange wrote:
The virbrN / xenbrN devices are bridges so see all traffic from any guest attached. We need to look at ths individual vifN.N or vnetN devices which are per-guest. This info isn't included in the XML though. If we can figure out a efficient way to export vif name in the XML we could use that, otherwie the API should probably take the MAC address on the device and use that to resolve the underlying VIF. The former is nicer though if we can do it.
The best I could come up with is this little bundle of joy ... diff -u -p -r1.132 xend_internal.c --- src/xend_internal.c 9 Aug 2007 20:19:12 -0000 1.132 +++ src/xend_internal.c 10 Aug 2007 15:07:20 -0000 @@ -1354,6 +1354,7 @@ xend_parse_sexp_desc(virConnectPtr conn, int max_mem, cur_mem; unsigned char uuid[VIR_UUID_BUFLEN]; char uuidstr[VIR_UUID_STRING_BUFLEN]; + int vif_index = 0; if (root == NULL) { /* ERROR */ @@ -1626,6 +1627,9 @@ xend_parse_sexp_desc(virConnectPtr conn, if (tmp) virBufferVSprintf(&buf, " <target dev='%s'/>\n", tmp); + else + virBufferVSprintf(&buf, " <target dev='vif%d.%d'/>\n", + domid, vif_index); tmp = sexpr_node(node, "device/vif/mac"); if (tmp) virBufferVSprintf(&buf, " <mac address='%s'/>\n", @@ -1639,6 +1643,7 @@ xend_parse_sexp_desc(virConnectPtr conn, tmp2); virBufferAdd(&buf, " </interface>\n", 17); + vif_index++; } else if (sexpr_lookup(node, "device/vfb")) { /* New style graphics config for PV guests in >= 3.0.4, * or for HVM guests in >= 3.0.5 */ If that isn't acceptable then I suggest we just modify the Xen implementation of domainInterfaceStats so that it accepts a path of the form "vif<domid>.<portnum>" for now, and return to the problem of getting the real vif later. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Fri, Aug 10, 2007 at 03:35:08PM +0100, Richard W.M. Jones wrote:
This is the implementation (currently Xen, local only).
Thanks !
+++ include/libvirt/libvirt.h.in 10 Aug 2007 14:30:21 -0000 @@ -14,6 +14,9 @@ #ifndef __VIR_VIRLIB_H__ #define __VIR_VIRLIB_H__
+#include <sys/types.h> +#include <stdint.h> + [...] +struct _virDomainBlockStats { + int64_t rd_req;
That's my only worry at the moment. stdint.h isn't really that portable, we want to define an 64bits unsigned field, but we already use unsigned long long in libvirt.h . I would be tempted to rationalize this, either we think (stdint.h/int64_t) is more portable or long long is the one, but I would prefer if we picked one and stick with it at the API level. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Mon, Aug 13, 2007 at 05:45:27AM -0400, Daniel Veillard wrote:
On Fri, Aug 10, 2007 at 03:35:08PM +0100, Richard W.M. Jones wrote:
This is the implementation (currently Xen, local only).
Thanks !
+++ include/libvirt/libvirt.h.in 10 Aug 2007 14:30:21 -0000 @@ -14,6 +14,9 @@ #ifndef __VIR_VIRLIB_H__ #define __VIR_VIRLIB_H__
+#include <sys/types.h> +#include <stdint.h> + [...] +struct _virDomainBlockStats { + int64_t rd_req;
That's my only worry at the moment. stdint.h isn't really that portable, we want to define an 64bits unsigned field, but we already use unsigned long long in libvirt.h . I would be tempted to rationalize this, either we think (stdint.h/int64_t) is more portable or long long is the one, but I would prefer if we picked one and stick with it at the API level.
I don't mind one way or the other - there's not really much to choose between them - int64_t is POSIX, while long long is C99. So both are 'standards'. They've both been available on Linux & Solaris for as long as I can remember. # info gcc "5.8 Double-Word Integers ======================== ISO C99 supports data types for integers that are at least 64 bits wide, and as an extension GCC supports them in C89 mode and in C++. Simply write `long long int' for a signed integer, or `unsigned long long int' for an unsigned integer. " # info inttypes.h "If an implementation provides integer types with width 64 that meet these requirements, then the following types are required: int64_t uint64_t" Rock, paper, scissors. C99 wins! Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Mon, Aug 13, 2007 at 12:45:39PM +0100, Daniel P. Berrange wrote:
On Mon, Aug 13, 2007 at 05:45:27AM -0400, Daniel Veillard wrote:
On Fri, Aug 10, 2007 at 03:35:08PM +0100, Richard W.M. Jones wrote:
This is the implementation (currently Xen, local only).
Thanks !
+++ include/libvirt/libvirt.h.in 10 Aug 2007 14:30:21 -0000 @@ -14,6 +14,9 @@ #ifndef __VIR_VIRLIB_H__ #define __VIR_VIRLIB_H__
+#include <sys/types.h> +#include <stdint.h> + [...] +struct _virDomainBlockStats { + int64_t rd_req;
That's my only worry at the moment. stdint.h isn't really that portable, we want to define an 64bits unsigned field, but we already use unsigned long long in libvirt.h . I would be tempted to rationalize this, either we think (stdint.h/int64_t) is more portable or long long is the one, but I would prefer if we picked one and stick with it at the API level.
I don't mind one way or the other - there's not really much to choose between them - int64_t is POSIX, while long long is C99. So both are 'standards'. They've both been available on Linux & Solaris for as long as I can remember.
# info gcc "5.8 Double-Word Integers ========================
ISO C99 supports data types for integers that are at least 64 bits wide, and as an extension GCC supports them in C89 mode and in C++. Simply write `long long int' for a signed integer, or `unsigned long long int' for an unsigned integer. "
# info inttypes.h "If an implementation provides integer types with width 64 that meet these requirements, then the following types are required: int64_t uint64_t"
Rock, paper, scissors. C99 wins!
The only difference is that in some future (hopefully we will be retired by then ;-) long long may actually end up being say 128bits on some hardware. Honnestly I don't care, since we are already using unsigned long long in the header then let's stick to it and use it for the statistics too. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones