[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