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

[Anthony PERARD <anthony.perard@citrix.com>]

On Tue, Apr 29, 2014 at 06:11:53PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> This is my 4th series which I addresses all feedback from the
> first 3 series on adding systemd support into xen. I've taken
> things a bit further, I've been avoiding autoconf but in the end
> that proved to provide the best solution. Additionally not
> originally understanding systemd's socket stuff prompted me to
> look into that and decided its best to just switch to active sockets
> for systemd [0] intregration for both censtored and oxenstored. I've
> also decided its best to avoid separate service files for the
> two daemons given that we can do this cleanly with autoconf.
> 
> I've run time tested this against today's tip against the
> upstream kernel, on OpenSUSE using both censtored and oxenstored.
> 
> To build you can use either of with the default preferring
> oxenstored if ocaml tools are present:
> 
> ./configure --with-xenstored=cxenstored --enable-systemd
> ./configure --with-xenstored=oxenstored --enable-systemd
> 
> Systems should just have to:
> 
> systemctl enable xenstored.socket
> 
> And then anything that will tickle the sockets:
> 
> /var/run/xenstored/socket
> /var/run/xenstored/socket_ro
> 
> will trigger either censtored or oxenstored to activate. This
> example suffices:
> 
> nc -U /var/run/xenstored/socket_ro
> 
> This example also happens to test the order of supply / demand
> of sockets through sytsemd's active socket mechanism and our
> integration to do this in order. Sine we cannot currently stop
> the xenstore this means we cannot take advantage of dynamically
> switching xensrores live, but if that is fixed we should be able
> to dynamically swap even the different types of xenstore on a
> live system or just upgrade the xenstore without a reboot.
> 
> The ordering of active sockets implementation is begging to be
> shared with a common small library but given that xc / xl are
> not specific to the xenstore it would be pointless to stuff and
> duplicate code for both in there. Both the cxenstore and oxenstored
> handle their own store access on their own, if there's a desire to
> unify that small piece of code we should consider other things to
> stuff on it. For now this goes separately.
> 
> Systemd autconf support was split out as much as possible from
> xen to make it useful for any other project, perhaps this can
> go upstream to systemd.
> 
> Ocaml lacks support for systemd and as such I needed to extend
> oxenstored support through a small stub for access to systemd.
> System'd sd_listen_fds() can technically easily be implemented
> in ocaml *but* given that FD_CLOEXEC support through the new
> Unix.set_cloexec is only available on 4.00.1+dev which isn't
> yet widely available I decided agianst this, this lets
> systemd take care of FD_CLOEXEC for us. Proper support for
> systemd should instead in the end be merged upstream into
> ocaml, but who knows when that will happen.
> 
> Given the slew of autoconf updates to xen I only provide an
> autogen.sh update after the last change to make things easier
> to review.
> 
> [0] http://0pointer.de/blog/projects/socket-activation2.html
> [1] http://caml.inria.fr/mantis/view.php?id=5569

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).
Also, it would be nice if the --sbindir configure option was working.


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

So I tried `nc -U /var/run/xenstored/socket_ro`, 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.

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.


That is from me for now.

Regards,




usr/local/lib
usr/local/lib/fs
usr/local/lib/fs/ext2fs-lib
usr/local/lib/fs/ext2fs-lib/fsimage.so
usr/local/lib/fs/fat
usr/local/lib/fs/fat/fsimage.so
usr/local/lib/fs/iso9660
usr/local/lib/fs/iso9660/fsimage.so
usr/local/lib/fs/reiserfs
usr/local/lib/fs/reiserfs/fsimage.so
usr/local/lib/fs/ufs
usr/local/lib/fs/ufs/fsimage.so
usr/local/lib/fs/xfs
usr/local/lib/fs/xfs/fsimage.so
usr/local/lib/fs/zfs
usr/local/lib/fs/zfs/fsimage.so
usr/local/lib/libblktapctl.so -> libblktapctl.so.1.0
usr/local/lib/libblktapctl.so.1.0 -> libblktapctl.so.1.0.0
usr/local/lib/libblktapctl.so.1.0.0
usr/local/lib/libfsimage.so -> libfsimage.so.1.0
usr/local/lib/libfsimage.so.1.0 -> libfsimage.so.1.0.0
usr/local/lib/libfsimage.so.1.0.0
usr/local/lib/libvhd.so -> libvhd.so.1.0
usr/local/lib/libvhd.so.1.0 -> libvhd.so.1.0.0
usr/local/lib/libvhd.so.1.0.0
usr/local/lib/libxenctrl.so -> libxenctrl.so.4.4
usr/local/lib/libxenctrl.so.4.4 -> libxenctrl.so.4.4.0
usr/local/lib/libxenctrl.so.4.4.0
usr/local/lib/libxenguest.so -> libxenguest.so.4.4
usr/local/lib/libxenguest.so.4.4 -> libxenguest.so.4.4.0
usr/local/lib/libxenguest.so.4.4.0
usr/local/lib/libxenlight.so -> libxenlight.so.4.4
usr/local/lib/libxenlight.so.4.4 -> libxenlight.so.4.4.0
usr/local/lib/libxenlight.so.4.4.0
usr/local/lib/libxenstat.so -> libxenstat.so.0
usr/local/lib/libxenstat.so.0 -> libxenstat.so.0.0
usr/local/lib/libxenstat.so.0.0
usr/local/lib/libxenstore.so -> libxenstore.so.3.0
usr/local/lib/libxenstore.so.3.0 -> libxenstore.so.3.0.3
usr/local/lib/libxenstore.so.3.0.3
usr/local/lib/libxenvchan.so -> libxenvchan.so.1.0
usr/local/lib/libxenvchan.so.1.0 -> libxenvchan.so.1.0.0
usr/local/lib/libxenvchan.so.1.0.0
usr/local/lib/libxlutil.so -> libxlutil.so.4.3
usr/local/lib/libxlutil.so.4.3 -> libxlutil.so.4.3.0
usr/local/lib/libxlutil.so.4.3.0
usr/local/lib/xen
usr/local/lib/xen/bin
usr/local/lib/xen/bin/libxl-save-helper
usr/local/lib/xen/bin/lsevtchn
usr/local/lib/xen/bin/pygrub
usr/local/lib/xen/bin/readnotes
usr/local/lib/xen/bin/xenconsole
usr/local/lib/xen/bin/xenctx
usr/local/lib/xen/bin/xenpvnetboot

-- 
Anthony PERARD