Latest xen-unstable and issues building/using it

Latest xen-unstable and issues building/using it

[Kamala Narasimhan]

I just got the latest xen-unstable from staging and  I encounter the
following issues -

1) I get the following build error while building 32 bit libxl (gcc
version 4.2.4) [btw, I am using 64-bit xen].  I got past the error by
simply declaring a local variable rather than directly casting and
passing info->u.pv.bootloader to fork_exec_bootloader but thought I
would mention.

libxl_bootloader.c: In function ‘libxl_run_bootloader’:
libxl_bootloader.c:391: warning: passing argument 2 of
‘fork_exec_bootloader’ discards qualifiers from pointer target type

2) I am used to using older tool stack but it appears I need to start
xencommns daemon first to use xl.  Is that correct or is there a
different wrapper I should be invoking?  It would help if there is a
wiki on the new tool stack assuming there isn't one already.

3) Also, it appears the sample config files that get installed under
/etc/xen are not updated to be in sync with libxl changes.  Example,
the old disk syntax for cdrom seg faults when used as is from the
sample config file.  Also, libxl defaults to hap=1, oos=1.  Not sure
if that is what we want; it probably has no impact on failure case I
suppose but the sample config files are not updated to include the new
hap, oos options with defaults as done with other options as they were
introduced in the past.

4) Lastly, xend/xm works right away when I try to create a domain but
xl fails when built and used as is because of qemu-dm startup failure.
 I will look into this but wanted to let the libxl developers know
that it doesn't work when it is built and used as is.

Kamala

Re: Latest xen-unstable and issues building/using it

[Gianni Tedesco]

On Wed, 2010-08-18 at 17:15 +0100, Kamala Narasimhan wrote:
> 3) Also, it appears the sample config files that get installed under
> /etc/xen are not updated to be in sync with libxl changes.  Example,
> the old disk syntax for cdrom seg faults when used as is from the
> sample config file.  Also, libxl defaults to hap=1, oos=1.  Not sure
> if that is what we want; it probably has no impact on failure case I
> suppose but the sample config files are not updated to include the new
> hap, oos options with defaults as done with other options as they were
> introduced in the past.

The disk/cdrom parsing stuff in xl is known about and I have a fix for
but it needs a little tidy up before I will post it. Been busy with
other things :\

Re: Latest xen-unstable and issues building/using it

[Kamala Narasimhan]

> 4) Lastly, xend/xm works right away when I try to create a domain but
> xl fails when built and used as is because of qemu-dm startup failure.
>  I will look into this but wanted to let the libxl developers know
> that it doesn't work when it is built and used as is.
>

This one turned out to be rather simple - qemu did not understand
'--disable-opengl' param which get passed when opengl is set to 1
(which is the default in the sample config file I was basing off of).
May be we might want to consider commenting out code (temporarily)
around line 1100 in file libxl/libxl.c till the equivalent qemu that
get fetched with xen-unstable understands that option?

Kamala

Re: Re: Latest xen-unstable and issues building/using it

[Stefano Stabellini]

On Wed, 18 Aug 2010, Kamala Narasimhan wrote:
> > 4) Lastly, xend/xm works right away when I try to create a domain but
> > xl fails when built and used as is because of qemu-dm startup failure.
> > ??I will look into this but wanted to let the libxl developers know
> > that it doesn't work when it is built and used as is.
> >
> 
> This one turned out to be rather simple - qemu did not understand
> '--disable-opengl' param which get passed when opengl is set to 1
> (which is the default in the sample config file I was basing off of).
> May be we might want to consider commenting out code (temporarily)
> around line 1100 in file libxl/libxl.c till the equivalent qemu that
> get fetched with xen-unstable understands that option?
> 

The option only works if qemu has been compiled with opengl support.
However it is clear that we are passing -disable-opengl when the user
asks for opengl support instead of the other way around.
I'll send a patch to fix the issue.