Add support for newly supported Intel cpu features. Newly supported
flags are: pclmuldq, dtes64, smx, fma, pdcm, movbe, xsave, osxsave and
avx. This adds support for Intel's Sandy Bridge platform.
Reported by Alex Jia <ajia@redhat.com>. Function cmdDomIfGetLink did not
set a success return value on success path.
Signed-off-by: Alex Jia<ajia@redhat.com>
A preparatory patch for DHCP snooping where we want to be able to
differentiate between a VM's interface using the tuple of
<VM UUID, Interface MAC address>. We assume that MAC addresses could
possibly be re-used between different networks (VLANs) thus do not only
want to rely on the MAC address to identify an interface.
At the current 'final destination' in virNWFilterInstantiate I am leaving
the vmuuid parameter as ATTRIBUTE_UNUSED until the DHCP snooping patches arrive.
(we may not post the DHCP snooping patches for 0.9.9, though)
Mostly this is a pretty trivial patch. On the lowest layers, in lxc_driver
and uml_conf, I am passing the virDomainDefPtr around until I am passing
only the VM's uuid into the NWFilter calls.
This patch cleans up return codes in the nwfilter subsystem.
Some functions in nwfilter_conf.c (validators and formatters) are
keeping their bool return for now and I am converting their return
code to true/false.
All other functions now have failure return codes of -1 and success
of 0.
[I searched for all occurences of ' 1;' and checked all 'if ' and
adapted where needed. After that I did a grep for 'NWFilter' in the source
tree.]
Detected by valgrind. Leak introduced in commit dc675f3:
* tools/virsh.c: fix memory leak on cmdDomIfGetLink.
* how to reproduce?
% valgrind -v --leak-check=full virsh domif-getlink <domain name> 0
* actual valgrind result:
==13102== 18 bytes in 1 blocks are definitely lost in loss record 9 of 47
==13102== at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==13102== by 0x322A6A67DD: xmlStrndup (in /usr/lib64/libxml2.so.2.7.6)
==13102== by 0x414892: cmdDomIfGetLink (virsh.c:1538)
==13102== by 0x4136A2: vshCommandRun (virsh.c:16363)
==13102== by 0x4253FB: main (virsh.c:17865)
==13102==
==13102== LEAK SUMMARY:
==13102== definitely lost: 18 bytes in 1 blocks
==13102== indirectly lost: 0 bytes in 0 blocks
==13102== possibly lost: 0 bytes in 0 blocks
==13102== still reachable: 127,888 bytes in 1,361 blocks
==13102== suppressed: 0 bytes in 0 blocks
Signed-off-by: Alex Jia <ajia@redhat.com>
Detected by valgrind. Leak introduced in commit e9bd9a0:
* tools/virsh.c: fix memory leak on cmdBlkdeviotune.
* how to reproduce?
% valgrind -v --leak-check=full virsh blkdeviotune <domain name> <block device>
* actual valgrind result:
==12759== 576 bytes in 1 blocks are definitely lost in loss record 18 of 29
==12759== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==12759== by 0x42134E: _vshCalloc.clone.2 (virsh.c:422)
==12759== by 0x4217CB: cmdBlkdeviotune (virsh.c:6364)
==12759== by 0x4136A2: vshCommandRun (virsh.c:16363)
==12759== by 0x4253FB: main (virsh.c:17865)
==12759==
==12759== LEAK SUMMARY:
==12759== definitely lost: 576 bytes in 1 blocks
==12759== indirectly lost: 0 bytes in 0 blocks
==12759== possibly lost: 0 bytes in 0 blocks
==12759== still reachable: 126,964 bytes in 1,342 blocks
==12759== suppressed: 0 bytes in 0 blocks
Signed-off-by: Alex Jia <ajia@redhat.com>
Jiri Denemark reported an instance of bootstrapping libvirt
failing when run inside a sandbox, traced to rpm trying to
access /var/ which was not permitted by the sandbox.
Alex Jia reported that 0.9.8-rc1 failed to bootstrap if patch(1)
is not installed.
* bootstrap.conf (buildreq): Avoid rpm call if python-config
exists. Also, require patch, in case we have gnulib-local diffs.
In some error situations, the function testDomainRestoreFlags() could
unlock the test driver mutex without first locking it. This patch
moves the lock operation earlier, so that it occurs before any
potential jump down to the unlock call.
I found this problem while auditing the test driver lock usage to
determine the cause of a hang while running the following test:
cd tests; while true; do printf x; ./undefine; done
This patch *does not* solve that problem, but we now understand its
actual source, and danpb is working on a patch.
https://bugzilla.redhat.com/show_bug.cgi?id=738725
Commit ecd8725 tried to silence a spurious warning on the initial
libvirt install, and commit ba6cbb1 tried to fix up the logic to the
correct Fedora version, but the warning was still present due to a
logic bug: since %{fedora} and %{rhel} are never simulatanously
set, then 0%{rhel} <= 6 made the %if always true. Checking for
minimum versions (via >=) is okay, but checking for maximum versions
(via <=) requires a prerequisite test that the platform being tested
is non-zero.
Also fix a bogus setting of with_libxl (although we previously
hard-code with_libxl to 0 for rhel earlier in the file, so this
was not as severe a bug).
* libvirt.spec.in (with_cgconfig): Don't enable cgconfig on F16.
Over time, Fedora and RHEL RPMs have often backported upstream
patches that touched configure.ac and/or Makefile.am; this
necessitates rerunning the autotools for the patch to be effective.
Making this a one-liner spec tweak will make it easier for future
backports to pull patches without having to find all the places
to touch to properly use the autotools. Meanwhile, there have been
historical instances where an update in the autotools caused FTBFS
situations, so this is not on by default.
* libvirt.spec.in (enable_autotools): New variable, default off.
(BuildRequires): Conditionally add autotools.
(%build): Conditionally use them before configure.
* mingw32-libvirt.spec.in: Likewise.
The installation rules for the libvirt-guests.service were
totally broken
- Installing in the wrong location
- The location was not overridable
- The install-systemd rule was not invoked anywhere
- The install-systemd rule was not invoking install-initscript
which it depends on
- The installed service file lacked a .service extension
* tools/Makefile.am: Fix install of libvirt-guests.service
The %makeinstall macro does not set DESTDIR, instead of explicitly
prefixes %{buildroot} onto all paths. Thus we need to do the same
when setting the systemd unit dir
* libvirt.spec.in: Prefix %{buildroot} onto %{unitdir}
ppc64 as new arch type and pseries as new machine type are
added under <os> ... </os>.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com>
assumptions from generic code.
This implements the minimal set of changes needed in libvirt to launch a
PowerPC-KVM based guest.
It removes x86-specific assumptions about choice of serial driver backend
from generic qemu guest commandline generation code.
It also restricts the ACPI capability to be available for an x86 or
x86_64 domain.
This is not a complete solution -- it still does not guarantee libvirt
the capability to flag non-supported options in guest XML. (Eg, an ACPI
specification in a PowerPC guest XML will still get processed, even
though qemu-system-ppc64 does not support it while qemu-system-x86_64 does.)
This drawback exists because libvirt falls back on qemu to query supported
features, and qemu '-h' blindly lists all capabilities -- irrespective
of whether they are available while emulating a given architecture or not.
The long-term solution would be for qemu to list out capabilities based
on architecture and platform -- so that libvirt can cleanly make out what
devices are supported on an arch (say 'ppc64') and platform (say, 'mac99').
Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com>
This enables libvirt to select the correct qemu binary (qemu-system-ppc64)
for a guest vm based on arch 'ppc64'.
Also, libvirt is enabled to correctly parse the list of supported PowerPC
CPUs, generated by running 'qemu-system-ppc64 -cpu ?'
Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com>
Acked-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
to proc/cpuinfo
This patch creates a new sysfs hierarchy under
tests/nodeinfodata/linux-nodeinfo-sysfs-test-1.
Output files and /proc/cpuinfo files are also respectively added for
both x86 and ppc64.
Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com>
/proc/cpuinfo
Libvirt at present depends on /proc/cpuinfo to gather host
details such as CPUs, cores, threads, etc. This is an architecture-
dependent approach. An alternative is to use 'Sysfs', which provides
a platform-agnostic interface to parse host CPU topology.
Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com>
https://bugzilla.redhat.com/show_bug.cgi?id=694403 reports that
the specfile is incorrectly checking for a running libvirt-guests
service. For example,
$ LC_ALL=es_ES chkconfig --list libvirt-guests
libvirt-guests 0:desactivado 1:desactivado 2:desactivado 3:activo 4:activo 5:activo 6:desactivado
will fail to find 5:on, even though it is active. But chkconfig
already has a mode where you can silently use the exit status to
check for an active service.
* libvirt.spec.in (%post): Use simpler chkconfig options, to avoid
issues with localization.
On RHEL 5, with libxml2-2.6.26, the build failed with:
virsh.c: In function 'vshNodeIsSuperset':
virsh.c:11951: warning: implicit declaration of function 'xmlChildElementCount'
(or if warnings aren't errors, a link failure later on).
* src/util/xml.h (virXMLChildElementCount): New prototype.
* src/util/xml.c (virXMLChildElementCount): New function.
* src/libvirt_private.syms (xml.h): Export it.
* tools/virsh.c (vshNodeIsSuperset): Use it.
When one thread passes the buck to another thread, it uses
virCondSignal to wake up the target thread. The variable
'haveTheBuck' is not updated in a race-free manner when
this occurs. The current thread sets it to false, and the
woken up thread sets it to true. There is a window where
a 3rd thread can come in and grab the buck.
Even if this didn't lead to crashes & deadlocks, this would
still result in unfairness in the buckpassing algorithm.
A better solution is to *never* set haveTheBuck to false
when we're passing the buck. Only set it to false when there
is no further thread waiting for the buck.
* src/rpc/virnetclient.c: Only set haveTheBuck to false
if no thread is waiting
Commit fd06692544 tried to fix
a race condition in
commit fa9595003d
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Fri Nov 11 15:28:41 2011 +0000
Explicitly track whether the buck is held in remote client
Unfortunately there is a second race condition whereby the
event loop can trigger due to incoming data to read. Revert
this fix, so a complete fix for the problem can be cleanly
applied
* src/rpc/virnetclient.c: Revert fd06692544
With security_driver set to "none" in /etc/libvirt/qemu.conf,
libvirtd would crash when attempted to attach to an existing
qemu process. Only copy the security model if it actually exists.
During virDomainDestroy, QEMU may emit SHUTDOWN event as a response to
SIGTERM and since domain object is still locked, the event is processed
after the domain is destroyed. We need to ignore this event in such case
to avoid changing domain state from shutoff to shutdown.
This patch is to expose the fabric_name of fc_host class, which
might be useful for users who wants to known which fabric the
(v)HBA connects to.
The patch also adds the missed capabilities' XML schema of scsi_host,
(of course, with fabric_wwn added), and update the documents
(docs/formatnode.html.in)
Currently if you try to connect to a local libvirtd when
libvirtd is not in $PATH, you'll get an error
error: internal error invalid use of command API
This is because remoteFindDaemonPath() returns NULL, which
causes us to pass NULL into virNetSocketConnectUNIX which
in turn causes us to pass NULL into virCommandNewArgList.
Adding missing error checks improves this to
error: internal error Unable to locate libvirtd daemon in $PATH
* src/remote/remote_driver.c: Report error if libvirtd
cannot be found
* src/rpc/virnetsocket.c: Report error if caller requested
spawning of daemon, but provided no binary path
https://bugzilla.redhat.com/show_bug.cgi?id=754909 complains that
because libvirt didn't require dmidecode, that the logs are noisy
and virConnectGetSysinfo needlessly fails. Even 'virt-what' requires
dmidecode, so it's not that onerous of a dependency. We may be
able to drop this in the future when we move to parsing sysfs data,
but for now, listing the dependency will help matters.
* libvirt.spec.in (Requires): Sort Requires before BuildRequires.
Add dmidecode.
Older gcc warns (on every file!) that -Wabi and -Wdeprecated only
make sense on C++ projects. Newer gcc accepts these warnings for
C, but it is not clear that they can do anything useful, so it
is easier to just drop the warnings altogether.
* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Silence
-Wabi and -Wdeprecated on older gcc.
Reported by Peter Krempa.
The Mingw32 linker highlighted that the symbols for virtime.h
declared in libvirt_private.syms were incorrect
* src/libvirt_private.syms: Fix virtime.h symbols
When QEMU guest finishes its shutdown sequence, qemu stops virtual CPUs
and when started with -no-shutdown waits for us to kill it using
SGITERM. Since QEMU is flushing its internal buffers, some time may pass
before QEMU actually dies. We mistakenly used "paused" state (and
events) for this which is quite confusing since users may see a domain
going to pause while they expect it to shutdown. Since we already have
"shutdown" state with "the domain is being shut down" semantics, we
should use it for this state.
However, the state didn't have a corresponding event so I created one
and called its detail as VIR_DOMAIN_EVENT_SHUTDOWN_FINISHED (guest OS
finished its shutdown sequence) with the intent to add
VIR_DOMAIN_EVENT_SHUTDOWN_STARTED in the future if we have a
sufficiently capable guest agent that can notify us when guest OS starts
to shutdown.
Otherwise connections to older libvirt abort with:
$ virsh -c qemu+ssh://host.example.com/system list
error: invalid connection pointer in virDrvSupportsFeature
error: failed to connect to the hypervisor
Tested against 0.8.3 and 0.9.8-rc2.
This patch adds binding for virNodeGetMemoryStats method of libvirtd.
Return value is represented as a python dictionary mapping field
names to values.
https://bugzilla.redhat.com/show_bug.cgi?id=648855 mentioned a
misuse of 'an' where 'a' is proper; that has since been fixed,
but a search found other problems (some were a spelling error for
'and', while most were fixed by 'a').
* daemon/stream.c: Fix grammar.
* src/conf/domain_conf.c: Likewise.
* src/conf/domain_event.c: Likewise.
* src/esx/esx_driver.c: Likewise.
* src/esx/esx_vi.c: Likewise.
* src/rpc/virnetclient.c: Likewise.
* src/rpc/virnetserverprogram.c: Likewise.
* src/storage/storage_backend_fs.c: Likewise.
* src/util/conf.c: Likewise.
* src/util/dnsmasq.c: Likewise.
* src/util/iptables.c: Likewise.
* src/xen/xen_hypervisor.c: Likewise.
* src/xen/xend_internal.c: Likewise.
* src/xen/xs_internal.c: Likewise.
* tools/virsh.c: Likewise.
We want our tarballs to be complete - this means that any
generated file that gets shipped as part of the tarball so that
ordinary users don't have to rebuild it must be something
that the maintainer can generate. There have been various
reports of random build failures when using libvirt.git
instead of a tarball, and often it is due to missing a
maintainer-specific tool to produce one of these generated
files. This patch raises the bar for what you must have
installed to build libvirt.git, but does not impact what
you can get away with for building tarballs.
Note: It still remains possible to do a successful 'make dist'
without these tools, when starting from a release tarball.
* bootstrap.conf (buildreq): Add tools that maintainers need for a
successful 'make dist' from a fresh git checkout.
virBufferContentAndReset (intentionally) returns NULL for a buffer
with no content, but it is feasible to invoke a command with an
explicit empty string.
* src/util/command.c (virCommandAddEnvBuffer): Reject empty string.
(virCommandAddArgBuffer): Allow explicit empty argument.
* tests/commandtest.c (test9): Test it.
* tests/commanddata/test9.log: Adjust.
The RPC fixups needed on Linux are also needed on cygwin, and
worked without further tweaking to the list of fixups. Also,
unlike BSD, Cygwin exports 'struct ifreq', but unlike Linux,
Cygwin lacks the ioctls that we were using 'struct ifreq' to
access. This patch allows compilation under cygwin.
* src/rpc/genprotocol.pl: Also perform fixups on cygwin.
* src/util/virnetdev.c (HAVE_STRUCT_IFREQ): Also require AF_PACKET
definition.
* src/util/virnetdevbridge.c (virNetDevSetupControlFull): Only
compile if SIOCBRADDBR works.
I had previously tested commit 059d746 with -O intentionally omitted
from my CFLAGS; but that means that I missed out on this warning
from gcc 4.6.2 when optimizations are enabled:
util/buf.c: In function 'virBufferGetIndent':
util/buf.c:86:1: error: function might be candidate for attribute 'pure' [-Werror=suggest-attribute=pure]
While it is probably a good idea to add the attributes and silence
this warning, it's also invasive; 'make -k' found more than 75 such
complaints. And it doesn't help that gcc 4.6.2 is still buggy
(coreutils reported a case where gcc 4.6.2 incorrectly suggested
marking a function pure that incremented a global variable; fixed
in gcc 4.7). So the best fix for now is to disable the warning.
It also doesn't help that I stumbled across another problem - gcc
documents that -Wsuggest-attribute=pure only warns if you use -O,
or if you use -fipa-pure-const. But in practice, when I omitted -O
but added -fipa-pure-const, the warnings are fickle - I got warnings
for simple compilation that disappeared when I also added -fPIC.
And the way libtool compiles things is with -fPIC first, then without
-fPIC but with errors sent to /dev/null - which meant that without
disabling -Wsuggest-attribute=pure, I got a compile error with no
message. :( See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10197
* m4/virt-compile-warnings.m4 (LIBVIRT_COMPILE_WARNINGS): Silence
-Wsuggest-attribute warnings for now.
The pathname for the pipe for tunnelled migration is unresolvable. The
libvirt apparmor driver therefore refuses access, causing migration to
fail. If we can't resolve the path, the worst that can happen is that
we should have given permission to the file but didn't. Otherwise
(especially since this is a /proc/$$/fd/N file) the file is already open
and libvirt won't be refused access by apparmor anyway.
Also adjust virt-aa-helper to allow access to the
*.tunnelmigrate.dest.name files.
For more information, see https://launchpad.net/bugs/869553.
Signed-off-by: Serge Hallyn <serge.hallyn@canonical.com>
Originaly, the code checked if another client is the queue and infered
ownership of the buck from that. Commit fa9595003d
added a separate variable to track the buck. That caused, that a new
call might enter claiming it has the buck, while another thread was
signalled to take the buck. This ends in two threads claiming they hold
the buck and entering poll(). This happens due to a race on waking up
threads on the client lock mutex.
This caused multi-threaded clients to hang, most prominently visible and
reproducible on python based clients, like virt-manager.
This patch causes threads, that have been signalled to take the buck to
re-check if buck is held by another thread.
With fragments borrowed from David Steven's previous submission and some
further modifications:
A set of modifications to filters to handle multiple IP addresses
(and MAC addresses) per interface.
Also:
- enable DHCP traffic from VM to any DHCP server
- will require an update to a libvirt-tck data file
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
