Re: [Fedora-xen] Xen 4.4 RC2 [TestDay]

[M A Young]

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

Xen 4.4 RC2 [TestDay]

[Dario Faggioli]

[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

-- 
<<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)

Enable Xen in f20 qemu? [Was: Xen 4.4 RC2 [TestDay]]

[Bill McGonigle]

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

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bill(a)bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle

Enable Xen in f20 qemu? [Was: Xen 4.4 RC2 [TestDay]]

[Cole Robinson]

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