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>

The commandhelper binary is a helper for commandtest that
validates what file handles were inherited. For this to
work reliably we must not have any libraries that leak
file descriptors into commandhelper. Unfortunately some
versions of gnutls will intentionally open file handles
at library load time via a constructor function.

We previously hacked around this in

  commit 4cbc15d0
  Author: Martin Kletzander <mkletzan@redhat.com>
  Date:   Fri May 2 09:55:52 2014 +0200

    tests: don't fail with newer gnutls

    gnutls-3.3.0 and newer leaves 2 FDs open in order to be backwards
    compatible when it comes to chrooted binaries [1].  Linking
    commandhelper with gnutls then leaves these two FDs open and
    commandtest fails thanks to that.  This patch does not link
    commandhelper with libvirt.la, but rather only the utilities making
    the test pass.

    Based on suggestion from Daniel [2].

    [1] http://lists.gnutls.org/pipermail/gnutls-help/2014-April/003429.html
    [2] https://www.redhat.com/archives/libvir-list/2014-April/msg01119.html

That fix relied on fact that while libvirt.so linked with
gnutls, libvirt_util.la did not link to it.  With the
introduction of the util/vircrypto.c file that assumption
is no longer valid. We must not link to libvirt_util.la
at all - only gnulib and libc can (hopefully) be relied
on not to open random file descriptors in constructors.
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

For vhost-user ports, Open vSwitch acts as the server and QEMU the client.
When OVS crashed or restart, QEMU shoule be reconnect to OVS.
Signed-off-by: NZhiPeng Lu <lu.zhipeng@zte.com.cn>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This commit adds new events for two methods and operations: *PoolBuild() and
*PoolDelete(). Using the event-test and the commands set below we have the
following outputs:

$ sudo ./event-test
Registering event callbacks
myStoragePoolEventCallback EVENT: Storage pool test Defined 0
myStoragePoolEventCallback EVENT: Storage pool test Created 0
myStoragePoolEventCallback EVENT: Storage pool test Started 0
myStoragePoolEventCallback EVENT: Storage pool test Stopped 0
myStoragePoolEventCallback EVENT: Storage pool test Deleted 0
myStoragePoolEventCallback EVENT: Storage pool test Undefined 0

Another terminal:
$ sudo virsh pool-define test.xml
Pool test defined from test.xml

$ sudo virsh pool-build test
Pool test built

$ sudo virsh pool-start test
Pool test started

$ sudo virsh pool-destroy test
Pool test destroyed

$ sudo virsh pool-delete test
Pool test deleted

$ sudo virsh pool-undefine test
Pool test has been undefined

This commits can be a solution for RHBZ #1475227.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1475227Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The patch passes the reconnect timeout to QEMU by monitor on
chardev hotplug.
Signed-off-by: NZhiPeng Lu <lu.zhipeng@zte.com.cn>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The util/vircrypto.c file uses gnutls, so we must directly link
libvirt_util.la with gnutls to avoid errors on OS which do not
resolve symbols against indirectly linked libraries.

This fixes a build failure on Ubuntu Trusty

  CCLD     storagevolxml2argvtest
/usr/bin/ld: ../src/.libs/libvirt_util.a(libvirt_util_la-vircrypto.o): undefined reference to symbol 'gnutls_strerror@@GNUTLS_1_4'

//usr/lib/x86_64-linux-gnu/libgnutls.so.26: error adding symbols: DSO missing from command line
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The VxHS block device will only use the newer formatting options and
avoid the legacy URI syntax.

An excerpt for a sample QEMU command line is:

  -drive file.driver=vxhs,file.vdisk-id=eb90327c-8302-4725-9e1b-4e85ed4dc251,\
   file.server.type=tcp,file.server.host=192.168.0.1,\
   file.server.port=9999,format=raw,if=none,id=drive-virtio-disk0,cache=none \
  -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,\
   id=virtio-disk0

Update qemuxml2argvtest with a simple test.
Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Extract out the "guts" of building a server entry into it's own
separately callable/usable function in order to allow building
a server entry for a consumer with src->nhosts == 1.

Add the backing parse and a test case to verify parsing of VxHS
backing storage.
Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Alter the schema to allow a VxHS block device. Sample XML is:

  <disk type='network' device='disk'>
    <driver name='qemu' type='raw' cache='none'/>
    <source protocol='vxhs' name='eb90327c-8302-4725-9e1b-4e85ed4dc251'>
      <host name='192.168.0.1' port='9999'/>
    </source>
    <target dev='vda' bus='virtio'/>
    <serial>eb90327c-8302-4725-9e1b-4e85ed4dc251</serial>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
  </disk>

Update the html docs to describe the capability for VxHS.

Alter the qemuxml2xmltest to validate the formatting.
Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add a new virStorageNetProtocol for Veritas HyperScale (VxHS) disks
Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Using the query-qmp-schema introspection - look for the 'vxhs'
blockdevOptions type.

NB: This is a "best effort" type situation as there is not a
    mechanism to determine whether the running QEMU has been
    built with '--enable-vxhs'. All we can do is check if the
    option to use vxhs for a blockdev-add exists in the command
    infrastructure which does not take that into account when
    building its table of commands and options.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The mlx4 (Mellanox) netdev driver implements the sysfs phys_port_id
file for both VFs and PFs, so you can find the VF netdev plugged into
the same physical port as any given PF netdev by comparing the
contents of phys_port_id of the respective netdevs. That's what
libvirt does when attempting to find the PF netdev for a given VF
netdev (or vice versa).

Most other netdev's drivers don't implement phys_port_id, so the file
is visible in sysfs directory listing, but attempts to read it result
in ENOTSUPP. In these cases, libvirt is unable to read phys_port_id of
either the PF or the VF, so it just returns the first entry in the
PF/VF's list of netdevs.

But we've found that the i40e driver is in between those two
situations - it implements phys_port_id for PF netdevs, but doesn't
implement it for VF netdevs. So libvirt would successfully read the
phys_port_id of the PF netdev, then try to find a VF netdev with
matching phys_port_id, but would fail because phys_port_id is NULL for
all VFs. This would result in a message like the following:

   Could not find network device with phys_port_id '3cfdfe9edc39'
   under PCI device at /sys/class/net/ens4f1/device/virtfn0

To solve this problem in a way that won't break functionality for
anyone else, this patch saves the first netdev name we find for the
device, and returns that if we fail to find a netdev with the desired
phys_port_id.

Documentation states:

"'offset' and 'size' represent an area which must lie entirely within
the device or file." Enforce the that the buffer lies within fully.

Commit 3956af49 broke the blockPeek API since virStorageFileRead
allocates a return buffer and fills it with the data, while the API
fills a user-provided buffer. This did not get caught by the compiler
since the API prototype uses a 'void *'.

Fix it by transferring the data from the allocated buffer to the user
provided buffer.

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

Turns out a build job can be stuck waiting for a macOS worker to
become available for a pretty long time: if more than 5 commits
have been pushed in the meantime, the clone will be too shallow
for the worker to find the commit it's supposed to verify, and
the build job will fail.

See https://travis-ci.org/libvirt/libvirt/jobs/277244110 for an
example of the failure described.

This reverts commit 2e975abd.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

This is particularly useful on operating systems that don't ship
Python as part of the base system (eg. FreeBSD) while still working
just as well as it did before on Linux.

While at it, make it explicit that our scripts are only going to
work with Python 2, and remove the usage of unbuffered I/O, which
as far as I can tell has no effect on the output files.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>