When we get a POLLHUP or VIR_EVENT_HANDLE_HANGUP event for a client, we
still want to read from the socket to process any accumulated data. But
doing so inevitably results in an error and a call to
virNetClientMarkClose before we get to processing the hangup event (and
another call to virNetClientMarkClose). However the close reason passed
to the second virNetClientMarkClose call is ignored because another one
was already set. We need to pass the correct close reason when marking
the socket to be closed for the first time.

https://bugzilla.redhat.com/show_bug.cgi?id=1373859Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit 42faf316)

While fixing a bug with incorrectly freed memory in commit
v3.1.0-399-g5498aa29, I accidentally broke persistent migration of
transient domains. Before adding qemuDomainDefCopy in the path, the code
just took NULL from vm->newDef and used it as the persistent def, which
resulted in no persistent XML being sent in the migration cookie. This
scenario is perfectly valid and the destination correctly handles it by
using the incoming live definition and storing it as the persistent one.

After the mentioned commit libvirtd would just segfault in the described
scenario.

https://bugzilla.redhat.com/show_bug.cgi?id=1446205Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit 59307fad)

If we are encoding a block of data that is 16 bytes in length,
we cannot leave it as 16 bytes, we must pad it out to the next
block boundary, 32 bytes. Without this padding, the decoder will
incorrectly treat the last byte of plain text as the padding
length, as it can't distinguish padded from non-padded data.

The problem exhibited itself when using a 16 byte passphrase
for a LUKS volume

  $ virsh secret-set-value 55806c7d-8e93-456f-829b-607d8c198367 \
       $(echo -n 1234567812345678 | base64)
  Secret value set

  $ virsh start demo
  error: Failed to start domain demo
  error: internal error: process exited while connecting to monitor: >>>>>>>>>>Len 16
  2017-05-02T10:35:40.016390Z qemu-system-x86_64: -object \
    secret,id=virtio-disk1-luks-secret0,data=SEtNi5vDUeyseMKHwc1c1Q==,\
    keyid=masterKey0,iv=zm7apUB1A6dPcH53VW960Q==,format=base64: \
    Incorrect number of padding bytes (56) found on decrypted data

Notice how the padding '56' corresponds to the ordinal value of
the character '8'.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 71890992)

If the network isn't active during networkNotifyActualDevice(), we
would log an error message stating that the bridge device didn't
exist. This patch adds a check to see if the network is active, making
the logs more useful in the case that it isn't.

Partially resolves: https://bugzilla.redhat.com/1442700

(cherry picked from commit 7949de96)

Nothing that could happen during networkNotifyActualDevice() could
justify unceremoniously killing the qemu process, but that's what we
were doing.

In particular, new code added in commit 85bcc022 (first appearred in
libvirt-3.2.0) attempts to reattach tap devices to their assigned
bridge devices when libvirtd restarts (to make it easier to recover
from a restart of a libvirt network). But if the network has been
stopped and *not* restarted, the bridge device won't exist and
networkNotifyActualDevice() will fail.

This patch changes networkNotifyActualDevice() and
qemuProcessNotifyNets() to return void, so that qemuProcessReconnect()
will soldier on regardless of what happens (any errors will still be
logged though).

Partially resolves: https://bugzilla.redhat.com/1442700

(cherry picked from commit cb182eb1)

This patch changes following output:

    ...
    <graphics type='vnc' port='-1' autoport='yes'>
      <listen type='none'/>
    </graphics>
    ...

into this output:

    ...
    <graphics type='vnc'>
      <listen type='none'/>
    </graphics>
    ...
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
(cherry picked from commit 2b7d5164)

Rather than freeing the list before starting a new VM clear it after
stopping the old instance when the data becomes invalid.

(cherry picked from commit 44f8e00b)

The alias would be leaked, since it's not freed on the vm stop path.

(cherry picked from commit 8c1fee5f)

Since the private data structure is not freed upon stopping a VM, the
usbaddrs pointer would be leaked:

==15388== 136 (16 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 893 of 1,019
==15388==    at 0x4C2CF55: calloc (vg_replace_malloc.c:711)
==15388==    by 0x54BF64A: virAlloc (viralloc.c:144)
==15388==    by 0x5547588: virDomainUSBAddressSetCreate (domain_addr.c:1608)
==15388==    by 0x144D38A2: qemuDomainAssignUSBAddresses (qemu_domain_address.c:2458)
==15388==    by 0x144D38A2: qemuDomainAssignAddresses (qemu_domain_address.c:2515)
==15388==    by 0x144ED1E3: qemuProcessPrepareDomain (qemu_process.c:5398)
==15388==    by 0x144F51FF: qemuProcessStart (qemu_process.c:5979)
[...]

(cherry picked from commit 3ab802d6)

Clean the stale data after shutting down the VM. Otherwise the data
would be leaked on next VM start. This happens due to the fact that the
private data object is not freed on destroy of the VM.

(cherry picked from commit 1730cdc6)

As with virtio-scsi, the "internal error" messages after
preparing a vhost-scsi hostdev overwrites more meaningful
error messages deeper in the callchain.  Remove it too.
Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
(cherry picked from commit 6ff38cee)

I tried to attach a SCSI LUN to two different guests, and forgot
to specify "shareable" in the hostdev XML.  Attaching the device
to the second guest failed, but the message was not helpful in
telling me what I was doing wrong:

  $ cat scsi_scratch_disk.xml
    <hostdev mode='subsystem' type='scsi'>
      <source>
        <adapter name='scsi_host3'/>
        <address bus='0' target='15' unit='1074151456'/>
      </source>
    </hostdev>

  $ virsh attach-device dasd_sles_d99c scsi_scratch_disk.xml
  Device attached successfully

  $ virsh attach-device dasd_fedora_0e1e scsi_scratch_disk.xml
  error: Failed to attach device from scsi_scratch_disk.xml
  error: internal error: Unable to prepare scsi hostdev: scsi_host3:0:15:1074151456

I eventually discovered my error, but thought it was weird that
Libvirt doesn't provide something more helpful in this case.
Looking over the code we had just gone through, I commented out
the "internal error" message, and got something more useful:

  $ virsh attach-device dasd_fedora_0e1e scsi_scratch_disk.xml
  error: Failed to attach device from scsi_scratch_disk.xml
  error: Requested operation is not valid: SCSI device 3:0:15:1074151456 is already in use by other domain(s) as 'non-shareable'

Looking over the error paths here, we seem to issue better
messages deeper in the callchain so these "internal error"
messages overwrite any of them.  Remove them, so that the
more detailed errors are seen.
Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
(cherry picked from commit 33c1fc43)

Signed-off-by: NEric Farman <farman@linux.vnet.ibm.com>
(cherry picked from commit 2dc94c3c)

qemuDomainGetNumaParameters would return the automatic nodeset even for
the persistent config if the domain was running. This is incorrect since
the automatic nodeset will be re-queried upon starting the vm.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1445325
(cherry picked from commit 135c56e2)

Migration with old QEMU which does not support query-migrate-parameters
would fail because the QMP command is called unconditionally since the
introduction of TLS migration. Previously it was only called if the user
explicitly requested a feature which uses QEMU migration parameters. And
even then the situation was not ideal, instead of reporting an
unsupported feature we'd just complain about missing QMP command.

Trivially no migration parameters are supported when
query-migrate-parameters QMP command is missing. There's no need to
report an error if it is missing, the callers will report better error
if needed.

https://bugzilla.redhat.com/show_bug.cgi?id=1441934Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit ac58c036)

Domain name is duplicated in make_nonnull_domain, but not freed when
virTypedParamsSerialize returns error.

(cherry picked from commit f6934047)

it should be a comparison of modes between new and old devices. So
the argument of the second virDomainNetGetActualDirectMode should be
newdev.
Signed-off-by: NZhiPeng Lu <lu.zhipeng@zte.com.cn>
(cherry picked from commit c77bc47f)

ka maybe have been freeed in virObjectUnref, application using
virKeepAliveTimer will segfault when unlock ka. We should keep
ka's refs positive before using it.

#0  0x00007fd8f79970e8 in virClassIsDerivedFrom (klass=0xdeadbeef, parent=0x7fd8e8001b80) at util/virobject.c:169
#1  0x00007fd8f799742e in virObjectIsClass (anyobj=anyobj entry=0x7fd8e800b9c0, klass=＜optimized out＞) at util/virobject.c:365
#2  0x00007fd8f79974e4 in virObjectUnlock (anyobj=0x7fd8e800b9c0) at util/virobject.c:338
#3  0x00007fd8f7ac477e in virKeepAliveTimer (timer=＜optimized out＞, opaque=0x7fd8e800b9c0) at rpc/virkeepalive.c:177
#4  0x00007fd8f7e5c9cf in libvirt_virEventInvokeTimeoutCallback () from /usr/lib64/python2.7/site-packages/libvirtmod.so
#5  0x00007fd8ff64db94 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#6  0x00007fd8ff64f1ad in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#7  0x00007fd8ff64d85f in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#8  0x00007fd8ff64d950 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#9  0x00007fd8ff64d950 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0
#10 0x00007fd8ff64f1ad in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0
#11 0x00007fd8ff5dc098 in function_call () from /lib64/libpython2.7.so.1.0
#12 0x00007fd8ff5b7073 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#13 0x00007fd8ff5c6085 in instancemethod_call () from /lib64/libpython2.7.so.1.0
#14 0x00007fd8ff5b7073 in PyObject_Call () from /lib64/libpython2.7.so.1.0
#15 0x00007fd8ff648ff7 in PyEval_CallObjectWithKeywords () from /lib64/libpython2.7.so.1.0
#16 0x00007fd8ff67d7e2 in t_bootstrap () from /lib64/libpython2.7.so.1.0
#17 0x00007fd8ff358df3 in start_thread () from /lib64/libpthread.so.0
#18 0x00007fd8fe97d3ed in clone () from /lib64/libc.so.6
Signed-off-by: NYi Wang <wang.yi59@zte.com.cn>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit ab5bb6f3)

