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

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(a)suse.com&gt; > --- > > 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.