Commit Graph

35466 Commits

Author SHA1 Message Date
Jiri Denemark
af8e39921a cpu_conf: Don't format empty model for host-model CPUs
Most likely for historical reasons our CPU def formatting code is
happily adding useless <model fallback='allow'/> for host-model CPUs. We
can just drop it.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-25 15:29:19 +01:00
Jiri Denemark
65fa7bba1a cpu_conf: Fix default value for CPU match attribute
Commit v0.8.4-66-g95ff6b18ec (9 years ago) changed the default value for
the cpu/@match attribute to 'exact' in a rather complicated way. It did
so only if <model> subelement was present and set -1 otherwise (which is
not expected to ever happen). Thus the following two equivalent XML
elements:

    <cpu mode='host-model'/>

and

    <cpu mode='host-model'>
      <model/>
    </cpu>

would be parsed differently. The former would end up with match == -1
while the latter would have match == 1 ('exact'). This is not a big deal
since the match attribute is ignored for host-model CPUs, but we can
simplify the code and make it a little bit saner anyway.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-25 15:29:19 +01:00
Pavel Mores
d3f2a8bd47 qemu: added tests of the new default video type selection algorithm
The test case for x86_64 and neither cirrus nor vga capability is of the
xml2argv type because it actually fails to parse the XML at all [*] which
is something that xml2xml tests don't seem to handle.  xml2argv test fails
to produce a qemu argv for this case which xml2argv tests can handle.

[*] This is a consequence of the decision not to have a fallback if the
obvious choices (cirrus and vga) aren't viable due to missing QEMU caps.

Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pavel Mores <pmores@redhat.com>
2019-11-25 08:47:08 -05:00
Pavel Mores
33a9757852 qemu: the actual change of default video devide type selection algorithm
If a graphics device was added to XML that had no video device, libvirt
automatically added a video device which was always of type 'cirrus' on
x86_64, even if the underlying qemu didn't support cirrus.

This patch refines a bit the decision about the type of the video device.
Based on QEMU capabilities, cirrus is still preferred but only added if
QEMU supports it, otherwise VGA is used if supported by QEMU.  There is now
no fallback as libvirt only aspires to generate a basic working config and
leaves anything more specific up to higher-level management tools.

Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pavel Mores <pmores@redhat.com>
2019-11-25 08:47:08 -05:00
Pavel Mores
4a067e70fa qemu: prepare existing test for change of the default video device type
The test relied implicitly on default video device being cirrus.  As we're
about to change that the test would start failing.  To avoid this, just make
the test's requirement explicit.

Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pavel Mores <pmores@redhat.com>
2019-11-25 08:47:08 -05:00
Pavel Mores
b648d96289 qemu: default video device type selection algoritm moved into its own function
The default video device type selection algorithm we're about to deploy will
increase the amount of code dedicated to the task by amount enough to warrant
factoring the whole thing into its own function so as not to pollute the
caller qemuDomainDeviceVideoDefPostParse().  Do it now so that the actual
algorithm change later on is in a clean commit by itself and easy to review.

Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pavel Mores <pmores@redhat.com>
2019-11-25 08:47:08 -05:00
Daniel P. Berrangé
68aa7f3851 travis: add fedora-31 & fedora-rawhide to the build images
The CentOS7 distro is quite old and the Ubuntu 18.04 distro
is already a year & half old. Adding a Fedora 31 image gives
us coverage of the newest stable distro release, and
fedora-rawhide gives us the cutting edge.

Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-25 10:28:04 +00:00
Erik Skultety
36a01c2a47 Revert "network: Check for QOS before blindly using it"
This reverts commit f4db846c32.

This patch results in the following error when trying to start
essentially any VM with default network:

unsupported configuration: QOS must be defined for network 'default'

Coverity didn't see that the bandwidth == NULL it complained about in
virNetDevBandwidthPlug was already checked properly in
networkCheckBandwidth, thus causing networkPlugBandwidth to return 0
and finish before a call to virNetDevBandwidthPlug would have been even
made.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-11-25 09:41:40 +01:00
Daniel P. Berrangé
bc7e72914a util: consolidate on one free callback for hash data
This previous commit introduced a simpler free callback for
hash data with only 1 arg, the value to free:

  commit 49288fac96
  Author: Peter Krempa <pkrempa@redhat.com>
  Date:   Wed Oct 9 15:26:37 2019 +0200

    util: hash: Add possibility to use simpler data free function in virHash

It missed two functions in the hash table code which need
to call the alternate data free function, virHashRemoveEntry
and virHashRemoveSet.

After the previous patch though, there is no code that
makes functional use of the 2nd key arg in the data
free function. There is merely one log message that can
be dropped.

We can thus purge the current virHashDataFree callback
entirely, and rename virHashDataFreeSimple to replace
it.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 14:21:28 +00:00
Daniel P. Berrangé
feef23e130 conf: stop using hash key when free'ing hash entries
The virChrdevHashEntryFree method uses the hash 'key'
as the name of the logfile it has to remove. By storing
a struct as the value which contains the stream and
the dev path, we can avoid relying on the hash key
when free'ing entries.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 14:21:16 +00:00
Peter Krempa
c6a9e54ce3 qemu: enable blockdev support
Now that all pieces are in place (hopefully) let's enable -blockdev.

We base the capability on presence of the fix for 'auto-read-only' on
files so that blockdev works properly, mandate that qemu supports
explicit SCSI id strings to avoid ABI regression and that the fix for
'savevm' is present so that internal snapshots work.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 12:51:27 +01:00
Peter Krempa
5b4b503be6 qemu: capabilities: Add detection of the 'savevm' fix for -blockdev
The 'savevm' HMP command didn't work properly with blockdev as it tried
to do snapshot of everything including the protocol nodes accessing
files which are not snapshottable. Qemu fixed this bug so now we need to
detect it to allow enabling blockdev.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 12:51:27 +01:00
Peter Krempa
e0300f92fc qemu: qapi: Add support for command features
The top level commands now can have 'feature' flags for fixes so add
support for querying those as well.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 12:51:27 +01:00
Peter Krempa
3460fef5a0 qemu: caps: Add capability for dynamic 'auto-read-only' support for files
Initial implementation of 'auto-read-only' didn't reopen the backing
files when needed. For '-blockdev' to work we need to be able to tel
qemu to open a file read-only and change it during blockjobs as we label
backing chains with a sVirt label which does not allow writing. The
dynamic auto-read-only supports this as it reopens files when writing
is demanded.

Add a capability to detect that the posix file based backends support
the dynamic part.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 12:51:27 +01:00
Peter Krempa
73445e49e0 tests: qemucapabilities: Refresh data for unreleased qemu-4.2 on x86_64
The data is captured from qemu v4.2.0-rc2-19-g2061735ff0

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 12:51:27 +01:00
Peter Krempa
48e57cd632 qemu: caps: Base support of 'backingStoreInput' domain feature on QEMU_CAPS_BLOCKDEV
The qemu driver will obey <backingStore> when we support blockdev.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 12:51:27 +01:00
Peter Krempa
4321bd0dd2 docs: Document support for obeying <backingStore> of <disk> on input
Until now we've only supported <backingStore> in an output mode. The
documentation for the element states that hypervisor drivers may start
to obey it in the future.

Update the documentation so that it mentions the recently added
'backingStoreInput' domain capability and explain what happens if it is
supported and <backingStore> is present on input.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 12:51:27 +01:00
Peter Krempa
757203ee52 conf: domcaps: Add 'backingStoreInput' domain capability
Historically we've only supported the <backingStore> as an output-only
element for domain disks. The documentation states that it may become
supported on input. To allow management apps detectin once that happens
add a domain capability which will be asserted if the hypervisor driver
will be able to obey the <backingStore> as configured on input.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 12:51:27 +01:00
Daniel P. Berrangé
eef089db78 docs: fix include of ACL permissions files
The XSL generator loads included HTML files relative to the source dir
but we need to tell it to load them from the build dir instead.

Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 11:14:20 +00:00
Daniel P. Berrangé
9434d7e139 docs: fix ability to view web pages from build tree
Some of the web content is only present in the source tree, thus when
viewing pages from the build tree they appear missing.

Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 11:14:20 +00:00
Daniel P. Berrangé
adfcc76575 docs: remove unused make targets
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 11:14:20 +00:00
Daniel P. Berrangé
0aa8536f14 docs: generate API reference pages for admin, qemu & lxc libraries
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 11:14:20 +00:00
Daniel P. Berrangé
fc24f22051 docs: use variable for referencing API XML filenames
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 11:14:20 +00:00
Daniel P. Berrangé
4ce0fea015 docs: drop building of API -refs.xml files
The API cross reference files are not used since

  commit d3043afe5c
  Author: Daniel Veillard <veillard@redhat.com>
  Date:   Mon Jan 21 08:08:33 2008 +0000

    Remove docs/API*.html
    * docs/API* docs/api.xsl docs/site.xsl docs/Makefile.am: remove the
      generation of the API*.html files as it's not really useful here

Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 11:14:16 +00:00
Daniel P. Berrangé
f6fbb2e67f docs: stop using custom rules for building / installing web pages
Define automake variables for all the data we need built and installed
and let automake generate the install rules normally.

Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 11:14:06 +00:00
Ján Tomko
e633461bdf scripts: use in even more
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-11-22 11:40:52 +01:00
Ján Tomko
65366bd960 scripts: check-aclrules: use regular expressions less often
Use a simple
  if "substr" in line
