On Fri, Mar 13, 2015 at 10:38:57 -0400, John Ferlan wrote:
>
>
> 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.
This is to prevent online migration in case where qemu doesn't due to a
failure report the addresses that were used for the module.
>
> 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.
The actual hotplug code adds another place that may potentialy fail to
fill the info on a failure but will not inhibit/fail the hotplug
operation as it's improbable that we could recover from that due to the
fact that at the point the device was exposed to the guest.
>
> 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
Peter
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list