On Fri, Sep 16, 2016 at 10:16:31AM +0200, Peter Krempa wrote:
On Thu, Sep 15, 2016 at 18:14:35 +0200, Martin Kletzander wrote:
> Such migration wouldn't work anyway with QEMU, we just haven't checked
> for it before.
>
> Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com>
> ---
> src/qemu/qemu_migration.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
> index e734816c4e12..d29b52b7aefa 100644
> --- a/src/qemu/qemu_migration.c
> +++ b/src/qemu/qemu_migration.c
> @@ -2346,6 +2346,19 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver,
> return false;
> }
> }
> +
> + for (i = 0; i < vm->def->nshmems; i++) {
> + virDomainShmemDefPtr shmem = vm->def->shmems[i];
> +
> + if (shmem->role != VIR_DOMAIN_SHMEM_ROLE_MASTER) {
> + virReportError(VIR_ERR_OPERATION_INVALID,
> + _("domain's shmem device '%s' has
role='%s', "
This includes "default" which may sound weird. You probably should
convert "default" to something sane beforehand.
I can do a switch, I just wanted to forbid it for anything else than
explicitly stated 'master' (in case there's more later). Default should
not be here any more since postparse callback will make that into
master/peer anyway.
> + "try unplugging it
first"),
I strongly disagree suggesting to the users to try hot(un)plug. Just
state that migration is not supported with such config.
OK, I'm fine with that.
Peter