nyuuzyou/wikis huggingface dataset:
XenAPI client libraries for ocaml

This page describes how to install the XenAPI client libraries for ocaml, and how to use them with tab-completion in a toplevel REPL.
This is currently a draft.
== Before you start ==
Use your distro's package manager to install an ocaml version >= 3.12.1
 
sudo apt-get install ocaml
== Install the ocaml package manager "opam" ==
The version of the package manager and the package repositories in the xapi-project fork on github are the most recent versions that have passed the xen-specific build tests.
 
git clone git://github.com/xapi-project/opam
(cd opam; ./configure && make && sudo make install)
== Initialise from the standard set of base packages ==
 
opam init git://github.com/xapi-project/opam-repository
== Add the xen-specific package repository ==
 
opam remote -add xapi-project git://github.com/xapi-project/opam-repo-dev
== Switch to a clean setup of the 3.12.1 compiler ==
 
opam switch 3.12.1
Run the following command in your terminal and add this to your .profile to make sure your ocaml environment variables are setup:
 
eval `opam config -env`
== Install packages ==
 
opam --yes install xen-api-client utop
== Try the XenAPI ==
Run "utop" in a terminal -- this should give you an ocaml toplevel with tab-completion. Type the following: (try hitting "tab" a lot)
 
#require "xen-api-client.lwt";;
XenExpress

XenExpress was a custom Linux distro that actually uses CentOS as a base. The XenSource folks take CentOS, replace the stock kernel with one with Xen support, strip down the install package set to a fairly barebones level (approximately 190 rpms) and then add in a few custom Xen server components.
XenExpress was rebranded to XenServer Free edition, following the Citrix acquisition of Xensource.
== Also See ==
* XenLinux
Category:Xen
Category:Glossary
XenGT

This page contains pointers for information about the XenGT project (now renamed "GVT-v for Xen").
== What is XenGT? ==
Rob Farber's answer:
A full (opensource!) GPU virtualization solution that allows virtualized guest operating systems to “own” a shared Intel GPU yet allows applications to run with near-native performance.
The XenGT effort is currently an out-of-tree effort by Intel developers. That is, the code supporting XenGT is not currently in Xen Project repositories, but Intel does make it available. Efforts at integrating XenGT into Xen Project are expected in 2015.
== What Information is Available? ==
* XenGT Architecture
* XenGT Setup Guide from Sept 2013
* XenGT slides from March 2014
* Video Presentation from October 2013
* Article on XenGT from December 2014 by Rob Farber
* Video About Intel's Work Virtualizing the GPU from January 2015
== Where is the Code? ==
Github repositories:
* Xen Project patches
* Linux kernel patches
* QEMU patches
Category:VGA
Category:Integration
XenLinux

__NOTOC__
XenLinux is the Linux kernel with patches applied so that it will run on the virtual architecture presented by the Xen hypervisor rather than on real hardware. Since version 3.0 of the Linux kernel, the Xen patches have been applied to the upstream kernel. This means it can serve as the kernel of a domain, but it will no longer run natively on a machine. Although other operating systems have been ported to run on Xen, Linux is the only one that has been given the extra functionality needed to run in dom0.
See also : Hurd.
Category:Kernel
Category:Xen
Category:PVOPS
Category:Glossary
XenNetworking/Examples

This page is here because I found it difficult to find information on what I felt was a relatively simple networking case. However it should not be limited by that case - it could become a good reference point for most common networking layouts.
== Single Physical Public - Single Virtual Backend ==
=== Justification ===
At Hetzner (a German hosting company - also available in SA) their root servers typically have a single ethernet connection, allowing multiple addresses. I also wanted to have a private network to allow home directory sharing and other such things between various functional Xen domains (www/mail...).
=== Network Layout ===
My IP and most of my /29 subnet are avaiable directly on the single ethernet interface provided. The first subnet address is the subnet gateway and is provided by my hosting provider.
Hosting Switch
 |
 |
 |
peth0
 |
xenbr0 xenbr1
 | - PubIP - dom0 - RFC1918 - |
 | - PubIP - domU - RFC1918 - |
 ...
