Bug 2004429

Summary:	Can't get vcpuinfo when the guest is shutoff
Product:	Red Hat Enterprise Linux 9	Reporter:	Meina Li <meili>
Component:	libvirt	Assignee:	Peter Krempa <pkrempa>
libvirt sub component:	General	QA Contact:	Luyao Huang <lhuang>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	unspecified
Priority:	high	CC:	jdenemar, lhuang, pkrempa, virt-maint, weizhan, xuzhang
Version:	9.0	Keywords:	Automation, Regression, Triaged
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	libvirt-7.7.0-3.el9	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-17 12:45:32 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 Meina Li 2021-09-15 09:41:41 UTC

Description of problem:
Can't get vcpuinfo when the guest is shutoff

Version-Release number of selected component (if applicable):
libvirt-7.7.0-1.el9.x86_64
qemu-kvm-6.1.0-2.el9.x86_64
kernel-5.14.0-1.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Prepare a shutoff guest.
# virsh domstate avocado-vt-vm1
shut off

2. Setvcpus to the guest.
# virsh setvcpus avocado-vt-vm1 1  --config

3. Check the vcpucount.
# virsh vcpucount avocado-vt-vm1
maximum      config         2
current      config         1

4. Check the vcpuinfo.
# virsh vcpuinfo avocado-vt-vm1
---no output


Actual results:
Can't get vcpuinfo when the guest is shutoff

Expected results:
Can get vcpuinfo even though the guest is off

Additional info:
auto case: virsh.setvcpus.normal_test.guest_off.option_config

Comment 1 Meina Li 2021-09-15 10:04:48 UTC

Can't reproduce in the last version: libvirt-7.6.0-2.el9.x86_64

Comment 2 Peter Krempa 2021-09-15 13:03:06 UTC

I've traced this to one of cleanup refactors of XML parsing in commit bd1f40fe7d4

Comment 3 Peter Krempa 2021-09-15 13:32:33 UTC

Fixed upstream:

commit eb2e317c65fdbbf45117d5f423da12870842cc59
Author: Peter Krempa <pkrempa>
Date:   Wed Sep 15 15:13:24 2021 +0200

    virshDomainGetVcpuBitmap: Refactor cleanup
    
    Rename the temp variable that is being returned and use automatic
    pointer clearing for it.
    
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Pavel Hrdina <phrdina>
    Reviewed-by: Jiri Denemark <jdenemar>
    Reviewed-by: Jonathon Jongsma <jjongsma>

commit 59e74c319384b766a50669c6248222da0cf10fd0
Author: Peter Krempa <pkrempa>
Date:   Wed Sep 15 15:09:00 2021 +0200

    virshDomainGetVcpuBitmap: Return bitmap when taking the fallback path
    
    In case the specific VCPU states are not present in the XML we were
    taking a fallback code path just noting that all cpus of the VM are
    enabled.
    
    This was broken by a mistake in a recent refactor where a 'goto cleanup'
    was mistakenly replaced by a 'return NULL'. This broke reporting of cpus
    and also caused a memory leak.
    
    Return the fallback cpu map.
    
    Fixes: bd1f40fe7d4
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2004429
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Pavel Hrdina <phrdina>
    Reviewed-by: Jiri Denemark <jdenemar>
    Reviewed-by: Jonathon Jongsma <jjongsma>

Comment 4 Luyao Huang 2021-10-15 02:19:38 UTC

Test passed on libvirt-7.8.0-1.el9.x86_64

Comment 7 Luyao Huang 2021-11-01 07:44:52 UTC

Verify this bug with libvirt-7.8.0-1.el9.x86_64:


# virsh domstate vm1
shut off

# virsh setvcpus vm1 1  --config


# virsh vcpucount vm1
maximum      config         2
current      config         1

# virsh vcpuinfo vm1
VCPU:           0
CPU:            N/A
State:          N/A
CPU time        N/A
CPU Affinity:   yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

Comment 9 errata-xmlrpc 2022-05-17 12:45:32 UTC

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 (new packages: libvirt), 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-2022:2390