If virNWFilterHashTablePut fails, then the @val was leaked.
Signed-off-by: NZhiPeng Lu <lu.zhipeng@zte.com.cn>

Use an empty string to let qemu fill out the default.
This matches what's done in qemuBuildChrChardevStr.

https://bugzilla.redhat.com/show_bug.cgi?id=1454671Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This reverts commit edaf4ebe.

This uses "reconnect" as attribute for <source> element, but we already
have a <reconnect> element for <source> element for chardev devices.

Since this is the same feature for different device it should be
presented in XML the same way.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Some values we read from the qemu monitor may be changed with the actual
state by the incoming migration. This means that we should refresh
certain things only after the migration has finished.

This is mostly visible in the cdrom tray state, which is by default
closed but may be opened by the guest OS. This would be refreshed before
qemu transferred the actual state and thus libvirt would think that the
tray is closed.

Note that this patch moves only a few obvious query commands. Others may
be moved later after individual assessment.

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

When the vcpu is successfully removed libvirt would remove the cgroup.
In cases when removal of the cgroup fails libvirt would report an error.

This does not make much sense, since the vcpu was removed and we can't
really do anything with the cgroup. This patch silences the errors from
cgroup removal.

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

Commit 6801da94 fixed the typo in the function name, but forgot
to adjust the indentation level of the next line.

It is possible (although possibly not very useful) to leave out
the service attribute when using <source mode='bind'/>

Fix the formatter bug introduced by commit 4a0da345 and format
the host when its present (checked for non-NULL inside
virBufferEscapeString) instead of basing it on the presence
of the service attribute.

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

The alias recorded in disk->info.alias is the alias for the frontend
device but we are interested in the backend drive. This messed up the
disk node name extraction code as qemu reports the drive alias in the
block query commands. This was broken in the node name detector
refactoring done in commit 0175dc6e

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

Move the check that skips node name detection if they are already
present earlier so that the hash table lookup is skipped.

Seeing a log message saying 'flags=93' is ambiguous & confusing unless
you happen to know that libvirt always prints flags as hex.  Change our
debug messages so that they always add a '0x' prefix when printing flags,
and '0' prefix when printing mode. A few other misc places gain a '0x'
prefix in error messages too.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Kernel 4.13 introduced finer-grained ptrace checks

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.13.2&id=290f458a4f16f9cf6cb6562b249e69fe1c3c3a07

With kernel 4.13 and apparmor 2.11, simply starting libvirtd
results in the following apparmor denial

type=AVC msg=audit(1506112085.645:954): apparmor="DENIED"
operation="ptrace" profile="/usr/sbin/libvirtd" pid=6984
comm="libvirtd" requested_mask="trace" denied_mask="trace"
peer="unconfined"

Attempting to start an unconfined domain results in

type=AVC msg=audit(1506112301.227:1112): apparmor="DENIED"
operation="ptrace" profile="/usr/sbin/libvirtd" pid=7498
comm="libvirtd" requested_mask="trace" denied_mask="trace"
peer="/usr/sbin/libvirtd"

And attempting to start a confined domain results in

type=AVC msg=audit(1506112631.408:1312): apparmor="DENIED"
operation="open" profile="virt-aa-helper" name="/etc/libnl/classid"
pid=8283 comm="virt-aa-helper" requested_mask="r" denied_mask="r"
fsuid=0 ouid=0
type=AVC msg=audit(1506112631.530:1319): apparmor="DENIED"
operation="open" profile="virt-aa-helper" name="/etc/libnl/classid"
pid=8289 comm="virt-aa-helper" requested_mask="r" denied_mask="r"
fsuid=0 ouid=0
type=AVC msg=audit(1506112632.186:1324): apparmor="DENIED"
operation="ptrace" profile="/usr/sbin/libvirtd" pid=8342
comm="libvirtd" requested_mask="trace" denied_mask="trace"
peer="libvirt-66154842-e926-4f92-92f0-1c1bf61dd1ff"

Add ptrace rules to allow the trace operations.

Resolves: https://bugzilla.suse.com/show_bug.cgi?id=1058847Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NGuido Günther <agx@sigxcpu.org>

