The 'file access' module of the storage driver has few feature checks to
determine whether libvirt supports given storage driver method. The code
to retrieve the driver struct needed for the check is the same so it can
be extracted.

We handle incremental storage migration in a different way. The support
for this new (as of QEMU 2.10) parameter is only needed for full
coverage of migration parameters used by QEMU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

We already support several ways of setting migration bandwidth and this
is not adding another one. With this patch we are able to read and write
this parameter using query-migrate-parameters and migrate-set-parameters
in one call with all other parameters.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The parameters used "migrate" prefix which is pretty redundant and
qemuMonitorMigrationParams structure is our internal representation of
QEMU migration parameters and it is supposed to use names which match
QEMU names.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

We already support setting the maximum downtime with a dedicated
virDomainMigrateSetMaxDowntime API. This patch does not implement
another way of setting the downtime by adding a new public migration
parameter. It just makes sure any parameter we are able to get from a
QEMU monitor by query-migrate-parameters can be passed back to QEMU via
migrate-set-parameters.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The second CHECK macro was used for string parameters. Let's rename it
to CHECK_STR and move it up to have all checks in one place.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The first CHECK macro in the test is used for checking integer values.
Let's make it a bit more generic to be usable for any numeric type and
use it for a new CHECK_INT macro.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The check can be easily replaced with a simple test in the JSON
implementation and we don't need to update it every time a new parameter
is added.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The APPEND macro is now be usable for any type.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The macro (now called PARSE_SET) is now usable for any type which needs
a *_set bool for indicating a valid value.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Linux kernel shows our "cmt" feature as "cqm". Let's mention the name in
the cpu_map.xml to make it easier to find.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