Commit f4ef3a71 made a variation of virNetDevSetMAC that would return
without logging an error message if errno was set to
EADDRNOTAVAIL. This errno is set by some SRIOV VF drivers (in
particular igbvf) when they fail to set the device's MAC address due
to the PF driver refusing the request. This is useful if we want to
try a different method of setting the VF MAC address before giving up
(Commit 86556e16 actually does this, setting the desired MAC address
to the "admin MAC in the PF, then detaching and reattaching the VF
netdev driver to force a reinit of the MAC address).

During testing of Bug 1442040 t was discovered that the ixgbe driver
returns EPERM in this situation, so this patch changes the exception
case for silent+non-terminal failure to account for this difference.

Completes resolution to: https://bugzilla.redhat.com/1415609 (RHEL 7.4)
                         https://bugzilla.redhat.com/1442040 (RHEL 7.3.z)

(cherry picked from commit 997134fb)

Reported by Rafał Wojciechowski <it@rafalwojciechowski.pl>.

Thread 1 (Thread 0x7f194b99d700 (LWP 5631)):
0  virNetDevGetifaddrsAddress (addr=0x7f194b99c7c0, ifname=0x7f193400e2b0 "ovirtmgmt") at util/virnetdevip.c:738
1  virNetDevIPAddrGet (ifname=0x7f193400e2b0 "ovirtmgmt", addr=addr@entry=0x7f194b99c7c0) at util/virnetdevip.c:795
2  0x00007f19467800d6 in networkGetNetworkAddress (netname=<optimized out>, netaddr=netaddr@entry=0x7f1924013f18) at network/bridge_driver.c:4780
3  0x00007f193e43a33c in qemuProcessGraphicsSetupNetworkAddress (listenAddr=0x7f19340f7650 "127.0.0.1", glisten=0x7f1924013f10) at qemu/qemu_process.c:4062
4  qemuProcessGraphicsSetupListen (vm=<optimized out>, graphics=0x7f1924014f10, cfg=0x7f1934119f00) at qemu/qemu_process.c:4133
5  qemuProcessSetupGraphics (flags=17, vm=0x7f19240155d0, driver=0x7f193411f1d0) at qemu/qemu_process.c:4196
6  qemuProcessPrepareDomain (conn=conn@entry=0x7f192c00ab50, driver=driver@entry=0x7f193411f1d0, vm=vm@entry=0x7f19240155d0, flags=flags@entry=17) at qemu/qemu_process.c:4969
7  0x00007f193e4417c0 in qemuProcessStart (conn=conn@entry=0x7f192c00ab50, driver=driver@entry=0x7f193411f1d0, vm=0x7f19240155d0,asyncJob=asyncJob@entry=QEMU_ASYNC_JOB_START, migrateFrom=migrateFrom@entry=0x0, migrateFd=migrateFd@entry=-1, migratePath=migratePath@entry=0x0,snapshot=snapshot@entry=0x0, vmop=vmop@entry=VIR_NETDEV_VPORT_PROFILE_OP_CREATE, flags=17, flags@entry=1) at qemu/qemu_process.c:5553

