Aggregate setup of various aspects of a disk source (secrets, TLS, ...)
into one function so that we don't need to call multiple across the code
base.

Disk sharing between two VMs may corrupt the images if the format driver
does not support it. Check that the user declared use of a supported
storage format when they want to share the disk.

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

Use a style that will discourage from adding inline checks.

Move network device validation into a separate function.

When doing block commit we need to allow write for members of the
backing chain so that we can commit the data into them.

qemuDomainDiskChainElementPrepare was used for this which since commit
786d8d91 calls qemuDomainNamespaceSetupDisk which has very adverse
side-effects, namely it relabels the nodes to the same label it has in
the main namespace. This was messing up permissions for the commit
operation since its touching various parts of a single backing chain.

Since we are are actually not introducing new images at that point add a
flag for qemuDomainDiskChainElementPrepare which will refrain from
calling to the namespace setup function.

Calls from qemuDomainSnapshotCreateSingleDiskActive and
qemuDomainBlockCopyCommon do introduce new members all calls from
qemuDomainBlockCommit do not, so the calls are anotated accordingly.

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

Most of the time it's okay to leave this up to negotiation between
the guest and the host, but in some situations it can be useful to
manually decide the behavior, especially to enforce its availability.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1308743Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Setup everything related to disks in one place rather than calling in
from various places.

The change to ordering of the setup steps is necessary since secrets
need the master key to be present.

In 4f157072 I've tried to make duplicates detection for
nested /dev mount better. However, I've missed the obvious case
when there are two same mount points. For instance if:

  # mount --bind /dev/blah /dev/blah
  # mount --bind /dev/blah /dev/blah

Yeah, very unlikely (in qemu driver world) but possible.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function works over domain definition and not domain object.
Its name is thus misleading.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Right-aligning backslashes when defining macros or using complex
commands in Makefiles looks cute, but as soon as any changes is
required to the code you end up with either distractingly broken
alignment or unnecessarily big diffs where most of the changes
are just pushing all backslashes a few characters to one side.

Generated using

  $ git grep -El '[[:blank:]][[:blank:]]\\$' | \
    grep -E '*\.([chx]|am|mk)$$' | \
    while read f; do \
      sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \
    done
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

When a user provides the backing chain, we will not need to re-detect
all the backing stores again, but should move to the end of the user
specified chain. Additionally if a user provides a full terminated chain
we should not attempt any further detection.

Iterate through the backing chain when setting up TLS for disks.

When attaching the disks, aliases are always generated.

Separate it so that it deals only with single virStorageSource, so that
it can later be reused for full backing chain support.

Two aliases are passed since authentication is more relevant to the
'storage backend' whereas encryption is more relevant to the protocol
layer. When using node names, the aliases will be different.

qemuDomainGetImageIds and qemuDomainStorageFileInit are helpful when
trying to access a virStorageSource from the qemu driver since they
figure out the correct uid and gid for the image.

When accessing members of a backing chain the permissions for the top
level would be used. To allow using specific permissions per backing
chain level but still allow inheritance from the parent of the chain we
need to add a new parameter to the image ID APIs.

This new capability enables a pause before device state serialization so
that we can finish all block jobs without racing with the end of the
migration. The pause is indicated by "pre-switchover" state. Once we're
done QEMU enters "device" migration state.

This patch just defines the new capability and QEMU migration states and
their mapping to our job states.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

This way users can uniquely identify devices at define time.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since we will be allowing users to set device aliases and memory
devices are fragile when it comes to aliases we have to make sure
they won't change during migration. Other devices should be fine.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

All calls to qemuMonitorGetMigrationCapability in QEMU driver are
replaced with qemuMigrationCapsGet.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Each time we need to check whether a given migration capability is
supported by QEMU, we call query-migrate-capabilities QMP command and
lookup the capability in the returned list. Asking for the list of
supported capabilities once when we connect to QEMU and storing the
result in a bitmap is much better and we don't need to enter a monitor
just to check whether a migration capability is supported.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Since the encryption information can also be disk source specific
move it from qemuDomainDiskPrivate to qemuDomainStorageSourcePrivate