* docs/news.xml: update for release
* po/*po*: regenerated

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Some tests require JSON_MODELS to be parsed into qemuCaps and applied
when computing CPU models and such test cannot succeed if QEMU driver is
disabled. Let's mark the tests with JSON_MODELS_REQUIRED and skip the
appropriate parts if building without QEMU.

On the other hand, CPU tests with JSON_MODELS should succeed even if
model definitions from QEMU are not parsed and applied. Let's explicitly
test this by repeating the tests without JSON_MODELS set.

This fixes the build with QEMU driver disabled, e.g., on some
architectures on RHEL/CentOS.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

When upgrading libvirt packages, there's no strict ordering for the
installation or removal of the individual libvirt sub packages. Thus
libvirt-daemon may be upgraded (and its %postun scriptlet) started
before all sub packages with driver libraries are upgraded. When
libvirt-daemon's %postun scriptlet restarts the daemon old drivers may
still be laying around and the daemon may crash when it tries to use
them.

Let's restart the daemon in %posttrans to make sure libvirtd is
restarted only after all sub packages are at the same version.

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

Since vhostuser type is really a tap that is just plugged into
different type of bridge, supporting QoS is trivial.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

For instance, NET_TYPE_MCAST doesn't support setting QoS. Instead
of claiming success and doing nothing, we should be explicit
about that and report an error.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Apparantly commit id 'dc4c2f75' wasn't specific enough, so here's
a few more clarifications.

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

Use virStorageBackendCreateVolUsingQemuImg to apply the LUKS information
to the logical volume just created.  As part of the processing of the
lvcreate command add 2MB to the capacity to account for the LUKS header
when it's determined that the volume desires to use encryption.

Create a shim that will allow other backends to make use of qemu-img
functionality to create or possibly modify the volume.

Refactor to extract out the LVCREATE command.  This also removes the
need for the local @created since the error path can now only be reached
after the creation of the logical volume.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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

Turns out the virStorageBackendVolResizeLocal did not differentiate
whether the target volume was a LUKS volume or not and just blindly
did the ftruncate() on the target volume.

Follow the volume creation logic (in general) and create a qemu-img
resize command to resize the target volume for LUKS ensuring that
the --object secret is provided as well as the '--image-opts' used
by the qemu-img resize logic to describe the path and secret ensuring
that it's using the luks driver on the volume of course.

Since all that was really needed was a couple of fields and building
the object can be more generic, let's alter the args a bit. This will
be useful shortly for adding the secret object for a volume resize
operation on a luks volume that will need a secret object.

Rather than inline the various free's and return NULL, just create
an error label.

Rather than passing just the path, pass the virStorageVolDefPtr as we're
going to need it shortly.

Also fix the order of code and stack variables in the calling function
virStorageBackendVolResizeLocal.

By Default (without -d) the tests will only print Failures.
So a log should follow general "no message is a good message" style.

But the testfw checks always emit the skip info to stdout. Instead
they should use the redirection that is controlled by -d.

This avoids mesages like the following to clutter the log:
  Skipping FW AAVMF32 test. Could not find /usr/share/AAVMF/AAVMF32_CODE.fd
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Some globbing chars in the domain name could be used to break out of
apparmor rules, so lets forbid these when in virt-aa-helper.

Also adding a test to ensure all those cases were detected as bad char.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Don't leak @blockNodes in the loop.

==226576== 7,120 bytes in 60 blocks are definitely lost in loss record 122 of 125
==226576==    at 0x4835214: calloc (vg_replace_malloc.c:711)
==226576==    by 0x4950D7B: virAllocN (viralloc.c:191)
==226576==    by 0x49EB5BB: virXPathNodeSet (virxml.c:676)
==226576==    by 0x104DB67: virQEMUCapsLoadCPUModels (qemu_capabilities.c:3738)
==226576==    by 0x105510D: virQEMUCapsLoadCache (qemu_capabilities.c:3929)
==226576==    by 0x104459F: qemuTestParseCapabilities (testutilsqemu.c:498)
==226576==    by 0x1040DC9: testQemuCapsCopy (qemucapabilitiestest.c:105)
==226576==    by 0x1041F07: virTestRun (testutils.c:180)
==226576==    by 0x1040B45: mymain (qemucapabilitiestest.c:181)
==226576==    by 0x104320F: virTestMain (testutils.c:1119)
==226576==    by 0x1041149: main (qemucapabilitiestest.c:193)
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Commit 6c43149c removed the minsize directive from the qemu logrotate
file but missed other hypervisors. Remove minsize from the libxl, lxc,
and uml logrotate files as well.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

On a cloud host it is possible to create 100's of unique instances
per day, each leaving behind a /var/log/libvirt/qemu/instance-name.log
file that is < 100k. With the current 'minsize 100k' directive, these
files are never rotated and hence never removed. Over months of time,
tens of thousands of these files can accumulate on the host.

Dropping 'minsize 100k' allows rotating small files, which will
increase the number of log files, but 'rotate 4' ensures they will
be removed after a month.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

In bf3a4140 "virt-aa-helper: fix libusb access to udev usb data" the
libusb access to properly detect the device/bus ids was fixed.

The path /run/udev/data/+usb* contains a subset of that information we
already allow to be read and are currently not needed for the function
qemu needs libusb for. But on the init of libusb all those files are
still read so a lot of apparmor denials can be seen when using usb host
devices, like:
  apparmor="DENIED" operation="open" name="/run/udev/data/+usb:2-1.2:1.0"
  comm="qemu-system-x86" requested_mask="r" denied_mask="r"

Today we could silence the warnings with a deny rule without breaking
current use cases. But since the data in there is only a subset of those
it can read already it is no additional information exposure. And on the
other hand a future udev/libusb/qemu combination might need it so allow
the access in the default apparmor profile.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Hot-adding disks does not parse the full XML to generate apparmor rules.
Instead it uses -f <PATH> to append a generic rule for that file path.

580cdaa7: "virt-aa-helper: locking disk files for qemu 2.10" implemented
the qemu 2.10 requirement to allow locking on disks images that are part of
the domain xml.

But on attach-device a user will still trigger an apparmor deny by going
through virt-aa-helper -f, to fix that add the lock "k" permission to the
append file case of virt-aa-helper.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

When adding CPU usability blockers I forgot to properly free them when
in virDomainCapsCPUModelsDispose.
Reported-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>