https://bugzilla.redhat.com/show_bug.cgi?id=947387

If a user configures a domain to use a seclabel of a specific type,
but the appropriate driver is not accessible, we should refuse to
start the domain. For instance, if user requires selinux, but it is
either non present in the system, or is just disabled, we should not
start the domain. Moreover, since we are touching only those labels we
have a security driver for, the other labels may confuse libvirt when
reconnecting to a domain on libvirtd restart. In our selinux example,
when starting up a domain, missing security label is okay, as we
auto-generate one. But later, when libvirt is re-connecting to a live
qemu instance, we parse a state XML, where security label is required
and it is an error if missing:

  error : virSecurityLabelDefParseXML:3228 : XML error: security label
  is missing

This results in a qemu process left behind without any libvirt control.

virsh schedinfo was able to set only one parameter at a time (not
counting the deprecated options), but it is useful to set more at
once, so this patch adds the possibility to do stuff like this:

virsh schedinfo <domain> cpu_shares=0 vcpu_period=0 vcpu_quota=0 \
emulator_period=0 emulator_quota=0

Invalid scheduler options are reported as well.  These were previously
reported only if the command hadn't updated any values (when
cmdSchedInfoUpdate returned 0).

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=810078
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=919372
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=919375

Mimic the fix done in 02b90972 to fix crash by
accessing an already freed structure. Also copy the explaining comment why the
pointer can't be accessed any more.

https://bugzilla.redhat.com/show_bug.cgi?id=928197

The virsh domfstrim command was not freeing allocated domain,
leaving leaked references behind.

Descriptions for vol-download and vol-upload didn't make much sense.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=923613

The virsh(1) man page wasn't saying anything about the 'migrateuri'
parameter other than it can be usually omitted.  A patched version of
docs/migrate.html.in is taken in this patch to fix that up in the man
page.

Use the established approach to improve this function too.

Use the established approach to improve this function too.

Use the established approach to improve this function too.

The man page states that with --config the next boot is affected. This
can be understood as if _only_ the next boot was affected. This isn't
true if the machine is running.

This patch adds the full --live, --config, --current infrastructure and
tweaks stuff to correctly support the obsolete --persistent flag.

Note that this patch changes the the behavior of the --config flag to match the
use of this flag in rest of libvirt. This flag was mistakenly renamed from
--persistent that originaly had different semantics.

The parameter options can be declared directly.

Also use macros for mutual exclusion on some of the incompatible
parameter variables.

This patch uses the new helper to avoid the more complex check for
domain state modification flags.

The domif-getlink command did not terminate successfully when the
interface state was found. As the code used old and too complex approach
to do the job, this patch refactors it and fixes the bug.

Format the address using the helper instead of having similar code in
multiple places.

This patch also fixes leak of the MAC address string in
ebtablesRemoveForwardAllowIn() and ebtablesAddForwardAllowIn() in
src/util/virebtables.c

The domain XML generator creates the mac addres strings with lowercase
strings with a separate piece of code. This patch changes the formating
helper to do the same stuff to allow using it to normalize a string
provided by the user. After this change some of the tests that are
outputing the mac address will need to be changed.

Currently, -machine option is used only when dump-guest-core is set.

To use options defined in machine option for newer version of QEMU,
it needs to use -machine xxx, and to be compatible with older version
-M, this patch adds QEMU_CAPS_MACHINE_OPT capability for newer
version which supports -machine option.
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

The limits are documented at
http://libvirt.org/formatdomain.html#elementsCPUTuning . Enforce them
when going through XML parsing in addition to being enforced by the API.

This is just a bare Easter Egg. Whenever a user runs virDomainScreenshot
over a domain in test driver, he'll get the Libvirt PNG logo in return.

Reported by Anthony Messina in
https://bugzilla.redhat.com/show_bug.cgi?id=904692
Present since introduction of smartcard support in commit f5fd9baa