The functionality was added in 4.8, but due to a rename of
the DEVLINK_CMD_ESWITCH_GET constant in the kernel headers,
the headers from kernel 4.11 are required by the libvirt code.

Remove the reference from the news entry, since it could be
misleading.

Some distros (see diff) chose to backport QMP support rather than rebase
to newer version of qemu. As a hack they added the string 'libvirt' to
the qemu -help output. Remove this as downstream-only hacks should be
carried by downstream and not litter upstream.

This effectively reverts commit ff88cd59

Because qemuDomainDefCopy needs a string representation of a domain
definition, there's no reason for calling the lower level
qemuDomainDefFormatBuf API.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

virDomainDefFormatInternal (called by qemuDomainDefFormatXMLInternal)
already checks for buffer errors and properly resets the buffer on
failure.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In my previous commit of b1d87f9a I've made a typo breaking
the FreeBSD build. s/ipAaddr/ipAddr/
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

instead of only unloading it. This makes sure old profiles don't pile up
in /etc/apparmor.d/libvirt and we get updates to modified templates on
VM restart.
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

After commit 8708ca01 libvirtd consistently aborts with "stack
 smashing detected" when nodedev driver is initialized.

This is caused by nlmsg_parse() being told that its array of nlattr*
has CTRL_CMD_MAX (10) entries, when in fact it is declared to have
CTRL_ATTR_MAX (8) entries. Since all the entries are initialized to
NULL, the result is that nlmsg_parse is overwriting 2*(sizof(nlattr*))
bytes outside the array.
Signed-off-by: NLaine Stump <laine@laine.org>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In aiforaf() (which exists only when building for BSD) the
@ipAddr may be leaked.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit id '5604c056' used the wrong API to generate the
<secret type='%s'..." field. The previous code used the
correct API as was done in commit id '6887af39'. The data
is actually a usage type not an auth type even though the
result is the same.

Move the virSecretUsageType into the util.

Passing a NULL value for the argument secAlias to the function
qemuDomainGetTLSObjects would cause a segmentation fault in
libvirtd.

Changed code to check before dereferencing a NULL secAlias.
Signed-off-by: NAshish Mittal <ashmit602@gmail.com>

Adding s390x qemu caps test for qemu version 2.10.0.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

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

When migrating to a file (e.g. when doing 'virsh save file'),
couple of things are happening in the thread that is executing
the API:

1) the domain obj is locked
2) iohelper is spawned as a separate process to handle all I/O
3) the thread waits for iohelper to finish
4) the domain obj is unlocked

Now, the problem is that while the thread waits in step 3 for
iohelper to finish this may take ages because iohelper calls
fdatasync(). And unfortunately, we are waiting the whole time
with the domain locked. So if another thread wants to jump in and
say copy the domain name ('virsh list' for instance), they are
stuck.

The solution is to unlock the domain whenever waiting for I/O and
lock it back again when it finished.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

Commit id '99a2d6af' was a bit too aggressive with determining whether
the provided path was a "physical" cd-rom in order to generate a taint
message due to the possibility of some guest and host trying to control
the tray. For cd-rom guest devices backed to some VIR_STORAGE_TYPE_FILE
storage, this wouldn't be a problem and as such it shouldn't be a problem
for guest devices using some sort of block device on the host such as
iSCSI, LVM, or a Disk pool would present.

So before issuing a taint message, let's check if the provided path of
the VIR_STORAGE_TYPE_BLOCK backed device is a "known" physical cdrom name
by comparing the beginning of the path w/ "/dev/cdrom" and "/dev/sr".
Also since it's possible the provided path could resolve to some /dev/srN
device, let's get that path as well and perform the same check.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The virSocketAddrFormat() allocates the string and it's caller
responsibility to free it afterwards.