=== dom0 (xend) ===
I run debian as a dom0, and chose to use 172.16.16.0/24 as my RFC1918 range, so I did the following (as root):
modprobe dummy
echo dummy >> /etc/modules
cat <<EOF >> /etc/network/interfaces
# Xen Backend
auto dummy0
iface dummy0 inet static
 address 172.16.16.1
 broadcast 172.16.16.255
 netmask 255.255.255.0
EOF
ifup dummy0
cat <<EOF > /etc/xen/scripts/my_network_script
#!/bin/sh
dir=$(dirname "$0")
"$dir/network-bridge" "$@" vifnum=0 netdev=eth0 bridge=xenbr0
"$dir/network-bridge" "$@" vifnum=1 netdev=dummy0 bridge=xenbr1
EOF
chmod +x /etc/xen/scripts/my_network_script
Don't forget to make the new script executable
Then edit /etc/xen/xend-config.sxp to have the following two lines of config:
(network-script my_network_script)
(vif-script vif-bridge)
And restart xend
/etc/init.d/xend restart
* lo
* eth0 (Your public IP address)
* dummy0 (172.16.16.1 - or other RFC1918 address)
* xenbr0
* xenbr1 
=== domU ===
Configure your domU as normal - but edit the cfg file to have the following entry (substitute your public IP and an available private IP):
vif = [ 'ip=<PublicIP>,bridge=xenbr0','ip=172.16.16.2,bridge=xenbr1' ]
When you boot it up - set the two interfaces up in /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
 address x.y.z.2
 gateway x.y.z.1
 netmask 255.255.255.248
 
auto eth1
iface eth1 inet static
 address 172.16.16.2
 netmask 255.255.255.0
== Also see ==
* HostConfiguration/Networking
* XenBestPractices
Category:Xen
Category:Example
Category:HowTo
XenParavirtOps/OpenSUSE

= OpenSUSE Xen pvops status =
This page is dedicated to keep track of what is needed to get you up and running with the latest kernel and latest xen code, that uses pvops. This assumes you will be building on top of vanilla Linux and vanilla unstable xen trees.
= Requirements to run pvops =
== Configuring the kernel ==
You'll first want to configure your kernel, since Xen supports both a dom0 and guest options folks have been historically building two separate kernels to support each of these functionalities. It is desirable however to build only one kernel to support both. There are some hard things to resolve to get to that but for now to build your kernel you want to use the new 'make xenconfig' kernel configuration option which will let you enables all you need for both dom0 and guest support on x86 and arm64 architectures, these patches are pending to be merged upstream, you can find them here:
http://ftp.suse.com/pub/people/mcgrof/xen/xenconfig-2014-12-08/
== Fixing grub ==
There are a series of outstanding bugs which have fixes made but yet to be merged:
 * boo#774666 grub2 does not offer a Xen entry after installing hypervisor and tools
 * bsc#895286 grub2 prevents xen pvops kernel from appearing on menu - fix now merged on Factory
 * bsc#897901 /sbin/installkernel requirements for Xen - fix now merged on Factory
XenSource

__NOTOC__
XenSource, Inc. developed enterprise-grade virtualization solutions based on the industry's best server virtualization technology, the open source Xen hypervisor. Founded and run by the original Xen development team, XenSource products will allow enterprises to realize the TCO savings that result from server consolidation, increased utilization, and reduced complexity in the datacenter.
XenSource was acquired by Citrix in 2007.
The XenSource name has been retained as a string in the paths of several XenServer/XCP components, for example /etc/xensource, /opt/xensource, /var/log/xensource.log and so on.
Category:Glossary
XenStore

__NOTOC__
XenStore is an information storage space shared between domains maintained by the Xenstored. It is meant for configuration and status information rather than for large data transfers. Each domain gets its own path in the store, which is somewhat similar in spirit to procfs. When values are changed in the store, the appropriate drivers are notified. For more information and a guide to developing with XenStore, see XenBus.
You can find more about the data stored in XenStore at XenStoreReference.
You can dump the contents of the xenstore using the xenstore-ls tool.
<nowiki>
# xenstore-ls 
local = ""
 domain = ""
 0 = ""
 name = "Domain-0"
 device-model = ""
 0 = ""
 state = "running"
 memory = ""
 target = "524288"
 static-max = "524288"
 freemem-slack = "1254331"
 libxl = ""
 disable_udev = "1"
