9:35 a.m.
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
9:51 a.m.
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 -=|
9:52 a.m.
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
10:08 a.m.
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
4:45 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6:45 a.m.
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 -=|
8:25 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6311
days inactive
6314
days old
6 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones