Bug 492139

IMHO there is no need for any dependancy from kernel-xen -> xen RPMs to solve this. The cpuspeed initscript should simply test to see whether xm exists, eg

  test -x /usr/bin/xm

and not try running it if it doesn't exist.

Yeah, I have to say I agree with Dan about this one; it's a simple one-line change to cpuspeed, so I think we should do it that way, rather than changing the dependencies.  After all, technically, kernel-xen does not depend on xen; you can happily run the xen kernel without the tools (although it's kind of useless).

Chris Lalancette

(In reply to comment #1)
> The cpuspeed initscript should simply test to see whether xm exists, eg
> 
>   test -x /usr/bin/xm
> 
> and not try running it if it doesn't exist.  

the catch is that it uses xm to find pcpus and vcpus numbers, see bug #488924

I am not sure if this can be worked around ... adding a dependency seemed obvious to me, let's go ahead if there is a better way

IMHO this problem doesn't justify adding the dependancy. The usage in question:

    if [ -d "$xendir" ]; then
      vcpus=$(xm list Domain-0 | tail -n 1 | awk '{print $4}')
      pcpus=$(xm info | grep nr_cpus | awk '{print $3}')
      if [ "$vcpus" -ne "$pcpus" ]; then
        echo "CPU freq scaling under Xen when vcpus != pcpus is not supported"
        return 6
      fi
    fi


is merely adding a sanity check. 

It is easy enough to work deal with the lack of 'xm', by adding a further check just before this

  if [ -d "$xendir" && ! -x /usr/bin/xm ]; then
      echo  "Not running CPU freq scaling under Xen because xm is not installed"
      return r6
  fi

isn't there a way how to get the numbers without running the xen service and using xm? - to me it seems unfortunate to give up on cpufreq completely just because of this ... although it is not that important, as I see it only as a marginal case resulting from misconfiguration rather than desired system setup

let's see what Jarod thinks about it ...?

The use of xm was about all clalance and I could come up with when discussing the matter. The problem is that one of the two numbers comes from the hypervisor, and the only way I'm aware of to query into the hypervisor is via an xm call. Sure, we could grep /proc/cpuinfo on dom0 to get its vcpu count, but we're still stuck needing a way to get info out of the hypervisor. I think Dan's suggestion in comment #5 looks sane. This is just a corner-case sanity check, not something to get horribly worried about.

The only other thing we might want to add is a check to see that xm can actually connect to xend. I think this might actually cover that and the check to see that xm is present:

if [ -d "$xendir" ]; then
  foo=$(xm list 2>&1 > dev/null)
  if [ $? -ne 0 ]; then
    echo "No soup for you, unable to talk to xend."
    return 6
  fi
fi

If xm is missing $? should be 127. If is present but can't connect to xend, $? should be 1. If all is well, we get 0. Sound like a plan?

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0424.html