On Mon, 20 Jan 2014, Eric Houby wrote:
The first issue I hit was:
[root@astar ~]# xl create mars.xl Parsing config from mars.xl libxl: error: libxl_create.c:1034:domcreate_launch_dm: unable to add disk devices libxl: error: libxl_dm.c:1467:kill_device_model: unable to find device model pid in /local/domain/1/image/device-model-pid libxl: error: libxl.c:1425:libxl__destroy_domid: libxl__destroy_device_model failed for 1 libxl: error: libxl_device.c:780:libxl__initiate_device_remove: unable to get my domid libxl: error: libxl.c:1461:devices_destroy_cb: libxl__devices_destroy failed for 1
After some discussion about the xencommons init script and ExecStartPost in xenstored.service, it was determined that manually running /usr/bin/xenstore-write "/local/domain/0/domid" 0 would fix the issue.
Was xenstored.service enabled? That should have set up the environment correctly.
[root@astar ~]# xl create mars.xl Parsing config from mars.xl libxl: error: libxl_dm.c:1371:device_model_spawn_outcome: domain 6 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1166:domcreate_devmodel_started: device model did not start: -3 libxl: error: libxl_dm.c:1475:kill_device_model: Device Model already exited
My qemu-dm-mars log file contained one line, Option xen-domid not supported for this target. This error led those helping to question about my qemu version and whether or not it supported xen.
One of the experiments I was intending to do with that build was to see if xen would would work with Fedora's qemu. As you have just discovered the answer is no, though the tools configuration option allowing you tell xen where to find it seems to work. If you uninstall the qemu-system-x86 package or add the line device_model_version="qemu-xen-traditional" to your configuration file then your hvm guest should boot.
Michael Young
[Re-sending with the proper address to get to the list too... sorry! :-/]
On lun, 2014-01-20 at 23:18 +0000, M A Young wrote:
On Mon, 20 Jan 2014, Eric Houby wrote:
[root@astar ~]# xl create mars.xl Parsing config from mars.xl libxl: error: libxl_dm.c:1371:device_model_spawn_outcome: domain 6 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1166:domcreate_devmodel_started: device model did not start: -3 libxl: error: libxl_dm.c:1475:kill_device_model: Device Model already exited
My qemu-dm-mars log file contained one line, Option xen-domid not supported for this target. This error led those helping to question about my qemu version and whether or not it supported xen.
One of the experiments I was intending to do with that build was to see if xen would would work with Fedora's qemu.
Cool... That is definitely something worth experimenting! :-)
As you have just discovered the answer is no, though the tools configuration option allowing you tell xen where to find it seems to work.
That part definitely works. As a part of his participation to the TestDay (which happened thanks to your rc2 packages, so thanks again Michael for doing that, and Eric for participating!), Eric produced this log: http://pastebin.com/iyTYEgJ4
... libxl: debug: libxl_dm.c:1303:libxl__spawn_local_dm: Spawning device-model /usr/bin/qemu-system-x86_64 with arguments: libxl: debug: libxl_dm.c:1305:libxl__spawn_local_dm: /usr/bin/qemu-system-x86_64 libxl: debug: libxl_dm.c:1305:libxl__spawn_local_dm: -xen-domid libxl: debug: libxl_dm.c:1305:libxl__spawn_local_dm: 5 ...
So... Yay! :-)
While investigating, we also spotted this: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/qemu.spec?h=f20
Which contains the following:
dobuild() { ./configure \ --prefix=%{_prefix} \ --libdir=%{_libdir} \ --sysconfdir=%{_sysconfdir} \ --interp-prefix=%{_prefix}/qemu-%%M \ --audio-drv-list=pa,sdl,alsa,oss \ --localstatedir=%{_localstatedir} \ --libexecdir=%{_libexecdir} \ --disable-strip \ --extra-ldflags="$extraldflags -pie -Wl,-z,relro -Wl,-z,now" \ --extra-cflags="%{optflags} -fPIE -DPIE" \ --enable-mixemu \ --enable-trace-backend=dtrace \ --disable-werror \ --disable-xen \ --enable-kvm \ ...
which seems to suggest that xen support is disabled in Fedora's qemu package. Should we ask why they do that, and investigate whether that can change (and, of course, whether that is enough for us) ?
Thanks again and Regards, Dario
On 01/21/14 03:15, Dario Faggioli wrote:
While investigating, we also spotted this: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/qemu.spec?h=f20
Which contains the following:
dobuild() { ./configure \ --prefix=%{_prefix} \ --libdir=%{_libdir} \ --sysconfdir=%{_sysconfdir} \ --interp-prefix=%{_prefix}/qemu-%%M \ --audio-drv-list=pa,sdl,alsa,oss \ --localstatedir=%{_localstatedir} \ --libexecdir=%{_libexecdir} \ --disable-strip \ --extra-ldflags="$extraldflags -pie -Wl,-z,relro -Wl,-z,now" \ --extra-cflags="%{optflags} -fPIE -DPIE" \ --enable-mixemu \ --enable-trace-backend=dtrace \ --disable-werror \ --disable-xen \ --enable-kvm \ ...
which seems to suggest that xen support is disabled in Fedora's qemu package. Should we ask why they do that, and investigate whether that can change (and, of course, whether that is enough for us) ?
This still seems to be true - I guess I've been building my own for a long time or using virt-preview and just now had the opportunity to notice that the stock f20 qemu still fails with virt-install.
# virt-install --name=testvm --ram=2048 --vcpus=2 --cpuset=2-11 --location=http://librescu/cobbler/ks_mirror/centos6-x86_64 --os-type=linux --os-variant=rhel6 --disk path=/dev/zvol/storage/testvm/boot --disk path=/dev/zvol/storage/testvm/root --network bridge=br0,mac=02:00:0a:0a:0a:19 --graphics=vnc --paravirt --arch=x86_64 --virt-type=xen
yields:
# tail -100 /var/log/libvirt/libxl/testvm.log | grep libxl__spawn_local_dm | grep -v Spawning | cut -f 6 -d ' '| xargs echo /usr/bin/qemu-system-i386 -xen-domid 13 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-13,server,nowait -mon chardev=libxl-cmd,mode=control -nodefaults -xen-attach -name testvm -vnc 127.0.0.1:0 -k en-us -machine xenpv -m 2049
which gives:
Option xen-domid not supported for this target
etc. I see the f21 version (I built the matching version from virt-preview on f20) works fine and I've been using the above pattern for a couple years on f[1?-20]. Is it time to just enable xen for f20 since it works and f20 will be supported for a while yet? It was a little tricky (aka time-consuming) for me to track this down and I have a slight clue how the parts work - failing for historical reasons seems to be incorrect and will unnecessarily confuse a large part of the user base.
-Bill
On 11/12/2014 12:19 PM, Bill McGonigle wrote:
On 01/21/14 03:15, Dario Faggioli wrote:
While investigating, we also spotted this: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/qemu.spec?h=f20
Which contains the following:
dobuild() { ./configure \ --prefix=%{_prefix} \ --libdir=%{_libdir} \ --sysconfdir=%{_sysconfdir} \ --interp-prefix=%{_prefix}/qemu-%%M \ --audio-drv-list=pa,sdl,alsa,oss \ --localstatedir=%{_localstatedir} \ --libexecdir=%{_libexecdir} \ --disable-strip \ --extra-ldflags="$extraldflags -pie -Wl,-z,relro -Wl,-z,now" \ --extra-cflags="%{optflags} -fPIE -DPIE" \ --enable-mixemu \ --enable-trace-backend=dtrace \ --disable-werror \ --disable-xen \ --enable-kvm \ ...
which seems to suggest that xen support is disabled in Fedora's qemu package. Should we ask why they do that, and investigate whether that can change (and, of course, whether that is enough for us) ?
This still seems to be true - I guess I've been building my own for a long time or using virt-preview and just now had the opportunity to notice that the stock f20 qemu still fails with virt-install.
# virt-install --name=testvm --ram=2048 --vcpus=2 --cpuset=2-11 --location=http://librescu/cobbler/ks_mirror/centos6-x86_64 --os-type=linux --os-variant=rhel6 --disk path=/dev/zvol/storage/testvm/boot --disk path=/dev/zvol/storage/testvm/root --network bridge=br0,mac=02:00:0a:0a:0a:19 --graphics=vnc --paravirt --arch=x86_64 --virt-type=xen
yields:
# tail -100 /var/log/libvirt/libxl/testvm.log | grep libxl__spawn_local_dm | grep -v Spawning | cut -f 6 -d ' '| xargs echo /usr/bin/qemu-system-i386 -xen-domid 13 -chardev socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-13,server,nowait -mon chardev=libxl-cmd,mode=control -nodefaults -xen-attach -name testvm -vnc 127.0.0.1:0 -k en-us -machine xenpv -m 2049
which gives:
Option xen-domid not supported for this target
etc. I see the f21 version (I built the matching version from virt-preview on f20) works fine and I've been using the above pattern for a couple years on f[1?-20]. Is it time to just enable xen for f20 since it works and f20 will be supported for a while yet? It was a little tricky (aka time-consuming) for me to track this down and I have a slight clue how the parts work - failing for historical reasons seems to be incorrect and will unnecessarily confuse a large part of the user base.
Should be fine, please file an f20 bug against qemu and I'll turn on xen in the next build
- Cole
-
Bill McGonigle -
Cole Robinson -
Dario Faggioli -
M A Young