* src/qemu/qemu_command.c (qemuBuildCommandLine): Match qemu spelling.
* tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.args:
Fix broken test.

Allow migration over IPv6 by listening on [::] instead of 0.0.0.0
when QEMU supports it (QEMU_CAPS_IPV6_MIGRATION) and there is
at least one v6 address configured on the system.

Use virURIParse in qemuMigrationPrepareDirect to allow parsing
IPv6 addresses, which would cause an 'incorrect :port' error
message before.

Move setting of migrateFrom from qemuMigrationPrepare{Direct,Tunnel}
after domain XML parsing, since we need the QEMU binary path from it
to get its capabilities.

Bug: https://bugzilla.redhat.com/show_bug.cgi?id=846013

The 'virsh vcpupin' and 'virsh emulatorpin' commands use the same
code to parse the cpulist. This patch abstracts the same code as
a helper. Along with various code style fixes, and error improvement
(only error "Physical CPU %d doesn't exist" if the specified CPU
exceed the range, no "cpulist: Invalid format", see the following
for an example of the error prior to this patch).

% virsh vcpupin 4 0 0-8
error: Physical CPU 4 doesn't exist.
error: cpulist: Invalid format.

Code added by commit id '523207fe'

TEST: qemuxml2argvtest
      ........................................ 40
      ........................................ 80
      ........................................ 120
      ........................................ 160
      ........................................ 200
      ........................................ 240
      .................................        273 OK
==30993== 39 bytes in 1 blocks are definitely lost in loss record 33 of 87
==30993==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==30993==    by 0x41E501: fakeSecretGetValue (qemuxml2argvtest.c:33)
==30993==    by 0x427591: qemuBuildDriveURIString (qemu_command.c:2571)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==    by 0x4204CA: virtTestMain (testutils.c:719)
==30993==    by 0x38D6821A04: (below main) (in /usr/lib64/libc-2.16.so)
==30993==
==30993== 46 bytes in 1 blocks are definitely lost in loss record 64 of 87
==30993==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==30993==    by 0x38D690A167: __vasprintf_chk (in /usr/lib64/libc-2.16.so)
==30993==    by 0x4CB28E7: virVasprintf (stdio2.h:210)
==30993==    by 0x4CB29A3: virAsprintf (virutil.c:2017)
==30993==    by 0x4275B4: qemuBuildDriveURIString (qemu_command.c:2580)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==    by 0x4204CA: virtTestMain (testutils.c:719)
==30993==    by 0x38D6821A04: (below main) (in /usr/lib64/libc-2.16.so)
==30993==
==30993== 385 (56 direct, 329 indirect) bytes in 1 blocks are definitely los
==30993==    at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==30993==    by 0x4C6B2CF: virAllocN (viralloc.c:152)
==30993==    by 0x4C9C7EB: virObjectNew (virobject.c:191)
==30993==    by 0x4D21810: virGetSecret (datatypes.c:642)
==30993==    by 0x41E5D5: fakeSecretLookupByUsage (qemuxml2argvtest.c:51)
==30993==    by 0x4D4BEC5: virSecretLookupByUsage (libvirt.c:15295)
==30993==    by 0x4276A9: qemuBuildDriveURIString (qemu_command.c:2565)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==
PASS: qemuxml2argvtest

Interesting side note is that running the test singularly via 'make -C tests
check TESTS=qemuxml2argvtest' didn't trip the valgrind error; however,
running during 'make -C tests valgrind' did cause the error to be seen.

