Bug 425791 - oprofiled can't be started more than once in guests
Summary: oprofiled can't be started more than once in guests
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen   
(Show other bugs)
Version: 5.1
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Markus Armbruster
QA Contact: Martin Jenner
Depends On:
TreeView+ depends on / blocked
Reported: 2007-12-15 18:19 UTC by Markus Armbruster
Modified: 2007-12-16 08:43 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-16 08:43:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Markus Armbruster 2007-12-15 18:19:06 UTC
Description of problem:
oprofiled can be started only once in an active Xenoprof domain.  Subsequent
attempts fail.

Version-Release number of selected component (if applicable):
Observed with oprofile-0.9.2-6.el5 and kernel-xen-2.6.18-58.el5 (both host and

How reproducible:

Steps to Reproduce:
0. Reboot host and guest (guest domid is 1)
1. In the host: opcontrol --start-daemon --no-vmlinux --xen=none --active-domains=1
2. In the guest: opcontrol --start --no-vmlinux --xen=none
3. In the host: opcontrol --start; opcontrol --stop; opcontrol --shutdown
4. In the guest: opcontrol --shutdown
5. (Optional, doesn't make a difference) in the host: opcontrol --start-daemon
6. In the guest: opcontrol --start-daemon

Actual results:
Steps 1.-5. succeed, step 6 fails: oprofiled refuses to start.  Hypervisor gripes:
(XEN) xenoprof: operation 8 failed for dom 2 (status : -1)

Expected results:
All steps succeed.  oprofiled runs in guest after step 6.  Hypervisor does not

Comment 1 Markus Armbruster 2007-12-16 07:11:19 UTC
This appears *not* to be a regression: I downgraded Xen-related packages to GA
(kernel-xen-2.6.18-8.el5.x86_64.rpm python-virtinst-0.99.0-2.el5.noarch.rpm
libvirt-python-0.1.8-15.el5.x86_64.rpm virt-manager-0.2.6-7.el5.x86_64.rpm
libvirt-0.1.8-15.el5.x86_64.rpm xen-3.0.3-25.el5.x86_64.rpm
xen-libs-3.0.3-25.el5.x86_64.rpm), and can still reproduce the bug.

Comment 2 Markus Armbruster 2007-12-16 08:43:16 UTC
Things work with step 5
opcontrol --start-daemon --no-vmlinux --xen=none --active-domains=`virsh domid

The failing restart behavior is identical to what happens when you do step 2
before step 1, i.e. when you try to start the guest before the host.

Looks like things work as (mis-)designed.

Note You need to log in before you can comment on or make changes to this bug.