off_t is signed and it's size is the same as long only on 64b archs.
Thus it cannot be formatted as %lu.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

These tests cover a number of scenarios where we care about
the memory locking limit being set correctly for the guest
to work properly.

This will be used later on in the test suite.

The value we use internally to represent the lack of a memory
locking limit, VIR_DOMAIN_MEMORY_PARAM_UNLIMITED, doesn't
match the value setrlimit() and prlimit() use for the same
purpose, RLIM_INFINITY, so we have to handle the translation
ourselves.

Partially-resolves: https://bugzilla.redhat.com/1431793

For guests that use <memoryBacking><locked>, our only option
is to remove the memory locking limit altogether.

Partially-resolves: https://bugzilla.redhat.com/1431793

Instead of having a separate function, we can simply return
zero from the existing qemuDomainGetMemLockLimitBytes() to
signal the caller that the memory locking limit doesn't need
to be set for the guest.

Having a single function instead of two makes it less likely
that we will use the wrong value, which is exactly what
happened when we started applying the limit that was meant
for VFIO-using guests to <memoryBacking><locked>-using
guests.

This reverts commit c2e60ad0.

Turns out this check is excessively strict: there are ways
other than <memtune><hard_limit> to raise the memory locking
limit for QEMU processes, one prominent example being
tweaking /etc/security/limits.conf.

Partially-resolves: https://bugzilla.redhat.com/1431793

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

Commits 29f7b5ea and 5edf9aaf pushed them incorrectly at the end of
the file in the bug fixes section for libvirt 2.5.0.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When reading release notes, patch summary is not always the best
description of what users can expect in new version.  I propose
changing it slightly so that it describes what exactly happens and
when.

However, we do not have to add every single code change to the news
file, that would be ridiculous and unreadable for users.  If the patch
subject needs changes like this one, I'm rather tempted to say that
such changes should not be in the news file at all.  So that would be
the other way how to fix this.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The mock, as well as the test, is only available on Linux.  So skip
building it everywhere else, especially when it fails on mingw.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

If if_indextoname is not defined, the whole function using it should
not be defined either.  Add stub to fix build on mingw.

Caused by 5dd60705Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Creating a copy of the definition we want to add in a migration cookie
makes the code cleaner and less prone to memory leaks or double free
errors.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

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

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

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

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

Clean up the virsh man page description for --pool-create-as in order
to better describe how the various arguments are used when creating
(or defining) a logical pool.

Also modify the storage pool XML parsing algorithm to check for the
mismatched "name" and "source-name".

Move the --print-xml to the end of the qualifiers since it's not
properly positionally situated for both --pool-create-as and --pool-define-as
and could be miscontrued as being the 3rd positional argument.

While parsing if the storage source is not present, then a defaultFormat
was not set. This could lead to oddities such as seeing "unknown" format
in output for the "logical" pool even though the only format the pool could
support would be "lvm2".

This does "put a label" on other pool defaults as follows:

   File System: FS_AUTO
   Network File System: NETFS_AUTO
   Disk: UNKNOWN

Each of which is the "0" value for their respective pools and thus
would be no "real" change.

Migration with invtsc is allowed by QEMU as long as TSC frequency is
explicitly specified.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

QEMU allows for TSC frequency to be explicitly set to enable migration
with invtsc (migration fails if the destination QEMU cannot set the
exact same frequency used when starting the domain on the source host).

Libvirt already supports setting the TSC frequency in the XML using

    <clock>
      <timer name='tsc' frequency='1234567890'/>
    </clock>

which will be transformed into

    -cpu Model,tsc-frequency=1234567890

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

The frequency is documented and formatted as an attribute of the <timer>
element rather than a nested <frequency> element expected by the parser.
Luckily enough, timer frequency has not been used by any driver so far.
And users were not able to set it in the XML either.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

 - Make virMediatedDeviceNew() stub args match its prototype
 - Fix typo: virRerportError -> virReportError
 - Move MDEV_SYSFS_DEVICES definition out of the #ifdef __linux__ block
   so we don't have to stub virMediatedDeviceGetSysfsPath()

Fix typo: virNetDevVLanPtr -> virNetDevVlanPtr.

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

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

As it turns out some file headers (e.g. ext4) may be larger/longer than
the 512 bytes of zeros being written prior to a pvcreate, so let's write
out 2048 bytes similar to how the pvcreate sources would peek at the first
4 sectors of the device.

Make sure there is at enough bytes on the device to clear before doing
doing the clear - just to be sure.

Causes build failure when enabling static analysis

Ensure to insert </change> <change> between items - lost during merge
resolution.

This adds a few validations to the devices listed for a hostdev network:

* devices must be listed by PCI address, not by netdev name

* listing a device by PCI address is valid only for hostdev networks, not
  for other types of network (e.g. macvtap passthrough).

* each device in a hostdev pool must be an SR-IOV VF

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

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

That way you get the error from the compiler before the linker.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Previously, this function must've been called only on Linux in order
to fail gracefully.  That lead to #ifdef mess in callers, so the
function was redesigned so it failed gracefully on non-existing
files.  However that commit forgot to define the function outside the
__linux__ ifdef, it broke non-Linux builds.

Caused by c67e04e2.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Be more positive and reject negative numbers where we don't
allow them by using the virStrToLong variants with 'p'.

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

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