vm = ""
libxl = ""
</nowiki>
or with -f to produce a flattened output
<nowiki>
# xenstore-ls -f
/local = ""
/local/domain = ""
/local/domain/0 = ""
/local/domain/0/name = "Domain-0"
/local/domain/0/device-model = ""
/local/domain/0/device-model/0 = ""
/local/domain/0/device-model/0/state = "running"
/local/domain/0/memory = ""
/local/domain/0/memory/target = "524288"
/local/domain/0/memory/static-max = "524288"
/local/domain/0/memory/freemem-slack = "1254331"
/local/domain/0/libxl = ""
/local/domain/0/libxl/disable_udev = "1"
/vm = ""
/libxl = ""
</nowiki>
Category:Xen
Category:Developers
Category:Glossary
XenTest

This page and its sub-pages have been archived. The reason is that Xen testing has never been implemented in the way that the old pages implied. The Xen team has an automated test harness that is currently undocumented. 
* A plan is in place to document the harness for Xen 4.3
* A plan is in place to make the harness deployable in distros and for everyone
* The test harness will be documented
* Test failures of the harness: failed tests lead to e-mails sent to xen-devel - these are marked with:
** [Xen-devel] [xen-unstable test] <test ID>: regressions - FAIL; for an example see this query 
** [Xen-devel] [xen-4.0-testing test] <test ID>: regressions - FAIL; for tests on the Xen 4.0 branch. 
** Etc.
 
== For the Archived pages go to ... ==
* Archived/XenTest - these are still valuable for manual testing
== Also see ==
* Distros - Recommended tests and integration notes for Linux/Unix distributions containing Xen pages
Xen (disambiguation)

__NOTOC__
= Xen (disambiguation) =
Xen may refer to:
* The Xen hypervisor, type 1 hypervisor (virtual machine monitor)
* The Xen Cloud Platform (XCP)
* XAPI_on_Debian XAPI_on_Ubuntu, Project Kronos, the Xen API (XAPI), which is the XCP toolstack, ported to Debian, Ubuntu, etc.
* Citrix XenServer
Category:Xen
Category:Glossary
Xen / XCP / XAPI Overview

This table gives a high level overview of the different high-level features of Xen, XCP and XCP-XAPI packages in Linux (Debian & Ubuntu) (also see Project Zeus (for Fedora)). 
Description 	Xen 	XCP 	XCP-XAPI packages in Linux
Hypervisor 	latest 	lagging 	as in latest Linux distro
Dom0 OS 	See Dom0_Kernels_for_Xen 	CentOS (5.7 in XCP 1.6) 	See Debian, Ubuntu and Fedora
Dom0 	32 and 64 bits 	32 bits 	32 and 64 bits
Linux 3 PVOPS Dom0 	Yes 	No 	Yes
Toolstack 	XM (deprecated), XL, libvirt 	XAPI with XE 	Same as XCP
Features 	Xen Feature List 	Xen Feature List and XCP Feature List 	Xen Feature List and XCP Feature List
Storage, Network, Drivers	Build and get yourself 	Integrated with Open vSwitch, multiple storage types & drivers	Get them yourself (only core components are provided)
Configurations 	Everything 	Constrained by XAPI 	Same as XCP
Usage Model 	Do it yourself 	Shrink wrapped and tested 	Do it yourself
Distribution 	Source code or via host Linux or Unix distributions	Delivered as ISO on xen.org 	Via host Linux or Unix distributions
Also see some interesting videos on the subject.
Category:Xen
Category:XCP
Category:Users
Category:Beginners
Xen 3.x Manuals

