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.
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.
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.