On 02/02/2012 09:07 AM, Cheer Xiao wrote:

2012/2/2 Cole Robinson <crobinso@redhat.com>:

...

On 02/02/2012 08:54 AM, Cheer Xiao wrote:

...

2012/2/2 Cole Robinson <crobinso@redhat.com>:

...

On 02/02/2012 08:05 AM, Cheer Xiao wrote:

...

Hi all,

I was setting up libvirt and virt-manager for managing Xen VMs. But when I hit "New" in virt-manager to provision a new VM, virt-manager gives me the error: "No install options available for this connection."

The hypervisor being used is para-virtualized Xen, running on Debian Squeeze.

lux-002# xm info host   Â  Â  Â  Â  Â  Â  Â  Â  : lux-002 release   Â  Â  Â  Â  Â  Â  Â : 2.6.32-5-xen-686 version   Â  Â  Â  Â  Â  Â  Â : #1 SMP Mon Jan 16 19:46:09 UTC 2012 machine   Â  Â  Â  Â  Â  Â  Â : i686 nr_cpus   Â  Â  Â  Â  Â  Â  Â : 4 nr_nodes   Â  Â  Â  Â  Â  Â  : 1 cores_per_socket   Â  Â  : 1 threads_per_core   Â  Â  : 2 cpu_mhz   Â  Â  Â  Â  Â  Â  Â : 3200 hw_caps   Â  Â  Â  Â  Â  Â  Â : bfebfbff:20100000:00000000:00000180:0000641d:00000000:00000001:00000000 virt_caps   Â  Â  Â  Â  Â  Â : total_memory   Â  Â  Â  Â  : 8191 free_memory   Â  Â  Â  Â  Â : 1150 node_to_cpu   Â  Â  Â  Â  Â : node0:0-3 node_to_memory   Â  Â  Â  : node0:1150 node_to_dma32_mem   Â  Â : node0:578 max_node_id   Â  Â  Â  Â  Â : 0 xen_major   Â  Â  Â  Â  Â  Â : 4 xen_minor   Â  Â  Â  Â  Â  Â : 0 xen_extra   Â  Â  Â  Â  Â  Â : .1 xen_caps   Â  Â  Â  Â  Â  Â  : xen-3.0-x86_32p xen_scheduler   Â  Â  Â  Â : credit xen_pagesize   Â  Â  Â  Â  : 4096 platform_params   Â  Â  Â : virt_start=0xf5800000 xen_changeset   Â  Â  Â  Â : unavailable xen_commandline   Â  Â  Â : placeholder com1=9600,8n1 console=com1,vga cc_compiler   Â  Â  Â  Â  Â : gcc version 4.4.5 (Debian 4.4.5-8) cc_compile_by   Â  Â  Â  Â : waldi cc_compile_domain   Â  Â : debian.org cc_compile_date   Â  Â  Â : Mon Nov  7 09:18:26 CET 2011 xend_config_format   Â  : 4 lux-002# libvirtd --version libvirtd (libvirt) 0.8.3

libvirt pokes into the host machine to try and figure out it's virt capabilities. So something must be going wrong there. Here's the function it uses in libvirt code:

http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/xen/xen_hypervisor.c;h=b5...

Something must be funky or unexpected with /sys/hypervisor/properties/capabilities

This is how it looks:

lux-002% cat /sys/hypervisor/properties/capabilities xen-3.0-x86_32p

So, is provision through on para-virtualized Xen *supposed* to be supported or not?

Uh... So I guess it's supposed to be supported

Yes, sorry, libvirt and virt-manager/virt-install do support this config.

...

That is saying your host supports 32bit paravirt guests only.

What's the output of 'virsh --connect xen:/// capabilities' ?

blackie% virsh -c xen+ssh://lux-002 capabilities <capabilities>

