When generating docs in a VPATH build we get a failure to
create a file due to the 'internals' subdir not existing:

  Generating internals/locking.html.tmp
  /bin/sh: line 3: internals/locking.html.tmp: No such file or directory
  rm: cannot remove ‘internals/locking.html.tmp’: No such file or directory
  Makefile:2229: recipe for target 'internals/locking.html.tmp' failed
  make: *** [internals/locking.html.tmp] Error 1

For some reason, make has decided to run the target

  %.html.tmp: %.html.in site.xsl page.xsl sitemap.html.in $(acl_generated)

instead of the target

  internals/%.html.tmp: internals/%.html.in subsite.xsl page.xsl sitemap.html.in

Removing '$(acl_generated)' from the first target, inexplicably
causes make to now run the correct target for the internals/
files.

Rather than figure this out, lets just combine the two targets
into one.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Instead of nested ifs, jump out early.

Mostly whitespace changes.

We do not care if the mac was specified in the delete section,
we are going to delete the record anyway.

The comment is relevant to the ADD action, not DEL.

Introduce a function for printing the leases on the 'init' operation.

Introduce virLeaseReadCustomLeaseFile which will populate
the new leases array with all the leases, except for expired
ones and the ones matching 'ip_to_delete'.

This removes five variables from main().

We either use the value from the environment variable, or learn it from
the existing lease file.

In the second case, the pointer would be pointing into the JSON object
of the first lease with a DUID, owned by leases_array, then
leases_array_new.

Always allocate the string instead, making obvious who should free the
string.

If dnsmasq specified DNSMASQ_IAID (so we're dealing with an IPv6
lease) but no DNSMASQ_MAC, we skip creation of the new lease object.

Also skip adding it to the leases array.

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

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

In order to be able to process disk storage pool's using a multipath
device to handle the partitions, libvirt_parthelper will need a way to
not automatically add a partition separator "p" to the generated device
name for each partition found. This is designed to mimic the multipath
features known as 'user_friendly_names' and custom 'alias' name.

If the part_separator attribute is set to "no", then generation of the
multipath partition name will not include the "p" partition separator
unless the source device path name ends with a number. The generated
partition names that get passed back to libvirt are processed in order
to find the device mapper multipath (dm-#) path device.

For example, device path "/dev/mapper/mpatha" would create partitions
"/dev/mapper/mpatha1", "/dev/mapper/mpatha2", etc. instead of
"/dev/mapper/mpathap1", "/dev/mapper/mpathap2", etc. If the device
path ends with a number "/dev/mapper/mpatha1", then the algorithm
to generate names "/dev/mapper/mpatha1p1", "/dev/mapper/mpatha1p2", etc.
would be utilized.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add a new storage pool source device attribute 'part_separator=[yes|no]'
in order to allow a 'disk' storage pool using a device mapper multipath
device to not add the "p" partition separator to the generated device
name when libvirt_parthelper is run.

This will allow libvirt to find device mapper multipath devices which were
configured in /etc/multipath.conf to use 'user_friendly_names' or custom
'alias' names for the LUN.

Since we pass dummy variables @fdout and @fdoutlen into
virNetClientProgramCall() we make it alloc @fdout array (even
though it's an array of 0 elements since vitlogd can hardly pass
us some FDs at this stage). Nevertheless, it's an allocation not
followed by free():

==29385== 0 bytes in 60 blocks are definitely lost in loss record 2 of 1,009
==29385==    at 0x4C2C070: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==29385==    by 0x54B99EF: virAllocN (viralloc.c:191)
==29385==    by 0x56821B1: virNetClientProgramCall (virnetclientprogram.c:359)
==29385==    by 0x563B304: virLogManagerDomainReadLogFile (log_manager.c:272)
==29385==    by 0x217CD613: qemuDomainLogContextRead (qemu_domain.c:2485)
==29385==    by 0x217EDC76: qemuProcessReadLog (qemu_process.c:1660)
==29385==    by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696)
==29385==    by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957)
==29385==    by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955)
==29385==    by 0x217F71A4: qemuProcessStart (qemu_process.c:5152)
==29385==    by 0x21846582: qemuDomainObjStart (qemu_driver.c:7396)
==29385==    by 0x218467DE: qemuDomainCreateWithFlags (qemu_driver.c:7450)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So I can observe this crasher that with freshly started daemon
(and virtlogd enabled) I am trying to startup a domain that
immediately dies (because it's said to use huge pages but I
haven't allocated a single one in the pool). Hardly reproducible
with -O0 or under valgrind. But I just got lucky:

==20469== Invalid write of size 8
==20469==    at 0x4C2E99B: memcpy@GLIBC_2.2.5 (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20469==    by 0x217EDD07: qemuProcessReadLog (qemu_process.c:1670)
==20469==    by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696)
==20469==    by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957)
==20469==    by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955)
==20469==    by 0x217F71A4: qemuProcessStart (qemu_process.c:5152)
==20469==    by 0x21846582: qemuDomainObjStart (qemu_driver.c:7396)
==20469==    by 0x218467DE: qemuDomainCreateWithFlags (qemu_driver.c:7450)
==20469==    by 0x21846845: qemuDomainCreate (qemu_driver.c:7468)
==20469==    by 0x5611CD0: virDomainCreate (libvirt-domain.c:6753)
==20469==    by 0x125D9A: remoteDispatchDomainCreate (remote_dispatch.h:3613)
==20469==    by 0x125CB7: remoteDispatchDomainCreateHelper (remote_dispatch.h:3589)
==20469==  Address 0x27a52ad0 is 0 bytes after a block of size 5,584 alloc'd
==20469==    at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20469==    by 0x9B8D1DB: xdr_string (in /lib64/libc-2.21.so)
==20469==    by 0x563B39C: xdr_virLogManagerProtocolNonNullString (log_protocol.c:24)
==20469==    by 0x563B6B7: xdr_virLogManagerProtocolDomainReadLogFileRet (log_protocol.c:123)
==20469==    by 0x164B34: virNetMessageDecodePayload (virnetmessage.c:407)
==20469==    by 0x5682360: virNetClientProgramCall (virnetclientprogram.c:379)
==20469==    by 0x563B30E: virLogManagerDomainReadLogFile (log_manager.c:272)
==20469==    by 0x217CD613: qemuDomainLogContextRead (qemu_domain.c:2485)
==20469==    by 0x217EDC76: qemuProcessReadLog (qemu_process.c:1660)
==20469==    by 0x217EDE1D: qemuProcessReportLogError (qemu_process.c:1696)
==20469==    by 0x217EE8C1: qemuProcessWaitForMonitor (qemu_process.c:1957)
==20469==    by 0x217F6636: qemuProcessLaunch (qemu_process.c:4955)

