There's no argument named @result, use @matches instead.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

On live migration with --p2p like:
 $ virsh migrate --live --p2p kvmguest-bionic-normal \
       qemu+ssh://10.6.221.80/system

We hit an apparmor deny like:
  apparmor="DENIED" operation="file_inherit"
  profile="/usr/sbin/libvirtd" pid=23477 comm="ssh" family="unix"
  sock_type="stream" protocol=0 requested_mask="send receive"
  denied_mask="send" addr=none peer_addr=none peer="unconfined"

The rule is not perfect, but can't be restricted further at the moment
(new upstream kernel features needed). For now the lack of a profile on the
peer as well as comm not being a conditional on rules do not allow to filter
further.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

These are already exported at header file level because of
VIR_ENUM_DECL being in numa_conf.h. However, they are not being
exported at object level because of missing libvirt_private.syms
record.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

QEMU 2.7 and newer don't allow guests to start unless the initial
vCPUs count is a multiple of the vCPU hotplug granularity, so
validate it and report an error if needed.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1283700Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

While at the moment we're only performing a single check that is
connected to vCPU hotplugging, we're going to introduce a second
one soon. Move the topology check underneath the capability check
to make that easier; since, after this change, the 'topologycpus'
variable doesn't need to have function scope, we move its
declaration to the inner scope as well.

The comments around the check are modified in order to explain
the different QEMU versions involved.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Introduced by commit <4ae9dbea>.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1528572Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Similar to qemuDomainAddChardevTLSObjects let's move the chardev
source must be TCP and it has the @haveTLS flag set checks before
trying to delete the TLS objects.

For the Chr device this represents no change; however, for RNG device
this is an additionaly check that was missed in commit id '68808516'.
Before adding the objects, TCP and haveTLS are checked.

Let's make a comment deletion helper similar to the Add helper
that can be called after the ExitMonitor.

The modify qemuDomainRemoveChrDevice and qemuDomainRemoveRNGDevice
to call the helper instead of inlining the copy and pasted code.

So far clients were closed when disposing the daemon, after the state
driver cleanup. This was leading to libvirtd crashing at shutdown due
to missing driver.

Moving the client close in virNetServerClose() fixes the problem.
Reviewed-by: NErik Skultety <eskultet@redhat.com>

virt-aa-helper needs read access to the disk image to resolve symlinks
and add the proper rules to the profile. Its profile whitelists a few
common paths, but users can place their images anywhere.

This commit helps users allowing access to their images by adding their
own rules in apparmor.d/local/usr.lib.libvirt.virt-aa-helper.