<host> <cpu> <arch>i686</arch> <features> <pae/> </features> </cpu> <migration_features> <live/> <uri_transports> <uri_transport>xenmigr</uri_transport> </uri_transports> </migration_features> <topology> <cells num='1'> <cell id='0'> <cpus num='4'> <cpu id='0'/> <cpu id='1'/> <cpu id='2'/> <cpu id='3'/> </cpus> </cell> </cells> </topology> </host>

<guest> <os_type>xen</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/lib/xen/bin/qemu-dm</emulator> <machine>xenpv</machine> <domain type='xen'> </domain> </arch> <features> <pae/> </features> </guest>

</capabilities>

Okay, libvirt is detecting things correctly. So why is virt-manager confused? Using that capabilities output works for me. What virt-manager version are you using? Can you run virt-manager with --debug, connect to xen, open the 'new vm' wizard that shows the error, and post the debug output here? Thanks, Cole

On 02/02/2012 10:53 AM, Cheer Xiao wrote:

2012/2/2 Cole Robinson <crobinso@redhat.com>:

...

... [snip] ...

Okay, libvirt is detecting things correctly. So why is virt-manager confused? Using that capabilities output works for me.

What virt-manager version are you using? Can you run virt-manager with --debug, connect to xen, open the 'new vm' wizard that shows the error, and post the debug output here?

The ouput is pasted. I also made a screenshot and uploaded to [1]. And another unrelated question: does the output says virt-manager uses HAL for physical network interface management? I suppose HAL is obsolete...

blackie% virt-manager --version 0.9.0 blackie% virt-manager --debug 2012-02-02 23:49:04,992 (cli:71): virt-manager startup 2012-02-02 23:49:04,992 (virt-manager:292): Launched as: /usr/share/virt-manager/virt-manager.py --debug 2012-02-02 23:49:04,993 (virt-manager:293): GTK version: (2, 24, 9) 2012-02-02 23:49:04,993 (virt-manager:294): virtManager import: <module 'virtManager' from '/usr/share/virt-manager/virtManager/__init__.py'> 2012-02-02 23:49:05,116 (keyring:30): gnomekeyring bindings not installed, no keyring support 2012-02-02 23:49:05,391 (engine:555): No inspection thread because libguestfs is too old, not available, or libvirt is not thread safe. 2012-02-02 23:49:05,396 (engine:346): About to connect to uris ['xen+ssh://lux-003/', 'xen+ssh://major/', 'xen+ssh://lux-002/', 'qemu:///system'] 2012-02-02 23:49:05,555 (engine:471): window counter incremented to 1 2012-02-02 23:49:14,633 (connection:954): Scheduling background open thread for xen+ssh://lux-002/ 2012-02-02 23:49:14,633 (connection:1140): Background 'open connection' thread is running 2012-02-02 23:49:16,082 (connection:1168): Background open thread complete, scheduling notify 2012-02-02 23:49:16,082 (connection:1173): Notifying open result 2012-02-02 23:49:18,120 (connection:1180): xen+ssh://lux-002/ capabilities: <capabilities>

<host> <cpu> <arch>i686</arch> <features> <pae/> </features> </cpu> <migration_features> <live/> <uri_transports> <uri_transport>xenmigr</uri_transport> </uri_transports> </migration_features> <topology> <cells num='1'> <cell id='0'> <cpus num='4'> <cpu id='0'/> <cpu id='1'/> <cpu id='2'/> <cpu id='3'/> </cpus> </cell> </cells> </topology> </host>

<guest> <os_type>xen</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/lib/xen/bin/qemu-dm</emulator> <machine>xenpv</machine> <domain type='xen'> </domain> </arch> <features> <pae/> </features> </guest>

</capabilities>

2012-02-02 23:49:20,336 (connection:514): Connection doesn't seem to support interface APIs. Skipping all interface polling. 2012-02-02 23:49:27,777 (connection:570): Connection managed save support: False 2012-02-02 23:49:28,877 (halhelper:133): Unable to connect to HAL to list network devices: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Hal was not provided by any .service files 2012-02-02 23:49:28,877 (connection:157): Libvirt version does not support physical interface listing 2012-02-02 23:49:28,879 (connection:200): Using libvirt API for mediadev enumeration 2012-02-02 23:49:55,510 (create:832): Guest type set to os_type=xen, arch=i686, dom_type=xen

1. http://ftp.tuna.tsinghua.edu.cn/xiaqs/screenshot-new-vm.png

Okay, none of that indicates why it isn't working. I can't reproduce using your capabilities output and virt-manager 0.9.0 either (though I hacked it in so I could have missed a detail). Can you try with current upstream? git clone git://git.fedorahosted.org/virt-manager.git git clone git://git.fedorahosted.org/python-virtinst.git cd python-virtinst python setup.py build cd ../virt-manager ./autogen.sh && ./configure && make -j4 # Then after you can launch virt-manager with PYTHONPATH=../python-virtinst python src/virt-manager.py --debug See if you can reproduce, and if so please provide debug output and we can go from there. - Cole

2012/2/5 Cheer Xiao <xiaqqaix@gmail.com>:

2012/2/4 Cole Robinson <crobinso@redhat.com>:

...

... [snip] ... Okay, none of that indicates why it isn't working. I can't reproduce using your capabilities output and virt-manager 0.9.0 either (though I hacked it in so I could have missed a detail).

Can you try with current upstream?

git clone git://git.fedorahosted.org/virt-manager.git git clone git://git.fedorahosted.org/python-virtinst.git cd python-virtinst python setup.py build cd ../virt-manager ./autogen.sh && ./configure && make -j4

# Then after you can launch virt-manager with PYTHONPATH=../python-virtinst python src/virt-manager.py --debug

See if you can reproduce, and if so please provide debug output and we can go from there.

Thanks! I'll be testing in a few days.

The problem is still present, and I have collected the debug output. FYII, * My laptop runs Archlinux and In Arch the default python is python3, which makes it a little tricky to install python applications by hand. Thus I tested on a VirtualBox guest, running Ubuntu 12.04. The remote Xen host is the same. * The PYTHONPATH trick didn't work for me, for some reason. So I did `sudo python setup.py install` in python-virtinst and `sudo make install` in virt-manager and ran just `virt-manager --debug`. * python-virtinst and virt-manager are both compiled from HEAD of Git. xiaq@vblackie ~/S/virt-manager> virt-manager --debug ** WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags' ** WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags' Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap", 2012-02-06 20:52:17,589 (cli:71): virt-manager startup 2012-02-06 20:52:17,590 (virt-manager:291): Launched as: /usr/local/share/virt-manager/virt-manager.py --debug 2012-02-06 20:52:17,590 (virt-manager:292): GTK version: (2, 24, 8) 2012-02-06 20:52:17,596 (virt-manager:293): virt-manager version: 0.9.1 2012-02-06 20:52:17,596 (virt-manager:294): virtManager import: <module 'virtManager' from '/usr/local/share/virt-manager/virtManager/__init__.py'> 2012-02-06 20:52:17,874 (cli:118): virtinst version: 0.600.1 2012-02-06 20:52:17,876 (cli:119): virtinst import: <module 'virtinst' from '/usr/local/lib/python2.7/dist-packages/virtinst/__init__.pyc'> /usr/local/share/virt-manager/virt-manager.py:305: DeprecationWarning: Importing dbus.glib to use the GLib main loop with dbus-python is deprecated. Instead, use this sequence: from dbus.mainloop.glib import DBusGMainLoop DBusGMainLoop(set_as_default=True) import dbus.glib 2012-02-06 20:52:18,490 (engine:555): No inspection thread because libguestfs is too old, not available, or libvirt is not thread safe. 2012-02-06 20:52:18,501 (systray:138): Showing systray: False 2012-02-06 20:52:18,511 (engine:346): About to connect to uris ['xen+ssh://xiaq@lux-002/'] 2012-02-06 20:52:18,736 (manager:171): Showing manager 2012-02-06 20:52:18,895 (engine:471): window counter incremented to 1 2012-02-06 20:52:29,286 (create:174): Showing new vm wizard -- Regards, Cheer Xiao aka. xiaq

