mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 10:11:27 +01:00
Luis R. Rodriguez
015330004e
This adds the systemd xen service / module files and integrates
support into the build system.
This goes in with AX_AVAILABLE_SYSTEMD() which will enable
systemd if development libraries have been found on your
build system. If you don't have systemd on target systems
for binaries built with systemd then the binary will not
work, you must explicitly disable systemd support if you
do not want to build systemd support.
When systemd libraries are present only systems that
have booted into systemd go through the systemd initialization,
otherwise the SysVinit is used.
These are originally based on the Fedora systemd files.
Changes made from Fedora's systemd files:
* split sockets into two files to claim different permissions
* Use /bin/sh -c exec to for a simple launcher implementation
* enables systemd socket activation for C xenstored and Ocaml
oxenstored
* use sd_notify(), so change the service to Type=notify, because of
this we remove the PIDFile specification as we don't care for it, and let
systemd do its magic for us, this also means we don't have to fork
so we use --no-fork with systemd
* defines a modules-load.d, its original source file will be shared
between systemd and old init systems
* simplify service files with ConditionVirtualization=xen which uses
the built in systemd virtualization backend detection, these
service files will not be available to start on systems that do not
boot with xen as a hypervisor
* use autoconf to replace @variable@ paths for us which piggy
backs on top of the latest autoconf changes to xen
* removes oxenstored service file in favor of a system variable which
controls which which xentored to use at run time, we avoid multiple
service files this way.
* simplifies startup to not require polling on the sockets
as initial socket management is handled by systemd, we just
take on the socket later once anything pokes at it, a simple nc -U
(as root) on any of the sockets files can activate the service for example.
Anything queued up will be sent to us once we start. Socket activation
should in theory also let us dynamically switch between xenstores but more
importantly we could upgrade xenstored while keeping all active
socket communication queued up, but in order to take advantage of
this we eventually would need to remove the requirement of not being
able to bring down the xenstored. Even though active sockets are
supported since most libxl communication doesn't triggger a check
on the unix socket first administrators are encouraged to enable
the xenstored.service to triggger an initialization of the xenstored
upon bring up. Some systems also never use unix sockets for
communication with the xenstored and as such active sockets will
not be used there.
* allow for xenstored configuration through *either* of these
configuration files:
- /etc/sysconfig/xenstored
- /etc/default/xenstored
The /etc/default/xenstored will let debian based systems do
the same, while SUSE/OpenSUSE/Fedora/RedHat can keep on chugging
with sysconfig. We leave these files all commented out by default
though given that for systemd we want to encourage not using them.
* ensures we create the run directory as most systems will likely
be using a tmpfs for run dirs for the pid files
* Some systems define the selinux context in the systemd Option for the
/var/lib/xenstored tmpfs:
Options=mode=755,context="system_u:object_r:xenstored_var_lib_t:s0"
For the upstream version we remove that and let systems specify the
context on their system /etc/default/xenstored or /etc/sysconfig/xenstored
$XENSTORED_MOUNT_CTX variable, with a default to none.
* takes advantage of the shared xendomains helper for the xendomains
service
* Add the new dom0 that gets kicked off for disk backend access into
its own systemd service associated to xen
We end up with these systemd files:
General requirements:
* proc-xen.mount
* var-lib-xenstored.mount
xenstored:
* xenstored.service
* xenstored.socket
* xenstored_ro.socket
* xenconsoled.service
* xen-qemu-dom0-disk-backend.service.in
Optional:
* xendomains.service
* xen-watchdog.service
As for integration with xen, we house keep all the systemd files
under a new directory tools/hotplug/Linux/systemd/ and will be targeted
by default when building on Linux systems if systemd development
libraries are present at build time.
The systemd files will be sanitized for meta @VARIABLES@ upon
configuration and installed upon the install target. Systems that
do not use systemd can still get systemd service unit files installed
if the build system enabled systemd support, this however does not
mandate a requirement of having systemd libraries present. Old init
scripts are always installed.
If you don't specify a prefix you will end up with the services
files under /usr/local/lib/systemd/system/ by default, and systemd
modules-load.d conf files under /usr/local/lib/modules-load.d/ which
systemd does look for (although it seems this is not documented).
Distributions are expected to provide their /usr/ prefix to end up in
the more generic location upon distribution install at
/usr/lib/systemd/system/ and /usr/lib/modules-load.d/ respectively.
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jan Rękorajski <baggins@pld-linux.org>
Cc: M A Young <m.a.young@durham.ac.uk>
Cc: Jacek Konieczny <jajcus@jajcus.net>
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
246 lines
9.7 KiB
Plaintext
246 lines
9.7 KiB
Plaintext
#################################
|
|
__ __ _ _ ____ _ _ _
|
|
\ \/ /___ _ __ | || | | ___| _ _ _ __ ___| |_ __ _| |__ | | ___
|
|
\ // _ \ '_ \ | || |_ |___ \ _____| | | | '_ \/ __| __/ _` | '_ \| |/ _ \
|
|
/ \ __/ | | | |__ _| ___) |_____| |_| | | | \__ \ || (_| | |_) | | __/
|
|
/_/\_\___|_| |_| |_|(_)____/ \__,_|_| |_|___/\__\__,_|_.__/|_|\___|
|
|
|
|
#################################
|
|
|
|
http://www.xen.org/
|
|
|
|
What is Xen?
|
|
============
|
|
|
|
Xen is a Virtual Machine Monitor (VMM) originally developed by the
|
|
Systems Research Group of the University of Cambridge Computer
|
|
Laboratory, as part of the UK-EPSRC funded XenoServers project. Xen
|
|
is freely-distributable Open Source software, released under the GNU
|
|
GPL. Since its initial public release, Xen has grown a large
|
|
development community, spearheaded by xen.org (http://www.xen.org).
|
|
|
|
The 4.3 release offers a number of improvements, including NUMA
|
|
scheduling affinity, openvswitch integration, and defaulting to
|
|
qemu-xen rather than qemu-traditional for non-stubdom guests.
|
|
(qemu-xen is kept very close to the upstream project.) We also have a
|
|
number of updates to vTPM, and improvements to XSM and Flask to allow
|
|
greater disaggregation. Additionally, 4.3 contains a basic version of
|
|
Xen for the new ARM server architecture, both 32- and 64-bit. And as
|
|
always, there are a number of performance, stability, and security
|
|
improvements under-the hood.
|
|
|
|
This file contains some quick-start instructions to install Xen on
|
|
your system. For more information see http:/www.xen.org/ and
|
|
http://wiki.xen.org/
|
|
|
|
Quick-Start Guide
|
|
=================
|
|
|
|
First, there are a number of prerequisites for building a Xen source
|
|
release. Make sure you have all the following installed, either by
|
|
visiting the project webpage or installing a pre-built package
|
|
provided by your OS distributor:
|
|
* GCC v4.1 or later
|
|
* GNU Make
|
|
* GNU Binutils
|
|
* Development install of zlib (e.g., zlib-dev)
|
|
* Development install of Python v2.3 or later (e.g., python-dev)
|
|
* Development install of curses (e.g., libncurses-dev)
|
|
* Development install of openssl (e.g., openssl-dev)
|
|
* Development install of x11 (e.g. xorg-x11-dev)
|
|
* Development install of uuid (e.g. uuid-dev)
|
|
* Development install of yajl (e.g. libyajl-dev)
|
|
* Development install of libaio (e.g. libaio-dev) version 0.3.107 or
|
|
greater.
|
|
* Development install of GLib v2.0 (e.g. libglib2.0-dev)
|
|
* Development install of Pixman (e.g. libpixman-1-dev)
|
|
* pkg-config
|
|
* bridge-utils package (/sbin/brctl)
|
|
* iproute package (/sbin/ip)
|
|
* udev
|
|
* GNU bison and GNU flex
|
|
* GNU gettext
|
|
* 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc debs)
|
|
* ACPI ASL compiler (iasl)
|
|
|
|
In addition to the above there are a number of optional build
|
|
prerequisites. Omitting these will cause the related features to be
|
|
disabled at compile time:
|
|
* Development install of Ocaml (e.g. ocaml-nox and
|
|
ocaml-findlib). Required to build ocaml components which
|
|
includes the alternative ocaml xenstored.
|
|
* cmake (if building vtpm stub domains)
|
|
* markdown
|
|
* figlet (for generating the traditional Xen start of day banner)
|
|
* systemd daemon development files
|
|
|
|
Second, you need to acquire a suitable kernel for use in domain 0. If
|
|
possible you should use a kernel provided by your OS distributor. If
|
|
no suitable kernel is available from your OS distributor then refer to
|
|
http://wiki.xen.org/wiki/XenDom0Kernels for suggestions for
|
|
suitable kernels to use.
|
|
If you are looking to compile a Dom0 kernel from source, please refer to
|
|
http://wiki.xen.org/wiki/XenParavirtOps.
|
|
|
|
[NB. Unless noted otherwise, all the following steps should be
|
|
performed with root privileges.]
|
|
|
|
1. Download and untar the source tarball file. This will be a
|
|
file named xen-unstable-src.tgz, or xen-$version-src.tgz.
|
|
You can also pull the current version from the mercurial
|
|
repository at http://xenbits.xen.org/
|
|
|
|
# tar xzf xen-unstable-src.tgz
|
|
|
|
Assuming you are using the unstable tree, this will
|
|
untar into xen-unstable. The rest of the instructions
|
|
use the unstable tree as an example, substitute the
|
|
version for unstable.
|
|
|
|
2. cd to xen-unstable (or whatever you sensibly rename it to).
|
|
|
|
3. For the very first build, or if you want to destroy build trees,
|
|
perform the following steps:
|
|
|
|
# ./configure
|
|
# make world
|
|
# make install
|
|
|
|
If you want, you can run ./configure --help to see the list of
|
|
options available options when building and installing Xen.
|
|
|
|
This will create and install onto the local machine. It will build
|
|
the xen binary (xen.gz), the tools and the documentation.
|
|
|
|
You can override the destination for make install by setting DESTDIR
|
|
to some value.
|
|
|
|
4. To rebuild an existing tree without modifying the config:
|
|
# make dist
|
|
|
|
This will build and install xen, tools, and docs into the local dist/
|
|
directory.
|
|
|
|
You can override the destination for make install by setting DISTDIR
|
|
to some value.
|
|
|
|
make install and make dist differ in that make install does the
|
|
right things for your local machine (installing the appropriate
|
|
version of udev scripts, for example), but make dist includes all
|
|
versions of those scripts, so that you can copy the dist directory
|
|
to another machine and install from that distribution.
|
|
|
|
xenstore: xenstored and oxenstored
|
|
====================================
|
|
|
|
Xen uses a configuration database called xenstore [0] to maintain configuration
|
|
and status information shared between domains. A daemon is implemented as part
|
|
of xenstore to act as an interface for access to the database for dom0 and
|
|
guests. Two xenstored daemons are supported, one written in C which we refer
|
|
to as the xenstored (sometimes referred to as cxenstored), and another written
|
|
in Ocaml called oxenstored. Details for xenstore and the different
|
|
implementations can be found on the wiki's xenstore reference guide [1] and
|
|
the xenstored [2] page. You can choose which xenstore you want to enable as
|
|
default on a system through configure:
|
|
|
|
./configure --with-xenstored=xenstored
|
|
./configure --with-xenstored=oxenstored
|
|
|
|
By default oxenstored will be used if the ocaml development tools are found.
|
|
If you enable oxenstored the xenstored will still be built and installed,
|
|
the xenstored used can be changed through the configuration file:
|
|
|
|
/etc/sysconfig/xencommons
|
|
or
|
|
/etc/default/xencommons
|
|
|
|
You can change the preferred xenstored you want to use in the configuration
|
|
but since we cannot stop the daemon a reboot will be required to make the
|
|
change take effect.
|
|
|
|
[0] http://wiki.xen.org/wiki/XenStore
|
|
[1] http://wiki.xen.org/wiki/XenStoreReference
|
|
[2] http://wiki.xen.org/wiki/Xenstored
|
|
|
|
Systemd support
|
|
===============
|
|
|
|
If you have systemd development packages installed you can build binaries
|
|
with systemd support. Systemd support is enabled by default if you have
|
|
systemd development libraries present. If you want to force enable systemd to
|
|
ensure you build binaries with systemd support you can use the --enable-systemd
|
|
flag. Likewise if you want to force disable systemd you can use:
|
|
|
|
./configure --disable-systemd
|
|
|
|
For more details refer to the xen xenstored systemd wiki page [3].
|
|
|
|
[3] http://wiki.xen.org/wiki/Xenstored#xenstored_systemd_support
|
|
|
|
Python Runtime Libraries
|
|
========================
|
|
|
|
Xend (the Xen daemon) has the following runtime dependencies:
|
|
|
|
* Python 2.3 or later.
|
|
In some distros, the XML-aspects to the standard library
|
|
(xml.dom.minidom etc) are broken out into a separate python-xml package.
|
|
This is also required.
|
|
In more recent versions of Debian and Ubuntu the XML-aspects are included
|
|
in the base python package however (python-xml has been removed
|
|
from Debian in squeeze and from Ubuntu in intrepid).
|
|
|
|
URL: http://www.python.org/
|
|
Debian: python
|
|
|
|
* For optional SSL support, pyOpenSSL:
|
|
URL: http://pyopenssl.sourceforge.net/
|
|
Debian: python-pyopenssl
|
|
|
|
* For optional PAM support, PyPAM:
|
|
URL: http://www.pangalactic.org/PyPAM/
|
|
Debian: python-pam
|
|
|
|
* For optional XenAPI support in XM, lxml:
|
|
URL: http://lxml.de/
|
|
Debian: python-lxml
|
|
YUM: python-lxml
|
|
|
|
|
|
Intel(R) Trusted Execution Technology Support
|
|
=============================================
|
|
|
|
Intel's technology for safer computing, Intel(R) Trusted Execution Technology
|
|
(Intel(R) TXT), defines platform-level enhancements that provide the building
|
|
blocks for creating trusted platforms. For more information, see
|
|
http://www.intel.com/technology/security/.
|
|
|
|
Intel(R) TXT support is provided by the Trusted Boot (tboot) module in
|
|
conjunction with minimal logic in the Xen hypervisor.
|
|
|
|
Tboot is an open source, pre- kernel/VMM module that uses Intel(R) TXT to
|
|
perform a measured and verified launch of an OS kernel/VMM.
|
|
|
|
The Trusted Boot module is available from
|
|
http://sourceforge.net/projects/tboot. This project hosts the code in a
|
|
mercurial repo at http://tboot.sourceforge.net/hg/tboot.hg and contains
|
|
tarballs of the source. Instructions in the tboot README describe how
|
|
to modify grub.conf to use tboot to launch Xen.
|
|
|
|
There are optional targets as part of Xen's top-level makefile that will
|
|
download and build tboot: install-tboot, build-tboot, dist-tboot, clean-tboot.
|
|
These will download the latest tar file from the SourceForge site using wget,
|
|
then build/install/dist according to Xen's settings.
|
|
|
|
Required Kernel modules
|
|
======================
|
|
|
|
Xen has a set of Kernel modules which the init scripts ensure to load before
|
|
before starting Xen guests. The list of modules are maintained in one place:
|
|
|
|
* config/$(XEN_OS).modules
|
|
|
|
For more details refer to:
|
|
|
|
http://wiki.xen.org/wiki/Category:Host_Configuration#Kernel_modules
|