Almost every failure in qemuMigrationRun while we are talking to QEMU
monitor results in a jump to exit_monitor label. The only exception is
removed by this patch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The "ret" variable is used for storing the return value of a function
and should not be used as a temporary variable.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Merge cancel and cancelPostCopy sections with the generic error section,
where we can easily decide whether canceling the ongoing migration is
required.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Let cleanup only do things common to both failure and success paths and
move error handling code inside the new "error" section.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Some code which was supposed to be executed only when migration
succeeded was buried inside the cleanup code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When adding a new job state it's useful to let the compiler complain
about places where we need to think about what to do with the new
state.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@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: Michal Privoznik <mprivozn@redhat.com>
They have to be unique within the domain. As usual, backwards
compatibility takes its price. In this particular situation we
have a device that is represented twice in a domain and so is its
alias.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When assigning alias to a device we usually iterate over other
devices of its kind trying to find next index. We do this by
stripping down the prefix and then parsing number at the end,
Usually, if the prefix doesn't match the one we are expecting, we
just continue with next iteration. Except for couple of
functions: qemuGetNextChrDevIndex(),
qemuAssignDeviceRedirdevAlias() and qemuAssignDeviceShmemAlias().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The only remaining user of qemuMonitorGetMigrationCapability is our test
suite. Let's replace qemuMonitorGetMigrationCapability with
qemuMonitorGetMigrationCapabilities there and drop the unused function.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
All calls to qemuMonitorGetMigrationCapability in QEMU driver are
replaced with qemuMigrationCapsGet.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John 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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The new function is called qemuProcessInitMonitor and it will enter/exit
the monitor so that the caller doesn't have to deal with this.
The goal of this patch is to simplify the code in qemuConnectMonitor
which would otherwise be a bit hairy after the following patch.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John 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: John Ferlan <jferlan@redhat.com>
Signed-off-by: Peter 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: John Ferlan <jferlan@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Add the object definition and helpers to store security-related private
data for virStorageSources.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
When commit id 'da86c6c22' added support for diskPriv->encinfo in
qemuDomainSecretDiskPrepare a change to qemuDomainSecretDiskDestroy
to was missed. Although qemuDomainDiskPrivateDispose probably would
do the trick.
Signed-off-by: John 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: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Let's move all the virAsprintf()-s into separate functions for
better structure of the code. Later, when somebody wants to
generate a device alias, all they need is to expose the function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
We have a special function for assigning aliases to RNG devices.
Use that instead of plain virAsprintf().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Back in the times of using 'pci_del', unplugging a device without
a PCI address was not wired up.
After completely removing support for qemu without QEMU_CAPS_DEVICE,
aliases are used to uniquely identify devices in all cases.
Remove the pointless validation of data that was already present
in the domain definition.
There are two more cases where we set an S390/CCW/PCI address
type based on the machine type.
Reuse qemuDomainEnsureVirtioAddress to reduce repetition.
Split out the common code responsible for reserving/assigning
PCI/CCW addresses for virtio disks into a helper function
for reuse by other virtio devices.
We pass the source.file to qemuCheckCCWS390AddressSupport for
the purpose of reporting an error message without actually checking
that the rng device is of type VIR_DOMAIN_RNG_BACKEND_RANDOM.
Change it to a hardcoded "rng" string, which also avoids
referring to the device by a host-side attribute.
There is one limitation for using this API, when the guest is started
with all actions set to "destroy" we put "-no-reboot" on the QEMU
command line. That cannot be changed while QEMU is running and
the QEMU process is always terminated no matter what is configured
for any action.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1460677
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
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: John Ferlan <jferlan@redhat.com>
Signed-off-by: Pavel 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: John Ferlan <jferlan@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
