[Libvir] [PATCH] Block device and network stats (version 2)
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
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 -=|
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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
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 -=|
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
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
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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
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 -=|
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
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 -=|
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
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 -=|
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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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
participants (5)
-
Daniel P. Berrange -
Daniel Veillard -
John Levon -
Mindaugas Kiznis -
Richard W.M. Jones