In the bug description, the target machine is  8.1.0 AV -
 
version : libvirt-5.5.0-1.virtcov.el8.x86_64  & qemu-kvm-4.0.0-5.module+el8.1.0+3622+5812d9bf.x86_64.

And tried to migrate the domain to target machine with 8.0.1 AV and the migration can succeed.

Marc-Andre, is this even supported on qemu side?

Yes, it should work, but there was some complication related to ramblock naming, see upstream commit fa0cb34d2210cc749b9a70db99bb41c56ad20831 ("hostmem: use object id for memory region name with >= 4.0")

What is the machine version being used?

    <type arch='x86_64' machine='??'>hvm</type>

Are the qemu version different from src & dest?

Have you tried save & restore before doing migration?

(In reply to Jing Qi from comment #1)
> In the bug description, the target machine is  8.1.0 AV -
>  
> version : libvirt-5.5.0-1.virtcov.el8.x86_64  &
> qemu-kvm-4.0.0-5.module+el8.1.0+3622+5812d9bf.x86_64.
> 
> And tried to migrate the domain to target machine with 8.0.1 AV and the
> migration can succeed.

Ok, so?

 qemu-kvm-3.1.0 -> qemu-kvm-3.1.0 OK
 qemu-kvm-3.1.0 -> qemu-kvm-4.0.0 KO

Let's make sure the machine version is correct. We might be missing compat stuff for RHEL I suppose..

I tried with both machine type of  "pc-q35-rhel8.0.0" & "pc-i440fx-rhel7.6.0".

I tried with both machine type of  "pc-q35-rhel8.0.0" & "pc-i440fx-rhel7.6.0".

I tried with the newer qemu-kvm version of rhel8.1.0av  for target machine:
qemu-kvm-4.1.0-23.module+el8.1.1+5938+f5e53076.2.x86_64
 
The source qemu-kvm version:
qemu-kvm-3.1.0-30.module+el8.0.1+4607+7ea9baa9.2.x86_64

It reports different error message:
virsh migrate avocado-vm1 qemu+ssh://10.73.224.176/system --live --verbose   
root@10.73.224.176's password: 
root@10.73.224.176's password: 
error: internal error: process exited while connecting to monitor: 2020-03-11T09:25:40.349373Z qemu-kvm: -object memory-backend-memfd,id=ram-node0,size=1073741824: invalid object type: memory-backend-memfd

Marc-Andre,
I have sent an email including the machines' info to you. 

For the second issue, shall we need a bug for it?

Thanks,

Jing Qi

(In reply to Jing Qi from comment #9)
> For the second issue, shall we need a bug for it?

Yes, please

Hi Miroslav,

since rhel-7.6 ~ qemu-3.0,
why pc_machine_rhel760_options() doesn't chain up to pc_i440fx_3_1_machine_options() ? (there is no rhel8 machine)

fwiw, pc_q35_machine_rhel760_options() chains up to pc_q35_machine_rhel800_options() which seems correct.

In qemu-kvm-4.2 we have:

static void pc_machine_rhel760_options(MachineClass *m)
{
    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
    pc_machine_rhel7_options(m);
    m->desc = "RHEL 7.6.0 PC (i440FX + PIIX, 1996)";
    m->async_pf_vmexit_disable = true;
    m->smbus_no_migration_support = true;
    pcmc->pvh_enabled = false;
    pcmc->default_cpu_version = CPU_VERSION_LEGACY;
    compat_props_add(m->compat_props, hw_compat_rhel_8_1, hw_compat_rhel_8_1_len);
    compat_props_add(m->compat_props, pc_rhel_8_1_compat, pc_rhel_8_1_compat_len);
    compat_props_add(m->compat_props, hw_compat_rhel_8_0, hw_compat_rhel_8_0_len);
    compat_props_add(m->compat_props, pc_rhel_8_0_compat, pc_rhel_8_0_compat_len);
    compat_props_add(m->compat_props, hw_compat_rhel_7_6, hw_compat_rhel_7_6_len);
    compat_props_add(m->compat_props, pc_rhel_7_6_compat, pc_rhel_7_6_compat_len);
}

In qemu-kvm-4.1:

static void pc_machine_rhel760_options(MachineClass *m)
{
    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
    pc_machine_rhel7_options(m);
    m->desc = "RHEL 7.6.0 PC (i440FX + PIIX, 1996)";
    m->async_pf_vmexit_disable = true;
    m->smbus_no_migration_support = true;
    pcmc->pvh_enabled = false;
    pcmc->default_cpu_version = CPU_VERSION_LEGACY;
    compat_props_add(m->compat_props, hw_compat_rhel_8_0, hw_compat_rhel_8_0_len);
    compat_props_add(m->compat_props, pc_rhel_8_0_compat, pc_rhel_8_0_compat_len);
    compat_props_add(m->compat_props, hw_compat_rhel_7_6, hw_compat_rhel_7_6_len);
    compat_props_add(m->compat_props, pc_rhel_7_6_compat, pc_rhel_7_6_compat_len);
}

The rhel8 lines were added by commit 0784125ba3ccd72a590d210cf3f52d80e96b4263 ("x86 machine types: add pc-q35-rhel8.1.0").

I think we need similar lines for qemu-kvm-4.0

Even with:
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 37907fe76a..348228b329 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -1029,6 +1029,7 @@ static void pc_machine_rhel760_options(MachineClass *m)
     pc_machine_rhel7_options(m);
     m->desc = "RHEL 7.6.0 PC (i440FX + PIIX, 1996)";
     m->async_pf_vmexit_disable = true;
+    compat_props_add(m->compat_props, hw_compat_rhel_8_0, hw_compat_rhel_8_0_len);
     compat_props_add(m->compat_props, hw_compat_rhel_7_6, hw_compat_rhel_7_6_len);
     compat_props_add(m->compat_props, pc_rhel_7_6_compat, pc_rhel_7_6_compat_len);
 }

I get: "Missing section footer for 0000:00:01.3/piix4_pm"

(In reply to Marc-Andre Lureau from comment #12)
> I think we need similar lines for qemu-kvm-4.0

I don't think we ever released a qemu-kvm-4.0 package to customers.

So is this a qemu bug then? Should we move it to qemu? Or does it require a libvirt copy?

It's qemu.  I sent a patch to rhvirt: "[RHEL-AV-8.1.0 qemu-kvm PATCH] piix: chain up to rhel8.0 compat properties".

But apparently that version of qemu, rhel-av-8.1.0/master-4.0.0, isn't maintained.

Since the qemu-4.1.0 is the released version for rhel-av-8.1.0 and the bug happened in qemu-4.0.0, the bug doesn't need an extra patch, right?  And the memfd type was decided to be not supported in rhel-av-8.1.0 / qemu-4.1.0-23 at last.

Clearing stale needinfo in comment 11.