Re: [libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
by David Miller
From: Mike Frysinger <vapier(a)gentoo.org>
Date: Wed, 16 Jan 2013 12:28:39 -0500
> if you're not calling the kernel directly, why are you including the kernel
> headers ? what is the problem people are actually trying to address here (and
> no, "i want to include both headers" is not the answer) ?
When GLIBC doesn't provide it's own definition of some networking
macros or interfaces that the kernel provides, people include the
kernel header.
This has been done for decades, wake up.
11 years, 11 months
Re: [libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
by Cong Wang
On Wed, 2013-01-16 at 14:22 -0500, Mike Frysinger wrote:
>
> but this is still too vague. what headers/definitions do people want to see
> simultaneously included ? changes would be needed on both sides (kernel & C
> library).
>
Hi, Mike,
Please take a look at my first email in this thread. The user
application includes <linux/if_bridge.h> and <netinet/in.h>.
<linux/if_bridge.h> uses struct_in6 but doesn't include <linux/in6.h>
(this is my bad, sorry), an obvious fix is just including <linux/in6.h>.
But this immediately breaks applications which include
<linux/if_bridge.h> and <netinet/in.h>, just as what Thomas reported.
And if_bridge.h is kernel-specific, there is no corresponding glibc one,
so you can't blame applications which include both of them.
Thanks.
11 years, 11 months
[libvirt] [PATCH 0/5] libxl: Trivial fixes and style improvements
by Jim Fehlig
This patchset contains some trivial bug fixes and style improvements
for the libxl driver that were noticed while investigating races
between the driver and libxl.
Jim Fehlig (5):
libxl: Use consistent style for function definitions
libxl: Use consistent parameter naming scheme
libxl: Don't free domain death event
libxl: Check for libxl_ctx_alloc failure
libxl: Fix cleanup on domain start error
src/libxl/libxl_driver.c | 106 ++++++++++++++++++++++++++---------------------
1 file changed, 58 insertions(+), 48 deletions(-)
--
1.8.0.1
11 years, 11 months
[libvirt] iptables --physdev-out warnings
by Reinier Schoof
Hi,
we've experienced some issues with starting lots of KVM based VM's with
libvirt. Since I couldn't find any clues on the libvirt mailing list,
I'm posting the way I fixed the issues.
When starting a VM, /var/log/messages was spammed with the following
message:
xt_physdev: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING
chains for non-bridged traffic is not supported anymore.
With each extra VM I start, the messages get amplified exponentially.
This results in longer starting times every new VM, relative the the
previously started VM. When I ran a test with starting 100 equal VM's,
the first VM started in about 2 seconds, the 100th VM took 48 seconds to
start. I'm running a vanilla 3.7.1 kernel, but I have the same issue on
VM hosts with kernel 3.2.28 or 3.2.0, running libvirt 0.9.12 and 0.9.8
respectively.
Looking into the warning, it seemed that iptables need an extra
argument, --physdev-is-bridged, in commands like:
iptables -A libvirt-out -m physdev --physdev-is-bridged --physdev-out
vnet99 -g FP-vnet99
I patched the libvirt source (version 1.0.0) to test whether this works
or not:
--- src/nwfilter/nwfilter_ebiptables_driver.c.orig 2013-01-16
10:51:43.000000000 +0100
+++ src/nwfilter/nwfilter_ebiptables_driver.c 2013-01-16
10:52:07.000000000 +0100
@@ -166,7 +166,7 @@
snprintf(buf, sizeof(buf), "%c%c-%s", prefix[0], prefix[1], ifname)
#define PHYSDEV_IN "--physdev-in"
-#define PHYSDEV_OUT "--physdev-out"
+#define PHYSDEV_OUT "--physdev-is-bridged --physdev-out"
static const char *m_state_out_str = "-m state --state NEW,ESTABLISHED";
static const char *m_state_in_str = "-m state --state ESTABLISHED";
The warnings in /var/log/messages are gone and running the test again
proved the 100th VM started in 3.8 seconds. It suprises me I'm the first
to mention this problem on the libvirt mailing list and I wondering if
I'm doing something wrong. Until then, this fix helps me a lot!
Reinier Schoof
--
TransIP BV | https://www.transip.nl/
11 years, 11 months
[libvirt] [PATCH] Fix typo in variable name
by Guido Günther
Hi,
I pushed that under the build breaker rule:
that broke the build like:
CC libvirt_conf_la-domain_conf.lo
conf/domain_conf.c: In function 'virDomainVcpuPinAdd':
conf/domain_conf.c:11920:29: error: 'vpcupin' undeclared (first use in this function)
conf/domain_conf.c:11920:29: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [libvirt_conf_la-domain_conf.lo] Error 1
---
src/conf/domain_conf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 88865b5..13c14e9 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -11917,7 +11917,7 @@ int virDomainVcpuPinAdd(virDomainVcpuPinDefPtr **vcpupin_list,
no_memory:
virReportOOMError();
- virDomainVcpuPinDefFree(vpcupin);
+ virDomainVcpuPinDefFree(vcpupin);
return -1;
}
--
1.7.10.4
11 years, 11 months
Re: [libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
by David Miller
From: Mike Frysinger <vapier(a)gentoo.org>
Date: Wed, 16 Jan 2013 14:22:16 -0500
> On Wednesday 16 January 2013 13:59:59 David Miller wrote:
>> This has been done for decades, wake up.
>
> and it's been broken for just as long. no need to be a dick.
By being ignorant and having such a simplistic view of the situation,
you're the one who's actually the dick.
11 years, 11 months
[libvirt] [PATCH 0/2] add qemu machine type q35 support
by liguang
qemu-1.3 added machine type q35,
changelog said:
Added Intel Q35 chipset as a new machine type,
'--machine q35'. Adds PCIe support. Requires an updated SeaBIOS (bios.bin),
and '-acpitable file=/seabios-path/q35-acpi-dsdt.aml' to run.
so add q35 support for libvirt.
src/conf/device_conf.c | 8 +++++++-
src/conf/device_conf.h | 1 +
src/conf/domain_conf.c | 1 +
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 11 +++++++++++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 8 +++-
7 files changed, 29 insertions(+), 2 deletions(-)
11 years, 11 months
[libvirt] [PATCH] safe{read,write}: Don't lie on nonblocking FD
by Michal Privoznik
Currently, whenever somebody calls saferead() on nonblocking FD
(safewrite() is totally interchangeable for purpose of this
message) he might get wrong return value. For instance, in the
first iteration some data is read. The number of bytes read is
stored into local variable 'nread'. However, in next iterations
we can get -1 from read() with errno == EAGAIN, in which case the
-1 is returned despite fact some data has already been read. So
the caller gets confused.
Moreover, the comment just above the functions says, they act
like regular read() with nicer handling of EINTR. Well, they
don't now.
---
src/util/virutil.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/util/virutil.c b/src/util/virutil.c
index b36e9d3..cd19971 100644
--- a/src/util/virutil.c
+++ b/src/util/virutil.c
@@ -105,6 +105,8 @@ saferead(int fd, void *buf, size_t count)
size_t nread = 0;
while (count > 0) {
ssize_t r = read(fd, buf, count);
+ if (r < 0 && nread && errno == EAGAIN)
+ return nread;
if (r < 0 && errno == EINTR)
continue;
if (r < 0)
@@ -125,7 +127,8 @@ safewrite(int fd, const void *buf, size_t count)
size_t nwritten = 0;
while (count > 0) {
ssize_t r = write(fd, buf, count);
-
+ if (r < 0 && nwritten && errno == EAGAIN)
+ return nwritten;
if (r < 0 && errno == EINTR)
continue;
if (r < 0)
--
1.8.0.2
11 years, 11 months
[libvirt] [PATCH] conf: fix class_id bitmap leak in virNetworkObj
by Ján Tomko
Commit '07d1b6b' added class_id bitmap to virNetworkObj but never freed
it.
---
src/conf/network_conf.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index 48639a9..9c35ea8 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -235,6 +235,7 @@ void virNetworkObjFree(virNetworkObjPtr net)
virNetworkDefFree(net->def);
virNetworkDefFree(net->newDef);
+ virBitmapFree(net->class_id);
virMutexDestroy(&net->lock);
--
1.7.8.6
11 years, 11 months
Re: [libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
by Ben Hutchings
On Wed, 2013-01-16 at 12:04 -0500, Mike Frysinger wrote:
> On Wednesday 16 January 2013 10:47:12 Ben Hutchings wrote:
> > On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
> > > Cong Wang wrote:
> > > > (Cc'ing some glibc developers...)
> > > >
> > > > Hello,
> > > >
> > > > In glibc source file inet/netinet/in.h and kernel source file
> > > > include/uapi/linux/in6.h, both define struct in6_addr, and both are
> > > > visible to user applications. Thomas reported a conflict below.
> > > >
> > > > So, how can we handle this? /me is wondering why we didn't see this
> > > > before.
> >
> > [...]
> >
> > > This is not a new issue. In addition to this,
> > > netinet/in.h also conflits with linux/in.h.
> > >
> > > We might have
> > >
> > > #if !defined(__GLIBC__) || !defined(_NETINET_IN_H)
> > >
> > > #endif
> > >
> > > around those conflicting definitions in uapi/linux/in{,6}.h.
> >
> > This only solves half the problem, as <netinet/in.h> might be included
> > after <linux/in.h>. Also, not all Linux userland uses glibc.
>
> certainly true, but the current expectation is that you don't mix your ABIs.
Whose expectation? Which ABIs are being mixed?
> if you're programming with the C library API, then use the C library headers.
> if you're banging directly on the kernel, then use the kernel headers. not
> saying it's a perfect solution, but it works for the vast majority of use
> cases.
In practice most C programs for Linux will use a mixture of thinly
wrapped system calls and higher-level APIs from the C library, and never
really call the kernel directly (as that requires inline assembler).
Userland programmers will work around this historical mess by tweaking
the #include order or splitting source files. But they shouldn't have
to.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
11 years, 11 months