==28857== 11 bytes in 1 blocks are definitely lost in loss record 37 of 168
==28857==    at 0x4C2BEDF: malloc (vg_replace_malloc.c:299)
==28857==    by 0x9A81D79: strdup (in /lib64/libc-2.23.so)
==28857==    by 0x5DA3BF0: virStrdup (virstring.c:902)
==28857==    by 0x5D96182: virSocketAddrFormatFull (virsocketaddr.c:427)
==28857==    by 0x5D95E13: virSocketAddrFormat (virsocketaddr.c:352)
==28857==    by 0x5706890: qemuBuildHostNetStr (qemu_command.c:3891)
==28857==    by 0x57138D3: qemuBuildInterfaceCommandLine (qemu_command.c:8597)
==28857==    by 0x5713D6A: qemuBuildNetCommandLine (qemu_command.c:8699)
==28857==    by 0x57176F6: qemuBuildCommandLine (qemu_command.c:10027)
==28857==    by 0x5769D61: qemuProcessCreatePretendCmd (qemu_process.c:6004)
==28857==    by 0x4056EC: testCompareXMLToArgv (qemuxml2argvtest.c:502)
==28857==    by 0x41DF40: virTestRun (testutils.c:180)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Since commit v2.2.0-199-g7ce711a3 libvirt stores an updated guest CPU
in domain's live definition and there's no need to update it every time
we want to format the definition. The commit itself tried to address
this in qemuDomainFormatXML, but forgot to fix qemuDomainDefFormatLive.
Not to mention that masking a previously set flag is only acceptable if
the flag was set by a public API user. Internally, libvirt should have
never set the flag in the first place.

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

When a user requested a domain XML description with
VIR_DOMAIN_XML_UPDATE_CPU flag, libvirt would use the host CPU
definition from host capabilities rather than the one which will
actually be used once the domain is started.

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

The only real usage of this flag was removed by "cpu_conf: Drop
updateCPU from virCPUDefFormat".
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In the past we updated host-model CPUs with host CPU data by adding a
model and features, but keeping the host-model mode. And since the CPU
model is not normally formatted for host-model CPU defs, we had to pass
the updateCPU flag to the formatting code to be able to properly output
updated host-model CPUs. Libvirt doesn't do this anymore, host-model
CPUs are turned into custom mode CPUs once updated with host CPU data
and thus there's no reason for keeping the hacks inside CPU XML
formatters.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

They are simply not supported on that machine type.

Partially-resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1487499Signed-off-by: NPino Toscano <ptoscano@redhat.com>

They are simply not supported on those architectures.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1487499Signed-off-by: NPino Toscano <ptoscano@redhat.com>

This will be used to improve the validation for this type of devices.

The former @def parameter is renamed to @dev, leaving @def for the
virDomainDef (following the style used elsewhere).
Signed-off-by: NPino Toscano <ptoscano@redhat.com>

If a test expects either a parse error or a failure but then there is
neither a parse error nor a failure, then properly mark the test as
failing, instead of failing later on (e.g. trying to open a
non-existing .args file).
Signed-off-by: NPino Toscano <ptoscano@redhat.com>

The guest of usb-bus-missing does not cause a parse error, but a
validation issue -- hence, switch from DO_TEST_PARSE_ERROR to
DO_TEST_FAILURE.

Fixes commit b003b978.
Signed-off-by: NPino Toscano <ptoscano@redhat.com>

For win32 we need EXIT_AM_SKIP which is in testutils.h. We must
define NO_LIBVIRT to prevent replacement of fprintf with
virFilePrintf as we can't link to libvirt_util.la
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The iohelper currently calls saferead() to get data from the
underlying file. This has a problem with O_DIRECT when hitting
end-of-file. saferead() is asked to read 1MB, but the first
read() it does may return only a few KB, so it'll try another
read() to fill the remaining buffer. Unfortunately the buffer
pointer passed into this 2nd read() is likely not aligned
to the extent that O_DIRECT requires, so rather than seeing
'0' for end-of-file, we'll get -1 + EINVAL due to misaligned
buffer.

The way the iohelper is currently written, it already handles
getting short reads, so there is actually no need to use
saferead() at all. We can simply call read() directly. The
benefit of this is that we can now write() the data immediately
so when we go into the subsequent reads() we'll always have a
correctly aligned buffer.

Technically the file position ought to be aligned for O_DIRECT
too, but this does not appear to matter when at end-of-file.
Tested-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>