The array doesn't necessarily have the same cardinality as the count of
vCPUs for a domain. Iterating it can cause access beyond the end of the
array.

Counterintuitively the user would end up with a VM with maximum number
of vCPUs available.

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

Next patch will add minimum checking, so use a more generic name.
Refactor return values to the commonly used semantics.

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

We are missing this value for cdrom-image device. It seems like
there's no added value to extend this to other types of disk
devices [1].

1: https://www.redhat.com/archives/libvir-list/2016-January/msg01038.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since 'savevm' was not converted to QMP libvirt has to parse for error
strings in the text monitor output. One of the unhandled errors is
produced when qemu treats a device as unmigratable.

As current qemu actually does support AHCI migration this bug is
applicable only to older versions of qemu.

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

Unify few error conditions into a single error reporting case.

Make bhyveload respect boot order as specified by os.boot section of the
domain XML or by "boot order" for specific devices. As bhyve does not
support a real boot order specification right now, it's just about
choosing a single device to boot from.

These functions are going to be used by the Bhyve driver.

libvirt always resets the MAC address of the physdev used for macvtap
passthrough when the guest is finished with it. This was happening
prior to the 802.1Qb[gh] DISASSOCIATE command, and was quite often
failing, presumably because the driver wouldn't allow the MAC address
to be reset while the association was still active, with a log message
like this:

virNetDevSetMAC:168 : Cannot set interface MAC to 00:00:00:00:00:00 on 'eth13': Cannot assign requested address

This patch changes the order - we now do the 802.1Qb[gh] disassociate
and delete the macvtap interface first, then and reset the MAC
address.

'free' on fedora23 wants to use the Slab field for calculated used
memory. The equation is:

used = MemTotal - MemFree - (Cached + Slab) - Buffers

We already set Cached and Buffers to 0, do the same for Slab and its
related values

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

'free' on Fedora 23 will use MemAvailable to calculate its 'available'
field, but we are passing through the host's value. Set it to match
MemFree, which is what 'free' will do for older linux that don't have
MemAvailable

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

We virtualize bits of /proc/meminfo by replacing host values with
values specific to the container.

However for calculating the final size of the returned data, we are
using the size of the original file and not the altered copy, which
could give garbelled output.

Reverse the conditional at the start so we aren't stuffing all the logic
in an 'if' block

... and consolidate the cmdline/extra/root parsing to facilitate doing
so.

The logic is the same as xl's parse_cmdline from the current xen.git master
branch (e6f0e099d2c17de47fd86e817b1998db903cab61).

On the formatting side switch to producing cmdline= instead of extra=.

Update a few tests and add serveral more.
  - test-cmdline is added to test the exclusive use of cmdline.
  - test-fullvirt-direct-kernel-boot.cfg is updated due to the switch
    on the formatting side and now tests the exclusive use of cmdline=.
  - Tests are added for both paravirt and fullvirt where the .cfg uses
    extra= and (paravirt only) root=. These are format (xl->xml) only
    since the inverse will generate cmdline= hence is not a round trip
    (which was already true if using root=, which used to generate
    extra= on the way back).
  - Tests are added for both paravirt and fullvirt where the .cfg
    declares cmdline= as well as bogus extra= and (paravirt only) root=
    entries which should be ignored. Again these are format only tests
    since the inverse won't include the bogus lines.

The last two bullets here required splitting the DO_TEST macro into
two halves, as is done in the xmconfigtest.c case.

In order to introduce a use of VIR_WARN for logging I had to add
virerror.h and VIR_LOG_INIT.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>

As suggested in a previous thread [0] this patch adds some missing calls
to libxl_dominfo_{init,dispose} when doing some of the libxl_domain_info
operations which would otherwise lead to memory leaks.

[0]
https://www.redhat.com/archives/libvir-list/2015-September/msg00519.htmlSigned-off-by: NJoao Martins <joao.m.martins@oracle.com>

Add "Xen XL Config" to the virErrorDomain enum and use it in
src/xenconfig/xen_xl.c.

The virErrorDomain enum has VIR_FROM_XEN, VIR_FROM_XEND,
VIR_FROM_XENSTORE, VIR_FROM_SEXPR, and VIR_FROM_XENXM. Use
these elements in the corresponding .c files. While at it,
remove the VIR_FROM_THIS define in src/xenconfig/xenxs_private.h.

The corresponding event in QEMU is called MIGRATION_PASS.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The VIR_DOMAIN_EVENT_ID_MIGRATION_ITERATION event will be triggered
whenever VIR_DOMAIN_JOB_MEMORY_ITERATION changes its value, i.e.,
whenever a new iteration over guest memory pages is started during
migration.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When acpi is used to reboot/shutdown qemu domain, qemu emits
SHUTDOWN event. Libvirt uses fakeReboot variable in order to
differentiate reboot or shutdown. fakeReboot value is reseted
to false after domain restart/reset.

When mode=agent is used to reboot qemu domain, qemu doesn't emit
SHUTDOWN event and libvirt doesn't reset fakeReboot value to false.
In this case next 'shutdown -h now' performs reboot. That's why
we don't need to set fakeReboot=true for mode=agent.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The generated output is dependent on perl hashtable ordering, which
gives different results for i686 and x86_64. Fix this by sorting
the hash keys before iterating over them

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

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>

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