Since the last allocated element from qemuDomainDiskPrivate is
removed, that means we no longer need qemuDomainDiskPrivateDispose.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Since the secret information is really virStorageSource specific
piece of data, let's manage the privateData from there instead of
at the Disk level.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Add the object definition and helpers to store security-related private
data for virStorageSources.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

When commit id 'da86c6c2' added support for diskPriv->encinfo in
qemuDomainSecretDiskPrepare a change to qemuDomainSecretDiskDestroy
to was missed. Although qemuDomainDiskPrivateDispose probably would
do the trick.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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

When creating new /dev for domain ran in namespace we try to
preserve all sub-mounts of /dev. Well, not quite all. For
instance if /dev/foo/bar and /dev/foo are both mount points, only
/dev/foo needs preserving. /dev/foo/bar is preserved with it too.
Now, to identify such cases like this one STRPREFIX() is used.
That is not good enough. While it works for [/dev/foo/bar;
/dev/foo] case, it fails for [/dev/prefix; /dev/prefix2] where
the strings share the same prefix but are in fact two different
paths. The solution is to use STRSKIP().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Let it be reused in qemu_domain_address.

We need to send allowReboot in the migration cookie to ensure the same
behavior of the virDomainSetLifecycleAction() API on the destination.

Consider this scenario:

    1. On the source the domain is started with:
        <on_poweroff>destroy</on_poweroff>
        <on_reboot>restart</on_reboot>
        <on_crash>destroy</on_crash>

    2. User calls an API to set "destroy" for <on_reboot>:
        <on_poweroff>destroy</on_poweroff>
        <on_reboot>destroy</on_reboot>
        <on_crash>destroy</on_crash>

    3. The guest is migrated to a different host

    4a. Without the allowReboot in the migration cookie the QEMU
        process on destination would be started with -no-reboot
        which would prevent using the virDomainSetLifecycleAction() API
        for the rest of the guest lifetime.

    4b. With the allowReboot in the migration cookie the QEMU process
        on destination is started without -no-reboot like it was started
        on the source host and the virDomainSetLifecycleAction() API
        continues to work.

The following patch adds a QEMU implementation of the
virDomainSetLifecycleAction() API and that implementation disallows
using the API if all actions are set to "destroy" because we add
"-no-reboot" on the QEMU command line.  Changing the lifecycle action
is in this case pointless because the QEMU process is always terminated.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This will be used later on in implementation of new API
virDomainSetLifecycleAction().  In order to use it, we need to store
the value in status XML to not lose the information if libvirtd is
restarted.

If some guest was started by old libvirt where it was not possible
to change the lifecycle action for running guest, we can safely
detect it based on the current actions from the status XML.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

When libvirt older than 3.9.0 reconnected to a running domain started by
old libvirt it could have messed up the expansion of host-model by
adding features QEMU does not support (such as cmt). Thus whenever we
reconnect to a running domain, revert to an active snapshot, or restore
a saved domain we need to check the guest CPU model and remove the
CPU features unknown to QEMU. We can do this because we know the domain
was successfully started, which means the CPU did not contain the
features when libvirt started the domain.

https://bugzilla.redhat.com/show_bug.cgi?id=1495171Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Add helpers that will simplify checking if a backing file is valid or
whether it has backing store. The helper virStorageSourceIsBacking
returns true if the given virStorageSource is a valid backing store
member. virStorageSourceHasBacking returns true if the virStorageSource
has a backing store child.

Adding these functions creates a central points for further refactors.

The command "info migrate" of qemu outputs the dirty-pages-rate during
migration, but page size is different in different architectures. So
page size should be output to calculate dirty pages in bytes.

Page size is already implemented with commit
030ce1f8612215fcbe9d353dfeaeb2937f8e3f94 in qemu.
Now Implement the counter-part in libvirt.
Signed-off-by: NChao Fan <fanc.fnst@cn.fujitsu.com>
Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Note when no blockjobs are running in the status XML so that we know
that the backing chain will not change until we reconnect.

Currently we don't do it. Therefore we accept senseless
combinations of models and buses they are attached to.
Moreover, diag288 watchdog is exclusive to s390(x).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Checking of disk presence accesses storage on the host so it should be
done from the host setup function. Move the code to new function called
qemuProcessPrepareHostStorage and remove qemuDomainCheckDiskPresence.