This commit also adds rules to allow reading files named:
  - *.raw as this is a rather common disk image extension
  - /run/libvirt/**[vd]d[a-z] as these are used by virt-sandbox

When autogen.sh finishes it helpfully prints

  "Now type 'make' to compile libvirt."

which is fine if on a host with GNU make, but on *BSD running
'make' will end in tears. We should tell users to run 'gmake'
on these platforms. If 'gmake' doesn't exist then we should
report an error too

  "GNU make is required to build libvirt"
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The list_guests function in libvirt-guests uses 'grep -v' to filter
Xen domain0 from a list of guests. If domain0 is the only item in
the list, 'grep -v' returns 1, causing the 'stop' operation to fail
when action is 'suspend'. Improve the filtering by using sed to remove
domain0 from the list of guests.

Prior to this change, we relied solely on the inherited readonly
attribute of a service's socket. This only worked for our UNIX sockets
(and only to some degree), but doesn't work for TCP sockets which are RW
by default, but such connections support RO as well. This patch forces
an update on the client object once we have established a connection to
reflect the nature of the connection itself rather than relying on the
underlying socket's attributes.
Clients connected to the admin server have always been connected as RW
only.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1524399Signed-off-by: NErik Skultety <eskultet@redhat.com>

A Xen domain0 is better described as a persistent domain. Mark it
as such during intialization.

The use of [[:blank:]] was intended to cover tabs as well, but
it couldn't possibly work in its current form, so the regex was
tweaked in d09429ab.

With the original reason for using [[:blank:]] now gone, we can
replace its usage with plain spaces. A comment about the purpose
of the check is added as well.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

ebtables/iptables processing is skipped for any interface connected to
Open vSwitch (they have their own packet filtering), likewise for
midonet (according to
http://blog.midokura.com/2016/04/midonet-rule-chains), but libvirt
would allow adding a <filterref> to interfaces connected in these
ways, so the user might mistakenly believe they were being protected.

This patch checks for a non-NULL <virtualport> element for an
interface (or its network) and logs an error if <virtualport> and
<filterref> are both present. This could cause some previously working
domains to no longer start, but that's really the whole point of this
patch - to warn people that their filterref isn't protecting them as
they might have thought.

I don't bother checking this during post-parse validation, because
such a check would be incomplete - it's possible that a network would
have a <virtualport> that would be applied to an interface, and you
can't know that until the domain is started.

Resolves: https://bugzilla.redhat.com/1502754

When the <bandwidth> of an interface is changed with update-device,
the old settings are cleared with tc, then new settings added with
tc. But if the <bandwidth has been removed, the old settings weren't
being removed, so the bandwidth restrictions would still be active on
the interface although the interface status in libvirt showed that
they had been removed.

This patch fixes it by calling virNetDevBandwidthClear() if the
"modification" to the interface bandwidth was to completely clear
it.

An alternative could have been to modify virNetDevBandwidthSet() to
always clear existing bandwith settings at the beginning of the
function (currently it short circuits in that case, doing nothing),
but that would have led to cases where virNetDevBandwidthClear() was
now being called in cases where it previously wasn't, and while many
of those cases would be NOPs, there could be cases where it would
cause an error. The way this patch works, the ...Clear() function is
only called in cases where the ...Set() function had previously been
called successfully, so the risk of regression is minimized.

  Resolves: https://bugzilla.redhat.com/1454709

Also call qemuDomainRemoveInputDevice if we receive the
event after the Detach API ends.

Commit 67486bb2 failed to include this.

https://bugzilla.redhat.com/show_bug.cgi?id=1524837Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Register the helpers directly to format and parse the data.

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

This will be the first private piece of data that will need to be stored
in the XML for some drivers. Add helpers which will do it.

VM drivers may need to store additional private data to the status XML
so that it can be restored after libvirtd restart. Since not everything
is needed add a callback infrastructure, where VM drivers can add only
stuff they need.

Note that the private data is formatted as a <privateData> sub-element
of the <disk> or <backingStore> <source> sub-element. This is done since
storing it out of band (in the VM private data) would require a complex
matching process to allow to put the data into correct place.

Commit id '1241e487' used <code>&lt;interface&gt;</code> which
is not valid syntax for a <summary>.

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

If the vhost-scsi device file cannot be found, the generic error

    "error: An error occurred, but the cause is unknown"

is returned.  Let's add a real error message to make it clear
why the failure occurred.

We cannot be sure someone initialized the passed *vhostfd and we
certainly don't want or need to be calling VIR_FORCE_CLOSE on what
probably is -1. So let's just return -1 immediately.

Commit id '70249927' neglected to cover this case because the test
had taken the "shortcut" to already add the <address>; however, when
the PCI address assignment code was adjusted by commit id '70249927'
the vhost-scsi (VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI_HOST) wasn't
covered thus returning a 0 for pciFlags. So I altered the tests too
to make sure it doesn't happen again.

Previously the qemuxml2xmloutdata was a softlink to the source
qemuxml2argvdata, so I unlinked and recreated the output file to
force generation of the adddress. Without the test changes, an
address generation returns:

    libvirt: Domain Config error : internal error: Cannot automatically
    add a new PCI bus for a device with connect flags 00

if an address was supplied in the test, a restart of libvirtd or
edit of a guest would display the following opaque message:

    warning : qemuDomainCollectPCIAddress:1237 :
    qemuDomainDeviceCalculatePCIConnectFlags() thinks that the device
     with PCI address 0000:00:09.0 should not have a PCI address

where the address is related to the guest PCI address provided.

virStringSplit may return NULL, so we must handle that.

Cc: John Ferlan <jferlan@redhat.com>
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Remove the unnecessary clearing of address_array as VIR_ALLOC_N
initialized the array already.

Cc: John Ferlan <jferlan@redhat.com>
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>

Commit id 'c5c96545' neglected to validate that the srcPriv was
non-NULL before dereferencing. Similar problem to what was fixed
by commit id '8056721c' but missed during multiple rebases and
code reworks.

Now that the storage pools are self locking, we can reduce the number
of places that need to take the big hammer storage driver lock

Now that we have a private storage pool list, we can take the next
step and convert to using objects. In this case, we're going to use
RWLockable objects (just like every other driver) with two hash
tables for lookup by UUID or Name.

Along the way the ForEach and Search API's will be adjusted to use
the related Hash API's and the various FindBy functions altered and
augmented to allow for HashLookup w/ and w/o the pool lock already
taken.

After virStoragePoolObjRemove we will need to virObjectUnref(obj)
after to indicate the caller is "done" with it's reference. The
Unlock occurs during the Remove.

The NumOf, GetNames, and Export functions all have their own callback
functions to return the required data and the FindDuplicate code
can use the HashSearch function callbacks.

Move the structure into virstorageobj.c.

Use the virStoragePoolObjListNew allocator to fill in the @pools for
the storage driver and test driver.

Commit id '5ab746b8' introduced the function as perhaps a copy
of storageVolLookupByPath; however, it did not use the @cleanpath
variable even though it used the virFileSanitizePath. So in essance
the only "check" being done for failure is whether it was possible
to strdup the path.

Looking at the virStoragePoolDefParseXML one will note that the
target.path is stored using the result of virFileSanitizePath.
Therefore, this function should sanitize and use the input @path
for the argument to storagePoolLookupByTargetPathCallback which
is comparing against stored target.path values.

Additionally, if there was an error we should use the proper error
of VIR_ERR_NO_STORAGE_POOL (instead of VIR_ERR_NO_STORAGE_VOL).

Replace the error message during startup of libvirtd with an info
message if audit_level < 2 and audit is not supported by the
kernel. Audit is not supported by the current kernel if the kernel
does not have audit compiled in or if audit is disabled (e.g. by the
kernel cmdline).
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

==25251== 5 bytes in 1 blocks are definitely lost in loss record 7 of 81
==25251==    at 0x4C2BEDF: malloc (vg_replace_malloc.c:299)
==25251==    by 0x967E379: strdup (in /lib64/libc-2.25.so)
==25251==    by 0x5366F9F: virStrdup (virstring.c:941)
==25251==    by 0x538BF1D: virDomainCapsNew (domain_capabilities.c:121)
==25251==    by 0x10EACE: test_virDomainCapsFormat (domaincapstest.c:295)
==25251==    by 0x10FBD2: virTestRun (testutils.c:180)
==25251==    by 0x10F192: mymain (domaincapstest.c:457)
==25251==    by 0x111C7F: virTestMain (testutils.c:1119)
==25251==    by 0x10FA3C: main (domaincapstest.c:528)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

==32171== 32 bytes in 1 blocks are definitely lost in loss record 44 of 107
==32171==    at 0x4C2DEF6: calloc (vg_replace_malloc.c:711)
==32171==    by 0x55744A9: virAllocN (viralloc.c:191)
==32171==    by 0x12CED2: xenMakeIPList (xen_common.c:1186)
==32171==    by 0x12D0BE: xenFormatNet (xen_common.c:1221)
==32171==    by 0x12F0D2: xenFormatVif (xen_common.c:1889)
==32171==    by 0x12F2B4: xenFormatConfigCommon (xen_common.c:1944)
==32171==    by 0x13BA32: xenFormatXL (xen_xl.c:1971)
==32171==    by 0x1186CA: testCompareParseXML (xlconfigtest.c:105)
==32171==    by 0x118A64: testCompareHelper (xlconfigtest.c:205)
==32171==    by 0x119E36: virTestRun (testutils.c:180)
==32171==    by 0x11970E: mymain (xlconfigtest.c:301)
==32171==    by 0x11BEE3: virTestMain (testutils.c:1119)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

==30399== 180 (144 direct, 36 indirect) bytes in 3 blocks are definitely lost in loss record 91 of 111
==30399==    at 0x4C2E0FF: realloc (vg_replace_malloc.c:785)
==30399==    by 0x5574572: virReallocN (viralloc.c:245)
==30399==    by 0x5574668: virExpandN (viralloc.c:294)
==30399==    by 0x55747AB: virResizeN (viralloc.c:352)
==30399==    by 0x560074D: virStringSplitCount (virstring.c:115)
==30399==    by 0x137A59: xenParseXLVnuma (xen_xl.c:442)
==30399==    by 0x13952B: xenParseXL (xen_xl.c:1064)
==30399==    by 0x11884D: testCompareFormatXML (xlconfigtest.c:152)
==30399==    by 0x118A87: testCompareHelper (xlconfigtest.c:207)
==30399==    by 0x119E36: virTestRun (testutils.c:180)
==30399==    by 0x119186: mymain (xlconfigtest.c:274)
==30399==    by 0x11BEE3: virTestMain (testutils.c:1119)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>