On 02/02/2012 10:53 AM, Cheer Xiao wrote: > 2012/2/2 Cole Robinson <crobinso@xxxxxxxxxx>: >> ... [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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list