1:09 p.m.
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 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".
Also (as it could have been expected, I guess) there is no way I can get
it to work with a file backed VHD.
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?
FYI, I've also opened this Fedora bugreport, about this very same issue:
https://bugzilla.redhat.com/show_bug.cgi?id=912488
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
10:19 a.m.
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
10:30 a.m.
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...
LIBXL_DISK_BACKEND_UNKNOWN will cause libxl to pick the best available
(which includes checking if blktap is actually there) backend given the
format and file type (block device, file etc). That's probably the right
default.
libxl__device_disk_set_backend is the guy to look at if you are
interested how the selection happens.
Ian.
11:07 a.m.
Ian Campbell wrote:
> 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...
>
LIBXL_DISK_BACKEND_UNKNOWN will cause libxl to pick the best available
(which includes checking if blktap is actually there) backend given the
format and file type (block device, file etc). That's probably the right
default.
Ok, thanks.
libxl__device_disk_set_backend is the guy to look at if you are
interested how the selection happens.
After taking a peek, agreed that LIBXL_DISK_BACKEND_UNKNOWN is a better
backend default. I'll leave the format default of LIBXL_DISK_FORMAT_RAW
to be consistent with $xen-src/docs/misc/xl-disk-configuration.txt.
Thanks,
Jim
11:12 a.m.
On Wed, 2013-02-20 at 17:07 +0000, Jim Fehlig wrote:
> libxl__device_disk_set_backend is the guy to look at if you are
> interested how the selection happens.
>
After taking a peek, agreed that LIBXL_DISK_BACKEND_UNKNOWN is a better
backend default. I'll leave the format default of LIBXL_DISK_FORMAT_RAW
to be consistent with $xen-src/docs/misc/xl-disk-configuration.txt.
Makes sense, libxl deliberately does not do format detection because it
can be dangerous (since a guest admin with a raw disk can write a qcow
snapshot header to the device pointing to /etc/shadow etc).
Ian.
12:07 p.m.
On mer, 2013-02-20 at 10:07 -0700, Jim Fehlig wrote:
> libxl__device_disk_set_backend is the guy to look at if you are
> interested how the selection happens.
>
After taking a peek, agreed that LIBXL_DISK_BACKEND_UNKNOWN is a better
backend default. I'll leave the format default of LIBXL_DISK_FORMAT_RAW
to be consistent with $xen-src/docs/misc/xl-disk-configuration.txt.
That sounds the best solution to me too... Thanks for looking at
this! :-)
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
4293
days inactive
4295
days old
5 comments
3 participants
participants (3)
-
Dario Faggioli -
Ian Campbell -
Jim Fehlig