On 02/06/2012 08:01 AM, Cheer Xiao wrote:

2012/2/6 Cheer Xiao <xiaqqaix@gmail.com>:

...

2012/2/5 Cheer Xiao <xiaqqaix@gmail.com>:

...

2012/2/4 Cole Robinson <crobinso@redhat.com>:

...

... [snip] ... Okay, none of that indicates why it isn't working. I can't reproduce using your capabilities output and virt-manager 0.9.0 either (though I hacked it in so I could have missed a detail).

Can you try with current upstream?

git clone git://git.fedorahosted.org/virt-manager.git git clone git://git.fedorahosted.org/python-virtinst.git cd python-virtinst python setup.py build cd ../virt-manager ./autogen.sh && ./configure && make -j4

# Then after you can launch virt-manager with PYTHONPATH=../python-virtinst python src/virt-manager.py --debug

See if you can reproduce, and if so please provide debug output and we can go from there.

Thanks! I'll be testing in a few days.

The problem is still present, and I have collected the debug output. FYII,

Sorry, wrong log. This is the correct version:

xiaq@vblackie ~/S/python-virtinst> virt-manager --debug

** WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap", 2012-02-06 20:59:56,609 (cli:71): virt-manager startup 2012-02-06 20:59:56,618 (virt-manager:291): Launched as: /usr/local/share/virt-manager/virt-manager.py --debug 2012-02-06 20:59:56,620 (virt-manager:292): GTK version: (2, 24, 8) 2012-02-06 20:59:56,621 (virt-manager:293): virt-manager version: 0.9.1 2012-02-06 20:59:56,621 (virt-manager:294): virtManager import: <module 'virtManager' from '/usr/local/share/virt-manager/virtManager/__init__.py'> 2012-02-06 20:59:56,873 (cli:118): virtinst version: 0.600.1 2012-02-06 20:59:56,875 (cli:119): virtinst import: <module 'virtinst' from '/usr/local/lib/python2.7/dist-packages/virtinst/__init__.pyc'> /usr/local/share/virt-manager/virt-manager.py:305: DeprecationWarning: Importing dbus.glib to use the GLib main loop with dbus-python is deprecated. Instead, use this sequence:

from dbus.mainloop.glib import DBusGMainLoop

DBusGMainLoop(set_as_default=True)

import dbus.glib 2012-02-06 20:59:57,541 (engine:555): No inspection thread because libguestfs is too old, not available, or libvirt is not thread safe. 2012-02-06 20:59:57,552 (systray:138): Showing systray: False 2012-02-06 20:59:57,566 (engine:346): About to connect to uris ['xen+ssh://xiaq@lux-002/'] 2012-02-06 20:59:57,780 (manager:171): Showing manager 2012-02-06 20:59:57,946 (engine:471): window counter incremented to 1 2012-02-06 20:59:59,745 (connection:991): Scheduling background open thread for xen+ssh://xiaq@lux-002/ 2012-02-06 20:59:59,756 (connection:1177): Background 'open connection' thread is running xiaq@lux-002's password: 2012-02-06 21:00:04,097 (connection:1227): Background open thread complete, scheduling notify 2012-02-06 21:00:04,102 (connection:1232): Notifying open result 2012-02-06 21:00:06,158 (connection:1239): xen+ssh://xiaq@lux-002/ capabilities: <capabilities>

