[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] libvirt-libxl driver defaulting to tap disk and not working (on Fedora 18 and rawhide)



Dario Faggioli wrote:
> Hi Jim, Everyone,
>
> I'm having some issues when trying out libvirt-libxl driver on my
> Fedora, bot on Fedora 18 and Fedorra rawhide (the former seems to be
> running 0.10.2.3, the later 1.0.2).
>
> Here's what happen:
>
> [root localhost ~]# systemctl status xend.service
> xend.service - Xend - interface between hypervisor and some applications
> 	  Loaded: loaded (/usr/lib/systemd/system/xend.service; disabled)
> 	  Active: inactive (dead)
>
> [root localhost ~]# virt-install -l http://fedora.mirror.constant.com/linux/releases/18/Fedora/x86_64/os/ --ram 1024 --disk /dev/vms/F18_x64 --name F18_x64
>
> Starting install...
> Retrieving file .treeinfo...                             | 2.2 kB     00:00 !!! 
> Retrieving file vmlinuz...                               | 9.3 MB     00:06 !!! 
> Retrieving file initrd.img...                            |  53 MB     00:33 !!! 
> ERROR    internal error libxenlight failed to create new domain 'F18_x64'
> Domain installation does not appear to have been successful.
> If it was, you can restart your domain by running:
>   virsh --connect xen:/// start F18_x64
> otherwise, please restart your installation.
>
> [root localhost ~]# cat /var/log/libvirt/libxl/libxl.log
> ...
> libxl: verbose: libxl_create.c:158:libxl__domain_build_info_setdefault: qemu-xen is unavailable, use qemu-xen-traditional instead: No such file or directory
> libxl: debug: libxl_create.c:1174:do_domain_create: ao 0x7f566c008d90: create: how=(nil) callback=(nil) poller=0x7f566c009030
> libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=tap
> libxl: debug: libxl_device.c:184:disk_try_backend: Disk vdev=xvda, backend tap unsuitable because blktap not available
> libxl: error: libxl_device.c:269:libxl__device_disk_set_backend: no suitable backend for disk xvda
> libxl: debug: libxl_event.c:1499:libxl__ao_complete: ao 0x7f566c008d90: complete, rc=-3
> libxl: debug: libxl_create.c:1187:do_domain_create: ao 0x7f566c008d90: inprogress: poller=0x7f566c009030, flags=ic
> libxl: debug: libxl_event.c:1471:libxl__ao__destroy: ao 0x7f566c008d90: destroy
>
> So, it looks like it tries to use blktap, even if I'm using an LVM
> volume, and fails.

If not specified, the driver name defaults to 'tap' and driver type
defaults to 'raw'.  From libxlMakeDisk() in
$libvirt-src/src/libxl/libxl_conf.c

    if (l_disk->driverName) {
        ...
    } else {
        /* No driverName - default to raw/tap?? */
        x_disk->format = LIBXL_DISK_FORMAT_RAW;
        x_disk->backend = LIBXL_DISK_BACKEND_TAP;
    }

I recall some discussion about the choice of these defaults, but can't
find anything in the xen or libvirt ml archives.  We can adjust the
defaults (or defer to libxl?) if it makes sense.  I took a quick peek at
newer libxl code (recall this was written against Xen 4.1 libxl) and
perhaps 'x_disk->backend = LIBXL_DISK_BACKEND_QDISK' would be a saner
default?  Adding Ian to help with this question...


>  If I go for this:
> [root localhost ~]# virt-install -l http://fedora.mirror.constant.com/linux/releases/18/Fedora/x86_64/os/ --ram 1024 --disk /dev/vms/F18_x64,driver_name=phy --name F18_x64 --bridge virbr0
>
> it works, but only because (or at least so it looks to me) I'm manually
> providing ",driver_name=phy".
>   

I don't think we should change the backend default to
LIBXL_DISK_BACKEND_PHY, so you would want to specify this anyhow. 
Although I think it would work if the backend default was
LIBXL_DISK_BACKEND_QDISK right? :)

> Also (as it could have been expected, I guess) there is no way I can get
> it to work with a file backed VHD.
>   

Have you tried ',driver_name=tap,driver_type=vhd'?  Or
',driver_name=tap2,driver_type=vhd' with blktap2.

> Is all this supposed to happen?
>
> I haven't had the chance to try out the code from git yet, do you think
> it would make any difference?
>   

No.  The defaults haven't changed since the code was originally written
against Xen 4.1.

> FYI, I've also opened this Fedora bugreport, about this very same issue:
>  https://bugzilla.redhat.com/show_bug.cgi?id=912488
>   

Ok, thanks for the bug reference.

Regards,
Jim


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]