In some cases (spotted with broken connection during tunneled migration)
we were overwriting the original error with worse or even misleading
errors generated when we were cleaning up after failed migration.
Laine Stump [Wed, 25 Apr 2012 19:49:44 +0000 (15:49 -0400)]
util: fix crash when starting macvtap interfaces
This patch resolves https://bugzilla.redhat.com/show_bug.cgi?id=815270
The function virNetDevMacVLanVPortProfileRegisterCallback() takes an
arg "virtPortProfile", and was checking it for non-NULL before using
it. However, the prototype for
virNetDevMacVLanPortProfileRegisterCallback had marked that arg with
ATTRIBUTE_NONNULL(). Contrary to what one may think,
ATTRIBUTE_NONNULL() does not provide any guarantee that an arg marked
as such really is always non-null; the only effect to the code
generated by gcc, is that gcc *assumes* it is non-NULL; this results
in, for example, the check for a non-NULL value being optimized out.
(Unfortunately, this code removal only occurs when optimization is
enabled, and I am in the habit of doing local builds with optimization
off to ease debugging, so the bug didn't show up in my earlier local
testing).
In general, virPortProfile might always be NULL, so it shouldn't be
marked as ATTRIBUTE_NONNULL. One other function prototype made this
same error, so this patch fixes it as well.
Eric Blake [Wed, 25 Apr 2012 03:40:08 +0000 (21:40 -0600)]
build: fix bootstrap on RHEL
Commit 8fe455fd364cd7462e02170084c45a58ee302cc3 tried to work around
a regression introduced in upstream gnulib that requires gettext 0.18
or newer on all projects using bootstrap, by making libvirt require
gettext 0.18. But this fails on RHEL 6.2, which still ships gettext
0.17. Revert that change, and instead, import the latest round of
gnulib updates that fix that problem properly.
If you have already built in the window where libvirt required 0.18,
be aware that incremental updates may run into problems: this is
because 'autopoint --force' will not downgrade m4/po.m4 back to an
older version, but it must be downgraded back to 0.17 levels to work
with this patch. You may either manually remove that file then rerun
bootstrap, or it may prove easier to just clean up all non-git files
to start from a clean slate.
* bootstrap.conf: Revert minimum gettext back to 0.17.
* configure.ac: Likewise.
* .gnulib: Update to latest, for bootstrap fixes.
* bootstrap: Resync from gnulib.
Peter Krempa [Tue, 24 Apr 2012 09:35:09 +0000 (11:35 +0200)]
build: Fix version of gettext macros
Commit c9cd419caba9effa11ca53e8696e5f6a4b424d60 added copying of the
makefile for translation files from gnulib. The makefile from gnulib is
of version 0.18 but the build configuration cretes macros from version
0.17 which breaks the build with message:
*** error: gettext infrastructure mismatch: using a Makefile.in.in from
gettext version 0.18 but the autoconf macros are from gettext version
0.17
virThreadSelf tries to access the virThreadPtr stored in TLS for the
current thread via TlsGetValue. When virThreadSelf is called on a thread
that was not created via virThreadCreate (e.g. the main thread) then
TlsGetValue returns NULL as TlsAlloc initializes TLS slots to NULL.
virThreadSelf can be called on the main thread via this call chain from
virsh
Eric Blake [Fri, 20 Apr 2012 03:41:27 +0000 (21:41 -0600)]
virnetserver: handle sigaction correctly
POSIX says that sa_sigaction is only safe to use if sa_flags
includes SA_SIGINFO; conversely, sa_handler is only safe to
use when flags excludes that bit. Gnulib doesn't guarantee
an implementation of SA_SIGINFO, but does guarantee that
if SA_SIGINFO is undefined, we can safely define it to 0 as
long as we don't dereference the 2nd or 3rd argument of
any handler otherwise registered via sa_sigaction.
Based on a report by Wen Congyang.
* src/rpc/virnetserver.c (SA_SIGINFO): Stub for mingw.
(virNetServerSignalHandler): Avoid bogus dereference.
(virNetServerFatalSignal, virNetServerNew): Set flags properly.
(virNetServerAddSignalHandler): Drop unneeded #ifdef.
Eric Blake [Wed, 18 Apr 2012 23:58:44 +0000 (17:58 -0600)]
conf: tighten up XML integer parsing
https://bugzilla.redhat.com/show_bug.cgi?id=617711 reported that
even with my recent patched to allow <memory unit='G'>1</memory>,
people can still get away with trying <memory>1G</memory> and
silently get <memory unit='KiB'>1</memory> instead. While
virt-xml-validate catches the error, our C parser did not.
Not to mention that it's always fun to fix bugs while reducing
lines of code. :)
Eric Blake [Thu, 19 Apr 2012 23:19:32 +0000 (17:19 -0600)]
build: avoid type-punning in vbox
Commit 78345c68 makes at least gcc 4.1.2 on RHEL 5 complain:
cc1: warnings being treated as errors
In file included from vbox/vbox_V4_0.c:13:
vbox/vbox_tmpl.c: In function 'vboxDomainUndefineFlags':
vbox/vbox_tmpl.c:5298: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
* src/vbox/vbox_tmpl.c (vboxDomainUndefineFlags): Use union to
avoid compiler warning.
Eric Blake [Thu, 19 Apr 2012 23:04:00 +0000 (17:04 -0600)]
build: fix fresh checkout on RHEL5
Building a fresh checkout on RHEL 5 has been broken since commit 29db7a00, due to a gnulib regression in the bootstrap script
(incremental builds from a checkout earlier than that point were
okay, though).
* .gnulib: Update to latest, for bootstrap fixes.
* bootstrap: Resync from gnulib.
* gnulib/local/top/maint.mk.diff: Drop patch that was added
upstream in the meantime.
D. Herrendoerfer [Fri, 13 Apr 2012 12:41:16 +0000 (14:41 +0200)]
util: only register callbacks for CREATE operations in virnetdevmacvlan.c
Currently upon a migration a callback is created when a 802.1qbg link
is set to PREASSOCIATE, this should not happen because this is a no-op
on most switches, and does not lead to an ASSOCIATE state. This patch
only creates callbacks when CREATE or RESTORE is requested. Migration
and libvirtd restart scenarios are already handled elsewhere.
Signed-off-by: D. Herrendoerfer <d.herrendoerfer@herrendoerfer.name>
Stefan Berger [Tue, 17 Apr 2012 19:13:33 +0000 (15:13 -0400)]
Fix a memory leak
The below patch fixes the following memory leak.
==20624== 24 bytes in 2 blocks are definitely lost in loss record 532 of 1,867
==20624== at 0x4A05E46: malloc (vg_replace_malloc.c:195)
==20624== by 0x38EC27FC01: strdup (strdup.c:43)
==20624== by 0x4EB6BA3: virDomainChrSourceDefCopy (domain_conf.c:1122)
==20624== by 0x495D76: qemuProcessFindCharDevicePTYs (qemu_process.c:1497)
==20624== by 0x498321: qemuProcessWaitForMonitor (qemu_process.c:1258)
==20624== by 0x49B5F9: qemuProcessStart (qemu_process.c:3652)
==20624== by 0x468B5C: qemuDomainObjStart (qemu_driver.c:4753)
==20624== by 0x469171: qemuDomainStartWithFlags (qemu_driver.c:4810)
==20624== by 0x4F21735: virDomainCreate (libvirt.c:8153)
==20624== by 0x4302BF: remoteDispatchDomainCreateHelper (remote_dispatch.h:852)
==20624== by 0x4F72C14: virNetServerProgramDispatch (virnetserverprogram.c:416)
==20624== by 0x4F6D690: virNetServerHandleJob (virnetserver.c:164)
==20624== by 0x4E8F43D: virThreadPoolWorker (threadpool.c:144)
==20624== by 0x4E8EAB5: virThreadHelper (threads-pthread.c:161)
==20624== by 0x38EC606CCA: start_thread (pthread_create.c:301)
==20624== by 0x38EC2E0C2C: clone (clone.S:115)
Osier Yang [Tue, 17 Apr 2012 14:57:01 +0000 (22:57 +0800)]
conf: Do not parse cpuset only if the placement is auto
So that a domain xml which doesn't have "placement" specified, but
"cpuset" is specified, could be parsed. And in this case, the
"placement" mode will be set as "static".
Stefan Bader [Fri, 13 Apr 2012 13:14:56 +0000 (15:14 +0200)]
xen: do not use ioemu type for any emulated NIC
When using the xm/xend stack to manage instances there is a bug
that causes the emulated interfaces to be unusable when the vif
config contains type=ioemu.
The current code already has a special quirk to not use this
keyword if no specific model is given for the emulated NIC
(defaulting to rtl8139).
Essentially it works because regardless of the type argument,i
the Xen stack always creates emulated and paravirt interfaces and
lets the guest decide which one to use. So neither xl nor xm stack
actually require the type keyword for emulated NICs.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
'omitted' was mispelt 'commited' twice. One of the sentences with
the typo was also missing an 'is' ('each VCPU *is* pinned to all...')
which I added in this commit while I was at it.
lvcreate want's the parent pool's name, not the pool path
lvchange and lvremove want lv specified as $vgname/$lvname
This largely worked before because these commands strip off a
starting /dev. But https://bugzilla.redhat.com/show_bug.cgi?id=714986
is from a user using a 'nested VG' that was having problems.
I couldn't find any info on nested LVM and the reporter never responded,
but I reproduced with XML that specified a valid source name, and
set target path to a symlink.
Osier Yang [Wed, 11 Apr 2012 14:40:33 +0000 (22:40 +0800)]
numad: Ignore cpuset if placement is auto
As explained in previous patch, numad will balance the affinity
dynamically, so reflecting the cpuset from numad at the first
time doesn't make much case, and may just could cause confusion.
(cherry picked from commit 8fb2164cfff35ce0b87f1d513a0f3ca5111d7880)
Osier Yang [Mon, 16 Apr 2012 10:04:27 +0000 (18:04 +0800)]
numad: Convert node list to cpumap before setting affinity
Instead of returning a CPUs list, numad returns NUMA node
list instead, this patch is to convert the node list to
cpumap before affinity setting. Otherwise, the domain
processes will be pinned only to CPU[$numa_cell_num],
which will cause significiant performance losses.
Also because numad will balance the affinity dynamically,
reflecting the cpuset from numad back doesn't make much
sense then, and it may just could produce confusion for
the users. Thus the better way is not to reflect it back
to XML. And in this case, it's better to ignore the cpuset
when parsing XML.
The codes to update the cpuset is removed in this patch
incidentally, and there will be a follow up patch to ignore
the manually specified "cpuset" if "placement" is "auto",
and document will be updated too.
(cherry picked from commit ccf80e36301d538505c5c053cf369a61d4671831)
Fix macvtap detection by also checking for IFLA_VF_MAX
since this isn't available on older kernels such as Debian Squeeze's
2.6.32. This make --with-macvtap=check work as expected.
(cherry picked from commit a2996926e303e84436a89dc42fe65d32b5ab8eb5)
Michal Privoznik [Fri, 13 Apr 2012 09:19:29 +0000 (11:19 +0200)]
conf: Avoid double assignment in virDomainDiskRemove
Although it should be harmless to do:
disk = disk = def->disks[i]
some not-so-wise compilers may fool around.
Besides, such assignment is useless here.
(cherry picked from commit e14d6571c1185133d15161bb4b18ec9b11192358)
Stefan Bader [Thu, 12 Apr 2012 13:42:37 +0000 (15:42 +0200)]
xend_internal: Use domain/status for shutdown check
On newer xend (v3.x and after) there is no state and domid reported
for inactive domains. When initially creating connections this is
handled in various places by assigning domain->id = -1.
But once an instance has been running, the id is set to the current
domain id. And it does not change when the instance is shut down.
So when querying the domain info, the hypervisor driver, which gets
asked first will indicate it cannot find information, then the
xend driver is asked and will set the status to NOSTATE because it
checks for the -1 domain id.
Checking domain/status for 0 seems to be more reliable for that.
One note: I am not sure whether the domain->id also should get set
back to -1 whenever any sub-driver thinks the instance is no longer
running.
D. Herrendoerfer [Thu, 29 Mar 2012 11:15:00 +0000 (13:15 +0200)]
qemu,util: fix netlink callback registration for migration
This patch adds a netlink callback when migrating a VEPA enabled
virtual machine. It fixes a Bug where a VM would not request a port
association when it was cleared by lldpad.
This patch requires the latest git version of lldpad to work.
Michal Privoznik [Wed, 11 Apr 2012 09:13:40 +0000 (11:13 +0200)]
qemuOpenFile: Don't force chown on NFS
If dynamic_ownership is off and we are creating a file on NFS
we force chown. This will fail as chown/chmod are not supported
on NFS. However, with no dynamic_ownership we are not required
to do any chown.
(cherry picked from commit b1256816ff34ca94675ef62eccfa66f2a7daa0fc)
% make && make -C tests check TESTS=libvirtdconftest
% cd tests && valgrind -v --leak-check=full ./libvirtdconftest
actual result:
==11008== 185 bytes in 5 blocks are definitely lost in loss record 3 of 5
==11008== at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==11008== by 0x39CF07F6E1: strdup (strdup.c:43)
==11008== by 0x406626: daemonConfigLoadOptions (libvirtd-config.c:438)
==11008== by 0x406800: daemonConfigLoadData (libvirtd-config.c:492)
==11008== by 0x403CCF: testCorrupt (libvirtdconftest.c:110)
==11008== by 0x404FAD: virtTestRun (testutils.c:145)
==11008== by 0x403A34: mymain (libvirtdconftest.c:219)
==11008== by 0x404687: virtTestMain (testutils.c:700)
==11008== by 0x39CF01ECDC: (below main) (libc-start.c:226)
==11008==
==11008== LEAK SUMMARY:
==11008== definitely lost: 185 bytes in 5 blocks
Peter Krempa [Tue, 10 Apr 2012 09:56:21 +0000 (11:56 +0200)]
qemu: Fix deadlock when qemuDomainOpenConsole cleans up a connection
The new safe console handling introduced a possibility to deadlock the
qemu driver when a new console connection forcibly disconnects a
previous console stream that belongs to an already closed connection.
The virStreamFree function calls subsequently a the virReleaseConnect
function that tries to lock the driver while discarding the connection,
but the driver was already locked in qemuDomainOpenConsole.
Backtrace of the deadlocked thread:
0 0x00007f66e5aa7f14 in __lll_lock_wait () from /lib64/libpthread.so.0
1 0x00007f66e5aa3411 in _L_lock_500 () from /lib64/libpthread.so.0
2 0x00007f66e5aa322a in pthread_mutex_lock () from/lib64/libpthread.so.0
3 0x0000000000462bbd in qemudClose ()
4 0x00007f66e6e178eb in virReleaseConnect () from/usr/lib64/libvirt.so.0
5 0x00007f66e6e19c8c in virUnrefStream () from /usr/lib64/libvirt.so.0
6 0x00007f66e6e3d1de in virStreamFree () from /usr/lib64/libvirt.so.0
7 0x00007f66e6e09a5d in virConsoleHashEntryFree () from/usr/lib64/libvirt.so.0
8 0x00007f66e6db7282 in virHashRemoveEntry () from/usr/lib64/libvirt.so.0
9 0x00007f66e6e09c4e in virConsoleOpen () from /usr/lib64/libvirt.so.0
10 0x00000000004526e9 in qemuDomainOpenConsole ()
11 0x00007f66e6e421f1 in virDomainOpenConsole () from/usr/lib64/libvirt.so.0
12 0x00000000004361e4 in remoteDispatchDomainOpenConsoleHelper ()
13 0x00007f66e6e80375 in virNetServerProgramDispatch () from/usr/lib64/libvirt.so.0
14 0x00007f66e6e7ae11 in virNetServerHandleJob () from/usr/lib64/libvirt.so.0
15 0x00007f66e6da897d in virThreadPoolWorker () from/usr/lib64/libvirt.so.0
16 0x00007f66e6da7ff6 in virThreadHelper () from/usr/lib64/libvirt.so.0
17 0x00007f66e5aa0c5c in start_thread () from /lib64/libpthread.so.0
18 0x00007f66e57e7fcd in clone () from /lib64/libc.so.6
* src/qemu/qemu_driver.c: qemuDomainOpenConsole()
-- unlock the qemu driver right after acquiring the domain
object
(cherry picked from commit 3d3de46a6772baabb6c203a7961a790af6e8d08c)
Peter Krempa [Tue, 10 Apr 2012 10:21:03 +0000 (12:21 +0200)]
virsh: Clarify use of the --managed-save flag for the list command
The documentation for the flag doesn't clearly state that the flag only
enhances the output and the user needs to specify other flags to list
inactive domains, that are enhanced by this flag.
(cherry picked from commit cc5100654b2aff0933ab4aa447a71bfd7ddbf2bd)
Stefan Berger [Tue, 10 Apr 2012 10:24:03 +0000 (06:24 -0400)]
Fix compilation error on 32bit
Below code failed to compile on a 32 bit machine with error
typewrappers.c: In function 'libvirt_intUnwrap':
typewrappers.c:135:5: error: logical 'and' of mutually exclusive tests is always false [-Werror=logical-op]
cc1: all warnings being treated as errors
Eric Blake [Thu, 5 Apr 2012 19:15:03 +0000 (13:15 -0600)]
snapshot: fix memory leak on error
Leak introduced in commit 0436d32. If we allocate an actions array,
but fail early enough to never consume it with the qemu monitor
transaction call, we leaked memory.
But our semantics of making the transaction command free the caller's
memory is awkward; avoiding the memory leak requires making every
intermediate function in the call chain check for error. It is much
easier to fix things so that the function that allocates also frees,
while the call chain leaves the caller's data intact. To do that,
I had to hack our JSON data structure to make it easy to protect a
portion of an arbitrary JSON tree from being freed.
* src/util/json.h (virJSONType): Name the enum.
(_virJSONValue): New field.
* src/util/json.c (virJSONValueFree): Use it to protect a portion
of an array.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONTransaction): Avoid
freeing caller's data.
* src/qemu/qemu_driver.c (qemuDomainSnapshotCreateDiskActive):
Free actions array on failure.
(cherry picked from commit 1413560966eb07732b56dc2b83215462533656e5)
We can tell qemuDomainSnapshotFSThaw if we want it to report errors or
not. However, if we don't want to and an error has been already set by
previous qemuReportError() we must keep copy of that error not just a
pointer to it. Otherwise, it get overwritten if FSThaw reports an error.
(cherry picked from commit 650da0e99c56f4142273f4e369ad02bd0c008765)
Laine Stump [Thu, 5 Apr 2012 20:31:36 +0000 (16:31 -0400)]
test: fix build errors with gcc 4.7.0 and -O0
When building on Fedora 17 (which uses gcc 4.7.0) with -O0 in CFLAGS,
three of the tests failed to compile.
cputest.c and qemuxml2argvtest.c had non-static structs defined
inside the macro that was being repeatedly invoked. Due to some so-far
unidentified change in gcc, the stack space used by variables defined
inside { } is not recovered/re-used when the block ends, so all these
structs have become additive (this is the same problem worked around
in commit cf57d345b). Fortunately, these two files could be fixed with
a single line addition of "static" to the struct definition in the
macro.
virnettlscontexttest.c was a bit different, though. The problem structs
in the do/while loop of macros had non-constant initializers, so it
took a bit more work and piecemeal initialization instead of member
initialization to get things to be happy.
In an ideal world, none of these changes should be necessary, but not
knowing how long it will be until the gcc regressions are fixed, and
since the code is just as correct after this patch as before, it makes
sense to fix libvirt's build for -O0 while also reporting the gcc
problem.
(cherry picked from commit 06a1a45cef57eb770069839e98a51bbb6d8eec9d)
Laine Stump [Thu, 5 Apr 2012 07:18:33 +0000 (03:18 -0400)]
test: fix segfault in networkxml2argvtest
This bug resolves https://bugzilla.redhat.com/show_bug.cgi?id=810100
rpm builds for i686 were failing with a segfault in
networkxml2argvtest. Running under valgrind showed that a region of
memory was being referenced after it had been freed (as the result of
realloc - see the valgrind report in the BZ).
The problem (in replaceTokens() - added in commit 22ec60, meaning this
bug was in 0.9.10 and 0.9.11) was that the pointers token_start and
token_end were being computed based on the value of *buf, then *buf
was being realloc'ed (potentially moving it), then token_start and
token_end were used without recomputing them to account for movement
of *buf.
The solution is to change the code so that token_start and token_end
are offsets into *buf rather than pointers. This way there is only a
single pointer to the buffer, and nothing needs readjusting after a
realloc. (You may note that some uses of token_start/token_end didn't
need to be changed to add in "*buf +" - that's because there ended up
being a +*buf and -*buf which canceled each other out).
% make && make -C tests check TESTS=qemuxml2argvtest
% cd tests && valgrind -v --leak-check=full ./qemuxml2argvtest
actual result:
==2143== 12 bytes in 2 blocks are definitely lost in loss record 74 of 179
==2143== at 0x4A05FDE: malloc (vg_replace_malloc.c:236)
==2143== by 0x39D90A67DD: xmlStrndup (xmlstring.c:45)
==2143== by 0x4F5EC0: virDomainDiskDefParseXML (domain_conf.c:3438)
==2143== by 0x502F00: virDomainDefParseXML (domain_conf.c:8304)
==2143== by 0x505FE3: virDomainDefParseNode (domain_conf.c:9080)
==2143== by 0x5069AE: virDomainDefParse (domain_conf.c:9030)
==2143== by 0x41CBF4: testCompareXMLToArgvHelper (qemuxml2argvtest.c:105)
==2143== by 0x41E5DD: virtTestRun (testutils.c:145)
==2143== by 0x416FA3: mymain (qemuxml2argvtest.c:399)
==2143== by 0x41DCB7: virtTestMain (testutils.c:700)
==2143== by 0x39CF01ECDC: (below main) (libc-start.c:226)
Basically, openvz dropped strict version numbering (3.1 vs 3.1.0),
which caused parsing to fail.
(cherry picked from commit 37075dfe6ccdb5a257cdd64194b5fdd51458fa8b)
* configure.ac: Set WITH_SYSCTL only on Linux hosts
* daemon/Makefile.am: Conditionalize install-sysctl using WITH_SYSCTL
Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Cc: Jason Helfman <jhelfman@e-e.com>
(cherry picked from commit e7eca6e4be5175ec127a4327462b4374953b9bc5)
Every now & then, with parallel builds, we get a failure to
validate hvsupport.html.in. I eventually noticed that this
is because we get 2 instances of the generator running at
once.
We already list hvsupport.html.in in BUILT_SOURCES but this
was not working. It turns out the flaw is that we were
adding deps to the 'all:' target instead of the 'all-am:'
target. BUILT_SOURCES is a dep of 'all', so any custom
targets written in Makefile.am must use 'all-am:' so that
they don't get run until BUILT_SOURCES are completely
generated
Some of the test suites use fprintf with format specifiers
that are not supported on Win32 and are not fixed by gnulib.
The mingw32 compiler also has trouble detecting ssize_t
correctly, complaining that 'ssize_t' does not match
'signed size_t' (which it expects for %zd). Force the
cast to size_t to avoid this problem
* tests/testutils.c, tests/testutils.h: Fix printf
annotation on virTestResult. Use virVasprintf
instead of vfprintf
* tests/virhashtest.c: Use VIR_WARN instead of fprintf(stderr).
Cast to size_t to avoid mingw32 compiler bug
Michal Privoznik [Mon, 26 Mar 2012 14:44:19 +0000 (16:44 +0200)]
qemu: Build activeUsbHostdevs list on process reconnect
If the daemon is restarted it will lose list of active
USB devices assigned to active domains. Therefore we need
to rebuild this list on qemuProcessReconnect().
(cherry picked from commit ea3bc548aca7b4c448b48863120ad35a7337c127)
Michal Privoznik [Mon, 26 Mar 2012 14:40:01 +0000 (16:40 +0200)]
qemu: Delete USB devices used by domain on stop
To prevent assigning one USB device to two domains,
we keep a list of assigned USB devices. On domain
startup - qemuProcessStart() - we insert devices
used by domain into the list but remove them only
on detach-device. Devices are, however, released
on qemuProcessStop() as well.
(cherry picked from commit e2f5dd6134ebeb6846450c7d7782273d3d274859)
Void elements should be written with slash *after* the tag name,
not before, so they are not confused with ending tags.
(cherry picked from commit ae277e4ec262c37b85589ae0cd4191f9c9fb2872)
Currently, we put no strains on escape sequence possibly leaving users
with console that cannot be terminated. However, not all ASCII
characters can be used as escape sequence. Only those falling in
@ - _ can be; implement and document this constraint.
(cherry picked from commit 7960ce842b4188fd49a87ddd39b7ab7549228e1d)
Daniel Veillard [Tue, 3 Apr 2012 07:06:37 +0000 (15:06 +0800)]
Release of libvirt 0.9.11
* configure.ac docs/news.html.in libvirt.spec.in: update for the release
* po/*.po*: updated a number of languages translation including new
indian languages and regenerated
qemu: Start nested job in qemuDomainCheckEjectableMedia
Originally, qemuDomainCheckEjectableMedia was entering monitor with qemu
driver lock. Commit 2067e31bf97667eab9f111b496f5e9a44e827c5b, which I
made to fix that, revealed another issue we had (but didn't notice it
since the driver was locked): we didn't set nested job when
qemuDomainCheckEjectableMedia is called during migration. Thus the
original fix I made was wrong.
Philipp Hahn [Wed, 8 Feb 2012 16:32:34 +0000 (17:32 +0100)]
Xen: Fix <clock> handling
XenD-3.1 introduced managed domains. HV-domains have rtc_timeoffset
(hgd24f37b31030 from 2007-04-03), which tracks the offset between the
hypervisors clock and the domains RTC, and is persisted by XenD.
In combination with localtime=1 this had a bug until XenD-3.4
(hg5d701be7c37b from 2009-04-01) (I'm not 100% sure how that bug
manifests, but at least for me in TZ=Europe/Berlin I see the previous
offset relative to utc being applied to localtime again, which manifests
in an extra hour being added)
XenD implements the following variants for clock/@offset:
- PV domains don't have a RTC → 'localtime' | 'utc'
- <3.1: no managed domains → 'localtime' | 'utc'
- ≥3.1: the offset is tracked for HV → 'variable'
due to the localtime=1 bug → 'localtime' | 'utc'
- ≥3.4: the offset is tracked for HV → 'variable'
Current libvirtd still thinks XenD only implements <clock offset='utc'/>
and <clock offset='localtime'/>, which is wrong, since the semantic of
'utc' and 'localtime' specifies, that the offset will be reset on
domain-restart, while with 'variable' the offset is kept. (keeping the
offset over "virsh edit" is important, since otherwise the clock might
jump, which confuses certain guest OSs)
xendConfigVersion was last incremented to 4 by the xen-folks for
xen-3.1.0. I know of no way to reliably detect the version of XenD
(user space tools), which may be different from the version of the
hypervisor (kernel) version! Because of this only the change from
'utc'/'localtime' to 'variable' in XenD-3.1 is handled, not the buggy
behaviour of XenD-3.1 until XenD-3.4.
For backward compatibility with previous versions of libvirt Xen-HV
still accepts 'utc' and 'localtime', but they are returned as 'variable'
on the next read-back from Xend to libvirt, since this is what XenD
implements: The RTC is NOT reset back to the specified time on next
restart, but the previous offset is kept.
This behaviour can be turned off by adding the additional attribute
adjustment='reset', in which case libvirt will report an error instead
of doing the conversion. The attribute can also be used as a shortcut to
offset='variable' with basis='...'.
With these changes, it is also necessary to adjust the xen tests:
"localtime = 0" is always inserted, because otherwise on updates the
value is not changed within XenD.
adjustment='reset' is inserted for all cases, since they're all <
XEND_CONFIG_VERSION_3_1_0, only 3.1 introduced persistent
rtc_timeoffset.
Some statements change their order because code was moved around.
Philipp Hahn [Mon, 6 Feb 2012 13:59:16 +0000 (14:59 +0100)]
Support clock=variable relative to localtime
Since Xen 3.1 the clock=variable semantic is supported. In addition to
qemu/kvm Xen also knows about a variant where the offset is relative to
'localtime' instead of 'utc'.
Extends the libvirt structure with a flag 'basis' to specify, if the
offset is relative to 'localtime' or 'utc'.
Extends the libvirt structure with a flag 'reset' to force the reset
behaviour of 'localtime' and 'utc'; this is needed for backward
compatibility with previous versions of libvirt, since they report
incorrect XML.
Adapt the only user 'qemu' to the new name.
Extend the RelaxNG schema accordingly.
Document the new 'basis' attribute in the HTML documentation.
Adapt test for the new attribute.
The leak is really in virProcessInfoGetAffinity, as shown in the
valgrind output given in the above bug report - it calls CPU_ALLOC(),
but then fails to call CPU_FREE().
This leak has existed in every version of libvirt since 0.7.5.
Eric Blake [Fri, 30 Mar 2012 20:45:48 +0000 (14:45 -0600)]
conf: allow fuzz in XML with cur balloon > max
Commit 1b1402b introduced a regression. Since older libvirt versions
would silently round memory up (until the previous patch), but populated
current memory based on querying the guest, it was possible to have
dumpxml show cur > max by the amount of the rounding. For example, if
a user requested 1048570 KiB memory (just shy of 1GiB), the qemu
driver would actually run with 1048576 KiB, and libvirt 0.9.10 would
output a current that was 6KiB larger than the maximum. Situations
where this could have an impact include, but are not limited to,
migration from old to new libvirt, managedsave in old libvirt and
start in new libvirt, snapshot creation in old libvirt and revert in
new libvirt - without this patch, the new libvirt would reject the
VM because of the rounding discrepancy.
Fix things by adding a fuzz factor, and silently clamp current down to
maximum in that case, rather than failing to reparse XML for an existing
VM. From a practical standpoint, this has no user impact: 'virsh
dumpxml' will continue to query the running guest rather than rely on
the incoming xml, which will see the currect current value, and even if
clamping down occurs during parsing, it will be by at most the fuzz
factor of a megabyte alignment, and rounded back up when passed back to
the hypervisor.
Meanwhile, we continue to reject cur > max if the difference is beyond
the fuzz factor of nearest megabyte. But this is not a real change in
behavior, since with 0.9.10, even though the parser allowed it, later
in the processing stream we would reject it at the qemu layer; so
rejecting it in the parser just moves error detection to a nicer place.
* src/conf/domain_conf.c (virDomainDefParseXML): Don't reject
existing XML.
Based on a report by Zhou Peng.
Eric Blake [Fri, 30 Mar 2012 15:40:09 +0000 (09:40 -0600)]
qemu: reflect any memory rounding back to xml
If we round up a user's memory request, we should update the XML
to reflect the actual value in use by the VM, rather than giving
an artificially small value back to the user.
* src/qemu/qemu_command.c (qemuBuildNumaArgStr)
(qemuBuildCommandLine): Reflect rounding back to XML.
since you get an unsigned comparison if at least one side is
unsigned, using the largest rank of the two sides; but on 32-bit
platforms, where unsigned long and unsigned int are the same size,
this comparison is always true and ends up converting negative
long_val into posigive unsigned int values, rather than rejecting
the negative value as we had originally intended (python longs
are unbounded size, and we don't want to do silent modulo
arithmetic when converting to C code).
Fix this by using direct comparisons, rather than casting.
Fix client only RPM build & other misc RPM problems
* libvirt.spec.in: Remove obsolete --with-remote-pid-file arg.
Add missing %{without_libxl} statement. Fix handling of docs
in client only build. Put systemtap files in -client RPM
instead of -daemon RPM
* examples/xml/nwfilter/Makefile.am: Don't install examples if
nwfilter is disabled.
There are a number of flaws with our packaging of the libvirtd
daemon:
- Installing 'libvirt' does not install 'qemu-kvm' or 'xen'
etc which are required to actually run the hypervisor in
question
- Installing 'libvirt' pulls in the default configuration
files which may not be wanted & cause problems if installed
inside a guest
- It is not possible to explicitly required all the peices
required to manage a specific hypervisor
This change takes the 'libvirt' RPM and and changes it thus
- libvirt: just a virtual package with dep on libvirt-daemon,
libvirt-daemon-config-network & libvirt-daemon-config-nwfilter
- libvirt-daemon: the libvirt daemon and related pieces
- libvirt-daemon-config-network: the default network config
- libvirt-daemon-config-nwfilter: the network filter configs
- libvirt-docs: the website HTML
We then introduce some more virtual (empty) packages
- libvirt-daemon-qemu: Deps on libvirt-daemon & 'qemu'
- libvirt-daemon-kvm: Deps on libvirt-daemon & 'qemu-kvm'
- libvirt-daemon-lxc: Deps on libvirt-daemon
- libvirt-daemon-uml: Deps on libvirt-daemon
- libvirt-daemon-xen: Deps on libvirt-daemon & 'xen'
- libvirt-qemu: Deps on libvirt-daemon-qemu & libvirt-daemon-config-{network,nwfilter}
- libvirt-kvm: Deps on libvirt-daemon-kvm & libvirt-daemon-config-{network,nwfilter}
- libvirt-lxc: Deps on libvirt-daemon-lxc & libvirt-daemon-config-{network,nwfilter}
- libvirt-uml: Deps on libvirt-daemon-uml & libvirt-daemon-config-{network,nwfilter}
- libvirt-xen: Deps on libvirt-daemon-xen & libvirt-daemon-config-network
My intent in the future is to turn on the driver modules by
default, at which time 'libvirt-daemon' will cease to include
any specific drivers, instead we'll get libvirt-daemon-driver-XXXX
packages for each driver. The libvirt-daemon-XXX packages will
then pull in each driver that they require.
It is recommended that applications required a locally installed
libvirtd daemon, use either 'Requires: libvirt-daemon-XXXX' or
'Requires: libvirt-XXX' and *not* "Requires: libvirt-daemon"
or 'Requires: libvirt'
Previously the only attribute of a network device that could be
modified by virUpdateDeviceFlags() ("virsh update-device") was the
link state; attempts to change any other attribute would log an error
and fail.
This patch adds recognition of a change in bridge device name, and
supports reconnecting the guest's interface to the new device.
Standard audit logs for detaching and attaching a network device are
also generated. Although the current auditing function doesn't log the
bridge being attached to, this will later be changed in a separate
patch.
Eric Blake [Fri, 30 Mar 2012 16:28:03 +0000 (10:28 -0600)]
build: fix mingw ssize_t, syntax check
We are so close to a release that we don't want to pull in a
gnulib submodule update and risk regressions, since there has
been a lot of other gnulib churn upstream. However, there are
a couple of gnulib issues that are worth fixing in isolation,
by applying local patches to gnulib.
There was an upstream gnulib bug in maint.mk that rendered most
of our syntax checks ineffective (and fixing it flushed out a
minor bug in our code):
https://lists.gnu.org/archive/html/bug-gnulib/2012-03/msg00194.html
There is still an upstream bug where gnulib uses the wrong type
for ssize_t on mingw; we need the fix now even though it has not
yet been accepted into gnulib:
https://lists.gnu.org/archive/html/bug-gnulib/2012-03/msg00188.html
* gnulib/local/top/maint.mk.diff: Pick up upstream gnulib
maint.mk.
* gnulib/local/m4/ssize_t.m4.diff: Work around gnulib bug.
* src/libvirt.c: Remove unused header.
* cfg.mk
(exclude_file_name_regexp--sc_prohibit_empty_lines_at_EOF): Exempt
gnulib local files.
Laine Stump [Wed, 28 Mar 2012 17:06:37 +0000 (13:06 -0400)]
qemu: eliminate nested switch, simplify code
qemuBuildHostNetStr had a switch-within-a-switch where both were
looking at the same variable. This was apparently to take advantage of
code common to three different cases (while also taking care of some
code that was different). However, there were only 2 lines common to
all, one of those can be eliminated by merging it into the
virAsprintfs that are in each case. On top of that, all the extra
empty cases cause Coverity complaints (because they are unreachable),
but absence of the empty cases causes a compile error due to
"enumeration value not handled in switch".
The solution is to just make each toplevel case independent, folding
in the common code to each.
Laine Stump [Fri, 30 Mar 2012 07:16:23 +0000 (03:16 -0400)]
qemu: set default name for SPICE agent channel when generating command
commit b0e2bb33 set a default value for the SPICE agent channel by
inserting it during parsing of the channel XML. That method of setting
a default is problematic because it makes a format/parse roundtrip
unclean, and experience with setting other values as a side effect of
parsing has led to headaches (e.g. automatically setting a MAC address
in the parser when one isn't specified in the input XML).
This patch does not revert commit b0e2bb33 (it will be reverted in a
separate patch) but adds the alternate implementation of simply
inserting the default value in the appropriate place on the qemu
commandline when no value is provided.
qemu_agent: Issue guest-sync prior to every command
If we issue guest command and GA is not running, the issuing thread
will block endlessly. We can check for GA presence by issuing
guest-sync with unique ID (timestamp). We don't want to issue real
command as even if GA is not running, once it is started, it process
all commands written to GA socket.
Michal Privoznik [Fri, 30 Mar 2012 11:37:13 +0000 (13:37 +0200)]
virnetdevtap: Don't check for flags in virNetDevTapCreateFlags
With latest gnulib we are checking even the lowest level functions
whether they check flags. Moreover, we are shadowing the real error
on system without TUNSETIFF support.
The commandhelper.c & ssh.c programs rely on various APIs not present
on Win32. Disable them, since the tests that uses these helpers are
already disabled
* tests/commandhelper.c, tests/ssh.c: Disable on WIN32
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Wen Congyang [Fri, 30 Mar 2012 06:21:49 +0000 (14:21 +0800)]
fix a deadlock when qemu cannot start
When qemu cannot start, we may call qemuProcessStop() twice.
We have check whether the vm is running at the beginning of
qemuProcessStop() to avoid libvirt deadlock. We call
qemuProcessStop() with driver and vm locked. It seems that
we can avoid libvirt deadlock. But unfortunately we may
unlock driver and vm in the function qemuProcessKill() while
vm->def->id is not -1. So qemuProcessStop() will be run twice,
and monitor will be freed unexpectedly. So we should set
vm->def->id to -1 at the beginning of qemuProcessStop().
qemu: Make migration fail when port profile association fails on the dst host
In the current V3 migration protocol, Libvirt does not
check the result of the function
qemuMigrationVPAssociatePortProfiles
This means that it is possible for a migration to complete
successfully even when the VM loses network connectivity on
the destination host.
With this change libvirt aborts the migration
(during the "finish" step) when the above function fails, that
is to say when at least one of the port profile associations fails.
Signed-off by: Christian Benvenuti <benve@cisco.com>
libvirt documentation for channels with type 'spicevmc' says that the
'target' child node has:
"an optional attribute name controls how the guest will have access
to the channel, and defaults to name='com.redhat.spice.0'."
However, this default value is never set in libvirt code base,
there's only a check in qemu_command.c to error out if the name
attribute doesn't have the expected value (if it's set).
This commit sets a default target name for spicevmc channels during
the domain configuration parsing so that the code agrees with the
documentation.
Fixing memory leaks, in addition, the patch also fixes a potential missing
return value issue in 'if (from)' statement, without the fixing, although
the programming met a error, the subsequent codes will be executed
continually.
* tools/virsh.c (cmdSnapshotList): fix memory leaks and missing return value.
actual result:
error: --roots and --from are mutually exclusive
Name Creation Time State
------------------------------------------------------------
libvirt 2012-03-28 13:46:51 +0800 running
Guannan Ren [Tue, 27 Mar 2012 06:06:10 +0000 (14:06 +0800)]
python: Add new helper functions for python to C integral conversion
int libvirt_intUnwrap(PyObject *obj, int *val);
int libvirt_uintUnwrap(PyObject *obj, unsigned int *val);
int libvirt_longUnwrap(PyObject *obj, long *val);
int libvirt_ulongUnwrap(PyObject *obj, unsigned long *val);
int libvirt_longlongUnwrap(PyObject *obj, long long *val);
int libvirt_ulonglongUnwrap(PyObject *obj, unsigned long long *val);
int libvirt_doubleUnwrap(PyObject *obj, double *val);
int libvirt_boolUnwrap(PyObject *obj, bool *val);
Enable all warnings permanently & default to -Werror for GIT builds
Given that we auto-detect whether each -Wxxxx flag is supported by
GCC, and we are warning-free and use automake silent rules, there
is no compelling reason to allow compile warnings to be disabled.
Replace the --enable-compile-warnings flag with a simpler
--enable-werror flag, which defaults to 'yes' if building
from GIT, or 'no' if building from tar.gz
This helps ensure that everyone writing patches for libvirt will
take care to fix their warning problems before submitting for
review
* autobuild.sh: Force -Werror
* configure.ac: Update for LIBVIRT_COMPILE_WARNINGS macro change
* m4/virt-compile-warnings.m4: Permanently enable all warnings,
auto-enable Werror for GIT builds
Enable build of test suite programs by default for GIT checkouts
Add a new flag '--with-test-suite' to configure to control whether
the test suite binaries are built by default. ie built with a
plain 'make', as opposed to delayed until 'make check'
For builds from tar.gz tests will not be built by default. For
builds from GIT, tests with be on by default, to try and ensure
that patch developers don't accidentally break the test suites
without noticing.
* configure.ac: Add --with-test-suite
* tests/Makefile.am: Use noinst_PROGRAMS instead of check_PROGRAMS
if building tests by default. Consolidate setting of TESTS and
{noinst,check}_PROGRAMS to avoid duplication
Stef Walter [Tue, 27 Mar 2012 14:20:54 +0000 (16:20 +0200)]
Change the default of mdns_adv to false
* Don't advertise information on the network without consent of
the user, either through manual configuration, or a user
interface that drives this option.
* Since libvirtd must be configured for network access anyway
(for all but ssh), this setting was not useful "out of the box",
so changing this default setting does not remove "out of the box"
functionality.
Eric Blake [Tue, 27 Mar 2012 14:33:23 +0000 (08:33 -0600)]
snapshot: don't pass NULL to QMP command creation
Commit d42a2ff caused a regression in creating a disk-only snapshot
of a qcow2 disk; by passing the wrong variable to the monitor call,
libvirt ended up creating JSON that looked like "format":null instead
of the intended "format":"qcow2".
To make it easier to diagnose this in the future, make JSON creation
error out if "s:arg" is paired with NULL (it is still possible to
use "n:arg" in the rare cases where qemu will accept a null).
projects / thirdparty / libvirt.git / log