__NOTOC__
== Xen Man Pages ==
Man pages are currently available in Xen 3.0.0 for the following:
* See :Category:ManPage
* xm
* xend-config.sxp
== Xen Books - On Line ==
* Xen Virtualization Essentials, by Neil Smyth (Virtuatopia.com; June 16, 2008; online: 20 chapters)
== Xen Books - In Print ==
* The Definitive Guide to the Xen Hypervisor, by David Chisnall (Prentice Hall; November 9, 2007; hardcover: 320 pages)
* Running Xen: A Hands-on Guide to the Art of Virtualization, by Jeanna Neefe Matthews, Eli M. Dow, Todd Deshane, Wenjin Hu, Jeremy Bongio, Patrick F. Wilbur, and Brendan Johnson (Prentice Hall; May 5, 2008; paperback: 720 pages)
* Professional XEN Virtualization, by William von Hagen (Wrox; August 27, 2007; paperback: 500 pages)
* XenExpress/ Virtualization with Xen: Including XenEnterprise, XenServer, and XenExpress, by David E. Williams (Syngress; April 1, 2007; paperback: 512 pages)
* Xen 3 (german), by Andrej Radonic and Frank Meyer (Franzis; October 2006; 439 pages)
* Xen - Virtualisierung unter Linux (german), by Timo Benk, Heninng Sprang, Jaroslaw Zdrzalek and Ralph Dehner (Open Source Press; April 2007; hardcover: 350 pages)
== Also See ==
* Xen 2.x Manuals
Category:Xen
Category:Users
Xen 4.3 Release Notes

= Overview =
Xen 4.3.0 was released on July 9, 2013.
= New Feature Highlights =
* Early support for ARM 32- (ARMv7) and 64-bit (ARMv8) architectures
* qemu-upstream is now the default for VMs not using stub domains. You can change this by adding device_model_version = "qemu-xen-traditional" to your config file.
* openvswitch hot-plug script support. See the Open vSwitch section of Xen Networking for more details.
* NUMA affinity for the scheduler
* xl can now accept several USB devices, rather than only one, using the following syntax: usbdevice=["device1","device2",...] The old format is still supported.
* XSM improvements. XSM can now override all IS_PRIV checks in the hypervisor.
* As always, a number of stability, performance, and security enhancements "under the hood".
A more complete list of features can be found on the Xen 4.3 Feature List
= Build Requirements =
The default installation prefix has been changed to /usr/local. Previously the default installation prefix was /usr To restore the previous behaviour, specify --prefix=/usr when running ./configure, e.g.:
 $ ./configure --prefix=/usr
If you choose to accept the new default then be sure to cleanup any residual bits of the old installation in the old prefix, especially libraries and tools which you might pick up by mistake.
Due to this change it may also now be necessary to run /sbin/ldconfig as root after installing Xen.
Note also that Xen now requires gcc v4.1 or greater.
= Other changes =
* Support for x86 32-bit and ia64 (itanium) hypervisors has been removed. 32bit VMs, including 32bit dom0, are still supported on the x86_64 64bit hypervisor.
= Known issues =
* qemu-upstream does not yet work with stub domains. Stub domains will still be created with qemu-traditional.
* If a mac address is not specified in the config file, a new random one may be assigned on migrate or reboot; this can cause networking issues for some guests. The work-around for now is to specify a mac address.
* Passing through some PCI devices, particularly video cards with large amounts of memory, may have some issues with the default qemu-xen. If you experience problems, try using qemu-traditional instead.
Category:Xen Category:Xen 4.3 Category:Release Notes Category:Users
Xen 4.8.0.bb