Man page for getifaddrs also states that the "ifa_addr" may contain
a null pointer which happens if there is an existing network interface
on the host without IP address.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
(cherry picked from commit 42000bf7)

libvirtd can spawn threads/tasks when creating new domains for
some hypervisors such as Xen's libxl driver, quickly reaching
the cgroups pids controller default TasksMax setting of 512. When
the limit is reached, attempting to create additional domains
results in an error from the cgroups pids controller, e.g.

kernel: [71282.213347] cgroup: fork rejected by pids controller in
/system.slice/libvirtd.service

Depending on domain type and configuration, anywhere from 4-7
threads/tasks may be created by libxl when starting a domain.
In order to support 4096 domains, similar to commit 27cd7635,
increase the TasksMax setting in libvirtd.service to
4096 * 8 = 32768 tasks.

(cherry picked from commit 6b3fb86b)

In the RPC client event loop code, if poll() returns only a POLLHUP
or POLLERR status, then we end up reporting a bogus error message:

  error: failed to connect to the hypervisor
  error: An error occurred, but the cause is unknown

We do actually report an error, but we virNetClientMarkClose method
has already captured the error status before we report it, so the
real error gets thrown away. The key fix is to report the error
before calling virNetClientMarkClose(). In changing this, we also
split out reporting of POLLHUP vs POLLERR to make any future bugs
easier to diagnose.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 234ac4e1)

