Bug 1729817
Summary: | memfd migration failed - qemu-kvm: Unknown ramblock "/objects/ram-node0", cannot accept migration | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | Jing Qi <jinqi> |
Component: | qemu-kvm | Assignee: | Virtualization Maintenance <virt-maint> |
qemu-kvm sub component: | Live Migration | QA Contact: | Jing Qi <jinqi> |
Status: | CLOSED CURRENTRELEASE | Docs Contact: | |
Severity: | medium | ||
Priority: | unspecified | CC: | fjin, jdenemar, jen, jsuchane, marcandre.lureau, mprivozn, mrezanin, pkrempa, virt-maint, xuzhang |
Version: | 8.0 | Keywords: | Triaged |
Target Milestone: | rc | ||
Target Release: | 8.0 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-03-18 02:54:58 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jing Qi
2019-07-15 02:46:54 UTC
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.224.176's password: root.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. |