RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1233023 - Guest can not be started when vcpu placement auto is set
Summary: Guest can not be started when vcpu placement auto is set
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.2
Hardware: ppc64le
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Andrea Bolognani
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-18 05:33 UTC by Dan Zheng
Modified: 2015-08-14 06:17 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-14 06:17:53 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Dan Zheng 2015-06-18 05:33:10 UTC 
Description of problem:
When vcpu placement auto is set, guest can not be started.

Version-Release number of selected component (if applicable):
libvirt-1.2.16-1.el7.ppc64le
qemu-kvm-rhev-2.3.0-2.el7.ppc64le
kernel-3.10.0-229.ael7b.ppc64le

How reproducible:
100%

Steps to Reproduce:
1. Prepare a guest with XMl setting below:
 <vcpu placement='auto'>4</vcpu>

2. Start the guest and get failure
# virsh start dzhengvm1
error: Failed to start domain dzhengvm1
error: invalid argument: Failed to parse bitmap ''

3. Check libvirtd.log
 ---libvirtd.log---
2015-06-18 01:45:39.714+0000: 88235: error : virCommandWait:2552 : internal error: Child process (/bin/numad -w 4:1000) unexpected exit status 1
2015-06-18 01:45:39.714+0000: 88235: error : virNumaGetAutoPlacementAdvice:72 : internal error: Failed to query numad for the advisory nodeset
2015-06-18 01:45:39.714+0000: 88235: error : virBitmapParse:423 : invalid argument: Failed to parse bitmap ''

4. Check numad can run standalone and works correctly. 
# numad -w 4:1000
0

5. Check guest log
2015-06-18 05:22:00.396+0000: shutting down

Actual results:
Guest fails to start with below errors:
error: Failed to start domain dzhengvm1
error: invalid argument: Failed to parse bitmap ''



Expected results:
The guest should be able to start.

Additional info:
[root@ibm-p8-kvm-02-qe /]# numactl --hardware
available: 4 nodes (0-1,16-17)
node 0 cpus: 0 8 16 24 32
node 0 size: 65536 MB
node 0 free: 45897 MB
node 1 cpus: 40 48 56 64 72
node 1 size: 65536 MB
node 1 free: 48205 MB
node 16 cpus: 80 88 96 104 112
node 16 size: 65536 MB
node 16 free: 47374 MB
node 17 cpus: 120 128 136 144 152
node 17 size: 65536 MB
node 17 free: 53089 MB
node distances:
node   0   1  16  17 
  0:  10  20  40  40 
  1:  20  10  40  40 
 16:  40  40  10  20 
 17:  40  40  20  10 

[root@ibm-p8-kvm-02-qe /]# virsh nodeinfo
CPU model:           ppc64le
CPU(s):              20
CPU frequency:       3690 MHz
CPU socket(s):       1
Core(s) per socket:  160
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         263635264 KiB
Comment 2 Wayne Sun 2015-06-30 08:48:26 UTC 
This is not 100% reproducible

Tested with
pkgs:
libvirt-1.2.16-1.el7.ppc64le
qemu-kvm-rhev-2.3.0-5.el7.ppc64le
kernel-3.10.0-282.el7.ppc64le

# virsh dumpxml virt-tests-debug-clone
...
  <vcpu placement='auto'>5</vcpu>
...

# virsh start virt-tests-debug-clone
Domain virt-tests-debug-clone started
Comment 3 Andrea Bolognani 2015-08-13 09:48:24 UTC 
After a dozen attempts I wasn't able to reproduce the issue.

I'm using the following packages:

  kernel-3.10.0-302.el7.ppc64le
  qemu-kvm-rhev-2.3.0-16.el7.ppc64le
  libvirt-daemon-1.2.17-4.el7.ppc64le

Do you still run into the issue on an updated host?
Comment 4 Dan Zheng 2015-08-14 02:01:02 UTC 
(In reply to Andrea Bolognani from comment #3)
> After a dozen attempts I wasn't able to reproduce the issue.
> 
> I'm using the following packages:
> 
>   kernel-3.10.0-302.el7.ppc64le
>   qemu-kvm-rhev-2.3.0-16.el7.ppc64le
>   libvirt-daemon-1.2.17-4.el7.ppc64le
> 
> Do you still run into the issue on an updated host?

Using above packages, I can not reproduce it any more. Pls close it. Thanks.
Note You need to log in before you can comment on or make changes to this bug.