/etc/libvirt/nwfilter/*.xml files are installed with no UUID, which
means libvirtd will automatically alter all of them once it starts. Thus
RPM verification will always fail on them. Let's use a trick similar to
the default network XML and store nwfilter XMLs in /usr/share. They will
be copied into /etc in %post. Additionally the /etc files are marked as
%ghost so that they are uninstalled if the RPM package is removed.

Note that the %post script overwrites existing files with new ones on
upgrade, which is what has always been happening.

https://bugzilla.redhat.com/show_bug.cgi?id=1431581
https://bugzilla.redhat.com/show_bug.cgi?id=1378774Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit 1d3963db)

Fix xlconfig channel tests when OOM testing is enabled.

TEST: xlconfigtest
32) Xen XL-2-XML Format channel-unix                                  ... OK
    Test OOM for nalloc=55 ................................................*** Error in `/home/jfehlig/virt/upstream/libvirt/tests/.libs/xlconfigtest': double free or corruption (fasttop): 0x0000000000679550 ***
...
(gdb) bt
#0  0x00007ffff36875af in raise () from /lib64/libc.so.6
#1  0x00007ffff36889aa in abort () from /lib64/libc.so.6
#2  0x00007ffff36c5150 in __libc_message () from /lib64/libc.so.6
#3  0x00007ffff36cb4f6 in malloc_printerr () from /lib64/libc.so.6
#4  0x00007ffff36cbcee in _int_free () from /lib64/libc.so.6
#5  0x00007ffff782babf in virFree (ptrptr=0x7fffffffdca8) at util/viralloc.c:582
#6  0x000000000042f2f3 in xenParseXLChannel (conf=0x677350, def=0x6815b0) at xenconfig/xen_xl.c:788
#7  0x000000000042f44e in xenParseXL (conf=0x677350, caps=0x6832b0, xmlopt=0x67f6e0) at xenconfig/xen_xl.c:828
#8  0x00000000004105a3 in testCompareFormatXML (
    xlcfg=0x6811e0 "/home/jfehlig/virt/upstream/libvirt/tests/xlconfigdata/test-channel-unix.cfg",
    xml=0x681110 "/home/jfehlig/virt/upstream/libvirt/tests/xlconfigdata/test-channel-unix.xml", replaceVars=false)
    at xlconfigtest.c:152

When a channel is successfully parsed and its path and name fields
assigned from local variables, set the local variables to NULL to
prevent a double free on error.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
(cherry picked from commit b2c12f57)

Fix xlconfigtest runs build for --enable-test-oom on
        Xen XL-2-XML Parse  new-disk

    #0  0x00007ffff3bd791f in raise () from /lib64/libc.so.6
    #1  0x00007ffff3bd951a in abort () from /lib64/libc.so.6
    #2  0x00007ffff3c1b200 in __libc_message () from /lib64/libc.so.6
    #3  0x00007ffff3c2488a in _int_free () from /lib64/libc.so.6
    #4  0x00007ffff3c282bc in free () from /lib64/libc.so.6
    #5  0x00007ffff7864fcb in virFree (ptrptr=ptrptr@entry=0x7fffffffd868) at util/viralloc.c:582
    #6  0x00007ffff78776e5 in virConfFreeValue (val=<optimized out>) at util/virconf.c:178
==> #7  0x0000000000425759 in xenFormatXLDomainDisks (def=0x7fffffffd8c0, def=0x7fffffffd8c0, conf=0x658220)
        at xenconfig/xen_xl.c:1159
    #8  xenFormatXL (def=def@entry=0x66ec20, conn=conn@entry=0x668cf0) at xenconfig/xen_xl.c:1558
    #9  0x000000000040ea1d in testCompareParseXML (replaceVars=<optimized out>,
        xml=0x65f5e0 "/home/wtenhave/WORK/libvirt/history/libvirt/tests/xlconfigdata/test-fullvirt-ovmf.xml",
        xlcfg=0x65f6b0 "/home/wtenhave/WORK/libvirt/history/libvirt/tests/xlconfigdata/test-fullvirt-ovmf.cfg")
        at xlconfigtest.c:105
    #10 testCompareHelper (data=<optimized out>) at xlconfigtest.c:205
    #11 0x000000000041079a in virTestRun (title=title@entry=0x431cf0 "Xen XL-2-XML Parse  fullvirt-ovmf",
        body=body@entry=0x40e720 <testCompareHelper>, data=data@entry=0x7fffffffda50) at testutils.c:247
    #12 0x000000000040ebc2 in mymain () at xlconfigtest.c:256
    #13 0x0000000000411070 in virTestMain (argc=1, argv=0x7fffffffdc08, func=0x40f2c0 <mymain>) at testutils.c:992
    #14 0x00007ffff3bc2401 in __libc_start_main () from /lib64/libc.so.6
    #15 0x000000000040e5da in _start ()

symmetry seems missing its sibbling coded functionality
demonstrated under functions;
        xenFormatXLUSBController()
        xenFormatXLUSB()
        xenFormatXLDomainChannels()
        xenFormatXMDisks
Signed-off-by: NWim ten Have <wim.ten.have@oracle.com>
(cherry picked from commit 2c1a31a3)

Fix xlconfigtest runs build for --enable-test-oom on
        Xen XL-2-XML Parse  channel-pty

Program received signal SIGSEGV, Segmentation fault.

    #0  0x00007ffff3c2b373 in __strchr_sse2 () from /lib64/libc.so.6
==> #1  0x00007ffff7875701 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=val@entry=0x674750) at util/virconf.c:290
    #2  0x00007ffff7875668 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=<optimized out>) at util/virconf.c:306
    #3  0x00007ffff78757ef in virConfSaveEntry (buf=buf@entry=0x7fffffffd8a0, cur=cur@entry=0x674780) at util/virconf.c:338
    #4  0x00007ffff78783eb in virConfWriteMem (memory=0x665570 "", len=len@entry=0x7fffffffd910, conf=conf@entry=0x65b940)
        at util/virconf.c:1543
    #5  0x000000000040eccb in testCompareParseXML (replaceVars=<optimized out>, xml=<optimized out>,
        xlcfg=0x662c00 "/home/wtenhave/WORK/libvirt/OOMtesting/libvirt-devel/tests/xlconfigdata/test-channel-pty.cfg")
        at xlconfigtest.c:108
    #6  testCompareHelper (data=<optimized out>) at xlconfigtest.c:205
    #7  0x0000000000410b3a in virTestRun (title=title@entry=0x432cc0 "Xen XL-2-XML Parse  channel-pty",
        body=body@entry=0x40e9b0 <testCompareHelper>, data=data@entry=0x7fffffffd9f0) at testutils.c:247
    #8  0x000000000040f322 in mymain () at xlconfigtest.c:278
    #9  0x0000000000411410 in virTestMain (argc=1, argv=0x7fffffffdba8, func=0x40f660 <mymain>) at testutils.c:992
    #10 0x00007ffff3bc0401 in __libc_start_main () from /lib64/libc.so.6
    #11 0x000000000040e86a in _start ()

    (gdb) frame 1
    #1  0x00007ffff7875701 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=val@entry=0x674750) at util/virconf.c:290
    290                 if (strchr(val->str, '\n') != NULL) {
    (gdb) print *val
    $1 = {type = VIR_CONF_STRING, next = 0x0, l = 0, str = 0x0, list = 0x0}
Signed-off-by: NWim ten Have <wim.ten.have@oracle.com>
(cherry picked from commit ae5d7582)

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

If the parent is not a scsi_host, then we can just happily return since
we won't be removing a vport.

Fixes a bug with the following output:

$ virsh pool-destroy host4_hba_pool
error: Failed to destroy pool host4_hba_pool
error: internal error: Invalid adapter name 'pci_0000_10_00_1' for SCSI pool

$

(cherry picked from commit 84f178bd)

The virRotatingFileWriterAppend method leaks the file->entry
on the virRotatingFileWriterEntryNew failing path.

(cherry picked from commit 123770cd)

Since refactoring by commit id '3dd859c0', @maxcpu is no longer used.

(cherry picked from commit b2641b43)

Variable def going out of scope leaks the storage def.source.hosts points to.

(cherry picked from commit d76267b2)

Use MD5_DIGEST_SIZE or VIR_UUID_BUFLEN rather than VIR_UUID_STRING_BUFLEN
when compare @uuid with @md5.

(cherry picked from commit 77cc51a4)

The code that validates whether an internal snapshot is possible would
reject an empty but not-readonly drive. Since floppies can have this
property, add a check for emptiness.

(cherry picked from commit eee3b4b9)

Properly error out when the user requests a port from a bus
that does not have a controller present in the domain XML.

https://bugzilla.redhat.com/show_bug.cgi?id=1441589
(cherry picked from commit b003b978)

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit c3d1df7b)

==20406== 4 bytes in 1 blocks are definitely lost in loss record 6 of 1,059
==20406==    at 0x4C2AF3F: malloc (vg_replace_malloc.c:299)
==20406==    by 0x8F17D39: strdup (in /lib64/libc-2.24.so)
==20406==    by 0x552C0E0: virStrdup (virstring.c:784)
==20406==    by 0x54D3622: virConfGetValueString (virconf.c:945)
==20406==    by 0x144E4692: virQEMUDriverConfigLoadFile (qemu_conf.c:687)
==20406==    by 0x1452A744: qemuStateInitialize (qemu_driver.c:664)
==20406==    by 0x55DB585: virStateInitialize (libvirt.c:770)
==20406==    by 0x124570: daemonRunStateInit (libvirtd.c:881)
==20406==    by 0x5532990: virThreadHelper (virthread.c:206)
==20406==    by 0x8C82493: start_thread (in /lib64/libpthread-2.24.so)
==20406==    by 0x8F7FA1E: clone (in /lib64/libc-2.24.so)

(cherry picked from commit 2ef3aa8f)

Commit a4a39d90 added a check that checks for VFIO support with mediated
devices. The problem is that the hostdev preparing functions behave like
a fallthrough if device of that specific type doesn't exist. However,
the check for VFIO support was independent of the existence of a mdev
device which caused the guest to fail to start with any device to be
directly assigned if VFIO was disabled/unavailable in the kernel.
The proposed change first ensures that it makes sense to check for VFIO
support in the first place, and only then performs the VFIO support check
itself.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1441291Signed-off-by: NErik Skultety <eskultet@redhat.com>
(cherry picked from commit b4c2ac8d)

Coverity complains about virBufferCurrentContent might be return null
when calling strlen, so check virBufferError first before calling
strlen.

(cherry picked from commit c5ca209f)

On virGetInterface failure, call virInterfaceDefFree for the @def.

(cherry picked from commit 1b1b0459)

==18591== 16 bytes in 1 blocks are definitely lost in loss record 41 of 183
==18591==    at 0x4C2B934: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18591==    by 0x54EBB1C: virAllocN (viralloc.c:191)
==18591==    by 0x1628CA: _vshMalloc (vsh.c:136)
==18591==    by 0x1344C4: virshVcpuPinQuery (virsh-domain.c:6603)
==18591==    by 0x1344C4: cmdVcpuPin (virsh-domain.c:6707)
==18591==    by 0x1631BF: vshCommandRun (vsh.c:1312)
==18591==    by 0x12DBB1: main (virsh.c:961)

(cherry picked from commit b1aa4613)

Found by running valgrind for these tests.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
(cherry picked from commit 9005a64b)