Description of problem: Failed to hot-plug vcpus Version-Release number of selected component (if applicable): qemu-kvm-4.1.0-1.module+el8.1.0+3966+4a23dca1.x86_64 libvirt-5.6.0-1.virtcov.el8.x86_64 kernel-4.18.0-129.el8.x86_64 How reproducible: 100% Steps to Reproduce: 1. Prepare a running VM with the following vcpus conf # virsh domstate test running # virsh vcpucount test maximum config 4 maximum live 4 current config 2 current live 2 2. Hot-plug vcpu and check stap info # virsh setvcpus test 3 --live error: internal error: unable to execute QEMU command 'device_add': Invalid CPU die-id: 4294967295 must be in range 0:3 # stap /usr/share/doc/libvirt-docs/examples/systemtap/qemu-monitor.stp 0.000 begin 2.943 > 0x7f62ec025900 {"execute":"device_add","arguments":{"driver":"Skylake-Server-IBRS-x86_64-cpu","id":"vcpu2","socket-id":2,"core-id":0,"thread-id":0},"id":"libvirt-280"} 2.948 < 0x7f62ec025900 {"id": "libvirt-280", "error": {"class": "GenericError", "desc": "Invalid CPU die-id: 4294967295 must be in range 0:3"}} Actual results: As step-2 shows Expected results: Hot-plugging should succeed Additional info: Can not reproduce this issue on qemu-kvm-4.0.0-6.module+el8.1.0+3736+a2aefea3.x86_64
I guess it's same issue as bug 1741151.
It looks like libvirt isn't following the expected interface for CPU hotplug. Understadable, as the documentation is sparse, and the paragraph below is easy to miss. Documentation for CpuInstanceProperties says: # Note: currently there are 5 properties that could be present # but management should be prepared to pass through other # properties with device_add command to allow for future # interface extension. This also requires the filed names to be kept in # sync with the properties passed to -device/device_add. If query-hotpluggable-cpus returns die-id=0 (which is the case in QEMU 4.1), libvirt should include die-id=0 in -device and device_add. We could make the interface a bit more flexible, though, and make die-id optional if there's only one possible value for it. I will submit a patch to QEMU upstream to make it more flexible, but I suggest we also change libvirt to follow the quoted paragraph above, and copy every single property from query-hotpluggable-cpus[].props.
(In reply to jiyan from comment #0) > # virsh setvcpus test 3 --live > error: internal error: unable to execute QEMU command 'device_add': Invalid > CPU die-id: 4294967295 must be in range 0:3 This error message is incorrect. In this case, die-id must be in range 0:0. I'm tracking this issue at bz#1741151.
Fix submitted upstream: https://lore.kernel.org/qemu-devel/20190815183803.13346-4-ehabkost@redhat.com/
(In reply to Eduardo Habkost from comment #4) > (In reply to jiyan from comment #0) > > # virsh setvcpus test 3 --live > > error: internal error: unable to execute QEMU command 'device_add': Invalid > > CPU die-id: 4294967295 must be in range 0:3 > > This error message is incorrect. In this case, die-id must be in range 0:0. > I'm tracking this issue at bz#1741151. If so, should we close this bz and track bz1741151? Best regards, Junyi
(In reply to juzhang from comment #6) > > This error message is incorrect. In this case, die-id must be in range 0:0. > > I'm tracking this issue at bz#1741151. > > If so, should we close this bz and track bz1741151? I prefer like to keep this one open because it's about the most serious issue (libvirt integration failing). bz 1741151 can be used to track the less serious issues with the error messages
Verify: qemu-kvm-4.1.0-5.module+el8.1.0+4076+b5e41ebc libvirt-client-5.6.0-2.module+el8.1.0+4015+63576633.x86_64 kernel-4.18.0-131.el8.x86_64 Test with virsh, hotplug vcpus successfully, and guest work well. # virsh start rhel8 Domain rhel8 started # virsh domstate rhel8 running # virsh vcpucount rhel8 maximum config 8 maximum live 8 current config 4 current live 4 # virsh setvcpus rhel8 6 --live # virsh vcpucount rhel8 maximum config 8 maximum live 8 current config 4 current live 6 # virsh domstate rhel8 running
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3723