before running a regular expression, which saves time,
especially if the regex has a capture group.

This reduces runtime of the check by almost 78 % for me.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-11-22 11:40:52 +01:00
Ján Tomko
988f02a99c scripts: check-aclrules: use in instead of find
For checking whether a substring is present in a string,
using the pattern:
    "str" in string
is slightly faster than:
    string.find("str") != -1

Use it to shave off 4 % of the runtime of this script that
processes quite a few long source files.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-11-22 11:40:52 +01:00
Ján Tomko
424a385c3a scripts: speedup prohibit-duplicate-header
Running regular expressions with capture groups is expensive.
Bail out early if the line does not start with a '#'.

This reduces the runtime of the check by two thirds.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-11-22 11:40:52 +01:00
Pino Toscano
05d28facb5 virsh: limit completion of 'domhostname' to active domains
Getting the hostname of a guest usually requires a in-guest agent,
or generally can be determined only on active domains.

Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-11-22 11:36:51 +01:00
Michal Privoznik
8fa0374c5b qemuProcessStop: Remove image metadata for running mirror jobs
If user starts a blockcommit or a blockcopy then we modify access
for qemu on both images and leave it like that until the job
terminates.  So far so good. Problem is, if user instead of
terminating the job (where we would modify the access again so
that the state before the job is restored) calls destroy on the
domain or if qemu dies whilst executing the block job.  In this
case we don't ever clear the access we granted at the beginning.
To fix this, maybe a bit harsh approach is used, but it works:
after all labels were restored (that is after
qemuSecurityRestoreAllLabel() was called), we iterate over each
disk in the domain and remove XATTRs from the whole backing chain
and also from any file the disk is being mirrored to.

This would have been done at the time of pivot, but it isn't
because user decided to kill the domain instead. If we don't do
this and leave some XATTRs behind the domain might be unable to
start.

Also, secdriver can't do this because it doesn't know if there is
any job running. It's outside of its scope - the hypervisor
driver is responsible for calling secdriver's APIs.

Moreover, this is safe to call because we don't remember labels
for any member of a backing chain except of the top layer. But
that one was restored in qemuSecurityRestoreAllLabel() call done
earlier. Therefore, not only we don't remember labels (and thus
this is basically a NOP for other images in the backing chain) it
is also safe to call this when no blockjob was started in the
first place, or if some parts of the backing chain are shared
with some other domains - this is NOP, unless a block job is
active at the time of domain destroy.

https://bugzilla.redhat.com/show_bug.cgi?id=1741456#c19

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2019-11-22 10:48:14 +01:00
Michal Privoznik
1c12b86185 qemu: Separate image metadata removal into a function
There are four places where we remove image XATTRs and in all of
them we have the same for() loop with the same body. Move it into
a separate function because I'm about to introduce fifth place
where the same needs to be done.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2019-11-22 10:48:04 +01:00
Peter Krempa
86085c9a2f qemu: Instantiate pflash via -machine when using blockdev
Install the convertor function which enables the internals that will use
-blockdev to make qemu open the firmware image and stop using -drive.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 08:32:25 +01:00
Peter Krempa
c8eb99eebf qemu: command: Build the 'pflash' drives via -machine
The old way to instantiate a pflash device via -drive was a hack since
it's a platform device.

The modern approach calls for configuring it via -machine and takes the
node name as an argument.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 08:32:25 +01:00
Peter Krempa
7d2f942af9 qemu: command: Build -blockdev-s for backing of pflash
As a first step we will build the blockdevs which will be supposed to
back the pflash drives when moving away from -drive.

This code is similar to the way we build the blockdevs for the disk, but
skips the copy-on-read layer and doesn't implement any legacy approach.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 08:32:25 +01:00
Peter Krempa
11d13ad8cf qemu: domain: Introduce helper to convert <loader> into virStorageSource
Add a helper which will covert the PFLASH code file and variable file
into the virStorageSource objects stored in private data so that we can
use them with -blockdev while keeping the infrastructure to determine
the path to the loaders intact.

This is a temporary solution until we will want to do snapshots of the
pflash where we will be forced do track the full backing chain in the
XML.

In the meanwhile just convert it partially so that we can stop using
-drive.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 08:32:25 +01:00
Peter Krempa
07675b0100 qemu: domain: Store virStorageSources representing pflash backing
To allow converting the pflash drives to blockdev we will need a
virStorageSource to allow using our helpers. Temporarily prior to
coverting loader data to a virStorageSoruce add private data which will
house this.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-22 08:32:25 +01:00
Peter Krempa
316223b6ad qemu: command: Extract formatting of -drive for pflash
Extract the old way to instantiate pflash devices to hold the firmware
via -drive to a separate function so that it can later be conditionally
disabled when -blockdev will be used.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-22 08:32:23 +01:00
Peter Krempa
c78fadb57c domcaps: Remove function initializing domain caps as unsupported
Commit 5751a0b6b1 added a helper function
called virDomainCapsFeaturesInitUnsupported which initialized all domain
capability features as unsupported.

When adding a new feature this would initialize it as unsupported also
for hypervisor drivers which the original author possibly didn't intend
to modify. To prevent accidental wrong value being reported in such case
revert back to initializing individual features in the hypervisor
drivers themselves.

