Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1066630 - virsh capabilities has no <guest> sections (ppc64)
Summary: virsh capabilities has no <guest> sections (ppc64)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: ppc64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs 1059428
TreeView+ depends on / blocked
 
Reported: 2014-02-18 18:22 UTC by Richard W.M. Jones
Modified: 2014-02-18 18:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-18 18:38:37 UTC
Embargoed:

Attachments (Terms of Use)
libvirt daemon debugging (90.61 KB, text/plain)
2014-02-18 18:37 UTC, Richard W.M. Jones 		no flags Details
View All

Description Richard W.M. Jones 2014-02-18 18:22:13 UTC 
Description of problem:

This is the output of

  $ ./run ./tools/virsh capabilities

non-root, on libvirt, compiled from git today, on ppc64 (Fedora Rawhide).

<capabilities>

  <host>
    <uuid>dfe785c8-06f9-48d6-b57b-87fb00abc31c</uuid>
    <cpu>
      <arch>ppc64</arch>
      <model>POWER7+_v2.1</model>
      <vendor>IBM</vendor>
      <topology sockets='1' cores='8' threads='4'/>
    </cpu>
    <power_management>
      <suspend_mem/>
      <suspend_disk/>
      <suspend_hybrid/>
    </power_management>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='2'>
        <cell id='0'>
          <memory unit='KiB'>65950848</memory>
          <cpus num='32'>
            <cpu id='0'/>
            <cpu id='1'/>
            <cpu id='2'/>
            <cpu id='3'/>
            <cpu id='4'/>
            <cpu id='5'/>
            <cpu id='6'/>
            <cpu id='7'/>
            <cpu id='8'/>
            <cpu id='9'/>
            <cpu id='10'/>
            <cpu id='11'/>
            <cpu id='12'/>
            <cpu id='13'/>
            <cpu id='14'/>
            <cpu id='15'/>
            <cpu id='16'/>
            <cpu id='17'/>
            <cpu id='18'/>
            <cpu id='19'/>
            <cpu id='20'/>
            <cpu id='21'/>
            <cpu id='22'/>
            <cpu id='23'/>
            <cpu id='24'/>
            <cpu id='25'/>
            <cpu id='26'/>
            <cpu id='27'/>
            <cpu id='28'/>
            <cpu id='29'/>
            <cpu id='30'/>
            <cpu id='31'/>
          </cpus>
        </cell>
        <cell id='1'>
          <memory unit='KiB'>64435520</memory>
          <cpus num='32'>
            <cpu id='32'/>
            <cpu id='33'/>
            <cpu id='34'/>
            <cpu id='35'/>
            <cpu id='36'/>
            <cpu id='37'/>
            <cpu id='38'/>
            <cpu id='39'/>
            <cpu id='40'/>
            <cpu id='41'/>
            <cpu id='42'/>
            <cpu id='43'/>
            <cpu id='44'/>
            <cpu id='45'/>
            <cpu id='46'/>
            <cpu id='47'/>
            <cpu id='48'/>
            <cpu id='49'/>
            <cpu id='50'/>
            <cpu id='51'/>
            <cpu id='52'/>
            <cpu id='53'/>
            <cpu id='54'/>
            <cpu id='55'/>
            <cpu id='56'/>
            <cpu id='57'/>
            <cpu id='58'/>
            <cpu id='59'/>
            <cpu id='60'/>
            <cpu id='61'/>
            <cpu id='62'/>
            <cpu id='63'/>
          </cpus>
        </cell>
      </cells>
    </topology>
    <secmodel>
      <model>selinux</model>
      <doi>0</doi>
      <baselabel type='kvm'>system_u:system_r:svirt_t:s0</baselabel>
      <baselabel type='qemu'>system_u:system_r:svirt_tcg_t:s0</baselabel>
    </secmodel>
  </host>

The problem from a libguestfs point of view is there are
no <guest> sections at all.

Version-Release number of selected component (if applicable):

libvirt compiled from git today

How reproducible:

100%

Steps to Reproduce:
1. On ppc64, compile libvirt from git.
2. Kill any libvirtd processes running.
3. ./run ./tools/virsh capabilities (non-root)

Actual results:

See above.

Expected results:

Expect to see some <guest> sections.

Additional info:

qemu binaries are installed:

$ qemu-system-
qemu-system-alpha         qemu-system-mips64        qemu-system-sh4
qemu-system-arm           qemu-system-mips64el      qemu-system-sh4eb
qemu-system-cris          qemu-system-mipsel        qemu-system-sparc
qemu-system-i386          qemu-system-moxie         qemu-system-sparc64
qemu-system-lm32          qemu-system-or32          qemu-system-unicore32
qemu-system-m68k          qemu-system-ppc           qemu-system-x86_64
qemu-system-microblaze    qemu-system-ppc64         qemu-system-xtensa
qemu-system-microblazeel  qemu-system-ppcemb        qemu-system-xtensaeb
qemu-system-mips          qemu-system-s390x
Comment 1 Richard W.M. Jones 2014-02-18 18:27:02 UTC 
Also happens as root, with libvirt from Rawhide.

