On Tue, 12 Feb 2013, M A Young wrote:

Let me try (again), repeating all the steps, starting from a fresh F18
install. After that, we'll decide if we want to stick with 893699
bugzilla entry, or create a new one, or whatever else we want to do...

Ok, here I am.

1. Install F18
2. yum install xen
3. reboot
4. ps aux | grep xend                       [nothing found]
5. creating a domain with xl                [_works_]
6. yum install libvirt-daemon-xen virt-manager virt-viewer \
        python-virt-inst libvirt-daemon-config-network
7. rpm -qa | grep daemon-driver-libxl       [yes,]
8. rpm -qa | grep daemon-driver-xen         [yes,]
9. reboot (just in case!)
10. ps aux | grep xend                      [nothing found]
11. systemctl status libvirtd.service       [active (running)]
12. start virt manager                      [connected to xen:// (I
                                            can't see Dom0, but that
                                            is fine, IIRC)]
13. ps aux | grep xend                      [nothing found]
14. creating a domain with xl               [_works_]
15. creating a domain with virt-install     [_DOES_NOT_ work (*)]

Check /var/log/libvirt/libxl/libxl.log to see what went wrong. I have done some testing and in my case it seems it defaults to trying the blktap driver for disks, which won't work with the Fedora kernel. There may be some way to get it to use file, phy or other driver as you can with an xl configuration file, but I haven't found a way that works yet.

Actually, in your case you could try --disk path=/dev/vms/F18_x64,driver_name=phy . Unfortunately driver_name=file doesn't work for a disk image file as it seems that uses blktap, which is arguably a libvirt libxl driver bug.

        Michael Young
xen mailing list

Reply via email to