https://wiki.xenproject.org/api.php?action=feedcontributions&user=Wenzel&feedformat=atomXen - User contributions [en]2024-03-28T09:00:46ZUser contributionsMediaWiki 1.31.3https://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source&diff=19208Compiling Xen From Source2019-03-13T15:23:59Z<p>Wenzel: /* Post-Installation */ - systemd: remove xenstored as it's an dependency and should not enabled maually</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen Project software from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen Project 4.2 release, but an attempt will be made to point out differences from previous releases where relevant.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Why Build From Source?==<br />
<br />
Before embarking on the process of building Xen Project software yourself it is worth considering whether this is even necessary. There are many distributions around these days which have excellent support for Xen available right from the package manager, a partial list is available at [[Dom0 Kernels for Xen]]. Where possible it is highly recommended that users consume Xen Project via their chosen distribution wherever possible. Using the distribution packaging will give you a much more integrated solution and allow you to take advantage of all the resources provided by your distribution (e.g. documentation, support etc). You can find articles on how to install Xen Project on various distributions in [[:Category:Host Install]].<br />
<br />
The remainder of this document assumes that you have considered this and really do want to build from source.<br />
<br />
==Host (Domain 0) OS Installation==<br />
<br />
Before installing Xen Project you will first need to install your domain 0 OS, unless you have already done so. [[Host OS Install Considerations]] contains some things which you might want to consider while doing this.<br />
<br />
==Obtaining the Xen Project Source Code==<br />
<br />
The primary ways to obtain the Xen Project source code for a stable release are via the release tarballs or by cloning from the appropriate Mercurial source repository. For the development version of Xen Project (''xen-unstable'') Git is the primary source and Mercurial is the secondary source.<br />
<br />
===Release Tarballs===<br />
<br />
The latest Xen Project releases are linked to from [http://www.xen.org/products/downloads.html The Xen.org download page]<br />
<br />
===Git===<br />
<br />
The source code repositories are hosted using the Git version control system on [http://xenbits.xen.org/ xenbits].<br />
<br />
Each stable release has its own branch ''stable-X.Y'' (e.g. stable-4.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]). The code intended for the next stable point release is added to the branch ''staging-X.Y'' (e.g. staging-4.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]), and after they pass automated tests they will be pushed to ''stable-X.Y'' for the next release. The point releases are tagged in the main tree with ''RELEASE-X.Y.Z'' (e.g. RELEASE-4.2.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]). The result of automated tests are available on [http://lists.xen.org/mailman/listinfo/xen-devel xen-devel] mailing list.<br />
<br />
[[Xen Repositories|Xen Project Repositories]] contains information on the various repositories for the stable and development branches.<br />
<br />
To clone the source first install ''Git'' using your distro's package manager. Then execute the following command:<br />
$ git clone '''URL'''<br />
Where '''URL''' is the URL of the repository you wish to clone. In our case we should use:<br />
$ git clone git://xenbits.xen.org/xen.git<br />
As the default HEAD in xen.git is ''master'', your local repository will also have a branch called ''master'' pointing to the upstream branch.<br />
If you wish to use different HEAD (say, ''staging''), you can:<br />
$ cd xen; git checkout -b staging origin/staging<br />
You can also checkout any tags, branches as you wish.<br />
<br />
===Mercurial===<br />
<br />
<strong>Please note that XenProject.org has moved to using Git. The following section is deprecated. We do maintain Mercurial repositories mirroring Git ones, so we retain following section for reference.</strong><br />
<br />
Xen Project's source code repositories are hosted using the [http://mercurial.selenic.com/ Mercurial] version control system on [http://xenbits.xen.org/ xenbits].<br />
<br />
Each stable release has it's own branch ''xen-X.Y-testing.hg'' (e.g. [http://xenbits.xen.org/hg/xen-4.2-testing.hg xen-4.2-testing.hg]) where code intended for the next stable point release is added. The Xen Project development branch is known as ''xen-unstable'' and has its own repository [http://xenbits.xen.org/hg/xen-unstable.hg xen-unstable.hg].<br />
<br />
Each stable and development branch is available in two forms either tested (the main branch) or untested (the ''staging'' branch). When commits are made to a Xen Project tree they are first added to the ''staging'' branch and only propagated to the main branch after automated testing has passed. For example all commits to the Xen Project development branch will initially appear in [http://xenbits.xen.org/hg/staging/xen-unstable.hg staging/xen-unstable.hg] and then propagate to [http://xenbits.xen.org/hg/xen-unstable.hg xen-unstable.hg] after automated testing has completed. The automated test results are posted to the [http://lists.xen.org/mailman/listinfo/xen-devel xen-devel] mailing list.<br />
<br />
[[Xen Repositories|Xen Project Repositories]] contains information on the various repositories for the stable and development branches.<br />
<br />
To clone the source first install the ''mercurial'' tool using your distributions package manager. Then execute the following command:<br />
$ hg clone '''URL'''<br />
Where '''URL''' is the URL of the repository you wish to clone. e.g. to clone the latest tested ''xen-unstable'' tree:<br />
$ hg clone http://xenbits.xen.org/hg/xen-unstable.hg<br />
Or to clone the ''staging'' (e.g. not yet tested) ''xen-unstable'' tree:<br />
$ hg clone http://xenbits.xen.org/hg/staging/xen-unstable.hg<br />
You may want to get a specific changeset (revision), for example when trying to replicate someone else's build, or when dealing with other patches you have to apply afterwards. You can do this with the -r option. For example, to get changeset 25364:<br />
$ hg clone -r 25364 http://xenbits.xen.org/hg/xen-unstable.hg<br />
<br />
==Quick-Start==<br />
<br />
The ''README'' at the top level of the Xen Project source code tree contains a quick-start guide to building the software. This provides a quick overview of the process and requirements for building Xen Project software and will generally contain the most up to date information specific to the particular source tree you are looking at. After obtaining the Xen Project source this is the first document you should read.<br />
<br />
==Building from Source==<br />
<br />
This section documents all known requirements to build from source.<br />
<br />
===Updated /sbin/installkernel on Linux ===<br />
<br />
Linux distributions shipping with grub2 will need to ensure that their /sbin/installkernel script, which has to be provided by each Linux distribution, copies the the kernel configuration upon a custom kernel install time. The requirement for the config file comes from [http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub.d/20_linux_xen.in upstream grub2 /etc/grub.d/20_linux_xen] which <br />
will only add xen as an instance to your grub.cfg if and only if it finds in your config file either of:<br />
<br />
CONFIG_XEN_DOM0=y<br />
CONFIG_XEN_PRIVILEGED_GUEST=y<br />
<br />
Without this a user compiling and installing their own kernel with proper support for xen and with the xen hypervisor present will not get their respective grub2 update script to pick up the xen hypervisor. Debian testing has proper support for this, OpenSUSE required [https://github.com/openSUSE/mkinitrd/commit/56f8a20e1bf3efa9c822a724cb33f5683818b7ec this change upstream on mkinitrd], so OpenSUSE folks will want to get the latest /sbin/installkernel hosted on the [https://github.com/openSUSE/mkinitrd OpenSUSE mkinitrd repository on github].<br />
<br />
# If on OpenSUSE update your /sbin/installkernel<br />
git clone https://github.com/openSUSE/mkinitrd.git<br />
cd mkinitrd<br />
sudo cp sbin/installkernel /sbin/installkernel <br />
<br />
Fedora might need a similar update. Please edit this wiki once you confirm.<br />
<br />
===Build Dependencies===<br />
<br />
Xen Project uses several external libraries and tools. The primary list of these prerequisites is the list present in the ''README'' file.<br />
<br />
Even this list assumes some sort of basic development environment. A good starting point for this is to use your distributions ''development install'' package option.<br />
<br />
==== Build Dependencies - Debian / Ubuntu ====<br />
<br />
Under Debian / Ubuntu (and derived distributions) install the ''build-essential'' package:<br />
# apt-get install build-essential<br />
<br />
you also need to install these additional debs:<br />
# apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig tgif <br />
# apt-get install texinfo texlive-latex-base texlive-latex-recommended texlive-fonts-extra texlive-fonts-recommended pciutils-dev mercurial<br />
# apt-get install make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev patch libvncserver-dev libsdl-dev libjpeg62-dev<br />
# apt-get install iasl libbz2-dev e2fslibs-dev git-core uuid-dev ocaml ocaml-findlib libx11-dev bison flex xz-utils libyajl-dev<br />
# apt-get install gettext libpixman-1-dev libaio-dev markdown pandoc<br />
<br />
And if you're building on Wheezy onward:<br />
# apt-get install libc6-dev-i386<br />
<br />
One useful shortcut can be to use your distributions package manager to install all the prerequisite packages is to install those packages which are noted as being required to build the distribution's own Xen packages. e.g. under Debian or a Debian derived distribution:<br />
# apt-get build-dep xen<br />
<br />
However you need to be mindful of new prerequisites added between whatever version of Xen Project software is in your distribution and the version you are building when using this trick.<br />
<br />
==== Build Dependencies - OpenSUSE ====<br />
<br />
If you're now on the latest OpenSUSE you'll note its now a<br />
rolling distribution base. The default instructions do not actually encourage you to<br />
install the source repositories, and even if you did<br />
install them the instructions disable them by default, so<br />
be sure to install them and enable them otherwise<br />
the command zypper source-install -d won't work.<br />
To enable the required repository if you already had it<br />
installed:<br />
<br />
# zypper mr -e repo-src-oss <br />
<br />
Now get the build dependencies for Xen<br />
<br />
# zypper source-install -d xen<br />
<br />
Here's a list of things not currentloy picked up by the build dependencies which have been found to be needed:<br />
<br />
# zypper install systemd-devel gettext-tools\<br />
ocaml ocaml-compiler-libs ocaml-runtime \<br />
ocaml-ocamldoc ocaml-findlib glibc-devel-32bit make patch<br />
<br />
While at it also get the build dependencies for Linux:<br />
<br />
# zypper source-install -d kernel-desktop<br />
<br />
==== Build Dependencies - Fedora ====<br />
<br />
These instructions are kept separate from RHEL / Centos as Fedora is updated more frequently, so you are expected to do less work to build the latest and greatest Xen.<br />
<br />
Install known build dependencies:<br />
<br />
# yum-builddep xen<br />
<br />
Install things not picked up by the current build dependencies:<br />
<br />
# yum install glibc-devel.x86_64 systemd-devel.x86_64<br />
<br />
Get build dependencies for Linux, the kernel, while at it:<br />
<br />
# yum-builddep kernel <br />
<br />
==== Build Dependencies - RHEL / Centos ====<br />
<br />
Under RHEL, CentOS, Fedora based distributions you want to install the ''Development Tools'' package groups:<br />
# yum groupinstall "Development Tools"<br />
<br />
(On old CentOS and Fedora, a group called ''Development Libraries'' should, if available, installed too. That is not present in recent releases of the distributions any longer, though).<br />
<br />
Then install known build dependencies (confirmation needed if this works on RHEL / Centos):<br />
<br />
# yum-builddep xen<br />
<br />
You also need to install these additional rpms:<br />
<br />
# yum install transfig wget tar less texi2html libaio-devel dev86 glibc-devel e2fsprogs-devel gitk mkinitrd iasl xz-devel bzip2-devel<br />
# yum install pciutils-libs pciutils-devel SDL-devel libX11-devel gtk2-devel bridge-utils PyXML qemu-common qemu-img mercurial texinfo<br />
# yum install libidn-devel yajl yajl-devel ocaml ocaml-findlib ocaml-findlib-devel python-devel uuid-devel libuuid-devel openssl-devel<br />
# yum install python-markdown pandoc systemd-devel glibc-devel.i686<br />
<br />
If on CentOS, for some of this packages (e.g., '''dev86''' and '''pandoc'''), enabling the [http://fedoraproject.org/wiki/EPEL EPEL] [http://fedoraproject.org/wiki/EPEL additional repository] is necessary.<br />
<br />
==== Additional notes ====<br />
<br />
Having installed this you should then install each of the prerequisites listed in the ''README'' using your distribution's package management tool. In general the Xen Project code tries to only depend upon external tools and libraries which are commonly available in distributions therefore obtaining the prerequisites other than from your distribution's package management system is out of scope for this document. If you have trouble locating a particular prerequisite then please contact the [http://lists.xenproject.org/mailman/listinfo/xen-users xen-users] mailing list.<br />
<br />
===Configure===<br />
<br />
From Xen Project 4.2 onwards, the software uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen Project, as well as compile time sanity checking. To configure Xen Project, simply run the provided ''configure'' script:<br />
$ ./configure<br />
<br />
To see the various options run the configure script with ''--help'' e.g.:<br />
$ ./configure --help<br />
[...]<br />
Optional Features:<br />
--disable-option-checking ignore unrecognized --enable/--with options<br />
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)<br />
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]<br />
--enable-githttp Download GIT repositories via HTTP (default is<br />
DISABLED)<br />
<br />
This step is only required from Xen Project 4.2 onwards. Prior to Xen Project 4.2 these options could be configured by passing a variable on the ''make'' command line during build & install or by writing the variable to a file named ''.config'' at the top level of the source tree.<br />
<br />
====Use ''http://'' Rather Than ''git://'' to Clone Additional Repositories====<br />
<br />
When building the software from Mercurial, the build system will automatically clone several additional repositories from the network. Some of these repositories use the version control system which uses its own protocol on a specific port. Sometimes this causes issues due to firewalls etc blocking the git port. This can be worked around by instructing the Xen build system to clone such repositories using a less efficient HTTP based protocol:<br />
$ ./configure --enable-githttp<br />
<br />
Prior to Xen Project 4.2 this could be achieved by writing ''GIT_HTTP=y'' to your ''.config'':<br />
$ cat .config<br />
GIT_HTTP = y<br />
<br />
====Library Installation Directory====<br />
<br />
Xen Project 4.2 onwards defaults to installing libraries into /usr/lib by default and from 4.3 onwards defaults to installing to /usr/local/lib by default.<br />
<br />
Users on systems which use /usr/local/lib64 for 64-bit libraries should use the --libdir option. e.g:<br />
<br />
$ ./configure --libdir=/usr/local/lib64<br />
<br />
Failure to do this usually results in errors about libraries not found or using older versions of the libraries which will likely not work.<br />
<br />
_NB_: If you are using `--prefix=/usr` you should use `--libdir=/usr/lib64` too.<br />
<br />
====Systemd====<br />
<br />
If the target system uses [http://www.freedesktop.org/wiki/Software/systemd/ systemd], do not forget to enable it:<br />
<br />
$ ./configure --enable-systemd<br />
<br />
====Python Prefix and Module Layout====<br />
<br />
On some distros (e.g. Debian and Ubuntu) Xen Project may install the python parts of the code into the wrong place (See [http://bugs.debian.org/693721 Debian bug #693721]). Therefore it is necessary to set ''PYTHON_PREFIX_ARG=--install-layout=deb'':<br />
$ cat .config<br />
PYTHON_PREFIX_ARG=--install-layout=deb<br />
<br />
Some versions of Ubuntu have a [https://bugs.launchpad.net/ubuntu/+bug/362570 bug] which requires instead that ''PYTHON_PREFIX_ARG'' is to set the empty string:<br />
$ cat .config<br />
PYTHON_PREFIX_ARG=<br />
<br />
As of 4.2 this option is not yet supported by the ''configure'' script and therefore should still be set via ''.config'' or on the ''make'' command line.<br />
<br />
The most common symptom of this issue is ''pygrub'' failing to work, with output similar to:<br />
<br />
Traceback (most recent call last):<br />
File "/usr/lib/xen/bin/pygrub", line 20, in <module><br />
import xen.lowlevel.xc<br />
ImportError: No module named xen.lowlevel.xc<br />
<br />
===Build & Install===<br />
<br />
{{Warning|Xen Project downloads various components at build time. This means that building Xen Project currently requires an active connection to the Internet}}<br />
<br />
To build all components (hypervisor, tools, docs, stubdomains, etc) you can use the ''dist'' target.<br />
$ make dist<br />
<br />
If you wish to just (re)build a single component you can use the appropriate ''dist-COMPONENT'' target:<br />
$ make dist-xen<br />
$ make dist-tools<br />
$ make dist-docs<br />
$ ... etc ...<br />
<br />
If you want to rebuild a tree as if from a fresh check then you can use the ''world'' target. This is effectively the same as ''clean'' and the ''dist''<br />
$ make world<br />
<br />
All of the above targets will build and install the appropriate component into the ''dist'' subdirectory but not actually install onto the system.<br />
<br />
To install onto the local machine simply call the ''install'' target (as root):<br />
# make install<br />
<br />
As with ''dist'' you can also install individual components using the appropriate ''install-COMPONENT'' target:<br />
# make install-xen<br />
# make install-tools<br />
# make install-docs<br />
# ... etc ...<br />
<br />
If you want to install onto a remote machine then you can simply copy the ''dist'' directory over and '''TBD'''<br />
<br />
A better option is to make a "package-ball" -- a package which is the equivalent of a tarball with no dependency checking or set-up. There are target for either deb-based systems:<br />
# make debball<br />
or rpm-based systems:<br />
# make rpmball<br />
<br />
Packages are placed in the ''dist/'' directory.<br />
<br />
Installing the resulting package is functionally equivalent to the ''make install'' target above, but because the files are tracked by the package manager, it is easier to remove or update.<br />
<br />
After installing (either via ''make install'' or a packageballl) you rebuild your dynamic linker cache by running:<br />
# /sbin/ldconfig<br />
<br />
To get more information on the available targets use the ''help'' target:<br />
$ make help<br />
<br />
=== Linux grub2 update ===<br />
<br />
When on Linux and using grub2 after installing Xen you will also need to make sure grub2 will pick up your new shiny Xen hypervisor. Distributions differ on how to do this. This section documents how to do this for known distributions.<br />
<br />
==== update grub2 config on OpenSUSE ====<br />
<br />
# update-bootloader --refresh<br />
<br />
==== update grub2 config on Debian ====<br />
<br />
# update-grub<br />
<br />
==== update grub2 config on Fedora ====<br />
<br />
TBD<br />
<br />
==== update grub2 config on RHEL / Centos ====<br />
<br />
TBD<br />
<br />
===Troubleshooting===<br />
<br />
* If SeaBIOS fails to compile when building Xen 4.2 on a system with a non-English locale, try setting LC_ALL to en_US.UTF-8 before calling make:<br />
# export LC_ALL=en_US.UTF-8<br />
# make world<br />
<br />
===Kernels===<br />
<br />
The Linux kernel now supports different hypervisors with one kernel. There is also no requirement for a domain 0 (or guest) kernel to match your hypervisor so you are free to pick the kernel which best suits your needs (e.g. many distributions supply a kernel which is compatible with Xen Project, which is a quick and easy path). [[Dom0 Kernels for Xen]] contains some guidance on this issue.<br />
<br />
==== Compiling latest Linux kernel support ====<br />
<br />
If compiling Linux from source for either dom0 or a guest you can now enable Xen support for both through one simple kernel configuration helper, this was added as of v4.2:<br />
<br />
make xenconfig<br />
<br />
This lets you build a kernel which can support xen dom0 or xen guests on i386, x86-64 and arm64.<br />
<br />
===Post-Installation===<br />
<br />
A few system services should be manually enabled after the installation:<br />
<br />
====SystemV====<br />
<br />
Required:<br />
<br />
update-rc.d xencommons defaults 19 18<br />
<br />
Optional:<br />
<br />
update-rc.d xendomains defaults 21 20<br />
update-rc.d xen-watchdog defaults 22 23<br />
<br />
<br />
====systemd====<br />
<br />
Required:<br />
<br />
systemctl enable xen-qemu-dom0-disk-backend.service<br />
systemctl enable xen-init-dom0.service<br />
systemctl enable xenconsoled.service<br />
<br />
Optional:<br />
<br />
systemctl enable xendomains.service<br />
systemctl enable xen-watchdog.service<br />
systemctl enable xendriverdomain.service<br />
<br />
After making those changes reboot the system.<br />
<br />
==Host Configuration==<br />
<br />
Once the Xen Project code is installed there is still some host level setup required. [[:Category:Host Configuration]] covers this.<br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:Developers]] [[Category:Fundamentals]]</div>Wenzelhttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source&diff=19207Compiling Xen From Source2019-03-13T15:13:30Z<p>Wenzel: /* Post-Installation */ - update systemd optional service list</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen Project software from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen Project 4.2 release, but an attempt will be made to point out differences from previous releases where relevant.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Why Build From Source?==<br />
<br />
Before embarking on the process of building Xen Project software yourself it is worth considering whether this is even necessary. There are many distributions around these days which have excellent support for Xen available right from the package manager, a partial list is available at [[Dom0 Kernels for Xen]]. Where possible it is highly recommended that users consume Xen Project via their chosen distribution wherever possible. Using the distribution packaging will give you a much more integrated solution and allow you to take advantage of all the resources provided by your distribution (e.g. documentation, support etc). You can find articles on how to install Xen Project on various distributions in [[:Category:Host Install]].<br />
<br />
The remainder of this document assumes that you have considered this and really do want to build from source.<br />
<br />
==Host (Domain 0) OS Installation==<br />
<br />
Before installing Xen Project you will first need to install your domain 0 OS, unless you have already done so. [[Host OS Install Considerations]] contains some things which you might want to consider while doing this.<br />
<br />
==Obtaining the Xen Project Source Code==<br />
<br />
The primary ways to obtain the Xen Project source code for a stable release are via the release tarballs or by cloning from the appropriate Mercurial source repository. For the development version of Xen Project (''xen-unstable'') Git is the primary source and Mercurial is the secondary source.<br />
<br />
===Release Tarballs===<br />
<br />
The latest Xen Project releases are linked to from [http://www.xen.org/products/downloads.html The Xen.org download page]<br />
<br />
===Git===<br />
<br />
The source code repositories are hosted using the Git version control system on [http://xenbits.xen.org/ xenbits].<br />
<br />
Each stable release has its own branch ''stable-X.Y'' (e.g. stable-4.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]). The code intended for the next stable point release is added to the branch ''staging-X.Y'' (e.g. staging-4.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]), and after they pass automated tests they will be pushed to ''stable-X.Y'' for the next release. The point releases are tagged in the main tree with ''RELEASE-X.Y.Z'' (e.g. RELEASE-4.2.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]). The result of automated tests are available on [http://lists.xen.org/mailman/listinfo/xen-devel xen-devel] mailing list.<br />
<br />
[[Xen Repositories|Xen Project Repositories]] contains information on the various repositories for the stable and development branches.<br />
<br />
To clone the source first install ''Git'' using your distro's package manager. Then execute the following command:<br />
$ git clone '''URL'''<br />
Where '''URL''' is the URL of the repository you wish to clone. In our case we should use:<br />
$ git clone git://xenbits.xen.org/xen.git<br />
As the default HEAD in xen.git is ''master'', your local repository will also have a branch called ''master'' pointing to the upstream branch.<br />
If you wish to use different HEAD (say, ''staging''), you can:<br />
$ cd xen; git checkout -b staging origin/staging<br />
You can also checkout any tags, branches as you wish.<br />
<br />
===Mercurial===<br />
<br />
<strong>Please note that XenProject.org has moved to using Git. The following section is deprecated. We do maintain Mercurial repositories mirroring Git ones, so we retain following section for reference.</strong><br />
<br />
Xen Project's source code repositories are hosted using the [http://mercurial.selenic.com/ Mercurial] version control system on [http://xenbits.xen.org/ xenbits].<br />
<br />
Each stable release has it's own branch ''xen-X.Y-testing.hg'' (e.g. [http://xenbits.xen.org/hg/xen-4.2-testing.hg xen-4.2-testing.hg]) where code intended for the next stable point release is added. The Xen Project development branch is known as ''xen-unstable'' and has its own repository [http://xenbits.xen.org/hg/xen-unstable.hg xen-unstable.hg].<br />
<br />
Each stable and development branch is available in two forms either tested (the main branch) or untested (the ''staging'' branch). When commits are made to a Xen Project tree they are first added to the ''staging'' branch and only propagated to the main branch after automated testing has passed. For example all commits to the Xen Project development branch will initially appear in [http://xenbits.xen.org/hg/staging/xen-unstable.hg staging/xen-unstable.hg] and then propagate to [http://xenbits.xen.org/hg/xen-unstable.hg xen-unstable.hg] after automated testing has completed. The automated test results are posted to the [http://lists.xen.org/mailman/listinfo/xen-devel xen-devel] mailing list.<br />
<br />
[[Xen Repositories|Xen Project Repositories]] contains information on the various repositories for the stable and development branches.<br />
<br />
To clone the source first install the ''mercurial'' tool using your distributions package manager. Then execute the following command:<br />
$ hg clone '''URL'''<br />
Where '''URL''' is the URL of the repository you wish to clone. e.g. to clone the latest tested ''xen-unstable'' tree:<br />
$ hg clone http://xenbits.xen.org/hg/xen-unstable.hg<br />
Or to clone the ''staging'' (e.g. not yet tested) ''xen-unstable'' tree:<br />
$ hg clone http://xenbits.xen.org/hg/staging/xen-unstable.hg<br />
You may want to get a specific changeset (revision), for example when trying to replicate someone else's build, or when dealing with other patches you have to apply afterwards. You can do this with the -r option. For example, to get changeset 25364:<br />
$ hg clone -r 25364 http://xenbits.xen.org/hg/xen-unstable.hg<br />
<br />
==Quick-Start==<br />
<br />
The ''README'' at the top level of the Xen Project source code tree contains a quick-start guide to building the software. This provides a quick overview of the process and requirements for building Xen Project software and will generally contain the most up to date information specific to the particular source tree you are looking at. After obtaining the Xen Project source this is the first document you should read.<br />
<br />
==Building from Source==<br />
<br />
This section documents all known requirements to build from source.<br />
<br />
===Updated /sbin/installkernel on Linux ===<br />
<br />
Linux distributions shipping with grub2 will need to ensure that their /sbin/installkernel script, which has to be provided by each Linux distribution, copies the the kernel configuration upon a custom kernel install time. The requirement for the config file comes from [http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub.d/20_linux_xen.in upstream grub2 /etc/grub.d/20_linux_xen] which <br />
will only add xen as an instance to your grub.cfg if and only if it finds in your config file either of:<br />
<br />
CONFIG_XEN_DOM0=y<br />
CONFIG_XEN_PRIVILEGED_GUEST=y<br />
<br />
Without this a user compiling and installing their own kernel with proper support for xen and with the xen hypervisor present will not get their respective grub2 update script to pick up the xen hypervisor. Debian testing has proper support for this, OpenSUSE required [https://github.com/openSUSE/mkinitrd/commit/56f8a20e1bf3efa9c822a724cb33f5683818b7ec this change upstream on mkinitrd], so OpenSUSE folks will want to get the latest /sbin/installkernel hosted on the [https://github.com/openSUSE/mkinitrd OpenSUSE mkinitrd repository on github].<br />
<br />
# If on OpenSUSE update your /sbin/installkernel<br />
git clone https://github.com/openSUSE/mkinitrd.git<br />
cd mkinitrd<br />
sudo cp sbin/installkernel /sbin/installkernel <br />
<br />
Fedora might need a similar update. Please edit this wiki once you confirm.<br />
<br />
===Build Dependencies===<br />
<br />
Xen Project uses several external libraries and tools. The primary list of these prerequisites is the list present in the ''README'' file.<br />
<br />
Even this list assumes some sort of basic development environment. A good starting point for this is to use your distributions ''development install'' package option.<br />
<br />
==== Build Dependencies - Debian / Ubuntu ====<br />
<br />
Under Debian / Ubuntu (and derived distributions) install the ''build-essential'' package:<br />
# apt-get install build-essential<br />
<br />
you also need to install these additional debs:<br />
# apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig tgif <br />
# apt-get install texinfo texlive-latex-base texlive-latex-recommended texlive-fonts-extra texlive-fonts-recommended pciutils-dev mercurial<br />
# apt-get install make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev patch libvncserver-dev libsdl-dev libjpeg62-dev<br />
# apt-get install iasl libbz2-dev e2fslibs-dev git-core uuid-dev ocaml ocaml-findlib libx11-dev bison flex xz-utils libyajl-dev<br />
# apt-get install gettext libpixman-1-dev libaio-dev markdown pandoc<br />
<br />
And if you're building on Wheezy onward:<br />
# apt-get install libc6-dev-i386<br />
<br />
One useful shortcut can be to use your distributions package manager to install all the prerequisite packages is to install those packages which are noted as being required to build the distribution's own Xen packages. e.g. under Debian or a Debian derived distribution:<br />
# apt-get build-dep xen<br />
<br />
However you need to be mindful of new prerequisites added between whatever version of Xen Project software is in your distribution and the version you are building when using this trick.<br />
<br />
==== Build Dependencies - OpenSUSE ====<br />
<br />
If you're now on the latest OpenSUSE you'll note its now a<br />
rolling distribution base. The default instructions do not actually encourage you to<br />
install the source repositories, and even if you did<br />
install them the instructions disable them by default, so<br />
be sure to install them and enable them otherwise<br />
the command zypper source-install -d won't work.<br />
To enable the required repository if you already had it<br />
installed:<br />
<br />
# zypper mr -e repo-src-oss <br />
<br />
Now get the build dependencies for Xen<br />
<br />
# zypper source-install -d xen<br />
<br />
Here's a list of things not currentloy picked up by the build dependencies which have been found to be needed:<br />
<br />
# zypper install systemd-devel gettext-tools\<br />
ocaml ocaml-compiler-libs ocaml-runtime \<br />
ocaml-ocamldoc ocaml-findlib glibc-devel-32bit make patch<br />
<br />
While at it also get the build dependencies for Linux:<br />
<br />
# zypper source-install -d kernel-desktop<br />
<br />
==== Build Dependencies - Fedora ====<br />
<br />
These instructions are kept separate from RHEL / Centos as Fedora is updated more frequently, so you are expected to do less work to build the latest and greatest Xen.<br />
<br />
Install known build dependencies:<br />
<br />
# yum-builddep xen<br />
<br />
Install things not picked up by the current build dependencies:<br />
<br />
# yum install glibc-devel.x86_64 systemd-devel.x86_64<br />
<br />
Get build dependencies for Linux, the kernel, while at it:<br />
<br />
# yum-builddep kernel <br />
<br />
==== Build Dependencies - RHEL / Centos ====<br />
<br />
Under RHEL, CentOS, Fedora based distributions you want to install the ''Development Tools'' package groups:<br />
# yum groupinstall "Development Tools"<br />
<br />
(On old CentOS and Fedora, a group called ''Development Libraries'' should, if available, installed too. That is not present in recent releases of the distributions any longer, though).<br />
<br />
Then install known build dependencies (confirmation needed if this works on RHEL / Centos):<br />
<br />
# yum-builddep xen<br />
<br />
You also need to install these additional rpms:<br />
<br />
# yum install transfig wget tar less texi2html libaio-devel dev86 glibc-devel e2fsprogs-devel gitk mkinitrd iasl xz-devel bzip2-devel<br />
# yum install pciutils-libs pciutils-devel SDL-devel libX11-devel gtk2-devel bridge-utils PyXML qemu-common qemu-img mercurial texinfo<br />
# yum install libidn-devel yajl yajl-devel ocaml ocaml-findlib ocaml-findlib-devel python-devel uuid-devel libuuid-devel openssl-devel<br />
# yum install python-markdown pandoc systemd-devel glibc-devel.i686<br />
<br />
If on CentOS, for some of this packages (e.g., '''dev86''' and '''pandoc'''), enabling the [http://fedoraproject.org/wiki/EPEL EPEL] [http://fedoraproject.org/wiki/EPEL additional repository] is necessary.<br />
<br />
==== Additional notes ====<br />
<br />
Having installed this you should then install each of the prerequisites listed in the ''README'' using your distribution's package management tool. In general the Xen Project code tries to only depend upon external tools and libraries which are commonly available in distributions therefore obtaining the prerequisites other than from your distribution's package management system is out of scope for this document. If you have trouble locating a particular prerequisite then please contact the [http://lists.xenproject.org/mailman/listinfo/xen-users xen-users] mailing list.<br />
<br />
===Configure===<br />
<br />
From Xen Project 4.2 onwards, the software uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen Project, as well as compile time sanity checking. To configure Xen Project, simply run the provided ''configure'' script:<br />
$ ./configure<br />
<br />
To see the various options run the configure script with ''--help'' e.g.:<br />
$ ./configure --help<br />
[...]<br />
Optional Features:<br />
--disable-option-checking ignore unrecognized --enable/--with options<br />
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)<br />
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]<br />
--enable-githttp Download GIT repositories via HTTP (default is<br />
DISABLED)<br />
<br />
This step is only required from Xen Project 4.2 onwards. Prior to Xen Project 4.2 these options could be configured by passing a variable on the ''make'' command line during build & install or by writing the variable to a file named ''.config'' at the top level of the source tree.<br />
<br />
====Use ''http://'' Rather Than ''git://'' to Clone Additional Repositories====<br />
<br />
When building the software from Mercurial, the build system will automatically clone several additional repositories from the network. Some of these repositories use the version control system which uses its own protocol on a specific port. Sometimes this causes issues due to firewalls etc blocking the git port. This can be worked around by instructing the Xen build system to clone such repositories using a less efficient HTTP based protocol:<br />
$ ./configure --enable-githttp<br />
<br />
Prior to Xen Project 4.2 this could be achieved by writing ''GIT_HTTP=y'' to your ''.config'':<br />
$ cat .config<br />
GIT_HTTP = y<br />
<br />
====Library Installation Directory====<br />
<br />
Xen Project 4.2 onwards defaults to installing libraries into /usr/lib by default and from 4.3 onwards defaults to installing to /usr/local/lib by default.<br />
<br />
Users on systems which use /usr/local/lib64 for 64-bit libraries should use the --libdir option. e.g:<br />
<br />
$ ./configure --libdir=/usr/local/lib64<br />
<br />
Failure to do this usually results in errors about libraries not found or using older versions of the libraries which will likely not work.<br />
<br />
_NB_: If you are using `--prefix=/usr` you should use `--libdir=/usr/lib64` too.<br />
<br />
====Systemd====<br />
<br />
If the target system uses [http://www.freedesktop.org/wiki/Software/systemd/ systemd], do not forget to enable it:<br />
<br />
$ ./configure --enable-systemd<br />
<br />
====Python Prefix and Module Layout====<br />
<br />
On some distros (e.g. Debian and Ubuntu) Xen Project may install the python parts of the code into the wrong place (See [http://bugs.debian.org/693721 Debian bug #693721]). Therefore it is necessary to set ''PYTHON_PREFIX_ARG=--install-layout=deb'':<br />
$ cat .config<br />
PYTHON_PREFIX_ARG=--install-layout=deb<br />
<br />
Some versions of Ubuntu have a [https://bugs.launchpad.net/ubuntu/+bug/362570 bug] which requires instead that ''PYTHON_PREFIX_ARG'' is to set the empty string:<br />
$ cat .config<br />
PYTHON_PREFIX_ARG=<br />
<br />
As of 4.2 this option is not yet supported by the ''configure'' script and therefore should still be set via ''.config'' or on the ''make'' command line.<br />
<br />
The most common symptom of this issue is ''pygrub'' failing to work, with output similar to:<br />
<br />
Traceback (most recent call last):<br />
File "/usr/lib/xen/bin/pygrub", line 20, in <module><br />
import xen.lowlevel.xc<br />
ImportError: No module named xen.lowlevel.xc<br />
<br />
===Build & Install===<br />
<br />
{{Warning|Xen Project downloads various components at build time. This means that building Xen Project currently requires an active connection to the Internet}}<br />
<br />
To build all components (hypervisor, tools, docs, stubdomains, etc) you can use the ''dist'' target.<br />
$ make dist<br />
<br />
If you wish to just (re)build a single component you can use the appropriate ''dist-COMPONENT'' target:<br />
$ make dist-xen<br />
$ make dist-tools<br />
$ make dist-docs<br />
$ ... etc ...<br />
<br />
If you want to rebuild a tree as if from a fresh check then you can use the ''world'' target. This is effectively the same as ''clean'' and the ''dist''<br />
$ make world<br />
<br />
All of the above targets will build and install the appropriate component into the ''dist'' subdirectory but not actually install onto the system.<br />
<br />
To install onto the local machine simply call the ''install'' target (as root):<br />
# make install<br />
<br />
As with ''dist'' you can also install individual components using the appropriate ''install-COMPONENT'' target:<br />
# make install-xen<br />
# make install-tools<br />
# make install-docs<br />
# ... etc ...<br />
<br />
If you want to install onto a remote machine then you can simply copy the ''dist'' directory over and '''TBD'''<br />
<br />
A better option is to make a "package-ball" -- a package which is the equivalent of a tarball with no dependency checking or set-up. There are target for either deb-based systems:<br />
# make debball<br />
or rpm-based systems:<br />
# make rpmball<br />
<br />
Packages are placed in the ''dist/'' directory.<br />
<br />
Installing the resulting package is functionally equivalent to the ''make install'' target above, but because the files are tracked by the package manager, it is easier to remove or update.<br />
<br />
After installing (either via ''make install'' or a packageballl) you rebuild your dynamic linker cache by running:<br />
# /sbin/ldconfig<br />
<br />
To get more information on the available targets use the ''help'' target:<br />
$ make help<br />
<br />
=== Linux grub2 update ===<br />
<br />
When on Linux and using grub2 after installing Xen you will also need to make sure grub2 will pick up your new shiny Xen hypervisor. Distributions differ on how to do this. This section documents how to do this for known distributions.<br />
<br />
==== update grub2 config on OpenSUSE ====<br />
<br />
# update-bootloader --refresh<br />
<br />
==== update grub2 config on Debian ====<br />
<br />
# update-grub<br />
<br />
==== update grub2 config on Fedora ====<br />
<br />
TBD<br />
<br />
==== update grub2 config on RHEL / Centos ====<br />
<br />
TBD<br />
<br />
===Troubleshooting===<br />
<br />
* If SeaBIOS fails to compile when building Xen 4.2 on a system with a non-English locale, try setting LC_ALL to en_US.UTF-8 before calling make:<br />
# export LC_ALL=en_US.UTF-8<br />
# make world<br />
<br />
===Kernels===<br />
<br />
The Linux kernel now supports different hypervisors with one kernel. There is also no requirement for a domain 0 (or guest) kernel to match your hypervisor so you are free to pick the kernel which best suits your needs (e.g. many distributions supply a kernel which is compatible with Xen Project, which is a quick and easy path). [[Dom0 Kernels for Xen]] contains some guidance on this issue.<br />
<br />
==== Compiling latest Linux kernel support ====<br />
<br />
If compiling Linux from source for either dom0 or a guest you can now enable Xen support for both through one simple kernel configuration helper, this was added as of v4.2:<br />
<br />
make xenconfig<br />
<br />
This lets you build a kernel which can support xen dom0 or xen guests on i386, x86-64 and arm64.<br />
<br />
===Post-Installation===<br />
<br />
A few system services should be manually enabled after the installation:<br />
<br />
====SystemV====<br />
<br />
Required:<br />
<br />
update-rc.d xencommons defaults 19 18<br />
<br />
Optional:<br />
<br />
update-rc.d xendomains defaults 21 20<br />
update-rc.d xen-watchdog defaults 22 23<br />
<br />
<br />
====systemd====<br />
<br />
Required:<br />
<br />
systemctl enable xen-qemu-dom0-disk-backend.service<br />
systemctl enable xen-init-dom0.service<br />
systemctl enable xenconsoled.service<br />
<br />
Optional:<br />
<br />
systemctl enable xendomains.service<br />
systemctl enable xen-watchdog.service<br />
systemctl enable xendriverdomain.service<br />
systemctl enable xenstored.service<br />
<br />
After making those changes reboot the system.<br />
<br />
==Host Configuration==<br />
<br />
Once the Xen Project code is installed there is still some host level setup required. [[:Category:Host Configuration]] covers this.<br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:Developers]] [[Category:Fundamentals]]</div>Wenzelhttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source&diff=19206Compiling Xen From Source2019-03-13T14:52:17Z<p>Wenzel: remove xencommons from systemd section as it's not a systemd service unit</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen Project software from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen Project 4.2 release, but an attempt will be made to point out differences from previous releases where relevant.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Why Build From Source?==<br />
<br />
Before embarking on the process of building Xen Project software yourself it is worth considering whether this is even necessary. There are many distributions around these days which have excellent support for Xen available right from the package manager, a partial list is available at [[Dom0 Kernels for Xen]]. Where possible it is highly recommended that users consume Xen Project via their chosen distribution wherever possible. Using the distribution packaging will give you a much more integrated solution and allow you to take advantage of all the resources provided by your distribution (e.g. documentation, support etc). You can find articles on how to install Xen Project on various distributions in [[:Category:Host Install]].<br />
<br />
The remainder of this document assumes that you have considered this and really do want to build from source.<br />
<br />
==Host (Domain 0) OS Installation==<br />
<br />
Before installing Xen Project you will first need to install your domain 0 OS, unless you have already done so. [[Host OS Install Considerations]] contains some things which you might want to consider while doing this.<br />
<br />
==Obtaining the Xen Project Source Code==<br />
<br />
The primary ways to obtain the Xen Project source code for a stable release are via the release tarballs or by cloning from the appropriate Mercurial source repository. For the development version of Xen Project (''xen-unstable'') Git is the primary source and Mercurial is the secondary source.<br />
<br />
===Release Tarballs===<br />
<br />
The latest Xen Project releases are linked to from [http://www.xen.org/products/downloads.html The Xen.org download page]<br />
<br />
===Git===<br />
<br />
The source code repositories are hosted using the Git version control system on [http://xenbits.xen.org/ xenbits].<br />
<br />
Each stable release has its own branch ''stable-X.Y'' (e.g. stable-4.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]). The code intended for the next stable point release is added to the branch ''staging-X.Y'' (e.g. staging-4.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]), and after they pass automated tests they will be pushed to ''stable-X.Y'' for the next release. The point releases are tagged in the main tree with ''RELEASE-X.Y.Z'' (e.g. RELEASE-4.2.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]). The result of automated tests are available on [http://lists.xen.org/mailman/listinfo/xen-devel xen-devel] mailing list.<br />
<br />
[[Xen Repositories|Xen Project Repositories]] contains information on the various repositories for the stable and development branches.<br />
<br />
To clone the source first install ''Git'' using your distro's package manager. Then execute the following command:<br />
$ git clone '''URL'''<br />
Where '''URL''' is the URL of the repository you wish to clone. In our case we should use:<br />
$ git clone git://xenbits.xen.org/xen.git<br />
As the default HEAD in xen.git is ''master'', your local repository will also have a branch called ''master'' pointing to the upstream branch.<br />
If you wish to use different HEAD (say, ''staging''), you can:<br />
$ cd xen; git checkout -b staging origin/staging<br />
You can also checkout any tags, branches as you wish.<br />
<br />
===Mercurial===<br />
<br />
<strong>Please note that XenProject.org has moved to using Git. The following section is deprecated. We do maintain Mercurial repositories mirroring Git ones, so we retain following section for reference.</strong><br />
<br />
Xen Project's source code repositories are hosted using the [http://mercurial.selenic.com/ Mercurial] version control system on [http://xenbits.xen.org/ xenbits].<br />
<br />
Each stable release has it's own branch ''xen-X.Y-testing.hg'' (e.g. [http://xenbits.xen.org/hg/xen-4.2-testing.hg xen-4.2-testing.hg]) where code intended for the next stable point release is added. The Xen Project development branch is known as ''xen-unstable'' and has its own repository [http://xenbits.xen.org/hg/xen-unstable.hg xen-unstable.hg].<br />
<br />
Each stable and development branch is available in two forms either tested (the main branch) or untested (the ''staging'' branch). When commits are made to a Xen Project tree they are first added to the ''staging'' branch and only propagated to the main branch after automated testing has passed. For example all commits to the Xen Project development branch will initially appear in [http://xenbits.xen.org/hg/staging/xen-unstable.hg staging/xen-unstable.hg] and then propagate to [http://xenbits.xen.org/hg/xen-unstable.hg xen-unstable.hg] after automated testing has completed. The automated test results are posted to the [http://lists.xen.org/mailman/listinfo/xen-devel xen-devel] mailing list.<br />
<br />
[[Xen Repositories|Xen Project Repositories]] contains information on the various repositories for the stable and development branches.<br />
<br />
To clone the source first install the ''mercurial'' tool using your distributions package manager. Then execute the following command:<br />
$ hg clone '''URL'''<br />
Where '''URL''' is the URL of the repository you wish to clone. e.g. to clone the latest tested ''xen-unstable'' tree:<br />
$ hg clone http://xenbits.xen.org/hg/xen-unstable.hg<br />
Or to clone the ''staging'' (e.g. not yet tested) ''xen-unstable'' tree:<br />
$ hg clone http://xenbits.xen.org/hg/staging/xen-unstable.hg<br />
You may want to get a specific changeset (revision), for example when trying to replicate someone else's build, or when dealing with other patches you have to apply afterwards. You can do this with the -r option. For example, to get changeset 25364:<br />
$ hg clone -r 25364 http://xenbits.xen.org/hg/xen-unstable.hg<br />
<br />
==Quick-Start==<br />
<br />
The ''README'' at the top level of the Xen Project source code tree contains a quick-start guide to building the software. This provides a quick overview of the process and requirements for building Xen Project software and will generally contain the most up to date information specific to the particular source tree you are looking at. After obtaining the Xen Project source this is the first document you should read.<br />
<br />
==Building from Source==<br />
<br />
This section documents all known requirements to build from source.<br />
<br />
===Updated /sbin/installkernel on Linux ===<br />
<br />
Linux distributions shipping with grub2 will need to ensure that their /sbin/installkernel script, which has to be provided by each Linux distribution, copies the the kernel configuration upon a custom kernel install time. The requirement for the config file comes from [http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub.d/20_linux_xen.in upstream grub2 /etc/grub.d/20_linux_xen] which <br />
will only add xen as an instance to your grub.cfg if and only if it finds in your config file either of:<br />
<br />
CONFIG_XEN_DOM0=y<br />
CONFIG_XEN_PRIVILEGED_GUEST=y<br />
<br />
Without this a user compiling and installing their own kernel with proper support for xen and with the xen hypervisor present will not get their respective grub2 update script to pick up the xen hypervisor. Debian testing has proper support for this, OpenSUSE required [https://github.com/openSUSE/mkinitrd/commit/56f8a20e1bf3efa9c822a724cb33f5683818b7ec this change upstream on mkinitrd], so OpenSUSE folks will want to get the latest /sbin/installkernel hosted on the [https://github.com/openSUSE/mkinitrd OpenSUSE mkinitrd repository on github].<br />
<br />
# If on OpenSUSE update your /sbin/installkernel<br />
git clone https://github.com/openSUSE/mkinitrd.git<br />
cd mkinitrd<br />
sudo cp sbin/installkernel /sbin/installkernel <br />
<br />
Fedora might need a similar update. Please edit this wiki once you confirm.<br />
<br />
===Build Dependencies===<br />
<br />
Xen Project uses several external libraries and tools. The primary list of these prerequisites is the list present in the ''README'' file.<br />
<br />
Even this list assumes some sort of basic development environment. A good starting point for this is to use your distributions ''development install'' package option.<br />
<br />
==== Build Dependencies - Debian / Ubuntu ====<br />
<br />
Under Debian / Ubuntu (and derived distributions) install the ''build-essential'' package:<br />
# apt-get install build-essential<br />
<br />
you also need to install these additional debs:<br />
# apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig tgif <br />
# apt-get install texinfo texlive-latex-base texlive-latex-recommended texlive-fonts-extra texlive-fonts-recommended pciutils-dev mercurial<br />
# apt-get install make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev patch libvncserver-dev libsdl-dev libjpeg62-dev<br />
# apt-get install iasl libbz2-dev e2fslibs-dev git-core uuid-dev ocaml ocaml-findlib libx11-dev bison flex xz-utils libyajl-dev<br />
# apt-get install gettext libpixman-1-dev libaio-dev markdown pandoc<br />
<br />
And if you're building on Wheezy onward:<br />
# apt-get install libc6-dev-i386<br />
<br />
One useful shortcut can be to use your distributions package manager to install all the prerequisite packages is to install those packages which are noted as being required to build the distribution's own Xen packages. e.g. under Debian or a Debian derived distribution:<br />
# apt-get build-dep xen<br />
<br />
However you need to be mindful of new prerequisites added between whatever version of Xen Project software is in your distribution and the version you are building when using this trick.<br />
<br />
==== Build Dependencies - OpenSUSE ====<br />
<br />
If you're now on the latest OpenSUSE you'll note its now a<br />
rolling distribution base. The default instructions do not actually encourage you to<br />
install the source repositories, and even if you did<br />
install them the instructions disable them by default, so<br />
be sure to install them and enable them otherwise<br />
the command zypper source-install -d won't work.<br />
To enable the required repository if you already had it<br />
installed:<br />
<br />
# zypper mr -e repo-src-oss <br />
<br />
Now get the build dependencies for Xen<br />
<br />
# zypper source-install -d xen<br />
<br />
Here's a list of things not currentloy picked up by the build dependencies which have been found to be needed:<br />
<br />
# zypper install systemd-devel gettext-tools\<br />
ocaml ocaml-compiler-libs ocaml-runtime \<br />
ocaml-ocamldoc ocaml-findlib glibc-devel-32bit make patch<br />
<br />
While at it also get the build dependencies for Linux:<br />
<br />
# zypper source-install -d kernel-desktop<br />
<br />
==== Build Dependencies - Fedora ====<br />
<br />
These instructions are kept separate from RHEL / Centos as Fedora is updated more frequently, so you are expected to do less work to build the latest and greatest Xen.<br />
<br />
Install known build dependencies:<br />
<br />
# yum-builddep xen<br />
<br />
Install things not picked up by the current build dependencies:<br />
<br />
# yum install glibc-devel.x86_64 systemd-devel.x86_64<br />
<br />
Get build dependencies for Linux, the kernel, while at it:<br />
<br />
# yum-builddep kernel <br />
<br />
==== Build Dependencies - RHEL / Centos ====<br />
<br />
Under RHEL, CentOS, Fedora based distributions you want to install the ''Development Tools'' package groups:<br />
# yum groupinstall "Development Tools"<br />
<br />
(On old CentOS and Fedora, a group called ''Development Libraries'' should, if available, installed too. That is not present in recent releases of the distributions any longer, though).<br />
<br />
Then install known build dependencies (confirmation needed if this works on RHEL / Centos):<br />
<br />
# yum-builddep xen<br />
<br />
You also need to install these additional rpms:<br />
<br />
# yum install transfig wget tar less texi2html libaio-devel dev86 glibc-devel e2fsprogs-devel gitk mkinitrd iasl xz-devel bzip2-devel<br />
# yum install pciutils-libs pciutils-devel SDL-devel libX11-devel gtk2-devel bridge-utils PyXML qemu-common qemu-img mercurial texinfo<br />
# yum install libidn-devel yajl yajl-devel ocaml ocaml-findlib ocaml-findlib-devel python-devel uuid-devel libuuid-devel openssl-devel<br />
# yum install python-markdown pandoc systemd-devel glibc-devel.i686<br />
<br />
If on CentOS, for some of this packages (e.g., '''dev86''' and '''pandoc'''), enabling the [http://fedoraproject.org/wiki/EPEL EPEL] [http://fedoraproject.org/wiki/EPEL additional repository] is necessary.<br />
<br />
==== Additional notes ====<br />
<br />
Having installed this you should then install each of the prerequisites listed in the ''README'' using your distribution's package management tool. In general the Xen Project code tries to only depend upon external tools and libraries which are commonly available in distributions therefore obtaining the prerequisites other than from your distribution's package management system is out of scope for this document. If you have trouble locating a particular prerequisite then please contact the [http://lists.xenproject.org/mailman/listinfo/xen-users xen-users] mailing list.<br />
<br />
===Configure===<br />
<br />
From Xen Project 4.2 onwards, the software uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen Project, as well as compile time sanity checking. To configure Xen Project, simply run the provided ''configure'' script:<br />
$ ./configure<br />
<br />
To see the various options run the configure script with ''--help'' e.g.:<br />
$ ./configure --help<br />
[...]<br />
Optional Features:<br />
--disable-option-checking ignore unrecognized --enable/--with options<br />
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)<br />
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]<br />
--enable-githttp Download GIT repositories via HTTP (default is<br />
DISABLED)<br />
<br />
This step is only required from Xen Project 4.2 onwards. Prior to Xen Project 4.2 these options could be configured by passing a variable on the ''make'' command line during build & install or by writing the variable to a file named ''.config'' at the top level of the source tree.<br />
<br />
====Use ''http://'' Rather Than ''git://'' to Clone Additional Repositories====<br />
<br />
When building the software from Mercurial, the build system will automatically clone several additional repositories from the network. Some of these repositories use the version control system which uses its own protocol on a specific port. Sometimes this causes issues due to firewalls etc blocking the git port. This can be worked around by instructing the Xen build system to clone such repositories using a less efficient HTTP based protocol:<br />
$ ./configure --enable-githttp<br />
<br />
Prior to Xen Project 4.2 this could be achieved by writing ''GIT_HTTP=y'' to your ''.config'':<br />
$ cat .config<br />
GIT_HTTP = y<br />
<br />
====Library Installation Directory====<br />
<br />
Xen Project 4.2 onwards defaults to installing libraries into /usr/lib by default and from 4.3 onwards defaults to installing to /usr/local/lib by default.<br />
<br />
Users on systems which use /usr/local/lib64 for 64-bit libraries should use the --libdir option. e.g:<br />
<br />
$ ./configure --libdir=/usr/local/lib64<br />
<br />
Failure to do this usually results in errors about libraries not found or using older versions of the libraries which will likely not work.<br />
<br />
_NB_: If you are using `--prefix=/usr` you should use `--libdir=/usr/lib64` too.<br />
<br />
====Systemd====<br />
<br />
If the target system uses [http://www.freedesktop.org/wiki/Software/systemd/ systemd], do not forget to enable it:<br />
<br />
$ ./configure --enable-systemd<br />
<br />
====Python Prefix and Module Layout====<br />
<br />
On some distros (e.g. Debian and Ubuntu) Xen Project may install the python parts of the code into the wrong place (See [http://bugs.debian.org/693721 Debian bug #693721]). Therefore it is necessary to set ''PYTHON_PREFIX_ARG=--install-layout=deb'':<br />
$ cat .config<br />
PYTHON_PREFIX_ARG=--install-layout=deb<br />
<br />
Some versions of Ubuntu have a [https://bugs.launchpad.net/ubuntu/+bug/362570 bug] which requires instead that ''PYTHON_PREFIX_ARG'' is to set the empty string:<br />
$ cat .config<br />
PYTHON_PREFIX_ARG=<br />
<br />
As of 4.2 this option is not yet supported by the ''configure'' script and therefore should still be set via ''.config'' or on the ''make'' command line.<br />
<br />
The most common symptom of this issue is ''pygrub'' failing to work, with output similar to:<br />
<br />
Traceback (most recent call last):<br />
File "/usr/lib/xen/bin/pygrub", line 20, in <module><br />
import xen.lowlevel.xc<br />
ImportError: No module named xen.lowlevel.xc<br />
<br />
===Build & Install===<br />
<br />
{{Warning|Xen Project downloads various components at build time. This means that building Xen Project currently requires an active connection to the Internet}}<br />
<br />
To build all components (hypervisor, tools, docs, stubdomains, etc) you can use the ''dist'' target.<br />
$ make dist<br />
<br />
If you wish to just (re)build a single component you can use the appropriate ''dist-COMPONENT'' target:<br />
$ make dist-xen<br />
$ make dist-tools<br />
$ make dist-docs<br />
$ ... etc ...<br />
<br />
If you want to rebuild a tree as if from a fresh check then you can use the ''world'' target. This is effectively the same as ''clean'' and the ''dist''<br />
$ make world<br />
<br />
All of the above targets will build and install the appropriate component into the ''dist'' subdirectory but not actually install onto the system.<br />
<br />
To install onto the local machine simply call the ''install'' target (as root):<br />
# make install<br />
<br />
As with ''dist'' you can also install individual components using the appropriate ''install-COMPONENT'' target:<br />
# make install-xen<br />
# make install-tools<br />
# make install-docs<br />
# ... etc ...<br />
<br />
If you want to install onto a remote machine then you can simply copy the ''dist'' directory over and '''TBD'''<br />
<br />
A better option is to make a "package-ball" -- a package which is the equivalent of a tarball with no dependency checking or set-up. There are target for either deb-based systems:<br />
# make debball<br />
or rpm-based systems:<br />
# make rpmball<br />
<br />
Packages are placed in the ''dist/'' directory.<br />
<br />
Installing the resulting package is functionally equivalent to the ''make install'' target above, but because the files are tracked by the package manager, it is easier to remove or update.<br />
<br />
After installing (either via ''make install'' or a packageballl) you rebuild your dynamic linker cache by running:<br />
# /sbin/ldconfig<br />
<br />
To get more information on the available targets use the ''help'' target:<br />
$ make help<br />
<br />
=== Linux grub2 update ===<br />
<br />
When on Linux and using grub2 after installing Xen you will also need to make sure grub2 will pick up your new shiny Xen hypervisor. Distributions differ on how to do this. This section documents how to do this for known distributions.<br />
<br />
==== update grub2 config on OpenSUSE ====<br />
<br />
# update-bootloader --refresh<br />
<br />
==== update grub2 config on Debian ====<br />
<br />
# update-grub<br />
<br />
==== update grub2 config on Fedora ====<br />
<br />
TBD<br />
<br />
==== update grub2 config on RHEL / Centos ====<br />
<br />
TBD<br />
<br />
===Troubleshooting===<br />
<br />
* If SeaBIOS fails to compile when building Xen 4.2 on a system with a non-English locale, try setting LC_ALL to en_US.UTF-8 before calling make:<br />
# export LC_ALL=en_US.UTF-8<br />
# make world<br />
<br />
===Kernels===<br />
<br />
The Linux kernel now supports different hypervisors with one kernel. There is also no requirement for a domain 0 (or guest) kernel to match your hypervisor so you are free to pick the kernel which best suits your needs (e.g. many distributions supply a kernel which is compatible with Xen Project, which is a quick and easy path). [[Dom0 Kernels for Xen]] contains some guidance on this issue.<br />
<br />
==== Compiling latest Linux kernel support ====<br />
<br />
If compiling Linux from source for either dom0 or a guest you can now enable Xen support for both through one simple kernel configuration helper, this was added as of v4.2:<br />
<br />
make xenconfig<br />
<br />
This lets you build a kernel which can support xen dom0 or xen guests on i386, x86-64 and arm64.<br />
<br />
===Post-Installation===<br />
<br />
A few system services should be manually enabled after the installation:<br />
<br />
====SystemV====<br />
<br />
Required:<br />
<br />
update-rc.d xencommons defaults 19 18<br />
<br />
Optional:<br />
<br />
update-rc.d xendomains defaults 21 20<br />
update-rc.d xen-watchdog defaults 22 23<br />
<br />
<br />
====systemd====<br />
<br />
Required:<br />
<br />
systemctl enable xen-qemu-dom0-disk-backend.service<br />
systemctl enable xen-init-dom0.service<br />
systemctl enable xenconsoled.service<br />
<br />
Optional:<br />
<br />
systemctl enable xendomains.service<br />
systemctl enable xen-watchdog.service<br />
<br />
After making those changes reboot the system.<br />
<br />
==Host Configuration==<br />
<br />
Once the Xen Project code is installed there is still some host level setup required. [[:Category:Host Configuration]] covers this.<br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:Developers]] [[Category:Fundamentals]]</div>Wenzelhttps://wiki.xenproject.org/index.php?title=Compiling_Xen_From_Source&diff=19205Compiling Xen From Source2019-03-13T13:17:41Z<p>Wenzel: add dedicated section for systemd service in Post-Installation</p>
<hr />
<div>==Introduction==<br />
<br />
The purpose of this document is to guide users through the process of installing Xen Project software from source (either from the tarball releases or from a source code repository).<br />
<br />
This document was written targeting the Xen Project 4.2 release, but an attempt will be made to point out differences from previous releases where relevant.<br />
<br />
An assumption is made of some familiarity with the general concept of building software and with using your distributions package manager to install relevant build tools etc.<br />
<br />
==Why Build From Source?==<br />
<br />
Before embarking on the process of building Xen Project software yourself it is worth considering whether this is even necessary. There are many distributions around these days which have excellent support for Xen available right from the package manager, a partial list is available at [[Dom0 Kernels for Xen]]. Where possible it is highly recommended that users consume Xen Project via their chosen distribution wherever possible. Using the distribution packaging will give you a much more integrated solution and allow you to take advantage of all the resources provided by your distribution (e.g. documentation, support etc). You can find articles on how to install Xen Project on various distributions in [[:Category:Host Install]].<br />
<br />
The remainder of this document assumes that you have considered this and really do want to build from source.<br />
<br />
==Host (Domain 0) OS Installation==<br />
<br />
Before installing Xen Project you will first need to install your domain 0 OS, unless you have already done so. [[Host OS Install Considerations]] contains some things which you might want to consider while doing this.<br />
<br />
==Obtaining the Xen Project Source Code==<br />
<br />
The primary ways to obtain the Xen Project source code for a stable release are via the release tarballs or by cloning from the appropriate Mercurial source repository. For the development version of Xen Project (''xen-unstable'') Git is the primary source and Mercurial is the secondary source.<br />
<br />
===Release Tarballs===<br />
<br />
The latest Xen Project releases are linked to from [http://www.xen.org/products/downloads.html The Xen.org download page]<br />
<br />
===Git===<br />
<br />
The source code repositories are hosted using the Git version control system on [http://xenbits.xen.org/ xenbits].<br />
<br />
Each stable release has its own branch ''stable-X.Y'' (e.g. stable-4.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]). The code intended for the next stable point release is added to the branch ''staging-X.Y'' (e.g. staging-4.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]), and after they pass automated tests they will be pushed to ''stable-X.Y'' for the next release. The point releases are tagged in the main tree with ''RELEASE-X.Y.Z'' (e.g. RELEASE-4.2.2 on [http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Xen.git summary page]). The result of automated tests are available on [http://lists.xen.org/mailman/listinfo/xen-devel xen-devel] mailing list.<br />
<br />
[[Xen Repositories|Xen Project Repositories]] contains information on the various repositories for the stable and development branches.<br />
<br />
To clone the source first install ''Git'' using your distro's package manager. Then execute the following command:<br />
$ git clone '''URL'''<br />
Where '''URL''' is the URL of the repository you wish to clone. In our case we should use:<br />
$ git clone git://xenbits.xen.org/xen.git<br />
As the default HEAD in xen.git is ''master'', your local repository will also have a branch called ''master'' pointing to the upstream branch.<br />
If you wish to use different HEAD (say, ''staging''), you can:<br />
$ cd xen; git checkout -b staging origin/staging<br />
You can also checkout any tags, branches as you wish.<br />
<br />
===Mercurial===<br />
<br />
<strong>Please note that XenProject.org has moved to using Git. The following section is deprecated. We do maintain Mercurial repositories mirroring Git ones, so we retain following section for reference.</strong><br />
<br />
Xen Project's source code repositories are hosted using the [http://mercurial.selenic.com/ Mercurial] version control system on [http://xenbits.xen.org/ xenbits].<br />
<br />
Each stable release has it's own branch ''xen-X.Y-testing.hg'' (e.g. [http://xenbits.xen.org/hg/xen-4.2-testing.hg xen-4.2-testing.hg]) where code intended for the next stable point release is added. The Xen Project development branch is known as ''xen-unstable'' and has its own repository [http://xenbits.xen.org/hg/xen-unstable.hg xen-unstable.hg].<br />
<br />
Each stable and development branch is available in two forms either tested (the main branch) or untested (the ''staging'' branch). When commits are made to a Xen Project tree they are first added to the ''staging'' branch and only propagated to the main branch after automated testing has passed. For example all commits to the Xen Project development branch will initially appear in [http://xenbits.xen.org/hg/staging/xen-unstable.hg staging/xen-unstable.hg] and then propagate to [http://xenbits.xen.org/hg/xen-unstable.hg xen-unstable.hg] after automated testing has completed. The automated test results are posted to the [http://lists.xen.org/mailman/listinfo/xen-devel xen-devel] mailing list.<br />
<br />
[[Xen Repositories|Xen Project Repositories]] contains information on the various repositories for the stable and development branches.<br />
<br />
To clone the source first install the ''mercurial'' tool using your distributions package manager. Then execute the following command:<br />
$ hg clone '''URL'''<br />
Where '''URL''' is the URL of the repository you wish to clone. e.g. to clone the latest tested ''xen-unstable'' tree:<br />
$ hg clone http://xenbits.xen.org/hg/xen-unstable.hg<br />
Or to clone the ''staging'' (e.g. not yet tested) ''xen-unstable'' tree:<br />
$ hg clone http://xenbits.xen.org/hg/staging/xen-unstable.hg<br />
You may want to get a specific changeset (revision), for example when trying to replicate someone else's build, or when dealing with other patches you have to apply afterwards. You can do this with the -r option. For example, to get changeset 25364:<br />
$ hg clone -r 25364 http://xenbits.xen.org/hg/xen-unstable.hg<br />
<br />
==Quick-Start==<br />
<br />
The ''README'' at the top level of the Xen Project source code tree contains a quick-start guide to building the software. This provides a quick overview of the process and requirements for building Xen Project software and will generally contain the most up to date information specific to the particular source tree you are looking at. After obtaining the Xen Project source this is the first document you should read.<br />
<br />
==Building from Source==<br />
<br />
This section documents all known requirements to build from source.<br />
<br />
===Updated /sbin/installkernel on Linux ===<br />
<br />
Linux distributions shipping with grub2 will need to ensure that their /sbin/installkernel script, which has to be provided by each Linux distribution, copies the the kernel configuration upon a custom kernel install time. The requirement for the config file comes from [http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub.d/20_linux_xen.in upstream grub2 /etc/grub.d/20_linux_xen] which <br />
will only add xen as an instance to your grub.cfg if and only if it finds in your config file either of:<br />
<br />
CONFIG_XEN_DOM0=y<br />
CONFIG_XEN_PRIVILEGED_GUEST=y<br />
<br />
Without this a user compiling and installing their own kernel with proper support for xen and with the xen hypervisor present will not get their respective grub2 update script to pick up the xen hypervisor. Debian testing has proper support for this, OpenSUSE required [https://github.com/openSUSE/mkinitrd/commit/56f8a20e1bf3efa9c822a724cb33f5683818b7ec this change upstream on mkinitrd], so OpenSUSE folks will want to get the latest /sbin/installkernel hosted on the [https://github.com/openSUSE/mkinitrd OpenSUSE mkinitrd repository on github].<br />
<br />
# If on OpenSUSE update your /sbin/installkernel<br />
git clone https://github.com/openSUSE/mkinitrd.git<br />
cd mkinitrd<br />
sudo cp sbin/installkernel /sbin/installkernel <br />
<br />
Fedora might need a similar update. Please edit this wiki once you confirm.<br />
<br />
===Build Dependencies===<br />
<br />
Xen Project uses several external libraries and tools. The primary list of these prerequisites is the list present in the ''README'' file.<br />
<br />
Even this list assumes some sort of basic development environment. A good starting point for this is to use your distributions ''development install'' package option.<br />
<br />
==== Build Dependencies - Debian / Ubuntu ====<br />
<br />
Under Debian / Ubuntu (and derived distributions) install the ''build-essential'' package:<br />
# apt-get install build-essential<br />
<br />
you also need to install these additional debs:<br />
# apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig tgif <br />
# apt-get install texinfo texlive-latex-base texlive-latex-recommended texlive-fonts-extra texlive-fonts-recommended pciutils-dev mercurial<br />
# apt-get install make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev patch libvncserver-dev libsdl-dev libjpeg62-dev<br />
# apt-get install iasl libbz2-dev e2fslibs-dev git-core uuid-dev ocaml ocaml-findlib libx11-dev bison flex xz-utils libyajl-dev<br />
# apt-get install gettext libpixman-1-dev libaio-dev markdown pandoc<br />
<br />
And if you're building on Wheezy onward:<br />
# apt-get install libc6-dev-i386<br />
<br />
One useful shortcut can be to use your distributions package manager to install all the prerequisite packages is to install those packages which are noted as being required to build the distribution's own Xen packages. e.g. under Debian or a Debian derived distribution:<br />
# apt-get build-dep xen<br />
<br />
However you need to be mindful of new prerequisites added between whatever version of Xen Project software is in your distribution and the version you are building when using this trick.<br />
<br />
==== Build Dependencies - OpenSUSE ====<br />
<br />
If you're now on the latest OpenSUSE you'll note its now a<br />
rolling distribution base. The default instructions do not actually encourage you to<br />
install the source repositories, and even if you did<br />
install them the instructions disable them by default, so<br />
be sure to install them and enable them otherwise<br />
the command zypper source-install -d won't work.<br />
To enable the required repository if you already had it<br />
installed:<br />
<br />
# zypper mr -e repo-src-oss <br />
<br />
Now get the build dependencies for Xen<br />
<br />
# zypper source-install -d xen<br />
<br />
Here's a list of things not currentloy picked up by the build dependencies which have been found to be needed:<br />
<br />
# zypper install systemd-devel gettext-tools\<br />
ocaml ocaml-compiler-libs ocaml-runtime \<br />
ocaml-ocamldoc ocaml-findlib glibc-devel-32bit make patch<br />
<br />
While at it also get the build dependencies for Linux:<br />
<br />
# zypper source-install -d kernel-desktop<br />
<br />
==== Build Dependencies - Fedora ====<br />
<br />
These instructions are kept separate from RHEL / Centos as Fedora is updated more frequently, so you are expected to do less work to build the latest and greatest Xen.<br />
<br />
Install known build dependencies:<br />
<br />
# yum-builddep xen<br />
<br />
Install things not picked up by the current build dependencies:<br />
<br />
# yum install glibc-devel.x86_64 systemd-devel.x86_64<br />
<br />
Get build dependencies for Linux, the kernel, while at it:<br />
<br />
# yum-builddep kernel <br />
<br />
==== Build Dependencies - RHEL / Centos ====<br />
<br />
Under RHEL, CentOS, Fedora based distributions you want to install the ''Development Tools'' package groups:<br />
# yum groupinstall "Development Tools"<br />
<br />
(On old CentOS and Fedora, a group called ''Development Libraries'' should, if available, installed too. That is not present in recent releases of the distributions any longer, though).<br />
<br />
Then install known build dependencies (confirmation needed if this works on RHEL / Centos):<br />
<br />
# yum-builddep xen<br />
<br />
You also need to install these additional rpms:<br />
<br />
# yum install transfig wget tar less texi2html libaio-devel dev86 glibc-devel e2fsprogs-devel gitk mkinitrd iasl xz-devel bzip2-devel<br />
# yum install pciutils-libs pciutils-devel SDL-devel libX11-devel gtk2-devel bridge-utils PyXML qemu-common qemu-img mercurial texinfo<br />
# yum install libidn-devel yajl yajl-devel ocaml ocaml-findlib ocaml-findlib-devel python-devel uuid-devel libuuid-devel openssl-devel<br />
# yum install python-markdown pandoc systemd-devel glibc-devel.i686<br />
<br />
If on CentOS, for some of this packages (e.g., '''dev86''' and '''pandoc'''), enabling the [http://fedoraproject.org/wiki/EPEL EPEL] [http://fedoraproject.org/wiki/EPEL additional repository] is necessary.<br />
<br />
==== Additional notes ====<br />
<br />
Having installed this you should then install each of the prerequisites listed in the ''README'' using your distribution's package management tool. In general the Xen Project code tries to only depend upon external tools and libraries which are commonly available in distributions therefore obtaining the prerequisites other than from your distribution's package management system is out of scope for this document. If you have trouble locating a particular prerequisite then please contact the [http://lists.xenproject.org/mailman/listinfo/xen-users xen-users] mailing list.<br />
<br />
===Configure===<br />
<br />
From Xen Project 4.2 onwards, the software uses the commonly used ''autoconf'' tool to provide compile time configurability of the toolstack. This allows some control of what features are built into Xen Project, as well as compile time sanity checking. To configure Xen Project, simply run the provided ''configure'' script:<br />
$ ./configure<br />
<br />
To see the various options run the configure script with ''--help'' e.g.:<br />
$ ./configure --help<br />
[...]<br />
Optional Features:<br />
--disable-option-checking ignore unrecognized --enable/--with options<br />
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)<br />
--enable-FEATURE[=ARG] include FEATURE [ARG=yes]<br />
--enable-githttp Download GIT repositories via HTTP (default is<br />
DISABLED)<br />
<br />
This step is only required from Xen Project 4.2 onwards. Prior to Xen Project 4.2 these options could be configured by passing a variable on the ''make'' command line during build & install or by writing the variable to a file named ''.config'' at the top level of the source tree.<br />
<br />
====Use ''http://'' Rather Than ''git://'' to Clone Additional Repositories====<br />
<br />
When building the software from Mercurial, the build system will automatically clone several additional repositories from the network. Some of these repositories use the version control system which uses its own protocol on a specific port. Sometimes this causes issues due to firewalls etc blocking the git port. This can be worked around by instructing the Xen build system to clone such repositories using a less efficient HTTP based protocol:<br />
$ ./configure --enable-githttp<br />
<br />
Prior to Xen Project 4.2 this could be achieved by writing ''GIT_HTTP=y'' to your ''.config'':<br />
$ cat .config<br />
GIT_HTTP = y<br />
<br />
====Library Installation Directory====<br />
<br />
Xen Project 4.2 onwards defaults to installing libraries into /usr/lib by default and from 4.3 onwards defaults to installing to /usr/local/lib by default.<br />
<br />
Users on systems which use /usr/local/lib64 for 64-bit libraries should use the --libdir option. e.g:<br />
<br />
$ ./configure --libdir=/usr/local/lib64<br />
<br />
Failure to do this usually results in errors about libraries not found or using older versions of the libraries which will likely not work.<br />
<br />
_NB_: If you are using `--prefix=/usr` you should use `--libdir=/usr/lib64` too.<br />
<br />
====Systemd====<br />
<br />
If the target system uses [http://www.freedesktop.org/wiki/Software/systemd/ systemd], do not forget to enable it:<br />
<br />
$ ./configure --enable-systemd<br />
<br />
====Python Prefix and Module Layout====<br />
<br />
On some distros (e.g. Debian and Ubuntu) Xen Project may install the python parts of the code into the wrong place (See [http://bugs.debian.org/693721 Debian bug #693721]). Therefore it is necessary to set ''PYTHON_PREFIX_ARG=--install-layout=deb'':<br />
$ cat .config<br />
PYTHON_PREFIX_ARG=--install-layout=deb<br />
<br />
Some versions of Ubuntu have a [https://bugs.launchpad.net/ubuntu/+bug/362570 bug] which requires instead that ''PYTHON_PREFIX_ARG'' is to set the empty string:<br />
$ cat .config<br />
PYTHON_PREFIX_ARG=<br />
<br />
As of 4.2 this option is not yet supported by the ''configure'' script and therefore should still be set via ''.config'' or on the ''make'' command line.<br />
<br />
The most common symptom of this issue is ''pygrub'' failing to work, with output similar to:<br />
<br />
Traceback (most recent call last):<br />
File "/usr/lib/xen/bin/pygrub", line 20, in <module><br />
import xen.lowlevel.xc<br />
ImportError: No module named xen.lowlevel.xc<br />
<br />
===Build & Install===<br />
<br />
{{Warning|Xen Project downloads various components at build time. This means that building Xen Project currently requires an active connection to the Internet}}<br />
<br />
To build all components (hypervisor, tools, docs, stubdomains, etc) you can use the ''dist'' target.<br />
$ make dist<br />
<br />
If you wish to just (re)build a single component you can use the appropriate ''dist-COMPONENT'' target:<br />
$ make dist-xen<br />
$ make dist-tools<br />
$ make dist-docs<br />
$ ... etc ...<br />
<br />
If you want to rebuild a tree as if from a fresh check then you can use the ''world'' target. This is effectively the same as ''clean'' and the ''dist''<br />
$ make world<br />
<br />
All of the above targets will build and install the appropriate component into the ''dist'' subdirectory but not actually install onto the system.<br />
<br />
To install onto the local machine simply call the ''install'' target (as root):<br />
# make install<br />
<br />
As with ''dist'' you can also install individual components using the appropriate ''install-COMPONENT'' target:<br />
# make install-xen<br />
# make install-tools<br />
# make install-docs<br />
# ... etc ...<br />
<br />
If you want to install onto a remote machine then you can simply copy the ''dist'' directory over and '''TBD'''<br />
<br />
A better option is to make a "package-ball" -- a package which is the equivalent of a tarball with no dependency checking or set-up. There are target for either deb-based systems:<br />
# make debball<br />
or rpm-based systems:<br />
# make rpmball<br />
<br />
Packages are placed in the ''dist/'' directory.<br />
<br />
Installing the resulting package is functionally equivalent to the ''make install'' target above, but because the files are tracked by the package manager, it is easier to remove or update.<br />
<br />
After installing (either via ''make install'' or a packageballl) you rebuild your dynamic linker cache by running:<br />
# /sbin/ldconfig<br />
<br />
To get more information on the available targets use the ''help'' target:<br />
$ make help<br />
<br />
=== Linux grub2 update ===<br />
<br />
When on Linux and using grub2 after installing Xen you will also need to make sure grub2 will pick up your new shiny Xen hypervisor. Distributions differ on how to do this. This section documents how to do this for known distributions.<br />
<br />
==== update grub2 config on OpenSUSE ====<br />
<br />
# update-bootloader --refresh<br />
<br />
==== update grub2 config on Debian ====<br />
<br />
# update-grub<br />
<br />
==== update grub2 config on Fedora ====<br />
<br />
TBD<br />
<br />
==== update grub2 config on RHEL / Centos ====<br />
<br />
TBD<br />
<br />
===Troubleshooting===<br />
<br />
* If SeaBIOS fails to compile when building Xen 4.2 on a system with a non-English locale, try setting LC_ALL to en_US.UTF-8 before calling make:<br />
# export LC_ALL=en_US.UTF-8<br />
# make world<br />
<br />
===Kernels===<br />
<br />
The Linux kernel now supports different hypervisors with one kernel. There is also no requirement for a domain 0 (or guest) kernel to match your hypervisor so you are free to pick the kernel which best suits your needs (e.g. many distributions supply a kernel which is compatible with Xen Project, which is a quick and easy path). [[Dom0 Kernels for Xen]] contains some guidance on this issue.<br />
<br />
==== Compiling latest Linux kernel support ====<br />
<br />
If compiling Linux from source for either dom0 or a guest you can now enable Xen support for both through one simple kernel configuration helper, this was added as of v4.2:<br />
<br />
make xenconfig<br />
<br />
This lets you build a kernel which can support xen dom0 or xen guests on i386, x86-64 and arm64.<br />
<br />
===Post-Installation===<br />
<br />
A few system services should be manually enabled after the installation:<br />
<br />
====SystemV====<br />
<br />
Required:<br />
<br />
update-rc.d xencommons defaults 19 18<br />
<br />
Optional:<br />
<br />
update-rc.d xendomains defaults 21 20<br />
update-rc.d xen-watchdog defaults 22 23<br />
<br />
<br />
====systemd====<br />
<br />
Required:<br />
<br />
systemctl enable xencommons.service<br />
systemctl enable xenconsoled.service<br />
systemctl enable xen-qemu-dom0-disk-backend.service<br />
systemctl enable xen-init-dom0.service<br />
<br />
Optional:<br />
<br />
systemctl enable xendomains.service<br />
systemctl enable xen-watchdog.service<br />
<br />
After making those changes reboot the system.<br />
<br />
==Host Configuration==<br />
<br />
Once the Xen Project code is installed there is still some host level setup required. [[:Category:Host Configuration]] covers this.<br />
<br />
[[Category:Users]] [[Category:Host Install]] [[Category:Developers]] [[Category:Fundamentals]]</div>Wenzelhttps://wiki.xenproject.org/index.php?title=QEMU_Upstream&diff=19137QEMU Upstream2019-02-14T10:09:07Z<p>Wenzel: Fix typo</p>
<hr />
<div>= History =<br />
<br />
Historically Xen contained a fork of qemu with Xen support added, known as 'qemu-xen-traditional' in the xl toolstack. However since Qemu 1.0 support for Xen has been part of the mainline Qemu and can be used with Xen from 4.2 onwards. The xl toolstack describes this version as 'qemu-xen', and this became the default from Xen 4.3 onward.<br />
<br />
The 'qemu-xen-traditional' fork remains available to support guest OSs that were installed using it. After a Dom0 upgrade to a newer Xen version the new 'qemu-xen' device model is recognized as a significant hardware change. Some guest operating systems, especially non-free systems that rely on licensing bound to a specific hardware, do not behave nicely when hardware is changed under their feet.<br />
<br />
= Xen Qemu Trees =<br />
<br />
The '''qemu-xen''' code is maintained upstream in the [http://wiki.qemu.org/Main_Page qemu.org] git trees. In addition the Xen project also maintains its own stable branch of qemu, based on the upstream stable branches with a small number of additional fixes for Xen.<br />
These can be found on [http://xenbits.xen.org xenbits] in [https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=summary qemu-xen.git]<br />
with a branch for each release of Xen named 'stable-VERSION',<br />
e.g. [https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=shortlog;h=refs/heads/stable-4.10 stable-4.10].<br />
<br />
The '''qemu-xen-traditional''' fork is maintained on [http://xenbits.xen.org xenbits]<br />
in [https://xenbits.xen.org/gitweb/?p=qemu-xen-traditional.git;a=summary qemu-xen-traditional.git].<br />
There are branches for each release of Xen named 'stable-VERSION' e.g. [https://xenbits.xen.org/gitweb/?p=qemu-xen-traditional.git;a=shortlog;h=refs/heads/stable-4.10 stable-4.10].<br />
<br />
By default the Xen build system will clone and build both versions of QEMU from the branches on [http://xenbits.xen.org xenbits].<br />
<br />
=== Obsolete Xen Qemu Trees ===<br />
<br />
In the past, we maintained the following trees:<br />
* '''qemu-xen''': The 'qemu-xen' code is maintained upstream in the [http://wiki.qemu.org/Main_Page qemu.org] git trees. In addition the Xen project also maintains its own stable branch of qemu, based on the upstream stable branches with a small number of additional fixes for Xen. These can be found on [http://xenbits.xen.org xenbits] in '''qemu-upstream-VERSION.git''' e.g. [http://xenbits.xen.org/gitweb/?p=qemu-upstream-unstable.git;a=summary qemu-upstream-unstable.git], [http://xenbits.xen.org/gitweb/?p=qemu-upstream-4.3-testing.git;a=summary qemu-upstream-4.3-testing.git].<br />
* '''qemu-xen-traditional''': [http://xenbits.xen.org xenbits] in '''qemu-xen-VERSION.git''' e.g. [http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=summary qemu-xen-unstable.git], [http://xenbits.xen.org/gitweb/?p=qemu-xen-4.3-testing.git;a=summary qemu-xen-4.3-testing.git] etc.<br />
<br />
These trees are still around for reference, but are not in use any more.<br />
<br />
= Why is <code>qemu-system-i386</code> used even on x86_64 and even non-x86? =<br />
<br />
QEMU in a Xen system only provides device model (DM) emulation and not any CPU instruction emulation, so the nominal arch doesn't actually matter and Xen builds i386 everywhere as a basically arbitrary choice.<br />
<br />
It happens that the Xen DM part of QEMU is quite closely tied to the x86 scaffolding for various historical reasons, so we end up using <code>qemu-system-i386</code> even e.g. on ARM!<br />
<br />
There is no practical difference between <code>qemu-system-i386</code> and <code>qemu-system-x86_64</code>, they should be interchangeable. However only <code>qemu-system-i386</code> is regularly tested by Xen Project (via osstest).<br />
<br />
= Using a distribution supplied version of Qemu =<br />
<br />
By default Xen will build its own copy of the upstream qemu tree from a branch hosted on [http://xenbits.xen.org xenbits]. However it is possible to use Xen with the qemu supplied by the distribution, assuming it is new enough and is compiled with Xen support.<br />
<br />
You can configure this at build time by using:<br />
<br />
./configure --with-system-qemu=/path/some/qemu-bin/<br />
<br />
This will cause the Xen toolstack to use binary when launching qemu. If you specify the 'with-system-qemu' option but do not specify a path then the default will be to call <tt>qemu-system-i386</tt> using the system's default search path.<br />
<br />
Note that Xen does not use Qemu for processor emulation and therefore makes no distinction between <tt>qemu-system-i386</tt> and <tt>qemu-system-x86_64</tt>, both of which can be used with either 32- or 64-bit guests. By default Xen uses <code>qemu-system-i386</code>.<br />
<br />
As well as building Xen with support for the system version of Qemu it is also possible to override the binary to be used via ''device_model_override'' field in your xl vm configuration (other toolstacks may or may not expose this option). For example:<br />
<br />
device_model_override = "/usr/bin/qemu-system-x86_64"<br />
<br />
Note that it is you responsibility to ensure that 'device_model_version' is set to either 'qemu-xen-traditional' or 'qemu-xen' as appropriate when overriding the binary to use.<br />
<br />
= Xen build system integration =<br />
<br />
By default building Xen will cause a suitable version of Qemu to be downloaded and built.<br />
<br />
== When xen builds qemu ==<br />
<br />
[http://xenbits.xen.org/gitweb/?p=xen.git xen] will build qemu by default if it is supported on your target.<br />
<br />
== Where Xen builds qemu ==<br />
<br />
Qemu will build it under the <code>tools/qemu-xen-dir</code> subdirectory of your xen source tree.<br />
<br />
== How xen builds qemu ==<br />
<br />
When running ''make'' when building xen in the [http://xenbits.xen.org/gitweb/?p=xen.git xen git tree] the enabled qemu targets will be built and by default on x86 and x86_64 two targets are built:<br />
<br />
* CONFIG_QEMU_TRAD: checks out the git tree defined by CONFIG_QEMU<br />
git://xenbits.xen.org/qemu-xen-unstable.git<br />
* CONFIG_QEMU_XEN: checks out the git tree defined by QEMU_UPSTREAM_URL<br />
git://xenbits.xen.org/qemu-upstream-unstable.git<br />
<br />
== Overriding QEMU URL and revision ==<br />
<br />
If you'd like to modify the URL so that the another upstream version of qemu is used, and override the branch used you can edit your "xen/.Config.mk" file, for example:<br />
<br />
QEMU_UPSTREAM_URL = git://git.qemu.org/qemu.git<br />
QEMU_UPSTREAM_REVISION = master<br />
<br />
== Building your own qemu ==<br />
<br />
* Get Xen source from the [http://xenbits.xen.org/gitweb/?p=xen.git xen git tree]<br />
* Get QEMU upstream source from: [git://git.qemu.org/qemu.git qemu git tree]<br />
* Build Xen:<br />
<br />
make xen tools<br />
<br />
If it fail see below.<br />
=== Build QEMU upstream with Xen ===<br />
<br />
./configure --enable-xen --target-list=i386-softmmu \<br />
--extra-cflags="-I$path_to_xen_source/tools/include -I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore" \<br />
--extra-ldflags="-L$path_to_xen_source/tools/libxc -L$path_to_xen_source/tools/xenstore"<br />
make<br />
<br />
Troubleshooting compilation errors: If you get an error from configure like "ERROR: User requested feature xen ERROR: configure was not able to find it" then see this: http://xen.1045712.n5.nabble.com/Upstream-Qemu-With-Xen-configuration-problem-td4561779.html , ie. you need to point the paths for "configure" to xen source directory, not to xen dist directory.<br />
<br />
==== Other QEMU configure options ====<br />
Some features of QEMU that a Xen guest might use may not be built if a dependency isn't installed. Here is a list of <code>./configure</code> options to use:<br />
* Xen 9pfs<br />
--enable-virtfs<br />
* PVUSB<br />
--enable-libusb<br />
<br />
= Use with SeaBIOS =<br />
<br />
SeaBIOS support is now fully integrated into the Xen build system and is always used when using ''device_model_version = "qemu-xen"''.<br />
<br />
If you want to build a version of SeaBIOS other than the [http://xenbits.xen.org/gitweb/?p=seabios.git;a=shortlog;h=refs/heads/xen-unstable default] then you can override ''SEABIOS_UPSTREAM_URL'' and/or ''SEABIOS_UPSTREAM_TAG'' via ''.config''. For reference the upstream SeaBIOS repository is [[git://git.seabios.org/seabios.git]].<br />
<br />
= New features =<br />
== VirtIO ==<br />
It's the PV drivers from KVM world.<br />
To use it for network, just use 'virtio-net' as a model:<br />
<br />
vif = [ 'model=virtio-net' ]<br />
<br />
You will need those kernel modules to use a VirtIO device<br />
virtio_mmio virtio_pci virtio_net<br />
<br />
== SPICE / QXL ==<br />
SPICE is another remote-display protocol and QXL is a PV framebuffer which uses the best of the SPICE capabilities.<br />
To activate SPICE you can add this in the VM config file (this works only with xl).<br />
spice=1<br />
spicehost='0.0.0.0'<br />
spiceport=6000<br />
spicedisable_ticketing=1<br />
<br />
With xen 4.4 usb redirection, vdagent and clipboard sharing was added:<br />
<br />
- for use usb redirection add in domU's xl cfg spiceusbredirection=N where N is number of channels one for each usb device that can be redirected, max 4.<br />
<br />
- for use spice vdagent add the line below in domU's xl cfg:<br />
spicevdagent=1<br />
- for use spice clipboard sharing<br />
spice_clipboard_sharing=1<br />
<br />
QXL currently work under Xen only on windows but xl patch is available for testing.<br />
(check [[http://wiki.xen.org/wiki/SPICE_support_in_Xen SPICE page]] for more information.)<br />
<br />
= Difference with qemu-xen-traditional =<br />
== Missing feature from the good old qemu-dm ==<br />
Currently, there is few missing feature that not supported by QEMU upstream, but the work is ongoing.<br />
* '''VGA passthrough''': Sometime (all the time?), simple PCI passthrough does not works for graphics card. The few things that are done in qemu-dm are not yet upstreamed.<br />
<br />
== New feature from QEMU upstream ==<br />
There are some benefits from upstreaming the support of Xen to QEMU. <br />
We can now use:<br />
* VirtIO as an alternative to Xen PV drivers<br />
* SPICE, as a remote-display protocol instead of the old VNC.<br />
* different kind of file format for a disc.<br />
* the ability to connect several times to the VNC server.<br />
* ...</div>Wenzelhttps://wiki.xenproject.org/index.php?title=Virtual_Machine_Introspection&diff=19110Virtual Machine Introspection2019-01-31T12:58:09Z<p>Wenzel: fix typo</p>
<hr />
<div>In Xen 4.5, VM introspection using Intel EPT / AMD RVI hardware virtualization functionality was added building on Xen Project Hypervisors Memory Inspection APIs introduced in 2011. In Xen 4.6 a number of significant improvements to Xen’s Virtual Machine Introspection (VMI) subsystems make it the best hypervisor for security applications. Hardware support for VM Functions (VMFunc) available on Intel’s 4th generation Haswell CPUs and Atom Silvermont CPUs decreases overheads. Support for Virtualization Exceptions is now available on Intel’s 5th generation Broadwell CPUs and Atom Goldmont CPUs has significantly reduced latency. VMI support for ARM CPUs has also been added. Further improvements were made in Xen 4.7 and 4.8.<br />
<br />
VMI addresses a number of security issues from outside the guest OS without relying on functionality that can be rendered unreliable by advanced malware. The approach works by auditing access of sensitive memory areas using HW support in guests in an unobtrusive way (or maybe better: with minimal overhead) and allows control software running within a dedicated VM to allow or deny attempts to access sensitive memory based on policy and security heuristics. <br />
<br />
Key contributors in alphabetical order: Bitdefender, Intel, Novetta, Zentific<br />
<br />
== Chronology ==<br />
* 2009: First patches for the mem_event API<br />
* 2011: Xen 4.1: First memory introspection API upstream<br />
* 2015: Xen 4.5: VM introspection using Intel EPT / AMD RVI hardware virtualization<br />
* 2015: Xen 4.6:<br />
** mem_event becomes vm_event to support all kinds of hardware events (interrupts, registers, etc...)<br />
** x86 and ARM introspection support<br />
** hardware support for VMFUNC<br />
** altp2m<br />
<br />
== Background Information, papers, presentations ==<br />
* [https://www.linux.com/news/virtual-machine-introspection-security-innovation-new-commercial-applications Virtual Machine Introspection: A Security Innovation With New Commercial Applications (2016)]<br />
* [http://www.wesrch.com/electronics/paper-details/pdf-EL11TZ000PYAA-hypervisor-extensions-for-virtual-machine-memory-introspection Hypervisor Extensions for Virtual Machine Memory Introspection (2016)]<br />
* [http://www.sciencedirect.com/science/article/pii/S1742287616300081 TLSkex: Harnessing virtual machine introspection for decrypting TLS communication (2016)]<br />
* [https://blog.xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m/ Stealthy Monitoring with alt2pm (2016)]<br />
* [http://www.slideshare.net/tklengyel/stealthy-hypervisorbased-malware-analysis Stealthy, Hypervisor-based Malware Analysis (2016)]<br />
* [https://www.youtube.com/watch?v=k0BVFyyuvRA Virtual Machine Introspection with Xen (2015)]<br />
* [https://www.youtube.com/watch?v=nKrfsGvZgvo VM Introspection: Practical Applications (2015)]<br />
* [https://www.youtube.com/watch?v=GGjPU6jHi_w YouTube video] ([http://events.linuxfoundation.org/sites/events/files/slides/Zero-Footprint%20Guest%20Memory%20Introspection%20from%20Xen%20_%20draft11.pdf presentation]) (2014)<br />
<br />
== Related Projects ==<br />
* Malware analysis<br />
** [http://tklengyel.github.io/drakvuf/ DRAKVUF - Dynamic Malware Analysis] (contains a number of demos)<br />
* Hypervisor-level debugger<br />
** [https://github.com/Zentific/vmidbg vmidbg Enable s debuggers to remotely access and manipulate VM memory, utilizing the virtual machine introspection capabilities of LibVMI]<br />
** [https://github.com/Wenzel/r2vmi Hypervisor-Level Debugger based on Radare2/LibVMI]<br />
** [https://github.com/Wenzel/pyvmidbg pyvmidbg: LibVMI based GDB stub, a flexible hypervisor-level debugger]<br />
** [https://github.com/nccgroup/xendbg xendbg: Xen VMI Debugger: Debug Xen PV and HVM guests]<br />
* VMI libraries<br />
** [https://github.com/libvmi/libvmi LibVMI on GitHub] <br />
** [http://libvmi.com/ LibVMI Home Page]<br />
** [https://blog.xenproject.org/2015/08/04/the-bitdefender-virtual-machine-introspection-library-is-now-on-github/ The Bitdefender virtual machine introspection library is now on GitHub]<br />
<br />
== Commercial Applications (in alphabetical order) ==<br />
* AIS IntroVirt (XenServer)<br />
** [https://www.ainfosec.com/innovative-products/#introvirt IntroVirt]<br />
* BitDefender Hypervisor Introspection (for XenServer)<br />
** [http://xenserver.org/blog/entry/xenserver-dundee-released.html XenServer 7.0 with Direct Inspect API set (which essentially is VMI)]<br />
** [https://www.bitdefender.com/business/hypervisor-introspection.html Bitdefender Hypervisor Introspection] <br />
** [https://www.youtube.com/watch?v=qUsqKoGX-U0 Video: The XenServer Direct Inspect API and Bitdefender Hypervisor Introspection]<br />
** [https://www.youtube.com/watch?v=5j0_cpxra7A Video: (Bitdefender Hypervisor Introspection Demo)]<br />
<br />
* Zentific Zazen (for Xen Project and XenServer)<br />
** [https://www.zentific.com/zazen/ Zazen Product page]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]<br />
[[Category:Xen 4.8]]<br />
[[Category:Security]]</div>Wenzelhttps://wiki.xenproject.org/index.php?title=Virtual_Machine_Introspection&diff=19109Virtual Machine Introspection2019-01-31T10:24:42Z<p>Wenzel: /* Related Projects */</p>
<hr />
<div>In Xen 4.5, VM introspection using Intel EPT / AMD RVI hardware virtualization functionality was added building on Xen Project Hypervisors Memory Inspection APIs introduced in 2011. In Xen 4.6 a number of significant improvements to Xen’s Virtual Machine Introspection (VMI) subsystems make it the best hypervisor for security applications. Hardware support for VM Functions (VMFunc) available on Intel’s 4th generation Haswell CPUs and Atom Silvermont CPUs decreases overheads. Support for Virtualization Exceptions is now available on Intel’s 5th generation Broadwell CPUs and Atom Goldmont CPUs has significantly reduced latency. VMI support for ARM CPUs has also been added. Further improvements were made in Xen 4.7 and 4.8.<br />
<br />
VMI addresses a number of security issues from outside the guest OS without relying on functionality that can be rendered unreliable by advanced malware. The approach works by auditing access of sensitive memory areas using HW support in guests in an unobtrusive way (or maybe better: with minimal overhead) and allows control software running within a dedicated VM to allow or deny attempts to access sensitive memory based on policy and security heuristics. <br />
<br />
Key contributors in alphabetical order: Bitdefender, Intel, Novetta, Zentific<br />
<br />
== Chronology ==<br />
* 2009: First patches for the mem_event API<br />
* 2011: Xen 4.1: First memory introspection API upstream<br />
* 2015: Xen 4.5: VM introspection using Intel EPT / AMD RVI hardware virtualization<br />
* 2015: Xen 4.6:<br />
** mem_event becomes vm_event to support all kinds of hardware events (interrupts, registers, etc...)<br />
** x86 and ARM introspection support<br />
** hardware support or VMFUNC<br />
** altp2m<br />
<br />
<br />
== Background Information, papers, presentations ==<br />
* [https://www.linux.com/news/virtual-machine-introspection-security-innovation-new-commercial-applications Virtual Machine Introspection: A Security Innovation With New Commercial Applications (2016)]<br />
* [http://www.wesrch.com/electronics/paper-details/pdf-EL11TZ000PYAA-hypervisor-extensions-for-virtual-machine-memory-introspection Hypervisor Extensions for Virtual Machine Memory Introspection (2016)]<br />
* [http://www.sciencedirect.com/science/article/pii/S1742287616300081 TLSkex: Harnessing virtual machine introspection for decrypting TLS communication (2016)]<br />
* [https://blog.xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m/ Stealthy Monitoring with alt2pm (2016)]<br />
* [http://www.slideshare.net/tklengyel/stealthy-hypervisorbased-malware-analysis Stealthy, Hypervisor-based Malware Analysis (2016)]<br />
* [https://www.youtube.com/watch?v=k0BVFyyuvRA Virtual Machine Introspection with Xen (2015)]<br />
* [https://www.youtube.com/watch?v=nKrfsGvZgvo VM Introspection: Practical Applications (2015)]<br />
* [https://www.youtube.com/watch?v=GGjPU6jHi_w YouTube video] ([http://events.linuxfoundation.org/sites/events/files/slides/Zero-Footprint%20Guest%20Memory%20Introspection%20from%20Xen%20_%20draft11.pdf presentation]) (2014)<br />
<br />
== Related Projects ==<br />
* Malware analysis<br />
** [http://tklengyel.github.io/drakvuf/ DRAKVUF - Dynamic Malware Analysis] (contains a number of demos)<br />
* Hypervisor-level debugger<br />
** [https://github.com/Zentific/vmidbg vmidbg Enable s debuggers to remotely access and manipulate VM memory, utilizing the virtual machine introspection capabilities of LibVMI]<br />
** [https://github.com/Wenzel/r2vmi Hypervisor-Level Debugger based on Radare2/LibVMI]<br />
** [https://github.com/Wenzel/pyvmidbg pyvmidbg: LibVMI based GDB stub, a flexible hypervisor-level debugger]<br />
** [https://github.com/nccgroup/xendbg xendbg: Xen VMI Debugger: Debug Xen PV and HVM guests]<br />
* VMI libraries<br />
** [https://github.com/libvmi/libvmi LibVMI on GitHub] <br />
** [http://libvmi.com/ LibVMI Home Page]<br />
** [https://blog.xenproject.org/2015/08/04/the-bitdefender-virtual-machine-introspection-library-is-now-on-github/ The Bitdefender virtual machine introspection library is now on GitHub]<br />
<br />
== Commercial Applications (in alphabetical order) ==<br />
* AIS IntroVirt (XenServer)<br />
** [https://www.ainfosec.com/innovative-products/#introvirt IntroVirt]<br />
* BitDefender Hypervisor Introspection (for XenServer)<br />
** [http://xenserver.org/blog/entry/xenserver-dundee-released.html XenServer 7.0 with Direct Inspect API set (which essentially is VMI)]<br />
** [https://www.bitdefender.com/business/hypervisor-introspection.html Bitdefender Hypervisor Introspection] <br />
** [https://www.youtube.com/watch?v=qUsqKoGX-U0 Video: The XenServer Direct Inspect API and Bitdefender Hypervisor Introspection]<br />
** [https://www.youtube.com/watch?v=5j0_cpxra7A Video: (Bitdefender Hypervisor Introspection Demo)]<br />
<br />
* Zentific Zazen (for Xen Project and XenServer)<br />
** [https://www.zentific.com/zazen/ Zazen Product page]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]<br />
[[Category:Xen 4.8]]<br />
[[Category:Security]]</div>Wenzelhttps://wiki.xenproject.org/index.php?title=Virtual_Machine_Introspection&diff=19108Virtual Machine Introspection2019-01-31T10:23:13Z<p>Wenzel: Add Xendbg</p>
<hr />
<div>In Xen 4.5, VM introspection using Intel EPT / AMD RVI hardware virtualization functionality was added building on Xen Project Hypervisors Memory Inspection APIs introduced in 2011. In Xen 4.6 a number of significant improvements to Xen’s Virtual Machine Introspection (VMI) subsystems make it the best hypervisor for security applications. Hardware support for VM Functions (VMFunc) available on Intel’s 4th generation Haswell CPUs and Atom Silvermont CPUs decreases overheads. Support for Virtualization Exceptions is now available on Intel’s 5th generation Broadwell CPUs and Atom Goldmont CPUs has significantly reduced latency. VMI support for ARM CPUs has also been added. Further improvements were made in Xen 4.7 and 4.8.<br />
<br />
VMI addresses a number of security issues from outside the guest OS without relying on functionality that can be rendered unreliable by advanced malware. The approach works by auditing access of sensitive memory areas using HW support in guests in an unobtrusive way (or maybe better: with minimal overhead) and allows control software running within a dedicated VM to allow or deny attempts to access sensitive memory based on policy and security heuristics. <br />
<br />
Key contributors in alphabetical order: Bitdefender, Intel, Novetta, Zentific<br />
<br />
== Chronology ==<br />
* 2009: First patches for the mem_event API<br />
* 2011: Xen 4.1: First memory introspection API upstream<br />
* 2015: Xen 4.5: VM introspection using Intel EPT / AMD RVI hardware virtualization<br />
* 2015: Xen 4.6:<br />
** mem_event becomes vm_event to support all kinds of hardware events (interrupts, registers, etc...)<br />
** x86 and ARM introspection support<br />
** hardware support or VMFUNC<br />
** altp2m<br />
<br />
<br />
== Background Information, papers, presentations ==<br />
* [https://www.linux.com/news/virtual-machine-introspection-security-innovation-new-commercial-applications Virtual Machine Introspection: A Security Innovation With New Commercial Applications (2016)]<br />
* [http://www.wesrch.com/electronics/paper-details/pdf-EL11TZ000PYAA-hypervisor-extensions-for-virtual-machine-memory-introspection Hypervisor Extensions for Virtual Machine Memory Introspection (2016)]<br />
* [http://www.sciencedirect.com/science/article/pii/S1742287616300081 TLSkex: Harnessing virtual machine introspection for decrypting TLS communication (2016)]<br />
* [https://blog.xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m/ Stealthy Monitoring with alt2pm (2016)]<br />
* [http://www.slideshare.net/tklengyel/stealthy-hypervisorbased-malware-analysis Stealthy, Hypervisor-based Malware Analysis (2016)]<br />
* [https://www.youtube.com/watch?v=k0BVFyyuvRA Virtual Machine Introspection with Xen (2015)]<br />
* [https://www.youtube.com/watch?v=nKrfsGvZgvo VM Introspection: Practical Applications (2015)]<br />
* [https://www.youtube.com/watch?v=GGjPU6jHi_w YouTube video] ([http://events.linuxfoundation.org/sites/events/files/slides/Zero-Footprint%20Guest%20Memory%20Introspection%20from%20Xen%20_%20draft11.pdf presentation]) (2014)<br />
<br />
== Related Projects ==<br />
* Malware analysis<br />
** [http://tklengyel.github.io/drakvuf/ DRAKVUF - Dynamic Malware Analysis] (contains a number of demos)<br />
* Hypervisor-level debugger<br />
** [https://github.com/Zentific/vmidbg vmidbg Enable s debuggers to remotely access and manipulate VM memory, utilizing the virtual machine introspection capabilities of LibVMI]<br />
** [https://github.com/Wenzel/r2vmi Hypervisor-Level Debugger based on Radare2/LibVMI]<br />
** [https://github.com/Wenzel/pyvmidbg pyvmidbg: LibVMI based GDB stub, a flexible hypervisor-level debugger]<br />
** [https://github.com/nccgroup/xendbg xendbg: Xen VMI Debugger: Debug Xen PV and HVM guests]<br />
* VMI libraries<br />
** [https://github.com/libvmi/libvmi LibVMI on GitHub] <br />
** [http://libvmi.com/ LibVMI Home Page]<br />
** [https://blog.xenproject.org/2015/08/04/the-bitdefender-virtual-machine-introspection-library-is-now-on-github/ The Bitdefender virtual machine introspection library is now on GitHub]<br />
-virtual-machine-introspection-library-is-now-on-github/<br />
<br />
== Commercial Applications (in alphabetical order) ==<br />
* AIS IntroVirt (XenServer)<br />
** [https://www.ainfosec.com/innovative-products/#introvirt IntroVirt]<br />
* BitDefender Hypervisor Introspection (for XenServer)<br />
** [http://xenserver.org/blog/entry/xenserver-dundee-released.html XenServer 7.0 with Direct Inspect API set (which essentially is VMI)]<br />
** [https://www.bitdefender.com/business/hypervisor-introspection.html Bitdefender Hypervisor Introspection] <br />
** [https://www.youtube.com/watch?v=qUsqKoGX-U0 Video: The XenServer Direct Inspect API and Bitdefender Hypervisor Introspection]<br />
** [https://www.youtube.com/watch?v=5j0_cpxra7A Video: (Bitdefender Hypervisor Introspection Demo)]<br />
<br />
* Zentific Zazen (for Xen Project and XenServer)<br />
** [https://www.zentific.com/zazen/ Zazen Product page]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]<br />
[[Category:Xen 4.8]]<br />
[[Category:Security]]</div>Wenzelhttps://wiki.xenproject.org/index.php?title=Virtual_Machine_Introspection&diff=19107Virtual Machine Introspection2019-01-31T10:15:16Z<p>Wenzel: </p>
<hr />
<div>In Xen 4.5, VM introspection using Intel EPT / AMD RVI hardware virtualization functionality was added building on Xen Project Hypervisors Memory Inspection APIs introduced in 2011. In Xen 4.6 a number of significant improvements to Xen’s Virtual Machine Introspection (VMI) subsystems make it the best hypervisor for security applications. Hardware support for VM Functions (VMFunc) available on Intel’s 4th generation Haswell CPUs and Atom Silvermont CPUs decreases overheads. Support for Virtualization Exceptions is now available on Intel’s 5th generation Broadwell CPUs and Atom Goldmont CPUs has significantly reduced latency. VMI support for ARM CPUs has also been added. Further improvements were made in Xen 4.7 and 4.8.<br />
<br />
VMI addresses a number of security issues from outside the guest OS without relying on functionality that can be rendered unreliable by advanced malware. The approach works by auditing access of sensitive memory areas using HW support in guests in an unobtrusive way (or maybe better: with minimal overhead) and allows control software running within a dedicated VM to allow or deny attempts to access sensitive memory based on policy and security heuristics. <br />
<br />
Key contributors in alphabetical order: Bitdefender, Intel, Novetta, Zentific<br />
<br />
== Chronology ==<br />
* 2009: First patches for the mem_event API<br />
* 2011: Xen 4.1: First memory introspection API upstream<br />
* 2015: Xen 4.5: VM introspection using Intel EPT / AMD RVI hardware virtualization<br />
* 2015: Xen 4.6:<br />
** mem_event becomes vm_event to support all kinds of hardware events (interrupts, registers, etc...)<br />
** x86 and ARM introspection support<br />
** hardware support or VMFUNC<br />
** altp2m<br />
<br />
<br />
== Background Information, papers, presentations ==<br />
* [https://www.linux.com/news/virtual-machine-introspection-security-innovation-new-commercial-applications Virtual Machine Introspection: A Security Innovation With New Commercial Applications (2016)]<br />
* [http://www.wesrch.com/electronics/paper-details/pdf-EL11TZ000PYAA-hypervisor-extensions-for-virtual-machine-memory-introspection Hypervisor Extensions for Virtual Machine Memory Introspection (2016)]<br />
* [http://www.sciencedirect.com/science/article/pii/S1742287616300081 TLSkex: Harnessing virtual machine introspection for decrypting TLS communication (2016)]<br />
* [https://blog.xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m/ Stealthy Monitoring with alt2pm (2016)]<br />
* [http://www.slideshare.net/tklengyel/stealthy-hypervisorbased-malware-analysis Stealthy, Hypervisor-based Malware Analysis (2016)]<br />
* [https://www.youtube.com/watch?v=k0BVFyyuvRA Virtual Machine Introspection with Xen (2015)]<br />
* [https://www.youtube.com/watch?v=nKrfsGvZgvo VM Introspection: Practical Applications (2015)]<br />
* [https://www.youtube.com/watch?v=GGjPU6jHi_w YouTube video] ([http://events.linuxfoundation.org/sites/events/files/slides/Zero-Footprint%20Guest%20Memory%20Introspection%20from%20Xen%20_%20draft11.pdf presentation]) (2014)<br />
<br />
== Related Projects ==<br />
* [http://tklengyel.github.io/drakvuf/ DRAKVUF - Dynamic Malware Analysis] (contains a number of demos)<br />
* [https://github.com/Zentific/vmidbg vmidbg Enables debuggers to remotely access and manipulate VM memory, utilizing the virtual machine introspection capabilities of LibVMI]<br />
* [https://github.com/Wenzel/r2vmi Hypervisor-Level Debugger based on Radare2/LibVMI]<br />
* [https://github.com/Wenzel/pyvmidbg pyvmidbg: LibVMI based GDB stub, a flexible hypervisor-level debugger]<br />
* [https://github.com/libvmi/libvmi LibVMI on GitHub] <br />
* [http://libvmi.com/ LibVMI Home Page]<br />
* [https://blog.xenproject.org/2015/08/04/the-bitdefender-virtual-machine-introspection-library-is-now-on-github/ The Bitdefender virtual machine introspection library is now on GitHub]<br />
<br />
== Commercial Applications (in alphabetical order) ==<br />
* AIS IntroVirt (XenServer)<br />
** [https://www.ainfosec.com/innovative-products/#introvirt IntroVirt]<br />
* BitDefender Hypervisor Introspection (for XenServer)<br />
** [http://xenserver.org/blog/entry/xenserver-dundee-released.html XenServer 7.0 with Direct Inspect API set (which essentially is VMI)]<br />
** [https://www.bitdefender.com/business/hypervisor-introspection.html Bitdefender Hypervisor Introspection] <br />
** [https://www.youtube.com/watch?v=qUsqKoGX-U0 Video: The XenServer Direct Inspect API and Bitdefender Hypervisor Introspection]<br />
** [https://www.youtube.com/watch?v=5j0_cpxra7A Video: (Bitdefender Hypervisor Introspection Demo)]<br />
<br />
* Zentific Zazen (for Xen Project and XenServer)<br />
** [https://www.zentific.com/zazen/ Zazen Product page]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]<br />
[[Category:Xen 4.8]]<br />
[[Category:Security]]</div>Wenzelhttps://wiki.xenproject.org/index.php?title=Virtual_Machine_Introspection&diff=19102Virtual Machine Introspection2019-01-20T23:02:22Z<p>Wenzel: add pyvmidbg</p>
<hr />
<div>In Xen 4.5, VM introspection using Intel EPT / AMD RVI hardware virtualization functionality was added building on Xen Project Hypervisors Memory Inspection APIs introduced in 2011. In Xen 4.6 a number of significant improvements to Xen’s Virtual Machine Introspection (VMI) subsystems make it the best hypervisor for security applications. Hardware support for VM Functions (VMFunc) available on Intel’s 4th generation Haswell CPUs and Atom Silvermont CPUs decreases overheads. Support for Virtualization Exceptions is now available on Intel’s 5th generation Broadwell CPUs and Atom Goldmont CPUs has significantly reduced latency. VMI support for ARM CPUs has also been added. Further improvements were made in Xen 4.7 and 4.8.<br />
<br />
VMI addresses a number of security issues from outside the guest OS without relying on functionality that can be rendered unreliable by advanced malware. The approach works by auditing access of sensitive memory areas using HW support in guests in an unobtrusive way (or maybe better: with minimal overhead) and allows control software running within a dedicated VM to allow or deny attempts to access sensitive memory based on policy and security heuristics. <br />
<br />
Key contributors in alphabetical order: Bitdefender, Intel, Novetta, Zentific<br />
<br />
== Background Information, papers, presentations ==<br />
* [https://www.linux.com/news/virtual-machine-introspection-security-innovation-new-commercial-applications Virtual Machine Introspection: A Security Innovation With New Commercial Applications (2016)]<br />
* [http://www.wesrch.com/electronics/paper-details/pdf-EL11TZ000PYAA-hypervisor-extensions-for-virtual-machine-memory-introspection Hypervisor Extensions for Virtual Machine Memory Introspection (2016)]<br />
* [http://www.sciencedirect.com/science/article/pii/S1742287616300081 TLSkex: Harnessing virtual machine introspection for decrypting TLS communication (2016)]<br />
* [https://blog.xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m/ Stealthy Monitoring with alt2pm (2016)]<br />
* [http://www.slideshare.net/tklengyel/stealthy-hypervisorbased-malware-analysis Stealthy, Hypervisor-based Malware Analysis (2016)]<br />
* [https://www.youtube.com/watch?v=k0BVFyyuvRA Virtual Machine Introspection with Xen (2015)]<br />
* [https://www.youtube.com/watch?v=nKrfsGvZgvo VM Introspection: Practical Applications (2015)]<br />
* [https://www.youtube.com/watch?v=GGjPU6jHi_w YouTube video] ([http://events.linuxfoundation.org/sites/events/files/slides/Zero-Footprint%20Guest%20Memory%20Introspection%20from%20Xen%20_%20draft11.pdf presentation]) (2014)<br />
<br />
== Related Projects ==<br />
* [http://tklengyel.github.io/drakvuf/ DRAKVUF - Dynamic Malware Analysis] (contains a number of demos)<br />
* [https://github.com/Zentific/vmidbg vmidbg Enables debuggers to remotely access and manipulate VM memory, utilizing the virtual machine introspection capabilities of LibVMI]<br />
* [https://github.com/Wenzel/r2vmi Hypervisor-Level Debugger based on Radare2/LibVMI]<br />
* [https://github.com/Wenzel/pyvmidbg pyvmidbg: LibVMI based GDB stub, a flexible hypervisor-level debugger]<br />
* [https://github.com/libvmi/libvmi LibVMI on GitHub] <br />
* [http://libvmi.com/ LibVMI Home Page]<br />
* [https://blog.xenproject.org/2015/08/04/the-bitdefender-virtual-machine-introspection-library-is-now-on-github/ The Bitdefender virtual machine introspection library is now on GitHub]<br />
<br />
== Commercial Applications (in alphabetical order) ==<br />
* AIS IntroVirt (XenServer)<br />
** [https://www.ainfosec.com/innovative-products/#introvirt IntroVirt]<br />
* BitDefender Hypervisor Introspection (for XenServer)<br />
** [http://xenserver.org/blog/entry/xenserver-dundee-released.html XenServer 7.0 with Direct Inspect API set (which essentially is VMI)]<br />
** [https://www.bitdefender.com/business/hypervisor-introspection.html Bitdefender Hypervisor Introspection] <br />
** [https://www.youtube.com/watch?v=qUsqKoGX-U0 Video: The XenServer Direct Inspect API and Bitdefender Hypervisor Introspection]<br />
** [https://www.youtube.com/watch?v=5j0_cpxra7A Video: (Bitdefender Hypervisor Introspection Demo)]<br />
<br />
* Zentific Zazen (for Xen Project and XenServer)<br />
** [https://www.zentific.com/zazen/ Zazen Product page]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]<br />
[[Category:Xen 4.8]]<br />
[[Category:Security]]</div>Wenzelhttps://wiki.xenproject.org/index.php?title=Virtual_Machine_Introspection&diff=19039Virtual Machine Introspection2018-10-17T14:12:59Z<p>Wenzel: add r2vmi</p>
<hr />
<div>In Xen 4.5, VM introspection using Intel EPT / AMD RVI hardware virtualization functionality was added building on Xen Project Hypervisors Memory Inspection APIs introduced in 2011. In Xen 4.6 a number of significant improvements to Xen’s Virtual Machine Introspection (VMI) subsystems make it the best hypervisor for security applications. Hardware support for VM Functions (VMFunc) available on Intel’s 4th generation Haswell CPUs and Atom Silvermont CPUs decreases overheads. Support for Virtualization Exceptions is now available on Intel’s 5th generation Broadwell CPUs and Atom Goldmont CPUs has significantly reduced latency. VMI support for ARM CPUs has also been added. Further improvements were made in Xen 4.7 and 4.8.<br />
<br />
VMI addresses a number of security issues from outside the guest OS without relying on functionality that can be rendered unreliable by advanced malware. The approach works by auditing access of sensitive memory areas using HW support in guests in an unobtrusive way (or maybe better: with minimal overhead) and allows control software running within a dedicated VM to allow or deny attempts to access sensitive memory based on policy and security heuristics. <br />
<br />
Key contributors in alphabetical order: Bitdefender, Intel, Novetta, Zentific<br />
<br />
== Background Information, papers, presentations ==<br />
* [https://www.linux.com/news/virtual-machine-introspection-security-innovation-new-commercial-applications Virtual Machine Introspection: A Security Innovation With New Commercial Applications (2016)]<br />
* [http://www.wesrch.com/electronics/paper-details/pdf-EL11TZ000PYAA-hypervisor-extensions-for-virtual-machine-memory-introspection Hypervisor Extensions for Virtual Machine Memory Introspection (2016)]<br />
* [http://www.sciencedirect.com/science/article/pii/S1742287616300081 TLSkex: Harnessing virtual machine introspection for decrypting TLS communication (2016)]<br />
* [https://blog.xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m/ Stealthy Monitoring with alt2pm (2016)]<br />
* [http://www.slideshare.net/tklengyel/stealthy-hypervisorbased-malware-analysis Stealthy, Hypervisor-based Malware Analysis (2016)]<br />
* [https://www.youtube.com/watch?v=k0BVFyyuvRA Virtual Machine Introspection with Xen (2015)]<br />
* [https://www.youtube.com/watch?v=nKrfsGvZgvo VM Introspection: Practical Applications (2015)]<br />
* [https://www.youtube.com/watch?v=GGjPU6jHi_w YouTube video] ([http://events.linuxfoundation.org/sites/events/files/slides/Zero-Footprint%20Guest%20Memory%20Introspection%20from%20Xen%20_%20draft11.pdf presentation]) (2014)<br />
<br />
== Related Projects ==<br />
* [http://tklengyel.github.io/drakvuf/ DRAKVUF - Dynamic Malware Analysis] (contains a number of demos)<br />
* [https://github.com/Zentific/vmidbg vmidbg Enables debuggers to remotely access and manipulate VM memory, utilizing the virtual machine introspection capabilities of LibVMI]<br />
* [https://github.com/Wenzel/r2vmi Hypervisor-Level Debugger based on Radare2/LibVMI] <br />
* [https://github.com/libvmi/libvmi LibVMI on GitHub] <br />
* [http://libvmi.com/ LibVMI Home Page]<br />
* [https://blog.xenproject.org/2015/08/04/the-bitdefender-virtual-machine-introspection-library-is-now-on-github/ The Bitdefender virtual machine introspection library is now on GitHub]<br />
<br />
== Commercial Applications (in alphabetical order) ==<br />
* AIS IntroVirt (XenServer)<br />
** [https://www.ainfosec.com/innovative-products/#introvirt IntroVirt]<br />
* BitDefender Hypervisor Introspection (for XenServer)<br />
** [http://xenserver.org/blog/entry/xenserver-dundee-released.html XenServer 7.0 with Direct Inspect API set (which essentially is VMI)]<br />
** [https://www.bitdefender.com/business/hypervisor-introspection.html Bitdefender Hypervisor Introspection] <br />
** [https://www.youtube.com/watch?v=qUsqKoGX-U0 Video: The XenServer Direct Inspect API and Bitdefender Hypervisor Introspection]<br />
** [https://www.youtube.com/watch?v=5j0_cpxra7A Video: (Bitdefender Hypervisor Introspection Demo)]<br />
<br />
* Zentific Zazen (for Xen Project and XenServer)<br />
** [https://www.zentific.com/zazen/ Zazen Product page]<br />
<br />
[[Category:Xen 4.5]]<br />
[[Category:Xen 4.6]]<br />
[[Category:Xen 4.7]]<br />
[[Category:Xen 4.8]]<br />
[[Category:Security]]</div>Wenzel