# rpm -qf `which virsh`
libvirt-client-1.2.0-1.fc21.ppc64
# systemctl restart libvirtd
# ps ax | grep libvirtd
45510 ?        Ssl    0:00 /usr/sbin/libvirtd
45616 pts/7    S+     0:00 grep --color=auto libvirtd
# virsh capabilities
<capabilities>

  <host>
    <uuid>6ac3b69a-7939-4ede-80d0-a9837723a8f1</uuid>
    <cpu>
      <arch>ppc64</arch>
      <model>POWER7+_v2.1</model>
      <vendor>IBM</vendor>
      <topology sockets='1' cores='8' threads='4'/>
    </cpu>
    <power_management>
      <suspend_mem/>
      <suspend_disk/>
      <suspend_hybrid/>
    </power_management>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='2'>
        <cell id='0'>
          <memory unit='KiB'>65950848</memory>
          <cpus num='32'>
            <cpu id='0'/>
            <cpu id='1'/>
            <cpu id='2'/>
            <cpu id='3'/>
            <cpu id='4'/>
            <cpu id='5'/>
            <cpu id='6'/>
            <cpu id='7'/>
            <cpu id='8'/>
            <cpu id='9'/>
            <cpu id='10'/>
            <cpu id='11'/>
            <cpu id='12'/>
            <cpu id='13'/>
            <cpu id='14'/>
            <cpu id='15'/>
            <cpu id='16'/>
            <cpu id='17'/>
            <cpu id='18'/>
            <cpu id='19'/>
            <cpu id='20'/>
            <cpu id='21'/>
            <cpu id='22'/>
            <cpu id='23'/>
            <cpu id='24'/>
            <cpu id='25'/>
            <cpu id='26'/>
            <cpu id='27'/>
            <cpu id='28'/>
            <cpu id='29'/>
            <cpu id='30'/>
            <cpu id='31'/>
          </cpus>
        </cell>
        <cell id='1'>
          <memory unit='KiB'>64435520</memory>
          <cpus num='32'>
            <cpu id='32'/>
            <cpu id='33'/>
            <cpu id='34'/>
            <cpu id='35'/>
            <cpu id='36'/>
            <cpu id='37'/>
            <cpu id='38'/>
            <cpu id='39'/>
            <cpu id='40'/>
            <cpu id='41'/>
            <cpu id='42'/>
            <cpu id='43'/>
            <cpu id='44'/>
            <cpu id='45'/>
            <cpu id='46'/>
            <cpu id='47'/>
            <cpu id='48'/>
            <cpu id='49'/>
            <cpu id='50'/>
            <cpu id='51'/>
            <cpu id='52'/>
            <cpu id='53'/>
            <cpu id='54'/>
            <cpu id='55'/>
            <cpu id='56'/>
            <cpu id='57'/>
            <cpu id='58'/>
            <cpu id='59'/>
            <cpu id='60'/>
            <cpu id='61'/>
            <cpu id='62'/>
            <cpu id='63'/>
          </cpus>
        </cell>
      </cells>
    </topology>
    <secmodel>
      <model>selinux</model>
      <doi>0</doi>
      <baselabel type='kvm'>system_u:system_r:svirt_t:s0</baselabel>
      <baselabel type='qemu'>system_u:system_r:svirt_tcg_t:s0</baselabel>
    </secmodel>
    <secmodel>
      <model>dac</model>
      <doi>0</doi>
      <baselabel type='kvm'>+107:+107</baselabel>
      <baselabel type='qemu'>+107:+107</baselabel>
    </secmodel>
  </host>

</capabilities>
Comment 2 Richard W.M. Jones 2014-02-18 18:37:12 UTC 
Created attachment 864677 [details]
libvirt daemon debugging

libvirtd deadlocks somehow if you enable debugging (log_level = 1).

I was only able to set log_level = 3, and attached is the result.

To cut a long story short, turns out to be some sort of strange
qemu linking problem:

symbol lookup error: /usr/bin/qemu-system-s390x: undefined symbo\
l: glfs_discard_async
Comment 3 Richard W.M. Jones 2014-02-18 18:38:37 UTC 
Fixed by updating glusterfs-devel to match the version
qemu was compiled against.
Comment 4 Richard W.M. Jones 2014-02-18 18:40:14 UTC 
BTW I think the bug here is that libvirt makes this kind
of problem (which I've had several times) excessively hard
to diagnose.

It should produce a "your qemu is totally broken" message
somewhere.  Perhaps the capabilities output could include
an informative section which shows the buggy output from
broken qemu?

<info>
  Could not run qemu-system-blah:
  "symbol lookup error: /usr/bin/qemu-system-s390x: undefined symbo\
l: glfs_discard_async"
</info>
Note You need to log in before you can comment on or make changes to this bug.