On 03/04/2015 11:24 AM, Peter Krempa wrote:
> Make sure that libvirt has all vital information needed to reliably
> represent configuration of guest's memory devices in case of a
> migration.
>
> This patch forbids migration in case the required slot number and module
> base address are not present (failed to be loaded from qemu via
> monitor).
> ---
> src/qemu/qemu_migration.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index 20e40aa..a31ce9a 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -2016,6 +2016,20 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver, virDomainObjPtr vm,
> }
> }
>
> + /* Verify that memory device config can be transferred reliably */
> + for (i = 0; i < def->nmems; i++) {
> + virDomainMemoryDefPtr mem = def->mems[i];
> +
> + if (mem->model == VIR_DOMAIN_MEMORY_MODEL_DIMM &&
> + mem->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DIMM) {
> + virReportError(VIR_ERR_OPERATION_INVALID, "%s",
> + _("domain's dimm info lacks slot ID "
> + "or base address"));
> +
> + return false;
> + }
> + }
> +
> return true;
> }
>
Would this only be possibly true for an offline migration? It would
seem an online/live migration that guest startup and continued running
of libvirtd would seemingly fill in the values. Then if libvirtd is
restarted, the cached copy of the guest with the addresses is read. If
the qemuProcessAttach code is implemented, then we have an address.
Could this be because we 'ignore' the -2 failures in patch 5? However,
if we do, then we've never "really" added support for this
functionality. Of course if the target of the migration does have it,
then there's issues.
While what's being checked is valid and safely protects us against some
unintended mutilation and thus I'd say ACK for just the safety reasons,
I'm mostly curious as to the why. Other checks in the API seem to be
valid you are not allowed to migrate because we said you couldn't
migrate with snapshots, block job running non-USB host devices, or with
a specific CPU feature enabled. But, this seems to be - something went
wrong and we decided to ignore it, so you cannot migrate this guest. Is
there "anything" we could do to possible fill in the values so that we
don't cause failure because of some decision point in libvirt? Of course
we couldn't have already gone through this in previous reviews, but my
"short term memory" would have been unplugged ;-)
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list