Bug 425791 - oprofiled can't be started more than once in guests
oprofiled can't be started more than once in guests
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
5.1
All Linux
low Severity low
: ---
: ---
Assigned To: Markus Armbruster
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-15 13:19 EST by Markus Armbruster
Modified: 2007-12-16 03:43 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-16 03:43:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Markus Armbruster 2007-12-15 13:19:06 EST
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
guest).

How reproducible:
Always.

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
gripe.
Comment 1 Markus Armbruster 2007-12-16 02:11:19 EST
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 03:43:16 EST
Things work with step 5
opcontrol --start-daemon --no-vmlinux --xen=none --active-domains=`virsh domid
rhel5pv`

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.