This is not a straight revert as additonal patches modified how we store
the capabilities.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-11-22 08:16:51 +01:00
Erik Skultety
d6064e2759 libvirt-<module>: Check caller-provided buffers to be NULL with size > 0
Pre-Glib era which used malloc allowed the size of the client-side
buffers to be declared as 0, because malloc documents that it can either
return 0 or a unique pointer on 0 size allocations.
With glib this doesn't work anymore, because glib documents that for
such allocation requests NULL is always returned which results in an
error in our public API checks server-side.
This patch complements the fix in the RPC layer by explicitly erroring
out on the following combination of args used by our legacy APIs (their
moder equivalents don't suffer from this):

function(caller-allocated-array, size, ...) {
    if (!caller-allocated-array && size > 0)
        return error;
}

treating everything else as a valid input and potentially let that fail
on the server-side rather than client-side.

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

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-21 18:16:35 +01:00
Erik Skultety
bf2988235c rpc: gendispatch: Fix a couple of places adding trailing spaces
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-21 18:16:18 +01:00
Ján Tomko
5e067ba4e1 conf: remove NULL check from virDomainQemuMonitorEventNew
The qemu_domain_monitor_event_msg struct in qemu_protocol.x
defines event as a nonnull_string and qemuMonitorJSONIOProcessEvent
also errors out on a non-NULL event.

Drop the check to fix the build with static analysis.

This essentially reverts commit d343e8203d

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-11-21 12:44:23 +01:00
Christian Ehrhardt
7611a1ef00
virt-aa-helper: testcase for shmem devices
Adding build time self tests for basic (deprecated), doorbell and plain mode.

Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
2019-11-21 08:27:03 +01:00
Christian Ehrhardt
36afd1a78e
virt-aa-helper: add rules for shmem devices
Shared memory devices need qemu to be able to access certain paths
either for the shared memory directly (mostly ivshmem-plain) or for a
socket (mostly ivshmem-doorbell).

Add logic to virt-aa-helper to render those apparmor rules based
on the domain configuration.

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

Reviewed-by: Cole Robinson <crobinso@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
2019-11-21 08:26:56 +01:00
Christian Ehrhardt
d53f4d02d0
apparmor: let AppArmorSetSecurityImageLabel append rules
There are currently broken use cases, e.g. snapshotting more than one disk at
once like:
 $ virsh snapshot-create-as --domain eoan --disk-only --atomic
   --diskspec vda,snapshot=no  --diskspec vdb,snapshot=no
   --diskspec vdc,file=/test/disk1.snapshot1.qcow,snapshot=external
   --diskspec vdd,file=/test/disk2.snapshot1.qcow,snapshot=external
The command above will iterate from qemuDomainSnapshotCreateDiskActive and
eventually add /test/disk1.snapshot1.qcow first (appears in the rules)
to then later add /test/disk2.snapshot1.qcow and while doing so throwing
away the former rule causing it to fail.

All other calls to (re)load_profile already use append=true when adding
rules append=false is only used when restoring rules [1].

Fix this by letting AppArmorSetSecurityImageLabel use append=true as well.

Since this is removing a (unintentional) trigger to revoke all rules
appended so far we agreed on review to do some tests, but in the tests
no rules came back on:
- hot-plug
- hot-unplug
- snapshotting

Bugs:
https://bugs.launchpad.net/libvirt/+bug/1845506
https://bugzilla.redhat.com/show_bug.cgi?id=1746684

[1]: https://bugs.launchpad.net/libvirt/+bug/1845506/comments/13

Reviewed-by: Cole Robinson <crobinso@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
2019-11-21 08:26:07 +01:00
Christian Ehrhardt
9714f270f1
apparmor: refactor AppArmorSetSecurityImageLabel
A lot of the code in AppArmorSetSecurityImageLabel is a duplicate of
what is in reload_profile, this refactors AppArmorSetSecurityImageLabel
to use reload_profile instead.

Reviewed-by: Cole Robinson <crobinso@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
2019-11-21 08:26:07 +01:00
Christian Ehrhardt
70cf0af7bf
apparmor: drop useless call to get_profile_name
reload_profile calls get_profile_name for no particular gain, lets
remove that call. The string isn't used in that function later on
and not registered/passed anywhere.

It can only fail if it either can't allocate or if the
virDomainDefPtr would have no uuid set (which isn't allowed).

Thereby the only "check" it really provides is if it can allocate the
string to then free it again.

This was initially added in [1] when the code was still in
AppArmorRestoreSecurityImageLabel (later moved) and even back then had
no further effect than described above.

[1]: https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/security/security_apparmor.c;h=16de0f26f41689e0c50481120d9f8a59ba1f4073;hb=bbaecd6a8f15345bc822ab4b79eb0955986bb2fd#l487

Reviewed-by: Cole Robinson <crobinso@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
2019-11-21 08:26:06 +01:00
Christian Ehrhardt
9d38bce689
virt-aa-helper: clarify command line options
While only used internally from libvirt the options still are misleading
enough to cause issues every now and then.
Group modes, options and an adding extra file and extend the wording of
the latter which had the biggest lack of clarity.
Both add a file to the end of the rules, but one re-generates the
rules from XML and the other keeps the existing rules as-is not
considering the XML content.

Reviewed-by: Cole Robinson <crobinso@redhat.com>
Acked-by: Jamie Strandboge <jamie@canonical.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
2019-11-21 08:26:06 +01:00
Jiri Denemark
5e939cea89 qemu: Store default CPU in domain XML
When starting a domain without a CPU model specified in the domain XML,
QEMU will choose a default one. Which is fine unless the domain gets
migrated to another host because libvirt doesn't perform any CPU ABI
checks and the virtual CPU provided by QEMU on the destination host can
differ from the one on the source host.

With QEMU 4.2.0 we can probe for the default CPU model used by QEMU for
a particular machine type and store it in the domain XML. This way the
chosen CPU model is more visible to users and libvirt will make sure
the guest will see the exact same CPU after migration.

Architecture specific notes
- aarch64: We only set the default CPU for TCG domains as KVM requires
  explicit "-cpu host" to work.

- ppc64: The default CPU for KVM is "host" thanks to some hacks in QEMU,
  we will translate the default model to the model corresponding to the
  host CPU ("POWER8" on a Power8 host, "POWER9" on Power9 host, etc.).
  This is not a problem as the corresponding CPU model is in fact an
  alias for "host". This is probably not ideal, but it's not wrong and
  the default virtual CPU configured by libvirt is the same QEMU would
  use. TCG uses various CPU models depending on machine type and its
  version.

- s390x: The default CPU for KVM is "host" while TCG defaults to "qemu".

- x86_64: The default CPU model (qemu64) is not runnable on any host
  with KVM, but QEMU just disables unavailable features and starts
  happily.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-20 17:22:07 +01:00
Jiri Denemark
4a79d391b5 qemuxml2*test: Add test cases for default CPU models on x86_64
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-11-20 17:22:07 +01:00