[libvirt] [RFC PATCH] Add new migration flag VIR_MIGRATE_DRY_RUN

[Michal Privoznik]

On 11/02/2018 11:34 PM, Jim Fehlig wrote:
> A dry run can be used as a best-effort check that a migration command
> will succeed. The destination host will be checked to see if it can
> accommodate the resources required by the domain. DRY_RUN will fail if
> the destination host is not capable of running the domain. Although a
> subsequent migration will likely succeed, the success of DRY_RUN does not
> ensure a future migration will succeed. Resources on the destination host
> could become unavailable between a DRY_RUN and actual migration.
> 
> Signed-off-by: Jim Fehlig <jfehlig at suse.com>
> ---
> 
> If it is agreed this is useful, my thought was to use the begin and
> prepare phases of migration to implement it. qemuMigrationDstPrepareAny()
> already does a lot of the heavy lifting wrt checking the host can
> accommodate the domain. Some of it, and the remaining migration phases,
> can be short-circuited in the case of dry run.
> 
> One interesting wrinkle I've observed is the check for cpu compatibility.
> AFAICT qemu is actually invoked on the dst, "filtered-features" of the cpu
> are requested via qmp, and results are checked against cpu in domain config.
> If cpu on dst is insufficient, migration fails in the prepare phase with
> something like "guest CPU doesn't match specification: missing features: z y z".
> I was hoping to avoid launching qemu in the case of dry run, but that may
> be unavoidable if we'd like a dependable dry run result.
> 
> Thanks for considering the idea!
> 
> (BTW, if it is considered useful I will follow up with a V1 series that
> includes this patch and and impl for the qemu driver.)
> 
>  include/libvirt/libvirt-domain.h | 12 ++++++++++++
>  src/qemu/qemu_migration.h        |  3 ++-
>  tools/virsh-domain.c             |  7 +++++++
>  tools/virsh.pod                  | 10 +++++++++-
>  4 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
> index fdd2d6b8ea..6d52f6ce50 100644
> --- a/include/libvirt/libvirt-domain.h
> +++ b/include/libvirt/libvirt-domain.h
> @@ -830,6 +830,18 @@ typedef enum {
>       */
>      VIR_MIGRATE_TLS               = (1 << 16),
>  
> +    /* Setting the VIR_MIGRATE_DRY_RUN flag will cause libvirt to make a
> +     * best-effort attempt to check if migration will succeed. The destination
> +     * host will be checked to see if it can accommodate the resources required
> +     * by the domain. For example are the network, disk, memory, and CPU

While this is a honourable goal to achieve I don't think we can
guarantee it (without running qemu). At least in qemu world. For
instance, libvirt doesn't check if there's enough memory (nor regular
nor hugepages) when domain is started/migrated. We just run qemu and let
it fail. However, for network, CPU and hostdev we do run checks so these
might work. Disks are in grey area - we check their presence but not
their labels. And if domain is relabel=no then the only way to learn if
qemu would succeed is to run it.

But I don't see much problem with starting qemu in paused state. I mean,
we can get through Prepare phase but never actually reach Perform stage.
The API/flag would return success if Prepare succeeded.

I bet it's easier to check if migration would succeed in xen world, or?

The other thing is how are apps expected to use this? I mean, if an app
wants to work without admin intervention then it would need to learn how
to fix any possible error (missing disk, perms issue, missing hostdev,
etc.). This is not a trivial task IMO.

Michal