[libvirt] [PATCHv2.5 06/10] qemu: migration: Forbid migration with memory modules lacking info

Peter Krempa pkrempa at redhat.com
Mon Mar 16 16:06:14 UTC 2015


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150316/cb70cc42/attachment-0001.sig>


More information about the libvir-list mailing list