require recipes-extended/xen/xen.inc
 
 DEPENDS += " iasl-native"
 
 RDEPENDS_${PN}-xenstore = "bash"
 
 FILES_${PN}-xenstore += "\
 /usr/lib/xen/bin/init-xenstore-domain \
 /etc/xen/scripts/launch-xenstore \
 "
 
 # The followings are for Xen 4.9:
 FILES_${PN}-libxenstat += "\
 ${datadir}/pkgconfig/xenstat.pc \
 "
 FILES_${PN}-libblktapctl += "\
 ${datadir}/pkgconfig/xenblktapctl.pc \
 "
 FILES_${PN}-libxenstore += "\
 ${datadir}/pkgconfig/xenstore.pc \
 "
 FILES_${PN}-libxentoollog += "\
 ${datadir}/pkgconfig/xentoollog.pc \
 "
 FILES_${PN}-libxenctrl += "\
 ${datadir}/pkgconfig/xencontrol.pc \
 "
 FILES_${PN}-libxenguest += "\
 ${datadir}/pkgconfig/xenguest.pc \
 "
 FILES_${PN}-libxengnttab += "\
 ${datadir}/pkgconfig/xengnttab.pc \
 "
 FILES_${PN}-libxenvchan += "\
 ${datadir}/pkgconfig/xenvchan.pc \
 "
 FILES_${PN}-libxencall += "\
 ${datadir}/pkgconfig/xencall.pc \
 "
 FILES_${PN}-libxenforeignmemory += "\
 ${datadir}/pkgconfig/xenforeignmemory.pc \
 "
 FILES_${PN}-libxenevtchn += "\
 ${datadir}/pkgconfig/xenevtchn.pc \
 "
 FILES_${PN}-xendomains += "\
 ${sysconfdir}/init.d/xendriverdomain \
 "
 PACKAGES += "${PN}-xendevicemodel ${PN}-xendevicemodel-dev"
 FILES_${PN}-xendevicemodel += "\
 ${libdir}/libxendevicemodel.so.* \
 ${datadir}/pkgconfig/xendevicemodel.pc \
 "
 FILES_${PN}-xendevicemodel-dev += "${libdir}/libxendevicemodel.so"
 
 DEFAULT_PREFERENCE = "1"
 
 # update to the last commit and branch name
 SRCREV = "de22e0dd0df7244052b978fdd939aae7a0937077"
 SRC_URI = "git://xenbits.xen.org/xen.git;protocol=git;branch=staging;"
 
 S = "${WORKDIR}/git"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=bbb4b1bdc2c3b6743da3c39d03249095"
 
 # Xen suffixes the libexecdir within its configure scripts, prevent the nested xen/xen/
 libexecdir = "${libdir}"
 
 # These options override detected values from the build.
 EXTRA_OECONF_append += " \
 --with-initddir=${INIT_D_DIR} \
 --with-sysconfig-leaf-dir=default \
 --with-system-qemu=/usr/bin/qemu-system-i386 \
 --disable-qemu-traditional \
 "
 EXTRA_OEMAKE += "CROSS_COMPILE=${TARGET_PREFIX} APPEND_CFLAGS=-Wno-error"
Category:XenARM Category:Yocto Category:Developers
Xen ARM DEBUG hypercalls

If you are trying to DEBUG early boot code in your guest kernel, either Dom0 or DomU, you might find the Xen on ARM DEBUG hypercalls useful. They are only available to DEBUG builds, i.e. builds with Debugging Options ---> Developer Checks enabled.
Simply add one of the following hvc instructions to your code, and Xen will print something on the console for you:
 hvc 0xfffd
prints the program counter
 hvc 0xfffe
prints first byte of register x0
 hvc 0xffff
prints all registers and stack of the guest
 
 hvc 0xffe0-0xffef
prints program counter and a register: e0 prints x0, e1 prints x1, etc.
Xen ARM Manual Smoke Test

This page is about manually verifying that Xen on ARM works correctly on your ARM or ARM64 platforms. It is recommended to follow these steps during Xen test days and to verify Xen RCs (Release Candidates) on as many different platforms as possible.
* Install Xen on ARM on your system. A lot of information about how to build Xen from source and install it on your ARM platform is available here.
* Boot the system. Check the console logs and verify that Xen and Dom0 booted successfully. Connect to the console and verify that the system is usable (Is it responsive? Can you issue commands in Dom0?).
* Test hypervisor functionalities: clone raisin on the platform and run ./raise test
* Report your findings to xen-devel (see below) and/or add a quick record to Xen_ARM_Manual_Smoke_Test/Results.
= Reporting Bugs (& Issues) =
* Use Freenode IRC channel #xentest to discuss questions interactively
* Report any bugs / missing functionality / unexpected results. 
* Please put [TestDay] into the subject line
* Also make sure you specify the RC number you are using
* Make sure to follow the guidelines on Reporting Bugs against Xen.
= Reporting success by mail =
We would love it if you could report successes by e-mailing xen-devel@lists.xen.org, preferably including:
* Hardware: Please at least include the exact board or hardware name into the test
* Software: If you're using a distro, the distro name and version would be the most helpful. Other helpful information might include the kernel that you're running, or other virtualization-related software you're using (e.g., libvirt).
* Guest operating systems: If you tested a guest, please specify here
* Functionality tested: ARM Manual Smoke Test
Subject: [TESTDAY] Test report (<name of board>)
 