- configure.ac docs/news.html.in libvirt.spec.in: updates for the release
- po/*.po*: fetch translation updates from Transifex and regenerate

Since the refactoring in fbe2d494 we call virSecretFree even if
virSecretDefineXML fails, which leads to overwriting the error
message with:
error: Invalid secret: virSecretFree

Bug: https://bugzilla.redhat.com/show_bug.cgi?id=929045

When logical pool has no PVs associated with itself (user-created),
virCommandFree(cmd) is called twice with the same pointer and that
causes a segfault in daemon.

Both virIsCapableFCHost and virIsCapableVport return 0 when the
respective sysfs path is accessible.

With my previous patches, we unconditionally appended a seclabel,
even if it wasn't generated but found in array of defined seclabels.
This resulted in double free later when doing virDomainDefFree
and iterating over the array of defined seclabels.

Moreover, there was another possibility of double free, if the
seclabel was generated in the last iteration of the process of
walking trough security managers array.

There has been a typo in virIsCapbleVport function name.

---
Pushed under build-breaker rule.

One of my previous patches manipulated virSecurityLabel* APIs,
some were added to header files, and some were renamed. However,
these changes were not reflected in libvirt_private.syms.

https://bugzilla.redhat.com/show_bug.cgi?id=923946

The <seclabel type='none'/> should be added iff there is no other
seclabel defined within a domain. This bug can be easily reproduced:
1) configure selinux seclabel for a domain
2) disable system's selinux and restart libvirtd
3) observe <seclabel type='none'/> being appended to a domain on its
   startup

The virDomainDefGetSecurityLabelDef was modifying the domain XML.
It tried to find a seclabel corresponding to given sec driver. If the
label wasn't found, the function created one which is wrong. In fact
it's security manager which should modify this part of domain XML.

When libvirtd loads active network configs from network state directory,
it should release the class_id memory block which was allocated
at the time of loading xml from network config directory.
virBitmapParse will create a new memory block of bitmap class_id which
causes a memory leak.

This happens when at least one virtual network is active before.

==12234== 8,216 (24 direct, 8,192 indirect) bytes in 1 blocks are definitely \
              lost in loss record 702 of 709
==12234==    at 0x4A06B2F: calloc (vg_replace_malloc.c:593)
==12234==    by 0x37AB04D77D: virAlloc (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB04EF89: virBitmapNew (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB0BFB37: virNetworkAssignDef (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB0BFD31: ??? (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB0BFE92: virNetworkLoadAllConfigs (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x10650E5A: ??? (in /usr/lib64/libvirt/connection-driver/libvirt_driver_network.so)
==12234==    by 0x37AB0EB72F: virStateInitialize (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x40DE04: ??? (in /usr/sbin/libvirtd)
==12234==    by 0x37AB0832E8: ??? (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x3796807D14: start_thread (in /usr/lib64/libpthread-2.16.so)
==12234==    by 0x37960F246C: clone (in /usr/lib64/libc-2.16.so)

iptables-1.4.18 removed the long deprecated "state" match.
Use "conntrack" instead in forwarding rules.
Fixes openSUSE bug https://bugzilla.novell.com/811251 #811251.

Check function pointer before calling.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

Despite the comment stating virNetClientIncomingEvent handler should
never be called with either client->haveTheBuck or client->wantClose
set, there is a sequence of events that may lead to both booleans being
true when virNetClientIncomingEvent is called. However, when that
happens, we must not immediately close the socket as there are other
threads waiting for the buck and they would cause SIGSEGV once they are
woken up after the socket was closed. Another thing is we should clear
all remaining calls in the queue after closing the socket.

The situation that can lead to the crash involves three threads, one of
them running event loop and the other two calling libvirt APIs. The
event loop thread detects an event on client->sock and calls
virNetClientIncomingEvent handler. But before the handler gets a chance
to lock client, the other two threads (T1 and T2) start calling some
APIs. T1 gets the buck and detects EOF on client->sock while processing
its RPC call. Since T2 is waiting for its own call, T1 passes the buck
on to it and unlocks client. But before T2 gets the signal, the event
loop thread wakes up, does its job and closes client->sock. The crash
happens when T2 actually wakes up and tries to do its job using a closed
client->sock.

When we write a log message into a log, we separate thread ID from
timestamp using ": ". However, when storing the message into the ring
buffer, we omitted the separator, e.g.:

    2013-02-27 11:49:11.852+00003745: ...