Re: [Xen-devel] [PATCH v4 00/15] xen: add systemd support

["Luis R. Rodriguez" <mcgrof@xxxxxxxx>]

On Thu, May 08, 2014 at 12:28:50PM +0100, Anthony PERARD wrote:
> Hi,
> 
> I gave a try to this patch series, the "./configure; make install" and
> the systemd services.
> 
> 
> A) First, what when wrong during make install:
> 
> When I do `./configure --prefix=/usr`, `make install` will put libs into
> /usr/local/lib ... (full list at the bottom of the mail, to help debug).

That is not an issue with --prefix not being respected but rather that
libs will be installed under the libdir variable which is what Xen likes
to use, so you will have to use --libdir=/usr/lib64/ to override that.

If we want to change this to use prefix we can do it but I went with what
was used by the default configuration.

> Also, it would be nice if the --sbindir configure option was working.

--sbindir was not used before so my changes don't add support for it,
so adding support for that is easy but its a separate change, but easy
and I'd rather we do this separately. Right now we respect the old
behaviour and use SBINDIR=$prefix/sbin

> B) Next, xenstored.socket:
> 
> I install xen, activate the socket, reboot the machine, and:
> $ xl info
> xc: error: Could not obtain handle on privileged command interface (2 = No 
> such file or directory): Internal error
> libxl: error: libxl.c:99:libxl_ctx_alloc: cannot open libxc handle: No such 
> file or directory
> cannot init xl context

You need to make sure ldconfig us run on the system after installation.
I noted this in the mailing list and I was told that we never do this
on the build system, so the onus is on the person installing to use this.
This also bit me on the ass a few times, and hence why I wanted to also
run it within the build system.

> So I tried `nc -U /var/run/xenstored/socket_ro`,

I made some changes which will require now this to be run as root as I had
left the socket open widely, my next series addresses that.

> but it appear that
> /var/lib/xenstored those not mount because of an empty context= option.
> Once the context= options have been removed, xenstored is finaly started.

Well that is odd, an empty context works here, what system are you using?
Mind if we roll in the changes as we have them now and address this separately?
Can't think of a way to deal with this cleanly right now.

> Then, `xl create hvm_guest`. This does not return ...
> I think qemu is not happy about xenstore, this is what I get from a `xl
> -vvv create hvm_guest`:
> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch w=0x127b9a8 
> wpath=/local/domain/0/device-model/3/state token=3/0: register slotnum=3
> libxl: debug: libxl_create.c:1370:do_domain_create: ao 0x127ce90: inprogress: 
> poller=0x127c5e0, flags=i
> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0x127b9a8 
> wpath=/local/domain/0/device-model/3/state token=3/0: event 
> epath=/local/domain/0/device-model/3/state
> (qemu is running)
> Actually, dmesg said that both xl and qemu-system-i386 proccess are
> blocked. I suppose qemu is not able to access xenstore.

I traced this down to that bug fix on mmap() failing, and the unchecked failure
on madvise with the fork option. Apart from this I also found that the xl 
library
should not use systemd but rather just open the socket regularly, I've fixed 
this
on my series and will push out the new changes soon.

  Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel