Bug 1370424

Created attachment 1194275 [details]
gdb log

Created attachment 1194276 [details]
guest xml

Created attachment 1194277 [details]
virt-manager debug log

The stack trace indicates that this assertion is hit in libguestfs:

https://github.com/libguestfs/libguestfs/blob/master/src/libvirt-domain.c#L613

xiaodwan, could you do me a favour and dump the XML of one guest:

  virsh dumpxml rhel6.7_spice

I suspect it has an unexpected port=0 attribute, or something like that.

Created attachment 1194306 [details]
rhel6.7_spice xml

Most probably the cause is in the 'gluster1' guest:

    <disk type='network' device='disk'>
      <driver name='qemu' type='raw'/>
      <source protocol='gluster' name='gluster-vol1/xdw.qcow2'>
        <host name='10.66.4.164'/>
      </source>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>

because the <host> tag has no "port" attribute.  I guess we could fallback to some default port depending on the protocol; I will see what libvirt does in this case.

(In reply to Pino Toscano from comment #8)
> I will see what libvirt does in this case.

http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_command.c;hb=HEAD#l436
(reformatted to make it shorter)

  static int qemuNetworkDriveGetPort(int protocol, const char *port)
  {
      int ret = 0;
      if (port) {
          if (virStrToLong_i(port, NULL, 10, &ret) < 0 || ret < 0) {
              virReportError(VIR_ERR_INTERNAL_ERROR, _("failed to parse port number '%s'"), port);
              return -1;
          }
          return ret;
      }
      switch ((virStorageNetProtocol) protocol) {
          case VIR_STORAGE_NET_PROTOCOL_HTTP:
              return 80;
          case VIR_STORAGE_NET_PROTOCOL_HTTPS:
              return 443;
          case VIR_STORAGE_NET_PROTOCOL_FTP:
              return 21;
          case VIR_STORAGE_NET_PROTOCOL_FTPS:
              return 990;
          case VIR_STORAGE_NET_PROTOCOL_TFTP:
              return 69;
          case VIR_STORAGE_NET_PROTOCOL_SHEEPDOG:
              return 7000;
          case VIR_STORAGE_NET_PROTOCOL_NBD:
              return 10809;
          case VIR_STORAGE_NET_PROTOCOL_SSH:
              return 22;
          case VIR_STORAGE_NET_PROTOCOL_ISCSI:
          case VIR_STORAGE_NET_PROTOCOL_GLUSTER:
              /* no default port specified */
              return 0;
          case VIR_STORAGE_NET_PROTOCOL_RBD:
          case VIR_STORAGE_NET_PROTOCOL_LAST:
          case VIR_STORAGE_NET_PROTOCOL_NONE:
              /* not applicable */
              return -1;
      }
      return -1;
  }

So if there is no "port" attribute at all, a default value is used according to the protocol. Most probably we could do something similar, and append the port to the host string only if specified or there's a default value for it.

Patch posted:
https://www.redhat.com/archives/libguestfs/2016-August/msg00211.html

Upstream commits:

9e7b564fc1d9fa0e99a46e4739614820812ca42b
98aa78f288e44868bcccf56b777d57d9fd4ec6a6

Verified with packages:
python-libguestfs-1.32.7-3.el7.x86_64

Steps:
1. Make sure python-libguestfs is installed.
2. Prepare an gluster env, run virt-install to create a guest which has gluster image. 
# virt-install --name gluster1 --memory 1024 --disk gluster://10.66.4.164/gluster-vol1/xdw.qcow2 -l http://download.englab.nay.redhat.com/pub/rhel/released/RHEL-6/6.6/Server/x86_64/os
Don't need to install it, just ensure the guest is started.
3. Open virt-manager and wait a moment.

Virt-manager doesn't crash and exit after few minutes.

So verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2576.html