Bug 1334562

Thanks for the report. virt-install --debug will probably tell us what the culprit is. My guess is that the XML we get back from xen does not have a graphical listen= address in it or something, which confuses virt-viewer

Created attachment 1155796 [details]
virt-install -debug .blah blah 2>stderr.txt output

Here is the output.

Specifically I did:
virt-install --debug   -n F24-64 --memory 1024 --location http://192.168.102.1:/tftpboot/lab/tst031/f24  --disk /var/lib/libvirt/images/f24-i686.img --network bridge=switch,mac=00:0f:4b:01:00:87 2>stderr.txt

So the issue here is that the XML we get back from the libxl driver looks like

    <graphics type='vnc' port='5900' autoport='yes' keymap='en-us'/>

Which doesn't tell us what the listen= address is. virt-viewer doesn't know what address to connect to. The XML virtinst sent in was:

    <graphics type="vnc" port="-1" keymap="en-us"/>

For the qemu driver, no request for a listen address means 'please fill in the default' which can be changed in /etc/libvirt/qemu.conf. Does libxl have something similar? If not virtinst needs to be changed, or libxl could just default to listen=127.0.0.1 which is the qemu.conf default

fwiw virt-manager seems to work fine in this case since the spice and vnc clients default to listen=127.0.0.1 as well, but virt-viewer is complaining nowadays. regardless I think libxl should explicitly report 127.0.0.1 in this case

(In reply to Cole Robinson from comment #5)
> regardless I think libxl should explicitly report 127.0.0.1 in
> this case

Agreed. I've added this to my todo list for the libxl driver.

So this is very odd.

I updated libvirt to libvirt-1.3.3.1-2.fc24.x86_64
and it looks to launch the guest (still get the error).

If I look in XenStore I see:

[root@tst032 ~]# xenstore-ls /local/domain/6/device/vfb
0 = ""
 backend = "/local/domain/0/backend/vfb/6/0"
 backend-id = "0"
 state = "3"
 page-ref = "1107844"
 event-channel = "9"
 protocol = "x86_64-abi"
 feature-update = "1"
[root@tst032 ~]# 

Which is good. However qemu:
root      3057     1  0 12:04 ?        00:00:00 /usr/bin/qemu-system-i386 -xen-domid 6 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-6,server,nowait -no-shutdown -mon chardev=libxl-cmd,mode=control -chardev socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-6,server,nowait -mon chardev=libxenstat-cmd,mode=control -nodefaults -xen-attach -name F24-64_2 -vnc 127.0.0.1:0 -display none -k en-us -machine xenpv -m 2048

Has 'display' none! Let me try with an HVM guest.

Still seems relevant with libvirt 3.2.0, here's example XML I get from libvirt after the following virt-install command line:

# virt-install --connect xen:/// --name vnc-test --ram 64 --nodisks --pxe --hvm --graphics vnc --noautoconsole

...

# virsh --connect xen:/// dumpxml vnc-test
...
    <graphics type='vnc' port='5900' autoport='yes' keymap='en-us'>
      <listen type='address'/>
    </graphics>
    <video>
      <model type='cirrus' vram='8192' heads='1' primary='yes'/>
    </video>
...

Patch sent upstream to add the listen address to the <graphics> config

https://www.redhat.com/archives/libvir-list/2017-May/msg00616.html

V2 posted on libvirt dev list for review

https://www.redhat.com/archives/libvir-list/2017-May/msg00760.html

The patch reference in Jim's comments appears to have been merged.