10:31 a.m.
This patch adds block device and network stats. The main changes over
the previous version are:
* Remote support.
* Change Xen network interface names to have the form
"vif<domid>.<n>"[1].
Discussions about the previous version may be found starting here:
https://www.redhat.com/archives/libvir-list/2007-August/thread.html#00064
I have left use of stdint.h / int64_t, since it wasn't clear to me what
conclusion people had arrived at.
I left the explicit structure size parameter to allow for future
extensibility.
Also attached is the output of:
virsh -c xen+tls://amd/ domifstat fc6_1 vif2.0
Rich.
[1] There is currently no way to get the interface name except to just
know it -- that is the subject of a separate patch.
--
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
libvirt: virConnectOpen (name=xen+tls://amd/)
libvirt: virInitialize ()
libvirt: virInitialize ()
libvirt: virInitialize ()
libvirt: virInitialize ()
libvirt: virInitialize ()
libvirt: virInitialize ()
libvirt: virInitialize ()
libvirt: virInitialize ()
libvirt: virInitialize ()
libvirt: do_open: proceeding with name=xen+tls://amd/
libvirt: do_open: trying driver 0 (Test) ...
libvirt: do_open: driver 0 Test returned DECLINED
libvirt: do_open: trying driver 1 (QEMU) ...
libvirt: do_open: driver 1 QEMU returned DECLINED
libvirt: do_open: trying driver 2 (Xen) ...
libvirt: do_open: driver 2 Xen returned DECLINED
libvirt: do_open: trying driver 3 (remote) ...
libvirt: do_open: driver 3 remote returned SUCCESS
libvirt: do_open: network driver 0 Test returned DECLINED
libvirt: do_open: network driver 1 QEMU returned DECLINED
libvirt: do_open: network driver 2 remote returned SUCCESS
libvirt: virDomainLookupByName (conn=0x130ee020, name=fc6_1)
libvirt: virDomainInterfaceStats (domain=0x13129bd0, path=vif2.0, stats=0x7fff688e6e20,
size=64)
libvirt: virDomainFree (domain=0x13129bd0)
libvirt: virConnectClose (conn=0x130ee020)
vif2.0 rx_bytes 18591
vif2.0 rx_packets 113
vif2.0 rx_errs 0
vif2.0 rx_drop 0
vif2.0 tx_bytes 125319
vif2.0 tx_packets 962
vif2.0 tx_errs 0
vif2.0 tx_drop 0
9:37 p.m.
On Mon, Aug 20, 2007 at 04:31:26PM +0100, Richard W.M. Jones wrote:
This patch adds block device and network stats. The main changes
over
the previous version are:
* Remote support.
* Change Xen network interface names to have the form
"vif<domid>.<n>"[1].
Discussions about the previous version may be found starting here:
https://www.redhat.com/archives/libvir-list/2007-August/thread.html#00064
I have left use of stdint.h / int64_t, since it wasn't clear to me what
conclusion people had arrived at.
Personally I'm for using long long, since its consistent with the other
existing APIs using 64 bit quantities. They're both standards so there's
no much of a reason to favour one over the other.
I notice the Xen impl of the block stats only fills in the rd_req and wr_req
fields, not the rd_bytes and wr_bytes fields. Are requests always fixed at
512 bytes in size ? If so, should be just junk those fields and only return
data in terms of the bytes (other units can be calculated as needed). As a
point of reference libstatgrab only returns bytes read/written for disks.
The Xen impl as coded only works for disks named xvdN, because the code for
calculating device ID assumes xvdN device numbering scheme:
device = 202 * 256 + minor;
I know this is all utterly horrific, but we need to apply same logic as
used in XenD for sdNNN and hdNNN :-( For sdNNN based disks it seems to be
8 * 256 + 16 * (ord value of disk letter ) + partition number
For hdNNN based disks it seems to be
ide major number corresponding to disk letter * 256 + minor number
as calculated from partition numbers.
:-(
The interface stats look OK to me. The impl which parses /proc/net/dev
though could be shared with the QEMU driver - only the device name needs
to be different between them - QEMU will be vnetXXX - we have the actual
dev name when we create teh TAP device, but don't bother to save it anywhere
from the looks of things.
I left the explicit structure size parameter to allow for future
extensibility.
Good plan.
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 -=|
2:45 a.m.
On Tue, Aug 21, 2007 at 03:37:41AM +0100, Daniel P. Berrange wrote:
On Mon, Aug 20, 2007 at 04:31:26PM +0100, Richard W.M. Jones wrote:
> This patch adds block device and network stats. The main changes over
> the previous version are:
>
> * Remote support.
> * Change Xen network interface names to have the form
"vif<domid>.<n>"[1].
>
> Discussions about the previous version may be found starting here:
> https://www.redhat.com/archives/libvir-list/2007-August/thread.html#00064
>
> I have left use of stdint.h / int64_t, since it wasn't clear to me what
> conclusion people had arrived at.
Personally I'm for using long long, since its consistent with the other
existing APIs using 64 bit quantities. They're both standards so there's
no much of a reason to favour one over the other.
Actually I have one: we already depend on 'long long' for the libvirt
API while we don't depend yet on stdint.h / int64_t. So I really favour
using unsigned long long there.
I notice the Xen impl of the block stats only fills in the rd_req and
wr_req
fields, not the rd_bytes and wr_bytes fields. Are requests always fixed at
512 bytes in size ? If so, should be just junk those fields and only return
data in terms of the bytes (other units can be calculated as needed). As a
point of reference libstatgrab only returns bytes read/written for disks.
I really prefer to keep the rd_req and wr_req. Maybe Xen isn't smart enough
yet to provide those but other hypervisors may be smarter, and even Xen can
evolve fairly quickly. I would keep the fields and try to initialize as best
as possible depending on the hypervisor.
[...]
The interface stats look OK to me. The impl which parses
/proc/net/dev
though could be shared with the QEMU driver - only the device name needs
to be different between them - QEMU will be vnetXXX - we have the actual
dev name when we create teh TAP device, but don't bother to save it anywhere
from the looks of things.
We should probably start to create OS specific modules, I can see how
doing the same on Solaris would be different, this may help protability
a little bit, but it's not urgent IMHO.
+1 for me, once the interfaces are changed to unsigned long long,
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/
3:02 a.m.
Daniel P. Berrange wrote:
On Mon, Aug 20, 2007 at 04:31:26PM +0100, Richard W.M. Jones wrote:
> This patch adds block device and network stats. The main changes over
> the previous version are:
>
> * Remote support.
> * Change Xen network interface names to have the form
"vif<domid>.<n>"[1].
>
> Discussions about the previous version may be found starting here:
> https://www.redhat.com/archives/libvir-list/2007-August/thread.html#00064
>
> I have left use of stdint.h / int64_t, since it wasn't clear to me what
> conclusion people had arrived at.
Personally I'm for using long long, since its consistent with the other
existing APIs using 64 bit quantities. They're both standards so there's
no much of a reason to favour one over the other.
I favour int64_t, because I want 64 bit integers (signed in this case
because I want the special -1 value). C doesn't specify a maximum width
for "long long".
I notice the Xen impl of the block stats only fills in the rd_req and
wr_req
fields, not the rd_bytes and wr_bytes fields. Are requests always fixed at
512 bytes in size ? If so, should be just junk those fields and only return
data in terms of the bytes (other units can be calculated as needed). As a
point of reference libstatgrab only returns bytes read/written for disks.
I assumed that Xen requests were variable in size ... That is based on
my reading of this code from blkif.h:
#define BLKIF_MAX_SEGMENTS_PER_REQUEST 11
struct blkif_request_segment {
grant_ref_t gref; /* reference to I/O buffer frame */
/* @first_sect: first sector in frame to transfer (inclusive). */
/* @last_sect: last sector in frame to transfer (inclusive). */
uint8_t first_sect, last_sect;
};
struct blkif_request {
uint8_t operation; /* BLKIF_OP_??? */
uint8_t nr_segments; /* number of segments */
blkif_vdev_t handle; /* only for read/write requests */
uint64_t id; /* private guest value, echoed in resp */
blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */
struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
};
typedef struct blkif_request blkif_request_t;
But to be honest I don't know (the source to Xen I have here still uses
the sparse tree, making it impossible to find the actual source for the
Linux drivers ...).
If it is true that requests have a fixed size, then returning bytes
_also_ would be good, but I suspect that we should also still return
requests as well since (a) it costs virtually nothing to do so, and (b)
it might be interesting to find the average size of each request, since
lots of small requests are likely to be less efficient than small
numbers of large requests.
The Xen impl as coded only works for disks named xvdN, because the
code for
calculating device ID assumes xvdN device numbering scheme:
device = 202 * 256 + minor;
I know this is all utterly horrific, but we need to apply same logic as
used in XenD for sdNNN and hdNNN :-( For sdNNN based disks it seems to be
8 * 256 + 16 * (ord value of disk letter ) + partition number
For hdNNN based disks it seems to be
ide major number corresponding to disk letter * 256 + minor number
as calculated from partition numbers.
OK ... I've never seen Xen guests with sdX/hdX devices. Are they common?
The interface stats look OK to me. The impl which parses
/proc/net/dev
though could be shared with the QEMU driver - only the device name needs
to be different between them - QEMU will be vnetXXX - we have the actual
dev name when we create teh TAP device, but don't bother to save it anywhere
from the looks of things.
> I left the explicit structure size parameter to allow for future
> extensibility.
Good plan.
Regards,
Dan.
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
8:45 a.m.
On Tue, Aug 21, 2007 at 09:02:45AM +0100, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
>On Mon, Aug 20, 2007 at 04:31:26PM +0100, Richard W.M. Jones wrote:
>>This patch adds block device and network stats. The main changes over
>>the previous version are:
>>
>>* Remote support.
>>* Change Xen network interface names to have the form
"vif<domid>.<n>"[1].
>>
>>Discussions about the previous version may be found starting here:
>>https://www.redhat.com/archives/libvir-list/2007-August/thread.html#00064
>>
>>I have left use of stdint.h / int64_t, since it wasn't clear to me what
>>conclusion people had arrived at.
>
>Personally I'm for using long long, since its consistent with the other
>existing APIs using 64 bit quantities. They're both standards so there's
>no much of a reason to favour one over the other.
I favour int64_t, because I want 64 bit integers (signed in this case
because I want the special -1 value). C doesn't specify a maximum width
for "long long".
>I notice the Xen impl of the block stats only fills in the rd_req and
>wr_req
>fields, not the rd_bytes and wr_bytes fields. Are requests always fixed at
>512 bytes in size ? If so, should be just junk those fields and only return
>data in terms of the bytes (other units can be calculated as needed). As a
>point of reference libstatgrab only returns bytes read/written for disks.
I assumed that Xen requests were variable in size ... That is based on
my reading of this code from blkif.h:
Ok, yes I they are variable size. I was mixing up requests vs sectors, the
latter being fixed, the former being variable since they can be made up of
multiple sectors.
If it is true that requests have a fixed size, then returning bytes
_also_ would be good, but I suspect that we should also still return
requests as well since (a) it costs virtually nothing to do so, and (b)
it might be interesting to find the average size of each request, since
lots of small requests are likely to be less efficient than small
numbers of large requests.
Yes, we need both. If we can't find actual request sizes for Xen, we should
make a note and see if its possible add this to future Xen kernel backend
drivers.
>For hdNNN based disks it seems to be
>
> ide major number corresponding to disk letter * 256 + minor number
> as calculated from partition numbers.
OK ... I've never seen Xen guests with sdX/hdX devices. Are they common?
Any HVM guest.... A lot of people do use them in paravirt too, we refuse
to use it in Fedora because the ability to hijack hdN and sdN was disappearing
in paravirt_ops Xen merge. So hopefully not so common in future, but we'll
likely hit them periodically in the wild
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 -=|
7:10 a.m.
Daniel P. Berrange wrote:
[about requests vs sectors]
Yes, we need both. If we can't find actual request sizes for Xen,
we should
make a note and see if its possible add this to future Xen kernel backend
drivers.
I notice that in the version of Xen in Fedora 7, we now have the
following statistics files, although for partition-backed paravirt
domains only:
# ls /sys/devices/xen-backend/vbd-6-51712/statistics/
br_req oo_req rd_req rd_sect wr_req wr_sect
rd_sect / wr_sect contain sectors, so if we can assume 512 bytes/sector
then we could fill in the bytes fields.
The Xen block device stats collection code needs some work anyway in
order to support hdX devices and fullvirt domains (where the statistics
files are called tap_XX_req etc.)
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
6:55 a.m.
On Tue, Aug 21, 2007 at 03:37:41AM +0100, Daniel P. Berrange wrote:
The Xen impl as coded only works for disks named xvdN, because the
code for
calculating device ID assumes xvdN device numbering scheme:
device = 202 * 256 + minor;
What's with device numbering at all? Must we really repeat this crazy
Linuxism from xend in libvirt :(
john
7:10 a.m.
On Tue, Aug 21, 2007 at 12:55:19PM +0100, John Levon wrote:
On Tue, Aug 21, 2007 at 03:37:41AM +0100, Daniel P. Berrange wrote:
> The Xen impl as coded only works for disks named xvdN, because the code for
> calculating device ID assumes xvdN device numbering scheme:
>
> device = 202 * 256 + minor;
What's with device numbering at all? Must we really repeat this crazy
Linuxism from xend in libvirt :(
Do you have an alternative ? Because this is commited in CVS and I
would like to get 0.3.2 rolled out ASAP ! So if you have a practical
suggestion or a patch, please post it, I may delay the issue but
just stating 'crazy Linuxism' without specifying why and how this can
be fixed won't help.
thanks !
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/
7:26 a.m.
On Tue, Aug 21, 2007 at 08:10:33AM -0400, Daniel Veillard wrote:
> > The Xen impl as coded only works for disks named xvdN,
because the code for
> > calculating device ID assumes xvdN device numbering scheme:
> >
> > device = 202 * 256 + minor;
>
> What's with device numbering at all? Must we really repeat this crazy
> Linuxism from xend in libvirt :(
Do you have an alternative ? Because this is commited in CVS and I
would like to get 0.3.2 rolled out ASAP ! So if you have a practical
suggestion or a patch, please post it, I may delay the issue but
just stating 'crazy Linuxism' without specifying why and how this can
be fixed won't help.
I just checked it out, and it looks like it can be safely encapsulated
in this case. I was worried it would end up like xend but it seems we
can entirely wrap the knowledge of this to be Linux-only.
BTW I am a little concerned that we're re-implementing all this code
when libxenstat can do it. I already wrote this code once :)
apologies,
john
8:06 a.m.
On Tue, Aug 21, 2007 at 01:26:14PM +0100, John Levon wrote:
On Tue, Aug 21, 2007 at 08:10:33AM -0400, Daniel Veillard wrote:
> > > The Xen impl as coded only works for disks named xvdN, because the code
for
> > > calculating device ID assumes xvdN device numbering scheme:
> > >
> > > device = 202 * 256 + minor;
> >
> > What's with device numbering at all? Must we really repeat this crazy
> > Linuxism from xend in libvirt :(
>
> Do you have an alternative ? Because this is commited in CVS and I
> would like to get 0.3.2 rolled out ASAP ! So if you have a practical
> suggestion or a patch, please post it, I may delay the issue but
> just stating 'crazy Linuxism' without specifying why and how this can
> be fixed won't help.
I just checked it out, and it looks like it can be safely encapsulated
in this case. I was worried it would end up like xend but it seems we
can entirely wrap the knowledge of this to be Linux-only.
Yeah we will need to #ifdef/#else on a per OS basis, which is not perfect
but this is still workable, as long as the API is clean I don't have too
much concerns.
BTW I am a little concerned that we're re-implementing all this
code
when libxenstat can do it. I already wrote this code once :)
Ah :-) Well that's LGPL so we can probably reuse pieces of it. But
I don't feel too confident relying on an installed Xen library at this
point.
apologies,
No need, express yourself :-) What I want to make sure is that 0.3.2
is not broken on a serious basis. If you think you can provide a solaris
patch for that new code I can wait for a day before actually rolling out the
release. Just tell me if you think it's possible,
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/
8:27 a.m.
On Tue, Aug 21, 2007 at 09:06:08AM -0400, Daniel Veillard wrote:
> apologies,
No need, express yourself :-) What I want to make sure is that 0.3.2
is not broken on a serious basis. If you think you can provide a solaris
patch for that new code I can wait for a day before actually rolling out the
release. Just tell me if you think it's possible,
Hi Dan, it will take us longer than that to implement these missing
bits, so go ahead without us. We'll catch up :)
regards
john
8:34 a.m.
On Tue, Aug 21, 2007 at 09:06:08AM -0400, Daniel Veillard wrote:
On Tue, Aug 21, 2007 at 01:26:14PM +0100, John Levon wrote:
> On Tue, Aug 21, 2007 at 08:10:33AM -0400, Daniel Veillard wrote:
>
> > > > The Xen impl as coded only works for disks named xvdN, because the
code for
> > > > calculating device ID assumes xvdN device numbering scheme:
> > > >
> > > > device = 202 * 256 + minor;
> > >
> > > What's with device numbering at all? Must we really repeat this crazy
> > > Linuxism from xend in libvirt :(
> >
> > Do you have an alternative ? Because this is commited in CVS and I
> > would like to get 0.3.2 rolled out ASAP ! So if you have a practical
> > suggestion or a patch, please post it, I may delay the issue but
> > just stating 'crazy Linuxism' without specifying why and how this can
> > be fixed won't help.
>
> I just checked it out, and it looks like it can be safely encapsulated
> in this case. I was worried it would end up like xend but it seems we
> can entirely wrap the knowledge of this to be Linux-only.
Yeah we will need to #ifdef/#else on a per OS basis, which is not perfect
but this is still workable, as long as the API is clean I don't have too
much concerns.
> BTW I am a little concerned that we're re-implementing all this code
> when libxenstat can do it. I already wrote this code once :)
Ah :-) Well that's LGPL so we can probably reuse pieces of it. But
I don't feel too confident relying on an installed Xen library at this
point.
FYI, in case people didn't realize we can /use/ code from libxenstat. We
can't link it though, because libxenstat links to libxc and thus the result
becomes GPL.
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:37 a.m.
On Tue, Aug 21, 2007 at 02:34:57PM +0100, Daniel P. Berrange wrote:
> Ah :-) Well that's LGPL so we can probably reuse pieces of
it. But
> I don't feel too confident relying on an installed Xen library at this
> point.
FYI, in case people didn't realize we can /use/ code from libxenstat. We
can't link it though, because libxenstat links to libxc and thus the result
becomes GPL.
Ugh, yes. It's a been a long long time since Ian last promised to look
at relicensing libxc sensibly. Oh well.
john
8:39 a.m.
On Tue, Aug 21, 2007 at 02:37:13PM +0100, John Levon wrote:
On Tue, Aug 21, 2007 at 02:34:57PM +0100, Daniel P. Berrange wrote:
> > Ah :-) Well that's LGPL so we can probably reuse pieces of it. But
> > I don't feel too confident relying on an installed Xen library at this
> > point.
>
> FYI, in case people didn't realize we can /use/ code from libxenstat. We
> can't link it though, because libxenstat links to libxc and thus the result
> becomes GPL.
Ugh, yes. It's a been a long long time since Ian last promised to look
at relicensing libxc sensibly. Oh well.
Re-licensing wouldn't help us either. Because it would mean libvirt could
only be used with new Xen releases, not old ones & we need to support the
entire 3.x series really.
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:21 a.m.
John Levon wrote:
BTW I am a little concerned that we're re-implementing all this
code
when libxenstat can do it. I already wrote this code once :)
I based this code on libxenstat. Because libxenstat itself depends on
libxc, and removing the libxc dependency was not going to be easy, I
reimplemented it. (It's also based on an internal Red Hat project
called virtstat).
I know libxenstat has the Solaris support ... That's what I was going
to copy over once I had a Solaris machine up and running here, but feel
free to beat me to it with a patch instead :-)
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
8:33 a.m.
On Tue, Aug 21, 2007 at 12:55:19PM +0100, John Levon wrote:
On Tue, Aug 21, 2007 at 03:37:41AM +0100, Daniel P. Berrange wrote:
> The Xen impl as coded only works for disks named xvdN, because the code for
> calculating device ID assumes xvdN device numbering scheme:
>
> device = 202 * 256 + minor;
What's with device numbering at all? Must we really repeat this crazy
Linuxism from xend in libvirt :(
We need to convert from 'xvda' into /local/domain/0/backend/vbd/[domid]/[device
num]
where 'device num' is a crazy ass number XenD calculaties using the formula
above. The other option is to just iterate over every backend node comparing
the device name field. O(n) vs O(1) xenstore queries.
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 -=|
5:46 a.m.
Hello,
- Aren't "xdr_remote_domain_interface_stats_ret" and
"xdr_remote_domain_interface_stats_args" functions missing in the patch?
As I understand, those should be in qemud/remote_protocol.c.
Repesctively, qemud/remote_protocol.h changes are missing too.
Best regards,
Mindaugas Kiznis
Richard W.M. Jones wrote:
This patch adds block device and network stats. The main changes
over
the previous version are:
* Remote support.
* Change Xen network interface names to have the form
"vif<domid>.<n>"[1].
Discussions about the previous version may be found starting here:
https://www.redhat.com/archives/libvir-list/2007-August/thread.html#00064
I have left use of stdint.h / int64_t, since it wasn't clear to me
what conclusion people had arrived at.
I left the explicit structure size parameter to allow for future
extensibility.
Also attached is the output of:
virsh -c xen+tls://amd/ domifstat fc6_1 vif2.0
Rich.
[1] There is currently no way to get the interface name except to just
know it -- that is the subject of a separate patch.
------------------------------------------------------------------------
--
Libvir-list mailing list
Libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
6:09 a.m.
Mindaugas Kiznis wrote:
- Aren't "xdr_remote_domain_interface_stats_ret" and
"xdr_remote_domain_interface_stats_args" functions missing in the patch?
As I understand, those should be in qemud/remote_protocol.c.
Repesctively, qemud/remote_protocol.h changes are missing too.
I usually omit changes to qemud/remote_protocol.[ch] and
qemud/remote_dispatch_*.h files since these files are automatically
generated from the single source file qemud/remote_protocol.x. If I
were to include those generated files in the patch it would make the
patch much larger and harder to understand.
To rebuild them, do:
rm -f qemud/remote_protocol.[ch] qemud/remote_dispatch_*.h
make -C qemud remote_protocol.c
make -C qemud all # ignore the error
Then you should be able to autogen.sh / make clean / make all install as
usual.
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
6294
days inactive
6303
days old
17 comments
5 participants
participants (5)
-
Daniel P. Berrange -
Daniel Veillard -
John Levon -
Mindaugas Kiznis -
Richard W.M. Jones