This points to memmove() in qemuProcessReadLog(). Imagine we just
read the following string from qemu:

"abc\n2016-01-18T09:40:44.022744Z qemu-system-x86_64: Error\n"

After the first pass of the while() loop in the
qemuProcessReadLog() (in which we have taken the false branch in
the if) @buf still points to the beginning of the string,
@filter_next points to the beginning of the second line.  So we
start second iteration because there is yet another newline
character at the end. In this iteration @eol points to it
actually. Now, the control gets inside true branch of if(). Just
to remind you:

got = 58
filter_next = buf + 5,
eol = buf + 58.

Therefore skip = 54 which is correct. The message we want to skip
is 54 bytes long. However:

memmove(filter_next, eol + 1, (got - skip) +1);

which is

memmove(filter_next, eol + 1, 5)

is obviously wrong as there is only one byte we can access, not 5!
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When building with gcc-5 (particularly gcc-5.3.0 now) and having pdwtags
installed (package dwarves) make check fails with the following error:

  $ make lock_protocol-struct
  GEN      lock_protocol-struct
  --- lock_protocol-structs	2016-01-13 15:04:59.318809607 +0100
  +++ lock_protocol-struct-t3	2016-01-13 15:05:17.703501234 +0100
  @@ -26,10 +26,6 @@
           virLockSpaceProtocolNonNullString name;
           u_int                      flags;
   };
  -enum virLockSpaceProtocolAcquireResourceFlags {
  -        VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_SHARED = 1,
  -        VIR_LOCK_SPACE_PROTOCOL_ACQUIRE_RESOURCE_AUTOCREATE = 2,
  -};
   struct virLockSpaceProtocolAcquireResourceArgs {
           virLockSpaceProtocolNonNullString path;
           virLockSpaceProtocolNonNullString name;
  Makefile:10415: recipe for target 'lock_protocol-struct' failed
  make: *** [lock_protocol-struct] Error 1

That happens because without any specific options gcc doesn't keep enum
information in the resulting binary object.  I managed to isolate the
parameters of gcc that caused this issue to disappear, however I
remember that they influenced the resulting binaries quite a bit and
were definitely not something we would want to add as mandatory to the
build process.

So to deal with this cleanly, let's take that enum and separate it out
to its own header file.  Since it is only used in the lockd driver and
the protocol, lock_driver_lockd.h feels like a suitable name.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This was reported in bug #1298024 where r would be filled with the
return code of rbd_open().

Should rbd_snap_unprotect() fail for any reason the virReportSystemError
call would return 'Success' since rbd_open() succeeded.

https://bugzilla.redhat.com/show_bug.cgi?id=1298024Signed-off-by: NWido den Hollander <wido@widodh.nl>

In the commit aea47e48 we have fixed a single pointer within
driver structure. Since all callers pass statically allocated
driver on stack other pointers within driver may contain random
values too. Before touching it lets overwrite it with zeroes and
thus fix all dangling pointers.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It was only used in two instances, so get rid of it for
consistency's sake.

Now that the first release made in 2016 is out, we can move all
entries for 2015 to their own file, just like we did for all previous
years.

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: regenerated

A device tree binary file specified by /domain/os/dtb element is a
read-only resource similar to kernel and initrd files. We shouldn't
restore its label when destroying a domain to avoid breaking other
domains configure with the same device tree.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Kernel/initrd files are essentially read-only shareable images and thus
should be handled in the same way. We already use the appropriate label
for kernel/initrd files when starting a domain, but when a domain gets
destroyed we would remove the labels which would make other running
domains using the same files very unhappy.

https://bugzilla.redhat.com/show_bug.cgi?id=921135Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We have this function qemuAgentNotifyEvent() which is supposed to
be called from thread pool responsible for processing qemu
monitor events. The function then should wake up other thread
that is waiting for a guest to shutdown or reboot. However, if we
have received a different error a warning is printed out. This
warning lacks info on which event is expected.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit id '90b721e4' moved where the virCgroupAddTask was made until
after the check for the vcpupin checks. However, in doing so it missed
an option where if the cpumap didn't exist, then the code would continue
back to the top of the current vcpu loop. The results was that the
virCgroupAddTask wouldn't be called.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This reverts commit ae09988e.

Since commit id '71ce4759' has been reverted, this one is no
longer necessary.

This reverts commit 71ce4759.

Since commit id 'a41c00b4' has been reverted, this no longer is
necessary

This reverts commit a41c00b4.

After much testing and upstream discussion this has been deemed to be
the incorrect operation since it means we no longer have any guarantee
about which resource controllers the QEMU processes in general are in.

There is no need to deny writes on a readonly mount: write still
won't be accepted, even if the user remounts the folder as RW in
the guest as qemu sets the 9p mount as ro.

This deny rule was leading to problems for example with readonly /:
The qemu process had to write to a bunch of files in / like logs,
sockets, etc. This deny rule was also preventing auditing of these
denials, making it harder to debug.

Commit id '7bf3198d' neglected to initialize deflate leading to a
possibility if model allocation/checks fail, then the VIR_FREE(deflate)
would be erroneous. Noted by Jan Tomko.

In 50078cfb I've tried to fix distcheck but accidentally
broke rpm build. The problem is that rpm build not only sets
DESTDIR but also passes plugindir path. This results in double
DESTDIR being in the plugin path, Drop one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Mention that we run a command in that namespace

Even though the Makefile has WITH_WIRESHARK guards, the _SOURCES
variables are still processed when adding bits to the dist archive.

plugin.c is a generated file that is only built when wireshark is
enabled and it shouldn't be distributed, so use 'nodist'

So, you try to start a domain, but before we even get to the part
where chardev part of qemu command line is generated (and
possibly missing path to unix sockets is made up) an error occurs
which results in calling qemuProcessStop. This will then try to
clean up the mess and possibly ends up calling unlink(NULL).

==8085== Thread 3:
==8085== Syscall param unlink(pathname) points to unaddressable byte(s)
==8085==    at 0xA85EA57: unlink (in /lib64/libc-2.21.so)
==8085==    by 0x213D3C24: qemuProcessCleanupChardevDevice (qemu_process.c:2866)
==8085==    by 0x558D6B1: virDomainChrDefForeach (domain_conf.c:22924)
==8085==    by 0x213DA9AE: qemuProcessStop (qemu_process.c:5326)
==8085==    by 0x213DA2F2: qemuProcessStart (qemu_process.c:5190)
==8085==    by 0x2142957F: qemuDomainObjStart (qemu_driver.c:7396)
==8085==    by 0x214297DB: qemuDomainCreateWithFlags (qemu_driver.c:7450)
==8085==    by 0x21429842: qemuDomainCreate (qemu_driver.c:7468)
==8085==    by 0x5611B95: virDomainCreate (libvirt-domain.c:6753)
==8085==    by 0x125D9A: remoteDispatchDomainCreate (remote_dispatch.h:3613)
==8085==    by 0x125CB7: remoteDispatchDomainCreateHelper (remote_dispatch.h:3589)
==8085==    by 0x568BF41: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
==8085==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==8085==
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit ec63000a missed checking the return value of regcomp(),
which coverity promptly identified.

Like everything we install, it should be prefixed with DESTDIR.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commmit fd2e3c4c used the domctl version 8 structure for version 9
in the xen_getdomaininfolist union, resulting in insufficient buffer
size (and subsequent memory corruption) for the GETDOMAININFOLIST
ioctl.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

- Don't double check for expectName
- actual is always non-NULL by this point, so don't check it either

Just handle it all in tools/Makefile.am. I verified the generated output
looks similar to the pre patch output, but I didn't test it.

So after da176bf6 and friend we have switched to $(wildcard
some/path/*.xml) instead of enumerating the files explicitly.
This is nice, however it makes distcheck build from VPATH fail.
The reason is that it's is not obvious to what does the wildcard
refer to: srcdir or builddir?
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Autodeflate can be enabled/disabled for memballon device
of model 'virtio'.

xml:
<devices>
  <memballoon model='virtio' autodeflate='on'/>
</devices>

qemu:
qemu -device virtio-balloon-pci,...,deflate-on-oom=on

Autodeflate cannot be enabled/disabled for running domain.