starting with kernel 2.6.38 macvtap supports a 'passthru' mode for
attaching virtual functions of a SRIOV capable network card directly to a VM.
This patch adds the capability to configure such a device.
Signed-off-by: Dirk Herrendoerfer <d.herrendoerfer@herrendoerfer.name>
<sys/syslimits.h> is not standardized, so portable programs should
not need to rely on it. If there really is something that we need
where <sys/syslimits.h> provided the limit but <limits.h> did not,
then that would be a candidate for fixing in gnulib. But this patch
did not turn up any compilation failures on Linux.
* src/internal.h (includes): Drop unused header.
* daemon/libvirtd.h (includes): Likewise.
* configure.ac (AC_CHECK_HEADERS): Likewise.
Based on a report by Matthias Bolte.
There is no need to redefine _GNU_SOURCE in tests that occur after
gl_INIT, since that macro already AC_DEFINE'd it for us.
Signed-off-by: Eric Blake <eblake@redhat.com>
glibc 2.13.90 has obsoleted its rpc implementation in favour of
the one provided by the TI-RPC library:
> * The RPC implementation in libc is obsoleted. Old programs keep working
> but new programs cannot be linked with the routines in libc anymore.
> Programs in need of RPC functionality must be linked against TI-RPC.
> The TI-RPC implemtation is IPv6 enabled and there are other benefits.
>
> Visible changes of this change include (obviously) the inability to
> link
> programs using RPC functions without referencing the TI-RPC library,
> the
> removal of the RPC headers from the glibc headers, and the lack of
> symbols defined in <rpc/netdb.h> when <netdb.h> is installed.
> Implemented by Ulrich Drepper.
(from glibc NEWS)
Thus with recent glibc, we need to try linking with -ltirpc when looking
for the XDR functions. The daemon also needs to use XDR_CFLAGS to be able
to find the XDR headers stored in /usr/include/tirpc.
When using TI-RPC, there are some warnings about redundant declarations, but
the fix probably belongs in other modules:
/usr/include/tirpc/rpc/rpcent.h:68:13: warning: redundant redeclaration of
'setrpcent' [-Wredundant-decls]
/usr/include/rpc/netdb.h:53:13: note: previous declaration of 'setrpcent'
was here
/usr/include/tirpc/rpc/rpcent.h:69:13: warning: redundant redeclaration of
'endrpcent' [-Wredundant-decls]
/usr/include/rpc/netdb.h:54:13: note: previous declaration of 'endrpcent'
was here
/usr/include/tirpc/rpc/rpc.h:84:12: warning: redundant redeclaration of
'bindresvport' [-Wredundant-decls]
/usr/include/netinet/in.h:440:12: note: previous declaration of
'bindresvport' was here
Version 2.0.0 or yajl changed API. It is fairly trivial for us to
cope with both APIs in libvirt, so adapt.
* configure.ac: Probe for yajl2 API
* src/util/json.c: Conditional support for yajl2 API
* configure.ac libvirt.spec.in docs/news.html.in: update and document
the release
* po/*.po*: update localizations for german, polish, spanish, ukrainian
and vietnamese coming from transifex, regenerate
In Fedora 15, with clang 2.8, 'scan-build env' shows:
CCC_ANALYZER_ANALYSIS=-analyzer-check-objc-mem -analyzer-check-security-syntactic -analyzer-check-dead-stores -analyzer-check-objc-unused-ivars -analyzer-check-objc-methodsigs
But in rawhide, with clang 2.9, the same variable is set but
empty, implying the default set of analysis. We still want
sa_assert defined in that case, to stop clang from hitting
false positives.
* configure.ac (STATIC_ANALYSIS): Detect clang even when the set
of analyses is the default.
If one specify "--with-python=yes" but no python-devel package
is installed, we ignore it with just a notice message, which
doesn't give clear guide to user.
Remove custom code for checking compiler warnings, using
gl_WARN_ADD instead. Don't list all flags ourselves, use
gnulib's gl_MANYWARN_ALL_GCC to get all possible GCC flags,
then turn off the ones we don't want yet.
* acinclude.m4: Rewrite to use gl_WARN_ADD and gl_MANYWARN_ALL_GCC
* bootstrap.conf: Add warnings & manywarnings
* configure.ac: Switch to gl_WARN_ADD
* m4/compiler-flags.m4: Obsoleted by gl_WARN_ADD
* src/Makefile.am src/libvirt_private.syms configure.ac: share and
reuse the sexpr routines from sexpr.h of the old xen driver
* src/libxl/libxl_driver.c: implements libxlDomainXMLFromNative and
libxlDomainXMLToNative
The Open Nebula driver has been unmaintained since it was first
introduced. The only commits have been for tree-wide cleanups.
It also has a major design flaw, in that it only knows about guests
that it has created itself, which makes it of very limited use.
Discussions wrt evolution of the VMWare ESX driver, concluded that
it should limit itself to single-node ESX operation and not try to
manage the multi-node architecture of VirtualCenter. Open Nebula
is a cluster like Virtual Center, not a single node system, so
the same reasoning applies.
The DeltaCloud project includes an Open Nebula driver and is a much
better fit architecturally, since it is explicitly targetting the
distributed multihost cluster scenario.
Thus this patch deletes the libvirt Open Nebula driver with the
recommendation that people use DeltaCloud for managing it instead.
* configure.ac: Remove probe for xmlrpc & --with-one arg
* daemon/Makefile.am, daemon/libvirtd.c, src/Makefile.am: Remove
ONE driver build
* src/opennebula/one_client.c, src/opennebula/one_client.h,
src/opennebula/one_conf.c, src/opennebula/one_conf.h,
src/opennebula/one_driver.c, src/opennebula/one_driver.c: Delete
files
* autobuild.sh, libvirt.spec.in, mingw32-libvirt.spec.in: Remove
build rules for Open Nebula
* docs/drivers.html.in, docs/sitemap.html.in: Remove reference
to OpenNebula
* docs/drvone.html.in: Delete file
The libxenlight driver does not build against the tech preview
version of libxenlight in Xen 4.0. Only enable building the
driver against more complete libxenlight found in Xen 4.1.
Add a new xen driver based on libxenlight [1], which is the primary
toolstack starting with Xen 4.1.0. The driver is stateful and runs
privileged only.
Like the existing xen-unified driver, the libxenlight driver is
accessed with xen:// URI. Driver selection is based on the status
of xend. If xend is running, the libxenlight driver will not load
and xen:// connections are handled by xen-unified. If xend is not
running *and* the libxenlight driver is available, xen://
connections are deferred to the libxenlight driver.
V6:
- Address several code style issues noted by Daniel Veillard
- Make drive work with xen:/// URI
- Hold domain object reference while domain is injected in
libvirt event loop. Race found and fixed by Markus Groß.
V5:
- Ensure events are unregistered when domain private data
is destroyed. Discovered and fixed by Markus Groß.
V4:
- Handle restart of libvirtd, reconnecting to previously
started domains
- Rebased to current master
- Tested against Xen 4.1 RC7-pre (c/s 22961:c5d121fd35c0)
V3:
- Reserve vnc port within driver when autoport=yes
V2:
- Update to Xen 4.1 RC6-pre (c/s 22940:5a4710640f81)
- Rebased to current master
- Plug memory leaks found by Stefano Stabellini and valgrind
- Handle SHUTDOWN_crash domain death event
[1] http://lists.xensource.com/archives/html/xen-devel/2009-11/msg00436.html
The kill() function doesn't exist on Win32, so it needs to be
checked for at build time & code disabled in cgroups
* configure.ac: Check for kill()
* src/util/cgroup.c: Stub out virCGroupKill* functions
when kill() isn't available
Currently, we need virIsDevMapperDevice() when we build libvirt with
disk or mpath storage drivers. So we should check device-mapper-devel
when we build with disk storage driver but without mpath storage
driver.
Two regressions:
Commit df1011ca broke builds for systems that lack devmapper
(non-Linux, as well as Linux with ./autogen.sh --without-libvirtd
and without the libraries present).
Commit ce6fd650 broke cross-compilation, due to a gnulib bug.
* .gnulib: Update to latest, for cross-compilation fix.
* src/util/util.c (virIsDevMapperDevice): Provide stub for
platforms not using storage driver.
* configure.ac (devmapper): Arrange to define HAVE_LIBDEVMAPPER_H.
devmapper issue reported by Wen Congyang.
The name convention of device mapper disk is different, and 'parted'
can't be used to delete a device mapper disk partition. e.g.
Name Path
-----------------------------------------
3600a0b80005ad1d7000093604cae912fp1 /dev/mapper/3600a0b80005ad1d7000093604cae912fp1
Error: Expecting a partition number.
This patch introduces 'dmsetup' to fix it.
Changes:
- New function "virIsDevMapperDevice" in "src/utils/utils.c"
- remove "is_dm_device" in "src/storage/parthelper.c", use
"virIsDevMapperDevice" instead.
- Requires "device-mapper" for 'with-storage-disk" in "libvirt.spec.in"
- Check "dmsetup" in 'configure.ac' for "with-storage-disk"
- Changes on "src/Makefile.am" to link against libdevmapper
- New entry for "virIsDevMapperDevice" in "src/libvirt_private.syms"
Changes from v1 to v3:
- s/virIsDeviceMapperDevice/virIsDevMapperDevice/g
- replace "virRun" with "virCommand"
- sort the list of util functions in "libvirt_private.syms"
- ATTRIBUTE_NONNULL(1) for virIsDevMapperDevice declaration.
e.g.
Name Path
-----------------------------------------
3600a0b80005ad1d7000093604cae912fp1 /dev/mapper/3600a0b80005ad1d7000093604cae912fp1
Vol /dev/mapper/3600a0b80005ad1d7000093604cae912fp1 deleted
Name Path
-----------------------------------------
* configure.ac docs/news.html.in libvirt.spec.in: bump version and add docs
* po/*.po*: updated Gujarati, Polish and Dutch localisations and regenerated
Make with_packager and with_packager_version default to "no". This way
--without-packager-version (as shorthand for --with-packager(-version)=no)
works correctly too.
Prior to this patch libvirt outputs a line like this when
--with-packager(-version) was not specified
# ./daemon/libvirtd
14:11:15.018: 31796: info : libvirt version: 0.8.8, package: ()
Now the unspecified parts are correctly omitted.
Reported by Osier Yang.
The logging functions are enhanced so that immediately prior to
the first log message being printed to any output channel, the
libvirt package version will be printed.
eg
$ LIBVIRT_DEBUG=1 virsh
18:13:28.013: 17536: info : libvirt version: 0.8.7
18:13:28.013: 17536: debug : virInitialize:361 : register drivers
...
The 'configure' script gains two new arguments which can be
used as
--with-packager="Fedora Project, x86-01.phx2.fedoraproject.org, 01-27-2011-18:00:10"
--with-packager-version="1.fc14"
to allow distros to append a custom string with package specific
data.
The RPM specfile is modified so that it appends the RPM version,
the build host, the build date and the packager name.
eg
$ LIBVIRT_DEBUG=1 virsh
18:14:52.086: 17551: info : libvirt version: 0.8.7, package: 1.fc13 (Fedora Project, x86-01.phx2.fedoraproject.org, 01-27-2011-18:00:10)
18:14:52.086: 17551: debug : virInitialize:361 : register drivers
Thus when distro packagers receive bug reports they can clearly
see what version was in use, even if the bug reporter mistakenly
or intentionally lies about version/builds
* src/util/logging.c: Output version data prior to first log message
* libvirt.spec.in: Include RPM release, date, hostname & packager
* configure.ac: Add --with-packager & --with-packager-version args
* .gnulib: Update to latest, for sigpipe and sigaction modules.
* bootstrap.conf (gnulib_modules): Add siaction, sigpipe, strerror_r.
* tools/virsh.c (vshSetupSignals) [!SIGPIPE]: Delete, now that
gnulib guarantees it.
(SA_SIGINFO): Define for mingw fallback.
* src/util/virterror.c (virStrerror): Simplify, now that gnulib
guarantees the POSIX interface.
* configure.ac (AC_CHECK_FUNCS_ONCE): Drop redundant check.
(AM_PROG_CC_STDC): Move earlier, to keep autoconf happy.
virSetUIDGID() sets both the real and effective group and user of the
process, and additionally calls initgroups() to assure that the
process joins all the auxiliary groups that the given uid is a member
of.
Running an instance of the router advertisement daemon (radvd) allows
guests using the virtual network to automatically acquire an IPv6
address and default route. Note that acquiring an address only works
for networks with a prefix length of exactly 64 - radvd is still run
in other circumstances, and still advertises routes, but autoconf will
not work because it requires exactly 64 bits of address info from the
network prefix.
This patch avoids a race condition with the pidfile by manually
daemonizing radvd rather than allowing it to daemonize itself, then
creating our own pidfile (in addition to radvd's own file, which is
unnecessary, but there is no way to tell radvd to not create it). This
is accomplished by exec'ing it with "--debug 1" in the commandline,
and using virCommand's features to fork, create a pidfile, and detach
from the newly forked process.
All of the iptables functions eventually call down to a single
bottom-level function, and fortunately, ip6tables syntax (for all the
args that we use) is identical to iptables format (except the
addresses), so all we need to do is:
1) Get an address family down to the lowest level function in each
case, either implied through an address, or explicitly when no
address is in the parameter list, and
2) At the lowest level, just decide whether to call "iptables" or
"ip6tables" based on the family.
The location of the ip6tables binary is determined at build time by
autoconf. If a particular target system happens to not have ip6tables
installed, any attempts to run it will generate an error, but that
won't happen unless someone tries to define an IPv6 address for a
network. This is identical behavior to IPv4 addresses and iptables.
brSetInetAddress can only set a single IP address on the bridge, and
uses a method (ioctl(SIOCSETIFADDR)) that only works for IPv4. Replace
it and brSetInetNetmask with a single function that uses the external
"ip addr add" command to add an address/prefix to the interface - this
supports IPv6, and allows adding multiple addresses to the interface.
Although it isn't currently used in the code, we also add a
brDelInetAddress for completeness' sake.
Also, while we're modifying bridge.c, we change brSetForwardDelay and
brSetEnableSTP to use the new virCommand API rather than the
deprecated virRun, and also log an error message in bridge_driver.c if
either of those fail (previously the failure would be completely
silent).
Now the VMware driver doesn't depend on the ESX driver anymore.
Add a WITH_VMX option that depends on WITH_ESX and WITH_VMWARE.
Also add a libvirt_vmx.syms file.
Move some escaping functions from esx_util.c to vmx.c.
Adapt the test suite, ESX and VMware driver to the new code layout.
* configure.ac (dlopen): Cygwin dlopen is in libc; avoid spurious
failure.
(XDR_CFLAGS): Define when needed.
* src/Makefile.am (libvirt_driver_remote_la_CFLAGS): Use it.
* configure.ac (with_selinux): Check for <selinux/label.h>.
* src/security/security_selinux.c (getContext): New function.
(SELinuxRestoreSecurityFileLabel): Use it to restore compilation
when using older libselinux.
Autoconf 2.59 doesn't define ${localedir}, so libvirt was failing
to compile due to a missing LOCALEDIR until today's configmake fix.
* .gnulib: Update to latest for configmake fix.
* configure.ac (libpcap): Avoid AS_CASE.
Don't require dlopen, but link to ole32 and oleaut32 on Windows.
Don't expose g_pVBoxFuncs anymore. It was only used to get the
version of the API. Make VBoxCGlueInit return the version instead.
This simplifies the implementation of the MSCOM glue layer.
Get the VirtualBox version from the registry.
Add a dummy implementation of the nsIEventQueue to the MSCOM glue
as there seems to be no direct equivalent with MSCOM. It might be
implemented using the normal window message loop. This requires
additional investigation.
Without this fix, ./configure --with-libpcap will cause --with-libpcap=yes
to be implicitly passed down, which cause yes/bin/pcap-config to be
searched for rather than /usr/bin/pcap-config.
Also output pcap: no when pcap is not found or disabled.
This fixes a misleading error message saying the libnl package
needs to be installed, when it's really the libnl-devel package
needing to be installed.
To allow messages from different threads to be untangled,
include an integer thread identifier in log messages.
* src/util/logging.c: Include thread ID
* src/util/threads.h, src/util/threads.h, src/util/threads-pthread.c:
Add new virThreadSelfID() function
* configure.ac: Check for sys/syscall.h