* Hardware:
 
* Software:
* Guest operating systems:
* Functionality tested: ARM Manual Smoke Test
* Comments:
= Reporting success by wiki =
The Xen ARM Manual Smoke Test/Results contains a list of people who have specific boards and also lists when these boards have been last tested. Feel free to add any test results to the table.
Category:XenARM
Category:Test Day
Xen ARM Manual Smoke Test/Results

__TOC__
= Contact Points =
Core/SoC/Board	Person/Org owning or willing to test	
= How To Report success on this page =
In the test results section below, please add an entry such as the following ...
<!-- Insert template into this section -->
{{BoardTestReport|OMAP5432|FAIL|4.7.0|RC2|Lars Kurth|}}
{{BoardTestReport|OMAP5432|PASS|4.7.0|RC2|Lars Kurth|}}
...
<!-- Do not edit below -->
= Test Results =
Core/SoC/Board	Pass/Fail	Last Tested Xen Release	Tested RC	Tested by	Link to xen-devel@ mail	
Category:XenARM
Category:Test Day
Xen ARM with Virtualization Extensions/BootProtocol

# Generic script to load and boot Xen from tftp
 #
 # For any questions/bug report please send an email to:
 # xen-devel@lists.xen.org
 #
 # Requirements:
 # U-boot variable environment:
 # - kernel_addr_r: kernel load address
 # - xen_addr_r: xen load address
 # - dtb_addr_r: fdt load address
 # - serverip: IP of the tftp server
 # - xen_bootargs: xen command line
 # - dom0_bootargs: dom0 command line
 # - kernel_path: kernel path
 # - xen_path: xen path
 # - dtb_path: device tree path
 #
 # Tftp server file:
 # You need to provide the files that you have specified in
 # $xen_path, $dtb_path and $kernel_path
 #
 ## Load the different components
 #
 # Load Linux in memory
 tftpboot $kernel_addr_r $serverip:$kernel_path
 # Load Xen in memory
 tftpboot $xen_addr_r $serverip:$xen_path
 # Load the device tree in memory
 tftpboot $dtb_addr_r $serverip:$dtb_path 
 #
 ## Fixup the device tree
 #
 # Be sure U-boot is using our FDT
 fdt addr $dtb_addr_r
 # Resize the FDT just in case
 fdt resize
 # Set Xen arguments based on $xen_bootargs
 fdt set /chosen xen,xen-bootargs \"$xen_bootargs\"
 #setenv bootargs $xen_bootargs # On Xen unstable, xen cmdline is in bootargs
 # Set Dom0 arguments based on $dom0_bootargs
 fdt set /chosen xen,dom0-bootargs \"$dom0_bootargs\"
 # Create modules node
 fdt mknode /chosen modules
 fdt set /chosen/modules '#address-cells' <1>
 fdt set /chosen/modules '#size-cells' <1>
 # Create node for the linux located at $kernel_addr_r
 # It seems U-boot doesn't have command to retrieve the size, so the size is
 # set to a big value (10Mb)
 fdt mknode /chosen/modules module@0
 fdt set /chosen/modules/module@0 compatible xen,linux-zimage xen,multiboot-module
 fdt set /chosen/modules/module@0 reg <$kernel_addr_r 0x00a00000>
 #
 ## Boot Xen
 bootm $xen_addr_r - $dtb_addr_r