[libvirt] Libvirt /proc/cpuinfo processing fails on Linux/Sparc
Below is what /proc/cpuinfo looks like on an Ultrasparc T1 running Linux. I haven't looked into it in detail yet, but the report from Dennis Gilmore is that this breaks every libvirt command. Presumably we are parsing /proc/cpuinfo at libvirt startup ... (Initially reported by Dennis Gilmore) Rich. cpu : UltraSparc T1 (Niagara) fpu : UltraSparc T1 integrated FPU prom : OBP 4.29.0.a 2008/09/15 11:59 type : sun4v ncpus probed : 32 ncpus active : 32 D$ parity tl1 : 0 I$ parity tl1 : 0 Cpu0ClkTck : 000000003b9aca00 Cpu1ClkTck : 000000003b9aca00 Cpu2ClkTck : 000000003b9aca00 Cpu3ClkTck : 000000003b9aca00 Cpu4ClkTck : 000000003b9aca00 Cpu5ClkTck : 000000003b9aca00 Cpu6ClkTck : 000000003b9aca00 Cpu7ClkTck : 000000003b9aca00 Cpu8ClkTck : 000000003b9aca00 Cpu9ClkTck : 000000003b9aca00 Cpu10ClkTck : 000000003b9aca00 Cpu11ClkTck : 000000003b9aca00 Cpu12ClkTck : 000000003b9aca00 Cpu13ClkTck : 000000003b9aca00 Cpu14ClkTck : 000000003b9aca00 Cpu15ClkTck : 000000003b9aca00 Cpu16ClkTck : 000000003b9aca00 Cpu17ClkTck : 000000003b9aca00 Cpu18ClkTck : 000000003b9aca00 Cpu19ClkTck : 000000003b9aca00 Cpu20ClkTck : 000000003b9aca00 Cpu21ClkTck : 000000003b9aca00 Cpu22ClkTck : 000000003b9aca00 Cpu23ClkTck : 000000003b9aca00 Cpu24ClkTck : 000000003b9aca00 Cpu25ClkTck : 000000003b9aca00 Cpu26ClkTck : 000000003b9aca00 Cpu27ClkTck : 000000003b9aca00 Cpu28ClkTck : 000000003b9aca00 Cpu29ClkTck : 000000003b9aca00 Cpu30ClkTck : 000000003b9aca00 Cpu31ClkTck : 000000003b9aca00 MMU Type : Hypervisor (sun4v) State: CPU0: online CPU1: online CPU2: online CPU3: online CPU4: online CPU5: online CPU6: online CPU7: online CPU8: online CPU9: online CPU10: online CPU11: online CPU12: online CPU13: online CPU14: online CPU15: online CPU16: online CPU17: online CPU18: online CPU19: online CPU20: online CPU21: online CPU22: online CPU23: online CPU24: online CPU25: online CPU26: online CPU27: online CPU28: online CPU29: online CPU30: online CPU31: online -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
On Mon, Feb 09, 2009 at 01:37:14PM +0000, Richard W.M. Jones wrote:
Below is what /proc/cpuinfo looks like on an Ultrasparc T1 running Linux.
I haven't looked into it in detail yet, but the report from Dennis Gilmore is that this breaks every libvirt command. Presumably we are parsing /proc/cpuinfo at libvirt startup ...
It shouldn't break libvirt startup AFAICT. We use this info for the virNodeInfo command obviously, but also when starting a new guest for purpose of CPU pinning. The latter is probably better off with us using numactl or a sysconf() macro determine max # of pCPUs available, since we don't need the full socket,core, thread topology in that context.
(Initially reported by Dennis Gilmore)
Don't suppose Dennis has a patch to add support for this ? He mentioned he was going to work on one when this came up on IRC a week or so back. FWIW, we'll need to add logic to src/nodeinfo.c to make the /proc/cpuinfo fields it looks for be architecture dependant since this stuff varies across basically every architecture. I expect ia64, ppc, s390, etc are all just as broken in this regard. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, Feb 09, 2009 at 01:48:58PM +0000, Daniel P. Berrange wrote:
On Mon, Feb 09, 2009 at 01:37:14PM +0000, Richard W.M. Jones wrote:
Below is what /proc/cpuinfo looks like on an Ultrasparc T1 running Linux.
I haven't looked into it in detail yet, but the report from Dennis Gilmore is that this breaks every libvirt command. Presumably we are parsing /proc/cpuinfo at libvirt startup ...
It shouldn't break libvirt startup AFAICT. We use this info for the virNodeInfo command obviously, but also when starting a new guest for purpose of CPU pinning. The latter is probably better off with us using numactl or a sysconf() macro determine max # of pCPUs available, since we don't need the full socket,core, thread topology in that context.
(Initially reported by Dennis Gilmore)
Don't suppose Dennis has a patch to add support for this ? He mentioned he was going to work on one when this came up on IRC a week or so back.
No. I'm waiting to get some more details, and I also now have access to his Sparc machine so I can test this myself. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
OK so the report is that NOT all commands fail. 'virsh nodeinfo' fails with: libvir: error : no cpus found Other commands work, eg. 'virsh list --all' is fine. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
Here's another error, starting the default network: <dgilmore> libvir: error : internal error '/usr/sbin/brctl setfd virbr0 0' exited with non-zero status 1 and signal 0: set forward delay failed: Operation not supported <dgilmore> Failed to autostart network 'default': internal error '/usr/sbin/brctl setfd virbr0 0' exited with non-zero status 1 and signal 0: set forward delay failed: Operation not supported Trying to use brctl manually on the same machine: # /usr/sbin/brctl setfd virbr0 0 set forward delay failed: Operation not supported I'm getting info on what kernel version he's running. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
On Mon, Feb 09, 2009 at 03:20:06PM +0000, Richard W.M. Jones wrote:
Here's another error, starting the default network:
<dgilmore> libvir: error : internal error '/usr/sbin/brctl setfd virbr0 0' exited with non-zero status 1 and signal 0: set forward delay failed: Operation not supported <dgilmore> Failed to autostart network 'default': internal error '/usr/sbin/brctl setfd virbr0 0' exited with non-zero status 1 and signal 0: set forward delay failed: Operation not supported
Trying to use brctl manually on the same machine:
# /usr/sbin/brctl setfd virbr0 0 set forward delay failed: Operation not supported
I'm getting info on what kernel version he's running.
Very odd, this smells like a kernel bug to me. I see no reason why the 'forward delay' parameter should not be available on Sparc, since this bridge code is not arch specific. Perhaps a missing CONFIG option in the Fedora sparc kernel build Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Mon, Feb 09, 2009 at 03:20:06PM +0000, Richard W.M. Jones wrote:
I'm getting info on what kernel version he's running.
It is: 2.6.27.12-78.2.8.fc9.sparc64.smp Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
participants (2)
-
Daniel P. Berrange -
Richard W.M. Jones