Description of problem: virt-manager coredump when vm with gluster image exists Version-Release number of selected component (if applicable): virt-manager-1.4.0-1.el7.noarch python-libguestfs-1.32.7-2.el7.x86_64 libvirt-2.0.0-6.el7.x86_64 # uname -r 3.10.0-493.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Make sure python-libguestfs is installed. 2. 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 3. Open virt-manager and wait a moment. Actual results: virt-manager crash after several seconds. Expected results: virt-manager should not crash. Additional info: 1. Please see attachment for virt-manager/gdb/guest_xml log. 2. This issue doesn't occur after removing python-libguestfs-1.32.7-2.el7.x86_64
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