<host> <cpu> <arch>i686</arch> <features> <pae/> </features> </cpu> <migration_features> <live/> <uri_transports> <uri_transport>xenmigr</uri_transport> </uri_transports> </migration_features> <topology> <cells num='1'> <cell id='0'> <cpus num='4'> <cpu id='0'/> <cpu id='1'/> <cpu id='2'/> <cpu id='3'/> </cpus> </cell> </cells> </topology> </host>

<guest> <os_type>xen</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/lib/xen/bin/qemu-dm</emulator> <machine>xenpv</machine> <domain type='xen'> </domain> </arch> <features> <pae/> </features> </guest>

</capabilities>

2012-02-06 21:00:08,648 (connection:551): Connection doesn't seem to support interface APIs. Skipping all interface polling. 2012-02-06 21:00:15,772 (connection:607): Connection managed save support: False 2012-02-06 21:00:17,041 (halhelper:133): Unable to connect to HAL to list network devices: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Hal was not provided by any .service files 2012-02-06 21:00:17,044 (connection:186): Libvirt version does not support physical interface listing 2012-02-06 21:00:17,047 (connection:229): Using libvirt API for mediadev enumeration 2012-02-06 21:00:24,328 (create:174): Showing new vm wizard start None None None after None None None 2012-02-06 21:00:24,439 (create:859): Guest type set to os_type=xen, arch=i686, dom_type=xen start xen xen None after xen xen None start xen xen i686 after xen xen i686 2012-02-06 21:00:35,392 (engine:426): Tick is slow, not running at requested rate.

Hmm, okay, can you try applying the attached debugging patch to virt-manager and reproduce again? Thanks, Cole

On 02/09/2012 04:18 AM, Cheer Xiao wrote:

2012/2/7 Cole Robinson <crobinso@redhat.com>:

...

On 02/06/2012 08:01 AM, Cheer Xiao wrote:

...

2012/2/6 Cheer Xiao <xiaqqaix@gmail.com>:

...

2012/2/5 Cheer Xiao <xiaqqaix@gmail.com>:

...

2012/2/4 Cole Robinson <crobinso@redhat.com>:

...

... [snip] ... Okay, none of that indicates why it isn't working. I can't reproduce using your capabilities output and virt-manager 0.9.0 either (though I hacked it in so I could have missed a detail).

Can you try with current upstream?

git clone git://git.fedorahosted.org/virt-manager.git git clone git://git.fedorahosted.org/python-virtinst.git cd python-virtinst python setup.py build cd ../virt-manager ./autogen.sh && ./configure && make -j4

# Then after you can launch virt-manager with PYTHONPATH=../python-virtinst python src/virt-manager.py --debug

See if you can reproduce, and if so please provide debug output and we can go from there.

Thanks! I'll be testing in a few days.

The problem is still present, and I have collected the debug output. FYII,

Sorry, wrong log. This is the correct version:

xiaq@vblackie ~/S/python-virtinst> virt-manager --debug

** WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap", 2012-02-06 20:59:56,609 (cli:71): virt-manager startup 2012-02-06 20:59:56,618 (virt-manager:291): Launched as: /usr/local/share/virt-manager/virt-manager.py --debug 2012-02-06 20:59:56,620 (virt-manager:292): GTK version: (2, 24, 8) 2012-02-06 20:59:56,621 (virt-manager:293): virt-manager version: 0.9.1 2012-02-06 20:59:56,621 (virt-manager:294): virtManager import: <module 'virtManager' from '/usr/local/share/virt-manager/virtManager/__init__.py'> 2012-02-06 20:59:56,873 (cli:118): virtinst version: 0.600.1 2012-02-06 20:59:56,875 (cli:119): virtinst import: <module 'virtinst' from '/usr/local/lib/python2.7/dist-packages/virtinst/__init__.pyc'> /usr/local/share/virt-manager/virt-manager.py:305: DeprecationWarning: Importing dbus.glib to use the GLib main loop with dbus-python is deprecated. Instead, use this sequence:

  from dbus.mainloop.glib import DBusGMainLoop

  DBusGMainLoop(set_as_default=True)

 import dbus.glib 2012-02-06 20:59:57,541 (engine:555): No inspection thread because libguestfs is too old, not available, or libvirt is not thread safe. 2012-02-06 20:59:57,552 (systray:138): Showing systray: False 2012-02-06 20:59:57,566 (engine:346): About to connect to uris ['xen+ssh://xiaq@lux-002/'] 2012-02-06 20:59:57,780 (manager:171): Showing manager 2012-02-06 20:59:57,946 (engine:471): window counter incremented to 1 2012-02-06 20:59:59,745 (connection:991): Scheduling background open thread for xen+ssh://xiaq@lux-002/ 2012-02-06 20:59:59,756 (connection:1177): Background 'open connection' thread is running xiaq@lux-002's password: 2012-02-06 21:00:04,097 (connection:1227): Background open thread complete, scheduling notify 2012-02-06 21:00:04,102 (connection:1232): Notifying open result 2012-02-06 21:00:06,158 (connection:1239): xen+ssh://xiaq@lux-002/ capabilities: <capabilities>

 <host>   <cpu>    <arch>i686</arch>    <features>     <pae/>    </features>   </cpu>   <migration_features>    <live/>    <uri_transports>     <uri_transport>xenmigr</uri_transport>    </uri_transports>   </migration_features>   <topology>    <cells num='1'>     <cell id='0'>      <cpus num='4'>       <cpu id='0'/>       <cpu id='1'/>       <cpu id='2'/>       <cpu id='3'/>      </cpus>     </cell>    </cells>   </topology>  </host>

 <guest>   <os_type>xen</os_type>   <arch name='i686'>    <wordsize>32</wordsize>    <emulator>/usr/lib/xen/bin/qemu-dm</emulator>    <machine>xenpv</machine>    <domain type='xen'>    </domain>   </arch>   <features>    <pae/>   </features>  </guest>

</capabilities>

2012-02-06 21:00:08,648 (connection:551): Connection doesn't seem to support interface APIs. Skipping all interface polling. 2012-02-06 21:00:15,772 (connection:607): Connection managed save support: False 2012-02-06 21:00:17,041 (halhelper:133): Unable to connect to HAL to list network devices: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Hal was not provided by any .service files 2012-02-06 21:00:17,044 (connection:186): Libvirt version does not support physical interface listing 2012-02-06 21:00:17,047 (connection:229): Using libvirt API for mediadev enumeration 2012-02-06 21:00:24,328 (create:174): Showing new vm wizard start None None None after None None None 2012-02-06 21:00:24,439 (create:859): Guest type set to os_type=xen, arch=i686, dom_type=xen start xen xen None after xen xen None start xen xen i686 after xen xen i686 2012-02-06 21:00:35,392 (engine:426): Tick is slow, not running at requested rate.

Hmm, okay, can you try applying the attached debugging patch to virt-manager and reproduce again?

Patched against HEAD and got this debug output (for completeness I also included the debug output after I hit the Cancel button of New VM Wizard and then Exit button of virt-manager):

Great, thanks for the info. I see the problem now, my confusion was that I was looking at the wrong error message in the code, and that there were some defects in the UI that were not reporting the problems very well. I've pushed some tweaks upstream so that we are reporting more info in this case, and actually allow import installs here. Xen PV doesn't work with CDROM or PXE installs, so those are rightly disabled. Since you are connecting to a remote machine, URL installs only work if you have a new enough libvirt which it doesn't look like you do. Import installs would work in your case, but a logic error was causing virt-manager not to allow it. I've changed the error reporting here to show the disabled install options even if we think none are available, since we set tooltips on the disabled entries that can provide more info. But end result is that your setup as is doesn't support creating new VMs: either update the remote libvirt version to 0.9.4 or later to get remote URL install support, or ssh to the remote machine and install a VM using virt-manager/virt-install. Thanks, Cole