https://wiki.xenproject.org/api.php?action=feedcontributions&user=OliverChick&feedformat=atomXen - User contributions [en]2024-03-28T21:28:59ZUser contributionsMediaWiki 1.31.3https://wiki.xenproject.org/index.php?title=Migration&diff=5212Migration2012-09-26T09:38:32Z<p>OliverChick: New page</p>
<hr />
<div>= Performing VM migration under Xen =<br />
<br />
Xen can migrate virtual machines between different servers, running Xen. This can be useful if you need to take a physical server offline, for maintenance. Rather than having to shutdown the VMs running on that host during the maintenance, you can migrate them to another physical server, and keep them running. Performing a migration does not require restarting the virtual server, and has no noticeable downtime.<br />
<br />
== Setup ==<br />
The persistent storage for the VMs must be shared, so that both Dom0s can see the same disk, at the same location.<br />
<br />
Then run `xl migrate <domain> <host>` to migrate the VM<br />
<br />
== Migrate without shared storage ==<br />
<br />
If you have no real shared storage (eg SAN) available, you can still test VM migration, using NBD. This allows you to share the harddrive of opne host to another. The disadvantage of this is that whilst you can migrate the VM, you cannot shutdown the host that contains the storage.<br />
<br />
* Install nbd-client on all Dom0s you will migrate between (apt-get install nbd-client on Debian-based distros)<br />
* Install nbd-server (apt-get intall nbd-server) on the Dom0 of the machine that contains the storage<br />
* Add the following to /etc/nbd-server/config<br />
<br />
<pre><br />
[<name>]<br />
exportname = <path to disk to share><br />
port = 9000<br />
</pre><br />
<br />
* Run `nbd-client 127.0.0.1 9000 /dev/nbd1` on the same machine<br />
* Run `nbd-client <hostname of machine that contains the storage> 9000 /dev/nbd1` on the machine you are migrating to<br />
* Modify your /etc/xen/foo.cfg file to use /dev/nbd1 as its disk, on the host backing the storage<br />
* Start the VM<br />
* Run `xl migrate <Domain> <new host>`<br />
<br />
[[Category:Users]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Ubuntu_10.04_domU&diff=5122Ubuntu 10.04 domU2012-09-24T15:31:45Z<p>OliverChick: added an out-of-date warning adn like to ubuntu's page on this</p>
<hr />
<div>{{Info|This page is out of date. See https://help.ubuntu.com/community/Xen to install the latest version of Ubuntu as a Xen DomU.}}<br />
<br />
== Installing Ubuntu 10.04 LTS (Lucid Lynx) Xen PV guest using the Ubuntu text installer ==<br />
Ubuntu 10.04 can be installed as Xen PV guest using the default text-based installer included in the Ubuntu distribution.<br />
<br />
First create a new LVM volume to store the guest virtual disk:<br />
<br />
<br />
<pre><br />
[root@f13 ~]# lvcreate -nubuntu01 -L20G /dev/vg_f13<br />
Logical volume "ubuntu01" created<br />
</pre><br />
<br />
Then download the official Ubuntu Xen guest configuration file:<br />
<br />
<br />
<pre><br />
[root@f13 ubuntu]# wget http://fi.archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/xen/xm-debian.cfg<br />
--2010-09-05 01:53:38-- http://fi.archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/xen/xm-debian.cfg<br />
Resolving fi.archive.ubuntu.com... 130.230.54.102, 2001:708:310:54::102<br />
Connecting to fi.archive.ubuntu.com|130.230.54.102|:80... connected.<br />
HTTP request sent, awaiting response... 200 OK<br />
Length: 7618 (7.4K) [text/plain]<br />
Saving to: “xm-debian.cfgâ€<br />
100%[======================================>] 7,618 --.-K/s in 0.008s<br />
2010-09-05 01:53:38 (911 KB/s) - “xm-debian.cfg†saved [7618/7618]<br />
</pre><br />
<br />
And rename it to "ubuntu01.cfg":<br />
<br />
<br />
<pre><br />
[root@f13 ubuntu]# mv xm-debian.cfg ubuntu01.cfg<br />
[root@f13 ubuntu]#<br />
</pre><br />
<br />
Then edit "ubuntu01.cfg" with your favourite text editor and make it look like this (among other stuff in it):<br />
<br />
<br />
<pre><br />
memory = 1024<br />
name = "ubuntu01"<br />
vcpus = 1<br />
vif = ['mac=00:16:36:64:3d:f3,bridge=virbr0']<br />
disk = ['phy:vg_f13/ubuntu01,xvda,w']<br />
</pre><br />
<br />
Modify the mac address to be unique.<br />
<br />
Then find a line in "ubuntu01.cfg" that says "bootloader=pygrub" and add proper path ("/usr/bin/pygrub") to it:<br />
<br />
<br />
<pre><br />
if not xm_vars.env.get('install'):<br />
bootloader="/usr/bin/pygrub"<br />
else:<br />
</pre><br />
<br />
Already modified configuration file is available as a reference from: http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu01.cfg .<br />
<br />
Then start the Ubuntu installer:<br />
<br />
<br />
<pre><br />
xm create -f ubuntu01.cfg -c install=true<br />
install-kernel="http://fi.archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/xen/vmlinuz"<br />
install-ramdisk="http://fi.archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/xen/initrd.gz"<br />
install-mirror="http://fi.archive.ubuntu.com/ubuntu"<br />
</pre><br />
<br />
All of the above command needs to be on a single line. Replace the mirror site URLs with your local mirror.<br />
<br />
Ubuntu 10.04 text installer starts:<br />
<br />
http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu01.png<br />
<br />
Install as usual. Choose DHCP for networking.<br />
<br />
http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu02.png<br />
<br />
http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu03.png<br />
<br />
http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu04.png<br />
<br />
http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu05.png<br />
<br />
When the installation finishes the Ubuntu guest VM will shut down.<br />
<br />
After installation you can start the Ubuntu guest like this:<br />
<br />
<br />
<pre><br />
xm create -f ubuntu01.cfg -c<br />
</pre><br />
<br />
First you'll see the pygrub menu which allows you to choose which Ubuntu kernel to boot, and then you'll get to the normal Xen PV guest text console and see the Ubuntu kernel booting. You can exit from the console by pressing ctrl+] or ctrl+5.<br />
[[Category:Beginners]]<br />
[[Category:Tutorial]]<br />
[[Category:Ubuntu]]<br />
[[Category:Guest Install]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Ubuntu_10.04_domU&diff=5121Ubuntu 10.04 domU2012-09-24T15:28:37Z<p>OliverChick: Undo revision 5120 by OliverChick (Talk)</p>
<hr />
<div>== Installing Ubuntu 10.04 LTS (Lucid Lynx) Xen PV guest using the Ubuntu text installer ==<br />
Ubuntu 10.04 can be installed as Xen PV guest using the default text-based installer included in the Ubuntu distribution.<br />
<br />
First create a new LVM volume to store the guest virtual disk:<br />
<br />
<br />
<pre><br />
[root@f13 ~]# lvcreate -nubuntu01 -L20G /dev/vg_f13<br />
Logical volume "ubuntu01" created<br />
</pre><br />
<br />
Then download the official Ubuntu Xen guest configuration file:<br />
<br />
<br />
<pre><br />
[root@f13 ubuntu]# wget http://fi.archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/xen/xm-debian.cfg<br />
--2010-09-05 01:53:38-- http://fi.archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/xen/xm-debian.cfg<br />
Resolving fi.archive.ubuntu.com... 130.230.54.102, 2001:708:310:54::102<br />
Connecting to fi.archive.ubuntu.com|130.230.54.102|:80... connected.<br />
HTTP request sent, awaiting response... 200 OK<br />
Length: 7618 (7.4K) [text/plain]<br />
Saving to: “xm-debian.cfgâ€<br />
100%[======================================>] 7,618 --.-K/s in 0.008s<br />
2010-09-05 01:53:38 (911 KB/s) - “xm-debian.cfg†saved [7618/7618]<br />
</pre><br />
<br />
And rename it to "ubuntu01.cfg":<br />
<br />
<br />
<pre><br />
[root@f13 ubuntu]# mv xm-debian.cfg ubuntu01.cfg<br />
[root@f13 ubuntu]#<br />
</pre><br />
<br />
Then edit "ubuntu01.cfg" with your favourite text editor and make it look like this (among other stuff in it):<br />
<br />
<br />
<pre><br />
memory = 1024<br />
name = "ubuntu01"<br />
vcpus = 1<br />
vif = ['mac=00:16:36:64:3d:f3,bridge=virbr0']<br />
disk = ['phy:vg_f13/ubuntu01,xvda,w']<br />
</pre><br />
<br />
Modify the mac address to be unique.<br />
<br />
Then find a line in "ubuntu01.cfg" that says "bootloader=pygrub" and add proper path ("/usr/bin/pygrub") to it:<br />
<br />
<br />
<pre><br />
if not xm_vars.env.get('install'):<br />
bootloader="/usr/bin/pygrub"<br />
else:<br />
</pre><br />
<br />
Already modified configuration file is available as a reference from: http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu01.cfg .<br />
<br />
Then start the Ubuntu installer:<br />
<br />
<br />
<pre><br />
xm create -f ubuntu01.cfg -c install=true<br />
install-kernel="http://fi.archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/xen/vmlinuz"<br />
install-ramdisk="http://fi.archive.ubuntu.com/ubuntu/dists/lucid/main/installer-amd64/current/images/netboot/xen/initrd.gz"<br />
install-mirror="http://fi.archive.ubuntu.com/ubuntu"<br />
</pre><br />
<br />
All of the above command needs to be on a single line. Replace the mirror site URLs with your local mirror.<br />
<br />
Ubuntu 10.04 text installer starts:<br />
<br />
http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu01.png<br />
<br />
Install as usual. Choose DHCP for networking.<br />
<br />
http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu02.png<br />
<br />
http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu03.png<br />
<br />
http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu04.png<br />
<br />
http://pasik.reaktio.net/fedora/f13xen4tutorial/ubuntu05.png<br />
<br />
When the installation finishes the Ubuntu guest VM will shut down.<br />
<br />
After installation you can start the Ubuntu guest like this:<br />
<br />
<br />
<pre><br />
xm create -f ubuntu01.cfg -c<br />
</pre><br />
<br />
First you'll see the pygrub menu which allows you to choose which Ubuntu kernel to boot, and then you'll get to the normal Xen PV guest text console and see the Ubuntu kernel booting. You can exit from the console by pressing ctrl+] or ctrl+5.<br />
[[Category:Beginners]]<br />
[[Category:Tutorial]]<br />
[[Category:Ubuntu]]<br />
[[Category:Guest Install]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Ubuntu_10.04_domU&diff=5120Ubuntu 10.04 domU2012-09-24T15:27:36Z<p>OliverChick: Blanked the page</p>
<hr />
<div></div>OliverChickhttps://wiki.xenproject.org/index.php?title=Asking_Xen_User_Questions&diff=5119Asking Xen User Questions2012-09-24T15:22:05Z<p>OliverChick: /* Performance Questions */</p>
<hr />
<div><!-- MoinMoin name: XenUsersQuestions --><br />
<!-- Comment: replace stephen.spector with community.manager@xen.org --><br />
<!-- WikiMedia name: XenUsersQuestions --><br />
<!-- Page revision: 00000007 --><br />
<!-- Original date: Tue Jan 25 16:12:06 2011 (1295971926000000) --><br />
<!-- ## Please edit system and help pages ONLY in the moinmaster wiki! For more --><br />
<!-- ## information, please see [[MoinMaster]]:[[MoinPagesEditorGroup]]. --><br />
<!-- ##master-page:[[HomepageReadWritePageTemplate]] --><br />
<!-- ##master-date:Unknown-Date --><br />
<!-- #format wiki --><br />
<!-- #language en --><br />
<br />
{{Needs_Refactor|Needs splitting and moving into the smaller FAQs on [[:Category:FAQ]]}}<br />
<br />
= Xen Users Mailing List Commonly Asked Questions =<br />
<br />
== Introduction ==<br />
This document is a Xen.org community effort to gather the most commonly asked questions from the xen-users emailing list and other support tools to assist new and experienced Xen hypervisor users with problems that frequently arise. If you would like to add content to this document, please send an email to community.manager@xen.org for editing rights if you don't have wiki editing rights already. <br />
For those users interested in trying Xen without installing the application, a Live CD version is available at http://wiki.xensource.com/xenwiki/LiveCD. <br />
<br />
== Support Tools ==<br />
The following sites are available for Xen hypervisor support:<br />
* xen-users mailing list - http://lists.xensource.com/mailman/listinfo/xen-users<br />
* Xen 3.3 Documentation - http://bits.xensource.com/Xen/docs/user.pdf <br />
* Stack Oveflow - http://stackoverflow.com/<br />
* Complete email history of all xen mailing lists - http://xen.markmail.org <br />
* Language Specific Support<br />
** Japanese - http://lists.xensource.com/mailman/listinfo/xen-japanese<br />
** Portuguese - http://groups.google.com/group/xen-br<br />
<br />
== How To Guide Links ==<br />
The Xen.org community Wiki has a [[HowTo]] Page with various information sources at http://wiki.xensource.com/xenwiki/HowTos. Updates to this Wiki page are continuous so check back often for new How Tos. <br />
Sample topics internally within the Wiki are:<br />
* [[XenNetworking| Xen Networking]]<br />
* [[FreeBSDdomU| Xen FreeBSD]]<br />
<br />
Sample topics with external links are:<br />
* Adding USB Devices to Xen HVM - http://www.virtuatopia.com/index.php <br />
* Xen on Fedora - http://rackerhacker.com/2011/08/05/xen-4-1-on-fedora-15-with-linux-3-0/ <br />
* Create and Install CentOS on Xen - http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU <br />
* http://www.virtuatopia.com/index.php/Configuring_a_VNC_based_Graphical_Console_for_a_Xen_Paravirtualized_domainU_Guest<br />
* https://help.ubuntu.com/community/Xen Xen on Ubuntu<br />
<br />
== Guest Related Questions ==<br />
=== Guest Conversion ===<br />
Q (G1.0): How do I convert a Centos HVM Guest to a PV Guest?<br />
<br />
A (G1.0): Creating a Centos HVM domU with working PV drivers : http://pastebin.com/fb6fe631 Converting HVM guest to PV guest : http://pastebin.com/f6a5022bf <br />
If you follow both parts correctly you should have a working PV domU. If anything goes wrong during conversion process, you should still be able to boot the previous HVM domU config if you select the non-xen kernel (second entry) from grub menu.list. <br />
=== Console ===<br />
<br />
Q (G2.0): I have an Xen image that was built for a graphical console (VNC). Is there any way to change it to the non-graphical console (xen console)? <br />
<br />
A (G2.0): For HVM guest, you need to enable serial port on domU config file (example here: http://pastebin.com/fb6fe631), and setup domU to use serial port (ttyS0 on Linux) by modifying (for Linux domU) /boot/grub/menu.lst, /etc/inittab, and /etc/securetty. <br />
If it's PV guest, you need to set up domU to use xen console (which is xvc0 on current xen version, hvc0 on pv_ops kernel). It's similar to setting up domU for serial console, you just need to change ttyS0 to hvc0. An example of domU setup that can use both xvc0 and vnc console is here : http://pastebin.com/f6a5022bf <br />
<br />
Q (G2.1): How do I remove an active virtual machine?<br />
<br />
A (G2.1): xl shutdown or xl delete<br />
<br />
Q (G2.2): How do I run xl console to a WindowsXP DomU?<br />
<br />
A (G2.2): You can't xl console to that (I'm not sure you can xl console to any hvm, but I know you can't to one that doesn't have a console). <br />
<br />
Q (G2.3): I start a new DomainU (Guest) and some text scrolls by for launching the guest but then it just sits there with Continue and no actions takes place? <br />
<br />
A (G2.3): The console for this new DomainU is not properly available for you; fix this by adding xtra="xencons=tty" in the configuration file. This will bring up a login screen directly for your new DomainU. <br />
<br />
Q (G2.4): One of our CentOS 5.3 randomly reboots, at different times of the day, and I can't see why it's doing it. I have looked through the logs, but don't see any thing in there that shows me why it has rebooted. How can I debug this? <br />
<br />
A (G2.4): The problem is that when the box panics, it stops syslogd, so you don't get the panic output in /var/log. The best way to fix this is to setup a logging serial console. <br />
<br />
Q (G2.5): Hi, i want to stop VMs, but when i execute xl destroy vmname the VM disappears completly from mu vm list (xl list) How can I stop them without delete them? <br />
<br />
A (G2.5): You've probably been using "xl create". That's the way it works.<br />
<br />
=== Drivers ===<br />
Q (G3.0): What are the GPLPV Drivers and where can I get them?<br />
<br />
A (G3.0): A collection of open source Window PV drivers that allow Windows to be para-virtualized. They are currently being implemented under the leadership of James Harper. More information on these drivers at:<br />
* http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing<br />
* http://lists.xensource.com/archives/html/xen-users/2009-04/msg00058.html<br />
* http://meadowcourt.org/downloads/<br />
<br />
Q (G3.1): How can I tell if the GPLPV Drivers are loaded correctly?<br />
<br />
A(G3.1): If the drivers are installed correctly there should be a Xen device under 'System Devices' in device manager. <br />
<br />
=== Domain0 ===<br />
Q (G4.0): Why cannot I see all my RAM on my Dom0?<br />
<br />
A (G4.0): Domain 0 is a paravirt VM in reality, so the amount of ram you allocate to it is what you will see when using local tools like free, /proc/meminfo, top, etc. <br />
To see the full system ram, you need to use the xm tools... and in this case, 'xm info' which will show you all the system resources, as opposed to the resources available to dom0. <br />
Also, you have 16GB ram on the system... you probably already know this, but be aware that without a PAE enabled kernel (if you're using 32bit Xen) you'll only see 4GB of this. PAE will allow you to use up to 16, or maybe 32 (I don't remember what the upper limit for PAE enabled Xen is off the top of my head). <br />
<br />
Q (G4.1): Is there any way of checking DomU´s I/O from Dom0? <br />
<br />
A (G4.1): iostat (Debian: sysstat-package) <br />
<br />
Q (G4.2): Can I allocate one CPU to the Dom0 exclusively? <br />
<br />
A (G4.2): Add this to the kernel boot line <br />
* dom0_max_vcpus=1 & dom0_vcpus_pin <br />
* Edit /etc/xen/xend-config.sxp - set “(dom0-cpus 1)†<br />
* Reboot Dom0 <br />
* To try on an active system without a Reboot - <br />
* xm vcpu-set 0 1 xm vcpu-pin 0 0 0 <br />
<br />
Q (G4.3): Running xm info I see the following memory available; what does the free memory mean?<br />
total_memory : 2046 free_memory : 5 <br />
<br />
A (G4.3): Free_memory from "xm info" shows memory not allocated to any domain (inlcuding dom0). "free", "top" (or whatever) shows free memory on that particular domain (in your case, dom0). You can adjust memory allocation per domain using "xm mem-set". <br />
<br />
=== DomainU ===<br />
Q (G5.0): My DomU does not fully start; it shows the following output stopping at Continue...<br />
<br />
$ sudo xm console test<br />
<br />
io scheduler cfq registered<br />
<br />
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize<br />
<br />
Xen virtual console successfully installed as xvc0 Event-channel device installed. netfront: Initialising virtual ethernet driver. i8042.c: No controller found. mice: PS/2 mouse device common for all mice TCP bic registered NET: Registered protocol family 1 <br />
<br />
NET: Registered protocol family 17<br />
<br />
Using IPI No-Shortcut mode xen-vbd: registered block device major 8 blkfront: sda2: barriers enabled XENBUS: Device with no driver: device/console/0 Freeing unused kernel memory: 140k freed kjournald starting. Commit interval 5 seconds <br />
<br />
EXT3-fs: mounted filesystem with ordered data mode.<br />
<br />
* ************************************************************** <br />
* **************************************************************<br />
* * WARNING: Currently emulating unsupported memory accesses **<br />
* * in /lib/tls glibc libraries. The emulation is **<br />
* * slow. To ensure full performance you should **<br />
* * install a 'xen-friendly' (nosegneg) version of **<br />
* * the library, or disable tls support by executing **<br />
* * the following as root: **<br />
* * mv /lib/tls /lib/tls.disabled **<br />
* * Offending process: modprobe (pid=663) **<br />
* **************************************************************<br />
* **************************************************************<br />
Continuing... <br />
<br />
A (G5.0): It might only be that you don't have a VPS physical console, and that your VPS is fully booted, but you can't see it. There are few things to check.<br />
<br />
First, check that your VPS has a "console" device in /dev. Mount your domU filesystem in the dom0, go in /dev and do:<br />
<br />
/dev/MAKEDEV console<br />
<br />
If you are using a modern Xen kernel and hypervisor, you should check the parameters of the startup file. Check that it has the following option:<br />
<br />
extra = "4 TERM=xterm xencons=tty console=tty1"<br />
<br />
Then start your VPS and watch it booting. Note that once it's booted up, you should check that it has a xen friendly libc6 installed (in Debian, you would do "apt-get install libc6-xen").<br />
<br />
Q (G5.1): is there a way to set the credit-scheduler's limits and weights per domU<br />
in the domU configuration file? <br />
<br />
A (G5.1): weight= in the xm config file works, unless you are using RHEL or CentOS. <br />
<br />
Q (G5.2): How do I start an application from within a DomU?<br />
<br />
A (G5.2): Well, you could always just log in to that VM, open a terminal and run the program. <br />
Or you could SSH or telnet in to the VM, start a screen session and run the program. <br />
A VM acts just like any other server, so the proceedure for starting programs and executing commands locally and remotely are exactly the same as doing so on any computer. <br />
<br />
Q (G5.3): My domUs are in a permanent 'b' (blocked) status as shown by 'xm list', even though they are functioning just fine. That's not normal, is it? <br />
<br />
A (G5.3): It's normal for them to show as blocked when they aren't actively running something - in the same way that any process on a 'normal' machine will show as blocked when it's waiting for input, each guest will show as blocked when it's got nothing to do. Give something a processor intensive task to do and you'll find it changes state to running (at least some of the time). <br />
<br />
Q (G5.4): Is there any way, to get the name of a domU from the network-common script? <br />
<br />
A (G5.4): hostname=$(xenstore_read "$XENBUS_PATH/domain" | tr -- '_.:/+' '-----') <br />
<br />
Q (G5.5): Is it possible to increase the screen resolution of my xen guest Windows Vista? <br />
<br />
A (G5.5): On current Xen, with stdvga=1 & videoram=16, resolutions up to 2048x1536x32 are possible. All that said, the RDP suggestion is probably a better way to access the guest in any case. <br />
<br />
Q (G5.6): How to install Solaris via HTTP as a para guest? <br />
<br />
A (G5.6): Solaris 10 can only be used as HVM guest. [[OpenSolaris]] can be used as PV guest, installed from iso. You can't install it from http. Once you have it installed, you also need zfs support for pygrub (either that, or manually copying kernel and boot archive to dom0) <br />
<br />
Boris provides some nice examples on his site : http://bderzhavets.wordpress.com/ <br />
<br />
Q (G5.7): Is it possible to find out the specific vnc Display Number of a domU? <br />
<br />
A (G5.7): virsh vncdisplay domU_name_or_id <br />
xenstore-ls /local/domain/domU_id/console <br />
<br />
Q (G5.8): I am trying to create a guest domain. I specified the configurations in /etc/xen-tools/xen-tools.conf and I ran $sudo xen-create-image --hostname=virtualrouter1 --role=udev the output is: sudo: xen-create-image: command not found <br />
<br />
A (G5.8): Make sure you installed the Xen tools, for example: apt-get install xen-tools <br />
<br />
Q(G5.9): I'm trying to assign a dynamic hostname to a xen instance as follows: <br />
<br />
Cfg file <br />
kernel = "/root/vmlinuz-2.6.18-128.1.14.el5xen" <br />
ramdisk = "/root/initrd-2.6.18-128.1.14.el5xen.img" <br />
memory = 512 <br />
hostname = "uniquehostname" <br />
<!-- #hostname = " uniquehostname.xen.org" --><br />
name = "my-vm-name" <br />
* . . . . <br />
In both the cases, the instance is unable to get the correct hostname.. <br />
<br />
A (G5.9): From "xm create --help_config" : hostname=NAME Set the kernel IP hostname. interface=INTF Set the kernel IP interface name. dhcp=off|dhcp Set the kernel dhcp option. <br />
On most LInux distros, kernel hostname and IP address is ignored, making it somewhat useless. You need to use your normal distro method to set hostname on domU (/etc/sysconfig/network on RHEL) <br />
<br />
Q(G5.10): As far as I can see, there is something different between using 'xm create' and 'xm new' followed by 'xm start'. It's something to do with data being stored in [[XenStore]]. I couldn't suspend the one started with 'xm create'. Could someone please explain the effective difference between the two and when 'create' should be used instead of 'new' and vice-versa. <br />
<br />
A(G5.10): xm create -> domU configuration is NOT managed by xend. Usually using config files on /etc/xen. This is the easiest method to use for beginners, as you have a config file that you can edit manually. The default on RHEL5 (which uses Xen 3.1+). <br />
"xm new" and "xm start" -> domU configuration is managed by xend. You change values using commands like "xm block-attach", which can modify settings online. No config file to edit manually. The default on current versions of Xen. <br />
<br />
G (G5.11): I have problem with domU clock. It lose 30 minutes each day. How can i synchronize it with dom0 clock? <br />
<br />
A (G5.11): Is this PV domU? If yes, setting /proc/sys/xen/independent_wallclock to 0 (the default) should make it sync with dom0. You only need ntp on dom0, and domUs will follow. <br />
The alternative, set /proc/sys/xen/independent_wallclock to 1 and run ntp on domU. If this is a HVM dom0, running ntp on domU is your friend. <br />
Also, check<br />
http://tuttodebian.blogspot.com/2008/05/xen-clocksource0-time-went-backwards.html to see if your system experience similar symptoms. <br />
<br />
G (G5.12): I would like to set sched-cred parameters on my domU configuration file. How can i do that? <br />
<br />
A (G5.12): cpu_cap & cpu_weight <br />
Run "xm create --help_config" for details, and read http://wiki.xensource.com/xenwiki/CreditScheduler <br />
<br />
G (G5.13): Is it possible to increase guest memory without reboot? <br />
<br />
A (G5.13): You can do a "xm mem-set <Domain> <memory>" for a PV domU, but you had to set maxmem higher than current assignment beforehand. <br />
<br />
G (G5.14): Is it possible to take an already created domU sparse file and make it a non sparse file? <br />
<br />
A (G5.14): cp --sparse=never orig.img new.img <br />
<br />
G (G5.15): I have tried to change CD ISO images during a HVM install using the following commands but it doesn't work. After changing the CD ISO image, it doesn't detect the new ISO image. <br />
(qemu) eject -f hdc (qemu) change hdc /media/hitachi/cd-rom-image.iso <br />
<br />
A (G5.15): Use xm block-list <domid> to find the cdrom be-path for the domain, for example: <br />
xm block-list 5 Vdev BE handle state evt-ch ring-ref BE-path 768 0 0 4 9 16383 /local/domain/0/backend/vbd/5/768 5632 0 0 1 -1 -1 /local/domain/0/backend/vbd/5/5632 <br />
Having identified the cdrom device (5632) you can check what iso image it is connected to: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params <br />
(nothing returned) <br />
To connect a new iso image: <br />
xenstore-write /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
And you can now see that it is connected: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
This method works with both emulated devices and with gplpv drivers. <br />
<br />
Q (G5.16): Is it possible to set the xen to boot the domU one by one when server starts, as currently we have 20 domU, and if boot them together, the the hard disk will be very very slow. <br />
<br />
A (G5.16): cd /etc/xen/config/........ && for i in * do ...... (start VM, .....)...... sleep 60 (or whatever time you think <br />
is right to start a VM) done <br />
<br />
Q (G5.17): I use FluidVM on some of our VPS host nodes, and the management server<br />
has crashed, so now I need to recover the running VM's, somehow. FluidVM deploys the domU's on the hostnode dynamically from a database, i.e. there's no /etc/xen/vps1 (for example) config files. The domU's are still running on the servers, and I now want to create config files for them, while they're running.<br />
<br />
How would I be able todo this?<br />
<br />
For example, here's a list of running VM's from one of the servers:<br />
<br />
root@usaxen02:[~]$ xm list<br />
Name ID Mem(MiB) VCPUs State Time(s)<br />
AndriesBurger_39_cronos 90 255 1 -b---- 42.4<br />
Bruce_18_carmen 60 255 1 r----- 3528327.5<br />
Domain-0 0 3433 4 r----- 1116681.7<br />
Rudi_14_mars 40 3007 2 -b---- 953036.3<br />
Rudi_44_vps2 93 255 1 -b---- 22.9<br />
<br />
Is there any way to create a config file, /etc/xen/AndriesBurger_39_cronos, from the running domU<br />
AndriesBurger_39_cronos ?<br />
<br />
A (G5.17):You can use "xm list -l" to dump the configuration in SXP format; then you should be able to use "xm new" or "xm create" with the "-F" option to load an SXP-based config file. See the "xm" man page for more info - that's where I dug up this.<br />
<br />
Q (G5.18): How to set up Xen DomU as Windows 2008 Server on a CentOS Dom0 machine?<br />
<br />
A (G5.18): Start using the normal way that you usually do when you install a HVM domU, whether it's virt-manager/virt-install or using manually-created config file. One additional thing to note is that for 64bit HVM domUs you need to make sure that acpi, apic, and pae is set to 1 on domU config file. <br />
Once you get that Win2008 fully installed, you can install GPLPV driver later to improve performance.<br />
<br />
Q (G5.19): I need to install windows streaming media server on one of my xen3.4.2 guest. Is it possible to create a windows xp paravirtual guest on xen? Like I install other Linux guest as the paravirtual ones. If yes please give some brief steps for that. <br />
<br />
A (G5.19): No, unless you ask Microsoft to port XP kernel to Xen PV model:)<br />
<br />
Judging from the fact that XP was declared end of life several times, and the fact that even Hyper-V requires VT to run, I highly doubt they will ever create PV-enabled windows <br />
<br />
Q (G5.20): I would like to move an existing [[W2K3]] install onto my new super duper xen box -- Installing linux based machine is no issue, it's the windows ones that keep getting me. I have Acronis which we usually use for bare metal restores, and it seems that bare metal restores don't want to work too well with XEN, any assistance/help/ideas ? <br />
<br />
A (G5.20): I have successfully migrated several physical windows 2003 installs to Xen by adding the ide drivers as per http://support.microsoft.com/kb/314082 and then using Acronis True Image to copy the disks.<br />
<br />
One issue I had was that the boot cd created by the version of True Image we have did not boot under Xen (hung on boot screen), but Acronis support sent me a version that did work (TrueImageLinuxServer8072_multiparam_Standard_english_il.iso). However due to using emulated nic and hd running True Image directly under Xen was very slow, my first solution to that problem was to make a small windows hvm install with gplpv drivers loaded and true image installed and then temporarily add the target block device to it in order to write the image, but I recently switched to using a WinPE boot ISO with GPLPV and [[TrueImage]]/Backup And Recovery installed, the Acronis products come with a WinPE/BartPE Image builder utility so its quite easy to do.<br />
<br />
Also watch out for boot.ini, many servers come with a hidden partition on the boot volume for running diagnostics, in which case windows may be booting from the second partition, so you may need to adjust the boot.ini or you could remove it entirely and windows will then attempt to boot from \windows automatically. <br />
<br />
Q (G5.21): Could we add a file image, block device or lvm to domU while it is running without restarting?<br />
<br />
A (G5.21): Use "xm block-attach", and edit domU config file afterwards (if you still you file-based domU config) to make it permanent. Should work great with PV domUs.<br />
<br />
There are cases when you have to reboot the domU anyway though, since the driver installation of a new disk on domU OS could require reboot. One example is when using Windows + GPLPV.<br />
<br />
=== Devices ===<br />
<br />
Q (G6.0): For my xen domUs I'm using a mixture of locah physical partitions (with LVM) and iSCSI disks. For local partitions, I don't have any problem, because LVM volumes are always the same. But for iSCSI disks, devices are assigned in the order they are connected, so I can't be sured that device that now is /dev/sdb (for example) will always be /dev/sdb. <br />
So, is there any way to identify the physical device in the domU configuration not as phy:/dev/sdb, but something like phy:label=fslabel? Or is there any other solution to this problem? <br />
<br />
A (G6.0): I go with phy:/dev/disk/by-path/ip-*-iscsi-iqn.* If you assign iscsi luns directly as domU's fs without additional partitioning, you could probably also use /dev/disk/by-label/* or /dev/disk/by-uuid/*<br />
<br />
== Installation Questions ==<br />
<br />
See [[Xen_FAQ_Installation]]<br />
<br />
=== 32bit vs 64 bit ===<br />
<br />
Q (I2.1): Is there anyway to install 64Bit Linux DomU on 32Bit Linux Dom0? <br />
<br />
A (I2.1): Types of domU that can be run depends mostly on hypervisor, and not dom0. So if you have 64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit. <br />
If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not 64bit PV domU. <br />
<br />
== Networking Questions ==<br />
<br />
=== Bridging ===<br />
<br />
Q (N1.0): Which Mechanism is used by Xen bridging to handle packets coming from various VMs to forward them to their destination <br />
<br />
A (N1.0): Nothing. Xen by itself does not handle bridge. dom0 OS does that. <br />
On Linux dom0 : http://www.linuxfoundation.org/en/Net:Bridge <br />
On opensolaris dom0: http://opensolaris.org/os/project/crossbow/ <br />
IP Determination<br />
<br />
Q (N2.0): I want to know the IP of a running VM in XEN.. Is there any way to have this without login to that VM.. <br />
<br />
A (N2.0): Find domU's mac. This can be easy (if your domU config specify a static MAC).<br />
The easy way to get domU's IP address, you can look at domUs config file (if you specify it), or you can try running this:<br />
xm network-list domU_name <br />
if you get this line <br />
Idx BE MAC Addr. handle state evt-ch tx-/rx-ring-ref BE-path 0 0 00:16:3E:F7:D6:E7 0 4 6 16238/16237 /local/domain/0/backend/vif/163/0 <br />
Then domU's MAC is 00:16:3E:F7:D6:E7 <br />
The hard way to find out your MAC from a bridge, since your bridge is called eth0 you can try: <br />
xm list, note the domain ID (the number) <br />
- brctl showstp eth0 that should show which interface is identified as which "port". For example if your domU has an ID 163, look for the lines that has "vif163.0" or "tap163.0". If the line looks like this <br />
vif163.0 (11) <br />
then that vif is identified as port 11 on the bridge. <br />
- brctl showmacs eth0 Look for the port corresponding to the port above. If you get this line <br />
11 00:16:3e:f7:d6:e7 no 0.96 <br />
then on port11 (where your domU interface is) there's a MAC address 00:16:3e:f7:d6:e7. <br />
Now that you have domU's mac, you try snooping the bridge for that MAC. For example : <br />
# tcpdump -n -i eth0 ether src 00:16:3e:f7:d6:e7 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:54:56.419482 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 1, length 64 15:54:57.422349 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 2, length 64 <br />
Then you know that domU has IP address 10.0.0.10. <br />
NAT<br />
<br />
Q (N3.0): I managed to configure NAT on dom0 but this does not work properly. Outgoing traffic from domU is seen with the original domU ip address instead of the dom0 ip address and the requests can't get back to the domU. <br />
<br />
A (N3.0): I figured out MASQUERADING was not set. <br />
The following rule needs to be set: <br />
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE <br />
<br />
SSL/VPN<br />
<br />
Q (N4.0): Way can't i use openvpn with a xen guest I can't load the tun module <br />
<br />
A (N4.0): From openvpn perspective, the requirements for openvpn on xen domU is the same as openvpn on native Linux. If you can't load tun module, then you need to get a kernel that supports it. <br />
The easiest way is to use a distro that supports it. For example, I'm using RHEL/Centos 5.3 domU, loaded with pygrub, and they can run openvpn just fine. <br />
Another alternative is compile your own kernel with tun/tap support. <br />
<br />
=== General ===<br />
<br />
Q (N5.0): I want to ask how to mount one storage device to 2 guests? When I try to create vm handle everything is fine I can create one vdi and vbds for every guest. When I start first machine everything is ok, but when I try to start second one it says that<br />
<br />
ERROR: 2 INTERNAL_ERROR Device 2051 (vbd) could not be connected.<br />
Device /dev/mapper/test_vg-test64_454 is mounted in a guest domain,<br />
and so cannot be mounted now.<br />
<br />
Ideas how I can share one device to two or more virtual machines? I don't want network solution like nfs,iscsi ... etc but instead use ocfs2. How I can set mode to w! ? <br />
<br />
A (N5.0): First of all, you DO realize that sharing a block device without some kind of cluster file system could lead to data corruption? If you want to share it anyway, you can try changing the mode to "r"(for read only) or "w!" (to force read-write multiple mount). <br />
in your domU.cfg:<br />
<br />
'phy:/dev/data/bla-disk,sda1,w' => 'phy:/dev/data/bla-disk,sda1,r'<br />
<br />
Q (N5.1): I'm looking for a way to monitor network activities of processes in Guest OS. I want to get a list of Guest OS processes that open TCP connections to other machines (like "lsof" command). <br />
<br />
A (N5.1): If you're thinking about doing on from dom0, that's not possible. You need something that runs on domU for that, possibly by using snmpd and extending it to run "netstat -anp --tcp". Other host (including dom0) can then collect the information using snmp. <br />
Also, have a look at Versiera, it provides what you are looking for including, user<br />
IDs, inbound/outbound communications, IPv4, IPV6, etc. There are many more<br />
capabilities. Versiera is not open-source, but the Internet self-manage service<br />
is free. <br />
<br />
Q (N5.2): I’m attempting to gather stats on usage of the “metalâ€, by which I mean the physical host’s hardware. I would like to know the CPU, IO, and network stats for the hardware. <br />
<br />
A (N5.2): All DomU's IO passes through Dom0. there you can measure all you want. <br />
for disk IO, if you use phy: devices, you can use iostat to see the usage of each device. if you use file-based backends, it would be easier to check the userspace daemons. maybe iotop would help. in any case, if aggregate usage is all you need, just measure the disk usage seen at Dom0 <br />
for network, if you can measure at peth0, that would give you the aggregate usage. if you need stats for each DomU, check the respective tun devices. <br />
<br />
Q (N5.3): I have some trouble finding the best solution to my networking requirements. <br />
I want to have the following things: <br />
-dom0 : have 2 physical networks devices * 1 eth with public IP (static) * 1 eth with private IP (static) <br />
-domU * 1 eth with private IP <br />
-I also want openVPN solution to let people outside the private network have access to it. <br />
-A DHCP server is required so that domU get their IP from it. <br />
I have debian lenny and xen 3.2 installed and working. Actually openvpn and dhcp are on the dom0. All is fine *except* that domU don't have access to internet (this is my main problem). My current config use network-bridge netdev=eth1 (eth1 have a static private ip). <br />
It is perhaps better to have dhcp and openvpn server in a domU, feel free to suggest what you think is the best choice (and the config that go with it) :) <br />
<br />
A (N5.3): When designing such setups, with bridge networking, I often find it easier to think of dom0 as a switch or router, and domU like any other physical server on your network. <br />
In your setup you're making dom0 act as router/firewall. Your problem is that probably you haven't setup ip forwarding and NAT on dom0 to allow domU internet access. <br />
Note that (if you want) you could also have dom0 act like a switch. In that scenario you'd need another domU, with two network interfaces connected to both dom0's eth0 and eth1, acting as router/firewall. <br />
<br />
Q (N5.4): I have been trying to get a HVM DomU running and being able to connect to a vlan. I am starting to get the feeling that at least the hw emulations I have tried do not supoprt vlans. Also all the things I have found online would have me creating the vlans inside the Dom0 and pushing them to the DomU's as regular interface<br />
<br />
A (N5.4): You could always have a trunk port in your dom0 and create bridges for each VLAN for xen. <br />
You can even script it so you can add it to boot time. <br />
If you have the VLAN trunk set up, you can create bridges as follows. <br />
For this example, my trunk interface is on eth0 and the vlan I am adding is 2. <br />
<!-- # vconfig add eth0 2 # brctl addbr xenbr2 # brctl addif xenbr2 eth0.2 # ifconfig eth0.2 up # ifconfig xenbr2 up --><br />
Now all you would add in the domU configuration file is: <br />
vif=['bridge=xenbr2'] <br />
And you would be on VLAN 2. <br />
Otherwise I'm pretty sure you would have to pass through the network card to get VLAN access. <br />
You can also script this and give it a space separated list of VLANs and loop it through. I will leave this up to you though. <br />
<br />
== High Availability Questions ==<br />
=== Services ===<br />
<br />
*Q) What software exists for Xen to handle high availability? <br />
*A): Project Remus is supplied with Xen. http://blog.xen.org/index.php/2009/04/02/project-remus-released/<br />
<br />
*Q) How can I use LVM snapshots with Xen?<br />
*A): You could try this http://www.infohit.net/blog/post/using-lvm2-snapshots-to-provide-rollback-functionality-for-xen.html<br />
<br />
== Security Questions ==<br />
<br />
Q(S1.0): If I install minimal linux for XEN in dom0 and a periphery firewall in domU and other applications in other instances of domU, is it possible to restrict/bind the network card to domU having periphery firewall and from there forward packets for dom0 or for other domUs? <br />
Is this possible? If so, is it secure? Or does dom0 always have direct access to Network Card and needs a separate firewall? And packets will always route from dom0 to all domUs ? <br />
What are the issues involved? <br />
<br />
A(S1.0): The approach I've used at home is to hide a network card from Dom0 (see pic-back.hide) and pass it through to a DomU which then sees it as a native interface. I then run a firewall in the DomU and the outside traffic does NOT go through Dom0. The route for packets is then : <br />
real i/f -> DomU (firewall) -> VIF -> int bridge [ Dom0 | VIF -> DomU ] <br />
From security perspective, this is the same as having an L2 switch (when dom0's bridges have no IP address) or L3 switch (when dom0's bridges have an IP address) <br />
<br />
Q(S1.1): I want to use a Disk Encryption and the conplete physikal Disk in a DomU. I prefere Truecrypt or Loop-aes. i will going to test loop-aes cause it should have the better performance. <br />
But, did anybody here using truecrypt or loop-aes ? What is the better one, in the fact of speed ? <br />
<br />
A(S1.1): dm-crypt/luks is one option, and performs about the same or better than loop-aes. Also it's less problematic because it doesn't use loop devic<br />
<br />
== Design/Misc Questions ==<br />
=== Nested Xen ===<br />
Q (D1.0): Can I run Xen within Xen? <br />
<br />
A (D1.0): Yes, You can install Xen on the base system, create a HVM domain, and install Xen in that guest domain. Note that the inner Xen system will not (yet) support HVM again.<br />
<br />
=== How does Xen Work ===<br />
<br />
Q (D3.0): How does Xen process System Calls on para-virtualized guest?<br />
<br />
A (D3.0): When ever a system call is invoked via interrupt or sys center control gets transferred to the kernel (ring 0), which is then handled via system call handler. System call never goes to libc but Libc is a library that provides POSIX interface to the user space applications and in a way wrapper for invocation of a system call. <br />
System call interrupt based [i386]: During booting process, linux kernel of a domU register's its IDT with Xen Hypervisor via HYPERVISOR_set_trap_table(trap_table); [arch/i386/kernel/traps-xen.c]. Xen maintains two IDT's, one global IDT (its own) and other per domain IDT. Xen uses global IDT to register the entire trap handler except for system call handler (int 0x80). When a VM gets scheduled, its system call handler (from per domain IDT table) is registered with the processor. Hence when a domain/VM executes a system call, its own handler is executed. <br />
Implementation differs for x86_64: Xen registers its own system call handler with the processor and from that handler routes the request to VM/Domain specific handler. <br />
<br />
Q (D3.1): How does Xen process System Calls on fully virtualized guest (HVM)?<br />
<br />
A (D3.1): For HVM domU there is no change in the behavior of the system call. HVM is only supported for Intel-VT and AMD-SVM processors. These processors are virtualization aware. Virtualization aware processors provide a new ring (Root-Ring 0) with higher privilege for VMM and Guest OS continues to runs with the same privilege (as without Xen) in Non-Root Ring 0. Guest OS can issue the system calls the way it used to without Xen.<br />
<br />
Q (D3.2): Can I run various DomU operating systems on a different Dom0 operating system?<br />
<br />
A (D3.2): Yes. <br />
<br />
Q (D3.3): Just curious to know, if there is any way that given a terminal to a box, we can determine is it a physical machine or a virtual machine ? <br />
<br />
A (D3.3): You should be able to get some useful information from the DMI, e.g: <br />
% for i in system-manufacturer system-product-name system-version\ system-serial-number; do echo -n "$i: "; sudo dmidecode -s $i; done <br />
system-manufacturer: Xen system-product-name: HVM domU system-version: 3.3.1 system-serial-number: 89e5915f-dead-beef-cefd-46904ea94c4a <br />
OR<br />
Probably checking kernel process, check your process table for: <br />
[xenwatch] [xenbus] <br />
Another clue is checking the kernle suffix, for example: <br />
<!-- # uname -r 2.6.24-23-xen --><br />
and the proc files: <br />
/proc/xen/capabilities <br />
<br />
Q (D3.4): What is STUBDOM ? <br />
<br />
A (D3.4): Stubdoms are lightweight 'service' or 'driver' domains. The initial purpose was to offload qemu (for hvm guests) out of dom0. <br />
So with stubdoms you can run hvm guest qemu in a separate stubdom, which boosts performance and makes it more secure. <br />
stubdoms can also run for example pv-grub for pv guests, making it more secure compared to pygrub, which always runs in dom0. <br />
http://wiki.xensource.com/xenwiki/StubDom <br />
Presentation about stubdoms at Xen Summit: http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf <br />
http://blog.xen.org/index.php/2008/08/28/xen-33-feature-stub-domains/ http://blog.xen.org/index.php/2008/08/28/xen-33-feature-hvm-device-model-domain/ http://lxr.xensource.com/lxr/source/stubdom/README <br />
<br />
Q (D3.5): When is hardware virtualization used in Xen? Is it required?<br />
<br />
A (D3.5): Xen uses hardware virtualization for HVM guests. Xen will not launch a HVM guest unless hardware virtualization is turned on.<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Asking_Xen_User_Questions&diff=5118Asking Xen User Questions2012-09-24T15:21:30Z<p>OliverChick: /* Services */</p>
<hr />
<div><!-- MoinMoin name: XenUsersQuestions --><br />
<!-- Comment: replace stephen.spector with community.manager@xen.org --><br />
<!-- WikiMedia name: XenUsersQuestions --><br />
<!-- Page revision: 00000007 --><br />
<!-- Original date: Tue Jan 25 16:12:06 2011 (1295971926000000) --><br />
<!-- ## Please edit system and help pages ONLY in the moinmaster wiki! For more --><br />
<!-- ## information, please see [[MoinMaster]]:[[MoinPagesEditorGroup]]. --><br />
<!-- ##master-page:[[HomepageReadWritePageTemplate]] --><br />
<!-- ##master-date:Unknown-Date --><br />
<!-- #format wiki --><br />
<!-- #language en --><br />
<br />
{{Needs_Refactor|Needs splitting and moving into the smaller FAQs on [[:Category:FAQ]]}}<br />
<br />
= Xen Users Mailing List Commonly Asked Questions =<br />
<br />
== Introduction ==<br />
This document is a Xen.org community effort to gather the most commonly asked questions from the xen-users emailing list and other support tools to assist new and experienced Xen hypervisor users with problems that frequently arise. If you would like to add content to this document, please send an email to community.manager@xen.org for editing rights if you don't have wiki editing rights already. <br />
For those users interested in trying Xen without installing the application, a Live CD version is available at http://wiki.xensource.com/xenwiki/LiveCD. <br />
<br />
== Support Tools ==<br />
The following sites are available for Xen hypervisor support:<br />
* xen-users mailing list - http://lists.xensource.com/mailman/listinfo/xen-users<br />
* Xen 3.3 Documentation - http://bits.xensource.com/Xen/docs/user.pdf <br />
* Stack Oveflow - http://stackoverflow.com/<br />
* Complete email history of all xen mailing lists - http://xen.markmail.org <br />
* Language Specific Support<br />
** Japanese - http://lists.xensource.com/mailman/listinfo/xen-japanese<br />
** Portuguese - http://groups.google.com/group/xen-br<br />
<br />
== How To Guide Links ==<br />
The Xen.org community Wiki has a [[HowTo]] Page with various information sources at http://wiki.xensource.com/xenwiki/HowTos. Updates to this Wiki page are continuous so check back often for new How Tos. <br />
Sample topics internally within the Wiki are:<br />
* [[XenNetworking| Xen Networking]]<br />
* [[FreeBSDdomU| Xen FreeBSD]]<br />
<br />
Sample topics with external links are:<br />
* Adding USB Devices to Xen HVM - http://www.virtuatopia.com/index.php <br />
* Xen on Fedora - http://rackerhacker.com/2011/08/05/xen-4-1-on-fedora-15-with-linux-3-0/ <br />
* Create and Install CentOS on Xen - http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU <br />
* http://www.virtuatopia.com/index.php/Configuring_a_VNC_based_Graphical_Console_for_a_Xen_Paravirtualized_domainU_Guest<br />
* https://help.ubuntu.com/community/Xen Xen on Ubuntu<br />
<br />
== Guest Related Questions ==<br />
=== Guest Conversion ===<br />
Q (G1.0): How do I convert a Centos HVM Guest to a PV Guest?<br />
<br />
A (G1.0): Creating a Centos HVM domU with working PV drivers : http://pastebin.com/fb6fe631 Converting HVM guest to PV guest : http://pastebin.com/f6a5022bf <br />
If you follow both parts correctly you should have a working PV domU. If anything goes wrong during conversion process, you should still be able to boot the previous HVM domU config if you select the non-xen kernel (second entry) from grub menu.list. <br />
=== Console ===<br />
<br />
Q (G2.0): I have an Xen image that was built for a graphical console (VNC). Is there any way to change it to the non-graphical console (xen console)? <br />
<br />
A (G2.0): For HVM guest, you need to enable serial port on domU config file (example here: http://pastebin.com/fb6fe631), and setup domU to use serial port (ttyS0 on Linux) by modifying (for Linux domU) /boot/grub/menu.lst, /etc/inittab, and /etc/securetty. <br />
If it's PV guest, you need to set up domU to use xen console (which is xvc0 on current xen version, hvc0 on pv_ops kernel). It's similar to setting up domU for serial console, you just need to change ttyS0 to hvc0. An example of domU setup that can use both xvc0 and vnc console is here : http://pastebin.com/f6a5022bf <br />
<br />
Q (G2.1): How do I remove an active virtual machine?<br />
<br />
A (G2.1): xl shutdown or xl delete<br />
<br />
Q (G2.2): How do I run xl console to a WindowsXP DomU?<br />
<br />
A (G2.2): You can't xl console to that (I'm not sure you can xl console to any hvm, but I know you can't to one that doesn't have a console). <br />
<br />
Q (G2.3): I start a new DomainU (Guest) and some text scrolls by for launching the guest but then it just sits there with Continue and no actions takes place? <br />
<br />
A (G2.3): The console for this new DomainU is not properly available for you; fix this by adding xtra="xencons=tty" in the configuration file. This will bring up a login screen directly for your new DomainU. <br />
<br />
Q (G2.4): One of our CentOS 5.3 randomly reboots, at different times of the day, and I can't see why it's doing it. I have looked through the logs, but don't see any thing in there that shows me why it has rebooted. How can I debug this? <br />
<br />
A (G2.4): The problem is that when the box panics, it stops syslogd, so you don't get the panic output in /var/log. The best way to fix this is to setup a logging serial console. <br />
<br />
Q (G2.5): Hi, i want to stop VMs, but when i execute xl destroy vmname the VM disappears completly from mu vm list (xl list) How can I stop them without delete them? <br />
<br />
A (G2.5): You've probably been using "xl create". That's the way it works.<br />
<br />
=== Drivers ===<br />
Q (G3.0): What are the GPLPV Drivers and where can I get them?<br />
<br />
A (G3.0): A collection of open source Window PV drivers that allow Windows to be para-virtualized. They are currently being implemented under the leadership of James Harper. More information on these drivers at:<br />
* http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing<br />
* http://lists.xensource.com/archives/html/xen-users/2009-04/msg00058.html<br />
* http://meadowcourt.org/downloads/<br />
<br />
Q (G3.1): How can I tell if the GPLPV Drivers are loaded correctly?<br />
<br />
A(G3.1): If the drivers are installed correctly there should be a Xen device under 'System Devices' in device manager. <br />
<br />
=== Domain0 ===<br />
Q (G4.0): Why cannot I see all my RAM on my Dom0?<br />
<br />
A (G4.0): Domain 0 is a paravirt VM in reality, so the amount of ram you allocate to it is what you will see when using local tools like free, /proc/meminfo, top, etc. <br />
To see the full system ram, you need to use the xm tools... and in this case, 'xm info' which will show you all the system resources, as opposed to the resources available to dom0. <br />
Also, you have 16GB ram on the system... you probably already know this, but be aware that without a PAE enabled kernel (if you're using 32bit Xen) you'll only see 4GB of this. PAE will allow you to use up to 16, or maybe 32 (I don't remember what the upper limit for PAE enabled Xen is off the top of my head). <br />
<br />
Q (G4.1): Is there any way of checking DomU´s I/O from Dom0? <br />
<br />
A (G4.1): iostat (Debian: sysstat-package) <br />
<br />
Q (G4.2): Can I allocate one CPU to the Dom0 exclusively? <br />
<br />
A (G4.2): Add this to the kernel boot line <br />
* dom0_max_vcpus=1 & dom0_vcpus_pin <br />
* Edit /etc/xen/xend-config.sxp - set “(dom0-cpus 1)†<br />
* Reboot Dom0 <br />
* To try on an active system without a Reboot - <br />
* xm vcpu-set 0 1 xm vcpu-pin 0 0 0 <br />
<br />
Q (G4.3): Running xm info I see the following memory available; what does the free memory mean?<br />
total_memory : 2046 free_memory : 5 <br />
<br />
A (G4.3): Free_memory from "xm info" shows memory not allocated to any domain (inlcuding dom0). "free", "top" (or whatever) shows free memory on that particular domain (in your case, dom0). You can adjust memory allocation per domain using "xm mem-set". <br />
<br />
=== DomainU ===<br />
Q (G5.0): My DomU does not fully start; it shows the following output stopping at Continue...<br />
<br />
$ sudo xm console test<br />
<br />
io scheduler cfq registered<br />
<br />
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize<br />
<br />
Xen virtual console successfully installed as xvc0 Event-channel device installed. netfront: Initialising virtual ethernet driver. i8042.c: No controller found. mice: PS/2 mouse device common for all mice TCP bic registered NET: Registered protocol family 1 <br />
<br />
NET: Registered protocol family 17<br />
<br />
Using IPI No-Shortcut mode xen-vbd: registered block device major 8 blkfront: sda2: barriers enabled XENBUS: Device with no driver: device/console/0 Freeing unused kernel memory: 140k freed kjournald starting. Commit interval 5 seconds <br />
<br />
EXT3-fs: mounted filesystem with ordered data mode.<br />
<br />
* ************************************************************** <br />
* **************************************************************<br />
* * WARNING: Currently emulating unsupported memory accesses **<br />
* * in /lib/tls glibc libraries. The emulation is **<br />
* * slow. To ensure full performance you should **<br />
* * install a 'xen-friendly' (nosegneg) version of **<br />
* * the library, or disable tls support by executing **<br />
* * the following as root: **<br />
* * mv /lib/tls /lib/tls.disabled **<br />
* * Offending process: modprobe (pid=663) **<br />
* **************************************************************<br />
* **************************************************************<br />
Continuing... <br />
<br />
A (G5.0): It might only be that you don't have a VPS physical console, and that your VPS is fully booted, but you can't see it. There are few things to check.<br />
<br />
First, check that your VPS has a "console" device in /dev. Mount your domU filesystem in the dom0, go in /dev and do:<br />
<br />
/dev/MAKEDEV console<br />
<br />
If you are using a modern Xen kernel and hypervisor, you should check the parameters of the startup file. Check that it has the following option:<br />
<br />
extra = "4 TERM=xterm xencons=tty console=tty1"<br />
<br />
Then start your VPS and watch it booting. Note that once it's booted up, you should check that it has a xen friendly libc6 installed (in Debian, you would do "apt-get install libc6-xen").<br />
<br />
Q (G5.1): is there a way to set the credit-scheduler's limits and weights per domU<br />
in the domU configuration file? <br />
<br />
A (G5.1): weight= in the xm config file works, unless you are using RHEL or CentOS. <br />
<br />
Q (G5.2): How do I start an application from within a DomU?<br />
<br />
A (G5.2): Well, you could always just log in to that VM, open a terminal and run the program. <br />
Or you could SSH or telnet in to the VM, start a screen session and run the program. <br />
A VM acts just like any other server, so the proceedure for starting programs and executing commands locally and remotely are exactly the same as doing so on any computer. <br />
<br />
Q (G5.3): My domUs are in a permanent 'b' (blocked) status as shown by 'xm list', even though they are functioning just fine. That's not normal, is it? <br />
<br />
A (G5.3): It's normal for them to show as blocked when they aren't actively running something - in the same way that any process on a 'normal' machine will show as blocked when it's waiting for input, each guest will show as blocked when it's got nothing to do. Give something a processor intensive task to do and you'll find it changes state to running (at least some of the time). <br />
<br />
Q (G5.4): Is there any way, to get the name of a domU from the network-common script? <br />
<br />
A (G5.4): hostname=$(xenstore_read "$XENBUS_PATH/domain" | tr -- '_.:/+' '-----') <br />
<br />
Q (G5.5): Is it possible to increase the screen resolution of my xen guest Windows Vista? <br />
<br />
A (G5.5): On current Xen, with stdvga=1 & videoram=16, resolutions up to 2048x1536x32 are possible. All that said, the RDP suggestion is probably a better way to access the guest in any case. <br />
<br />
Q (G5.6): How to install Solaris via HTTP as a para guest? <br />
<br />
A (G5.6): Solaris 10 can only be used as HVM guest. [[OpenSolaris]] can be used as PV guest, installed from iso. You can't install it from http. Once you have it installed, you also need zfs support for pygrub (either that, or manually copying kernel and boot archive to dom0) <br />
<br />
Boris provides some nice examples on his site : http://bderzhavets.wordpress.com/ <br />
<br />
Q (G5.7): Is it possible to find out the specific vnc Display Number of a domU? <br />
<br />
A (G5.7): virsh vncdisplay domU_name_or_id <br />
xenstore-ls /local/domain/domU_id/console <br />
<br />
Q (G5.8): I am trying to create a guest domain. I specified the configurations in /etc/xen-tools/xen-tools.conf and I ran $sudo xen-create-image --hostname=virtualrouter1 --role=udev the output is: sudo: xen-create-image: command not found <br />
<br />
A (G5.8): Make sure you installed the Xen tools, for example: apt-get install xen-tools <br />
<br />
Q(G5.9): I'm trying to assign a dynamic hostname to a xen instance as follows: <br />
<br />
Cfg file <br />
kernel = "/root/vmlinuz-2.6.18-128.1.14.el5xen" <br />
ramdisk = "/root/initrd-2.6.18-128.1.14.el5xen.img" <br />
memory = 512 <br />
hostname = "uniquehostname" <br />
<!-- #hostname = " uniquehostname.xen.org" --><br />
name = "my-vm-name" <br />
* . . . . <br />
In both the cases, the instance is unable to get the correct hostname.. <br />
<br />
A (G5.9): From "xm create --help_config" : hostname=NAME Set the kernel IP hostname. interface=INTF Set the kernel IP interface name. dhcp=off|dhcp Set the kernel dhcp option. <br />
On most LInux distros, kernel hostname and IP address is ignored, making it somewhat useless. You need to use your normal distro method to set hostname on domU (/etc/sysconfig/network on RHEL) <br />
<br />
Q(G5.10): As far as I can see, there is something different between using 'xm create' and 'xm new' followed by 'xm start'. It's something to do with data being stored in [[XenStore]]. I couldn't suspend the one started with 'xm create'. Could someone please explain the effective difference between the two and when 'create' should be used instead of 'new' and vice-versa. <br />
<br />
A(G5.10): xm create -> domU configuration is NOT managed by xend. Usually using config files on /etc/xen. This is the easiest method to use for beginners, as you have a config file that you can edit manually. The default on RHEL5 (which uses Xen 3.1+). <br />
"xm new" and "xm start" -> domU configuration is managed by xend. You change values using commands like "xm block-attach", which can modify settings online. No config file to edit manually. The default on current versions of Xen. <br />
<br />
G (G5.11): I have problem with domU clock. It lose 30 minutes each day. How can i synchronize it with dom0 clock? <br />
<br />
A (G5.11): Is this PV domU? If yes, setting /proc/sys/xen/independent_wallclock to 0 (the default) should make it sync with dom0. You only need ntp on dom0, and domUs will follow. <br />
The alternative, set /proc/sys/xen/independent_wallclock to 1 and run ntp on domU. If this is a HVM dom0, running ntp on domU is your friend. <br />
Also, check<br />
http://tuttodebian.blogspot.com/2008/05/xen-clocksource0-time-went-backwards.html to see if your system experience similar symptoms. <br />
<br />
G (G5.12): I would like to set sched-cred parameters on my domU configuration file. How can i do that? <br />
<br />
A (G5.12): cpu_cap & cpu_weight <br />
Run "xm create --help_config" for details, and read http://wiki.xensource.com/xenwiki/CreditScheduler <br />
<br />
G (G5.13): Is it possible to increase guest memory without reboot? <br />
<br />
A (G5.13): You can do a "xm mem-set <Domain> <memory>" for a PV domU, but you had to set maxmem higher than current assignment beforehand. <br />
<br />
G (G5.14): Is it possible to take an already created domU sparse file and make it a non sparse file? <br />
<br />
A (G5.14): cp --sparse=never orig.img new.img <br />
<br />
G (G5.15): I have tried to change CD ISO images during a HVM install using the following commands but it doesn't work. After changing the CD ISO image, it doesn't detect the new ISO image. <br />
(qemu) eject -f hdc (qemu) change hdc /media/hitachi/cd-rom-image.iso <br />
<br />
A (G5.15): Use xm block-list <domid> to find the cdrom be-path for the domain, for example: <br />
xm block-list 5 Vdev BE handle state evt-ch ring-ref BE-path 768 0 0 4 9 16383 /local/domain/0/backend/vbd/5/768 5632 0 0 1 -1 -1 /local/domain/0/backend/vbd/5/5632 <br />
Having identified the cdrom device (5632) you can check what iso image it is connected to: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params <br />
(nothing returned) <br />
To connect a new iso image: <br />
xenstore-write /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
And you can now see that it is connected: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
This method works with both emulated devices and with gplpv drivers. <br />
<br />
Q (G5.16): Is it possible to set the xen to boot the domU one by one when server starts, as currently we have 20 domU, and if boot them together, the the hard disk will be very very slow. <br />
<br />
A (G5.16): cd /etc/xen/config/........ && for i in * do ...... (start VM, .....)...... sleep 60 (or whatever time you think <br />
is right to start a VM) done <br />
<br />
Q (G5.17): I use FluidVM on some of our VPS host nodes, and the management server<br />
has crashed, so now I need to recover the running VM's, somehow. FluidVM deploys the domU's on the hostnode dynamically from a database, i.e. there's no /etc/xen/vps1 (for example) config files. The domU's are still running on the servers, and I now want to create config files for them, while they're running.<br />
<br />
How would I be able todo this?<br />
<br />
For example, here's a list of running VM's from one of the servers:<br />
<br />
root@usaxen02:[~]$ xm list<br />
Name ID Mem(MiB) VCPUs State Time(s)<br />
AndriesBurger_39_cronos 90 255 1 -b---- 42.4<br />
Bruce_18_carmen 60 255 1 r----- 3528327.5<br />
Domain-0 0 3433 4 r----- 1116681.7<br />
Rudi_14_mars 40 3007 2 -b---- 953036.3<br />
Rudi_44_vps2 93 255 1 -b---- 22.9<br />
<br />
Is there any way to create a config file, /etc/xen/AndriesBurger_39_cronos, from the running domU<br />
AndriesBurger_39_cronos ?<br />
<br />
A (G5.17):You can use "xm list -l" to dump the configuration in SXP format; then you should be able to use "xm new" or "xm create" with the "-F" option to load an SXP-based config file. See the "xm" man page for more info - that's where I dug up this.<br />
<br />
Q (G5.18): How to set up Xen DomU as Windows 2008 Server on a CentOS Dom0 machine?<br />
<br />
A (G5.18): Start using the normal way that you usually do when you install a HVM domU, whether it's virt-manager/virt-install or using manually-created config file. One additional thing to note is that for 64bit HVM domUs you need to make sure that acpi, apic, and pae is set to 1 on domU config file. <br />
Once you get that Win2008 fully installed, you can install GPLPV driver later to improve performance.<br />
<br />
Q (G5.19): I need to install windows streaming media server on one of my xen3.4.2 guest. Is it possible to create a windows xp paravirtual guest on xen? Like I install other Linux guest as the paravirtual ones. If yes please give some brief steps for that. <br />
<br />
A (G5.19): No, unless you ask Microsoft to port XP kernel to Xen PV model:)<br />
<br />
Judging from the fact that XP was declared end of life several times, and the fact that even Hyper-V requires VT to run, I highly doubt they will ever create PV-enabled windows <br />
<br />
Q (G5.20): I would like to move an existing [[W2K3]] install onto my new super duper xen box -- Installing linux based machine is no issue, it's the windows ones that keep getting me. I have Acronis which we usually use for bare metal restores, and it seems that bare metal restores don't want to work too well with XEN, any assistance/help/ideas ? <br />
<br />
A (G5.20): I have successfully migrated several physical windows 2003 installs to Xen by adding the ide drivers as per http://support.microsoft.com/kb/314082 and then using Acronis True Image to copy the disks.<br />
<br />
One issue I had was that the boot cd created by the version of True Image we have did not boot under Xen (hung on boot screen), but Acronis support sent me a version that did work (TrueImageLinuxServer8072_multiparam_Standard_english_il.iso). However due to using emulated nic and hd running True Image directly under Xen was very slow, my first solution to that problem was to make a small windows hvm install with gplpv drivers loaded and true image installed and then temporarily add the target block device to it in order to write the image, but I recently switched to using a WinPE boot ISO with GPLPV and [[TrueImage]]/Backup And Recovery installed, the Acronis products come with a WinPE/BartPE Image builder utility so its quite easy to do.<br />
<br />
Also watch out for boot.ini, many servers come with a hidden partition on the boot volume for running diagnostics, in which case windows may be booting from the second partition, so you may need to adjust the boot.ini or you could remove it entirely and windows will then attempt to boot from \windows automatically. <br />
<br />
Q (G5.21): Could we add a file image, block device or lvm to domU while it is running without restarting?<br />
<br />
A (G5.21): Use "xm block-attach", and edit domU config file afterwards (if you still you file-based domU config) to make it permanent. Should work great with PV domUs.<br />
<br />
There are cases when you have to reboot the domU anyway though, since the driver installation of a new disk on domU OS could require reboot. One example is when using Windows + GPLPV.<br />
<br />
=== Devices ===<br />
<br />
Q (G6.0): For my xen domUs I'm using a mixture of locah physical partitions (with LVM) and iSCSI disks. For local partitions, I don't have any problem, because LVM volumes are always the same. But for iSCSI disks, devices are assigned in the order they are connected, so I can't be sured that device that now is /dev/sdb (for example) will always be /dev/sdb. <br />
So, is there any way to identify the physical device in the domU configuration not as phy:/dev/sdb, but something like phy:label=fslabel? Or is there any other solution to this problem? <br />
<br />
A (G6.0): I go with phy:/dev/disk/by-path/ip-*-iscsi-iqn.* If you assign iscsi luns directly as domU's fs without additional partitioning, you could probably also use /dev/disk/by-label/* or /dev/disk/by-uuid/*<br />
<br />
== Installation Questions ==<br />
<br />
See [[Xen_FAQ_Installation]]<br />
<br />
=== 32bit vs 64 bit ===<br />
<br />
Q (I2.1): Is there anyway to install 64Bit Linux DomU on 32Bit Linux Dom0? <br />
<br />
A (I2.1): Types of domU that can be run depends mostly on hypervisor, and not dom0. So if you have 64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit. <br />
If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not 64bit PV domU. <br />
<br />
== Networking Questions ==<br />
<br />
=== Bridging ===<br />
<br />
Q (N1.0): Which Mechanism is used by Xen bridging to handle packets coming from various VMs to forward them to their destination <br />
<br />
A (N1.0): Nothing. Xen by itself does not handle bridge. dom0 OS does that. <br />
On Linux dom0 : http://www.linuxfoundation.org/en/Net:Bridge <br />
On opensolaris dom0: http://opensolaris.org/os/project/crossbow/ <br />
IP Determination<br />
<br />
Q (N2.0): I want to know the IP of a running VM in XEN.. Is there any way to have this without login to that VM.. <br />
<br />
A (N2.0): Find domU's mac. This can be easy (if your domU config specify a static MAC).<br />
The easy way to get domU's IP address, you can look at domUs config file (if you specify it), or you can try running this:<br />
xm network-list domU_name <br />
if you get this line <br />
Idx BE MAC Addr. handle state evt-ch tx-/rx-ring-ref BE-path 0 0 00:16:3E:F7:D6:E7 0 4 6 16238/16237 /local/domain/0/backend/vif/163/0 <br />
Then domU's MAC is 00:16:3E:F7:D6:E7 <br />
The hard way to find out your MAC from a bridge, since your bridge is called eth0 you can try: <br />
xm list, note the domain ID (the number) <br />
- brctl showstp eth0 that should show which interface is identified as which "port". For example if your domU has an ID 163, look for the lines that has "vif163.0" or "tap163.0". If the line looks like this <br />
vif163.0 (11) <br />
then that vif is identified as port 11 on the bridge. <br />
- brctl showmacs eth0 Look for the port corresponding to the port above. If you get this line <br />
11 00:16:3e:f7:d6:e7 no 0.96 <br />
then on port11 (where your domU interface is) there's a MAC address 00:16:3e:f7:d6:e7. <br />
Now that you have domU's mac, you try snooping the bridge for that MAC. For example : <br />
# tcpdump -n -i eth0 ether src 00:16:3e:f7:d6:e7 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:54:56.419482 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 1, length 64 15:54:57.422349 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 2, length 64 <br />
Then you know that domU has IP address 10.0.0.10. <br />
NAT<br />
<br />
Q (N3.0): I managed to configure NAT on dom0 but this does not work properly. Outgoing traffic from domU is seen with the original domU ip address instead of the dom0 ip address and the requests can't get back to the domU. <br />
<br />
A (N3.0): I figured out MASQUERADING was not set. <br />
The following rule needs to be set: <br />
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE <br />
<br />
SSL/VPN<br />
<br />
Q (N4.0): Way can't i use openvpn with a xen guest I can't load the tun module <br />
<br />
A (N4.0): From openvpn perspective, the requirements for openvpn on xen domU is the same as openvpn on native Linux. If you can't load tun module, then you need to get a kernel that supports it. <br />
The easiest way is to use a distro that supports it. For example, I'm using RHEL/Centos 5.3 domU, loaded with pygrub, and they can run openvpn just fine. <br />
Another alternative is compile your own kernel with tun/tap support. <br />
<br />
=== General ===<br />
<br />
Q (N5.0): I want to ask how to mount one storage device to 2 guests? When I try to create vm handle everything is fine I can create one vdi and vbds for every guest. When I start first machine everything is ok, but when I try to start second one it says that<br />
<br />
ERROR: 2 INTERNAL_ERROR Device 2051 (vbd) could not be connected.<br />
Device /dev/mapper/test_vg-test64_454 is mounted in a guest domain,<br />
and so cannot be mounted now.<br />
<br />
Ideas how I can share one device to two or more virtual machines? I don't want network solution like nfs,iscsi ... etc but instead use ocfs2. How I can set mode to w! ? <br />
<br />
A (N5.0): First of all, you DO realize that sharing a block device without some kind of cluster file system could lead to data corruption? If you want to share it anyway, you can try changing the mode to "r"(for read only) or "w!" (to force read-write multiple mount). <br />
in your domU.cfg:<br />
<br />
'phy:/dev/data/bla-disk,sda1,w' => 'phy:/dev/data/bla-disk,sda1,r'<br />
<br />
Q (N5.1): I'm looking for a way to monitor network activities of processes in Guest OS. I want to get a list of Guest OS processes that open TCP connections to other machines (like "lsof" command). <br />
<br />
A (N5.1): If you're thinking about doing on from dom0, that's not possible. You need something that runs on domU for that, possibly by using snmpd and extending it to run "netstat -anp --tcp". Other host (including dom0) can then collect the information using snmp. <br />
Also, have a look at Versiera, it provides what you are looking for including, user<br />
IDs, inbound/outbound communications, IPv4, IPV6, etc. There are many more<br />
capabilities. Versiera is not open-source, but the Internet self-manage service<br />
is free. <br />
<br />
Q (N5.2): I’m attempting to gather stats on usage of the “metalâ€, by which I mean the physical host’s hardware. I would like to know the CPU, IO, and network stats for the hardware. <br />
<br />
A (N5.2): All DomU's IO passes through Dom0. there you can measure all you want. <br />
for disk IO, if you use phy: devices, you can use iostat to see the usage of each device. if you use file-based backends, it would be easier to check the userspace daemons. maybe iotop would help. in any case, if aggregate usage is all you need, just measure the disk usage seen at Dom0 <br />
for network, if you can measure at peth0, that would give you the aggregate usage. if you need stats for each DomU, check the respective tun devices. <br />
<br />
Q (N5.3): I have some trouble finding the best solution to my networking requirements. <br />
I want to have the following things: <br />
-dom0 : have 2 physical networks devices * 1 eth with public IP (static) * 1 eth with private IP (static) <br />
-domU * 1 eth with private IP <br />
-I also want openVPN solution to let people outside the private network have access to it. <br />
-A DHCP server is required so that domU get their IP from it. <br />
I have debian lenny and xen 3.2 installed and working. Actually openvpn and dhcp are on the dom0. All is fine *except* that domU don't have access to internet (this is my main problem). My current config use network-bridge netdev=eth1 (eth1 have a static private ip). <br />
It is perhaps better to have dhcp and openvpn server in a domU, feel free to suggest what you think is the best choice (and the config that go with it) :) <br />
<br />
A (N5.3): When designing such setups, with bridge networking, I often find it easier to think of dom0 as a switch or router, and domU like any other physical server on your network. <br />
In your setup you're making dom0 act as router/firewall. Your problem is that probably you haven't setup ip forwarding and NAT on dom0 to allow domU internet access. <br />
Note that (if you want) you could also have dom0 act like a switch. In that scenario you'd need another domU, with two network interfaces connected to both dom0's eth0 and eth1, acting as router/firewall. <br />
<br />
Q (N5.4): I have been trying to get a HVM DomU running and being able to connect to a vlan. I am starting to get the feeling that at least the hw emulations I have tried do not supoprt vlans. Also all the things I have found online would have me creating the vlans inside the Dom0 and pushing them to the DomU's as regular interface<br />
<br />
A (N5.4): You could always have a trunk port in your dom0 and create bridges for each VLAN for xen. <br />
You can even script it so you can add it to boot time. <br />
If you have the VLAN trunk set up, you can create bridges as follows. <br />
For this example, my trunk interface is on eth0 and the vlan I am adding is 2. <br />
<!-- # vconfig add eth0 2 # brctl addbr xenbr2 # brctl addif xenbr2 eth0.2 # ifconfig eth0.2 up # ifconfig xenbr2 up --><br />
Now all you would add in the domU configuration file is: <br />
vif=['bridge=xenbr2'] <br />
And you would be on VLAN 2. <br />
Otherwise I'm pretty sure you would have to pass through the network card to get VLAN access. <br />
You can also script this and give it a space separated list of VLANs and loop it through. I will leave this up to you though. <br />
<br />
== High Availability Questions ==<br />
=== Services ===<br />
<br />
*Q) What software exists for Xen to handle high availability? <br />
*A): Project Remus is supplied with Xen. http://blog.xen.org/index.php/2009/04/02/project-remus-released/<br />
<br />
*Q) How can I use LVM snapshots with Xen?<br />
*A): You could try this http://www.infohit.net/blog/post/using-lvm2-snapshots-to-provide-rollback-functionality-for-xen.html<br />
<br />
== Performance Questions ==<br />
<br />
== Security Questions ==<br />
<br />
Q(S1.0): If I install minimal linux for XEN in dom0 and a periphery firewall in domU and other applications in other instances of domU, is it possible to restrict/bind the network card to domU having periphery firewall and from there forward packets for dom0 or for other domUs? <br />
Is this possible? If so, is it secure? Or does dom0 always have direct access to Network Card and needs a separate firewall? And packets will always route from dom0 to all domUs ? <br />
What are the issues involved? <br />
<br />
A(S1.0): The approach I've used at home is to hide a network card from Dom0 (see pic-back.hide) and pass it through to a DomU which then sees it as a native interface. I then run a firewall in the DomU and the outside traffic does NOT go through Dom0. The route for packets is then : <br />
real i/f -> DomU (firewall) -> VIF -> int bridge [ Dom0 | VIF -> DomU ] <br />
From security perspective, this is the same as having an L2 switch (when dom0's bridges have no IP address) or L3 switch (when dom0's bridges have an IP address) <br />
<br />
Q(S1.1): I want to use a Disk Encryption and the conplete physikal Disk in a DomU. I prefere Truecrypt or Loop-aes. i will going to test loop-aes cause it should have the better performance. <br />
But, did anybody here using truecrypt or loop-aes ? What is the better one, in the fact of speed ? <br />
<br />
A(S1.1): dm-crypt/luks is one option, and performs about the same or better than loop-aes. Also it's less problematic because it doesn't use loop devic<br />
<br />
== Design/Misc Questions ==<br />
=== Nested Xen ===<br />
Q (D1.0): Can I run Xen within Xen? <br />
<br />
A (D1.0): Yes, You can install Xen on the base system, create a HVM domain, and install Xen in that guest domain. Note that the inner Xen system will not (yet) support HVM again.<br />
<br />
=== How does Xen Work ===<br />
<br />
Q (D3.0): How does Xen process System Calls on para-virtualized guest?<br />
<br />
A (D3.0): When ever a system call is invoked via interrupt or sys center control gets transferred to the kernel (ring 0), which is then handled via system call handler. System call never goes to libc but Libc is a library that provides POSIX interface to the user space applications and in a way wrapper for invocation of a system call. <br />
System call interrupt based [i386]: During booting process, linux kernel of a domU register's its IDT with Xen Hypervisor via HYPERVISOR_set_trap_table(trap_table); [arch/i386/kernel/traps-xen.c]. Xen maintains two IDT's, one global IDT (its own) and other per domain IDT. Xen uses global IDT to register the entire trap handler except for system call handler (int 0x80). When a VM gets scheduled, its system call handler (from per domain IDT table) is registered with the processor. Hence when a domain/VM executes a system call, its own handler is executed. <br />
Implementation differs for x86_64: Xen registers its own system call handler with the processor and from that handler routes the request to VM/Domain specific handler. <br />
<br />
Q (D3.1): How does Xen process System Calls on fully virtualized guest (HVM)?<br />
<br />
A (D3.1): For HVM domU there is no change in the behavior of the system call. HVM is only supported for Intel-VT and AMD-SVM processors. These processors are virtualization aware. Virtualization aware processors provide a new ring (Root-Ring 0) with higher privilege for VMM and Guest OS continues to runs with the same privilege (as without Xen) in Non-Root Ring 0. Guest OS can issue the system calls the way it used to without Xen.<br />
<br />
Q (D3.2): Can I run various DomU operating systems on a different Dom0 operating system?<br />
<br />
A (D3.2): Yes. <br />
<br />
Q (D3.3): Just curious to know, if there is any way that given a terminal to a box, we can determine is it a physical machine or a virtual machine ? <br />
<br />
A (D3.3): You should be able to get some useful information from the DMI, e.g: <br />
% for i in system-manufacturer system-product-name system-version\ system-serial-number; do echo -n "$i: "; sudo dmidecode -s $i; done <br />
system-manufacturer: Xen system-product-name: HVM domU system-version: 3.3.1 system-serial-number: 89e5915f-dead-beef-cefd-46904ea94c4a <br />
OR<br />
Probably checking kernel process, check your process table for: <br />
[xenwatch] [xenbus] <br />
Another clue is checking the kernle suffix, for example: <br />
<!-- # uname -r 2.6.24-23-xen --><br />
and the proc files: <br />
/proc/xen/capabilities <br />
<br />
Q (D3.4): What is STUBDOM ? <br />
<br />
A (D3.4): Stubdoms are lightweight 'service' or 'driver' domains. The initial purpose was to offload qemu (for hvm guests) out of dom0. <br />
So with stubdoms you can run hvm guest qemu in a separate stubdom, which boosts performance and makes it more secure. <br />
stubdoms can also run for example pv-grub for pv guests, making it more secure compared to pygrub, which always runs in dom0. <br />
http://wiki.xensource.com/xenwiki/StubDom <br />
Presentation about stubdoms at Xen Summit: http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf <br />
http://blog.xen.org/index.php/2008/08/28/xen-33-feature-stub-domains/ http://blog.xen.org/index.php/2008/08/28/xen-33-feature-hvm-device-model-domain/ http://lxr.xensource.com/lxr/source/stubdom/README <br />
<br />
Q (D3.5): When is hardware virtualization used in Xen? Is it required?<br />
<br />
A (D3.5): Xen uses hardware virtualization for HVM guests. Xen will not launch a HVM guest unless hardware virtualization is turned on.<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Asking_Xen_User_Questions&diff=5116Asking Xen User Questions2012-09-24T15:20:53Z<p>OliverChick: /* Services */</p>
<hr />
<div><!-- MoinMoin name: XenUsersQuestions --><br />
<!-- Comment: replace stephen.spector with community.manager@xen.org --><br />
<!-- WikiMedia name: XenUsersQuestions --><br />
<!-- Page revision: 00000007 --><br />
<!-- Original date: Tue Jan 25 16:12:06 2011 (1295971926000000) --><br />
<!-- ## Please edit system and help pages ONLY in the moinmaster wiki! For more --><br />
<!-- ## information, please see [[MoinMaster]]:[[MoinPagesEditorGroup]]. --><br />
<!-- ##master-page:[[HomepageReadWritePageTemplate]] --><br />
<!-- ##master-date:Unknown-Date --><br />
<!-- #format wiki --><br />
<!-- #language en --><br />
<br />
{{Needs_Refactor|Needs splitting and moving into the smaller FAQs on [[:Category:FAQ]]}}<br />
<br />
= Xen Users Mailing List Commonly Asked Questions =<br />
<br />
== Introduction ==<br />
This document is a Xen.org community effort to gather the most commonly asked questions from the xen-users emailing list and other support tools to assist new and experienced Xen hypervisor users with problems that frequently arise. If you would like to add content to this document, please send an email to community.manager@xen.org for editing rights if you don't have wiki editing rights already. <br />
For those users interested in trying Xen without installing the application, a Live CD version is available at http://wiki.xensource.com/xenwiki/LiveCD. <br />
<br />
== Support Tools ==<br />
The following sites are available for Xen hypervisor support:<br />
* xen-users mailing list - http://lists.xensource.com/mailman/listinfo/xen-users<br />
* Xen 3.3 Documentation - http://bits.xensource.com/Xen/docs/user.pdf <br />
* Stack Oveflow - http://stackoverflow.com/<br />
* Complete email history of all xen mailing lists - http://xen.markmail.org <br />
* Language Specific Support<br />
** Japanese - http://lists.xensource.com/mailman/listinfo/xen-japanese<br />
** Portuguese - http://groups.google.com/group/xen-br<br />
<br />
== How To Guide Links ==<br />
The Xen.org community Wiki has a [[HowTo]] Page with various information sources at http://wiki.xensource.com/xenwiki/HowTos. Updates to this Wiki page are continuous so check back often for new How Tos. <br />
Sample topics internally within the Wiki are:<br />
* [[XenNetworking| Xen Networking]]<br />
* [[FreeBSDdomU| Xen FreeBSD]]<br />
<br />
Sample topics with external links are:<br />
* Adding USB Devices to Xen HVM - http://www.virtuatopia.com/index.php <br />
* Xen on Fedora - http://rackerhacker.com/2011/08/05/xen-4-1-on-fedora-15-with-linux-3-0/ <br />
* Create and Install CentOS on Xen - http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU <br />
* http://www.virtuatopia.com/index.php/Configuring_a_VNC_based_Graphical_Console_for_a_Xen_Paravirtualized_domainU_Guest<br />
* https://help.ubuntu.com/community/Xen Xen on Ubuntu<br />
<br />
== Guest Related Questions ==<br />
=== Guest Conversion ===<br />
Q (G1.0): How do I convert a Centos HVM Guest to a PV Guest?<br />
<br />
A (G1.0): Creating a Centos HVM domU with working PV drivers : http://pastebin.com/fb6fe631 Converting HVM guest to PV guest : http://pastebin.com/f6a5022bf <br />
If you follow both parts correctly you should have a working PV domU. If anything goes wrong during conversion process, you should still be able to boot the previous HVM domU config if you select the non-xen kernel (second entry) from grub menu.list. <br />
=== Console ===<br />
<br />
Q (G2.0): I have an Xen image that was built for a graphical console (VNC). Is there any way to change it to the non-graphical console (xen console)? <br />
<br />
A (G2.0): For HVM guest, you need to enable serial port on domU config file (example here: http://pastebin.com/fb6fe631), and setup domU to use serial port (ttyS0 on Linux) by modifying (for Linux domU) /boot/grub/menu.lst, /etc/inittab, and /etc/securetty. <br />
If it's PV guest, you need to set up domU to use xen console (which is xvc0 on current xen version, hvc0 on pv_ops kernel). It's similar to setting up domU for serial console, you just need to change ttyS0 to hvc0. An example of domU setup that can use both xvc0 and vnc console is here : http://pastebin.com/f6a5022bf <br />
<br />
Q (G2.1): How do I remove an active virtual machine?<br />
<br />
A (G2.1): xl shutdown or xl delete<br />
<br />
Q (G2.2): How do I run xl console to a WindowsXP DomU?<br />
<br />
A (G2.2): You can't xl console to that (I'm not sure you can xl console to any hvm, but I know you can't to one that doesn't have a console). <br />
<br />
Q (G2.3): I start a new DomainU (Guest) and some text scrolls by for launching the guest but then it just sits there with Continue and no actions takes place? <br />
<br />
A (G2.3): The console for this new DomainU is not properly available for you; fix this by adding xtra="xencons=tty" in the configuration file. This will bring up a login screen directly for your new DomainU. <br />
<br />
Q (G2.4): One of our CentOS 5.3 randomly reboots, at different times of the day, and I can't see why it's doing it. I have looked through the logs, but don't see any thing in there that shows me why it has rebooted. How can I debug this? <br />
<br />
A (G2.4): The problem is that when the box panics, it stops syslogd, so you don't get the panic output in /var/log. The best way to fix this is to setup a logging serial console. <br />
<br />
Q (G2.5): Hi, i want to stop VMs, but when i execute xl destroy vmname the VM disappears completly from mu vm list (xl list) How can I stop them without delete them? <br />
<br />
A (G2.5): You've probably been using "xl create". That's the way it works.<br />
<br />
=== Drivers ===<br />
Q (G3.0): What are the GPLPV Drivers and where can I get them?<br />
<br />
A (G3.0): A collection of open source Window PV drivers that allow Windows to be para-virtualized. They are currently being implemented under the leadership of James Harper. More information on these drivers at:<br />
* http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing<br />
* http://lists.xensource.com/archives/html/xen-users/2009-04/msg00058.html<br />
* http://meadowcourt.org/downloads/<br />
<br />
Q (G3.1): How can I tell if the GPLPV Drivers are loaded correctly?<br />
<br />
A(G3.1): If the drivers are installed correctly there should be a Xen device under 'System Devices' in device manager. <br />
<br />
=== Domain0 ===<br />
Q (G4.0): Why cannot I see all my RAM on my Dom0?<br />
<br />
A (G4.0): Domain 0 is a paravirt VM in reality, so the amount of ram you allocate to it is what you will see when using local tools like free, /proc/meminfo, top, etc. <br />
To see the full system ram, you need to use the xm tools... and in this case, 'xm info' which will show you all the system resources, as opposed to the resources available to dom0. <br />
Also, you have 16GB ram on the system... you probably already know this, but be aware that without a PAE enabled kernel (if you're using 32bit Xen) you'll only see 4GB of this. PAE will allow you to use up to 16, or maybe 32 (I don't remember what the upper limit for PAE enabled Xen is off the top of my head). <br />
<br />
Q (G4.1): Is there any way of checking DomU´s I/O from Dom0? <br />
<br />
A (G4.1): iostat (Debian: sysstat-package) <br />
<br />
Q (G4.2): Can I allocate one CPU to the Dom0 exclusively? <br />
<br />
A (G4.2): Add this to the kernel boot line <br />
* dom0_max_vcpus=1 & dom0_vcpus_pin <br />
* Edit /etc/xen/xend-config.sxp - set “(dom0-cpus 1)†<br />
* Reboot Dom0 <br />
* To try on an active system without a Reboot - <br />
* xm vcpu-set 0 1 xm vcpu-pin 0 0 0 <br />
<br />
Q (G4.3): Running xm info I see the following memory available; what does the free memory mean?<br />
total_memory : 2046 free_memory : 5 <br />
<br />
A (G4.3): Free_memory from "xm info" shows memory not allocated to any domain (inlcuding dom0). "free", "top" (or whatever) shows free memory on that particular domain (in your case, dom0). You can adjust memory allocation per domain using "xm mem-set". <br />
<br />
=== DomainU ===<br />
Q (G5.0): My DomU does not fully start; it shows the following output stopping at Continue...<br />
<br />
$ sudo xm console test<br />
<br />
io scheduler cfq registered<br />
<br />
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize<br />
<br />
Xen virtual console successfully installed as xvc0 Event-channel device installed. netfront: Initialising virtual ethernet driver. i8042.c: No controller found. mice: PS/2 mouse device common for all mice TCP bic registered NET: Registered protocol family 1 <br />
<br />
NET: Registered protocol family 17<br />
<br />
Using IPI No-Shortcut mode xen-vbd: registered block device major 8 blkfront: sda2: barriers enabled XENBUS: Device with no driver: device/console/0 Freeing unused kernel memory: 140k freed kjournald starting. Commit interval 5 seconds <br />
<br />
EXT3-fs: mounted filesystem with ordered data mode.<br />
<br />
* ************************************************************** <br />
* **************************************************************<br />
* * WARNING: Currently emulating unsupported memory accesses **<br />
* * in /lib/tls glibc libraries. The emulation is **<br />
* * slow. To ensure full performance you should **<br />
* * install a 'xen-friendly' (nosegneg) version of **<br />
* * the library, or disable tls support by executing **<br />
* * the following as root: **<br />
* * mv /lib/tls /lib/tls.disabled **<br />
* * Offending process: modprobe (pid=663) **<br />
* **************************************************************<br />
* **************************************************************<br />
Continuing... <br />
<br />
A (G5.0): It might only be that you don't have a VPS physical console, and that your VPS is fully booted, but you can't see it. There are few things to check.<br />
<br />
First, check that your VPS has a "console" device in /dev. Mount your domU filesystem in the dom0, go in /dev and do:<br />
<br />
/dev/MAKEDEV console<br />
<br />
If you are using a modern Xen kernel and hypervisor, you should check the parameters of the startup file. Check that it has the following option:<br />
<br />
extra = "4 TERM=xterm xencons=tty console=tty1"<br />
<br />
Then start your VPS and watch it booting. Note that once it's booted up, you should check that it has a xen friendly libc6 installed (in Debian, you would do "apt-get install libc6-xen").<br />
<br />
Q (G5.1): is there a way to set the credit-scheduler's limits and weights per domU<br />
in the domU configuration file? <br />
<br />
A (G5.1): weight= in the xm config file works, unless you are using RHEL or CentOS. <br />
<br />
Q (G5.2): How do I start an application from within a DomU?<br />
<br />
A (G5.2): Well, you could always just log in to that VM, open a terminal and run the program. <br />
Or you could SSH or telnet in to the VM, start a screen session and run the program. <br />
A VM acts just like any other server, so the proceedure for starting programs and executing commands locally and remotely are exactly the same as doing so on any computer. <br />
<br />
Q (G5.3): My domUs are in a permanent 'b' (blocked) status as shown by 'xm list', even though they are functioning just fine. That's not normal, is it? <br />
<br />
A (G5.3): It's normal for them to show as blocked when they aren't actively running something - in the same way that any process on a 'normal' machine will show as blocked when it's waiting for input, each guest will show as blocked when it's got nothing to do. Give something a processor intensive task to do and you'll find it changes state to running (at least some of the time). <br />
<br />
Q (G5.4): Is there any way, to get the name of a domU from the network-common script? <br />
<br />
A (G5.4): hostname=$(xenstore_read "$XENBUS_PATH/domain" | tr -- '_.:/+' '-----') <br />
<br />
Q (G5.5): Is it possible to increase the screen resolution of my xen guest Windows Vista? <br />
<br />
A (G5.5): On current Xen, with stdvga=1 & videoram=16, resolutions up to 2048x1536x32 are possible. All that said, the RDP suggestion is probably a better way to access the guest in any case. <br />
<br />
Q (G5.6): How to install Solaris via HTTP as a para guest? <br />
<br />
A (G5.6): Solaris 10 can only be used as HVM guest. [[OpenSolaris]] can be used as PV guest, installed from iso. You can't install it from http. Once you have it installed, you also need zfs support for pygrub (either that, or manually copying kernel and boot archive to dom0) <br />
<br />
Boris provides some nice examples on his site : http://bderzhavets.wordpress.com/ <br />
<br />
Q (G5.7): Is it possible to find out the specific vnc Display Number of a domU? <br />
<br />
A (G5.7): virsh vncdisplay domU_name_or_id <br />
xenstore-ls /local/domain/domU_id/console <br />
<br />
Q (G5.8): I am trying to create a guest domain. I specified the configurations in /etc/xen-tools/xen-tools.conf and I ran $sudo xen-create-image --hostname=virtualrouter1 --role=udev the output is: sudo: xen-create-image: command not found <br />
<br />
A (G5.8): Make sure you installed the Xen tools, for example: apt-get install xen-tools <br />
<br />
Q(G5.9): I'm trying to assign a dynamic hostname to a xen instance as follows: <br />
<br />
Cfg file <br />
kernel = "/root/vmlinuz-2.6.18-128.1.14.el5xen" <br />
ramdisk = "/root/initrd-2.6.18-128.1.14.el5xen.img" <br />
memory = 512 <br />
hostname = "uniquehostname" <br />
<!-- #hostname = " uniquehostname.xen.org" --><br />
name = "my-vm-name" <br />
* . . . . <br />
In both the cases, the instance is unable to get the correct hostname.. <br />
<br />
A (G5.9): From "xm create --help_config" : hostname=NAME Set the kernel IP hostname. interface=INTF Set the kernel IP interface name. dhcp=off|dhcp Set the kernel dhcp option. <br />
On most LInux distros, kernel hostname and IP address is ignored, making it somewhat useless. You need to use your normal distro method to set hostname on domU (/etc/sysconfig/network on RHEL) <br />
<br />
Q(G5.10): As far as I can see, there is something different between using 'xm create' and 'xm new' followed by 'xm start'. It's something to do with data being stored in [[XenStore]]. I couldn't suspend the one started with 'xm create'. Could someone please explain the effective difference between the two and when 'create' should be used instead of 'new' and vice-versa. <br />
<br />
A(G5.10): xm create -> domU configuration is NOT managed by xend. Usually using config files on /etc/xen. This is the easiest method to use for beginners, as you have a config file that you can edit manually. The default on RHEL5 (which uses Xen 3.1+). <br />
"xm new" and "xm start" -> domU configuration is managed by xend. You change values using commands like "xm block-attach", which can modify settings online. No config file to edit manually. The default on current versions of Xen. <br />
<br />
G (G5.11): I have problem with domU clock. It lose 30 minutes each day. How can i synchronize it with dom0 clock? <br />
<br />
A (G5.11): Is this PV domU? If yes, setting /proc/sys/xen/independent_wallclock to 0 (the default) should make it sync with dom0. You only need ntp on dom0, and domUs will follow. <br />
The alternative, set /proc/sys/xen/independent_wallclock to 1 and run ntp on domU. If this is a HVM dom0, running ntp on domU is your friend. <br />
Also, check<br />
http://tuttodebian.blogspot.com/2008/05/xen-clocksource0-time-went-backwards.html to see if your system experience similar symptoms. <br />
<br />
G (G5.12): I would like to set sched-cred parameters on my domU configuration file. How can i do that? <br />
<br />
A (G5.12): cpu_cap & cpu_weight <br />
Run "xm create --help_config" for details, and read http://wiki.xensource.com/xenwiki/CreditScheduler <br />
<br />
G (G5.13): Is it possible to increase guest memory without reboot? <br />
<br />
A (G5.13): You can do a "xm mem-set <Domain> <memory>" for a PV domU, but you had to set maxmem higher than current assignment beforehand. <br />
<br />
G (G5.14): Is it possible to take an already created domU sparse file and make it a non sparse file? <br />
<br />
A (G5.14): cp --sparse=never orig.img new.img <br />
<br />
G (G5.15): I have tried to change CD ISO images during a HVM install using the following commands but it doesn't work. After changing the CD ISO image, it doesn't detect the new ISO image. <br />
(qemu) eject -f hdc (qemu) change hdc /media/hitachi/cd-rom-image.iso <br />
<br />
A (G5.15): Use xm block-list <domid> to find the cdrom be-path for the domain, for example: <br />
xm block-list 5 Vdev BE handle state evt-ch ring-ref BE-path 768 0 0 4 9 16383 /local/domain/0/backend/vbd/5/768 5632 0 0 1 -1 -1 /local/domain/0/backend/vbd/5/5632 <br />
Having identified the cdrom device (5632) you can check what iso image it is connected to: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params <br />
(nothing returned) <br />
To connect a new iso image: <br />
xenstore-write /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
And you can now see that it is connected: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
This method works with both emulated devices and with gplpv drivers. <br />
<br />
Q (G5.16): Is it possible to set the xen to boot the domU one by one when server starts, as currently we have 20 domU, and if boot them together, the the hard disk will be very very slow. <br />
<br />
A (G5.16): cd /etc/xen/config/........ && for i in * do ...... (start VM, .....)...... sleep 60 (or whatever time you think <br />
is right to start a VM) done <br />
<br />
Q (G5.17): I use FluidVM on some of our VPS host nodes, and the management server<br />
has crashed, so now I need to recover the running VM's, somehow. FluidVM deploys the domU's on the hostnode dynamically from a database, i.e. there's no /etc/xen/vps1 (for example) config files. The domU's are still running on the servers, and I now want to create config files for them, while they're running.<br />
<br />
How would I be able todo this?<br />
<br />
For example, here's a list of running VM's from one of the servers:<br />
<br />
root@usaxen02:[~]$ xm list<br />
Name ID Mem(MiB) VCPUs State Time(s)<br />
AndriesBurger_39_cronos 90 255 1 -b---- 42.4<br />
Bruce_18_carmen 60 255 1 r----- 3528327.5<br />
Domain-0 0 3433 4 r----- 1116681.7<br />
Rudi_14_mars 40 3007 2 -b---- 953036.3<br />
Rudi_44_vps2 93 255 1 -b---- 22.9<br />
<br />
Is there any way to create a config file, /etc/xen/AndriesBurger_39_cronos, from the running domU<br />
AndriesBurger_39_cronos ?<br />
<br />
A (G5.17):You can use "xm list -l" to dump the configuration in SXP format; then you should be able to use "xm new" or "xm create" with the "-F" option to load an SXP-based config file. See the "xm" man page for more info - that's where I dug up this.<br />
<br />
Q (G5.18): How to set up Xen DomU as Windows 2008 Server on a CentOS Dom0 machine?<br />
<br />
A (G5.18): Start using the normal way that you usually do when you install a HVM domU, whether it's virt-manager/virt-install or using manually-created config file. One additional thing to note is that for 64bit HVM domUs you need to make sure that acpi, apic, and pae is set to 1 on domU config file. <br />
Once you get that Win2008 fully installed, you can install GPLPV driver later to improve performance.<br />
<br />
Q (G5.19): I need to install windows streaming media server on one of my xen3.4.2 guest. Is it possible to create a windows xp paravirtual guest on xen? Like I install other Linux guest as the paravirtual ones. If yes please give some brief steps for that. <br />
<br />
A (G5.19): No, unless you ask Microsoft to port XP kernel to Xen PV model:)<br />
<br />
Judging from the fact that XP was declared end of life several times, and the fact that even Hyper-V requires VT to run, I highly doubt they will ever create PV-enabled windows <br />
<br />
Q (G5.20): I would like to move an existing [[W2K3]] install onto my new super duper xen box -- Installing linux based machine is no issue, it's the windows ones that keep getting me. I have Acronis which we usually use for bare metal restores, and it seems that bare metal restores don't want to work too well with XEN, any assistance/help/ideas ? <br />
<br />
A (G5.20): I have successfully migrated several physical windows 2003 installs to Xen by adding the ide drivers as per http://support.microsoft.com/kb/314082 and then using Acronis True Image to copy the disks.<br />
<br />
One issue I had was that the boot cd created by the version of True Image we have did not boot under Xen (hung on boot screen), but Acronis support sent me a version that did work (TrueImageLinuxServer8072_multiparam_Standard_english_il.iso). However due to using emulated nic and hd running True Image directly under Xen was very slow, my first solution to that problem was to make a small windows hvm install with gplpv drivers loaded and true image installed and then temporarily add the target block device to it in order to write the image, but I recently switched to using a WinPE boot ISO with GPLPV and [[TrueImage]]/Backup And Recovery installed, the Acronis products come with a WinPE/BartPE Image builder utility so its quite easy to do.<br />
<br />
Also watch out for boot.ini, many servers come with a hidden partition on the boot volume for running diagnostics, in which case windows may be booting from the second partition, so you may need to adjust the boot.ini or you could remove it entirely and windows will then attempt to boot from \windows automatically. <br />
<br />
Q (G5.21): Could we add a file image, block device or lvm to domU while it is running without restarting?<br />
<br />
A (G5.21): Use "xm block-attach", and edit domU config file afterwards (if you still you file-based domU config) to make it permanent. Should work great with PV domUs.<br />
<br />
There are cases when you have to reboot the domU anyway though, since the driver installation of a new disk on domU OS could require reboot. One example is when using Windows + GPLPV.<br />
<br />
=== Devices ===<br />
<br />
Q (G6.0): For my xen domUs I'm using a mixture of locah physical partitions (with LVM) and iSCSI disks. For local partitions, I don't have any problem, because LVM volumes are always the same. But for iSCSI disks, devices are assigned in the order they are connected, so I can't be sured that device that now is /dev/sdb (for example) will always be /dev/sdb. <br />
So, is there any way to identify the physical device in the domU configuration not as phy:/dev/sdb, but something like phy:label=fslabel? Or is there any other solution to this problem? <br />
<br />
A (G6.0): I go with phy:/dev/disk/by-path/ip-*-iscsi-iqn.* If you assign iscsi luns directly as domU's fs without additional partitioning, you could probably also use /dev/disk/by-label/* or /dev/disk/by-uuid/*<br />
<br />
== Installation Questions ==<br />
<br />
See [[Xen_FAQ_Installation]]<br />
<br />
=== 32bit vs 64 bit ===<br />
<br />
Q (I2.1): Is there anyway to install 64Bit Linux DomU on 32Bit Linux Dom0? <br />
<br />
A (I2.1): Types of domU that can be run depends mostly on hypervisor, and not dom0. So if you have 64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit. <br />
If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not 64bit PV domU. <br />
<br />
== Networking Questions ==<br />
<br />
=== Bridging ===<br />
<br />
Q (N1.0): Which Mechanism is used by Xen bridging to handle packets coming from various VMs to forward them to their destination <br />
<br />
A (N1.0): Nothing. Xen by itself does not handle bridge. dom0 OS does that. <br />
On Linux dom0 : http://www.linuxfoundation.org/en/Net:Bridge <br />
On opensolaris dom0: http://opensolaris.org/os/project/crossbow/ <br />
IP Determination<br />
<br />
Q (N2.0): I want to know the IP of a running VM in XEN.. Is there any way to have this without login to that VM.. <br />
<br />
A (N2.0): Find domU's mac. This can be easy (if your domU config specify a static MAC).<br />
The easy way to get domU's IP address, you can look at domUs config file (if you specify it), or you can try running this:<br />
xm network-list domU_name <br />
if you get this line <br />
Idx BE MAC Addr. handle state evt-ch tx-/rx-ring-ref BE-path 0 0 00:16:3E:F7:D6:E7 0 4 6 16238/16237 /local/domain/0/backend/vif/163/0 <br />
Then domU's MAC is 00:16:3E:F7:D6:E7 <br />
The hard way to find out your MAC from a bridge, since your bridge is called eth0 you can try: <br />
xm list, note the domain ID (the number) <br />
- brctl showstp eth0 that should show which interface is identified as which "port". For example if your domU has an ID 163, look for the lines that has "vif163.0" or "tap163.0". If the line looks like this <br />
vif163.0 (11) <br />
then that vif is identified as port 11 on the bridge. <br />
- brctl showmacs eth0 Look for the port corresponding to the port above. If you get this line <br />
11 00:16:3e:f7:d6:e7 no 0.96 <br />
then on port11 (where your domU interface is) there's a MAC address 00:16:3e:f7:d6:e7. <br />
Now that you have domU's mac, you try snooping the bridge for that MAC. For example : <br />
# tcpdump -n -i eth0 ether src 00:16:3e:f7:d6:e7 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:54:56.419482 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 1, length 64 15:54:57.422349 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 2, length 64 <br />
Then you know that domU has IP address 10.0.0.10. <br />
NAT<br />
<br />
Q (N3.0): I managed to configure NAT on dom0 but this does not work properly. Outgoing traffic from domU is seen with the original domU ip address instead of the dom0 ip address and the requests can't get back to the domU. <br />
<br />
A (N3.0): I figured out MASQUERADING was not set. <br />
The following rule needs to be set: <br />
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE <br />
<br />
SSL/VPN<br />
<br />
Q (N4.0): Way can't i use openvpn with a xen guest I can't load the tun module <br />
<br />
A (N4.0): From openvpn perspective, the requirements for openvpn on xen domU is the same as openvpn on native Linux. If you can't load tun module, then you need to get a kernel that supports it. <br />
The easiest way is to use a distro that supports it. For example, I'm using RHEL/Centos 5.3 domU, loaded with pygrub, and they can run openvpn just fine. <br />
Another alternative is compile your own kernel with tun/tap support. <br />
<br />
=== General ===<br />
<br />
Q (N5.0): I want to ask how to mount one storage device to 2 guests? When I try to create vm handle everything is fine I can create one vdi and vbds for every guest. When I start first machine everything is ok, but when I try to start second one it says that<br />
<br />
ERROR: 2 INTERNAL_ERROR Device 2051 (vbd) could not be connected.<br />
Device /dev/mapper/test_vg-test64_454 is mounted in a guest domain,<br />
and so cannot be mounted now.<br />
<br />
Ideas how I can share one device to two or more virtual machines? I don't want network solution like nfs,iscsi ... etc but instead use ocfs2. How I can set mode to w! ? <br />
<br />
A (N5.0): First of all, you DO realize that sharing a block device without some kind of cluster file system could lead to data corruption? If you want to share it anyway, you can try changing the mode to "r"(for read only) or "w!" (to force read-write multiple mount). <br />
in your domU.cfg:<br />
<br />
'phy:/dev/data/bla-disk,sda1,w' => 'phy:/dev/data/bla-disk,sda1,r'<br />
<br />
Q (N5.1): I'm looking for a way to monitor network activities of processes in Guest OS. I want to get a list of Guest OS processes that open TCP connections to other machines (like "lsof" command). <br />
<br />
A (N5.1): If you're thinking about doing on from dom0, that's not possible. You need something that runs on domU for that, possibly by using snmpd and extending it to run "netstat -anp --tcp". Other host (including dom0) can then collect the information using snmp. <br />
Also, have a look at Versiera, it provides what you are looking for including, user<br />
IDs, inbound/outbound communications, IPv4, IPV6, etc. There are many more<br />
capabilities. Versiera is not open-source, but the Internet self-manage service<br />
is free. <br />
<br />
Q (N5.2): I’m attempting to gather stats on usage of the “metalâ€, by which I mean the physical host’s hardware. I would like to know the CPU, IO, and network stats for the hardware. <br />
<br />
A (N5.2): All DomU's IO passes through Dom0. there you can measure all you want. <br />
for disk IO, if you use phy: devices, you can use iostat to see the usage of each device. if you use file-based backends, it would be easier to check the userspace daemons. maybe iotop would help. in any case, if aggregate usage is all you need, just measure the disk usage seen at Dom0 <br />
for network, if you can measure at peth0, that would give you the aggregate usage. if you need stats for each DomU, check the respective tun devices. <br />
<br />
Q (N5.3): I have some trouble finding the best solution to my networking requirements. <br />
I want to have the following things: <br />
-dom0 : have 2 physical networks devices * 1 eth with public IP (static) * 1 eth with private IP (static) <br />
-domU * 1 eth with private IP <br />
-I also want openVPN solution to let people outside the private network have access to it. <br />
-A DHCP server is required so that domU get their IP from it. <br />
I have debian lenny and xen 3.2 installed and working. Actually openvpn and dhcp are on the dom0. All is fine *except* that domU don't have access to internet (this is my main problem). My current config use network-bridge netdev=eth1 (eth1 have a static private ip). <br />
It is perhaps better to have dhcp and openvpn server in a domU, feel free to suggest what you think is the best choice (and the config that go with it) :) <br />
<br />
A (N5.3): When designing such setups, with bridge networking, I often find it easier to think of dom0 as a switch or router, and domU like any other physical server on your network. <br />
In your setup you're making dom0 act as router/firewall. Your problem is that probably you haven't setup ip forwarding and NAT on dom0 to allow domU internet access. <br />
Note that (if you want) you could also have dom0 act like a switch. In that scenario you'd need another domU, with two network interfaces connected to both dom0's eth0 and eth1, acting as router/firewall. <br />
<br />
Q (N5.4): I have been trying to get a HVM DomU running and being able to connect to a vlan. I am starting to get the feeling that at least the hw emulations I have tried do not supoprt vlans. Also all the things I have found online would have me creating the vlans inside the Dom0 and pushing them to the DomU's as regular interface<br />
<br />
A (N5.4): You could always have a trunk port in your dom0 and create bridges for each VLAN for xen. <br />
You can even script it so you can add it to boot time. <br />
If you have the VLAN trunk set up, you can create bridges as follows. <br />
For this example, my trunk interface is on eth0 and the vlan I am adding is 2. <br />
<!-- # vconfig add eth0 2 # brctl addbr xenbr2 # brctl addif xenbr2 eth0.2 # ifconfig eth0.2 up # ifconfig xenbr2 up --><br />
Now all you would add in the domU configuration file is: <br />
vif=['bridge=xenbr2'] <br />
And you would be on VLAN 2. <br />
Otherwise I'm pretty sure you would have to pass through the network card to get VLAN access. <br />
You can also script this and give it a space separated list of VLANs and loop it through. I will leave this up to you though. <br />
<br />
== High Availability Questions ==<br />
=== Services ===<br />
<br />
Q) What software exists for Xen to handle high availability? <br />
A): Project Remus is supplied with Xen. http://blog.xen.org/index.php/2009/04/02/project-remus-released/<br />
<br />
Q) How can I use LVM snapshots with Xen?<br />
A): You could try this http://www.infohit.net/blog/post/using-lvm2-snapshots-to-provide-rollback-functionality-for-xen.html<br />
<br />
== Performance Questions ==<br />
<br />
== Security Questions ==<br />
<br />
Q(S1.0): If I install minimal linux for XEN in dom0 and a periphery firewall in domU and other applications in other instances of domU, is it possible to restrict/bind the network card to domU having periphery firewall and from there forward packets for dom0 or for other domUs? <br />
Is this possible? If so, is it secure? Or does dom0 always have direct access to Network Card and needs a separate firewall? And packets will always route from dom0 to all domUs ? <br />
What are the issues involved? <br />
<br />
A(S1.0): The approach I've used at home is to hide a network card from Dom0 (see pic-back.hide) and pass it through to a DomU which then sees it as a native interface. I then run a firewall in the DomU and the outside traffic does NOT go through Dom0. The route for packets is then : <br />
real i/f -> DomU (firewall) -> VIF -> int bridge [ Dom0 | VIF -> DomU ] <br />
From security perspective, this is the same as having an L2 switch (when dom0's bridges have no IP address) or L3 switch (when dom0's bridges have an IP address) <br />
<br />
Q(S1.1): I want to use a Disk Encryption and the conplete physikal Disk in a DomU. I prefere Truecrypt or Loop-aes. i will going to test loop-aes cause it should have the better performance. <br />
But, did anybody here using truecrypt or loop-aes ? What is the better one, in the fact of speed ? <br />
<br />
A(S1.1): dm-crypt/luks is one option, and performs about the same or better than loop-aes. Also it's less problematic because it doesn't use loop devic<br />
<br />
== Design/Misc Questions ==<br />
=== Nested Xen ===<br />
Q (D1.0): Can I run Xen within Xen? <br />
<br />
A (D1.0): Yes, You can install Xen on the base system, create a HVM domain, and install Xen in that guest domain. Note that the inner Xen system will not (yet) support HVM again.<br />
<br />
=== How does Xen Work ===<br />
<br />
Q (D3.0): How does Xen process System Calls on para-virtualized guest?<br />
<br />
A (D3.0): When ever a system call is invoked via interrupt or sys center control gets transferred to the kernel (ring 0), which is then handled via system call handler. System call never goes to libc but Libc is a library that provides POSIX interface to the user space applications and in a way wrapper for invocation of a system call. <br />
System call interrupt based [i386]: During booting process, linux kernel of a domU register's its IDT with Xen Hypervisor via HYPERVISOR_set_trap_table(trap_table); [arch/i386/kernel/traps-xen.c]. Xen maintains two IDT's, one global IDT (its own) and other per domain IDT. Xen uses global IDT to register the entire trap handler except for system call handler (int 0x80). When a VM gets scheduled, its system call handler (from per domain IDT table) is registered with the processor. Hence when a domain/VM executes a system call, its own handler is executed. <br />
Implementation differs for x86_64: Xen registers its own system call handler with the processor and from that handler routes the request to VM/Domain specific handler. <br />
<br />
Q (D3.1): How does Xen process System Calls on fully virtualized guest (HVM)?<br />
<br />
A (D3.1): For HVM domU there is no change in the behavior of the system call. HVM is only supported for Intel-VT and AMD-SVM processors. These processors are virtualization aware. Virtualization aware processors provide a new ring (Root-Ring 0) with higher privilege for VMM and Guest OS continues to runs with the same privilege (as without Xen) in Non-Root Ring 0. Guest OS can issue the system calls the way it used to without Xen.<br />
<br />
Q (D3.2): Can I run various DomU operating systems on a different Dom0 operating system?<br />
<br />
A (D3.2): Yes. <br />
<br />
Q (D3.3): Just curious to know, if there is any way that given a terminal to a box, we can determine is it a physical machine or a virtual machine ? <br />
<br />
A (D3.3): You should be able to get some useful information from the DMI, e.g: <br />
% for i in system-manufacturer system-product-name system-version\ system-serial-number; do echo -n "$i: "; sudo dmidecode -s $i; done <br />
system-manufacturer: Xen system-product-name: HVM domU system-version: 3.3.1 system-serial-number: 89e5915f-dead-beef-cefd-46904ea94c4a <br />
OR<br />
Probably checking kernel process, check your process table for: <br />
[xenwatch] [xenbus] <br />
Another clue is checking the kernle suffix, for example: <br />
<!-- # uname -r 2.6.24-23-xen --><br />
and the proc files: <br />
/proc/xen/capabilities <br />
<br />
Q (D3.4): What is STUBDOM ? <br />
<br />
A (D3.4): Stubdoms are lightweight 'service' or 'driver' domains. The initial purpose was to offload qemu (for hvm guests) out of dom0. <br />
So with stubdoms you can run hvm guest qemu in a separate stubdom, which boosts performance and makes it more secure. <br />
stubdoms can also run for example pv-grub for pv guests, making it more secure compared to pygrub, which always runs in dom0. <br />
http://wiki.xensource.com/xenwiki/StubDom <br />
Presentation about stubdoms at Xen Summit: http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf <br />
http://blog.xen.org/index.php/2008/08/28/xen-33-feature-stub-domains/ http://blog.xen.org/index.php/2008/08/28/xen-33-feature-hvm-device-model-domain/ http://lxr.xensource.com/lxr/source/stubdom/README <br />
<br />
Q (D3.5): When is hardware virtualization used in Xen? Is it required?<br />
<br />
A (D3.5): Xen uses hardware virtualization for HVM guests. Xen will not launch a HVM guest unless hardware virtualization is turned on.<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Asking_Xen_User_Questions&diff=5115Asking Xen User Questions2012-09-24T15:18:20Z<p>OliverChick: /* = */ Removed rogue syntax causing an additional header</p>
<hr />
<div><!-- MoinMoin name: XenUsersQuestions --><br />
<!-- Comment: replace stephen.spector with community.manager@xen.org --><br />
<!-- WikiMedia name: XenUsersQuestions --><br />
<!-- Page revision: 00000007 --><br />
<!-- Original date: Tue Jan 25 16:12:06 2011 (1295971926000000) --><br />
<!-- ## Please edit system and help pages ONLY in the moinmaster wiki! For more --><br />
<!-- ## information, please see [[MoinMaster]]:[[MoinPagesEditorGroup]]. --><br />
<!-- ##master-page:[[HomepageReadWritePageTemplate]] --><br />
<!-- ##master-date:Unknown-Date --><br />
<!-- #format wiki --><br />
<!-- #language en --><br />
<br />
{{Needs_Refactor|Needs splitting and moving into the smaller FAQs on [[:Category:FAQ]]}}<br />
<br />
= Xen Users Mailing List Commonly Asked Questions =<br />
<br />
== Introduction ==<br />
This document is a Xen.org community effort to gather the most commonly asked questions from the xen-users emailing list and other support tools to assist new and experienced Xen hypervisor users with problems that frequently arise. If you would like to add content to this document, please send an email to community.manager@xen.org for editing rights if you don't have wiki editing rights already. <br />
For those users interested in trying Xen without installing the application, a Live CD version is available at http://wiki.xensource.com/xenwiki/LiveCD. <br />
<br />
== Support Tools ==<br />
The following sites are available for Xen hypervisor support:<br />
* xen-users mailing list - http://lists.xensource.com/mailman/listinfo/xen-users<br />
* Xen 3.3 Documentation - http://bits.xensource.com/Xen/docs/user.pdf <br />
* Stack Oveflow - http://stackoverflow.com/<br />
* Complete email history of all xen mailing lists - http://xen.markmail.org <br />
* Language Specific Support<br />
** Japanese - http://lists.xensource.com/mailman/listinfo/xen-japanese<br />
** Portuguese - http://groups.google.com/group/xen-br<br />
<br />
== How To Guide Links ==<br />
The Xen.org community Wiki has a [[HowTo]] Page with various information sources at http://wiki.xensource.com/xenwiki/HowTos. Updates to this Wiki page are continuous so check back often for new How Tos. <br />
Sample topics internally within the Wiki are:<br />
* [[XenNetworking| Xen Networking]]<br />
* [[FreeBSDdomU| Xen FreeBSD]]<br />
<br />
Sample topics with external links are:<br />
* Adding USB Devices to Xen HVM - http://www.virtuatopia.com/index.php <br />
* Xen on Fedora - http://rackerhacker.com/2011/08/05/xen-4-1-on-fedora-15-with-linux-3-0/ <br />
* Create and Install CentOS on Xen - http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU <br />
* http://www.virtuatopia.com/index.php/Configuring_a_VNC_based_Graphical_Console_for_a_Xen_Paravirtualized_domainU_Guest<br />
* https://help.ubuntu.com/community/Xen Xen on Ubuntu<br />
<br />
== Guest Related Questions ==<br />
=== Guest Conversion ===<br />
Q (G1.0): How do I convert a Centos HVM Guest to a PV Guest?<br />
<br />
A (G1.0): Creating a Centos HVM domU with working PV drivers : http://pastebin.com/fb6fe631 Converting HVM guest to PV guest : http://pastebin.com/f6a5022bf <br />
If you follow both parts correctly you should have a working PV domU. If anything goes wrong during conversion process, you should still be able to boot the previous HVM domU config if you select the non-xen kernel (second entry) from grub menu.list. <br />
=== Console ===<br />
<br />
Q (G2.0): I have an Xen image that was built for a graphical console (VNC). Is there any way to change it to the non-graphical console (xen console)? <br />
<br />
A (G2.0): For HVM guest, you need to enable serial port on domU config file (example here: http://pastebin.com/fb6fe631), and setup domU to use serial port (ttyS0 on Linux) by modifying (for Linux domU) /boot/grub/menu.lst, /etc/inittab, and /etc/securetty. <br />
If it's PV guest, you need to set up domU to use xen console (which is xvc0 on current xen version, hvc0 on pv_ops kernel). It's similar to setting up domU for serial console, you just need to change ttyS0 to hvc0. An example of domU setup that can use both xvc0 and vnc console is here : http://pastebin.com/f6a5022bf <br />
<br />
Q (G2.1): How do I remove an active virtual machine?<br />
<br />
A (G2.1): xl shutdown or xl delete<br />
<br />
Q (G2.2): How do I run xl console to a WindowsXP DomU?<br />
<br />
A (G2.2): You can't xl console to that (I'm not sure you can xl console to any hvm, but I know you can't to one that doesn't have a console). <br />
<br />
Q (G2.3): I start a new DomainU (Guest) and some text scrolls by for launching the guest but then it just sits there with Continue and no actions takes place? <br />
<br />
A (G2.3): The console for this new DomainU is not properly available for you; fix this by adding xtra="xencons=tty" in the configuration file. This will bring up a login screen directly for your new DomainU. <br />
<br />
Q (G2.4): One of our CentOS 5.3 randomly reboots, at different times of the day, and I can't see why it's doing it. I have looked through the logs, but don't see any thing in there that shows me why it has rebooted. How can I debug this? <br />
<br />
A (G2.4): The problem is that when the box panics, it stops syslogd, so you don't get the panic output in /var/log. The best way to fix this is to setup a logging serial console. <br />
<br />
Q (G2.5): Hi, i want to stop VMs, but when i execute xl destroy vmname the VM disappears completly from mu vm list (xl list) How can I stop them without delete them? <br />
<br />
A (G2.5): You've probably been using "xl create". That's the way it works.<br />
<br />
=== Drivers ===<br />
Q (G3.0): What are the GPLPV Drivers and where can I get them?<br />
<br />
A (G3.0): A collection of open source Window PV drivers that allow Windows to be para-virtualized. They are currently being implemented under the leadership of James Harper. More information on these drivers at:<br />
* http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing<br />
* http://lists.xensource.com/archives/html/xen-users/2009-04/msg00058.html<br />
* http://meadowcourt.org/downloads/<br />
<br />
Q (G3.1): How can I tell if the GPLPV Drivers are loaded correctly?<br />
<br />
A(G3.1): If the drivers are installed correctly there should be a Xen device under 'System Devices' in device manager. <br />
<br />
=== Domain0 ===<br />
Q (G4.0): Why cannot I see all my RAM on my Dom0?<br />
<br />
A (G4.0): Domain 0 is a paravirt VM in reality, so the amount of ram you allocate to it is what you will see when using local tools like free, /proc/meminfo, top, etc. <br />
To see the full system ram, you need to use the xm tools... and in this case, 'xm info' which will show you all the system resources, as opposed to the resources available to dom0. <br />
Also, you have 16GB ram on the system... you probably already know this, but be aware that without a PAE enabled kernel (if you're using 32bit Xen) you'll only see 4GB of this. PAE will allow you to use up to 16, or maybe 32 (I don't remember what the upper limit for PAE enabled Xen is off the top of my head). <br />
<br />
Q (G4.1): Is there any way of checking DomU´s I/O from Dom0? <br />
<br />
A (G4.1): iostat (Debian: sysstat-package) <br />
<br />
Q (G4.2): Can I allocate one CPU to the Dom0 exclusively? <br />
<br />
A (G4.2): Add this to the kernel boot line <br />
* dom0_max_vcpus=1 & dom0_vcpus_pin <br />
* Edit /etc/xen/xend-config.sxp - set “(dom0-cpus 1)†<br />
* Reboot Dom0 <br />
* To try on an active system without a Reboot - <br />
* xm vcpu-set 0 1 xm vcpu-pin 0 0 0 <br />
<br />
Q (G4.3): Running xm info I see the following memory available; what does the free memory mean?<br />
total_memory : 2046 free_memory : 5 <br />
<br />
A (G4.3): Free_memory from "xm info" shows memory not allocated to any domain (inlcuding dom0). "free", "top" (or whatever) shows free memory on that particular domain (in your case, dom0). You can adjust memory allocation per domain using "xm mem-set". <br />
<br />
=== DomainU ===<br />
Q (G5.0): My DomU does not fully start; it shows the following output stopping at Continue...<br />
<br />
$ sudo xm console test<br />
<br />
io scheduler cfq registered<br />
<br />
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize<br />
<br />
Xen virtual console successfully installed as xvc0 Event-channel device installed. netfront: Initialising virtual ethernet driver. i8042.c: No controller found. mice: PS/2 mouse device common for all mice TCP bic registered NET: Registered protocol family 1 <br />
<br />
NET: Registered protocol family 17<br />
<br />
Using IPI No-Shortcut mode xen-vbd: registered block device major 8 blkfront: sda2: barriers enabled XENBUS: Device with no driver: device/console/0 Freeing unused kernel memory: 140k freed kjournald starting. Commit interval 5 seconds <br />
<br />
EXT3-fs: mounted filesystem with ordered data mode.<br />
<br />
* ************************************************************** <br />
* **************************************************************<br />
* * WARNING: Currently emulating unsupported memory accesses **<br />
* * in /lib/tls glibc libraries. The emulation is **<br />
* * slow. To ensure full performance you should **<br />
* * install a 'xen-friendly' (nosegneg) version of **<br />
* * the library, or disable tls support by executing **<br />
* * the following as root: **<br />
* * mv /lib/tls /lib/tls.disabled **<br />
* * Offending process: modprobe (pid=663) **<br />
* **************************************************************<br />
* **************************************************************<br />
Continuing... <br />
<br />
A (G5.0): It might only be that you don't have a VPS physical console, and that your VPS is fully booted, but you can't see it. There are few things to check.<br />
<br />
First, check that your VPS has a "console" device in /dev. Mount your domU filesystem in the dom0, go in /dev and do:<br />
<br />
/dev/MAKEDEV console<br />
<br />
If you are using a modern Xen kernel and hypervisor, you should check the parameters of the startup file. Check that it has the following option:<br />
<br />
extra = "4 TERM=xterm xencons=tty console=tty1"<br />
<br />
Then start your VPS and watch it booting. Note that once it's booted up, you should check that it has a xen friendly libc6 installed (in Debian, you would do "apt-get install libc6-xen").<br />
<br />
Q (G5.1): is there a way to set the credit-scheduler's limits and weights per domU<br />
in the domU configuration file? <br />
<br />
A (G5.1): weight= in the xm config file works, unless you are using RHEL or CentOS. <br />
<br />
Q (G5.2): How do I start an application from within a DomU?<br />
<br />
A (G5.2): Well, you could always just log in to that VM, open a terminal and run the program. <br />
Or you could SSH or telnet in to the VM, start a screen session and run the program. <br />
A VM acts just like any other server, so the proceedure for starting programs and executing commands locally and remotely are exactly the same as doing so on any computer. <br />
<br />
Q (G5.3): My domUs are in a permanent 'b' (blocked) status as shown by 'xm list', even though they are functioning just fine. That's not normal, is it? <br />
<br />
A (G5.3): It's normal for them to show as blocked when they aren't actively running something - in the same way that any process on a 'normal' machine will show as blocked when it's waiting for input, each guest will show as blocked when it's got nothing to do. Give something a processor intensive task to do and you'll find it changes state to running (at least some of the time). <br />
<br />
Q (G5.4): Is there any way, to get the name of a domU from the network-common script? <br />
<br />
A (G5.4): hostname=$(xenstore_read "$XENBUS_PATH/domain" | tr -- '_.:/+' '-----') <br />
<br />
Q (G5.5): Is it possible to increase the screen resolution of my xen guest Windows Vista? <br />
<br />
A (G5.5): On current Xen, with stdvga=1 & videoram=16, resolutions up to 2048x1536x32 are possible. All that said, the RDP suggestion is probably a better way to access the guest in any case. <br />
<br />
Q (G5.6): How to install Solaris via HTTP as a para guest? <br />
<br />
A (G5.6): Solaris 10 can only be used as HVM guest. [[OpenSolaris]] can be used as PV guest, installed from iso. You can't install it from http. Once you have it installed, you also need zfs support for pygrub (either that, or manually copying kernel and boot archive to dom0) <br />
<br />
Boris provides some nice examples on his site : http://bderzhavets.wordpress.com/ <br />
<br />
Q (G5.7): Is it possible to find out the specific vnc Display Number of a domU? <br />
<br />
A (G5.7): virsh vncdisplay domU_name_or_id <br />
xenstore-ls /local/domain/domU_id/console <br />
<br />
Q (G5.8): I am trying to create a guest domain. I specified the configurations in /etc/xen-tools/xen-tools.conf and I ran $sudo xen-create-image --hostname=virtualrouter1 --role=udev the output is: sudo: xen-create-image: command not found <br />
<br />
A (G5.8): Make sure you installed the Xen tools, for example: apt-get install xen-tools <br />
<br />
Q(G5.9): I'm trying to assign a dynamic hostname to a xen instance as follows: <br />
<br />
Cfg file <br />
kernel = "/root/vmlinuz-2.6.18-128.1.14.el5xen" <br />
ramdisk = "/root/initrd-2.6.18-128.1.14.el5xen.img" <br />
memory = 512 <br />
hostname = "uniquehostname" <br />
<!-- #hostname = " uniquehostname.xen.org" --><br />
name = "my-vm-name" <br />
* . . . . <br />
In both the cases, the instance is unable to get the correct hostname.. <br />
<br />
A (G5.9): From "xm create --help_config" : hostname=NAME Set the kernel IP hostname. interface=INTF Set the kernel IP interface name. dhcp=off|dhcp Set the kernel dhcp option. <br />
On most LInux distros, kernel hostname and IP address is ignored, making it somewhat useless. You need to use your normal distro method to set hostname on domU (/etc/sysconfig/network on RHEL) <br />
<br />
Q(G5.10): As far as I can see, there is something different between using 'xm create' and 'xm new' followed by 'xm start'. It's something to do with data being stored in [[XenStore]]. I couldn't suspend the one started with 'xm create'. Could someone please explain the effective difference between the two and when 'create' should be used instead of 'new' and vice-versa. <br />
<br />
A(G5.10): xm create -> domU configuration is NOT managed by xend. Usually using config files on /etc/xen. This is the easiest method to use for beginners, as you have a config file that you can edit manually. The default on RHEL5 (which uses Xen 3.1+). <br />
"xm new" and "xm start" -> domU configuration is managed by xend. You change values using commands like "xm block-attach", which can modify settings online. No config file to edit manually. The default on current versions of Xen. <br />
<br />
G (G5.11): I have problem with domU clock. It lose 30 minutes each day. How can i synchronize it with dom0 clock? <br />
<br />
A (G5.11): Is this PV domU? If yes, setting /proc/sys/xen/independent_wallclock to 0 (the default) should make it sync with dom0. You only need ntp on dom0, and domUs will follow. <br />
The alternative, set /proc/sys/xen/independent_wallclock to 1 and run ntp on domU. If this is a HVM dom0, running ntp on domU is your friend. <br />
Also, check<br />
http://tuttodebian.blogspot.com/2008/05/xen-clocksource0-time-went-backwards.html to see if your system experience similar symptoms. <br />
<br />
G (G5.12): I would like to set sched-cred parameters on my domU configuration file. How can i do that? <br />
<br />
A (G5.12): cpu_cap & cpu_weight <br />
Run "xm create --help_config" for details, and read http://wiki.xensource.com/xenwiki/CreditScheduler <br />
<br />
G (G5.13): Is it possible to increase guest memory without reboot? <br />
<br />
A (G5.13): You can do a "xm mem-set <Domain> <memory>" for a PV domU, but you had to set maxmem higher than current assignment beforehand. <br />
<br />
G (G5.14): Is it possible to take an already created domU sparse file and make it a non sparse file? <br />
<br />
A (G5.14): cp --sparse=never orig.img new.img <br />
<br />
G (G5.15): I have tried to change CD ISO images during a HVM install using the following commands but it doesn't work. After changing the CD ISO image, it doesn't detect the new ISO image. <br />
(qemu) eject -f hdc (qemu) change hdc /media/hitachi/cd-rom-image.iso <br />
<br />
A (G5.15): Use xm block-list <domid> to find the cdrom be-path for the domain, for example: <br />
xm block-list 5 Vdev BE handle state evt-ch ring-ref BE-path 768 0 0 4 9 16383 /local/domain/0/backend/vbd/5/768 5632 0 0 1 -1 -1 /local/domain/0/backend/vbd/5/5632 <br />
Having identified the cdrom device (5632) you can check what iso image it is connected to: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params <br />
(nothing returned) <br />
To connect a new iso image: <br />
xenstore-write /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
And you can now see that it is connected: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
This method works with both emulated devices and with gplpv drivers. <br />
<br />
Q (G5.16): Is it possible to set the xen to boot the domU one by one when server starts, as currently we have 20 domU, and if boot them together, the the hard disk will be very very slow. <br />
<br />
A (G5.16): cd /etc/xen/config/........ && for i in * do ...... (start VM, .....)...... sleep 60 (or whatever time you think <br />
is right to start a VM) done <br />
<br />
Q (G5.17): I use FluidVM on some of our VPS host nodes, and the management server<br />
has crashed, so now I need to recover the running VM's, somehow. FluidVM deploys the domU's on the hostnode dynamically from a database, i.e. there's no /etc/xen/vps1 (for example) config files. The domU's are still running on the servers, and I now want to create config files for them, while they're running.<br />
<br />
How would I be able todo this?<br />
<br />
For example, here's a list of running VM's from one of the servers:<br />
<br />
root@usaxen02:[~]$ xm list<br />
Name ID Mem(MiB) VCPUs State Time(s)<br />
AndriesBurger_39_cronos 90 255 1 -b---- 42.4<br />
Bruce_18_carmen 60 255 1 r----- 3528327.5<br />
Domain-0 0 3433 4 r----- 1116681.7<br />
Rudi_14_mars 40 3007 2 -b---- 953036.3<br />
Rudi_44_vps2 93 255 1 -b---- 22.9<br />
<br />
Is there any way to create a config file, /etc/xen/AndriesBurger_39_cronos, from the running domU<br />
AndriesBurger_39_cronos ?<br />
<br />
A (G5.17):You can use "xm list -l" to dump the configuration in SXP format; then you should be able to use "xm new" or "xm create" with the "-F" option to load an SXP-based config file. See the "xm" man page for more info - that's where I dug up this.<br />
<br />
Q (G5.18): How to set up Xen DomU as Windows 2008 Server on a CentOS Dom0 machine?<br />
<br />
A (G5.18): Start using the normal way that you usually do when you install a HVM domU, whether it's virt-manager/virt-install or using manually-created config file. One additional thing to note is that for 64bit HVM domUs you need to make sure that acpi, apic, and pae is set to 1 on domU config file. <br />
Once you get that Win2008 fully installed, you can install GPLPV driver later to improve performance.<br />
<br />
Q (G5.19): I need to install windows streaming media server on one of my xen3.4.2 guest. Is it possible to create a windows xp paravirtual guest on xen? Like I install other Linux guest as the paravirtual ones. If yes please give some brief steps for that. <br />
<br />
A (G5.19): No, unless you ask Microsoft to port XP kernel to Xen PV model:)<br />
<br />
Judging from the fact that XP was declared end of life several times, and the fact that even Hyper-V requires VT to run, I highly doubt they will ever create PV-enabled windows <br />
<br />
Q (G5.20): I would like to move an existing [[W2K3]] install onto my new super duper xen box -- Installing linux based machine is no issue, it's the windows ones that keep getting me. I have Acronis which we usually use for bare metal restores, and it seems that bare metal restores don't want to work too well with XEN, any assistance/help/ideas ? <br />
<br />
A (G5.20): I have successfully migrated several physical windows 2003 installs to Xen by adding the ide drivers as per http://support.microsoft.com/kb/314082 and then using Acronis True Image to copy the disks.<br />
<br />
One issue I had was that the boot cd created by the version of True Image we have did not boot under Xen (hung on boot screen), but Acronis support sent me a version that did work (TrueImageLinuxServer8072_multiparam_Standard_english_il.iso). However due to using emulated nic and hd running True Image directly under Xen was very slow, my first solution to that problem was to make a small windows hvm install with gplpv drivers loaded and true image installed and then temporarily add the target block device to it in order to write the image, but I recently switched to using a WinPE boot ISO with GPLPV and [[TrueImage]]/Backup And Recovery installed, the Acronis products come with a WinPE/BartPE Image builder utility so its quite easy to do.<br />
<br />
Also watch out for boot.ini, many servers come with a hidden partition on the boot volume for running diagnostics, in which case windows may be booting from the second partition, so you may need to adjust the boot.ini or you could remove it entirely and windows will then attempt to boot from \windows automatically. <br />
<br />
Q (G5.21): Could we add a file image, block device or lvm to domU while it is running without restarting?<br />
<br />
A (G5.21): Use "xm block-attach", and edit domU config file afterwards (if you still you file-based domU config) to make it permanent. Should work great with PV domUs.<br />
<br />
There are cases when you have to reboot the domU anyway though, since the driver installation of a new disk on domU OS could require reboot. One example is when using Windows + GPLPV.<br />
<br />
=== Devices ===<br />
<br />
Q (G6.0): For my xen domUs I'm using a mixture of locah physical partitions (with LVM) and iSCSI disks. For local partitions, I don't have any problem, because LVM volumes are always the same. But for iSCSI disks, devices are assigned in the order they are connected, so I can't be sured that device that now is /dev/sdb (for example) will always be /dev/sdb. <br />
So, is there any way to identify the physical device in the domU configuration not as phy:/dev/sdb, but something like phy:label=fslabel? Or is there any other solution to this problem? <br />
<br />
A (G6.0): I go with phy:/dev/disk/by-path/ip-*-iscsi-iqn.* If you assign iscsi luns directly as domU's fs without additional partitioning, you could probably also use /dev/disk/by-label/* or /dev/disk/by-uuid/*<br />
<br />
== Installation Questions ==<br />
<br />
See [[Xen_FAQ_Installation]]<br />
<br />
=== 32bit vs 64 bit ===<br />
<br />
Q (I2.1): Is there anyway to install 64Bit Linux DomU on 32Bit Linux Dom0? <br />
<br />
A (I2.1): Types of domU that can be run depends mostly on hypervisor, and not dom0. So if you have 64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit. <br />
If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not 64bit PV domU. <br />
<br />
== Networking Questions ==<br />
<br />
=== Bridging ===<br />
<br />
Q (N1.0): Which Mechanism is used by Xen bridging to handle packets coming from various VMs to forward them to their destination <br />
<br />
A (N1.0): Nothing. Xen by itself does not handle bridge. dom0 OS does that. <br />
On Linux dom0 : http://www.linuxfoundation.org/en/Net:Bridge <br />
On opensolaris dom0: http://opensolaris.org/os/project/crossbow/ <br />
IP Determination<br />
<br />
Q (N2.0): I want to know the IP of a running VM in XEN.. Is there any way to have this without login to that VM.. <br />
<br />
A (N2.0): Find domU's mac. This can be easy (if your domU config specify a static MAC).<br />
The easy way to get domU's IP address, you can look at domUs config file (if you specify it), or you can try running this:<br />
xm network-list domU_name <br />
if you get this line <br />
Idx BE MAC Addr. handle state evt-ch tx-/rx-ring-ref BE-path 0 0 00:16:3E:F7:D6:E7 0 4 6 16238/16237 /local/domain/0/backend/vif/163/0 <br />
Then domU's MAC is 00:16:3E:F7:D6:E7 <br />
The hard way to find out your MAC from a bridge, since your bridge is called eth0 you can try: <br />
xm list, note the domain ID (the number) <br />
- brctl showstp eth0 that should show which interface is identified as which "port". For example if your domU has an ID 163, look for the lines that has "vif163.0" or "tap163.0". If the line looks like this <br />
vif163.0 (11) <br />
then that vif is identified as port 11 on the bridge. <br />
- brctl showmacs eth0 Look for the port corresponding to the port above. If you get this line <br />
11 00:16:3e:f7:d6:e7 no 0.96 <br />
then on port11 (where your domU interface is) there's a MAC address 00:16:3e:f7:d6:e7. <br />
Now that you have domU's mac, you try snooping the bridge for that MAC. For example : <br />
# tcpdump -n -i eth0 ether src 00:16:3e:f7:d6:e7 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:54:56.419482 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 1, length 64 15:54:57.422349 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 2, length 64 <br />
Then you know that domU has IP address 10.0.0.10. <br />
NAT<br />
<br />
Q (N3.0): I managed to configure NAT on dom0 but this does not work properly. Outgoing traffic from domU is seen with the original domU ip address instead of the dom0 ip address and the requests can't get back to the domU. <br />
<br />
A (N3.0): I figured out MASQUERADING was not set. <br />
The following rule needs to be set: <br />
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE <br />
<br />
SSL/VPN<br />
<br />
Q (N4.0): Way can't i use openvpn with a xen guest I can't load the tun module <br />
<br />
A (N4.0): From openvpn perspective, the requirements for openvpn on xen domU is the same as openvpn on native Linux. If you can't load tun module, then you need to get a kernel that supports it. <br />
The easiest way is to use a distro that supports it. For example, I'm using RHEL/Centos 5.3 domU, loaded with pygrub, and they can run openvpn just fine. <br />
Another alternative is compile your own kernel with tun/tap support. <br />
<br />
=== General ===<br />
<br />
Q (N5.0): I want to ask how to mount one storage device to 2 guests? When I try to create vm handle everything is fine I can create one vdi and vbds for every guest. When I start first machine everything is ok, but when I try to start second one it says that<br />
<br />
ERROR: 2 INTERNAL_ERROR Device 2051 (vbd) could not be connected.<br />
Device /dev/mapper/test_vg-test64_454 is mounted in a guest domain,<br />
and so cannot be mounted now.<br />
<br />
Ideas how I can share one device to two or more virtual machines? I don't want network solution like nfs,iscsi ... etc but instead use ocfs2. How I can set mode to w! ? <br />
<br />
A (N5.0): First of all, you DO realize that sharing a block device without some kind of cluster file system could lead to data corruption? If you want to share it anyway, you can try changing the mode to "r"(for read only) or "w!" (to force read-write multiple mount). <br />
in your domU.cfg:<br />
<br />
'phy:/dev/data/bla-disk,sda1,w' => 'phy:/dev/data/bla-disk,sda1,r'<br />
<br />
Q (N5.1): I'm looking for a way to monitor network activities of processes in Guest OS. I want to get a list of Guest OS processes that open TCP connections to other machines (like "lsof" command). <br />
<br />
A (N5.1): If you're thinking about doing on from dom0, that's not possible. You need something that runs on domU for that, possibly by using snmpd and extending it to run "netstat -anp --tcp". Other host (including dom0) can then collect the information using snmp. <br />
Also, have a look at Versiera, it provides what you are looking for including, user<br />
IDs, inbound/outbound communications, IPv4, IPV6, etc. There are many more<br />
capabilities. Versiera is not open-source, but the Internet self-manage service<br />
is free. <br />
<br />
Q (N5.2): I’m attempting to gather stats on usage of the “metalâ€, by which I mean the physical host’s hardware. I would like to know the CPU, IO, and network stats for the hardware. <br />
<br />
A (N5.2): All DomU's IO passes through Dom0. there you can measure all you want. <br />
for disk IO, if you use phy: devices, you can use iostat to see the usage of each device. if you use file-based backends, it would be easier to check the userspace daemons. maybe iotop would help. in any case, if aggregate usage is all you need, just measure the disk usage seen at Dom0 <br />
for network, if you can measure at peth0, that would give you the aggregate usage. if you need stats for each DomU, check the respective tun devices. <br />
<br />
Q (N5.3): I have some trouble finding the best solution to my networking requirements. <br />
I want to have the following things: <br />
-dom0 : have 2 physical networks devices * 1 eth with public IP (static) * 1 eth with private IP (static) <br />
-domU * 1 eth with private IP <br />
-I also want openVPN solution to let people outside the private network have access to it. <br />
-A DHCP server is required so that domU get their IP from it. <br />
I have debian lenny and xen 3.2 installed and working. Actually openvpn and dhcp are on the dom0. All is fine *except* that domU don't have access to internet (this is my main problem). My current config use network-bridge netdev=eth1 (eth1 have a static private ip). <br />
It is perhaps better to have dhcp and openvpn server in a domU, feel free to suggest what you think is the best choice (and the config that go with it) :) <br />
<br />
A (N5.3): When designing such setups, with bridge networking, I often find it easier to think of dom0 as a switch or router, and domU like any other physical server on your network. <br />
In your setup you're making dom0 act as router/firewall. Your problem is that probably you haven't setup ip forwarding and NAT on dom0 to allow domU internet access. <br />
Note that (if you want) you could also have dom0 act like a switch. In that scenario you'd need another domU, with two network interfaces connected to both dom0's eth0 and eth1, acting as router/firewall. <br />
<br />
Q (N5.4): I have been trying to get a HVM DomU running and being able to connect to a vlan. I am starting to get the feeling that at least the hw emulations I have tried do not supoprt vlans. Also all the things I have found online would have me creating the vlans inside the Dom0 and pushing them to the DomU's as regular interface<br />
<br />
A (N5.4): You could always have a trunk port in your dom0 and create bridges for each VLAN for xen. <br />
You can even script it so you can add it to boot time. <br />
If you have the VLAN trunk set up, you can create bridges as follows. <br />
For this example, my trunk interface is on eth0 and the vlan I am adding is 2. <br />
<!-- # vconfig add eth0 2 # brctl addbr xenbr2 # brctl addif xenbr2 eth0.2 # ifconfig eth0.2 up # ifconfig xenbr2 up --><br />
Now all you would add in the domU configuration file is: <br />
vif=['bridge=xenbr2'] <br />
And you would be on VLAN 2. <br />
Otherwise I'm pretty sure you would have to pass through the network card to get VLAN access. <br />
You can also script this and give it a space separated list of VLANs and loop it through. I will leave this up to you though. <br />
<br />
== High Availability Questions ==<br />
=== Services ===<br />
<br />
Q (HA1.0): What software exists for Xen to handle high availability? <br />
<br />
A (HA1.0): Here are several tools that currently exist:<br />
CentOS Cluster<br />
Project Kemari - http://www.osrg.net/kemari/<br />
Project Remus - http://blog.xen.org/index.php/2009/04/02/project-remus-released/<br />
Linux Cluster Resource Manager - http://clusterlabs.org/mediawiki/images/f/fb/Configuration_Explained.pdf <br />
<br />
Q (HA1.1): I'm not sure about how snapshots works on Xen. For example, if I snapshot a DomU with 10GB HD will take, for example, 30 seconds. But, if I snapshot a DomU with a 100GB HD will take longer (I guess). <br />
So, I wanna know how the snapshot works on xen. What if I want to move a snapshotted with a 100GB HD from a Dom0 to another Dom0? I've to move a 100GB file? <br />
<br />
A (HA1.1): You could try this approach: <br />
http://www.infohit.net/blog/post/using-lvm2-snapshots-to-provide-rollback-functionality-for-xen.html <br />
Makes snapshots quite quick. <br />
<br />
== Performance Questions ==<br />
<br />
== Security Questions ==<br />
<br />
Q(S1.0): If I install minimal linux for XEN in dom0 and a periphery firewall in domU and other applications in other instances of domU, is it possible to restrict/bind the network card to domU having periphery firewall and from there forward packets for dom0 or for other domUs? <br />
Is this possible? If so, is it secure? Or does dom0 always have direct access to Network Card and needs a separate firewall? And packets will always route from dom0 to all domUs ? <br />
What are the issues involved? <br />
<br />
A(S1.0): The approach I've used at home is to hide a network card from Dom0 (see pic-back.hide) and pass it through to a DomU which then sees it as a native interface. I then run a firewall in the DomU and the outside traffic does NOT go through Dom0. The route for packets is then : <br />
real i/f -> DomU (firewall) -> VIF -> int bridge [ Dom0 | VIF -> DomU ] <br />
From security perspective, this is the same as having an L2 switch (when dom0's bridges have no IP address) or L3 switch (when dom0's bridges have an IP address) <br />
<br />
Q(S1.1): I want to use a Disk Encryption and the conplete physikal Disk in a DomU. I prefere Truecrypt or Loop-aes. i will going to test loop-aes cause it should have the better performance. <br />
But, did anybody here using truecrypt or loop-aes ? What is the better one, in the fact of speed ? <br />
<br />
A(S1.1): dm-crypt/luks is one option, and performs about the same or better than loop-aes. Also it's less problematic because it doesn't use loop devic<br />
<br />
== Design/Misc Questions ==<br />
=== Nested Xen ===<br />
Q (D1.0): Can I run Xen within Xen? <br />
<br />
A (D1.0): Yes, You can install Xen on the base system, create a HVM domain, and install Xen in that guest domain. Note that the inner Xen system will not (yet) support HVM again.<br />
<br />
=== How does Xen Work ===<br />
<br />
Q (D3.0): How does Xen process System Calls on para-virtualized guest?<br />
<br />
A (D3.0): When ever a system call is invoked via interrupt or sys center control gets transferred to the kernel (ring 0), which is then handled via system call handler. System call never goes to libc but Libc is a library that provides POSIX interface to the user space applications and in a way wrapper for invocation of a system call. <br />
System call interrupt based [i386]: During booting process, linux kernel of a domU register's its IDT with Xen Hypervisor via HYPERVISOR_set_trap_table(trap_table); [arch/i386/kernel/traps-xen.c]. Xen maintains two IDT's, one global IDT (its own) and other per domain IDT. Xen uses global IDT to register the entire trap handler except for system call handler (int 0x80). When a VM gets scheduled, its system call handler (from per domain IDT table) is registered with the processor. Hence when a domain/VM executes a system call, its own handler is executed. <br />
Implementation differs for x86_64: Xen registers its own system call handler with the processor and from that handler routes the request to VM/Domain specific handler. <br />
<br />
Q (D3.1): How does Xen process System Calls on fully virtualized guest (HVM)?<br />
<br />
A (D3.1): For HVM domU there is no change in the behavior of the system call. HVM is only supported for Intel-VT and AMD-SVM processors. These processors are virtualization aware. Virtualization aware processors provide a new ring (Root-Ring 0) with higher privilege for VMM and Guest OS continues to runs with the same privilege (as without Xen) in Non-Root Ring 0. Guest OS can issue the system calls the way it used to without Xen.<br />
<br />
Q (D3.2): Can I run various DomU operating systems on a different Dom0 operating system?<br />
<br />
A (D3.2): Yes. <br />
<br />
Q (D3.3): Just curious to know, if there is any way that given a terminal to a box, we can determine is it a physical machine or a virtual machine ? <br />
<br />
A (D3.3): You should be able to get some useful information from the DMI, e.g: <br />
% for i in system-manufacturer system-product-name system-version\ system-serial-number; do echo -n "$i: "; sudo dmidecode -s $i; done <br />
system-manufacturer: Xen system-product-name: HVM domU system-version: 3.3.1 system-serial-number: 89e5915f-dead-beef-cefd-46904ea94c4a <br />
OR<br />
Probably checking kernel process, check your process table for: <br />
[xenwatch] [xenbus] <br />
Another clue is checking the kernle suffix, for example: <br />
<!-- # uname -r 2.6.24-23-xen --><br />
and the proc files: <br />
/proc/xen/capabilities <br />
<br />
Q (D3.4): What is STUBDOM ? <br />
<br />
A (D3.4): Stubdoms are lightweight 'service' or 'driver' domains. The initial purpose was to offload qemu (for hvm guests) out of dom0. <br />
So with stubdoms you can run hvm guest qemu in a separate stubdom, which boosts performance and makes it more secure. <br />
stubdoms can also run for example pv-grub for pv guests, making it more secure compared to pygrub, which always runs in dom0. <br />
http://wiki.xensource.com/xenwiki/StubDom <br />
Presentation about stubdoms at Xen Summit: http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf <br />
http://blog.xen.org/index.php/2008/08/28/xen-33-feature-stub-domains/ http://blog.xen.org/index.php/2008/08/28/xen-33-feature-hvm-device-model-domain/ http://lxr.xensource.com/lxr/source/stubdom/README <br />
<br />
Q (D3.5): When is hardware virtualization used in Xen? Is it required?<br />
<br />
A (D3.5): Xen uses hardware virtualization for HVM guests. Xen will not launch a HVM guest unless hardware virtualization is turned on.<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Asking_Xen_User_Questions&diff=5114Asking Xen User Questions2012-09-24T15:17:46Z<p>OliverChick: /* File Systems */ Duplicate Q&As. I have improved the other version, so replacing these with a link</p>
<hr />
<div><!-- MoinMoin name: XenUsersQuestions --><br />
<!-- Comment: replace stephen.spector with community.manager@xen.org --><br />
<!-- WikiMedia name: XenUsersQuestions --><br />
<!-- Page revision: 00000007 --><br />
<!-- Original date: Tue Jan 25 16:12:06 2011 (1295971926000000) --><br />
<!-- ## Please edit system and help pages ONLY in the moinmaster wiki! For more --><br />
<!-- ## information, please see [[MoinMaster]]:[[MoinPagesEditorGroup]]. --><br />
<!-- ##master-page:[[HomepageReadWritePageTemplate]] --><br />
<!-- ##master-date:Unknown-Date --><br />
<!-- #format wiki --><br />
<!-- #language en --><br />
<br />
{{Needs_Refactor|Needs splitting and moving into the smaller FAQs on [[:Category:FAQ]]}}<br />
<br />
= Xen Users Mailing List Commonly Asked Questions =<br />
<br />
== Introduction ==<br />
This document is a Xen.org community effort to gather the most commonly asked questions from the xen-users emailing list and other support tools to assist new and experienced Xen hypervisor users with problems that frequently arise. If you would like to add content to this document, please send an email to community.manager@xen.org for editing rights if you don't have wiki editing rights already. <br />
For those users interested in trying Xen without installing the application, a Live CD version is available at http://wiki.xensource.com/xenwiki/LiveCD. <br />
<br />
== Support Tools ==<br />
The following sites are available for Xen hypervisor support:<br />
* xen-users mailing list - http://lists.xensource.com/mailman/listinfo/xen-users<br />
* Xen 3.3 Documentation - http://bits.xensource.com/Xen/docs/user.pdf <br />
* Stack Oveflow - http://stackoverflow.com/<br />
* Complete email history of all xen mailing lists - http://xen.markmail.org <br />
* Language Specific Support<br />
** Japanese - http://lists.xensource.com/mailman/listinfo/xen-japanese<br />
** Portuguese - http://groups.google.com/group/xen-br<br />
<br />
== How To Guide Links ==<br />
The Xen.org community Wiki has a [[HowTo]] Page with various information sources at http://wiki.xensource.com/xenwiki/HowTos. Updates to this Wiki page are continuous so check back often for new How Tos. <br />
Sample topics internally within the Wiki are:<br />
* [[XenNetworking| Xen Networking]]<br />
* [[FreeBSDdomU| Xen FreeBSD]]<br />
<br />
Sample topics with external links are:<br />
* Adding USB Devices to Xen HVM - http://www.virtuatopia.com/index.php <br />
* Xen on Fedora - http://rackerhacker.com/2011/08/05/xen-4-1-on-fedora-15-with-linux-3-0/ <br />
* Create and Install CentOS on Xen - http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU <br />
* http://www.virtuatopia.com/index.php/Configuring_a_VNC_based_Graphical_Console_for_a_Xen_Paravirtualized_domainU_Guest<br />
* https://help.ubuntu.com/community/Xen Xen on Ubuntu<br />
<br />
== Guest Related Questions ==<br />
=== Guest Conversion ===<br />
Q (G1.0): How do I convert a Centos HVM Guest to a PV Guest?<br />
<br />
A (G1.0): Creating a Centos HVM domU with working PV drivers : http://pastebin.com/fb6fe631 Converting HVM guest to PV guest : http://pastebin.com/f6a5022bf <br />
If you follow both parts correctly you should have a working PV domU. If anything goes wrong during conversion process, you should still be able to boot the previous HVM domU config if you select the non-xen kernel (second entry) from grub menu.list. <br />
=== Console ===<br />
<br />
Q (G2.0): I have an Xen image that was built for a graphical console (VNC). Is there any way to change it to the non-graphical console (xen console)? <br />
<br />
A (G2.0): For HVM guest, you need to enable serial port on domU config file (example here: http://pastebin.com/fb6fe631), and setup domU to use serial port (ttyS0 on Linux) by modifying (for Linux domU) /boot/grub/menu.lst, /etc/inittab, and /etc/securetty. <br />
If it's PV guest, you need to set up domU to use xen console (which is xvc0 on current xen version, hvc0 on pv_ops kernel). It's similar to setting up domU for serial console, you just need to change ttyS0 to hvc0. An example of domU setup that can use both xvc0 and vnc console is here : http://pastebin.com/f6a5022bf <br />
<br />
Q (G2.1): How do I remove an active virtual machine?<br />
<br />
A (G2.1): xl shutdown or xl delete<br />
<br />
Q (G2.2): How do I run xl console to a WindowsXP DomU?<br />
<br />
A (G2.2): You can't xl console to that (I'm not sure you can xl console to any hvm, but I know you can't to one that doesn't have a console). <br />
<br />
Q (G2.3): I start a new DomainU (Guest) and some text scrolls by for launching the guest but then it just sits there with Continue and no actions takes place? <br />
<br />
A (G2.3): The console for this new DomainU is not properly available for you; fix this by adding xtra="xencons=tty" in the configuration file. This will bring up a login screen directly for your new DomainU. <br />
<br />
Q (G2.4): One of our CentOS 5.3 randomly reboots, at different times of the day, and I can't see why it's doing it. I have looked through the logs, but don't see any thing in there that shows me why it has rebooted. How can I debug this? <br />
<br />
A (G2.4): The problem is that when the box panics, it stops syslogd, so you don't get the panic output in /var/log. The best way to fix this is to setup a logging serial console. <br />
<br />
Q (G2.5): Hi, i want to stop VMs, but when i execute xl destroy vmname the VM disappears completly from mu vm list (xl list) How can I stop them without delete them? <br />
<br />
A (G2.5): You've probably been using "xl create". That's the way it works.<br />
<br />
=== Drivers ===<br />
Q (G3.0): What are the GPLPV Drivers and where can I get them?<br />
<br />
A (G3.0): A collection of open source Window PV drivers that allow Windows to be para-virtualized. They are currently being implemented under the leadership of James Harper. More information on these drivers at:<br />
* http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing<br />
* http://lists.xensource.com/archives/html/xen-users/2009-04/msg00058.html<br />
* http://meadowcourt.org/downloads/<br />
<br />
Q (G3.1): How can I tell if the GPLPV Drivers are loaded correctly?<br />
<br />
A(G3.1): If the drivers are installed correctly there should be a Xen device under 'System Devices' in device manager. <br />
<br />
=== Domain0 ===<br />
Q (G4.0): Why cannot I see all my RAM on my Dom0?<br />
<br />
A (G4.0): Domain 0 is a paravirt VM in reality, so the amount of ram you allocate to it is what you will see when using local tools like free, /proc/meminfo, top, etc. <br />
To see the full system ram, you need to use the xm tools... and in this case, 'xm info' which will show you all the system resources, as opposed to the resources available to dom0. <br />
Also, you have 16GB ram on the system... you probably already know this, but be aware that without a PAE enabled kernel (if you're using 32bit Xen) you'll only see 4GB of this. PAE will allow you to use up to 16, or maybe 32 (I don't remember what the upper limit for PAE enabled Xen is off the top of my head). <br />
<br />
Q (G4.1): Is there any way of checking DomU´s I/O from Dom0? <br />
<br />
A (G4.1): iostat (Debian: sysstat-package) <br />
<br />
Q (G4.2): Can I allocate one CPU to the Dom0 exclusively? <br />
<br />
A (G4.2): Add this to the kernel boot line <br />
* dom0_max_vcpus=1 & dom0_vcpus_pin <br />
* Edit /etc/xen/xend-config.sxp - set “(dom0-cpus 1)†<br />
* Reboot Dom0 <br />
* To try on an active system without a Reboot - <br />
* xm vcpu-set 0 1 xm vcpu-pin 0 0 0 <br />
<br />
Q (G4.3): Running xm info I see the following memory available; what does the free memory mean?<br />
total_memory : 2046 free_memory : 5 <br />
<br />
A (G4.3): Free_memory from "xm info" shows memory not allocated to any domain (inlcuding dom0). "free", "top" (or whatever) shows free memory on that particular domain (in your case, dom0). You can adjust memory allocation per domain using "xm mem-set". <br />
<br />
=== DomainU ===<br />
Q (G5.0): My DomU does not fully start; it shows the following output stopping at Continue...<br />
<br />
$ sudo xm console test<br />
<br />
io scheduler cfq registered<br />
<br />
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize<br />
<br />
Xen virtual console successfully installed as xvc0 Event-channel device installed. netfront: Initialising virtual ethernet driver. i8042.c: No controller found. mice: PS/2 mouse device common for all mice TCP bic registered NET: Registered protocol family 1 <br />
<br />
NET: Registered protocol family 17<br />
<br />
Using IPI No-Shortcut mode xen-vbd: registered block device major 8 blkfront: sda2: barriers enabled XENBUS: Device with no driver: device/console/0 Freeing unused kernel memory: 140k freed kjournald starting. Commit interval 5 seconds <br />
<br />
EXT3-fs: mounted filesystem with ordered data mode.<br />
<br />
* ************************************************************** <br />
* **************************************************************<br />
* * WARNING: Currently emulating unsupported memory accesses **<br />
* * in /lib/tls glibc libraries. The emulation is **<br />
* * slow. To ensure full performance you should **<br />
* * install a 'xen-friendly' (nosegneg) version of **<br />
* * the library, or disable tls support by executing **<br />
* * the following as root: **<br />
* * mv /lib/tls /lib/tls.disabled **<br />
* * Offending process: modprobe (pid=663) **<br />
* **************************************************************<br />
* **************************************************************<br />
Continuing... <br />
<br />
A (G5.0): It might only be that you don't have a VPS physical console, and that your VPS is fully booted, but you can't see it. There are few things to check.<br />
<br />
First, check that your VPS has a "console" device in /dev. Mount your domU filesystem in the dom0, go in /dev and do:<br />
<br />
/dev/MAKEDEV console<br />
<br />
If you are using a modern Xen kernel and hypervisor, you should check the parameters of the startup file. Check that it has the following option:<br />
<br />
extra = "4 TERM=xterm xencons=tty console=tty1"<br />
<br />
Then start your VPS and watch it booting. Note that once it's booted up, you should check that it has a xen friendly libc6 installed (in Debian, you would do "apt-get install libc6-xen").<br />
<br />
Q (G5.1): is there a way to set the credit-scheduler's limits and weights per domU<br />
in the domU configuration file? <br />
<br />
A (G5.1): weight= in the xm config file works, unless you are using RHEL or CentOS. <br />
<br />
Q (G5.2): How do I start an application from within a DomU?<br />
<br />
A (G5.2): Well, you could always just log in to that VM, open a terminal and run the program. <br />
Or you could SSH or telnet in to the VM, start a screen session and run the program. <br />
A VM acts just like any other server, so the proceedure for starting programs and executing commands locally and remotely are exactly the same as doing so on any computer. <br />
<br />
Q (G5.3): My domUs are in a permanent 'b' (blocked) status as shown by 'xm list', even though they are functioning just fine. That's not normal, is it? <br />
<br />
A (G5.3): It's normal for them to show as blocked when they aren't actively running something - in the same way that any process on a 'normal' machine will show as blocked when it's waiting for input, each guest will show as blocked when it's got nothing to do. Give something a processor intensive task to do and you'll find it changes state to running (at least some of the time). <br />
<br />
Q (G5.4): Is there any way, to get the name of a domU from the network-common script? <br />
<br />
A (G5.4): hostname=$(xenstore_read "$XENBUS_PATH/domain" | tr -- '_.:/+' '-----') <br />
<br />
Q (G5.5): Is it possible to increase the screen resolution of my xen guest Windows Vista? <br />
<br />
A (G5.5): On current Xen, with stdvga=1 & videoram=16, resolutions up to 2048x1536x32 are possible. All that said, the RDP suggestion is probably a better way to access the guest in any case. <br />
<br />
Q (G5.6): How to install Solaris via HTTP as a para guest? <br />
<br />
A (G5.6): Solaris 10 can only be used as HVM guest. [[OpenSolaris]] can be used as PV guest, installed from iso. You can't install it from http. Once you have it installed, you also need zfs support for pygrub (either that, or manually copying kernel and boot archive to dom0) <br />
<br />
Boris provides some nice examples on his site : http://bderzhavets.wordpress.com/ <br />
<br />
Q (G5.7): Is it possible to find out the specific vnc Display Number of a domU? <br />
<br />
A (G5.7): virsh vncdisplay domU_name_or_id <br />
xenstore-ls /local/domain/domU_id/console <br />
<br />
Q (G5.8): I am trying to create a guest domain. I specified the configurations in /etc/xen-tools/xen-tools.conf and I ran $sudo xen-create-image --hostname=virtualrouter1 --role=udev the output is: sudo: xen-create-image: command not found <br />
<br />
A (G5.8): Make sure you installed the Xen tools, for example: apt-get install xen-tools <br />
<br />
Q(G5.9): I'm trying to assign a dynamic hostname to a xen instance as follows: <br />
<br />
Cfg file <br />
=== == <br />
kernel = "/root/vmlinuz-2.6.18-128.1.14.el5xen" <br />
ramdisk = "/root/initrd-2.6.18-128.1.14.el5xen.img" <br />
memory = 512 <br />
hostname = "uniquehostname" <br />
<!-- #hostname = " uniquehostname.xen.org" --><br />
name = "my-vm-name" <br />
* . . . . <br />
In both the cases, the instance is unable to get the correct hostname.. <br />
<br />
A (G5.9): From "xm create --help_config" : hostname=NAME Set the kernel IP hostname. interface=INTF Set the kernel IP interface name. dhcp=off|dhcp Set the kernel dhcp option. <br />
On most LInux distros, kernel hostname and IP address is ignored, making it somewhat useless. You need to use your normal distro method to set hostname on domU (/etc/sysconfig/network on RHEL) <br />
<br />
Q(G5.10): As far as I can see, there is something different between using 'xm create' and 'xm new' followed by 'xm start'. It's something to do with data being stored in [[XenStore]]. I couldn't suspend the one started with 'xm create'. Could someone please explain the effective difference between the two and when 'create' should be used instead of 'new' and vice-versa. <br />
<br />
A(G5.10): xm create -> domU configuration is NOT managed by xend. Usually using config files on /etc/xen. This is the easiest method to use for beginners, as you have a config file that you can edit manually. The default on RHEL5 (which uses Xen 3.1+). <br />
"xm new" and "xm start" -> domU configuration is managed by xend. You change values using commands like "xm block-attach", which can modify settings online. No config file to edit manually. The default on current versions of Xen. <br />
<br />
G (G5.11): I have problem with domU clock. It lose 30 minutes each day. How can i synchronize it with dom0 clock? <br />
<br />
A (G5.11): Is this PV domU? If yes, setting /proc/sys/xen/independent_wallclock to 0 (the default) should make it sync with dom0. You only need ntp on dom0, and domUs will follow. <br />
The alternative, set /proc/sys/xen/independent_wallclock to 1 and run ntp on domU. If this is a HVM dom0, running ntp on domU is your friend. <br />
Also, check<br />
http://tuttodebian.blogspot.com/2008/05/xen-clocksource0-time-went-backwards.html to see if your system experience similar symptoms. <br />
<br />
G (G5.12): I would like to set sched-cred parameters on my domU configuration file. How can i do that? <br />
<br />
A (G5.12): cpu_cap & cpu_weight <br />
Run "xm create --help_config" for details, and read http://wiki.xensource.com/xenwiki/CreditScheduler <br />
<br />
G (G5.13): Is it possible to increase guest memory without reboot? <br />
<br />
A (G5.13): You can do a "xm mem-set <Domain> <memory>" for a PV domU, but you had to set maxmem higher than current assignment beforehand. <br />
<br />
G (G5.14): Is it possible to take an already created domU sparse file and make it a non sparse file? <br />
<br />
A (G5.14): cp --sparse=never orig.img new.img <br />
<br />
G (G5.15): I have tried to change CD ISO images during a HVM install using the following commands but it doesn't work. After changing the CD ISO image, it doesn't detect the new ISO image. <br />
(qemu) eject -f hdc (qemu) change hdc /media/hitachi/cd-rom-image.iso <br />
<br />
A (G5.15): Use xm block-list <domid> to find the cdrom be-path for the domain, for example: <br />
xm block-list 5 Vdev BE handle state evt-ch ring-ref BE-path 768 0 0 4 9 16383 /local/domain/0/backend/vbd/5/768 5632 0 0 1 -1 -1 /local/domain/0/backend/vbd/5/5632 <br />
Having identified the cdrom device (5632) you can check what iso image it is connected to: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params <br />
(nothing returned) <br />
To connect a new iso image: <br />
xenstore-write /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
And you can now see that it is connected: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
This method works with both emulated devices and with gplpv drivers. <br />
<br />
Q (G5.16): Is it possible to set the xen to boot the domU one by one when server starts, as currently we have 20 domU, and if boot them together, the the hard disk will be very very slow. <br />
<br />
A (G5.16): cd /etc/xen/config/........ && for i in * do ...... (start VM, .....)...... sleep 60 (or whatever time you think <br />
is right to start a VM) done <br />
<br />
Q (G5.17): I use FluidVM on some of our VPS host nodes, and the management server<br />
has crashed, so now I need to recover the running VM's, somehow. FluidVM deploys the domU's on the hostnode dynamically from a database, i.e. there's no /etc/xen/vps1 (for example) config files. The domU's are still running on the servers, and I now want to create config files for them, while they're running.<br />
<br />
How would I be able todo this?<br />
<br />
For example, here's a list of running VM's from one of the servers:<br />
<br />
root@usaxen02:[~]$ xm list<br />
Name ID Mem(MiB) VCPUs State Time(s)<br />
AndriesBurger_39_cronos 90 255 1 -b---- 42.4<br />
Bruce_18_carmen 60 255 1 r----- 3528327.5<br />
Domain-0 0 3433 4 r----- 1116681.7<br />
Rudi_14_mars 40 3007 2 -b---- 953036.3<br />
Rudi_44_vps2 93 255 1 -b---- 22.9<br />
<br />
Is there any way to create a config file, /etc/xen/AndriesBurger_39_cronos, from the running domU<br />
AndriesBurger_39_cronos ?<br />
<br />
A (G5.17):You can use "xm list -l" to dump the configuration in SXP format; then you should be able to use "xm new" or "xm create" with the "-F" option to load an SXP-based config file. See the "xm" man page for more info - that's where I dug up this.<br />
<br />
Q (G5.18): How to set up Xen DomU as Windows 2008 Server on a CentOS Dom0 machine?<br />
<br />
A (G5.18): Start using the normal way that you usually do when you install a HVM domU, whether it's virt-manager/virt-install or using manually-created config file. One additional thing to note is that for 64bit HVM domUs you need to make sure that acpi, apic, and pae is set to 1 on domU config file. <br />
Once you get that Win2008 fully installed, you can install GPLPV driver later to improve performance.<br />
<br />
Q (G5.19): I need to install windows streaming media server on one of my xen3.4.2 guest. Is it possible to create a windows xp paravirtual guest on xen? Like I install other Linux guest as the paravirtual ones. If yes please give some brief steps for that. <br />
<br />
A (G5.19): No, unless you ask Microsoft to port XP kernel to Xen PV model:)<br />
<br />
Judging from the fact that XP was declared end of life several times, and the fact that even Hyper-V requires VT to run, I highly doubt they will ever create PV-enabled windows <br />
<br />
Q (G5.20): I would like to move an existing [[W2K3]] install onto my new super duper xen box -- Installing linux based machine is no issue, it's the windows ones that keep getting me. I have Acronis which we usually use for bare metal restores, and it seems that bare metal restores don't want to work too well with XEN, any assistance/help/ideas ? <br />
<br />
A (G5.20): I have successfully migrated several physical windows 2003 installs to Xen by adding the ide drivers as per http://support.microsoft.com/kb/314082 and then using Acronis True Image to copy the disks.<br />
<br />
One issue I had was that the boot cd created by the version of True Image we have did not boot under Xen (hung on boot screen), but Acronis support sent me a version that did work (TrueImageLinuxServer8072_multiparam_Standard_english_il.iso). However due to using emulated nic and hd running True Image directly under Xen was very slow, my first solution to that problem was to make a small windows hvm install with gplpv drivers loaded and true image installed and then temporarily add the target block device to it in order to write the image, but I recently switched to using a WinPE boot ISO with GPLPV and [[TrueImage]]/Backup And Recovery installed, the Acronis products come with a WinPE/BartPE Image builder utility so its quite easy to do.<br />
<br />
Also watch out for boot.ini, many servers come with a hidden partition on the boot volume for running diagnostics, in which case windows may be booting from the second partition, so you may need to adjust the boot.ini or you could remove it entirely and windows will then attempt to boot from \windows automatically. <br />
<br />
Q (G5.21): Could we add a file image, block device or lvm to domU while it is running without restarting?<br />
<br />
A (G5.21): Use "xm block-attach", and edit domU config file afterwards (if you still you file-based domU config) to make it permanent. Should work great with PV domUs.<br />
<br />
There are cases when you have to reboot the domU anyway though, since the driver installation of a new disk on domU OS could require reboot. One example is when using Windows + GPLPV.<br />
<br />
=== Devices ===<br />
<br />
Q (G6.0): For my xen domUs I'm using a mixture of locah physical partitions (with LVM) and iSCSI disks. For local partitions, I don't have any problem, because LVM volumes are always the same. But for iSCSI disks, devices are assigned in the order they are connected, so I can't be sured that device that now is /dev/sdb (for example) will always be /dev/sdb. <br />
So, is there any way to identify the physical device in the domU configuration not as phy:/dev/sdb, but something like phy:label=fslabel? Or is there any other solution to this problem? <br />
<br />
A (G6.0): I go with phy:/dev/disk/by-path/ip-*-iscsi-iqn.* If you assign iscsi luns directly as domU's fs without additional partitioning, you could probably also use /dev/disk/by-label/* or /dev/disk/by-uuid/*<br />
<br />
== Installation Questions ==<br />
<br />
See [[Xen_FAQ_Installation]]<br />
<br />
=== 32bit vs 64 bit ===<br />
<br />
Q (I2.1): Is there anyway to install 64Bit Linux DomU on 32Bit Linux Dom0? <br />
<br />
A (I2.1): Types of domU that can be run depends mostly on hypervisor, and not dom0. So if you have 64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit. <br />
If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not 64bit PV domU. <br />
<br />
== Networking Questions ==<br />
<br />
=== Bridging ===<br />
<br />
Q (N1.0): Which Mechanism is used by Xen bridging to handle packets coming from various VMs to forward them to their destination <br />
<br />
A (N1.0): Nothing. Xen by itself does not handle bridge. dom0 OS does that. <br />
On Linux dom0 : http://www.linuxfoundation.org/en/Net:Bridge <br />
On opensolaris dom0: http://opensolaris.org/os/project/crossbow/ <br />
IP Determination<br />
<br />
Q (N2.0): I want to know the IP of a running VM in XEN.. Is there any way to have this without login to that VM.. <br />
<br />
A (N2.0): Find domU's mac. This can be easy (if your domU config specify a static MAC).<br />
The easy way to get domU's IP address, you can look at domUs config file (if you specify it), or you can try running this:<br />
xm network-list domU_name <br />
if you get this line <br />
Idx BE MAC Addr. handle state evt-ch tx-/rx-ring-ref BE-path 0 0 00:16:3E:F7:D6:E7 0 4 6 16238/16237 /local/domain/0/backend/vif/163/0 <br />
Then domU's MAC is 00:16:3E:F7:D6:E7 <br />
The hard way to find out your MAC from a bridge, since your bridge is called eth0 you can try: <br />
xm list, note the domain ID (the number) <br />
- brctl showstp eth0 that should show which interface is identified as which "port". For example if your domU has an ID 163, look for the lines that has "vif163.0" or "tap163.0". If the line looks like this <br />
vif163.0 (11) <br />
then that vif is identified as port 11 on the bridge. <br />
- brctl showmacs eth0 Look for the port corresponding to the port above. If you get this line <br />
11 00:16:3e:f7:d6:e7 no 0.96 <br />
then on port11 (where your domU interface is) there's a MAC address 00:16:3e:f7:d6:e7. <br />
Now that you have domU's mac, you try snooping the bridge for that MAC. For example : <br />
# tcpdump -n -i eth0 ether src 00:16:3e:f7:d6:e7 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:54:56.419482 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 1, length 64 15:54:57.422349 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 2, length 64 <br />
Then you know that domU has IP address 10.0.0.10. <br />
NAT<br />
<br />
Q (N3.0): I managed to configure NAT on dom0 but this does not work properly. Outgoing traffic from domU is seen with the original domU ip address instead of the dom0 ip address and the requests can't get back to the domU. <br />
<br />
A (N3.0): I figured out MASQUERADING was not set. <br />
The following rule needs to be set: <br />
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE <br />
<br />
SSL/VPN<br />
<br />
Q (N4.0): Way can't i use openvpn with a xen guest I can't load the tun module <br />
<br />
A (N4.0): From openvpn perspective, the requirements for openvpn on xen domU is the same as openvpn on native Linux. If you can't load tun module, then you need to get a kernel that supports it. <br />
The easiest way is to use a distro that supports it. For example, I'm using RHEL/Centos 5.3 domU, loaded with pygrub, and they can run openvpn just fine. <br />
Another alternative is compile your own kernel with tun/tap support. <br />
<br />
=== General ===<br />
<br />
Q (N5.0): I want to ask how to mount one storage device to 2 guests? When I try to create vm handle everything is fine I can create one vdi and vbds for every guest. When I start first machine everything is ok, but when I try to start second one it says that<br />
<br />
ERROR: 2 INTERNAL_ERROR Device 2051 (vbd) could not be connected.<br />
Device /dev/mapper/test_vg-test64_454 is mounted in a guest domain,<br />
and so cannot be mounted now.<br />
<br />
Ideas how I can share one device to two or more virtual machines? I don't want network solution like nfs,iscsi ... etc but instead use ocfs2. How I can set mode to w! ? <br />
<br />
A (N5.0): First of all, you DO realize that sharing a block device without some kind of cluster file system could lead to data corruption? If you want to share it anyway, you can try changing the mode to "r"(for read only) or "w!" (to force read-write multiple mount). <br />
in your domU.cfg:<br />
<br />
'phy:/dev/data/bla-disk,sda1,w' => 'phy:/dev/data/bla-disk,sda1,r'<br />
<br />
Q (N5.1): I'm looking for a way to monitor network activities of processes in Guest OS. I want to get a list of Guest OS processes that open TCP connections to other machines (like "lsof" command). <br />
<br />
A (N5.1): If you're thinking about doing on from dom0, that's not possible. You need something that runs on domU for that, possibly by using snmpd and extending it to run "netstat -anp --tcp". Other host (including dom0) can then collect the information using snmp. <br />
Also, have a look at Versiera, it provides what you are looking for including, user<br />
IDs, inbound/outbound communications, IPv4, IPV6, etc. There are many more<br />
capabilities. Versiera is not open-source, but the Internet self-manage service<br />
is free. <br />
<br />
Q (N5.2): I’m attempting to gather stats on usage of the “metalâ€, by which I mean the physical host’s hardware. I would like to know the CPU, IO, and network stats for the hardware. <br />
<br />
A (N5.2): All DomU's IO passes through Dom0. there you can measure all you want. <br />
for disk IO, if you use phy: devices, you can use iostat to see the usage of each device. if you use file-based backends, it would be easier to check the userspace daemons. maybe iotop would help. in any case, if aggregate usage is all you need, just measure the disk usage seen at Dom0 <br />
for network, if you can measure at peth0, that would give you the aggregate usage. if you need stats for each DomU, check the respective tun devices. <br />
<br />
Q (N5.3): I have some trouble finding the best solution to my networking requirements. <br />
I want to have the following things: <br />
-dom0 : have 2 physical networks devices * 1 eth with public IP (static) * 1 eth with private IP (static) <br />
-domU * 1 eth with private IP <br />
-I also want openVPN solution to let people outside the private network have access to it. <br />
-A DHCP server is required so that domU get their IP from it. <br />
I have debian lenny and xen 3.2 installed and working. Actually openvpn and dhcp are on the dom0. All is fine *except* that domU don't have access to internet (this is my main problem). My current config use network-bridge netdev=eth1 (eth1 have a static private ip). <br />
It is perhaps better to have dhcp and openvpn server in a domU, feel free to suggest what you think is the best choice (and the config that go with it) :) <br />
<br />
A (N5.3): When designing such setups, with bridge networking, I often find it easier to think of dom0 as a switch or router, and domU like any other physical server on your network. <br />
In your setup you're making dom0 act as router/firewall. Your problem is that probably you haven't setup ip forwarding and NAT on dom0 to allow domU internet access. <br />
Note that (if you want) you could also have dom0 act like a switch. In that scenario you'd need another domU, with two network interfaces connected to both dom0's eth0 and eth1, acting as router/firewall. <br />
<br />
Q (N5.4): I have been trying to get a HVM DomU running and being able to connect to a vlan. I am starting to get the feeling that at least the hw emulations I have tried do not supoprt vlans. Also all the things I have found online would have me creating the vlans inside the Dom0 and pushing them to the DomU's as regular interface<br />
<br />
A (N5.4): You could always have a trunk port in your dom0 and create bridges for each VLAN for xen. <br />
You can even script it so you can add it to boot time. <br />
If you have the VLAN trunk set up, you can create bridges as follows. <br />
For this example, my trunk interface is on eth0 and the vlan I am adding is 2. <br />
<!-- # vconfig add eth0 2 # brctl addbr xenbr2 # brctl addif xenbr2 eth0.2 # ifconfig eth0.2 up # ifconfig xenbr2 up --><br />
Now all you would add in the domU configuration file is: <br />
vif=['bridge=xenbr2'] <br />
And you would be on VLAN 2. <br />
Otherwise I'm pretty sure you would have to pass through the network card to get VLAN access. <br />
You can also script this and give it a space separated list of VLANs and loop it through. I will leave this up to you though. <br />
<br />
== High Availability Questions ==<br />
=== Services ===<br />
<br />
Q (HA1.0): What software exists for Xen to handle high availability? <br />
<br />
A (HA1.0): Here are several tools that currently exist:<br />
CentOS Cluster<br />
Project Kemari - http://www.osrg.net/kemari/<br />
Project Remus - http://blog.xen.org/index.php/2009/04/02/project-remus-released/<br />
Linux Cluster Resource Manager - http://clusterlabs.org/mediawiki/images/f/fb/Configuration_Explained.pdf <br />
<br />
Q (HA1.1): I'm not sure about how snapshots works on Xen. For example, if I snapshot a DomU with 10GB HD will take, for example, 30 seconds. But, if I snapshot a DomU with a 100GB HD will take longer (I guess). <br />
So, I wanna know how the snapshot works on xen. What if I want to move a snapshotted with a 100GB HD from a Dom0 to another Dom0? I've to move a 100GB file? <br />
<br />
A (HA1.1): You could try this approach: <br />
http://www.infohit.net/blog/post/using-lvm2-snapshots-to-provide-rollback-functionality-for-xen.html <br />
Makes snapshots quite quick. <br />
<br />
== Performance Questions ==<br />
<br />
== Security Questions ==<br />
<br />
Q(S1.0): If I install minimal linux for XEN in dom0 and a periphery firewall in domU and other applications in other instances of domU, is it possible to restrict/bind the network card to domU having periphery firewall and from there forward packets for dom0 or for other domUs? <br />
Is this possible? If so, is it secure? Or does dom0 always have direct access to Network Card and needs a separate firewall? And packets will always route from dom0 to all domUs ? <br />
What are the issues involved? <br />
<br />
A(S1.0): The approach I've used at home is to hide a network card from Dom0 (see pic-back.hide) and pass it through to a DomU which then sees it as a native interface. I then run a firewall in the DomU and the outside traffic does NOT go through Dom0. The route for packets is then : <br />
real i/f -> DomU (firewall) -> VIF -> int bridge [ Dom0 | VIF -> DomU ] <br />
From security perspective, this is the same as having an L2 switch (when dom0's bridges have no IP address) or L3 switch (when dom0's bridges have an IP address) <br />
<br />
Q(S1.1): I want to use a Disk Encryption and the conplete physikal Disk in a DomU. I prefere Truecrypt or Loop-aes. i will going to test loop-aes cause it should have the better performance. <br />
But, did anybody here using truecrypt or loop-aes ? What is the better one, in the fact of speed ? <br />
<br />
A(S1.1): dm-crypt/luks is one option, and performs about the same or better than loop-aes. Also it's less problematic because it doesn't use loop devic<br />
<br />
== Design/Misc Questions ==<br />
=== Nested Xen ===<br />
Q (D1.0): Can I run Xen within Xen? <br />
<br />
A (D1.0): Yes, You can install Xen on the base system, create a HVM domain, and install Xen in that guest domain. Note that the inner Xen system will not (yet) support HVM again.<br />
<br />
=== How does Xen Work ===<br />
<br />
Q (D3.0): How does Xen process System Calls on para-virtualized guest?<br />
<br />
A (D3.0): When ever a system call is invoked via interrupt or sys center control gets transferred to the kernel (ring 0), which is then handled via system call handler. System call never goes to libc but Libc is a library that provides POSIX interface to the user space applications and in a way wrapper for invocation of a system call. <br />
System call interrupt based [i386]: During booting process, linux kernel of a domU register's its IDT with Xen Hypervisor via HYPERVISOR_set_trap_table(trap_table); [arch/i386/kernel/traps-xen.c]. Xen maintains two IDT's, one global IDT (its own) and other per domain IDT. Xen uses global IDT to register the entire trap handler except for system call handler (int 0x80). When a VM gets scheduled, its system call handler (from per domain IDT table) is registered with the processor. Hence when a domain/VM executes a system call, its own handler is executed. <br />
Implementation differs for x86_64: Xen registers its own system call handler with the processor and from that handler routes the request to VM/Domain specific handler. <br />
<br />
Q (D3.1): How does Xen process System Calls on fully virtualized guest (HVM)?<br />
<br />
A (D3.1): For HVM domU there is no change in the behavior of the system call. HVM is only supported for Intel-VT and AMD-SVM processors. These processors are virtualization aware. Virtualization aware processors provide a new ring (Root-Ring 0) with higher privilege for VMM and Guest OS continues to runs with the same privilege (as without Xen) in Non-Root Ring 0. Guest OS can issue the system calls the way it used to without Xen.<br />
<br />
Q (D3.2): Can I run various DomU operating systems on a different Dom0 operating system?<br />
<br />
A (D3.2): Yes. <br />
<br />
Q (D3.3): Just curious to know, if there is any way that given a terminal to a box, we can determine is it a physical machine or a virtual machine ? <br />
<br />
A (D3.3): You should be able to get some useful information from the DMI, e.g: <br />
% for i in system-manufacturer system-product-name system-version\ system-serial-number; do echo -n "$i: "; sudo dmidecode -s $i; done <br />
system-manufacturer: Xen system-product-name: HVM domU system-version: 3.3.1 system-serial-number: 89e5915f-dead-beef-cefd-46904ea94c4a <br />
OR<br />
Probably checking kernel process, check your process table for: <br />
[xenwatch] [xenbus] <br />
Another clue is checking the kernle suffix, for example: <br />
<!-- # uname -r 2.6.24-23-xen --><br />
and the proc files: <br />
/proc/xen/capabilities <br />
<br />
Q (D3.4): What is STUBDOM ? <br />
<br />
A (D3.4): Stubdoms are lightweight 'service' or 'driver' domains. The initial purpose was to offload qemu (for hvm guests) out of dom0. <br />
So with stubdoms you can run hvm guest qemu in a separate stubdom, which boosts performance and makes it more secure. <br />
stubdoms can also run for example pv-grub for pv guests, making it more secure compared to pygrub, which always runs in dom0. <br />
http://wiki.xensource.com/xenwiki/StubDom <br />
Presentation about stubdoms at Xen Summit: http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf <br />
http://blog.xen.org/index.php/2008/08/28/xen-33-feature-stub-domains/ http://blog.xen.org/index.php/2008/08/28/xen-33-feature-hvm-device-model-domain/ http://lxr.xensource.com/lxr/source/stubdom/README <br />
<br />
Q (D3.5): When is hardware virtualization used in Xen? Is it required?<br />
<br />
A (D3.5): Xen uses hardware virtualization for HVM guests. Xen will not launch a HVM guest unless hardware virtualization is turned on.<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Asking_Xen_User_Questions&diff=5112Asking Xen User Questions2012-09-24T15:14:56Z<p>OliverChick: /* How To Guide Links */ Updated links to point to new Wiki</p>
<hr />
<div><!-- MoinMoin name: XenUsersQuestions --><br />
<!-- Comment: replace stephen.spector with community.manager@xen.org --><br />
<!-- WikiMedia name: XenUsersQuestions --><br />
<!-- Page revision: 00000007 --><br />
<!-- Original date: Tue Jan 25 16:12:06 2011 (1295971926000000) --><br />
<!-- ## Please edit system and help pages ONLY in the moinmaster wiki! For more --><br />
<!-- ## information, please see [[MoinMaster]]:[[MoinPagesEditorGroup]]. --><br />
<!-- ##master-page:[[HomepageReadWritePageTemplate]] --><br />
<!-- ##master-date:Unknown-Date --><br />
<!-- #format wiki --><br />
<!-- #language en --><br />
<br />
{{Needs_Refactor|Needs splitting and moving into the smaller FAQs on [[:Category:FAQ]]}}<br />
<br />
= Xen Users Mailing List Commonly Asked Questions =<br />
<br />
== Introduction ==<br />
This document is a Xen.org community effort to gather the most commonly asked questions from the xen-users emailing list and other support tools to assist new and experienced Xen hypervisor users with problems that frequently arise. If you would like to add content to this document, please send an email to community.manager@xen.org for editing rights if you don't have wiki editing rights already. <br />
For those users interested in trying Xen without installing the application, a Live CD version is available at http://wiki.xensource.com/xenwiki/LiveCD. <br />
<br />
== Support Tools ==<br />
The following sites are available for Xen hypervisor support:<br />
* xen-users mailing list - http://lists.xensource.com/mailman/listinfo/xen-users<br />
* Xen 3.3 Documentation - http://bits.xensource.com/Xen/docs/user.pdf <br />
* Stack Oveflow - http://stackoverflow.com/<br />
* Complete email history of all xen mailing lists - http://xen.markmail.org <br />
* Language Specific Support<br />
** Japanese - http://lists.xensource.com/mailman/listinfo/xen-japanese<br />
** Portuguese - http://groups.google.com/group/xen-br<br />
<br />
== How To Guide Links ==<br />
The Xen.org community Wiki has a [[HowTo]] Page with various information sources at http://wiki.xensource.com/xenwiki/HowTos. Updates to this Wiki page are continuous so check back often for new How Tos. <br />
Sample topics internally within the Wiki are:<br />
* [[XenNetworking| Xen Networking]]<br />
* [[FreeBSDdomU| Xen FreeBSD]]<br />
<br />
Sample topics with external links are:<br />
* Adding USB Devices to Xen HVM - http://www.virtuatopia.com/index.php <br />
* Xen on Fedora - http://rackerhacker.com/2011/08/05/xen-4-1-on-fedora-15-with-linux-3-0/ <br />
* Create and Install CentOS on Xen - http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU <br />
* http://www.virtuatopia.com/index.php/Configuring_a_VNC_based_Graphical_Console_for_a_Xen_Paravirtualized_domainU_Guest<br />
* https://help.ubuntu.com/community/Xen Xen on Ubuntu<br />
<br />
== Guest Related Questions ==<br />
=== Guest Conversion ===<br />
Q (G1.0): How do I convert a Centos HVM Guest to a PV Guest?<br />
<br />
A (G1.0): Creating a Centos HVM domU with working PV drivers : http://pastebin.com/fb6fe631 Converting HVM guest to PV guest : http://pastebin.com/f6a5022bf <br />
If you follow both parts correctly you should have a working PV domU. If anything goes wrong during conversion process, you should still be able to boot the previous HVM domU config if you select the non-xen kernel (second entry) from grub menu.list. <br />
=== Console ===<br />
<br />
Q (G2.0): I have an Xen image that was built for a graphical console (VNC). Is there any way to change it to the non-graphical console (xen console)? <br />
<br />
A (G2.0): For HVM guest, you need to enable serial port on domU config file (example here: http://pastebin.com/fb6fe631), and setup domU to use serial port (ttyS0 on Linux) by modifying (for Linux domU) /boot/grub/menu.lst, /etc/inittab, and /etc/securetty. <br />
If it's PV guest, you need to set up domU to use xen console (which is xvc0 on current xen version, hvc0 on pv_ops kernel). It's similar to setting up domU for serial console, you just need to change ttyS0 to hvc0. An example of domU setup that can use both xvc0 and vnc console is here : http://pastebin.com/f6a5022bf <br />
<br />
Q (G2.1): How do I remove an active virtual machine?<br />
<br />
A (G2.1): xl shutdown or xl delete<br />
<br />
Q (G2.2): How do I run xl console to a WindowsXP DomU?<br />
<br />
A (G2.2): You can't xl console to that (I'm not sure you can xl console to any hvm, but I know you can't to one that doesn't have a console). <br />
<br />
Q (G2.3): I start a new DomainU (Guest) and some text scrolls by for launching the guest but then it just sits there with Continue and no actions takes place? <br />
<br />
A (G2.3): The console for this new DomainU is not properly available for you; fix this by adding xtra="xencons=tty" in the configuration file. This will bring up a login screen directly for your new DomainU. <br />
<br />
Q (G2.4): One of our CentOS 5.3 randomly reboots, at different times of the day, and I can't see why it's doing it. I have looked through the logs, but don't see any thing in there that shows me why it has rebooted. How can I debug this? <br />
<br />
A (G2.4): The problem is that when the box panics, it stops syslogd, so you don't get the panic output in /var/log. The best way to fix this is to setup a logging serial console. <br />
<br />
Q (G2.5): Hi, i want to stop VMs, but when i execute xl destroy vmname the VM disappears completly from mu vm list (xl list) How can I stop them without delete them? <br />
<br />
A (G2.5): You've probably been using "xl create". That's the way it works.<br />
<br />
=== Drivers ===<br />
Q (G3.0): What are the GPLPV Drivers and where can I get them?<br />
<br />
A (G3.0): A collection of open source Window PV drivers that allow Windows to be para-virtualized. They are currently being implemented under the leadership of James Harper. More information on these drivers at:<br />
* http://wiki.xensource.com/xenwiki/XenWindowsGplPv/Installing<br />
* http://lists.xensource.com/archives/html/xen-users/2009-04/msg00058.html<br />
* http://meadowcourt.org/downloads/<br />
<br />
Q (G3.1): How can I tell if the GPLPV Drivers are loaded correctly?<br />
<br />
A(G3.1): If the drivers are installed correctly there should be a Xen device under 'System Devices' in device manager. <br />
<br />
=== Domain0 ===<br />
Q (G4.0): Why cannot I see all my RAM on my Dom0?<br />
<br />
A (G4.0): Domain 0 is a paravirt VM in reality, so the amount of ram you allocate to it is what you will see when using local tools like free, /proc/meminfo, top, etc. <br />
To see the full system ram, you need to use the xm tools... and in this case, 'xm info' which will show you all the system resources, as opposed to the resources available to dom0. <br />
Also, you have 16GB ram on the system... you probably already know this, but be aware that without a PAE enabled kernel (if you're using 32bit Xen) you'll only see 4GB of this. PAE will allow you to use up to 16, or maybe 32 (I don't remember what the upper limit for PAE enabled Xen is off the top of my head). <br />
<br />
Q (G4.1): Is there any way of checking DomU´s I/O from Dom0? <br />
<br />
A (G4.1): iostat (Debian: sysstat-package) <br />
<br />
Q (G4.2): Can I allocate one CPU to the Dom0 exclusively? <br />
<br />
A (G4.2): Add this to the kernel boot line <br />
* dom0_max_vcpus=1 & dom0_vcpus_pin <br />
* Edit /etc/xen/xend-config.sxp - set “(dom0-cpus 1)†<br />
* Reboot Dom0 <br />
* To try on an active system without a Reboot - <br />
* xm vcpu-set 0 1 xm vcpu-pin 0 0 0 <br />
<br />
Q (G4.3): Running xm info I see the following memory available; what does the free memory mean?<br />
total_memory : 2046 free_memory : 5 <br />
<br />
A (G4.3): Free_memory from "xm info" shows memory not allocated to any domain (inlcuding dom0). "free", "top" (or whatever) shows free memory on that particular domain (in your case, dom0). You can adjust memory allocation per domain using "xm mem-set". <br />
<br />
=== DomainU ===<br />
Q (G5.0): My DomU does not fully start; it shows the following output stopping at Continue...<br />
<br />
$ sudo xm console test<br />
<br />
io scheduler cfq registered<br />
<br />
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize<br />
<br />
Xen virtual console successfully installed as xvc0 Event-channel device installed. netfront: Initialising virtual ethernet driver. i8042.c: No controller found. mice: PS/2 mouse device common for all mice TCP bic registered NET: Registered protocol family 1 <br />
<br />
NET: Registered protocol family 17<br />
<br />
Using IPI No-Shortcut mode xen-vbd: registered block device major 8 blkfront: sda2: barriers enabled XENBUS: Device with no driver: device/console/0 Freeing unused kernel memory: 140k freed kjournald starting. Commit interval 5 seconds <br />
<br />
EXT3-fs: mounted filesystem with ordered data mode.<br />
<br />
* ************************************************************** <br />
* **************************************************************<br />
* * WARNING: Currently emulating unsupported memory accesses **<br />
* * in /lib/tls glibc libraries. The emulation is **<br />
* * slow. To ensure full performance you should **<br />
* * install a 'xen-friendly' (nosegneg) version of **<br />
* * the library, or disable tls support by executing **<br />
* * the following as root: **<br />
* * mv /lib/tls /lib/tls.disabled **<br />
* * Offending process: modprobe (pid=663) **<br />
* **************************************************************<br />
* **************************************************************<br />
Continuing... <br />
<br />
A (G5.0): It might only be that you don't have a VPS physical console, and that your VPS is fully booted, but you can't see it. There are few things to check.<br />
<br />
First, check that your VPS has a "console" device in /dev. Mount your domU filesystem in the dom0, go in /dev and do:<br />
<br />
/dev/MAKEDEV console<br />
<br />
If you are using a modern Xen kernel and hypervisor, you should check the parameters of the startup file. Check that it has the following option:<br />
<br />
extra = "4 TERM=xterm xencons=tty console=tty1"<br />
<br />
Then start your VPS and watch it booting. Note that once it's booted up, you should check that it has a xen friendly libc6 installed (in Debian, you would do "apt-get install libc6-xen").<br />
<br />
Q (G5.1): is there a way to set the credit-scheduler's limits and weights per domU<br />
in the domU configuration file? <br />
<br />
A (G5.1): weight= in the xm config file works, unless you are using RHEL or CentOS. <br />
<br />
Q (G5.2): How do I start an application from within a DomU?<br />
<br />
A (G5.2): Well, you could always just log in to that VM, open a terminal and run the program. <br />
Or you could SSH or telnet in to the VM, start a screen session and run the program. <br />
A VM acts just like any other server, so the proceedure for starting programs and executing commands locally and remotely are exactly the same as doing so on any computer. <br />
<br />
Q (G5.3): My domUs are in a permanent 'b' (blocked) status as shown by 'xm list', even though they are functioning just fine. That's not normal, is it? <br />
<br />
A (G5.3): It's normal for them to show as blocked when they aren't actively running something - in the same way that any process on a 'normal' machine will show as blocked when it's waiting for input, each guest will show as blocked when it's got nothing to do. Give something a processor intensive task to do and you'll find it changes state to running (at least some of the time). <br />
<br />
Q (G5.4): Is there any way, to get the name of a domU from the network-common script? <br />
<br />
A (G5.4): hostname=$(xenstore_read "$XENBUS_PATH/domain" | tr -- '_.:/+' '-----') <br />
<br />
Q (G5.5): Is it possible to increase the screen resolution of my xen guest Windows Vista? <br />
<br />
A (G5.5): On current Xen, with stdvga=1 & videoram=16, resolutions up to 2048x1536x32 are possible. All that said, the RDP suggestion is probably a better way to access the guest in any case. <br />
<br />
Q (G5.6): How to install Solaris via HTTP as a para guest? <br />
<br />
A (G5.6): Solaris 10 can only be used as HVM guest. [[OpenSolaris]] can be used as PV guest, installed from iso. You can't install it from http. Once you have it installed, you also need zfs support for pygrub (either that, or manually copying kernel and boot archive to dom0) <br />
<br />
Boris provides some nice examples on his site : http://bderzhavets.wordpress.com/ <br />
<br />
Q (G5.7): Is it possible to find out the specific vnc Display Number of a domU? <br />
<br />
A (G5.7): virsh vncdisplay domU_name_or_id <br />
xenstore-ls /local/domain/domU_id/console <br />
<br />
Q (G5.8): I am trying to create a guest domain. I specified the configurations in /etc/xen-tools/xen-tools.conf and I ran $sudo xen-create-image --hostname=virtualrouter1 --role=udev the output is: sudo: xen-create-image: command not found <br />
<br />
A (G5.8): Make sure you installed the Xen tools, for example: apt-get install xen-tools <br />
<br />
Q(G5.9): I'm trying to assign a dynamic hostname to a xen instance as follows: <br />
<br />
Cfg file <br />
=== == <br />
kernel = "/root/vmlinuz-2.6.18-128.1.14.el5xen" <br />
ramdisk = "/root/initrd-2.6.18-128.1.14.el5xen.img" <br />
memory = 512 <br />
hostname = "uniquehostname" <br />
<!-- #hostname = " uniquehostname.xen.org" --><br />
name = "my-vm-name" <br />
* . . . . <br />
In both the cases, the instance is unable to get the correct hostname.. <br />
<br />
A (G5.9): From "xm create --help_config" : hostname=NAME Set the kernel IP hostname. interface=INTF Set the kernel IP interface name. dhcp=off|dhcp Set the kernel dhcp option. <br />
On most LInux distros, kernel hostname and IP address is ignored, making it somewhat useless. You need to use your normal distro method to set hostname on domU (/etc/sysconfig/network on RHEL) <br />
<br />
Q(G5.10): As far as I can see, there is something different between using 'xm create' and 'xm new' followed by 'xm start'. It's something to do with data being stored in [[XenStore]]. I couldn't suspend the one started with 'xm create'. Could someone please explain the effective difference between the two and when 'create' should be used instead of 'new' and vice-versa. <br />
<br />
A(G5.10): xm create -> domU configuration is NOT managed by xend. Usually using config files on /etc/xen. This is the easiest method to use for beginners, as you have a config file that you can edit manually. The default on RHEL5 (which uses Xen 3.1+). <br />
"xm new" and "xm start" -> domU configuration is managed by xend. You change values using commands like "xm block-attach", which can modify settings online. No config file to edit manually. The default on current versions of Xen. <br />
<br />
G (G5.11): I have problem with domU clock. It lose 30 minutes each day. How can i synchronize it with dom0 clock? <br />
<br />
A (G5.11): Is this PV domU? If yes, setting /proc/sys/xen/independent_wallclock to 0 (the default) should make it sync with dom0. You only need ntp on dom0, and domUs will follow. <br />
The alternative, set /proc/sys/xen/independent_wallclock to 1 and run ntp on domU. If this is a HVM dom0, running ntp on domU is your friend. <br />
Also, check<br />
http://tuttodebian.blogspot.com/2008/05/xen-clocksource0-time-went-backwards.html to see if your system experience similar symptoms. <br />
<br />
G (G5.12): I would like to set sched-cred parameters on my domU configuration file. How can i do that? <br />
<br />
A (G5.12): cpu_cap & cpu_weight <br />
Run "xm create --help_config" for details, and read http://wiki.xensource.com/xenwiki/CreditScheduler <br />
<br />
G (G5.13): Is it possible to increase guest memory without reboot? <br />
<br />
A (G5.13): You can do a "xm mem-set <Domain> <memory>" for a PV domU, but you had to set maxmem higher than current assignment beforehand. <br />
<br />
G (G5.14): Is it possible to take an already created domU sparse file and make it a non sparse file? <br />
<br />
A (G5.14): cp --sparse=never orig.img new.img <br />
<br />
G (G5.15): I have tried to change CD ISO images during a HVM install using the following commands but it doesn't work. After changing the CD ISO image, it doesn't detect the new ISO image. <br />
(qemu) eject -f hdc (qemu) change hdc /media/hitachi/cd-rom-image.iso <br />
<br />
A (G5.15): Use xm block-list <domid> to find the cdrom be-path for the domain, for example: <br />
xm block-list 5 Vdev BE handle state evt-ch ring-ref BE-path 768 0 0 4 9 16383 /local/domain/0/backend/vbd/5/768 5632 0 0 1 -1 -1 /local/domain/0/backend/vbd/5/5632 <br />
Having identified the cdrom device (5632) you can check what iso image it is connected to: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params <br />
(nothing returned) <br />
To connect a new iso image: <br />
xenstore-write /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
And you can now see that it is connected: <br />
xenstore-read /local/domain/0/backend/vbd/5/5632/params /mnt/gl3-tb1_store/MWWin2003R2SvrStdx86_BX2SVOL_EN.iso <br />
This method works with both emulated devices and with gplpv drivers. <br />
<br />
Q (G5.16): Is it possible to set the xen to boot the domU one by one when server starts, as currently we have 20 domU, and if boot them together, the the hard disk will be very very slow. <br />
<br />
A (G5.16): cd /etc/xen/config/........ && for i in * do ...... (start VM, .....)...... sleep 60 (or whatever time you think <br />
is right to start a VM) done <br />
<br />
Q (G5.17): I use FluidVM on some of our VPS host nodes, and the management server<br />
has crashed, so now I need to recover the running VM's, somehow. FluidVM deploys the domU's on the hostnode dynamically from a database, i.e. there's no /etc/xen/vps1 (for example) config files. The domU's are still running on the servers, and I now want to create config files for them, while they're running.<br />
<br />
How would I be able todo this?<br />
<br />
For example, here's a list of running VM's from one of the servers:<br />
<br />
root@usaxen02:[~]$ xm list<br />
Name ID Mem(MiB) VCPUs State Time(s)<br />
AndriesBurger_39_cronos 90 255 1 -b---- 42.4<br />
Bruce_18_carmen 60 255 1 r----- 3528327.5<br />
Domain-0 0 3433 4 r----- 1116681.7<br />
Rudi_14_mars 40 3007 2 -b---- 953036.3<br />
Rudi_44_vps2 93 255 1 -b---- 22.9<br />
<br />
Is there any way to create a config file, /etc/xen/AndriesBurger_39_cronos, from the running domU<br />
AndriesBurger_39_cronos ?<br />
<br />
A (G5.17):You can use "xm list -l" to dump the configuration in SXP format; then you should be able to use "xm new" or "xm create" with the "-F" option to load an SXP-based config file. See the "xm" man page for more info - that's where I dug up this.<br />
<br />
Q (G5.18): How to set up Xen DomU as Windows 2008 Server on a CentOS Dom0 machine?<br />
<br />
A (G5.18): Start using the normal way that you usually do when you install a HVM domU, whether it's virt-manager/virt-install or using manually-created config file. One additional thing to note is that for 64bit HVM domUs you need to make sure that acpi, apic, and pae is set to 1 on domU config file. <br />
Once you get that Win2008 fully installed, you can install GPLPV driver later to improve performance.<br />
<br />
Q (G5.19): I need to install windows streaming media server on one of my xen3.4.2 guest. Is it possible to create a windows xp paravirtual guest on xen? Like I install other Linux guest as the paravirtual ones. If yes please give some brief steps for that. <br />
<br />
A (G5.19): No, unless you ask Microsoft to port XP kernel to Xen PV model:)<br />
<br />
Judging from the fact that XP was declared end of life several times, and the fact that even Hyper-V requires VT to run, I highly doubt they will ever create PV-enabled windows <br />
<br />
Q (G5.20): I would like to move an existing [[W2K3]] install onto my new super duper xen box -- Installing linux based machine is no issue, it's the windows ones that keep getting me. I have Acronis which we usually use for bare metal restores, and it seems that bare metal restores don't want to work too well with XEN, any assistance/help/ideas ? <br />
<br />
A (G5.20): I have successfully migrated several physical windows 2003 installs to Xen by adding the ide drivers as per http://support.microsoft.com/kb/314082 and then using Acronis True Image to copy the disks.<br />
<br />
One issue I had was that the boot cd created by the version of True Image we have did not boot under Xen (hung on boot screen), but Acronis support sent me a version that did work (TrueImageLinuxServer8072_multiparam_Standard_english_il.iso). However due to using emulated nic and hd running True Image directly under Xen was very slow, my first solution to that problem was to make a small windows hvm install with gplpv drivers loaded and true image installed and then temporarily add the target block device to it in order to write the image, but I recently switched to using a WinPE boot ISO with GPLPV and [[TrueImage]]/Backup And Recovery installed, the Acronis products come with a WinPE/BartPE Image builder utility so its quite easy to do.<br />
<br />
Also watch out for boot.ini, many servers come with a hidden partition on the boot volume for running diagnostics, in which case windows may be booting from the second partition, so you may need to adjust the boot.ini or you could remove it entirely and windows will then attempt to boot from \windows automatically. <br />
<br />
Q (G5.21): Could we add a file image, block device or lvm to domU while it is running without restarting?<br />
<br />
A (G5.21): Use "xm block-attach", and edit domU config file afterwards (if you still you file-based domU config) to make it permanent. Should work great with PV domUs.<br />
<br />
There are cases when you have to reboot the domU anyway though, since the driver installation of a new disk on domU OS could require reboot. One example is when using Windows + GPLPV.<br />
<br />
=== Devices ===<br />
<br />
Q (G6.0): For my xen domUs I'm using a mixture of locah physical partitions (with LVM) and iSCSI disks. For local partitions, I don't have any problem, because LVM volumes are always the same. But for iSCSI disks, devices are assigned in the order they are connected, so I can't be sured that device that now is /dev/sdb (for example) will always be /dev/sdb. <br />
So, is there any way to identify the physical device in the domU configuration not as phy:/dev/sdb, but something like phy:label=fslabel? Or is there any other solution to this problem? <br />
<br />
A (G6.0): I go with phy:/dev/disk/by-path/ip-*-iscsi-iqn.* If you assign iscsi luns directly as domU's fs without additional partitioning, you could probably also use /dev/disk/by-label/* or /dev/disk/by-uuid/*<br />
<br />
== Installation Questions ==<br />
<br />
=== File Systems ===<br />
<br />
Q (I1.0): Is there a way to have a shared root file system amongst a set of Xen servers?<br />
<br />
A (I1.0): You can install the OS in an LVM partition and use it shared across all the xen domUs when you use the parition as 'r' instead of 'w' when defining the disk. <br />
But you have to do all tasks needed for read-only root filesystem. <br />
Like 1. mount ramfs in /tmp and in /var ... <br />
http://en.opensuse.org/How-To_Make_the_root_filesystem_read-only <br />
I use 2 disks in Xen with one as read-only mounted as / and the other is the data partition. I have a need to have scratch partition with pre-populated data and for this I create a LV and put data into it (eg:- software etc.,) and then create a snapshot of this volume and send it as rw to the xen machine. This way my original software partitions are intact and also the changes (may be damaging) done in the xen volumes are lost once the snapshot grows to 100%. <br />
<br />
Q (I1.1): I installed two Debian web server which run a phpbb3 forum. One stays on a Xen paravirtualized domU (512 MB of ram, 1 vcpu, disc on a raw file file:/home/vale/debian.img,hda,w) on [[OpenSuse]] 11.0 and one run on a hyper-v virtual machine (512 MB 1 cpu) build on Windows Server 2008 R2. The performances on PV are very poor than hyper-v. ab -n 3000 -k -c50 http://site.lan/phpBB3/ returns 13,22 req/sec on PV domU and 38,37 req/sec on hyper-v.<br />
Why?<br />
<br />
I installed O.S. guest as a HVM domain, then I installed linux-xen-image files and I use them for vmlinuz and initrd. I also installed libc6-xen.<br />
<br />
Xen PV config file:<br />
name='pv'<br />
ramdisk='/home/vale/initrd.img-2.6.18-6-xen-686'<br />
kernel='/home/vale/vmlinuz-2.6.18-6-xen-686'<br />
bootloader=''<br />
vif=['mac=00:16:3e:33:37:4f, bridge=xenbr0']<br />
vcpus=1<br />
memory=512<br />
disk=['file:/home/vale/pv.img,hda,w']<br />
on_reboot='restart'<br />
on_crash='restart'<br />
extra=''<br />
root='/dev/hda1'<br />
platform='xen'<br />
<br />
A (I1.1): I'm assuming that phpBB3 is relatively I/O intensive (since it uses db, which I assume you also installed on the same host). In that case, your bad numbers are probably because of this<br />
disk=['file:/home/vale/pv.img,hda,w']<br />
<br />
On Xen, file:/ is not recommended, and you should use tap:aio:/ instead for file-backed storage. Then again, another user reported that even tap:aio isn't good enough<br />
<br />
http://lists.xensource.com/archives/html/xen-users/2009-01/msg00820.html<br />
<br />
So in short, if you use Xen PV, you might want to consider using LVM/partition-backed storage.<br />
<br />
Q (I1.2): Is it possible to start a VM that contains just gpxe (which when started, will get an image from a provisioning server and will load that image) <br />
<br />
A (I1.2): In this article, we'll show you the prcesses to setup PXE boot environment for Xen host (hypervisor + dom0) and Xen guest, both PV (Para-Virtualized) guest and HVM (Hardware-assisted Virtual Machine). Details at http://os-drive.com/files/docbook/xen-pxeboot.html.<br />
<br />
Q (I1.3): I tried to resize a disk of my data guest from 100 to 400 GB. I did an lvresize /dev/xendata/data-disk -L 400G an it works. I started the Guest and did an df -h to check the size but there are still 100 G <br />
<br />
A (I1.3): The container is bigger but the filesystem isn't. Resizing an LV doesn't make the FS any bigger. <br />
Log into the DomU and do a resize2fs <device>. You can do this while it's mounted as long as the filesystem is getting bigger. <br />
Oh, and if you've partitioned the LV inside the guest, you'll also need to resize the partition (BEFORE you do a resize2fs, etc.). There are two ways to do this - the safest is to use parted, which works if you're using ext2/ext3 (and a couple other of the most popular filesystems - reiser, I think). The other method is to delete the partition and recreate it with the extended end points. This isn't quite as safe and requires that 1) you're start point for the partition is exactly the same as it was before, and 2) the partition is the last (or only) one on the LV. <br />
<br />
Q (I1.4): I want use xen with dynamic slices. For example, I have 20 domU based on FreeBSD, xen hypervisor 3.3.1, Debian Lenny dom0 system. All domUs have 80Gb LVM partitions, but realy they use 20 of this 80Gb and I want to create more domU's. How can I do it? I know that some virtualisation have possibility to do dynamic slices(4 example Virtul box) <br />
<br />
A (I1.4): Do you mean storage overcommit? That is, assign more storage to domU than what you actually have? <br />
If yes, it's not a matter of Xen vs [[VirtualBox]]. It's a matter of what storage backend you use. If you use one of these: - sparse raw file (with file: or tap:aio:) - qcow - vmdk/vdisk (I think full support is only in newer Xen or Opensolaris) - zvol (on Opensolaris) then you can overcommit storage. But if you use disk/partition/LVM for domU storage, you won't be able to. <br />
<br />
=== 32bit vs 64 bit ===<br />
<br />
Q (I2.1): Is there anyway to install 64Bit Linux DomU on 32Bit Linux Dom0? <br />
<br />
A (I2.1): Types of domU that can be run depends mostly on hypervisor, and not dom0. So if you have 64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit. <br />
If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not 64bit PV domU. <br />
<br />
== Networking Questions ==<br />
<br />
=== Bridging ===<br />
<br />
Q (N1.0): Which Mechanism is used by Xen bridging to handle packets coming from various VMs to forward them to their destination <br />
<br />
A (N1.0): Nothing. Xen by itself does not handle bridge. dom0 OS does that. <br />
On Linux dom0 : http://www.linuxfoundation.org/en/Net:Bridge <br />
On opensolaris dom0: http://opensolaris.org/os/project/crossbow/ <br />
IP Determination<br />
<br />
Q (N2.0): I want to know the IP of a running VM in XEN.. Is there any way to have this without login to that VM.. <br />
<br />
A (N2.0): Find domU's mac. This can be easy (if your domU config specify a static MAC).<br />
The easy way to get domU's IP address, you can look at domUs config file (if you specify it), or you can try running this:<br />
xm network-list domU_name <br />
if you get this line <br />
Idx BE MAC Addr. handle state evt-ch tx-/rx-ring-ref BE-path 0 0 00:16:3E:F7:D6:E7 0 4 6 16238/16237 /local/domain/0/backend/vif/163/0 <br />
Then domU's MAC is 00:16:3E:F7:D6:E7 <br />
The hard way to find out your MAC from a bridge, since your bridge is called eth0 you can try: <br />
xm list, note the domain ID (the number) <br />
- brctl showstp eth0 that should show which interface is identified as which "port". For example if your domU has an ID 163, look for the lines that has "vif163.0" or "tap163.0". If the line looks like this <br />
vif163.0 (11) <br />
then that vif is identified as port 11 on the bridge. <br />
- brctl showmacs eth0 Look for the port corresponding to the port above. If you get this line <br />
11 00:16:3e:f7:d6:e7 no 0.96 <br />
then on port11 (where your domU interface is) there's a MAC address 00:16:3e:f7:d6:e7. <br />
Now that you have domU's mac, you try snooping the bridge for that MAC. For example : <br />
# tcpdump -n -i eth0 ether src 00:16:3e:f7:d6:e7 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:54:56.419482 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 1, length 64 15:54:57.422349 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 2, length 64 <br />
Then you know that domU has IP address 10.0.0.10. <br />
NAT<br />
<br />
Q (N3.0): I managed to configure NAT on dom0 but this does not work properly. Outgoing traffic from domU is seen with the original domU ip address instead of the dom0 ip address and the requests can't get back to the domU. <br />
<br />
A (N3.0): I figured out MASQUERADING was not set. <br />
The following rule needs to be set: <br />
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE <br />
<br />
SSL/VPN<br />
<br />
Q (N4.0): Way can't i use openvpn with a xen guest I can't load the tun module <br />
<br />
A (N4.0): From openvpn perspective, the requirements for openvpn on xen domU is the same as openvpn on native Linux. If you can't load tun module, then you need to get a kernel that supports it. <br />
The easiest way is to use a distro that supports it. For example, I'm using RHEL/Centos 5.3 domU, loaded with pygrub, and they can run openvpn just fine. <br />
Another alternative is compile your own kernel with tun/tap support. <br />
<br />
=== General ===<br />
<br />
Q (N5.0): I want to ask how to mount one storage device to 2 guests? When I try to create vm handle everything is fine I can create one vdi and vbds for every guest. When I start first machine everything is ok, but when I try to start second one it says that<br />
<br />
ERROR: 2 INTERNAL_ERROR Device 2051 (vbd) could not be connected.<br />
Device /dev/mapper/test_vg-test64_454 is mounted in a guest domain,<br />
and so cannot be mounted now.<br />
<br />
Ideas how I can share one device to two or more virtual machines? I don't want network solution like nfs,iscsi ... etc but instead use ocfs2. How I can set mode to w! ? <br />
<br />
A (N5.0): First of all, you DO realize that sharing a block device without some kind of cluster file system could lead to data corruption? If you want to share it anyway, you can try changing the mode to "r"(for read only) or "w!" (to force read-write multiple mount). <br />
in your domU.cfg:<br />
<br />
'phy:/dev/data/bla-disk,sda1,w' => 'phy:/dev/data/bla-disk,sda1,r'<br />
<br />
Q (N5.1): I'm looking for a way to monitor network activities of processes in Guest OS. I want to get a list of Guest OS processes that open TCP connections to other machines (like "lsof" command). <br />
<br />
A (N5.1): If you're thinking about doing on from dom0, that's not possible. You need something that runs on domU for that, possibly by using snmpd and extending it to run "netstat -anp --tcp". Other host (including dom0) can then collect the information using snmp. <br />
Also, have a look at Versiera, it provides what you are looking for including, user<br />
IDs, inbound/outbound communications, IPv4, IPV6, etc. There are many more<br />
capabilities. Versiera is not open-source, but the Internet self-manage service<br />
is free. <br />
<br />
Q (N5.2): I’m attempting to gather stats on usage of the “metalâ€, by which I mean the physical host’s hardware. I would like to know the CPU, IO, and network stats for the hardware. <br />
<br />
A (N5.2): All DomU's IO passes through Dom0. there you can measure all you want. <br />
for disk IO, if you use phy: devices, you can use iostat to see the usage of each device. if you use file-based backends, it would be easier to check the userspace daemons. maybe iotop would help. in any case, if aggregate usage is all you need, just measure the disk usage seen at Dom0 <br />
for network, if you can measure at peth0, that would give you the aggregate usage. if you need stats for each DomU, check the respective tun devices. <br />
<br />
Q (N5.3): I have some trouble finding the best solution to my networking requirements. <br />
I want to have the following things: <br />
-dom0 : have 2 physical networks devices * 1 eth with public IP (static) * 1 eth with private IP (static) <br />
-domU * 1 eth with private IP <br />
-I also want openVPN solution to let people outside the private network have access to it. <br />
-A DHCP server is required so that domU get their IP from it. <br />
I have debian lenny and xen 3.2 installed and working. Actually openvpn and dhcp are on the dom0. All is fine *except* that domU don't have access to internet (this is my main problem). My current config use network-bridge netdev=eth1 (eth1 have a static private ip). <br />
It is perhaps better to have dhcp and openvpn server in a domU, feel free to suggest what you think is the best choice (and the config that go with it) :) <br />
<br />
A (N5.3): When designing such setups, with bridge networking, I often find it easier to think of dom0 as a switch or router, and domU like any other physical server on your network. <br />
In your setup you're making dom0 act as router/firewall. Your problem is that probably you haven't setup ip forwarding and NAT on dom0 to allow domU internet access. <br />
Note that (if you want) you could also have dom0 act like a switch. In that scenario you'd need another domU, with two network interfaces connected to both dom0's eth0 and eth1, acting as router/firewall. <br />
<br />
Q (N5.4): I have been trying to get a HVM DomU running and being able to connect to a vlan. I am starting to get the feeling that at least the hw emulations I have tried do not supoprt vlans. Also all the things I have found online would have me creating the vlans inside the Dom0 and pushing them to the DomU's as regular interface<br />
<br />
A (N5.4): You could always have a trunk port in your dom0 and create bridges for each VLAN for xen. <br />
You can even script it so you can add it to boot time. <br />
If you have the VLAN trunk set up, you can create bridges as follows. <br />
For this example, my trunk interface is on eth0 and the vlan I am adding is 2. <br />
<!-- # vconfig add eth0 2 # brctl addbr xenbr2 # brctl addif xenbr2 eth0.2 # ifconfig eth0.2 up # ifconfig xenbr2 up --><br />
Now all you would add in the domU configuration file is: <br />
vif=['bridge=xenbr2'] <br />
And you would be on VLAN 2. <br />
Otherwise I'm pretty sure you would have to pass through the network card to get VLAN access. <br />
You can also script this and give it a space separated list of VLANs and loop it through. I will leave this up to you though. <br />
<br />
== High Availability Questions ==<br />
=== Services ===<br />
<br />
Q (HA1.0): What software exists for Xen to handle high availability? <br />
<br />
A (HA1.0): Here are several tools that currently exist:<br />
CentOS Cluster<br />
Project Kemari - http://www.osrg.net/kemari/<br />
Project Remus - http://blog.xen.org/index.php/2009/04/02/project-remus-released/<br />
Linux Cluster Resource Manager - http://clusterlabs.org/mediawiki/images/f/fb/Configuration_Explained.pdf <br />
<br />
Q (HA1.1): I'm not sure about how snapshots works on Xen. For example, if I snapshot a DomU with 10GB HD will take, for example, 30 seconds. But, if I snapshot a DomU with a 100GB HD will take longer (I guess). <br />
So, I wanna know how the snapshot works on xen. What if I want to move a snapshotted with a 100GB HD from a Dom0 to another Dom0? I've to move a 100GB file? <br />
<br />
A (HA1.1): You could try this approach: <br />
http://www.infohit.net/blog/post/using-lvm2-snapshots-to-provide-rollback-functionality-for-xen.html <br />
Makes snapshots quite quick. <br />
<br />
== Performance Questions ==<br />
<br />
== Security Questions ==<br />
<br />
Q(S1.0): If I install minimal linux for XEN in dom0 and a periphery firewall in domU and other applications in other instances of domU, is it possible to restrict/bind the network card to domU having periphery firewall and from there forward packets for dom0 or for other domUs? <br />
Is this possible? If so, is it secure? Or does dom0 always have direct access to Network Card and needs a separate firewall? And packets will always route from dom0 to all domUs ? <br />
What are the issues involved? <br />
<br />
A(S1.0): The approach I've used at home is to hide a network card from Dom0 (see pic-back.hide) and pass it through to a DomU which then sees it as a native interface. I then run a firewall in the DomU and the outside traffic does NOT go through Dom0. The route for packets is then : <br />
real i/f -> DomU (firewall) -> VIF -> int bridge [ Dom0 | VIF -> DomU ] <br />
From security perspective, this is the same as having an L2 switch (when dom0's bridges have no IP address) or L3 switch (when dom0's bridges have an IP address) <br />
<br />
Q(S1.1): I want to use a Disk Encryption and the conplete physikal Disk in a DomU. I prefere Truecrypt or Loop-aes. i will going to test loop-aes cause it should have the better performance. <br />
But, did anybody here using truecrypt or loop-aes ? What is the better one, in the fact of speed ? <br />
<br />
A(S1.1): dm-crypt/luks is one option, and performs about the same or better than loop-aes. Also it's less problematic because it doesn't use loop devic<br />
<br />
== Design/Misc Questions ==<br />
=== Nested Xen ===<br />
Q (D1.0): Can I run Xen within Xen? <br />
<br />
A (D1.0): Yes, You can install Xen on the base system, create a HVM domain, and install Xen in that guest domain. Note that the inner Xen system will not (yet) support HVM again.<br />
<br />
=== How does Xen Work ===<br />
<br />
Q (D3.0): How does Xen process System Calls on para-virtualized guest?<br />
<br />
A (D3.0): When ever a system call is invoked via interrupt or sys center control gets transferred to the kernel (ring 0), which is then handled via system call handler. System call never goes to libc but Libc is a library that provides POSIX interface to the user space applications and in a way wrapper for invocation of a system call. <br />
System call interrupt based [i386]: During booting process, linux kernel of a domU register's its IDT with Xen Hypervisor via HYPERVISOR_set_trap_table(trap_table); [arch/i386/kernel/traps-xen.c]. Xen maintains two IDT's, one global IDT (its own) and other per domain IDT. Xen uses global IDT to register the entire trap handler except for system call handler (int 0x80). When a VM gets scheduled, its system call handler (from per domain IDT table) is registered with the processor. Hence when a domain/VM executes a system call, its own handler is executed. <br />
Implementation differs for x86_64: Xen registers its own system call handler with the processor and from that handler routes the request to VM/Domain specific handler. <br />
<br />
Q (D3.1): How does Xen process System Calls on fully virtualized guest (HVM)?<br />
<br />
A (D3.1): For HVM domU there is no change in the behavior of the system call. HVM is only supported for Intel-VT and AMD-SVM processors. These processors are virtualization aware. Virtualization aware processors provide a new ring (Root-Ring 0) with higher privilege for VMM and Guest OS continues to runs with the same privilege (as without Xen) in Non-Root Ring 0. Guest OS can issue the system calls the way it used to without Xen.<br />
<br />
Q (D3.2): Can I run various DomU operating systems on a different Dom0 operating system?<br />
<br />
A (D3.2): Yes. <br />
<br />
Q (D3.3): Just curious to know, if there is any way that given a terminal to a box, we can determine is it a physical machine or a virtual machine ? <br />
<br />
A (D3.3): You should be able to get some useful information from the DMI, e.g: <br />
% for i in system-manufacturer system-product-name system-version\ system-serial-number; do echo -n "$i: "; sudo dmidecode -s $i; done <br />
system-manufacturer: Xen system-product-name: HVM domU system-version: 3.3.1 system-serial-number: 89e5915f-dead-beef-cefd-46904ea94c4a <br />
OR<br />
Probably checking kernel process, check your process table for: <br />
[xenwatch] [xenbus] <br />
Another clue is checking the kernle suffix, for example: <br />
<!-- # uname -r 2.6.24-23-xen --><br />
and the proc files: <br />
/proc/xen/capabilities <br />
<br />
Q (D3.4): What is STUBDOM ? <br />
<br />
A (D3.4): Stubdoms are lightweight 'service' or 'driver' domains. The initial purpose was to offload qemu (for hvm guests) out of dom0. <br />
So with stubdoms you can run hvm guest qemu in a separate stubdom, which boosts performance and makes it more secure. <br />
stubdoms can also run for example pv-grub for pv guests, making it more secure compared to pygrub, which always runs in dom0. <br />
http://wiki.xensource.com/xenwiki/StubDom <br />
Presentation about stubdoms at Xen Summit: http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf <br />
http://blog.xen.org/index.php/2008/08/28/xen-33-feature-stub-domains/ http://blog.xen.org/index.php/2008/08/28/xen-33-feature-hvm-device-model-domain/ http://lxr.xensource.com/lxr/source/stubdom/README <br />
<br />
Q (D3.5): When is hardware virtualization used in Xen? Is it required?<br />
<br />
A (D3.5): Xen uses hardware virtualization for HVM guests. Xen will not launch a HVM guest unless hardware virtualization is turned on.<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Remus&diff=5110Remus2012-09-24T15:05:05Z<p>OliverChick: /* Remus status */ 4.2 is no longer unstable</p>
<hr />
<div><!-- MoinMoin name: Remus --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: Remus --><br />
<!-- Page revision: 00000024 --><br />
<!-- Original date: Fri Oct 28 17:09:29 2011 (1319821769000000) --><br />
<br />
{{Needs_Refactor|Mixes elements of HowTo, Design Document and Glossary}}<br />
<br />
__NOTOC__<br />
= Remus =<br />
== Transparent high availability ("Fault Tolerance") for Xen VMs ==<br />
Remus provides transparent, comprehensive high availability to ordinary virtual machines running on the Xen virtual machine monitor. It does this by maintaining a completely up-to-date copy of a running VM on a backup server, which automatically activates if the primary server fails. Key features:<br />
<br />
* The backup VM is an exact copy of the primary VM. When failure happens, it continues running on the backup host as if failure had never occurred.<br />
* The backup is completely up-to-date. Even active TCP sessions are maintained without interruption.<br />
* Protection is transparent. Existing guests can be protected without modifying them in any way.<br />
== Remus requirements ==<br />
Remus requires the following components:<br />
<br />
* Xen hypervisor and tools with support for Remus.<br />
* Xen dom0 kernel with support for Remus.<br />
* PV (Paravirtual) guests need to have Remus support in the domU kernel.<br />
* Xen HVM guests don't require special changes for Remus. No kernel patches needed in the guest.<br />
* For initial testing: Shared storage accessible by both dom0s.<br />
* Actual Remus usage doesn't require or support shared storage!<br />
* DRBD storage backend is supported, allowing faster and automatic resynchronization after failed host is back online.<br />
<br />
== Remus status ==<br />
In Xen 4.0.0:<br />
<br />
* Xen hypervisor and tools have Remus support.<br />
* Only linux-2.6.18-xen is supported as Xen dom0 kernel with Remus.<br />
* If using a PV domU you need to run linux-2.6.18-xen as domU kernel.<br />
In Xen 4.0.1:<br />
<br />
* Pvops dom0 kernel support for Remus has been added in Xen 4.0.1-rc4, so it's available in Xen 4.0.1 final release. You can use Linux 2.6.32 based pvops dom0 kernel with Remus.<br />
* PV domU kernel still needs to be linux-2.6.18-xen.<br />
<br />
In Xen 4.2:<br />
* Many bugfixes to Remus.<br />
* Remus support for pvops domU kernels: Linux 2.6.39.2 and later upstream kernel.org versions are now supported as PV domU kernels, in addition to Jeremy's xen.git xen/stable-2.6.32.x branch.<br />
* For better Remus performance you should use a domU kernel with "suspend event channel" support, which means linux-2.6.18-xen, or any of the xenlinux forwardports (novell sles11sp1 2.6.32 kernel, for example). pvops domU kernels don't have suspend event channel support yet.<br />
* Checkpoint compression for less data to transfer between hosts.<br />
<br />
Note that if using linux-2.6.18-xen kernel it needs to be new enough to include Remus support/patches! It's recommended to download the latest version from linux-2.6.18-xen.hg mercurial repository for use with Remus.<br />
<br />
== Config options for Linux 2.6.32 pvops dom0 kernel for Remus ==<br />
<br />
Here are the .config options you need to enable for Remus, when using jeremy's xen.git xen/stable-2.6.32.x branch as dom0 kernel.<br />
<br />
<br />
<pre><br />
CONFIG_IFB=m<br />
CONFIG_IP_NF_IPTABLES=m<br />
CONFIG_IP_NF_FILTER=m<br />
CONFIG_NET_SCHED=y<br />
CONFIG_NET_SCH_PRIO=m<br />
CONFIG_NET_SCH_INGRESS=m<br />
CONFIG_NET_SCH_PLUG=m<br />
CONFIG_NET_CLS=y<br />
CONFIG_NET_CLS_BASIC=m<br />
CONFIG_NET_CLS_TCINDEX=m<br />
CONFIG_NET_CLS_U32=m<br />
CONFIG_NET_CLS_ACT=y<br />
CONFIG_NET_ACT_MIRRED=m<br />
</pre><br />
<br />
<br />
== Using Linux kernel v3.x as dom0 kernel for Remus Xen hosts ==<br />
<br />
Upstream Linux v3.x kernel contains Xen pvops dom0 support, but it does not contain "sch_plug" driver which is required for Remus. It's possible to manually add that driver to your custom upstream Linux v3.x kernel build. "sch_plug" driver is available for example from: http://pasik.reaktio.net/xen/remus/linux3x/ .<br />
<br />
== DRBD storage backend support for Remus ==<br />
<br />
A Remus version of DRBD can be found from git://aramis.nss.cs.ubc.ca/drbd-8.3-remus . Using DRBD instead of blktap2 for storage replication allows for quick resynchronization of the disk backend after failed host is back online. Since storage (re)synchronization is done online - while the VM is operational, there is no need to shutdown the VM. Once storage is synchronized, one can start, stop and restart Remus on a running VM anytime.<br />
<br />
== Links ==<br />
* The Remus project web site is http://nss.cs.ubc.ca/remus/ <br />
* Remus documentation: http://nss.cs.ubc.ca/remus/doc.html <br />
* Research/design paper about Remus: http://nss.cs.ubc.ca/remus/papers/remus-nsdi08.pdf .<br />
* Configuring and installing Remus tutorial: http://remusha.wikidot.com/<br />
* Latest linux-2.6.18-xen kernel is available from Mercurial tree at http://xenbits.xen.org/linux-2.6.18-xen.hg .<br />
<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Developers]]<br />
[[Category:Project]]<br />
[[Category:HowTo]]<br />
[[Category:Glossary]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_Project_Repositories&diff=5109Xen Project Repositories2012-09-24T14:59:41Z<p>OliverChick: Updated repos, as 4.2 is now current</p>
<hr />
<div><!-- MoinMoin name: XenRepositories --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: XenRepositories --><br />
<!-- Page revision: 00000014 --><br />
<!-- Original date: Wed Jul 20 16:38:16 2011 (1311179896000000) --><br />
<br />
__NOTOC__<br />
= Xen Repositories =<br />
<br />
''staging'' trees are automatically pushed to the primary trees after test <br />
<br />
<br />
== Current Xen stable release branch (xen-4.2-testing) ==<br />
<br />
The latest stable release from this branch is available from http://www.xen.org/products/xen_source.html .<br />
<br />
These repositories contain the in-progress work on the next release on the previous stable branch.<br />
<br />
* '''[http://xenbits.xen.org/hg/xen-4.2-testing.hg xen-4.2-testing.hg]''' (''[http://xenbits.xen.org/hg/staging/xen-4.2-testing.hg staging]'').<br />
* '''[http://xenbits.xen.org/gitweb/?p=qemu-xen-4.2-testing.git qemu-xen-4.2-testing.hg]''' (''[http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-4.2-testing.git staging]'').<br />
<br />
== Previous Xen stable release branch (xen-4.1-testing) ==<br />
<br />
The latest stable release from this branch is available from http://www.xen.org/products/xen_archives.html .<br />
<br />
These repositories contain the in-progress work on the next release on the previous stable branch.<br />
<br />
* '''[http://xenbits.xen.org/hg/xen-4.1-testing.hg xen-4.1-testing.hg]''' (''[http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg staging]'').<br />
* '''[http://xenbits.xen.org/gitweb/?p=qemu-xen-4.1-testing.git qemu-xen-4.1-testing.hg]''' (''[http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-4.1-testing.git staging]'').<br />
<br />
== Xen development branch (xen-unstable) ==<br />
<br />
These repositories contain the development version of Xen.<br />
<br />
* '''[http://xenbits.xen.org/hg/xen-unstable.hg xen-unstable.hg]''' (''[http://xenbits.xen.org/hg/staging/xen-unstable.hg staging]'').<br />
* '''[http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git qemu-xen-unstable.hg]''' (''[http://xenbits.xen.org/gitweb/?p=staging/qemu-xen-unstable.git staging]'').<br />
<br />
In addition to the above we have a[http://lxr.xensource.com/lxr/source xen-unstable.hg source browser].<br />
<br />
== Git mirror of Xen ==<br />
<br />
In addition to the mercurial repositories of Xen, there is a Git repository which contain several branches:<br />
* master -> xen-unstable.hg<br />
* staging -> staging/xen-unstable.hg<br />
* stable-4.0 -> xen-4.0-testing.hg<br />
* stable-4.1 -> xen-4.1-testing.hg<br />
<br />
[http://xenbits.xen.org/gitweb/?p=xen.git xen.git]<br />
<br />
== Kernels ==<br />
<br />
=== Linux ===<br />
<br />
For more information on selecting suitable domain 0 kernels please see http://wiki.xen.org/xenwiki/XenDom0Kernels.<br />
<br />
The recommended stable Linux kernel branch is:<br />
* [http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=shortlog;h=xen/stable-2.6.32.x xen.git xen/stable-2.6.32.x]<br />
<br />
Additional information:<br />
* List of features in various Xen kernel trees: [[XenKernelFeatures]]<br />
* More information about pvops kernels: [[XenParavirtOps]]<br />
<br />
== Browse all source repositories hosted on xenbits ==<br />
<br />
* [http://xenbits.xen.org/hg/ Mercurial Repositories]<br />
* [http://xenbits.xen.org/gitweb/ Git Repositories]<br />
* [http://xenbits.xen.org/ext/ Additional Mercurial Repositories]<br />
<br />
[[Category:Developers]]<br />
[[Category:Development Process]]<br />
[[Category:Xen]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Category:HowTo&diff=5107Category:HowTo2012-09-24T14:44:58Z<p>OliverChick: /* Xen Management Tools */ Old link removed</p>
<hr />
<div>[[File:XenFuPandaWikiHowTo.png]]<br />
<br />
'''Go [[#pages|here]] to see a list of documents in this category.'''<br />
----<br />
This category contains HowTo documents. HowTo documents are detailed "how to" documents on specific subjects. <br />
__NOTOC__<br />
== External HowTo's ==<br />
<br />
== XCP ==<br />
* [http://grantmcwilliams.com/tech/virtualization/xcp-howtos Grant McWilliam's XCP HowTos]<br />
<br />
== File System ==<br />
* [http://www.virtuatopia.com/index.php/Creating_and_Booting_a_Xen_Guest_domainU_using_an_NFS_Mounted_Root_Filesystem How to Create and Boot a Xen Guest domainU using an NFS Mounted Root Filesystem]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Xen_Virtual_Guest_Filesystem_on_a_Disk_Image_(Cloning_Host_System) How to Build a Xen Virtual Guest Filesystem on a Disk Image (Cloning Host System)]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Xen_Virtual_Guest_Filesystem_using_Logical_Volume_Management_(LVM) How to Build a Xen Virtual Guest Filesystem using Logical Volume Management (LVM)]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Xen_Virtual_Guest_Filesystem_on_a_Physical_Disk_Partition_(Cloning_Host_System) How to Build a Xen Virtual Guest Filesystem on a Physical Disk Partition (Cloning Host System)]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Debian_or_Ubuntu_Xen_Guest_Root_Filesystem_using_debootstrap How to Build a Debian or Ubuntu Xen Guest Root Filesystem using debootstrap]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Xen_Guest_Root_Filesystem_using_yum_and_rpm Building a Xen Guest Root Filesystem using yum and rpm]<br />
<br />
== DomainU Guest ==<br />
* [http://grantmcwilliams.com/tech/virtualization/xen-howtos/ Grant McWilliam's Xen HowTos]<br />
* [http://www.virtuatopia.com/index.php/Using_QEMU_Disk_Images_for_Xen_DomainU_Systems How to Use QEMU Disk Images for Xen DomainU Systems]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Xen_Guest_Domain_using_Xen-Tools How to Build a Xen Guest Domain using Xen-Tools]<br />
* [[Setting boot order for domUs]]<br />
<br />
== Windows 7/XP/Vista/Server 2008 ==<br />
* [http://www.virtuatopia.com/index.php/Installing_and_Running_Windows_7_as_a_Xen_HVM_domainU_Guest Installing and Running Windows 7 as a Xen HVM domainU Guest]<br />
* [http://www.virtuatopia.com/index.php/Installing_and_Running_Windows_XP_or_Vista_as_a_Xen_HVM_domainU_Guest Installing and Running Windows XP or Vista as a Xen HVM domainU Guest]<br />
* [http://www.virtuatopia.com/index.php/Virtualizing_Windows_Server_2008_with_Xen Virtualizing Windows Server 2008 with Xen]<br />
* [http://www.valent-blog.eu/2008/01/13/full-virtualization-di-windows-con-xen/ Create a windows 32-bit domU (in italian)]<br />
<br />
== Consoles ==<br />
* [http://www.virtuatopia.com/index.php/Configuring_a_VNC_based_Graphical_Console_for_a_Xen_Paravirtualized_domainU_Guest How to Configure a VNC based Graphical Console for a Xen Paravirtualized domainU Guest]<br />
* [http://www.virtuatopia.com/index.php/Running_and_Connecting_to_VNC_Servers_on_a_Xen_Guest_(domainU)_System How to Run and Connect to VNC Servers on a Xen Guest (domainU) System]<br />
<br />
== DomainU Migration ==<br />
* [http://www.virtuatopia.com/index.php/Migrating_Xen_domainU_Guests_Between_Host_Systems How to Perform Live Xen domainU Guest Migrations]<br />
<br />
== USB Devices ==<br />
* [http://www.virtuatopia.com/index.php/Adding_USB_Devices_to_a_Xen_HVM_domainU_Guest Adding USB Devices to a Xen HVM Guest]<br />
<br />
== Install Xen on Various Linux Distros and [[OpenSolaris]] ==<br />
* [https://help.ubuntu.com/community/Xen Installing Xen on Ubuntu]<br />
* [http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer Installing Xen on Debian]<br />
* [http://rackerhacker.com/2011/08/05/xen-4-1-on-fedora-15-with-linux-3-0/ Installing Xen 4.1 on Fedora 15]<br />
* [http://www.suse.com/documentation/sled11/singlehtml/book_xen/book_xen.html Xen on openSUSE]<br />
* [http://www.netbsd.org/Ports/xen/howto.html NetBSD/xen Howto ]<br />
<br />
== Writing Good HowTos ==<br />
Good HowTo documents include<br />
* An '''overview''' that helps potential readers to determine quickly if a particular How-To matches their interests or needs. <br />
* Describe your '''intended audience''':<br />
* State the '''purpose''' of your HowTo: this will explain how the reader will benefit by reading it.<br />
* '''Preconditions''': inform your reader about any required knowledge, configuration, or resources they may need before stepping through your How-To.<br />
* '''Step-by-step instractions''': in a precise, step-by-step approach, walk your reader through the process. Make sure your reader can reproduce your intended result by following your exact steps. Make the learning process efficient by supplying sample code snippets or configuration details as necessary.<br />
<br />
==Add a page to this category==<br />
To add a page or uploaded file to a category, simply edit the page and add the following text at the bottom of the page (note that a page can be in several categories).<br />
<nowiki>[[</nowiki>{{ns:category}}:'''''HowTo''''']]<br />
<br />
{{Anchor|pages}}<br />
{{Languages|:Category:HowTo}}</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Category:HowTo&diff=5106Category:HowTo2012-09-24T14:44:30Z<p>OliverChick: /* Install Xen on Various Linux Distros and OpenSolaris */ Removed old links</p>
<hr />
<div>[[File:XenFuPandaWikiHowTo.png]]<br />
<br />
'''Go [[#pages|here]] to see a list of documents in this category.'''<br />
----<br />
This category contains HowTo documents. HowTo documents are detailed "how to" documents on specific subjects. <br />
__NOTOC__<br />
== External HowTo's ==<br />
<br />
== XCP ==<br />
* [http://grantmcwilliams.com/tech/virtualization/xcp-howtos Grant McWilliam's XCP HowTos]<br />
<br />
== File System ==<br />
* [http://www.virtuatopia.com/index.php/Creating_and_Booting_a_Xen_Guest_domainU_using_an_NFS_Mounted_Root_Filesystem How to Create and Boot a Xen Guest domainU using an NFS Mounted Root Filesystem]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Xen_Virtual_Guest_Filesystem_on_a_Disk_Image_(Cloning_Host_System) How to Build a Xen Virtual Guest Filesystem on a Disk Image (Cloning Host System)]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Xen_Virtual_Guest_Filesystem_using_Logical_Volume_Management_(LVM) How to Build a Xen Virtual Guest Filesystem using Logical Volume Management (LVM)]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Xen_Virtual_Guest_Filesystem_on_a_Physical_Disk_Partition_(Cloning_Host_System) How to Build a Xen Virtual Guest Filesystem on a Physical Disk Partition (Cloning Host System)]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Debian_or_Ubuntu_Xen_Guest_Root_Filesystem_using_debootstrap How to Build a Debian or Ubuntu Xen Guest Root Filesystem using debootstrap]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Xen_Guest_Root_Filesystem_using_yum_and_rpm Building a Xen Guest Root Filesystem using yum and rpm]<br />
<br />
== DomainU Guest ==<br />
* [http://grantmcwilliams.com/tech/virtualization/xen-howtos/ Grant McWilliam's Xen HowTos]<br />
* [http://www.virtuatopia.com/index.php/Using_QEMU_Disk_Images_for_Xen_DomainU_Systems How to Use QEMU Disk Images for Xen DomainU Systems]<br />
* [http://www.virtuatopia.com/index.php/Building_a_Xen_Guest_Domain_using_Xen-Tools How to Build a Xen Guest Domain using Xen-Tools]<br />
* [[Setting boot order for domUs]]<br />
<br />
== Windows 7/XP/Vista/Server 2008 ==<br />
* [http://www.virtuatopia.com/index.php/Installing_and_Running_Windows_7_as_a_Xen_HVM_domainU_Guest Installing and Running Windows 7 as a Xen HVM domainU Guest]<br />
* [http://www.virtuatopia.com/index.php/Installing_and_Running_Windows_XP_or_Vista_as_a_Xen_HVM_domainU_Guest Installing and Running Windows XP or Vista as a Xen HVM domainU Guest]<br />
* [http://www.virtuatopia.com/index.php/Virtualizing_Windows_Server_2008_with_Xen Virtualizing Windows Server 2008 with Xen]<br />
* [http://www.valent-blog.eu/2008/01/13/full-virtualization-di-windows-con-xen/ Create a windows 32-bit domU (in italian)]<br />
<br />
== Consoles ==<br />
* [http://www.virtuatopia.com/index.php/Configuring_a_VNC_based_Graphical_Console_for_a_Xen_Paravirtualized_domainU_Guest How to Configure a VNC based Graphical Console for a Xen Paravirtualized domainU Guest]<br />
* [http://www.virtuatopia.com/index.php/Running_and_Connecting_to_VNC_Servers_on_a_Xen_Guest_(domainU)_System How to Run and Connect to VNC Servers on a Xen Guest (domainU) System]<br />
<br />
== DomainU Migration ==<br />
* [http://www.virtuatopia.com/index.php/Migrating_Xen_domainU_Guests_Between_Host_Systems How to Perform Live Xen domainU Guest Migrations]<br />
<br />
== USB Devices ==<br />
* [http://www.virtuatopia.com/index.php/Adding_USB_Devices_to_a_Xen_HVM_domainU_Guest Adding USB Devices to a Xen HVM Guest]<br />
<br />
== Install Xen on Various Linux Distros and [[OpenSolaris]] ==<br />
* [https://help.ubuntu.com/community/Xen Installing Xen on Ubuntu]<br />
* [http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer Installing Xen on Debian]<br />
* [http://rackerhacker.com/2011/08/05/xen-4-1-on-fedora-15-with-linux-3-0/ Installing Xen 4.1 on Fedora 15]<br />
* [http://www.suse.com/documentation/sled11/singlehtml/book_xen/book_xen.html Xen on openSUSE]<br />
* [http://www.netbsd.org/Ports/xen/howto.html NetBSD/xen Howto ]<br />
<br />
== Xen Management Tools ==<br />
* [http://www.howtoforge.com/xen_tools_xen_shell_argo Managing Xen With Xen-Tools, Xen-Shell, And Argo]<br />
<br />
== Writing Good HowTos ==<br />
Good HowTo documents include<br />
* An '''overview''' that helps potential readers to determine quickly if a particular How-To matches their interests or needs. <br />
* Describe your '''intended audience''':<br />
* State the '''purpose''' of your HowTo: this will explain how the reader will benefit by reading it.<br />
* '''Preconditions''': inform your reader about any required knowledge, configuration, or resources they may need before stepping through your How-To.<br />
* '''Step-by-step instractions''': in a precise, step-by-step approach, walk your reader through the process. Make sure your reader can reproduce your intended result by following your exact steps. Make the learning process efficient by supplying sample code snippets or configuration details as necessary.<br />
<br />
==Add a page to this category==<br />
To add a page or uploaded file to a category, simply edit the page and add the following text at the bottom of the page (note that a page can be in several categories).<br />
<nowiki>[[</nowiki>{{ns:category}}:'''''HowTo''''']]<br />
<br />
{{Anchor|pages}}<br />
{{Languages|:Category:HowTo}}</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_on_4_app_servers&diff=5100Xen on 4 app servers2012-09-24T14:30:50Z<p>OliverChick: Fixed more indentation problems</p>
<hr />
<div><!-- MoinMoin name: Xen_on_4_app_servers --><br />
<!-- Comment: Fixed some typos and some cleanup --><br />
<!-- WikiMedia name: Xen on 4 app servers --><br />
<!-- Page revision: 00000048 --><br />
<!-- Original date: Mon Apr 26 00:34:16 2010 (1272242056000000) --><br />
<br />
<!-- ## page was renamed from How to run 4 Application servers on same piece of hardware with a separate OS for each of them. --><br />
<!-- ## Please edit system and help pages ONLY in the moinmaster wiki! For more --><br />
<!-- ## information, please see [[MoinMaster]]:[[MoinPagesEditorGroup]]. --><br />
<!-- ##master-page:[[Category:Template]] --><br />
<!-- ##master-date:Unknown-Date --><br />
<!-- #format wiki --><br />
<!-- #language en --><br />
<br />
<br />
== Objective ==<br />
To have four application servers which will be running on top of Xen. These servers will have Debian as their operating system. These four servers will be hosting the applications which are critical to the functioning of organization. We are going to demonstrate how this is possible using Xen and Debian Linux distribution and Apache2.<br />
<br />
'''System Description:''' Dell [[PowerEdge]] R710,Debian (amd64), 500GB Hard disk, 8GB RAM, Quad Core Processor.<br />
<br />
'''Key Terms:''' Virtualization, Reverse Proxy on Apache2<br />
<br />
'''Who should read this document:'''<br />
<br />
* People/Organizations who want to have different servers for each application which will be dedicated to those applications without buying a separate hardware for these servers.<br />
*System administrators who are new to Linux on Xen.<br />
*Any one who is interested in testing virtualization.<br />
*Curious people<br />
<br />
Before you go to read this document familiarize yourself with DNS, Gateway and some basic networking stuff. Those who want to go a level higher they should learn how to use iptables on Linux.<br />
<br />
== What is virtualization? ==<br />
* Virtualization is the name given to a concept where in you run multiple operating systems, at the same time, on one computer.<br />
* Rather than running operating systems on the hardware, a small layer of software, called a hypervisor, runs between the operating system and hardware. The hypervisor's role is to provide a platform that can run multiple operating systems concurrently.<br />
*These guest operating systems can be Windows, Linux, Solaris or any other operating system.<br />
<br />
== Test Infrastructure and Network ==<br />
We are going to install Debian on a Dell [[PowerEdge]] R710 Server. We have a network whose configuration is as follows<br />
<br />
<pre><br />
Dom0 with IP 192.168.0.100<br />
DomU1 with IP 192.168.0.11<br />
DomU2 with IP 192.168.0.12<br />
DomU3 with IP 192.168.0.13<br />
DomU4 with IP 192.168.0.14<br />
</pre><br />
<br />
All of these have a subnet mask of 255.255.255.0 and 192.168.0.1 is the gateway<br />
<br />
== Preparing the base system Dom0 ==<br />
<br />
Follow instructions at http://www.debian.org/releases/stable/installmanual to install the latest Debian version.<br />
<br />
== Installing Xen on Debian ==<br />
There are two ways to install Xen.<br />
* Compile Xen from sources. See [[http://wiki.xen.org/wiki/Compiling_Xen_From_Source]]<br />
* Install a precompiled binary package.<br />
<br />
We have chosen the second approach.<br />
<br />
<pre><br />
apt-get install xen-linux-system<br />
dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen<br />
update-grub<br />
</pre><br />
<br />
Setup networking. See [[Host_Configuration/Networking]].<br />
<br />
== Creating LVM based DomU Images on Xen for Debian ==<br />
Before we go on to proceed with LVM based images we will check for the LVM setup.You can skip this section if you have already set a LVM based setup and go to Creation of LVM based images.<br />
<br />
* Check your hard disk structure<br />
<pre><br />
dom0#fdisk -l<br />
Device Boot Start End Blocks Id System<br />
/dev/sda1 1 1216 9767488+ 83 Linux<br />
/dev/sda2 1217 60801 478616512+ 5 Extended<br />
/dev/sda5 1217 4863 29294496 82 Linux swap / Solaris<br />
/dev/sda6 4864 17021 97659103+ 83 Linux<br />
/dev/sda7 17022 29179 97659103+ 83 Linux<br />
/dev/sda8 29180 41337 97659103+ 83 Linux<br />
/dev/sda9 41338 60801 156344548+ 83 Linux<br />
</pre><br />
<br />
* First you need to install LVM: <br />
<pre><br />
apt-get install lvm2<br />
</pre><br />
<br />
* Add each disk partition as a physical volume, into LVM.<br />
<pre><br />
dom0#pvcreate /dev/sda6 /dev/sda7 /dev/sda8 /dev/sda9<br />
Physical volume "/dev/sda6" successfully created<br />
Physical volume "/dev/sda7" successfully created<br />
Physical volume "/dev/sda8" successfully created<br />
Physical volume "/dev/sda9" successfully created<br />
</pre><br />
<br />
You can run pvdisplay to learn about the current state of your physical volumes.<br />
<br />
<pre><br />
dom0:~# pvdisplay<br />
--- Physical volume ---<br />
PV Name /dev/sda6<br />
VG Name<br />
PV Size 93.13 GB / not usable 2.22 MB<br />
Allocatable yes<br />
PE Size (KByte) 4096<br />
Total PE 23842<br />
Free PE 128<br />
Allocated PE 23714<br />
PV UUID l8lIGR-246n-js5p-bb6y-w2zI-XCdy-r6H2CY<br />
--- Physical volume ---<br />
PV Name /dev/sda7<br />
VG Name<br />
PV Size 93.13 GB / not usable 2.22 MB<br />
Allocatable yes (but full)<br />
PE Size (KByte) 4096<br />
Total PE 23842<br />
Free PE 0<br />
Allocated PE 23842<br />
PV UUID m6eqKv-ud3V-TJP2-p9E3-k4FK-3SxM-ZSzKrz<br />
--- Physical volume ---<br />
PV Name /dev/sda8<br />
VG Name<br />
PV Size 93.13 GB / not usable 2.22 MB<br />
Allocatable yes (but full)<br />
PE Size (KByte) 4096<br />
Total PE 23842<br />
Free PE 0<br />
Allocated PE 23842<br />
PV UUID DGGrt0-Bxhn-JmYc-lq2O-acw8-DAt3-KaPC7P<br />
--- Physical volume ---<br />
PV Name /dev/sda9<br />
VG Name<br />
PV Size 149.10 GB / not usable 228.50 KB<br />
Allocatable yes (but full)<br />
PE Size (KByte) 4096<br />
Total PE 38170<br />
Free PE 0<br />
Allocated PE 38170<br />
PV UUID 6ushwj-9Rse-cGGu-RXDk-2vTe-uSbw-6N5R42<br />
</pre><br />
<br />
Now we will create our volume group virtualization and add /dev/sda6 - /dev/sda7- /dev/sda8 /dev/sda9<br />
<br />
<pre><br />
dom0:~# vgcreate virtualization /dev/sda6 /dev/sda7 /dev/sda8 /dev/sda9<br />
Volume group "virtualization" successfully created<br />
dom0:~# vgscan<br />
Reading all physical volumes. This may take a while...<br />
Found volume group "virtualization" using metadata type lvm2<br />
</pre><br />
<br />
Follow the instructions for installing a Debian guest, [[http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer]]<br />
<br />
<br />
<br />
To use the newly created guest, execute<br />
<br />
<pre><br />
xl create -c /etc/xen/debian.cfg<br />
</pre><br />
<br />
To shut down the guest, execute <br />
<br />
<pre><br />
xl shutdown debian<br />
</pre><br />
<br />
in dom0.<br />
<br />
For more commands you can use xl help. For example, if you have four different DomU's installed, this will show:<br />
<br />
<pre><br />
dom0:~# xl list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 875 8 r----- 361.4<br />
domu1 7 3072 4 -b---- 32.9<br />
domu2 9 1024 4 -b---- 32.0<br />
domu3 8 1024 4 -b---- 34.0<br />
domu4 6 2048 4 -b---- 32.2<br />
</pre><br />
<br />
If you want domu1 to start automatically at the next boot of the system, then execute:<br />
<br />
<pre><br />
ln -s /etc/xen/domu1.cfg /etc/xen/auto<br />
</pre><br />
== Configuration files ==<br />
A sample configuration file for domU looks like this<br />
<br />
<pre><br />
kernel = '/boot/vmlinuz-3.5.0'<br />
ramdisk = '/boot/initrd.img-3.5.0'<br />
memory = '2048'<br />
<br />
#<br />
# Disk device(s).<br />
#<br />
disk = [<br />
'phy:/dev/virtualization/domu1-swap,xvda1,w',<br />
'phy:/dev/virtualization/domu1-disk,xvda2,w',<br />
]<br />
#<br />
# Hostname<br />
#<br />
name = 'domu1'<br />
#<br />
# Networking<br />
#<br />
vif = [ 'ip=192.168.0.11,mac=00:16:3E:66:03:E1' ]<br />
#<br />
# Behaviour<br />
#<br />
on_poweroff = 'destroy'<br />
on_reboot = 'restart'<br />
on_crash = 'restart'<br />
vcpus = '4'<br />
</pre><br />
<br />
== Setting up Networking ==<br />
We are now going to set up each of our guests with networking. Each will have its own IP address. The result of this setup will look like:<br />
<br />
<pre><br />
IP of Domu1:192.168.0.11 Lets call it as a<br />
IP of Domu2:192.168.0.12 Lets call it as b<br />
IP of Domu3:192.168.0.13 Lets Call it as c<br />
IP of Domu4:192.168.0.14 Lets Call it as d<br />
Ip of Dom0 :192.168.0.100 (Will behave as Gateway for DomU's)<br />
Lets call Dom0 as A<br />
Gateway for the network is 192.168.0.1<br />
We will call it as G.<br />
</pre><br />
<br />
We have to enable IP forwarding for the hosts to appear on network:<br />
<br />
dom0:~# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
<br />
In /etc/sysctl.conf uncomment net.ipv4.ip_forward=1<br />
<br />
Now your hosts should appear on network. Inspite of the fact that that a,b,c,d are DomU's they are available on network as actual machines.<br />
<br />
DNS should point to actual DNS of your network since with IP Forwarding enabled the DomU's will be able to access the proxy and rest of the network.<br />
<br />
Now since you have enabled IP Forwarding so you should be able to ping from any other machine to you DomU's to make sure the things are working as expected you ping from C to a you should get a reply.<br />
<br />
<pre><br />
ping 192.168.0.11 <br />
PING 192.168.0.11 (192.168.0.11) 56(84) bytes of data.<br />
64 bytes from 192.168.0.11: icmp_seq=1 ttl=64 time=3.32 ms<br />
64 bytes from 192.168.0.11: icmp_seq=2 ttl=64 time=0.045 ms<br />
^C<br />
--- 192.168.0.11 ping statistics ---<br />
2 packets transmitted, 2 received, 0% packet loss, time 1008ms<br />
rtt min/avg/max/mdev = 0.045/1.685/3.326/1.641 ms<br />
</pre><br />
<br />
So DomU1 is accessible from C and in turn from the rest of the network. If you experience problems, ensure you have enabled ip forwarding in Dom0.<br />
<br />
Xen has a default network managment which will create a bridge whose name will be same as your interface name. Follow instructions at [[Network_Configuration_Examples_(Xen_4.1%2B)]].<br />
<br />
== Install applications ==<br />
Now follow instructions to install and configure your desired applications.<br />
<br />
== Check points and possible errors ==<br />
* Before you choose to install separate OS as DomU's calculte the amount of RAM they consume and swap space that to allocate them. When Dom's run they require a certain amount of memory to be allocated to them. Suppose you have 8 GB RAM and you decide to give 2GB Ram to each of the virtual hosts, you create then you won't be left with memory for Dom0. We planned to give 875 Mb memory to the Dom0 so we were left with 8192-875=7317Mb of Ram which we planned to give to the DomU's. The memory assigned to each domain is shown by the command xl list.<br />
<br />
<pre><br />
dom0:~# xl list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 875 8 r----- 361.4<br />
domu1 7 3072 4 -b---- 32.9<br />
domu2 9 1024 4 -b---- 32.0<br />
domu3 8 1024 4 -b---- 34.0<br />
domu4 6 2048 4 -b---- 32.2<br />
</pre><br />
<br />
Where domu1,domu2,domu3,domu4 are different dom's running.<br />
<br />
If you encounter any problem doing above or want to give some suggestion that can be added in this page drop me a mail Tapas: mightydreams@gmail.com<br />
<br />
[[Category:Xen]]<br />
[[Category:Tutorial]]<br />
[[Category:Example]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_on_4_app_servers&diff=5098Xen on 4 app servers2012-09-24T14:25:29Z<p>OliverChick: Removed outdated content, and tried to replace with links to other work. Improved SPAG. Renamed xenserver to dom0 to avoid confusion.</p>
<hr />
<div><br />
<br />
<!-- MoinMoin name: Xen_on_4_app_servers --><br />
<!-- Comment: Fixed some typos and some cleanup --><br />
<!-- WikiMedia name: Xen on 4 app servers --><br />
<!-- Page revision: 00000048 --><br />
<!-- Original date: Mon Apr 26 00:34:16 2010 (1272242056000000) --><br />
<br />
<!-- ## page was renamed from How to run 4 Application servers on same piece of hardware with a separate OS for each of them. --><br />
<!-- ## Please edit system and help pages ONLY in the moinmaster wiki! For more --><br />
<!-- ## information, please see [[MoinMaster]]:[[MoinPagesEditorGroup]]. --><br />
<!-- ##master-page:[[Category:Template]] --><br />
<!-- ##master-date:Unknown-Date --><br />
<!-- #format wiki --><br />
<!-- #language en --><br />
<br />
{{Needs_Formatting|Quite a lot of indentation issues}}<br />
<br />
== Objective ==<br />
To have four application servers which will be running on top of Xen. These servers will have Debian as their operating system. These four servers will be hosting the applications which are critical to the functioning of organization. We are going to demonstrate how this is possible using Xen and Debian Linux distribution and Apache2.<br />
<br />
'''System Description:''' Dell [[PowerEdge]] R710,Debian (amd64), 500GB Hard disk, 8GB RAM, Quad Core Processor.<br />
<br />
'''Key Terms:''' Virtualization, Reverse Proxy on Apache2<br />
<br />
'''Who should read this document:'''<br />
<br />
* People/Organizations who want to have different servers for each application which will be dedicated to those applications without buying a separate hardware for these servers.<br />
*System administrators who are new to Linux on Xen.<br />
*Any one who is interested in testing virtualization.<br />
*Curious people<br />
<br />
Before you go to read this document familiarize yourself with DNS, Gateway and some basic networking stuff. Those who want to go a level higher they should learn how to use iptables on Linux.<br />
<br />
== What is virtualization? ==<br />
* Virtualization is the name given to a concept where in you run multiple operating systems, at the same time, on one computer.<br />
* Rather than running operating systems on the hardware, a small layer of software, called a hypervisor, runs between the operating system and hardware. The hypervisor's role is to provide a platform that can run multiple operating systems concurrently.<br />
*These guest operating systems can be Windows, Linux, Solaris or any other operating system.<br />
<br />
== Test Infrastructure and Network ==<br />
* We are going to install Debian on a Dell [[PowerEdge]] R710 Server. We have a network whose configuration is as follows<br />
<br />
<pre><br />
Dom0 with IP 192.168.0.100<br />
DomU1 with IP 192.168.0.11<br />
DomU2 with IP 192.168.0.12<br />
DomU3 with IP 192.168.0.13<br />
DomU4 with IP 192.168.0.14<br />
</pre><br />
<br />
All of these have a subnet mask of 255.255.255.0 and 192.168.0.1 is the gateway<br />
<br />
== Section A: Preparing the base system Dom0 ==<br />
<br />
Follow instructions at http://www.debian.org/releases/stable/installmanual to install the latest Debian version.<br />
<br />
== Step B Installing Xen on Debian ==<br />
There are two ways to install Xen.<br />
* Compile Xen from sources. See [[http://wiki.xen.org/wiki/Compiling_Xen_From_Source]]<br />
* Install a precompiled binary package.<br />
<br />
We have chosen the second approach.<br />
<br />
===Installing Xen===<br />
<br />
<pre><br />
apt-get install xen-linux-system<br />
dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen<br />
update-grub<br />
</pre><br />
<br />
Setup networking. See [[Host_Configuration/Networking]].<br />
<br />
=== Creating LVM based DomU Images on Xen for Debian ===<br />
Before we go on to proceed with LVM based images we will check for the LVM setup.You can skip this section if you have already set a LVM based setup and go to Creation of LVM based images.<br />
<br />
* Check your hard disk structure<br />
<pre><br />
dom0#fdisk -l<br />
Device Boot Start End Blocks Id System<br />
/dev/sda1 1 1216 9767488+ 83 Linux<br />
/dev/sda2 1217 60801 478616512+ 5 Extended<br />
/dev/sda5 1217 4863 29294496 82 Linux swap / Solaris<br />
/dev/sda6 4864 17021 97659103+ 83 Linux<br />
/dev/sda7 17022 29179 97659103+ 83 Linux<br />
/dev/sda8 29180 41337 97659103+ 83 Linux<br />
/dev/sda9 41338 60801 156344548+ 83 Linux<br />
</pre><br />
<br />
* First you need to install LVM: <br />
<pre><br />
apt-get install lvm2<br />
</pre><br />
<br />
* Add each disk partition as a physical volume, into LVM.<br />
<pre><br />
dom0#pvcreate /dev/sda6 /dev/sda7 /dev/sda8 /dev/sda9<br />
Physical volume "/dev/sda6" successfully created<br />
Physical volume "/dev/sda7" successfully created<br />
Physical volume "/dev/sda8" successfully created<br />
Physical volume "/dev/sda9" successfully created<br />
</pre><br />
<br />
You can run pvdisplay to learn about the current state of your physical volumes.<br />
<br />
<pre><br />
dom0:~# pvdisplay<br />
--- Physical volume ---<br />
PV Name /dev/sda6<br />
VG Name<br />
PV Size 93.13 GB / not usable 2.22 MB<br />
Allocatable yes<br />
PE Size (KByte) 4096<br />
Total PE 23842<br />
Free PE 128<br />
Allocated PE 23714<br />
PV UUID l8lIGR-246n-js5p-bb6y-w2zI-XCdy-r6H2CY<br />
--- Physical volume ---<br />
PV Name /dev/sda7<br />
VG Name<br />
PV Size 93.13 GB / not usable 2.22 MB<br />
Allocatable yes (but full)<br />
PE Size (KByte) 4096<br />
Total PE 23842<br />
Free PE 0<br />
Allocated PE 23842<br />
PV UUID m6eqKv-ud3V-TJP2-p9E3-k4FK-3SxM-ZSzKrz<br />
--- Physical volume ---<br />
PV Name /dev/sda8<br />
VG Name<br />
PV Size 93.13 GB / not usable 2.22 MB<br />
Allocatable yes (but full)<br />
PE Size (KByte) 4096<br />
Total PE 23842<br />
Free PE 0<br />
Allocated PE 23842<br />
PV UUID DGGrt0-Bxhn-JmYc-lq2O-acw8-DAt3-KaPC7P<br />
--- Physical volume ---<br />
PV Name /dev/sda9<br />
VG Name<br />
PV Size 149.10 GB / not usable 228.50 KB<br />
Allocatable yes (but full)<br />
PE Size (KByte) 4096<br />
Total PE 38170<br />
Free PE 0<br />
Allocated PE 38170<br />
PV UUID 6ushwj-9Rse-cGGu-RXDk-2vTe-uSbw-6N5R42<br />
</pre><br />
<br />
* Now we will create our volume group virtualization and add /dev/sda6 - /dev/sda7- /dev/sda8 /dev/sda9<br />
<br />
<pre><br />
dom0:~# vgcreate virtualization /dev/sda6 /dev/sda7 /dev/sda8 /dev/sda9<br />
Volume group "virtualization" successfully created<br />
dom0:~# vgscan<br />
Reading all physical volumes. This may take a while...<br />
Found volume group "virtualization" using metadata type lvm2<br />
</pre><br />
<br />
Follow the instructions for installing a Debian guest, [[http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer]]<br />
<br />
<br />
<br />
To use the newly created guest, execute<br />
<br />
xl create -c /etc/xen/debian.cfg<br />
<br />
To shut down the guest, execute <br />
xl shutdown debian<br />
<br />
in dom0.<br />
<br />
For more commands you can use xl help. For example, if you have four different DomU's installed, this will show:<br />
<br />
<pre><br />
dom0:~# xl list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 875 8 r----- 361.4<br />
domu1 7 3072 4 -b---- 32.9<br />
domu2 9 1024 4 -b---- 32.0<br />
domu3 8 1024 4 -b---- 34.0<br />
domu4 6 2048 4 -b---- 32.2<br />
</pre><br />
<br />
If you want domu1 to start automatically at the next boot of the system, then do this: ln -s /etc/xen/domu1.cfg /etc/xen/auto<br />
<br />
==== Configuration files ====<br />
A sample configuration file for domU looks like this<br />
<br />
<pre><br />
kernel = '/boot/vmlinuz-3.5.0'<br />
ramdisk = '/boot/initrd.img-3.5.0'<br />
memory = '2048'<br />
<br />
#<br />
# Disk device(s).<br />
#<br />
disk = [<br />
'phy:/dev/virtualization/domu1-swap,xvda1,w',<br />
'phy:/dev/virtualization/domu1-disk,xvda2,w',<br />
]<br />
#<br />
# Hostname<br />
#<br />
name = 'domu1'<br />
#<br />
# Networking<br />
#<br />
vif = [ 'ip=192.168.0.11,mac=00:16:3E:66:03:E1' ]<br />
#<br />
# Behaviour<br />
#<br />
on_poweroff = 'destroy'<br />
on_reboot = 'restart'<br />
on_crash = 'restart'<br />
vcpus = '4'<br />
</pre><br />
<br />
<br />
===Setting up Networking ===<br />
We are now going to set up each of our guests with networking. Each will have its own IP address. The result of this setup will look like:<br />
<br />
<pre><br />
IP of Domu1:192.168.0.11 Lets call it as a<br />
IP of Domu2:192.168.0.12 Lets call it as b<br />
IP of Domu3:192.168.0.13 Lets Call it as c<br />
IP of Domu4:192.168.0.14 Lets Call it as d<br />
Ip of Dom0 :192.168.0.100 (Will behave as Gateway for DomU's)<br />
Lets call Dom0 as A<br />
Gateway for the network is 192.168.0.1<br />
We will call it as G.<br />
</pre><br />
<br />
We have to enable IP forwarding for the hosts to appear on network:<br />
<br />
dom0:~# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
<br />
In /etc/sysctl.conf uncomment net.ipv4.ip_forward=1<br />
<br />
Now your hosts should appear on network. Inspite of the fact that that a,b,c,d are DomU's they are available on network as actual machines.<br />
<br />
DNS should point to actual DNS of your network since with IP Forwarding enabled the DomU's will be able to access the proxy and rest of the network.<br />
<br />
Now since you have enabled IP Forwarding so you should be able to ping from any other machine to you DomU's to make sure the things are working as expected you ping from C to a you should get a reply.<br />
<br />
<pre><br />
ping 192.168.0.11 <br />
PING 192.168.0.11 (192.168.0.11) 56(84) bytes of data.<br />
64 bytes from 192.168.0.11: icmp_seq=1 ttl=64 time=3.32 ms<br />
64 bytes from 192.168.0.11: icmp_seq=2 ttl=64 time=0.045 ms<br />
^C<br />
--- 192.168.0.11 ping statistics ---<br />
2 packets transmitted, 2 received, 0% packet loss, time 1008ms<br />
rtt min/avg/max/mdev = 0.045/1.685/3.326/1.641 ms<br />
</pre><br />
<br />
So DomU1 is accessible from C and in turn from the rest of the network. If you experience problems, ensure you have enabled ip forwarding in Dom0.<br />
<br />
Xen has a default network managment which will create a bridge whose name will be same as your interface name. Follow instructions at [[Network_Configuration_Examples_(Xen_4.1%2B)]].<br />
<br />
== Install applications ===<br />
Now follow instructions to install and configure your desired applications.<br />
<br />
==== Check points and possible errors ====<br />
* Before you choose to install separate OS as DomU's calculte the amount of RAM they consume and swap space that to allocate them. When Dom's run they require a certain amount of memory to be allocated to them. Suppose you have 8 GB RAM and you decide to give 2GB Ram to each of the virtual hosts, you create then you won't be left with memory for Dom0. We planned to give 875 Mb memory to the Dom0 so we were left with 8192-875=7317Mb of Ram which we planned to give to the DomU's. The memory assigned to each domain is shown by the command xl list.<br />
<br />
<pre><br />
dom0:~# xl list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 875 8 r----- 361.4<br />
domu1 7 3072 4 -b---- 32.9<br />
domu2 9 1024 4 -b---- 32.0<br />
domu3 8 1024 4 -b---- 34.0<br />
domu4 6 2048 4 -b---- 32.2<br />
</pre><br />
<br />
* Where domu1,domu2,domu3,domu4 are different dom's running.<br />
<br />
If you encounter any problem doing above or want to give some suggestion that can be added in this page<br />
<br />
* drop me a mail Tapas: mightydreams@gmail.com<br />
<br />
[[Category:Xen]]<br />
[[Category:Tutorial]]<br />
[[Category:Example]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_FAQ_Booting&diff=5097Xen FAQ Booting2012-09-24T13:46:05Z<p>OliverChick: Page totally out of date. Removed</p>
<hr />
<div></div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_FAQ_Booting&diff=5096Xen FAQ Booting2012-09-24T13:45:30Z<p>OliverChick: /* I get an error from Xen... (console output starting "(XEN)") */ Removed - Xen 2.0 is no longer relevant</p>
<hr />
<div><!-- MoinMoin name: XenFaq --><br />
<!-- Comment: Added link to XenFAQ2 --><br />
<!-- WikiMedia name: XenFaq --><br />
<!-- Page revision: 00000096 --><br />
<!-- Original date: Wed Sep 14 11:36:18 2011 (1316000178000000) --><br />
<br />
<!-- #pragma section-numbers on --><br />
<!-- ! TOC here --><br />
<br />
= Booting Xen =<br />
== How do I hide a pci device from dom0? ==<br />
In Xen 2.x, you can add the <code><nowiki>physdev_dom0_hide</nowiki></code> parameter (see [[Xen Hypervisor Boot Options]] for more parameters) to hide one or more pci devices to Dom0, so you can affect them to domU.<br />
<br />
Pci slots MUST be formatted like this:<br />
<br />
* '''(nn:nn.n)'''<br />
so<br />
<br />
* <code><nowiki>(03:06.1)</nowiki></code> is correct<br />
* <code><nowiki>(03:6.1)</nowiki></code> is NOT correct<br />
You can get the pci bus address on a Linux system by using the lspci command (only the last bits are relevant):<br />
<br />
<br />
<pre><nowiki><br />
lspci | grep Ethernet<br />
0000:02:03.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01)<br />
0000:02:03.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 01)<br />
</nowiki></pre><br />
<br />
Then:<br />
<br />
* to hide the second network interface from dom0, you can then append <code><nowiki>physdev_dom0_hide=(02:03.1)</nowiki></code> to your <code><nowiki>kernel /boot/xen-2.0.gz</nowiki></code>.<br />
* to hide multiple pci devices, simply concatenate all the pci slots address like this: <code><nowiki>physdev_dom0_hide=(02:03.0)(02:03.1)</nowiki></code><br />
If everything went ok, you should see the following lines after a reboot:<br />
<br />
<br />
<pre><nowiki><br />
(XEN) Hiding PCI device 02:03.0 from DOM0<br />
(XEN) Hiding PCI device 02:03.1 from DOM0<br />
</nowiki></pre><br />
<br />
== Error about root device still mounted when it's not mounted, zombie domU that can't be killed, domU hangs under heavy I/O (e.g disk) access ==<br />
This is an unresolved problem with Xen 3.0.<br />
<br />
You may try to [http://lists.xensource.com/archives/html/xen-users/2006-03/msg00651.html pass nousb to dom0 kernel command line], or [http://lists.xensource.com/archives/html/xen-devel/2005-07/msg00436.html pass ignorebiostables], or try to [http://lists.xensource.com/archives/html/xen-devel/2005-07/msg00468.html disable software IRQ affinity for 1850/2850 systems].<br />
<br />
* [http://lists.xensource.com/archives/html/xen-users/2006-02/msg00851.html Discussion in xen-users mailing list]<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_Project_Beginners_Guide&diff=5094Xen Project Beginners Guide2012-09-24T13:43:26Z<p>OliverChick: /* Creating a Windows HVM (Hardware Virtualized) Guest */ xm => xl</p>
<hr />
<div>Welcome!<br />
<br />
This guide was written to introduce beginners to basic Xen concepts and allow you to get started with Xen with no prior knowledge. Some prior Linux experience is required however, knowledge of networking, lvm and grub will go a long way!<br />
<br />
By completing this guide you will have installed a fully functional Xen hypervisor and started your first guest operating systems, connected them to your network and have been introduced to fundamental concepts such as virtual machine storage and virtual networking.<br />
To make this process easy we will be using a Linux distribution called Debian. Debian’s current stable release “Squeeze” ships with support for Xen 4 and everything you need to get started!<br />
<br />
Though this guide looks long at first don’t be daunted, it is very indepth and comprehensive but doesn’t expect you to know all that much beforehand. The goal instead is to teach you all the things you need to know to build a functioning Xen hypervisor. :)<br />
<br />
=What is Xen all about?=<br />
<br />
Xen is a Virtual Machine Monitor (VMM) also known as a hypervisor, this is a software system that allows the execution of multiple virtual guest operating systems simultaneously on a single physical machine. Xen is known as a Type 1 or “bare-metal” hypervisor, meaning that it runs directly ontop of the physical machine as opposed to within an operating system.<br />
<br />
Guest virtual machines running on Xen are known as “domains” and a special domain known as dom0 is responsible for controlling the hypervisor and starting other guest operating systems. These other guest operating systems are called domUs, this is because these domains are “unprivileged” in the sense they cannot control Xen or start/stop other domains.<br />
<br />
Xen supports 2 primary types of virtualization, para-virtualization and hardware virtual machine (HVM) also known as “full virtualization”. Para-virtualization uses modified guest operating systems that we refer to as enlightened guests. These operating systems are aware that they are being virtualized and as such don’t require virtual “hardware” devices, instead they make special calls to Xen that allow them to access CPUs, storage and network resources.<br />
<br />
In contrast HVM guests need not be modified as Xen will create a fully virtual set of hardware devices for this machine that resemble a physical x86 computer. This emulation requires much more overhead than the paravirtualisation approach but allows unmodified guest operating systems like Microsoft Windows to run ontop of Xen. HVM support requires special CPU extensions - VT-x for Intel processors and AMD-V for AMD based machines. This technology is now prevalent and all recent servers and desktop systems should be equipped with them.<br />
<br />
A third type of virtualization though not discussed in this guide is called PVHVM or “Para-virtualisation on HVM” which is a HVM domain with paravirtualized storage, network and other devices. This provides the best of both worlds by reducing expensive emulation but providing hardware accelerated CPU and memory access.<br />
A brief look at Xen architecture<br />
To understand how storage, networking and other resources are delivered to guest systems we need to quickly delve into how the different bits of Xen interact.<br />
<br />
'''<todo diagram>'''<br />
<br />
'''<todo explain dom0 role and datapath for guest IO/network>'''<br />
<br />
The dom0 forms the interface to the hypervisor, through special instructions the dom0 communicates to Xen and changes the configuration of the hypervisor. This includes instantiating new domains and related tasks.<br />
<br />
Another crucial part of the dom0’s role is that it is the primary interface to the hardware. Xen doesn’t contain device drivers, instead the devices are attached to dom0 and you can use standard Linux drivers. Dom0 then shares these resources with guest operating systems through a number of “backend” deamons.<br />
<br />
For each para-virtualized subsystem in Xen consists of 2 parts, the aforementioned “backend” that lives in dom0 and the “frontend” driver within the guest domain. The backend is effectively a deamon which uses special ring buffer based interfaces to transfer data to guests, be it to provide a virtual hard-disk, Ethernet adapter of even a generic SCSI device.<br />
The frontend driver then takes this stream of data and converts it back into a device within the guest operating system.<br />
<br />
The 2 important paravirtualisation systems are known as net-back/net-front and blk-back/blk-front which are the paravirtualized networking and storage systems respectively.<br />
<br />
You can read more about how Xen is architected, paravirtualization and the benefits of such here:<br />
<br />
'''<todo find xen article on wiki with deep explaination of PV>'''<br />
<br />
=Preparation=<br />
<br />
This guide requires a number of items, this checklist is what you will need:<br />
<br />
* 64bit x86 computer with atleast 1GB of RAM (this can be a server,desktop or laptop!)<br />
* (Optional) VT-d or AMD-V support<br />
* Sufficient storage space for your dom0 and whatever guests you want to install<br />
* A CD burner + blank CD (you can use a USB but this is not covered here)<br />
* Internet access for downloading and installing Debian<br />
* (Optional) Windows Server 2008R2 installation ISO, a trial copy is sufficient<br />
* (Optional) VNC client for installing HVM domain<br />
<br />
==Enable virtualization support in BIOS==<br />
<br />
''NOTE: This is optional and not required for PV guests''<br />
<br />
In order to support HVM guests we need to ensure that virtualization extensions are enabled in the BIOS. If you don’t wish to start a HVM guest you can skip this step but it is still highly recommended. If your system doesn’t support these extensions you cannot use Xen to virtualize unmodified operating systems, however para-virtualization will work fine.<br />
<br />
The virtualization option appears differently in different BIOS builds but generally it is refered to as “Enable Virtualisation Technology” or “Enable Intel VT” for Intel chipsets, however in some cases it can be listed as “Vanderpool Technology”. Oftentimes this option can be found under the “Advanced Chipset Features” menu in the BIOS. Similar also for AMD.<br />
<br />
Consult your motherboard documentation for more assistance in enabling virtualization extensions on your system.<br />
<br />
==Download and burn Debian Squeeze Installer CD==<br />
<br />
Download the ISO image from this URL:<br />
<br />
http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/<br />
<br />
The netinst image is sufficient for our purposes.<br />
<br />
Burn the ISO to disk using your computers standard utilities. I recommend wodim on Linux or the built in ISO burning feature in Windows.<br />
<br />
==Quick intro to Debian==<br />
<br />
Debian is a simple, stable and well supported Linux distribution. It has included Xen support since Debian 3.1 “Sarge” released in 2005. The current stable release Debian 6.0 “Squeeze” ships with Xen 4.0.1 and a Xen enabled Linux 2.6.32 kernel.<br />
<br />
Debian uses the simple Apt package management system which is both powerful and simple to use.<br />
Installing a package is as simple as the following example:<br />
<br />
aptitude install htop<br />
<br />
Where htop was the application desired to install.<br />
<br />
Simple tasks such as configuring startup scripts, setting up the network etc are covered by this tutorial so don’t worry if you haven’t used Debian before!<br />
<br />
Many popular distributions are based off of Debian and also use the Apt package manager, if you have used Ubuntu, Linux Mint or Damn Small Linux you will feel right at home.<br />
<br />
=Installing Debian Squeeze=<br />
<br />
Boot the Debian Squeeze Installer CD<br />
Insert the Debian CD and configure the CDROM drive as your default boot device in the BIOS or use the system bootmenu if your BIOS supports it (usually F12).<br />
<br />
You should see a menu, choose the default “Install” option to begin the installation process.<br />
Install the system<br />
The Debian installer is very straight forward. Follow the prompts until you reach the disk partitioning section.<br />
<br />
Choose advanced/custom, we are going to configure a few partitions here, one for /boot another for /, one more for swap and a final partition to setup as an LVM volume group for our guest machines.<br />
<br />
First create the /boot partition by choosing the disk and hitting enter, make the partition 300MB and format it as ext2, choose /boot as the mountpoint.<br />
<br />
Repeat the process for / but of course changing the mountpoint to / and making it 15GB or so large. Format it as ext3.<br />
<br />
Create another partition approximately 1.5x the amount of RAM you have in size and elect to have it used as a swap volume.<br />
<br />
Finally create a partition that consumes the rest of the diskspace but don’t format it or assign a mount point.<br />
<br />
We should now have a layout that looks like this assuming your disk device is /dev/sda :<br />
<br />
sda1 - /boot 200MB<br />
sda2 - / 15GB<br />
sda3 - swap<br />
sda4 - reserved for LVM<br />
<br />
When you reach the package selection stage only install the base system, we won’t require any GUI or other packages for this guide.<br />
<br />
'''<todo: extend to cover the rest of the installation process>'''<br />
<br />
Continue through the installer then reboot and login at the prompt as root.<br />
<br />
=Setup LVM storage for guests=<br />
<br />
LVM is the Linux Logical Volume manager. It is a technology that allows Linux to manage block devices in a more abstract manner.<br />
<br />
LVM introduces the concept of a “logical volume”, effectively a virtualized block device composed of blocks written to 1 or more physical devices. These blocks don’t need to be contiguous unlike proper disk partitions.<br />
<br />
Because of this abstraction logical volumes can be created, deleted, resized and even snapshotted without affecting other logical volumes.<br />
<br />
LVM creates logical volumes within what is called a volume group, which is simply a set of logical volumes that share the same physical storage, known as physical volumes.<br />
<br />
The process of setting up LVM can be sumarized as allocating a physical volume, creating a volume group ontop of this then creating logical volumes to store data.<br />
<br />
Because of these features and superior performance over file backed virtual machines I recommend the use of LVM if you are going to store VM data locally.<br />
<br />
Now lets install LVM and get started!<br />
<br />
Install LVM with aptitude by running this command:<br />
<br />
aptitude install lvm2<br />
<br />
Now that we have LVM installed lets configure it to use /dev/sda4 as it’s physical volume<br />
<br />
pvcreate /dev/sda4<br />
<br />
Ok, now LVM has somewhere to store it’s blocks (known as extents for future reference).<br />
Lets create a volume group called ‘vg0’ using this physical volume:<br />
<br />
vgcreate vg0 /dev/sda4<br />
<br />
Now LVM is setup and initialized so that we can later create logical volumes for our virtual machines.<br />
<br />
For the interested below is a number of useful commands and tricks when using LVM.<br />
<br />
Create a new logical volume:<br />
<br />
lvcreate -n<name of the volume> -L<size, you can use G and M here> <volume group><br />
<br />
For example, creating a 100 gigabyte volume called database-data on a volume group called vg0.<br />
<br />
lvcreate -ndatabase-data -L100G vg0<br />
<br />
You can then remove this volume with the following:<br />
<br />
lvremove /dev/vg0/database-data<br />
<br />
Note that you have to provide the path to the volume here.<br />
<br />
If you already have a volume setup that you would like to copy, LVM has a cool feature that allows you to create a CoW (copy on write) clone called a snapshot.<br />
This means that you can make an "instant" copy that will only store the changes compared to the original. There are a number of caveats to this that will be discussed in a yet unwritten article.<br />
The most important thing to note is that the "size" of the snapshot is only the ammount of space allocated to store changes. So you can make the snapshot "size" alot smaller than the source volume.<br />
<br />
To create a snapshot use the following command:<br />
<br />
lvcreate -s /dev/vg0/database-data -ndatabase-backup -L5G<br />
<br />
Once again note the use of the full path.<br />
<br />
=Setup Linux Bridge for guest networking=<br />
<br />
Next we need to setup our system so that we can attach virtual machines to the external network. This is done by creating a virtual switch within dom0 that takes packets from the virtual machines and forwards them onto the physical network so they can see the internet and other machines on your network.<br />
<br />
The piece of software we use to do this is called the Linux bridge and it’s core components reside inside the Linux kernel. In this case the “bridge” is effectively our virtual switch. Our Debian kernels are compiled with the Linux bridging module so all we need to do is install the control utilities.<br />
<br />
aptitude install bridge-utils<br />
<br />
With bridge-utils installed we now have a utility called “brctl” this utility talks to the Linux bridging module to setup new bridges and attach physical or virtual interfaces to these bridges.<br />
<br />
brctl can be used to create a bridge as such, where <bridgename> is the name of the bridge:<br />
<br />
brctl addbr <bridgename><br />
<br />
And interfaces can be added to that bridge by running the following:<br />
<br />
brctl addif <bridgename> <interface><br />
<br />
Instead of calling brctl directly we are instead going to configure our bridge through Debian’s networking infrastructure which can be configured through <br />
<br />
/etc/network/interfaces<br />
<br />
Open this file with the editor of your choice (more editors can be installed with aptitude)<br />
Nano is installed by default if you selected the minimal install<br />
<br />
nano /etc/network/interfaces<br />
<br />
Depending on your hardware you probably see a file pretty similar to this:<br />
<br />
<pre><br />
auto lo<br />
iface lo inet loopback<br />
<br />
auto eth0<br />
iface eth0 inet dhcp<br />
</pre><br />
<br />
This file is very simple. Each stanza represents a single interface.<br />
Breaking it down “auto eth0” means that eth0 will be configured when ifup -a is run (which is run a boot time) what this means is that the interface with automatically be started/stopped for you.<br />
“iface eth0” then describes the interface itself, in this case it merely specifies that it should be configured by DHCP - we are going to assume that you have DHCP running on your network for this guide. If you are using static addressing you probably know how to set that up.<br />
We are going to edit this file so it resembles such:<br />
<br />
<pre><br />
auto lo<br />
iface lo inet loopback<br />
<br />
iface eth0 inet manual<br />
auto xenbr0<br />
<br />
iface xenbr0 inet dhcp<br />
bridge_ports eth0<br />
</pre><br />
<br />
This will setup the bridge xenbr0 and add eth0 to the bridge for us.<br />
The equivalent commands would be:<br />
<br />
brctl addbr xenbr0<br />
brctl addif xenbr0 eth0<br />
dhclient xenbr0<br />
<br />
Except this will now be done automatically on boot and completely managed by Debian.<br />
<br />
This method of network configuration is best practice and the automated scripts called by xend are now deprecated, we will discuss this later once we have Xen installed.<br />
<br />
=Installing Xen=<br />
<br />
The Debian Xen packages consists primarily of a Xen enabled Linux kernel, the Xen hypervisor itself, a modified version of QEMU that support Xen’s HVM mode and a set of userland tools.<br />
<br />
All of this except QEMU can be installed via an Apt meta-package callled xen-linux-system. A meta-package is basically a way of installing a group of packages automatically. Apt will ofcourse resolve all dependencies and bring in all the extra libraries we need.<br />
<br />
Lets install the xen-linux-system metapackage:<br />
<br />
aptitude -P install xen-linux-system<br />
<br />
Next we will install the Xen QEMU package so that we can boot HVM guests later (this is optional but highly recommended)<br />
<br />
aptitude install xen-qemu-dm<br />
<br />
Now have Xen, a Xen kernel and the userland tools installed, almost ready to go.<br />
<br />
=Configure GRUB to start Xen=<br />
<br />
Because Xen starts before your operating system we need to change how your systems boot process is setup. The bootloader installed during installation called GRUB is what tells your computer which operating system to start and how.<br />
<br />
GRUB2 configuration is stored in the file /boot/grub/grub.cfg<br />
However we aren’t going to edit this file directly, as it changes every time we update our kernel.<br />
Debian configures GRUB for us using a number of automated scripts that handle upgrades etc, these scripts are stored in /etc/grub.d/* and are configured via<br />
<br />
/etc/default/grub<br />
<br />
We are going to change the order of the operating systems so that our Xen system is the default option. By executing the below command we are moving Xen to a higher priority than default Linux so that it gets the first position in the boot menu.<br />
<br />
mv -i /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen<br />
<br />
We then generate the /boot/grub/grub.cfg file by running the command below:<br />
<br />
update-grub<br />
<br />
We can now reboot and the default boot option will be our Xen dom0 running ontop of Xen!<br />
<br />
'''See also'''<br />
* [[Xen Hypervisor Boot Options|Xen GRUB Boot Options]]<br />
<br />
=Basic Xen commands=<br />
<br />
Before we dive into creating some guest domains we will quickly cover some basic Xen commands using the “xm” utiltiy. Going forward it is likely that xm will be deprecated as previously mentioned but once xl is stable and part of a supported release this guide will be rewritten to reflect that.<br />
<br />
So lets start with simple stuff!<br />
<br />
xl info<br />
<br />
This returns the information about the Xen hypervisor and dom0 including version, free memory etc.<br />
<br />
xl list<br />
<br />
Lists running domains, their IDs. memory, state and CPU time consumed<br />
<br />
xl top<br />
<br />
Shows running domains in real time and is similar to the “top” command under Linux. This can be used to visualize CPU, memory usage and block device access.<br />
<br />
We will cover some more commands during the creation of our guest domains.<br />
<br />
'''See also'''<br />
* [[Xen Man Pages]]<br />
<br />
=Creating a Debian PV (Paravirtualized) Guest=<br />
<br />
PV guests are notoriously “different” to install. Due to the nature of enlightened systems they don’t have the usual concepts of a CD-ROM drive installer analagous to their physical counterparts. However, luckly enough there does exist some tools that help us prepare “images” or effectively snapshots of the operating systems that are able to run inside of Xen domains.<br />
<br />
Debian contains a number of tools for creating Xen guests. The easiest of which is known as xen-tools. This software suite manages the downloading and installing of guest operating systems including both Debian and RHEL based DomUs. In this guide we are going to use xen-tools to prepare a Debian Squeeze paravirtualized domU.<br />
<br />
Xen-tools can use LVM storage for storing the guest operating systems, in this guide we created the volume group “vg0” in the Setting up LVM Storage section.<br />
<br />
When guests are paravirtualized there is no “BIOS” or bootloader resident within the guest filesystem and for a long time guests were provided with kernels external to the guest image. This however is bad for maintainability (guests cannot upgrade their kernels without access to the dom0) and is not as flexible in terms of boot options as they must be passed via the config file.<br />
<br />
The Xen community wrote a utility known as pygrub which is a python application for PV guests that enables the dom0 to parse the GRUB configuration of the domU and extract it’s kernel, initrd and boot parameters. This allows for kernel upgrades etc inside of our guest machines along with a GRUB menu. Using pygrub or the stub-dom implementation known as pv-grub is best practice for starting PV guests. In some cases pv-grub is arguably more secure but as it is not included with Debian we won’t use it here though it is recommended in production environments where guests cannot be trusted.<br />
<br />
Apart from this PV guests are very similar to their HVM and physical OS counterparts.<br />
Configuring xen-tools and building our guest<br />
First lets install the xen-tools package:<br />
<br />
aptitude install xen-tools<br />
<br />
We can now create a guest operating system with this tool. It effectly automates the process of setting up a PV guest from scratch right to the point of creating config files and starting the guest. The process can be summarized as follows:<br />
<br />
* Create logical volume for rootfs<br />
* Create logical volume for swap<br />
* Create filesystem for rootfs<br />
* Mount rootfs<br />
* Install operating system using debootstrap (or rinse etc, only debootstrap covered here)<br />
* Run a series of scripts to generate guest config files like fstab/inittab/menu.lst<br />
* Create a Xen config file for the guest<br />
* Generate a root password for the guest system<br />
* Unmount the guest filesystem<br />
<br />
These 9 steps can be carried out manually but the manual process is outside the scope of this guide. We instead will execute the below command:<br />
<br />
xen-create-image --hostname=tutorial-pv-guest \<br />
--memory=512mb \<br />
--vcpus=2 \<br />
--lvm=vg0 \<br />
--dhcp \<br />
--pygrub \<br />
--dist=squeeze<br />
<br />
This command instructs xen-create-image (the primary binary of the xen-tools toolkit) to create a guest domain with 512MB of memory, 2 vcpus, using storage from the vg0 volume group we created, use DHCP for networking, pygrub to extract the kernel from the image when booted and lastly we specify that we want to deploy a Debian Squeeze operating system.<br />
<br />
This process will take a few minutes after which you can start the guest with:<br />
<br />
xl create -c /etc/xen/tutorial-pv-guest.cfg<br />
<br />
The -c in this command tells xm that we wish to connect to the guest virtual console. Which is a paravirtualised serial port within the domain that xen-create-image configured to listen with a getty. This is analgous to running:<br />
<br />
xl create /etc/xen/tutorial-pv-guest.cfg && xm console tutorial-pv-guest<br />
<br />
You can leave the guest virtual console by pressing ctrl+] and re-enter it by running the “xl console <domain>” command.<br />
<br />
You can later shutdown this guest either from within the domain or from dom0 with the following:<br />
<br />
xl shutdown tutorial-pv-guest<br />
<br />
That completes our section on setting up your first paravirtualized domain! If you don’t have any interest in setting up a HVM domain then no need to read any further but it is highly recommended!<br />
<br />
=Creating a Windows HVM (Hardware Virtualized) Guest=<br />
<br />
HVM guests are quite a bit different to their PV counterparts. Because they require the emulation of hardware there is more moving pieces that need to be configured etc.<br />
<br />
The main point worth mentioning here is that HVM requires the emulation of ATA, Ethernet and other devices, while virtualized CPU and Memory access is performed in hardware to achieve good performance. Because of this the default emulated devices are very slow and we generally try to use PV drivers within HVM domains. We will be installing a set of Windows PV drivers that greatly increase performance once we have our Windows guest running.<br />
<br />
This extra emulation is provided by a Xen modified version of QEMU we should have installed this earlier but in case you skipped that step install the Xen QEMU package now:<br />
<br />
aptitude install xen-qemu-dm<br />
<br />
Once the necessary packages are installed we need to create a logical volume to store our Windows VM hard disk, create a config file that tells Xen to start the domain in HVM mode and boot from the DVD in order to install Windows.<br />
<br />
First, create the new logical volume - name the volume "windows", set the size to 20GB and use the volume group vg0 we created earlier.<br />
<br />
lvcreate -nwindows -L20G vg0<br />
<br />
Next open a new file with your text editor of choice:<br />
<br />
nano windows.cfg<br />
<br />
Paste the config below into the file and save it, NOTE this assumes your Windows iso is located in /root/ with the filename windows.iso.<br />
<br />
kernel = "/usr/lib/xen-4.0/boot/hvmloader"<br />
builder='hvm'<br />
memory = 4096<br />
vcpus=4<br />
name = "ovm-1734"<br />
vif = ['bridge=xenbr0']<br />
disk = ['phy:/dev/vg0/windows,hda,w','file:/root/windows.iso,hdc:cdrom,r']<br />
acpi = 1<br />
device_model = 'qemu-dm'<br />
boot="d"<br />
sdl=0<br />
serial='pty'<br />
vnc=1<br />
vnclisten=""<br />
vncpasswd=""<br />
<br />
You can then start the domain and connect to it via VNC from your graphical machine.<br />
<br />
xl create windows.cfg<br />
<br />
The VNC display should be available on port 5900 of your dom0 IP, for instance using gvncviewer:<br />
<br />
gvncviewer <dom0 ip>:5900<br />
<br />
Once you have installed Windows by formatting the disk and by following the prompts the domain will restart - however this time we want to prevent it booting from DVD so destroy the domain with<br />
<br />
xl destroy windows<br />
<br />
Then change the boot line in the config file to read boot="c"' restart the domain with<br />
<br />
xl create windows.cfg<br />
<br />
Reconnect with VNC and finish the installatation.<br />
When this process is complete you should then procede to download the GPLPV drivers for Windows by James Harper.<br />
<br />
Signed drivers can be obtained from here:<br />
<br />
http://wiki.univention.de/index.php?title=Installing-signed-GPLPV-drivers<br />
<br />
Many thanks for Univention for making signed drivers available to the Xen community and ofcourse a massive thanks to James for all his work on making Windows on Xen such a smooth experience.<br />
On finalizing the installation and rebooting you should notice much improved disk and network performance and Xen will now be able to gracefully shutdown your Windows domains.<br />
<br />
= Conclusion =<br />
<br />
That concludes our introduction to Xen, by now you can setup both PV and HVM domains on a bare dom0 hypervisor!<br />
<br />
You can now move onto building your own guest images or try out some prebuilt [[Guest VM Images]].<br />
<br />
<br />
[[Category:Xen]]<br />
[[Category:Beginners]]<br />
[[Category:Tutorial]]<br />
[[Category:Debian]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_Project_Beginners_Guide&diff=5092Xen Project Beginners Guide2012-09-24T13:42:38Z<p>OliverChick: /* Creating a Debian PV (Paravirtualized) Guest */ xm => xl</p>
<hr />
<div>Welcome!<br />
<br />
This guide was written to introduce beginners to basic Xen concepts and allow you to get started with Xen with no prior knowledge. Some prior Linux experience is required however, knowledge of networking, lvm and grub will go a long way!<br />
<br />
By completing this guide you will have installed a fully functional Xen hypervisor and started your first guest operating systems, connected them to your network and have been introduced to fundamental concepts such as virtual machine storage and virtual networking.<br />
To make this process easy we will be using a Linux distribution called Debian. Debian’s current stable release “Squeeze” ships with support for Xen 4 and everything you need to get started!<br />
<br />
Though this guide looks long at first don’t be daunted, it is very indepth and comprehensive but doesn’t expect you to know all that much beforehand. The goal instead is to teach you all the things you need to know to build a functioning Xen hypervisor. :)<br />
<br />
=What is Xen all about?=<br />
<br />
Xen is a Virtual Machine Monitor (VMM) also known as a hypervisor, this is a software system that allows the execution of multiple virtual guest operating systems simultaneously on a single physical machine. Xen is known as a Type 1 or “bare-metal” hypervisor, meaning that it runs directly ontop of the physical machine as opposed to within an operating system.<br />
<br />
Guest virtual machines running on Xen are known as “domains” and a special domain known as dom0 is responsible for controlling the hypervisor and starting other guest operating systems. These other guest operating systems are called domUs, this is because these domains are “unprivileged” in the sense they cannot control Xen or start/stop other domains.<br />
<br />
Xen supports 2 primary types of virtualization, para-virtualization and hardware virtual machine (HVM) also known as “full virtualization”. Para-virtualization uses modified guest operating systems that we refer to as enlightened guests. These operating systems are aware that they are being virtualized and as such don’t require virtual “hardware” devices, instead they make special calls to Xen that allow them to access CPUs, storage and network resources.<br />
<br />
In contrast HVM guests need not be modified as Xen will create a fully virtual set of hardware devices for this machine that resemble a physical x86 computer. This emulation requires much more overhead than the paravirtualisation approach but allows unmodified guest operating systems like Microsoft Windows to run ontop of Xen. HVM support requires special CPU extensions - VT-x for Intel processors and AMD-V for AMD based machines. This technology is now prevalent and all recent servers and desktop systems should be equipped with them.<br />
<br />
A third type of virtualization though not discussed in this guide is called PVHVM or “Para-virtualisation on HVM” which is a HVM domain with paravirtualized storage, network and other devices. This provides the best of both worlds by reducing expensive emulation but providing hardware accelerated CPU and memory access.<br />
A brief look at Xen architecture<br />
To understand how storage, networking and other resources are delivered to guest systems we need to quickly delve into how the different bits of Xen interact.<br />
<br />
'''<todo diagram>'''<br />
<br />
'''<todo explain dom0 role and datapath for guest IO/network>'''<br />
<br />
The dom0 forms the interface to the hypervisor, through special instructions the dom0 communicates to Xen and changes the configuration of the hypervisor. This includes instantiating new domains and related tasks.<br />
<br />
Another crucial part of the dom0’s role is that it is the primary interface to the hardware. Xen doesn’t contain device drivers, instead the devices are attached to dom0 and you can use standard Linux drivers. Dom0 then shares these resources with guest operating systems through a number of “backend” deamons.<br />
<br />
For each para-virtualized subsystem in Xen consists of 2 parts, the aforementioned “backend” that lives in dom0 and the “frontend” driver within the guest domain. The backend is effectively a deamon which uses special ring buffer based interfaces to transfer data to guests, be it to provide a virtual hard-disk, Ethernet adapter of even a generic SCSI device.<br />
The frontend driver then takes this stream of data and converts it back into a device within the guest operating system.<br />
<br />
The 2 important paravirtualisation systems are known as net-back/net-front and blk-back/blk-front which are the paravirtualized networking and storage systems respectively.<br />
<br />
You can read more about how Xen is architected, paravirtualization and the benefits of such here:<br />
<br />
'''<todo find xen article on wiki with deep explaination of PV>'''<br />
<br />
=Preparation=<br />
<br />
This guide requires a number of items, this checklist is what you will need:<br />
<br />
* 64bit x86 computer with atleast 1GB of RAM (this can be a server,desktop or laptop!)<br />
* (Optional) VT-d or AMD-V support<br />
* Sufficient storage space for your dom0 and whatever guests you want to install<br />
* A CD burner + blank CD (you can use a USB but this is not covered here)<br />
* Internet access for downloading and installing Debian<br />
* (Optional) Windows Server 2008R2 installation ISO, a trial copy is sufficient<br />
* (Optional) VNC client for installing HVM domain<br />
<br />
==Enable virtualization support in BIOS==<br />
<br />
''NOTE: This is optional and not required for PV guests''<br />
<br />
In order to support HVM guests we need to ensure that virtualization extensions are enabled in the BIOS. If you don’t wish to start a HVM guest you can skip this step but it is still highly recommended. If your system doesn’t support these extensions you cannot use Xen to virtualize unmodified operating systems, however para-virtualization will work fine.<br />
<br />
The virtualization option appears differently in different BIOS builds but generally it is refered to as “Enable Virtualisation Technology” or “Enable Intel VT” for Intel chipsets, however in some cases it can be listed as “Vanderpool Technology”. Oftentimes this option can be found under the “Advanced Chipset Features” menu in the BIOS. Similar also for AMD.<br />
<br />
Consult your motherboard documentation for more assistance in enabling virtualization extensions on your system.<br />
<br />
==Download and burn Debian Squeeze Installer CD==<br />
<br />
Download the ISO image from this URL:<br />
<br />
http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/<br />
<br />
The netinst image is sufficient for our purposes.<br />
<br />
Burn the ISO to disk using your computers standard utilities. I recommend wodim on Linux or the built in ISO burning feature in Windows.<br />
<br />
==Quick intro to Debian==<br />
<br />
Debian is a simple, stable and well supported Linux distribution. It has included Xen support since Debian 3.1 “Sarge” released in 2005. The current stable release Debian 6.0 “Squeeze” ships with Xen 4.0.1 and a Xen enabled Linux 2.6.32 kernel.<br />
<br />
Debian uses the simple Apt package management system which is both powerful and simple to use.<br />
Installing a package is as simple as the following example:<br />
<br />
aptitude install htop<br />
<br />
Where htop was the application desired to install.<br />
<br />
Simple tasks such as configuring startup scripts, setting up the network etc are covered by this tutorial so don’t worry if you haven’t used Debian before!<br />
<br />
Many popular distributions are based off of Debian and also use the Apt package manager, if you have used Ubuntu, Linux Mint or Damn Small Linux you will feel right at home.<br />
<br />
=Installing Debian Squeeze=<br />
<br />
Boot the Debian Squeeze Installer CD<br />
Insert the Debian CD and configure the CDROM drive as your default boot device in the BIOS or use the system bootmenu if your BIOS supports it (usually F12).<br />
<br />
You should see a menu, choose the default “Install” option to begin the installation process.<br />
Install the system<br />
The Debian installer is very straight forward. Follow the prompts until you reach the disk partitioning section.<br />
<br />
Choose advanced/custom, we are going to configure a few partitions here, one for /boot another for /, one more for swap and a final partition to setup as an LVM volume group for our guest machines.<br />
<br />
First create the /boot partition by choosing the disk and hitting enter, make the partition 300MB and format it as ext2, choose /boot as the mountpoint.<br />
<br />
Repeat the process for / but of course changing the mountpoint to / and making it 15GB or so large. Format it as ext3.<br />
<br />
Create another partition approximately 1.5x the amount of RAM you have in size and elect to have it used as a swap volume.<br />
<br />
Finally create a partition that consumes the rest of the diskspace but don’t format it or assign a mount point.<br />
<br />
We should now have a layout that looks like this assuming your disk device is /dev/sda :<br />
<br />
sda1 - /boot 200MB<br />
sda2 - / 15GB<br />
sda3 - swap<br />
sda4 - reserved for LVM<br />
<br />
When you reach the package selection stage only install the base system, we won’t require any GUI or other packages for this guide.<br />
<br />
'''<todo: extend to cover the rest of the installation process>'''<br />
<br />
Continue through the installer then reboot and login at the prompt as root.<br />
<br />
=Setup LVM storage for guests=<br />
<br />
LVM is the Linux Logical Volume manager. It is a technology that allows Linux to manage block devices in a more abstract manner.<br />
<br />
LVM introduces the concept of a “logical volume”, effectively a virtualized block device composed of blocks written to 1 or more physical devices. These blocks don’t need to be contiguous unlike proper disk partitions.<br />
<br />
Because of this abstraction logical volumes can be created, deleted, resized and even snapshotted without affecting other logical volumes.<br />
<br />
LVM creates logical volumes within what is called a volume group, which is simply a set of logical volumes that share the same physical storage, known as physical volumes.<br />
<br />
The process of setting up LVM can be sumarized as allocating a physical volume, creating a volume group ontop of this then creating logical volumes to store data.<br />
<br />
Because of these features and superior performance over file backed virtual machines I recommend the use of LVM if you are going to store VM data locally.<br />
<br />
Now lets install LVM and get started!<br />
<br />
Install LVM with aptitude by running this command:<br />
<br />
aptitude install lvm2<br />
<br />
Now that we have LVM installed lets configure it to use /dev/sda4 as it’s physical volume<br />
<br />
pvcreate /dev/sda4<br />
<br />
Ok, now LVM has somewhere to store it’s blocks (known as extents for future reference).<br />
Lets create a volume group called ‘vg0’ using this physical volume:<br />
<br />
vgcreate vg0 /dev/sda4<br />
<br />
Now LVM is setup and initialized so that we can later create logical volumes for our virtual machines.<br />
<br />
For the interested below is a number of useful commands and tricks when using LVM.<br />
<br />
Create a new logical volume:<br />
<br />
lvcreate -n<name of the volume> -L<size, you can use G and M here> <volume group><br />
<br />
For example, creating a 100 gigabyte volume called database-data on a volume group called vg0.<br />
<br />
lvcreate -ndatabase-data -L100G vg0<br />
<br />
You can then remove this volume with the following:<br />
<br />
lvremove /dev/vg0/database-data<br />
<br />
Note that you have to provide the path to the volume here.<br />
<br />
If you already have a volume setup that you would like to copy, LVM has a cool feature that allows you to create a CoW (copy on write) clone called a snapshot.<br />
This means that you can make an "instant" copy that will only store the changes compared to the original. There are a number of caveats to this that will be discussed in a yet unwritten article.<br />
The most important thing to note is that the "size" of the snapshot is only the ammount of space allocated to store changes. So you can make the snapshot "size" alot smaller than the source volume.<br />
<br />
To create a snapshot use the following command:<br />
<br />
lvcreate -s /dev/vg0/database-data -ndatabase-backup -L5G<br />
<br />
Once again note the use of the full path.<br />
<br />
=Setup Linux Bridge for guest networking=<br />
<br />
Next we need to setup our system so that we can attach virtual machines to the external network. This is done by creating a virtual switch within dom0 that takes packets from the virtual machines and forwards them onto the physical network so they can see the internet and other machines on your network.<br />
<br />
The piece of software we use to do this is called the Linux bridge and it’s core components reside inside the Linux kernel. In this case the “bridge” is effectively our virtual switch. Our Debian kernels are compiled with the Linux bridging module so all we need to do is install the control utilities.<br />
<br />
aptitude install bridge-utils<br />
<br />
With bridge-utils installed we now have a utility called “brctl” this utility talks to the Linux bridging module to setup new bridges and attach physical or virtual interfaces to these bridges.<br />
<br />
brctl can be used to create a bridge as such, where <bridgename> is the name of the bridge:<br />
<br />
brctl addbr <bridgename><br />
<br />
And interfaces can be added to that bridge by running the following:<br />
<br />
brctl addif <bridgename> <interface><br />
<br />
Instead of calling brctl directly we are instead going to configure our bridge through Debian’s networking infrastructure which can be configured through <br />
<br />
/etc/network/interfaces<br />
<br />
Open this file with the editor of your choice (more editors can be installed with aptitude)<br />
Nano is installed by default if you selected the minimal install<br />
<br />
nano /etc/network/interfaces<br />
<br />
Depending on your hardware you probably see a file pretty similar to this:<br />
<br />
<pre><br />
auto lo<br />
iface lo inet loopback<br />
<br />
auto eth0<br />
iface eth0 inet dhcp<br />
</pre><br />
<br />
This file is very simple. Each stanza represents a single interface.<br />
Breaking it down “auto eth0” means that eth0 will be configured when ifup -a is run (which is run a boot time) what this means is that the interface with automatically be started/stopped for you.<br />
“iface eth0” then describes the interface itself, in this case it merely specifies that it should be configured by DHCP - we are going to assume that you have DHCP running on your network for this guide. If you are using static addressing you probably know how to set that up.<br />
We are going to edit this file so it resembles such:<br />
<br />
<pre><br />
auto lo<br />
iface lo inet loopback<br />
<br />
iface eth0 inet manual<br />
auto xenbr0<br />
<br />
iface xenbr0 inet dhcp<br />
bridge_ports eth0<br />
</pre><br />
<br />
This will setup the bridge xenbr0 and add eth0 to the bridge for us.<br />
The equivalent commands would be:<br />
<br />
brctl addbr xenbr0<br />
brctl addif xenbr0 eth0<br />
dhclient xenbr0<br />
<br />
Except this will now be done automatically on boot and completely managed by Debian.<br />
<br />
This method of network configuration is best practice and the automated scripts called by xend are now deprecated, we will discuss this later once we have Xen installed.<br />
<br />
=Installing Xen=<br />
<br />
The Debian Xen packages consists primarily of a Xen enabled Linux kernel, the Xen hypervisor itself, a modified version of QEMU that support Xen’s HVM mode and a set of userland tools.<br />
<br />
All of this except QEMU can be installed via an Apt meta-package callled xen-linux-system. A meta-package is basically a way of installing a group of packages automatically. Apt will ofcourse resolve all dependencies and bring in all the extra libraries we need.<br />
<br />
Lets install the xen-linux-system metapackage:<br />
<br />
aptitude -P install xen-linux-system<br />
<br />
Next we will install the Xen QEMU package so that we can boot HVM guests later (this is optional but highly recommended)<br />
<br />
aptitude install xen-qemu-dm<br />
<br />
Now have Xen, a Xen kernel and the userland tools installed, almost ready to go.<br />
<br />
=Configure GRUB to start Xen=<br />
<br />
Because Xen starts before your operating system we need to change how your systems boot process is setup. The bootloader installed during installation called GRUB is what tells your computer which operating system to start and how.<br />
<br />
GRUB2 configuration is stored in the file /boot/grub/grub.cfg<br />
However we aren’t going to edit this file directly, as it changes every time we update our kernel.<br />
Debian configures GRUB for us using a number of automated scripts that handle upgrades etc, these scripts are stored in /etc/grub.d/* and are configured via<br />
<br />
/etc/default/grub<br />
<br />
We are going to change the order of the operating systems so that our Xen system is the default option. By executing the below command we are moving Xen to a higher priority than default Linux so that it gets the first position in the boot menu.<br />
<br />
mv -i /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen<br />
<br />
We then generate the /boot/grub/grub.cfg file by running the command below:<br />
<br />
update-grub<br />
<br />
We can now reboot and the default boot option will be our Xen dom0 running ontop of Xen!<br />
<br />
'''See also'''<br />
* [[Xen Hypervisor Boot Options|Xen GRUB Boot Options]]<br />
<br />
=Basic Xen commands=<br />
<br />
Before we dive into creating some guest domains we will quickly cover some basic Xen commands using the “xm” utiltiy. Going forward it is likely that xm will be deprecated as previously mentioned but once xl is stable and part of a supported release this guide will be rewritten to reflect that.<br />
<br />
So lets start with simple stuff!<br />
<br />
xl info<br />
<br />
This returns the information about the Xen hypervisor and dom0 including version, free memory etc.<br />
<br />
xl list<br />
<br />
Lists running domains, their IDs. memory, state and CPU time consumed<br />
<br />
xl top<br />
<br />
Shows running domains in real time and is similar to the “top” command under Linux. This can be used to visualize CPU, memory usage and block device access.<br />
<br />
We will cover some more commands during the creation of our guest domains.<br />
<br />
'''See also'''<br />
* [[Xen Man Pages]]<br />
<br />
=Creating a Debian PV (Paravirtualized) Guest=<br />
<br />
PV guests are notoriously “different” to install. Due to the nature of enlightened systems they don’t have the usual concepts of a CD-ROM drive installer analagous to their physical counterparts. However, luckly enough there does exist some tools that help us prepare “images” or effectively snapshots of the operating systems that are able to run inside of Xen domains.<br />
<br />
Debian contains a number of tools for creating Xen guests. The easiest of which is known as xen-tools. This software suite manages the downloading and installing of guest operating systems including both Debian and RHEL based DomUs. In this guide we are going to use xen-tools to prepare a Debian Squeeze paravirtualized domU.<br />
<br />
Xen-tools can use LVM storage for storing the guest operating systems, in this guide we created the volume group “vg0” in the Setting up LVM Storage section.<br />
<br />
When guests are paravirtualized there is no “BIOS” or bootloader resident within the guest filesystem and for a long time guests were provided with kernels external to the guest image. This however is bad for maintainability (guests cannot upgrade their kernels without access to the dom0) and is not as flexible in terms of boot options as they must be passed via the config file.<br />
<br />
The Xen community wrote a utility known as pygrub which is a python application for PV guests that enables the dom0 to parse the GRUB configuration of the domU and extract it’s kernel, initrd and boot parameters. This allows for kernel upgrades etc inside of our guest machines along with a GRUB menu. Using pygrub or the stub-dom implementation known as pv-grub is best practice for starting PV guests. In some cases pv-grub is arguably more secure but as it is not included with Debian we won’t use it here though it is recommended in production environments where guests cannot be trusted.<br />
<br />
Apart from this PV guests are very similar to their HVM and physical OS counterparts.<br />
Configuring xen-tools and building our guest<br />
First lets install the xen-tools package:<br />
<br />
aptitude install xen-tools<br />
<br />
We can now create a guest operating system with this tool. It effectly automates the process of setting up a PV guest from scratch right to the point of creating config files and starting the guest. The process can be summarized as follows:<br />
<br />
* Create logical volume for rootfs<br />
* Create logical volume for swap<br />
* Create filesystem for rootfs<br />
* Mount rootfs<br />
* Install operating system using debootstrap (or rinse etc, only debootstrap covered here)<br />
* Run a series of scripts to generate guest config files like fstab/inittab/menu.lst<br />
* Create a Xen config file for the guest<br />
* Generate a root password for the guest system<br />
* Unmount the guest filesystem<br />
<br />
These 9 steps can be carried out manually but the manual process is outside the scope of this guide. We instead will execute the below command:<br />
<br />
xen-create-image --hostname=tutorial-pv-guest \<br />
--memory=512mb \<br />
--vcpus=2 \<br />
--lvm=vg0 \<br />
--dhcp \<br />
--pygrub \<br />
--dist=squeeze<br />
<br />
This command instructs xen-create-image (the primary binary of the xen-tools toolkit) to create a guest domain with 512MB of memory, 2 vcpus, using storage from the vg0 volume group we created, use DHCP for networking, pygrub to extract the kernel from the image when booted and lastly we specify that we want to deploy a Debian Squeeze operating system.<br />
<br />
This process will take a few minutes after which you can start the guest with:<br />
<br />
xl create -c /etc/xen/tutorial-pv-guest.cfg<br />
<br />
The -c in this command tells xm that we wish to connect to the guest virtual console. Which is a paravirtualised serial port within the domain that xen-create-image configured to listen with a getty. This is analgous to running:<br />
<br />
xl create /etc/xen/tutorial-pv-guest.cfg && xm console tutorial-pv-guest<br />
<br />
You can leave the guest virtual console by pressing ctrl+] and re-enter it by running the “xl console <domain>” command.<br />
<br />
You can later shutdown this guest either from within the domain or from dom0 with the following:<br />
<br />
xl shutdown tutorial-pv-guest<br />
<br />
That completes our section on setting up your first paravirtualized domain! If you don’t have any interest in setting up a HVM domain then no need to read any further but it is highly recommended!<br />
<br />
=Creating a Windows HVM (Hardware Virtualized) Guest=<br />
<br />
HVM guests are quite a bit different to their PV counterparts. Because they require the emulation of hardware there is more moving pieces that need to be configured etc.<br />
<br />
The main point worth mentioning here is that HVM requires the emulation of ATA, Ethernet and other devices, while virtualized CPU and Memory access is performed in hardware to achieve good performance. Because of this the default emulated devices are very slow and we generally try to use PV drivers within HVM domains. We will be installing a set of Windows PV drivers that greatly increase performance once we have our Windows guest running.<br />
<br />
This extra emulation is provided by a Xen modified version of QEMU we should have installed this earlier but in case you skipped that step install the Xen QEMU package now:<br />
<br />
aptitude install xen-qemu-dm<br />
<br />
Once the necessary packages are installed we need to create a logical volume to store our Windows VM hard disk, create a config file that tells Xen to start the domain in HVM mode and boot from the DVD in order to install Windows.<br />
<br />
First, create the new logical volume - name the volume "windows", set the size to 20GB and use the volume group vg0 we created earlier.<br />
<br />
lvcreate -nwindows -L20G vg0<br />
<br />
Next open a new file with your text editor of choice:<br />
<br />
nano windows.cfg<br />
<br />
Paste the config below into the file and save it, NOTE this assumes your Windows iso is located in /root/ with the filename windows.iso.<br />
<br />
kernel = "/usr/lib/xen-4.0/boot/hvmloader"<br />
builder='hvm'<br />
memory = 4096<br />
vcpus=4<br />
name = "ovm-1734"<br />
vif = ['bridge=xenbr0']<br />
disk = ['phy:/dev/vg0/windows,hda,w','file:/root/windows.iso,hdc:cdrom,r']<br />
acpi = 1<br />
device_model = 'qemu-dm'<br />
boot="d"<br />
sdl=0<br />
serial='pty'<br />
vnc=1<br />
vnclisten=""<br />
vncpasswd=""<br />
<br />
You can then start the domain and connect to it via VNC from your graphical machine.<br />
<br />
xm create windows.cfg<br />
<br />
The VNC display should be available on port 5900 of your dom0 IP, for instance using gvncviewer:<br />
<br />
gvncviewer <dom0 ip>:5900<br />
<br />
Once you have installed Windows by formatting the disk and by following the prompts the domain will restart - however this time we want to prevent it booting from DVD so destroy the domain with<br />
<br />
xm destroy windows<br />
<br />
Then change the boot line in the config file to read boot="c"' restart the domain with<br />
<br />
xm create windows.cfg<br />
<br />
Reconnect with VNC and finish the installatation.<br />
When this process is complete you should then procede to download the GPLPV drivers for Windows by James Harper.<br />
<br />
Signed drivers can be obtained from here:<br />
<br />
http://wiki.univention.de/index.php?title=Installing-signed-GPLPV-drivers<br />
<br />
Many thanks for Univention for making signed drivers available to the Xen community and ofcourse a massive thanks to James for all his work on making Windows on Xen such a smooth experience.<br />
On finalizing the installation and rebooting you should notice much improved disk and network performance and Xen will now be able to gracefully shutdown your Windows domains.<br />
<br />
= Conclusion =<br />
<br />
That concludes our introduction to Xen, by now you can setup both PV and HVM domains on a bare dom0 hypervisor!<br />
<br />
You can now move onto building your own guest images or try out some prebuilt [[Guest VM Images]].<br />
<br />
<br />
[[Category:Xen]]<br />
[[Category:Beginners]]<br />
[[Category:Tutorial]]<br />
[[Category:Debian]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_Project_Beginners_Guide&diff=5091Xen Project Beginners Guide2012-09-24T13:41:23Z<p>OliverChick: /* Basic Xen commands */ xm => xl</p>
<hr />
<div>Welcome!<br />
<br />
This guide was written to introduce beginners to basic Xen concepts and allow you to get started with Xen with no prior knowledge. Some prior Linux experience is required however, knowledge of networking, lvm and grub will go a long way!<br />
<br />
By completing this guide you will have installed a fully functional Xen hypervisor and started your first guest operating systems, connected them to your network and have been introduced to fundamental concepts such as virtual machine storage and virtual networking.<br />
To make this process easy we will be using a Linux distribution called Debian. Debian’s current stable release “Squeeze” ships with support for Xen 4 and everything you need to get started!<br />
<br />
Though this guide looks long at first don’t be daunted, it is very indepth and comprehensive but doesn’t expect you to know all that much beforehand. The goal instead is to teach you all the things you need to know to build a functioning Xen hypervisor. :)<br />
<br />
=What is Xen all about?=<br />
<br />
Xen is a Virtual Machine Monitor (VMM) also known as a hypervisor, this is a software system that allows the execution of multiple virtual guest operating systems simultaneously on a single physical machine. Xen is known as a Type 1 or “bare-metal” hypervisor, meaning that it runs directly ontop of the physical machine as opposed to within an operating system.<br />
<br />
Guest virtual machines running on Xen are known as “domains” and a special domain known as dom0 is responsible for controlling the hypervisor and starting other guest operating systems. These other guest operating systems are called domUs, this is because these domains are “unprivileged” in the sense they cannot control Xen or start/stop other domains.<br />
<br />
Xen supports 2 primary types of virtualization, para-virtualization and hardware virtual machine (HVM) also known as “full virtualization”. Para-virtualization uses modified guest operating systems that we refer to as enlightened guests. These operating systems are aware that they are being virtualized and as such don’t require virtual “hardware” devices, instead they make special calls to Xen that allow them to access CPUs, storage and network resources.<br />
<br />
In contrast HVM guests need not be modified as Xen will create a fully virtual set of hardware devices for this machine that resemble a physical x86 computer. This emulation requires much more overhead than the paravirtualisation approach but allows unmodified guest operating systems like Microsoft Windows to run ontop of Xen. HVM support requires special CPU extensions - VT-x for Intel processors and AMD-V for AMD based machines. This technology is now prevalent and all recent servers and desktop systems should be equipped with them.<br />
<br />
A third type of virtualization though not discussed in this guide is called PVHVM or “Para-virtualisation on HVM” which is a HVM domain with paravirtualized storage, network and other devices. This provides the best of both worlds by reducing expensive emulation but providing hardware accelerated CPU and memory access.<br />
A brief look at Xen architecture<br />
To understand how storage, networking and other resources are delivered to guest systems we need to quickly delve into how the different bits of Xen interact.<br />
<br />
'''<todo diagram>'''<br />
<br />
'''<todo explain dom0 role and datapath for guest IO/network>'''<br />
<br />
The dom0 forms the interface to the hypervisor, through special instructions the dom0 communicates to Xen and changes the configuration of the hypervisor. This includes instantiating new domains and related tasks.<br />
<br />
Another crucial part of the dom0’s role is that it is the primary interface to the hardware. Xen doesn’t contain device drivers, instead the devices are attached to dom0 and you can use standard Linux drivers. Dom0 then shares these resources with guest operating systems through a number of “backend” deamons.<br />
<br />
For each para-virtualized subsystem in Xen consists of 2 parts, the aforementioned “backend” that lives in dom0 and the “frontend” driver within the guest domain. The backend is effectively a deamon which uses special ring buffer based interfaces to transfer data to guests, be it to provide a virtual hard-disk, Ethernet adapter of even a generic SCSI device.<br />
The frontend driver then takes this stream of data and converts it back into a device within the guest operating system.<br />
<br />
The 2 important paravirtualisation systems are known as net-back/net-front and blk-back/blk-front which are the paravirtualized networking and storage systems respectively.<br />
<br />
You can read more about how Xen is architected, paravirtualization and the benefits of such here:<br />
<br />
'''<todo find xen article on wiki with deep explaination of PV>'''<br />
<br />
=Preparation=<br />
<br />
This guide requires a number of items, this checklist is what you will need:<br />
<br />
* 64bit x86 computer with atleast 1GB of RAM (this can be a server,desktop or laptop!)<br />
* (Optional) VT-d or AMD-V support<br />
* Sufficient storage space for your dom0 and whatever guests you want to install<br />
* A CD burner + blank CD (you can use a USB but this is not covered here)<br />
* Internet access for downloading and installing Debian<br />
* (Optional) Windows Server 2008R2 installation ISO, a trial copy is sufficient<br />
* (Optional) VNC client for installing HVM domain<br />
<br />
==Enable virtualization support in BIOS==<br />
<br />
''NOTE: This is optional and not required for PV guests''<br />
<br />
In order to support HVM guests we need to ensure that virtualization extensions are enabled in the BIOS. If you don’t wish to start a HVM guest you can skip this step but it is still highly recommended. If your system doesn’t support these extensions you cannot use Xen to virtualize unmodified operating systems, however para-virtualization will work fine.<br />
<br />
The virtualization option appears differently in different BIOS builds but generally it is refered to as “Enable Virtualisation Technology” or “Enable Intel VT” for Intel chipsets, however in some cases it can be listed as “Vanderpool Technology”. Oftentimes this option can be found under the “Advanced Chipset Features” menu in the BIOS. Similar also for AMD.<br />
<br />
Consult your motherboard documentation for more assistance in enabling virtualization extensions on your system.<br />
<br />
==Download and burn Debian Squeeze Installer CD==<br />
<br />
Download the ISO image from this URL:<br />
<br />
http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/<br />
<br />
The netinst image is sufficient for our purposes.<br />
<br />
Burn the ISO to disk using your computers standard utilities. I recommend wodim on Linux or the built in ISO burning feature in Windows.<br />
<br />
==Quick intro to Debian==<br />
<br />
Debian is a simple, stable and well supported Linux distribution. It has included Xen support since Debian 3.1 “Sarge” released in 2005. The current stable release Debian 6.0 “Squeeze” ships with Xen 4.0.1 and a Xen enabled Linux 2.6.32 kernel.<br />
<br />
Debian uses the simple Apt package management system which is both powerful and simple to use.<br />
Installing a package is as simple as the following example:<br />
<br />
aptitude install htop<br />
<br />
Where htop was the application desired to install.<br />
<br />
Simple tasks such as configuring startup scripts, setting up the network etc are covered by this tutorial so don’t worry if you haven’t used Debian before!<br />
<br />
Many popular distributions are based off of Debian and also use the Apt package manager, if you have used Ubuntu, Linux Mint or Damn Small Linux you will feel right at home.<br />
<br />
=Installing Debian Squeeze=<br />
<br />
Boot the Debian Squeeze Installer CD<br />
Insert the Debian CD and configure the CDROM drive as your default boot device in the BIOS or use the system bootmenu if your BIOS supports it (usually F12).<br />
<br />
You should see a menu, choose the default “Install” option to begin the installation process.<br />
Install the system<br />
The Debian installer is very straight forward. Follow the prompts until you reach the disk partitioning section.<br />
<br />
Choose advanced/custom, we are going to configure a few partitions here, one for /boot another for /, one more for swap and a final partition to setup as an LVM volume group for our guest machines.<br />
<br />
First create the /boot partition by choosing the disk and hitting enter, make the partition 300MB and format it as ext2, choose /boot as the mountpoint.<br />
<br />
Repeat the process for / but of course changing the mountpoint to / and making it 15GB or so large. Format it as ext3.<br />
<br />
Create another partition approximately 1.5x the amount of RAM you have in size and elect to have it used as a swap volume.<br />
<br />
Finally create a partition that consumes the rest of the diskspace but don’t format it or assign a mount point.<br />
<br />
We should now have a layout that looks like this assuming your disk device is /dev/sda :<br />
<br />
sda1 - /boot 200MB<br />
sda2 - / 15GB<br />
sda3 - swap<br />
sda4 - reserved for LVM<br />
<br />
When you reach the package selection stage only install the base system, we won’t require any GUI or other packages for this guide.<br />
<br />
'''<todo: extend to cover the rest of the installation process>'''<br />
<br />
Continue through the installer then reboot and login at the prompt as root.<br />
<br />
=Setup LVM storage for guests=<br />
<br />
LVM is the Linux Logical Volume manager. It is a technology that allows Linux to manage block devices in a more abstract manner.<br />
<br />
LVM introduces the concept of a “logical volume”, effectively a virtualized block device composed of blocks written to 1 or more physical devices. These blocks don’t need to be contiguous unlike proper disk partitions.<br />
<br />
Because of this abstraction logical volumes can be created, deleted, resized and even snapshotted without affecting other logical volumes.<br />
<br />
LVM creates logical volumes within what is called a volume group, which is simply a set of logical volumes that share the same physical storage, known as physical volumes.<br />
<br />
The process of setting up LVM can be sumarized as allocating a physical volume, creating a volume group ontop of this then creating logical volumes to store data.<br />
<br />
Because of these features and superior performance over file backed virtual machines I recommend the use of LVM if you are going to store VM data locally.<br />
<br />
Now lets install LVM and get started!<br />
<br />
Install LVM with aptitude by running this command:<br />
<br />
aptitude install lvm2<br />
<br />
Now that we have LVM installed lets configure it to use /dev/sda4 as it’s physical volume<br />
<br />
pvcreate /dev/sda4<br />
<br />
Ok, now LVM has somewhere to store it’s blocks (known as extents for future reference).<br />
Lets create a volume group called ‘vg0’ using this physical volume:<br />
<br />
vgcreate vg0 /dev/sda4<br />
<br />
Now LVM is setup and initialized so that we can later create logical volumes for our virtual machines.<br />
<br />
For the interested below is a number of useful commands and tricks when using LVM.<br />
<br />
Create a new logical volume:<br />
<br />
lvcreate -n<name of the volume> -L<size, you can use G and M here> <volume group><br />
<br />
For example, creating a 100 gigabyte volume called database-data on a volume group called vg0.<br />
<br />
lvcreate -ndatabase-data -L100G vg0<br />
<br />
You can then remove this volume with the following:<br />
<br />
lvremove /dev/vg0/database-data<br />
<br />
Note that you have to provide the path to the volume here.<br />
<br />
If you already have a volume setup that you would like to copy, LVM has a cool feature that allows you to create a CoW (copy on write) clone called a snapshot.<br />
This means that you can make an "instant" copy that will only store the changes compared to the original. There are a number of caveats to this that will be discussed in a yet unwritten article.<br />
The most important thing to note is that the "size" of the snapshot is only the ammount of space allocated to store changes. So you can make the snapshot "size" alot smaller than the source volume.<br />
<br />
To create a snapshot use the following command:<br />
<br />
lvcreate -s /dev/vg0/database-data -ndatabase-backup -L5G<br />
<br />
Once again note the use of the full path.<br />
<br />
=Setup Linux Bridge for guest networking=<br />
<br />
Next we need to setup our system so that we can attach virtual machines to the external network. This is done by creating a virtual switch within dom0 that takes packets from the virtual machines and forwards them onto the physical network so they can see the internet and other machines on your network.<br />
<br />
The piece of software we use to do this is called the Linux bridge and it’s core components reside inside the Linux kernel. In this case the “bridge” is effectively our virtual switch. Our Debian kernels are compiled with the Linux bridging module so all we need to do is install the control utilities.<br />
<br />
aptitude install bridge-utils<br />
<br />
With bridge-utils installed we now have a utility called “brctl” this utility talks to the Linux bridging module to setup new bridges and attach physical or virtual interfaces to these bridges.<br />
<br />
brctl can be used to create a bridge as such, where <bridgename> is the name of the bridge:<br />
<br />
brctl addbr <bridgename><br />
<br />
And interfaces can be added to that bridge by running the following:<br />
<br />
brctl addif <bridgename> <interface><br />
<br />
Instead of calling brctl directly we are instead going to configure our bridge through Debian’s networking infrastructure which can be configured through <br />
<br />
/etc/network/interfaces<br />
<br />
Open this file with the editor of your choice (more editors can be installed with aptitude)<br />
Nano is installed by default if you selected the minimal install<br />
<br />
nano /etc/network/interfaces<br />
<br />
Depending on your hardware you probably see a file pretty similar to this:<br />
<br />
<pre><br />
auto lo<br />
iface lo inet loopback<br />
<br />
auto eth0<br />
iface eth0 inet dhcp<br />
</pre><br />
<br />
This file is very simple. Each stanza represents a single interface.<br />
Breaking it down “auto eth0” means that eth0 will be configured when ifup -a is run (which is run a boot time) what this means is that the interface with automatically be started/stopped for you.<br />
“iface eth0” then describes the interface itself, in this case it merely specifies that it should be configured by DHCP - we are going to assume that you have DHCP running on your network for this guide. If you are using static addressing you probably know how to set that up.<br />
We are going to edit this file so it resembles such:<br />
<br />
<pre><br />
auto lo<br />
iface lo inet loopback<br />
<br />
iface eth0 inet manual<br />
auto xenbr0<br />
<br />
iface xenbr0 inet dhcp<br />
bridge_ports eth0<br />
</pre><br />
<br />
This will setup the bridge xenbr0 and add eth0 to the bridge for us.<br />
The equivalent commands would be:<br />
<br />
brctl addbr xenbr0<br />
brctl addif xenbr0 eth0<br />
dhclient xenbr0<br />
<br />
Except this will now be done automatically on boot and completely managed by Debian.<br />
<br />
This method of network configuration is best practice and the automated scripts called by xend are now deprecated, we will discuss this later once we have Xen installed.<br />
<br />
=Installing Xen=<br />
<br />
The Debian Xen packages consists primarily of a Xen enabled Linux kernel, the Xen hypervisor itself, a modified version of QEMU that support Xen’s HVM mode and a set of userland tools.<br />
<br />
All of this except QEMU can be installed via an Apt meta-package callled xen-linux-system. A meta-package is basically a way of installing a group of packages automatically. Apt will ofcourse resolve all dependencies and bring in all the extra libraries we need.<br />
<br />
Lets install the xen-linux-system metapackage:<br />
<br />
aptitude -P install xen-linux-system<br />
<br />
Next we will install the Xen QEMU package so that we can boot HVM guests later (this is optional but highly recommended)<br />
<br />
aptitude install xen-qemu-dm<br />
<br />
Now have Xen, a Xen kernel and the userland tools installed, almost ready to go.<br />
<br />
=Configure GRUB to start Xen=<br />
<br />
Because Xen starts before your operating system we need to change how your systems boot process is setup. The bootloader installed during installation called GRUB is what tells your computer which operating system to start and how.<br />
<br />
GRUB2 configuration is stored in the file /boot/grub/grub.cfg<br />
However we aren’t going to edit this file directly, as it changes every time we update our kernel.<br />
Debian configures GRUB for us using a number of automated scripts that handle upgrades etc, these scripts are stored in /etc/grub.d/* and are configured via<br />
<br />
/etc/default/grub<br />
<br />
We are going to change the order of the operating systems so that our Xen system is the default option. By executing the below command we are moving Xen to a higher priority than default Linux so that it gets the first position in the boot menu.<br />
<br />
mv -i /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen<br />
<br />
We then generate the /boot/grub/grub.cfg file by running the command below:<br />
<br />
update-grub<br />
<br />
We can now reboot and the default boot option will be our Xen dom0 running ontop of Xen!<br />
<br />
'''See also'''<br />
* [[Xen Hypervisor Boot Options|Xen GRUB Boot Options]]<br />
<br />
=Basic Xen commands=<br />
<br />
Before we dive into creating some guest domains we will quickly cover some basic Xen commands using the “xm” utiltiy. Going forward it is likely that xm will be deprecated as previously mentioned but once xl is stable and part of a supported release this guide will be rewritten to reflect that.<br />
<br />
So lets start with simple stuff!<br />
<br />
xl info<br />
<br />
This returns the information about the Xen hypervisor and dom0 including version, free memory etc.<br />
<br />
xl list<br />
<br />
Lists running domains, their IDs. memory, state and CPU time consumed<br />
<br />
xl top<br />
<br />
Shows running domains in real time and is similar to the “top” command under Linux. This can be used to visualize CPU, memory usage and block device access.<br />
<br />
We will cover some more commands during the creation of our guest domains.<br />
<br />
'''See also'''<br />
* [[Xen Man Pages]]<br />
<br />
=Creating a Debian PV (Paravirtualized) Guest=<br />
<br />
PV guests are notoriously “different” to install. Due to the nature of enlightened systems they don’t have the usual concepts of a CD-ROM drive installer analagous to their physical counterparts. However, luckly enough there does exist some tools that help us prepare “images” or effectively snapshots of the operating systems that are able to run inside of Xen domains.<br />
<br />
Debian contains a number of tools for creating Xen guests. The easiest of which is known as xen-tools. This software suite manages the downloading and installing of guest operating systems including both Debian and RHEL based DomUs. In this guide we are going to use xen-tools to prepare a Debian Squeeze paravirtualized domU.<br />
<br />
Xen-tools can use LVM storage for storing the guest operating systems, in this guide we created the volume group “vg0” in the Setting up LVM Storage section.<br />
<br />
When guests are paravirtualized there is no “BIOS” or bootloader resident within the guest filesystem and for a long time guests were provided with kernels external to the guest image. This however is bad for maintainability (guests cannot upgrade their kernels without access to the dom0) and is not as flexible in terms of boot options as they must be passed via the config file.<br />
<br />
The Xen community wrote a utility known as pygrub which is a python application for PV guests that enables the dom0 to parse the GRUB configuration of the domU and extract it’s kernel, initrd and boot parameters. This allows for kernel upgrades etc inside of our guest machines along with a GRUB menu. Using pygrub or the stub-dom implementation known as pv-grub is best practice for starting PV guests. In some cases pv-grub is arguably more secure but as it is not included with Debian we won’t use it here though it is recommended in production environments where guests cannot be trusted.<br />
<br />
Apart from this PV guests are very similar to their HVM and physical OS counterparts.<br />
Configuring xen-tools and building our guest<br />
First lets install the xen-tools package:<br />
<br />
aptitude install xen-tools<br />
<br />
We can now create a guest operating system with this tool. It effectly automates the process of setting up a PV guest from scratch right to the point of creating config files and starting the guest. The process can be summarized as follows:<br />
<br />
* Create logical volume for rootfs<br />
* Create logical volume for swap<br />
* Create filesystem for rootfs<br />
* Mount rootfs<br />
* Install operating system using debootstrap (or rinse etc, only debootstrap covered here)<br />
* Run a series of scripts to generate guest config files like fstab/inittab/menu.lst<br />
* Create a Xen config file for the guest<br />
* Generate a root password for the guest system<br />
* Unmount the guest filesystem<br />
<br />
These 9 steps can be carried out manually but the manual process is outside the scope of this guide. We instead will execute the below command:<br />
<br />
xen-create-image --hostname=tutorial-pv-guest \<br />
--memory=512mb \<br />
--vcpus=2 \<br />
--lvm=vg0 \<br />
--dhcp \<br />
--pygrub \<br />
--dist=squeeze<br />
<br />
This command instructs xen-create-image (the primary binary of the xen-tools toolkit) to create a guest domain with 512MB of memory, 2 vcpus, using storage from the vg0 volume group we created, use DHCP for networking, pygrub to extract the kernel from the image when booted and lastly we specify that we want to deploy a Debian Squeeze operating system.<br />
<br />
This process will take a few minutes after which you can start the guest with:<br />
<br />
xm create -c /etc/xen/tutorial-pv-guest.cfg<br />
<br />
The -c in this command tells xm that we wish to connect to the guest virtual console. Which is a paravirtualised serial port within the domain that xen-create-image configured to listen with a getty. This is analgous to running:<br />
<br />
xm create /etc/xen/tutorial-pv-guest.cfg && xm console tutorial-pv-guest<br />
<br />
You can leave the guest virtual console by pressing ctrl+] and re-enter it by running the “xm console <domain>” command.<br />
<br />
You can later shutdown this guest either from within the domain or from dom0 with the following:<br />
<br />
xm shutdown tutorial-pv-guest<br />
<br />
That completes our section on setting up your first paravirtualized domain! If you don’t have any interest in setting up a HVM domain then no need to read any further but it is highly recommended!<br />
<br />
=Creating a Windows HVM (Hardware Virtualized) Guest=<br />
<br />
HVM guests are quite a bit different to their PV counterparts. Because they require the emulation of hardware there is more moving pieces that need to be configured etc.<br />
<br />
The main point worth mentioning here is that HVM requires the emulation of ATA, Ethernet and other devices, while virtualized CPU and Memory access is performed in hardware to achieve good performance. Because of this the default emulated devices are very slow and we generally try to use PV drivers within HVM domains. We will be installing a set of Windows PV drivers that greatly increase performance once we have our Windows guest running.<br />
<br />
This extra emulation is provided by a Xen modified version of QEMU we should have installed this earlier but in case you skipped that step install the Xen QEMU package now:<br />
<br />
aptitude install xen-qemu-dm<br />
<br />
Once the necessary packages are installed we need to create a logical volume to store our Windows VM hard disk, create a config file that tells Xen to start the domain in HVM mode and boot from the DVD in order to install Windows.<br />
<br />
First, create the new logical volume - name the volume "windows", set the size to 20GB and use the volume group vg0 we created earlier.<br />
<br />
lvcreate -nwindows -L20G vg0<br />
<br />
Next open a new file with your text editor of choice:<br />
<br />
nano windows.cfg<br />
<br />
Paste the config below into the file and save it, NOTE this assumes your Windows iso is located in /root/ with the filename windows.iso.<br />
<br />
kernel = "/usr/lib/xen-4.0/boot/hvmloader"<br />
builder='hvm'<br />
memory = 4096<br />
vcpus=4<br />
name = "ovm-1734"<br />
vif = ['bridge=xenbr0']<br />
disk = ['phy:/dev/vg0/windows,hda,w','file:/root/windows.iso,hdc:cdrom,r']<br />
acpi = 1<br />
device_model = 'qemu-dm'<br />
boot="d"<br />
sdl=0<br />
serial='pty'<br />
vnc=1<br />
vnclisten=""<br />
vncpasswd=""<br />
<br />
You can then start the domain and connect to it via VNC from your graphical machine.<br />
<br />
xm create windows.cfg<br />
<br />
The VNC display should be available on port 5900 of your dom0 IP, for instance using gvncviewer:<br />
<br />
gvncviewer <dom0 ip>:5900<br />
<br />
Once you have installed Windows by formatting the disk and by following the prompts the domain will restart - however this time we want to prevent it booting from DVD so destroy the domain with<br />
<br />
xm destroy windows<br />
<br />
Then change the boot line in the config file to read boot="c"' restart the domain with<br />
<br />
xm create windows.cfg<br />
<br />
Reconnect with VNC and finish the installatation.<br />
When this process is complete you should then procede to download the GPLPV drivers for Windows by James Harper.<br />
<br />
Signed drivers can be obtained from here:<br />
<br />
http://wiki.univention.de/index.php?title=Installing-signed-GPLPV-drivers<br />
<br />
Many thanks for Univention for making signed drivers available to the Xen community and ofcourse a massive thanks to James for all his work on making Windows on Xen such a smooth experience.<br />
On finalizing the installation and rebooting you should notice much improved disk and network performance and Xen will now be able to gracefully shutdown your Windows domains.<br />
<br />
= Conclusion =<br />
<br />
That concludes our introduction to Xen, by now you can setup both PV and HVM domains on a bare dom0 hypervisor!<br />
<br />
You can now move onto building your own guest images or try out some prebuilt [[Guest VM Images]].<br />
<br />
<br />
[[Category:Xen]]<br />
[[Category:Beginners]]<br />
[[Category:Tutorial]]<br />
[[Category:Debian]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Fedora_13_Xen_4_Tutorial&diff=5090Fedora 13 Xen 4 Tutorial2012-09-24T13:33:06Z<p>OliverChick: Marked as out of date</p>
<hr />
<div><!-- MoinMoin name: Fedora13Xen4Tutorial --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: Fedora13Xen4Tutorial --><br />
<!-- Page revision: 00000117 --><br />
<!-- Original date: Tue Aug 30 06:23:21 2011 (1314685401000000) --><br />
{{Info|This page is marked out-of-date. Both Fedora 13, and Xen 4.0.1 are out-of-date}}<br />
<br />
This is a step-by-step tutorial how to install Xen hypervisor 4.0.1 and the long-term maintained Linux pvops dom0 kernel 2.6.32.x on Fedora 13 (x86_64) Linux. <br />
<br />
As a default Fedora 13 includes Xen 3.4.3 RPMs, but this tutorial explains how to install the newer Xen 4.0.1 version by downloading the RPMs from Fedora Koji. <br />
<br />
Additionally, this tutorial will also cover the installation of a PVops dom0 kernel.<br />
<br />
Note that this tutorial disables various security features to make sure everything works well without unexpected problems! After getting everything to work OK you should enable SElinux, iptables firewall etc. Follow this tutorial step-by-step and you'll get a working system.<br />
<br />
The steps below also work for Fedora 14. Fedora 14 includes Xen 4.0.2 rpm binaries in the default repositories. <br />
<br />
Hardware used in this tutorial:<br />
<br />
* Intel Core2 Quad CPU.<br />
* 8 GB of RAM.<br />
* SATA harddisk (AHCI mode).<br />
* DVDROM drive.<br />
* Intel NIC (e1000), DHCP for Internet access.<br />
For generic information about Xen 4.0 release please see [[Xen4.0]] wiki page.<br />
<br />
This tutorial is verified to work on 30th of October 2010.<br />
<br />
== Installing Fedora 13 ==<br />
Get Fedora, whether by burning a CD/DVD, running it from a USB drive, or doing a network install. You can follow the official Fedora Guide, available [http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/pt-Preparing_for_Installation.html here] for more information.<br />
<br />
The installation is straight forward. There are no Xen specific options that have to be selected at install time, other than setting up your hard drive(s) for later use. Ideally, you should choose the "Minimal Installation" option, though it's not strictly necessary. These instructions are just guidelines, and don't have to be strictly adhered to. Feel free to modify them as necessary.<br />
<br />
In general:<br />
* Make /boot partition the primary (first) partition and choose "ext3" (not "ext4") as the filesystem type<br />
* Make /boot big, say 2 GB, to fit all the development debug-enabled kernels and big initrd-images caused by debug-enabled kernel modules. <br />
* With the rest of the space on the drive, create a second partition and format it as LVM PV (Physical Volume)<br />
* Create a LVM Volume Group on your newly created LVM PV. <br />
* Then create a new logical volume on the new volume group, and assign it the mount point / (the root). It should be at least 40 GB to fit all the development tools and source trees. The type of filesystem isn't important, though it's unlikely you'll need to change the default - ext4.<br />
* Create a swap partition logical volume on the volume group as well.<br />
* '''Important note about LVM volume group setup: You should leave free space in the LVM volume group for storing guest virtual disks!! ''' If you don't do this, you'll need to find an alternate location to store the guest virtual disks.<br />
* See this F13 installer screenshot for disk partitioning and LVM setup example:<br />
http://pasik.reaktio.net/fedora/f13xen4tutorial/f13-installer-partitions-for-xen.jpg<br />
<br />
== Configuration after installation ==<br />
After the installation login as "root" from the console.<br />
<br />
Enable automatic start of networking and start the network (it's disabled by default in favor of NetworkManager):<br />
<br />
<pre><br />
# chkconfig network on<br />
# chkconfig NetworkManager off<br />
# /etc/init.d/network start<br />
</pre><br />
<br />
After starting the network you can log in from the network using SSH, if you prefer remotely configuring and setting up things. Use "ifconfig" to check the IP of the newly installed system (if using DHCP).<br />
<br />
Then we continue and install some commonly used and needed tools:<br />
<br />
<pre><br />
# yum install screen vim wget tcpdump ntp ntpdate man smartmontools ethtool<br />
</pre><br />
<br />
Enable and start ntpd to keep time synchronized:<br />
<br />
<pre><br />
# chkconfig ntpd on<br />
# chkconfig ntpdate on<br />
# /etc/init.d/ntpdate start<br />
# /etc/init.d/ntpd start<br />
</pre><br />
<br />
As a default (in F13) you don't get to choose the kernel - grub menu will be skipped. So you'll need to fix the timeout to be able to choose which kernel to boot during system startup. <br />
<br />
Edit "/boot/grub/grub.conf" and modify "timeout=10" and comment out the "hiddenmenu" option, so it'll look like:<br />
<br />
<pre><br />
#boot=/dev/sda<br />
default=0<br />
timeout=10<br />
splashimage=(hd0,0)/grub/splash.xpm.gz<br />
#hiddenmenu<br />
title Fedora (2.6.33.3-85.fc13.x86_64)<br />
root (hd0,0)<br />
kernel /vmlinuz-2.6.33.3-85.fc13.x86_64 ro root=/dev/mapper/vg_f13-lvroot rd_LVM_LV=vg_f13/lvroot rd_LVM_LV=vg_f13/lvswap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=fi rhgb quiet<br />
initrd /initramfs-2.6.33.3-85.fc13.x86_64.img<br />
</pre><br />
<br />
SELinux doesn't play too well with Xen, and we want to make sure we don't get problems from too strict selinux policies at this point. So edit "/etc/selinux/config" and disable SELinux:<br />
<br />
<pre><br />
# This file controls the state of SELinux on the system.<br />
# SELINUX= can take one of these three values:<br />
# enforcing - SELinux security policy is enforced.<br />
# permissive - SELinux prints warnings instead of enforcing.<br />
# disabled - No SELinux policy is loaded.<br />
SELINUX=disabled<br />
# SELINUXTYPE= can take one of these two values:<br />
# targeted - Targeted processes are protected,<br />
# mls - Multi Level Security protection.<br />
SELINUXTYPE=targeted<br />
</pre><br />
<br />
We're going to be connecting to the dom0 by SSH/VNC for remote domU installs, so disable the Fedora default iptables firewall for now: (Properly configuring the firewall is out of scope for this tutorial, but it is recommended.)<br />
<br />
<pre><br />
# /etc/init.d/iptables stop<br />
# chkconfig iptables off<br />
</pre><br />
<br />
Next, disable ksmtuned so that it won't flood the console with errors (it's not compatible with Xen currently):<br />
<br />
<pre><br />
# /etc/init.d/ksmtuned stop<br />
# chkconfig ksmtuned off<br />
</pre><br />
<br />
If you're going to use X11 forwarding over ssh session, install "xorg-x11-xauth"<br />
<br />
<pre><br />
# yum install xorg-x11-xauth<br />
</pre><br />
<br />
Install the latest Fedora package updates, any security fixes, etc:<br />
<br />
<pre><br />
# yum update<br />
</pre><br />
<br />
And at this point it's best to reboot the system, to get the newest kernel in use, and make sure everything works so far.<br />
<br />
<pre><br />
# reboot<br />
</pre><br />
<br />
After the system reboots it's good to verify the firewall got disabled properly and there are no iptables rules in use anymore:<br />
<br />
<pre><br />
# iptables -L -n -v<br />
Chain INPUT (policy ACCEPT 99 packets, 11467 bytes)<br />
pkts bytes target prot opt in out source destination<br />
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)<br />
pkts bytes target prot opt in out source destination<br />
Chain OUTPUT (policy ACCEPT 97 packets, 9805 bytes)<br />
pkts bytes target prot opt in out source destination<br />
</pre><br />
<br />
Also verify SElinux is disabled:<br />
<br />
<pre><br />
# getenforce<br />
Disabled<br />
</pre><br />
<br />
Now all the basic setup is done and you can move forward.<br />
<br />
== Installing Xen 4 ==<br />
For Fedora 14 (and later), RPMs are pre-compiled and included in the Fedora repos. As such, it is possible to do <code>yum install xen</code> to get all the necessary xen components.<br />
<br />
For Fedora 13, the latest and greatest updates for all versions of Fedora are available for download directly from [http://koji.fedoraproject.org/koji/packageinfo?packageID=7 Fedora Koji]. <br />
In theory, the RPMs built for later distributions (ie Fedora 15) can work with Fedora 13/14 - however, this has not been tested. Instead, download the RPMs built for Fedora 14, then do a <br />
<br />
<pre>yum localinstall *.rpm</pre><br />
<br />
If you want to download & compile Xen yourself, see [[Compiling_Xen|Compiling Xen]] for a step by step guide.<br />
<br />
== Download or compile Linux 2.6.32.x pvops Xen dom0 kernel ==<br />
For more information about pvops dom0 kernels and why it's necessary to use a special kernel, please see [[XenParavirtOps]] wiki page.<br />
<br />
The easiest way to get the kernel is to download a pre-built "xendom0" kernel rpm. You can get them from Fedora developer M A Young's site:<br />
<br />
* http://repos.fedorapeople.org/repos/myoung/dom0-kernel/<br />
<br />
'''As of 14th Apr 2011, the compiled kernels were last updated on 3rd May 2011, and were built for Fedora 13 according to the filename. However, they should work on Fedora 14. You can compile the kernel yourself to get the latest updates, or choose to download the kernel RPMs. '''<br />
<br />
== Prepare to reboot into Xen ==<br />
First we have to set up a new grub entry to boot the Xen hypervisor with the pvops dom0 kernel. We do so by editing "/boot/grub/grub.conf" to make it look like this:<br />
<br />
<pre><br />
# grub.conf generated by anaconda<br />
#<br />
# Note that you do not have to rerun grub after making changes to this file<br />
# NOTICE: You have a /boot partition. This means that<br />
# all kernel and initrd paths are relative to /boot/, eg.<br />
# root (hd0,0)<br />
# kernel /vmlinuz-version ro root=/dev/mapper/vg_f13-lvroot<br />
# initrd /initrd-[generic-]version.img<br />
#boot=/dev/sda<br />
default=0<br />
timeout=10<br />
splashimage=(hd0,0)/grub/splash.xpm.gz<br />
#hiddenmenu<br />
title Fedora (2.6.33.6-147.2.4.fc13.x86_64)<br />
root (hd0,0)<br />
kernel /vmlinuz-2.6.33.6-147.2.4.fc13.x86_64 ro root=/dev/mapper/vg_f13-lvroot rd_LVM_LV=vg_f13/lvroot rd_LVM_LV=vg_f13/lvswap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=fi rhgb quiet<br />
initrd /initramfs-2.6.33.6-147.2.4.fc13.x86_64.img<br />
title Fedora (2.6.33.3-85.fc13.x86_64)<br />
root (hd0,0)<br />
kernel /vmlinuz-2.6.33.3-85.fc13.x86_64 ro root=/dev/mapper/vg_f13-lvroot rd_LVM_LV=vg_f13/lvroot rd_LVM_LV=vg_f13/lvswap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=fi rhgb quiet<br />
initrd /initramfs-2.6.33.3-85.fc13.x86_64.img<br />
title Fedora Xen 4.0 with Linux 2.6.32.25 pvops dom0<br />
root (hd0,0)<br />
kernel /xen.gz dom0_mem=1024M loglvl=all guest_loglvl=all<br />
module /vmlinuz-2.6.32.25 ro root=/dev/mapper/vg_f13-lvroot nomodeset<br />
module /initramfs-2.6.32.25.img<br />
</pre><br />
<br />
Note the last entry: The kernel you're booting is actually Xen, and we're using the 'module' keywords to tell Xen to start the actual kernel and initrd once Xen starts up.<br />
<br />
Important: Make sure the "root=/dev/something/here" parameter matches what you have for the normal Fedora kernel entries! If they don't match, '''your system will not boot'''.<br />
<br />
Finally, verify that Xen services/daemons are properly configured to start automatically:<br />
<br />
<pre><br />
# chkconfig --list | grep xen<br />
xenconsoled 0:off 1:off 2:off 3:on 4:on 5:on 6:off<br />
xend 0:off 1:off 2:off 3:on 4:on 5:on 6:off<br />
xendomains 0:off 1:off 2:off 3:on 4:on 5:on 6:off<br />
xenstored 0:off 1:off 2:off 3:on 4:on 5:on 6:off<br />
</pre><br />
<br />
And now you're ready to reboot into Xen.<br />
<br />
<pre><br />
# reboot<br />
</pre><br />
<br />
Remember: '''When the system restarts select the Xen entry from Grub boot menu!''' We haven't changed the default grub entry yet.<br />
<br />
== Verifying the Xen setup after reboot ==<br />
When your system is done rebooting log in as root and run the following commands to verify everything is working properly.<br />
<br />
Check that the Xen hypervisor is running by asking it for information:<br />
<br />
<pre><br />
[root@f13 ~]# xm info<br />
host : f13.localdomain<br />
release : 2.6.32.25<br />
version : #3 SMP Sat Oct 30 15:24:53 EEST 2010<br />
machine : x86_64<br />
nr_cpus : 4<br />
nr_nodes : 1<br />
cores_per_socket : 4<br />
threads_per_core : 1<br />
cpu_mhz : 2826<br />
hw_caps : bfebfbff:20100800:00000000:00000940:0408e3fd:00000000:00000001:00000000<br />
virt_caps : hvm<br />
total_memory : 8190<br />
free_memory : 7076<br />
node_to_cpu : node0:0-3<br />
node_to_memory : node0:7076<br />
node_to_dma32_mem : node0:3259<br />
max_node_id : 0<br />
xen_major : 4<br />
xen_minor : 0<br />
xen_extra : .1<br />
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64<br />
xen_scheduler : credit<br />
xen_pagesize : 4096<br />
platform_params : virt_start=0xffff800000000000<br />
xen_changeset : unavailable<br />
xen_commandline : dom0_mem=1024M loglvl=all guest_loglvl=all<br />
cc_compiler : gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)<br />
cc_compile_by : root<br />
cc_compile_domain :<br />
cc_compile_date : Sat Oct 16 00:13:54 EEST 2010<br />
xend_config_format : 4<br />
</pre><br />
<br />
Check the list of running domUs:<br />
<br />
<pre><br />
# xm list<br />
Name ID Mem VCPUs State Time(s)<br />
Domain-0 0 1017 4 r----- 23.1<br />
</pre><br />
<br />
Make sure the "Mem" field for Domain-0 is around the same amount that you specified in grub.conf in "dom0_mem" parameter.<br />
<br />
Finally, check the dom0 Linux kernel version:<br />
<br />
<pre><br />
# uname -a<br />
Linux f13.localdomain 2.6.32.25 #3 SMP Sat Oct 30 15:24:53 EEST 2010 x86_64 x86_64 x86_64 GNU/Linux<br />
</pre><br />
<br />
The basic setup is now done. You should now go back to the grub menu file and change the <code>default=0</code> line to read <code>default=2</code> (or whatever line your new entry is at) to automatically boot into Xen.<br />
<br />
== Installing libvirtd and graphical virt-manager ==<br />
If you want to install new Xen guests (virtual machines) with the graphical virt-manager GUI, install it like this:<br />
<br />
<pre><br />
# yum install virt-manager libvirt virt-viewer<br />
</pre><br />
<br />
Note that libvirt (libvirtd) is also required for text-based guest VM network installations!<br />
<br />
Verify "libvirtd" is set to automatically start so the "virbr0" bridge nat/dhcp service provided by dnsmasq works ok for guest (vm) network installations. Also start it now:<br />
<br />
<br />
<pre><br />
# chkconfig --list libvirtd<br />
libvirtd 0:off 1:off 2:off 3:on 4:on 5:on 6:off<br />
<br />
# /etc/init.d/libvirtd start<br />
<br />
</pre><br />
<br />
Verify there's the "virbr0" bridge and "dnsmasq" process running:<br />
<br />
<br />
<pre><br />
# brctl show<br />
bridge name bridge id STP enabled interfaces<br />
virbr0 8000.000000000000 yes<br />
<br />
# ps aux | grep -i dnsmasq<br />
nobody 1966 0.0 0.0 12784 708 ? S 23:27 0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --listen-address 192.168.122.1 --except-interface lo --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-lease-max=253<br />
</pre><br />
<br />
Verify the IP settings libvirtd/dnsmasq configured for the "virbr0" network interface:<br />
<br />
<br />
<pre><br />
# ifconfig virbr0<br />
virbr0 Link encap:Ethernet HWaddr 12:57:62:0E:3F:9E<br />
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0<br />
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br />
RX packets:0 errors:0 dropped:0 overruns:0 frame:0<br />
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0<br />
collisions:0 txqueuelen:0<br />
RX bytes:0 (0.0 b) TX bytes:933 (933.0 b)<br />
</pre><br />
<br />
Also verify libvirtd/dnsmasq has added the required iptables NAT rule ("MASQUERADE") to enable Internet access from the virbr0 bridge:<br />
<br />
<br />
<pre><br />
# iptables -t nat -L -n -v<br />
Chain PREROUTING (policy ACCEPT 23 packets, 5301 bytes)<br />
pkts bytes target prot opt in out source destination<br />
Chain POSTROUTING (policy ACCEPT 116 packets, 8764 bytes)<br />
pkts bytes target prot opt in out source destination<br />
0 0 MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24<br />
Chain OUTPUT (policy ACCEPT 116 packets, 8764 bytes)<br />
pkts bytes target prot opt in out source destination<br />
</pre><br />
<br />
And that IP forwarding (routing) is enabled:<br />
<br />
<br />
<pre><br />
# cat /proc/sys/net/ipv4/ip_forward<br />
1<br />
</pre><br />
<br />
Note that to run the graphical virt-manager you don't have to run X server on the Xen system (dom0), you can run virt-manager in dom0 but tunnel the X11 GUI over ssh and display the graphical tools on your remote workstation/laptop!<br />
<br />
== Using ssh X11 forwarding ==<br />
Install "xorg-x11-xauth" on your Fedora 13 Xen system to be able to use X11 forwarding over ssh session from your desktop/laptop:<br />
<br />
<br />
<pre><br />
# yum install xorg-x11-xauth<br />
</pre><br />
If you're connecting from a Linux workstation/laptop enable ssh X11 forwarding like this:<br />
<br />
<br />
<pre><br />
# ssh -X root@<f13_host_ip><br />
</pre><br />
<br />
If you're using Putty on Windows you need to enable X11 forwarding in Putty settings, and also install X-server to Windows, such as Xming, and start it before trying to run graphical applications from ssh session.<br />
<br />
This is what you should see when logging in for the first time with ssh, when X11 forwarding is enabled in your ssh client. Note the ssh server system (Fedora 13 Xen host) needs to have "xorg-x11-xauth" rpm package installed:<br />
<br />
<br />
<pre><br />
Last login: Mon Aug 23 21:50:49 2010 from <your_workstation_ip><br />
/usr/bin/xauth: creating new authority file /root/.Xauthority<br />
</pre><br />
<br />
Now you can run graphical (X11) applications and the GUI will be displayed on your local workstation/laptop X, tunneled over the secure ssh connection. Try running "virt-manager", or any other graphical (X11) tool as an example.<br />
<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
[[Category:Tutorial]]<br />
[[Category:Xen]]<br />
[[Category:Host Install]]<br />
[[Category:Fedora]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Dom0_Kernel_Versions&diff=5089Dom0 Kernel Versions2012-09-24T13:28:38Z<p>OliverChick: /* Ubuntu */ Update to 12.04</p>
<hr />
<div>This page lists the dom0 kernel versions that are known to exist for various distributions. Kept here for info if people are using older distributions. This was extracted from [[Dom0_Kernels_for_Xen]].<br />
= Debian =<br />
* Debian 4.0 ("Etch") contains 2.6.18 Xen dom0 kernel.<br />
* Debian 5.0 ("Lenny") contains 2.6.26 Xen dom0 kernel based on early version of OpenSUSE forward-ported patches. Some users have experienced stability problems with this kernel, when used with newer Xen 3.3 and 3.4 hypervisors. Also, some users have reported live migrations being broken with this lenny's kernel.<br />
* Debian 6.0 ("Squeeze") contains a pv_ops Xen dom0 kernel<br />
Also see [http://wiki.debian.org/Xen|the official Debian Xen page]<br />
<br />
= Fedora =<br />
Now that dom0 kernel support has entered the upstream kernel, [http://fedoraproject.org/ Fedora] 16 (and later) supports Xen out of the box. <br />
<br />
'''Obsolete information: This is relevant for Fedora 15 and lesser'''<br />
Fedora 9 - 15 do not contain Xen dom0 kernels (but they do contain Xen hypervisor and tools and Xen domU enabled kernels). If you are running Fedora 15 or earlier you can find [http://fedorapeople.org/~myoung/dom0/ third party rpm packages built for you by M A Young] (they require Xen >= 4.0).<br />
* Also see [[Fedora13Xen4Tutorial|Fedora 13/14 Xen 4.0 Tutorial]] and [http://fedoraproject.org/wiki/Features/XenPvopsDom0|Fedora's Xen Dom0 page]<br />
<br />
= Gentoo =<br />
Gentoo has multiple dom0 kernels available: xen.org-based 2.6.18 (latest is xen-sources-2.6.18-r12) and rebased kernels with OpenSUSE patches (latest is xen-sources-2.6.31-r11). (Note: Old, outdated info)<br />
<br />
= Red Hat Enterprise Linux and CentOS =<br />
The last release of [http://www.redhat.com/rhel RHEL] (and by extension [http://www.centos.org/ CentOS] and other derivatives) to include a Xen dom0 kernel was RHEL 5. We are currently working with the community to provide dom0 kernel packages for RHEL 6.<br />
<br />
RHEL 5:<br />
* Includes Xen dom0 kernel based on Linux 2.6.18, with a lot of patches and fixes by Redhat. RH has also backported a lot of drivers and support for new hardware and features.<br />
* Known to be very stable, but doesn't support latest Xen features<br />
* Is known to work with Xen 3.4.x hypervisors (http://gitco.de/repo/), and of course with the official RHEL5 Xen 3.1.2 hypervisor.<br />
* Available in kernel-2.6.18-*.el5.src.rpm from: [ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/]<br />
* RHEL 5.4 ships with kernel-2.6.18-164.*.el5.src.rpm<br />
* RHEL 5.5 ships with kernel-2.6.18-194.*.el5.src.rpm<br />
<br />
* Good choice as dom0 because RHEL5 has long lifecycle, and it's actively maintained and bugfixed.<br />
* Good choice because it's tested and certified to run on many vendors server hardware.<br />
* Good choice especially if you are trying out Xen virtualization for the first time, and want to use a distribution that has well working and tested Xen included.<br />
* Also see [[RHEL6Xen4Tutorial|Redhat Enterprise Linux 6 Xen 4.0 Tutorial]]<br />
<br />
= Oracle VM =<br />
Uses modified Oracle Linux 5 Dom0 kernels<br />
* Oracle VM 2.1 and 2.2 use 2.6.18-based kernels<br />
* Oracle VM 3.0 uses a 2.6.32-based kernel, derived from the Oracle Unbreakable Enterprise Kernel for Oracle Linux 5<br />
<br />
= OpenSUSE =<br />
Novell is forward-porting the original Xenlinux 2.6.18 patches for new kernels in OpenSUSE (and SLES). Currently (as of November 2011) patches and Xen dom0 kernel packages exist up to Linux 3.1.<br />
* OpenSUSE 11.2 ships with Linux 2.6.31 based Xen kernel using the forward-ported Xenlinux patches.<br />
* OpenSUSE 11.3 ships with Linux 2.6.34 based Xen kernel using the forward-ported Xenlinux patches.<br />
* OpenSUSE 11.4 ships with Linux 2.6.37 based Xen kernel using the forward-ported Xenlinux patches.<br />
* OpenSUSE 12.1 ships with Linux 3.1 based Xen kernel using the forward-ported Xenlinux patches.<br />
* OpenSUSE kernel factory: http://download.opensuse.org/repositories/Kernel:/HEAD/openSUSE_Factory/<br />
<br />
= SuSE Linux Enterprise (SLES) =<br />
SLES10 and SLES11 contain Xen dom0 kernels.<br />
* SLES10 is based on Linux 2.6.16.<br />
* SLES11 is based on Linux 2.6.27 with forward-ported original Xenlinux 2.6.18 patches.<br />
* SLES11 SP1 ships with a Linux 2.6.32 dom0 kernel based on the forward-ported Xenlinux patches.<br />
* Good choice as dom0 because SLES releases have long lifecycle and they are actively maintained and bugfixed, and it's tested and certified to run on many vendor's server hardware.<br />
<br />
= Ubuntu =<br />
Ubuntu 12.04 has a 3.2 Linux kernel, which can be used as a dom0 kernel.<br />
<br />
= XCP =<br />
XCP (Xen Cloud Platform) uses the Citrix [[XenServer]] kernel as is. Up to and including XCP v0.5, the kernel's been based on 2.6.27<br />
More information about XCP is available here: [http://www.xen.org/products/cloudxen.html]<br />
<br />
Building the kernel:<br />
* Available from the mercurial patch queue and in kernel-dom0 directory in source-1.iso from: http://www.xen.org/products/cloud_source.html<br />
* XCP dom0 2.6.27 kernel patch queue mercurial repository: http://xenbits.xen.org/XCP/linux-2.6.27.pq.hg<br />
* XCP dom0 2.6.32 kernel patch queue mercurial repository: http://xenbits.xen.org/XCP/linux-2.6.32.pq.hg<br />
<br />
= XCI =<br />
Based on [[XenServer]] 2.6.27 kernel, with XCI specific patches and modifications.<br />
<br />
Building the kernel:<br />
* See this mail for some building related information (June 2009): http://lists.xensource.com/archives/html/xen-devel/2009-06/msg00259.html<br />
* XCI project page with more information: http://www.xen.org/products/xci.html<br />
* XCI source including build instructions: http://www.xen.org/products/xci_source.html</div>OliverChickhttps://wiki.xenproject.org/index.php?title=CD_Rom_Support_in_Xen&diff=5088CD Rom Support in Xen2012-09-24T13:24:49Z<p>OliverChick: Updated xml to xl</p>
<hr />
<div><!-- MoinMoin name: XenCdrom --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: XenCdrom --><br />
<!-- Page revision: 00000002 --><br />
<!-- Original date: Fri Aug 8 02:52:33 2008 (1218163953000000) --><br />
<br />
'''CDROM Support under Xen Guests'''<br />
<br />
<!-- ! TOC here --><br />
<br />
This page will give some information about CDROM support under Xen guests.<br />
<br />
= PV Guest =<br />
<br />
Currently, there's no paravirtual CDROM driver available. So in PV guest, you can only add a iso image as a disk and cannot change this disk at runtime. But as a workaround, you can detach it and re-attach another iso as the same frontend.<br />
<br />
= HVM Guest =<br />
<br />
== Adding CDROM to Guest ==<br />
<br />
To add a physical CDROM drive or iso file as CDROM, you need to append ":cdrom" suffix to the target device name. Eg.<br />
<pre><nowiki><br />
disk = ['phy:/dev/hdc,hdc:cdrom,r']<br />
disk = ['file:/test.iso,hdc:cdrom,r']<br />
disk = ['phy:/dev/null,hdc:cdrom,r']<br />
disk = [',hdc:cdrom,r']<br />
</nowiki></pre><br />
<br />
<br />
== Change CDROM for a running guest ==<br />
<br />
If you attached a physical CDROM drive, the CDROM media in the guest will change automatically when you change it physically.<br />
<br />
If it doesn't change, execute the following command in Dom0:<br />
<pre><nowiki><br />
# xl block-configure [DomID] phy:/dev/hdc hdc:cdrom r<br />
</nowiki></pre><br />
or: <br />
<pre><nowiki><br />
# xl block-configure [DomID] file:/test.iso hdc:cdrom r<br />
</nowiki></pre><br />
if you want to bind an iso to a CDROM.<br />
<br />
If you are using the SDL viewer, Inside the VM press the following key combination to get into the monitor:<br />
<br />
<pre><nowiki><br />
Ctrl-Alt-2<br />
</nowiki></pre><br />
<br />
And then use the following command to eject the CDROM:<br />
<br />
<pre><nowiki><br />
eject hdc [return]<br />
</nowiki></pre><br />
<br />
Now you should be able to eject the cd manually, and put in a different CD. Then type the following command to change CDROM for the guest:<br />
<br />
<pre><nowiki><br />
change hdb /dev/hdc [return]<br />
</nowiki></pre><br />
<br />
To get back to the VM gui, press:<br />
<br />
<pre><nowiki><br />
Ctrl-Alt-1<br />
</nowiki></pre><br />
<br />
The new disk should be ready for mounting.<br />
<br />
== Booting from CDROM ==<br />
<br />
To boot from CDROM, add config parameter "boot=c" to the vm configure file.<br />
<br />
= Troubleshooting =<br />
<br />
* Under certain circumstance, using /dev/cdrom, which is a symbol link to the actual device, doesn't work.<br />
<br />
[[Category:Xen]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
[[Category:Overview]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=XenParavirtOps&diff=5085XenParavirtOps2012-09-24T12:20:05Z<p>OliverChick: /* Update services */ Don't start xend on boot - it has been deprecated after all</p>
<hr />
<div><!-- MoinMoin name: XenParavirtOps --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: XenParavirtOps --><br />
<!-- Page revision: 00000206 --><br />
<!-- Original date: Sat Oct 29 12:50:21 2011 (1319892621000000) --><br />
<br />
<!-- ! TOC here --><br />
<br />
== What is paravirt_ops? ==<br />
paravirt_ops (pv-ops for short) is a piece of Linux kernel infrastructure to allow it to run paravirtualized on a hypervisor. It currently supports VMWare's VMI, Rusty's lguest, and most interestingly, Xen.<br />
<br />
The infrastructure allows you to compile a single kernel binary which will either boot native on bare hardware (or in hvm mode under Xen), or boot fully paravirtualized in any of the environments you've enabled in the kernel configuration, and lately also as Xen dom0.<br />
<br />
It uses various techniques, such as binary patching, to make sure that the performance impact when running on bare hardware is effectively unmeasurable when compared to a non-paravirt_ops kernel.<br />
<br />
At present paravirt_ops is available for x86_32, x86_64 and ia64 architectures.<br />
<br />
'''Dom0''' means the first guest that Xen boots. It usually (mostly always) is the one that has the driver support. The other guests that are booted (HVM or PV) are called '''DomU'''.<br />
<br />
== Current state in Linux kernel and in distributions ==<br />
<br />
['''Updated Oct 26th 2011''']<br />
<br />
Linux 3.0 (and later) can run as guest (domU) and as host (dom0). All necessary backends (and frontends) are in the upstream kernel. Look in [[#Roadmap|Roadmap]] in the features section to get an idea what is happening in next kernel releases.<br />
<br />
You can also visit the [[#History_timeline|history]] section on the story of pvops. <br />
<br />
Starting with Linux v2.6.37 dom0 support was added and with 3.0 having the necessary backend drivers.<br />
[http://fedoraproject.org/wiki/Features/XenPvopsDom0 Fedora Core 16] and [https://wiki.ubuntu.com/OneiricOcelot/ Ubuntu 11.10] ship with the 3.0 kernel (or later) and the user just needs to install the hypervisor:<br />
<br />
<pre><nowiki><br />
$yum install xen<br />
</nowiki></pre><br />
<br />
<br />
<pre><nowiki><br />
$apt-get install xen<br />
</nowiki></pre><br />
<br />
TODO: Verify the Ubuntu<br />
<br />
Then reboot the machine and select '''Xen''' in the GRUB(2) menu. Also consult<br />
[[:Category:FAQ]] and [[XenCommonProblems]]<br />
<br />
== Are there other distributions that have a Xen dom0 kernels available? ==<br />
Yes. See this wiki page for more information: [[XenDom0Kernels]] and [[XenKernelFeatures]]<br />
<br />
== Help! I am having troubles ==<br />
{{Anchor|troubleshooting}}<br />
<br />
First of, did you look in [[:Category:FAQ]] and [[XenCommonProblems]] wiki page?<br />
<br />
Did not find anything relevant? Was it any of these:<br />
<br />
=== I have graphics card (DRM/TTM/KMS/Xorg) related problems with the pv_ops dom0 kernel.. ===<br />
<br />
Screen looks like a checker-board? See errors from the Radeon|Nouveau driver? If so<br />
please see the [[XenPVOPSDRM]] wiki page.<br />
<br />
=== Dom0 console gets all weird and corrupted in the end of the boot process ===<br />
<br />
Is the last line on the console something like ''Setting console screen modes and fonts'' ? Then you might want to disable "console-screen.sh" service from starting automatically and it should workaround the problem.<br />
<br />
=== Dom0 console doesn't show any output and remains blank ===<br />
Unfortunately, a patch that enables the xen dom0 kernel to use the VGA text console didn't made it into initial release of Linux 3.0.0. This patch was merged into Linux 3.1.0 and also to 3.0.2 stable update.<br />
<br />
=== Maybe it is something obvious? How do I make the bootup more verbose? ===<br />
<br />
If you do encounter problems, then getting as much information as possible is very helpful. If the domain crashes very early, before any output appears on the console, then booting with: ''earlyprintk=xen'' should provide some useful information. Note that ''earlyprintk=xen'' only works for domU/dom0 if you have Xen hypervisor built in debug mode! If you are running a debug build of Xen hypervisor (set "debug = y" in Config.mk in the Xen source tree), then you should get crash dumps on the Xen console. You can view those with "xm dmesg". Also, CTRL+O can be used to send [[SysRq]] (not really specific to pv_ops, but can be handy for kernel debugging).<br />
<br />
==== OK, how do I add ''earlyprintk=xen'' and all that? ====<br />
<br />
Edit /boot/grub/grub.conf (or /boot/grub2/grub.cfg) and make sure you have a correct grub entry to boot Xen hypervisor with dom0 kernel.<br />
<br />
In grub.conf it's a good idea to enable all the logging options for Xen: '''loglvl=all guest_loglvl=all sync_console console_to_ring''' and for Linux pv_ops dom0 kernel: '''earlyprintk=xen debug loglevel=8''', and set up a serial console to be able to see and capture the full boot messages from Xen and from dom0 kernel, in the case system doesn't start up properly or crashes.<br />
<br />
For the full list of Xen bootup options, look in [[XenHypervisorBootOptions]]<br />
Here is an example:<br />
<br />
<br />
<pre><nowiki><br />
title pv_ops dom0 debug (2.6.32.27) with serial console<br />
root (hd0,0)<br />
kernel /xen-4.0.gz dom0_mem=1024M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1 console=com1 lapic=debug apic_verbosity=debug apic=debug iommu=off<br />
module /vmlinuz-2.6.32.27 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset initcall_debug debug loglevel=10<br />
module /initrd-2.6.32.27.img</nowiki></pre><br />
<br />
<br />
==== I got a funky serial console (IPMI/AMT, etc) - Is there more information available how to debug and troubleshoot using a serial console? ====<br />
<br />
For debugging and testing you should be using a computer with a built-in serial port on the motherboard (com1), or add a PCI serial card if your motherboard lacks a built-in serial port. You can also use SOL (Serial Over Lan) for logging the Xen hypervisor and dom0 kernel messages. Most server-class machines have SOL available through their management processor or IPMI. SOL device looks like a normal serial port for the OS/Xen, but enables you to connect to the serial console over a network, through the management processor.<br />
<br />
For more details (and examples) please see [[XenSerialConsole]] wiki page.<br />
<br />
=== Nothing is helping! Help!! ===<br />
<br />
Before submitting bugreports to xen-devel mailinglist please read:<br />
<br />
* [http://wiki.xensource.com/xenwiki/Linux_30_bugs Linux 3.0 and further bugs] that we are aware of and working on.<br />
* This wiki page: [[XenParavirtOpsHelp]] . It lists all the information you '''NEED''' to provide so the problem can be diagnosed and debugged!<br />
<br />
Please mail questions/answers/patches/etc to the [http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel Xen-devel mailing list].<br />
<br />
== Roadmap ==<br />
<span id="Roadmap"></span><br />
<br />
=== Status updates: ===<br />
<br />
* Jeremy's view of the status of pv_ops dom0 kernel (June 2009): http://lists.xensource.com/archives/html/xen-devel/2009-06/msg01193.html<br />
* Jeremy's roadmap update (August 2009): http://lists.xensource.com/archives/html/xen-devel/2009-08/msg00510.html<br />
* Jeremy's status update (September 2009): http://lists.xensource.com/archives/html/xen-devel/2009-09/msg00806.html<br />
* Presentation by Jeremy about pv_ops dom0 kernel at Xen Summit Asia 2009 (November 2009): http://www.xen.org/files/xensummit_intel09/xensummit-asia-2009-talk.pdf<br />
* Short update (03 December 2009): http://lists.xensource.com/archives/html/xen-devel/2009-12/msg00190.html<br />
* Status update (22 December 2009): http://lists.xensource.com/archives/html/xen-devel/2009-12/msg01127.html<br />
* Status update (03 March 2010): http://lists.xensource.com/archives/html/xen-devel/2010-03/msg00162.html<br />
* Status update from Xen Summit 2010 NA (April 2010): http://www.slideshare.net/xen_com_mgr/xen-summit-amdpvopsupdate4<br />
* Status update from Xen Summit 2011 NA (August 2011): http://xen.org/files/xensummit_santaclara11/aug2/5_KonradW_Update_on_Linux_PVOPS.pdf<br />
<br />
=== Work in progress for 3.6 ===<br />
<br />
* kdump/kexec (GSoC project: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/dkiper/1001). The patches to the kexec-tools have been accepted. The patches to the Linux kernel need another pass for upstream acceptance.<br />
<br />
<br />
And naturally fixing bugs: [http://wiki.xensource.com/xenwiki/Linux_30_bugs Linux 3.0 and further] has the list of the ones we are aware and working on.<br />
<br />
=== Work in the future ===<br />
<br />
Future work queued up. In general you want to stick with issues in the [[XenDevelopmentProjects]] wiki page, but here are some add-ons:<br />
<br />
* pcifront: turn SWIOTLB when PCI devices are hot-plugged. There is code in lib/swiotlb.c that can allocate the SWIOTLB pool after early_bootmem.It is currently only used by IA64, but there should be no trouble extending it to be used under X86. It would allow us to have xen-pcifront automatically turn on SWIOTLB if it detects anything on the PV ring.<br />
* fix balloon target driver to have a logarithmic scale of hitting the 'target'. Dan and Jan talked about it and Jan posted a patch for this some time ago. http://lists.xensource.com/archives/html/xen-devel/2008-04/msg00143.html and http://lists.xensource.com/archives/html/xen-devel/2010-06/msg01076.html<br />
* netfront support skb coalescing. Borrow the ideas from Netchannel2 to coalesce the SKB's so that the backend does not have to jump all over the memory and instead can easily fetch the pages in a physical contingous manner.<br />
* Add EFI support in Linux pv-ops. Jan Beulich wrote patches to make Xen hypervisor be able to compile as an EFI application. "Build xen.efi, write up a config file for it to read (most importantly so it knows what Dom0 kernel and initrd to use), and you should be good to go (provided the EFI implementation isn't too flawed). This being an EFI application you can simply run it from the shell prompt. Parameter for Xen.efi is -cfg <file>, and <file> has: kernel=, ramdisk=, options=, video=gfx-x. The Linux pv-ops needs at least to parse XEN_VGATYPE_EFI_LFB data, E820 parsed (should be working) and give the ACPI subsystem a pointer to the ACPI DSDT without consulting EBDA.<br />
* microcode update. Jeremy wrote one http://oss.oracle.com/git/kwilk/xen.git/p=kwilk/xen.git;a=commit;h=0a49ceea0d032864a72a8744c82c3786a01f34f4 but sadly the upstream maintainer (Borislav, https://lkml.org/lkml/2011/1/30/108) was not too keen. He was thinking of making grub do the microcode update, but that sounds to have run afoul of what Ingo [x86 maintainer] thinks (http://mid.gmane.org/20110525193601.GE17864@elte.hu) in a different thread.<br />
* MTRR support. Usually this is used for graphics cards, but the 10G Myantic drivers do enable it on their PCIe MMIO space to speed up performance (sets it to Write Combine). We need to implement (or perhaps backport from 2.6.18) the Xen MTRR code.<br />
* remove VM_IO vesitages. Linux 3.0 has dropped most of the _PAGE_IOMAP code. There is one usage left in xen_make_pte and it should be redo to do proper M2P and P2M without consulting the _PAGE_IOMAP flag. Potentially remove the _PAGE_IOMAP usage in the 1-1 phys code. _PAGE_IOMAP used by mmap batches code to map foreign patches. Can be done with M2P override perhaps? The PAGE_IOMAP was used to say MFN==PFN. The outstanding issue is with xenfs doing hypercall on the behest of the tools - specifically mapping memory and providing the MFN value.<br />
* Device hotplug (MODULE_ALIAS) - missing for Xen PCI backend<br />
* Suspend event channel support for faster checkpointing in Remus FT.<br />
<br />
== Changelog ==<br />
<span id="changelog"></span><br />
<br />
* Features in 2.6.26:<br />
** x86-32 support<br />
** SMP<br />
** Console (hvc0)<br />
** Blockfront (xvdX)<br />
** Netfront<br />
** Balloon (reversible contraction only)<br />
** paravirtual framebuffer + mouse (pvfb)<br />
** 2.6.26 onwards pv domU is PAE-only (on x86-32)<br />
* Features added in 2.6.27:<br />
** x86-64 support<br />
** Save/restore/migration<br />
** Further pvfb enhancements<br />
* Features added in 2.6.28:<br />
** ia64 (itanium) pv_ops xen domU support<br />
** Various bug fixes and cleanups<br />
** Expand Xen blkfront for > 16 xvd devices<br />
** Implement CPU hotplugging<br />
** Add debugfs support<br />
* Features added in 2.6.29:<br />
** bugfixes<br />
** performance improvements<br />
** swiotlb (required for dom0 support)<br />
* Features added in 2.6.30:<br />
** bugfixes.<br />
* Features added in 2.6.31:<br />
** bugfixes.<br />
* Features added in 2.6.32:<br />
** bugfixes.<br />
* Features added in 2.6.33:<br />
** bugfixes.<br />
** save/restore/migration bugfixes. These bugfixes can also be found from the 2.6.32.10 update.<br />
* Features added in 2.6.34:<br />
** bugfixes.<br />
* Features added in 2.6.35:<br />
** bugfixes.<br />
* Features added in 2.6.36:<br />
** Xen-SWIOTLB (required for Xen PCI frontend driver and Xen dom0 support).<br />
** Xen PV-on-HVM optimized paravirtualized drivers for fully virtualized (HVM) guest VMs.<br />
** Xen VBD (Virtual Block Device) online dynamic resize support for resizing guest disks (xvd*) on-the-fly.<br />
* Features added in 2.6.37:<br />
** Core Xen dom0 support (no backend drivers yet).<br />
** Xen PCI frontend driver required for Xen PCI Passthru to PV guest/domU.<br />
** Enhanced PV-on-HVM drivers: pirq remappings. Deliver IRQs as Xen event channels for better performance. Requires Xen 4.1 (or newer) hypervisor.<br />
* Features added in 2.6.38:<br />
** Generic Xen dom0 backend bits, required by all xen backend drivers.<br />
** xen-gntdev driver (grant device).<br />
** Bugfixes.<br />
* Features added in 2.6.39:<br />
** xen-netback backend driver to be used in dom0 to serve virtual networks to VMs. Currently unoptimized, optimizations will be added in later kernel versions.<br />
** Many dom0 related bugfixes and improvements.<br />
** PV-on-HVM driver fixes and improvements (xen balloon driver and PV spinlocks support for HVM guests).<br />
** xen-gntalloc driver for userspace grant allocation between Xen domains.<br />
** xen-gntdev support for HVM guests.<br />
** Xen watchdog driver.<br />
** 1-1 identity mapping in P2M. Allows us to automatically figure out if a page is for an I/O hole or not based on the E820. Fixes some device drivers.<br />
** IRQ code rework to support dynamic IRQs so that we're not limited to running 155 VMs.<br />
** Balloon driver has been prepared for memory hotplug and gntalloc.<br />
** save/restore bugfixes.<br />
** Dom0 startup crash fix when certain CONFIG_ options were set.<br />
** Bug fixes in xen-kbdfront, xen-netfront, xen-pcifront, and xen-blkfront.<br />
** Handling of guest events is now round-robin, fixes starvation issue of later guests not having their services served.<br />
** Many cleanups and bugfixes.<br />
* Features added in 3.0:<br />
** xen-blkback backend driver to be used in dom0 to serve virtual block devices (disks) to VMs.<br />
** Bugfixes and cleanups.<br />
** In 3.0.2: Enable use of vga text console in Xen dom0.<br />
* Features added in 3.1:<br />
** xen-pciback backend driver to be used in dom0 to support PCI passthru to VMs.<br />
** support for VGA text console in dom0.<br />
** memory hotplug support for xen balloon driver (allows adding more memory to the VM online / on-the-fly).<br />
** self-balloon driver to decrease memory in the guest and make the swap pages be shuffled by tmem to be compressed/shared/etc.<br />
** tmem driver to shuffle file-system and swap pages between guests as appropiate. <br />
** Xen PCI glue code cleanup.<br />
** Xen MMU debugfs tracing API support.<br />
** blkback providing completion latency that follows the hardware's completion latency.<br />
* Features added in 3.2:<br />
** blkback emulating the 'feature-barrier' option.<br />
** blkback providing TRIM/DISCARD operations ('feature-discard')<br />
** syncing wall clock time from Dom0 to hypervisor<br />
* Features added in 3.3:<br />
** Support v2 of granttables<br />
** /dev/xen/privcmd is now usuable instead of /proc/xen/privcmd<br />
** network backend can work in HVM<br />
** PCI graphic cards (ATI ES1000 for example) work now.<br />
** Multiple fixes in blkback, blkfront, xenbus, etc<br />
** PIRQ MFN bitmap is supported (meaning IRQ ack are done faster)<br />
* Features added in 3.4:<br />
** 'xenpm' works now if the xen-acpi-processor is loaded. The Xen ACPI processor is the driver that uploads ACPI power management data to the hypervisor.<br />
** blkback backend can work in HVM<br />
** pciback can do FLR, multiple fixes added<br />
** PV console works in HVM<br />
* Features added in 3.5:<br />
** Many performance enhancements (fewer MSR traps on AMD)<br />
** APIC IPI interface support, enabling the 'perf' tool in dom0<br />
** Additional HVM driver domain support<br />
** Memory reporting improvements<br />
<br />
== I want to build the Xen/paravirt_ops components myself ==<br />
<br />
=== Novice ===<br />
<br />
If you are using a 3.0 kernel or later, you already have it working and there is no need to compile a new kernel - unless you feel adventurous.<br />
<br />
=== Expert ===<br />
<br />
The top level view is that you need to:<br />
<br />
# Get a current kernel. The [[#stable_version|latest kernel.org kernel]] is generally a good choice. Or you can use the [[#dev_version|development version]].<br />
# Configure as normal; you can start with your current .config file or use ''make defconfig''.<br />
# Then [[Mainline_Linux_Kernel_Configs|configure .config Xen options]]<br />
# [[#build_kernel|Build the kernel]]<br />
# Update [[#configure_modules]] modules (optional)<br />
# [[#build_xen|Build the Xen hypervisor]]<br />
# Update [[#configure_services|services]] (optional)<br />
# Update [[#configure_grub|GRUB1 or GRUB2]]<br />
# Reboot and [[#running|run it]]<br />
# [[#troubleshoot|Troubleshoot]] if necessary<br />
<br />
=== Getting the mainline Linux kernel ===<br />
<span id="build_linux_kernel"></span><br />
<br />
In order to get a proper Xen mainline kernel please check: [[Mainline_Linux_Kernel_Configs]] .<br />
<br />
=== Build Xen ===<br />
<span id="build_xen"></span><br />
<br />
=== Xen requirements for using pv_ops dom0 kernel ===<br />
<span id="xen_requirements_for_pvops"></span><br />
<br />
Xen hypervisor and tools need to have support for pv_ops dom0 kernels. In general it means:<br />
<br />
* The ability for the Xen hypervisor to load and boot bzImage pv_ops dom0 kernel.<br />
* The ability for the Xen tools to use the sysfs memory ballooning support provided by pv_ops dom0 kernel.<br />
* Current recommended 2.6.32.x version of pvops dom0 kernel requires new IOAPIC setup hypercall from Xen hypervisor.<br />
'''This means you need to have at least Xen version 4.0.1.'''<br />
<br />
Using older Xen versions is known to be problematic, for example Xen 4.0.0 libraries have problems with recent 2.6.32.x kernels, making xend fail to start due to evtchn/gntdev device node creation issues. Using Xen 3.4.2 or older won't work at all, since old hypervisor versions lack the new required IOAPIC setup hypercall and boot will fail with IRQ related issues.<br />
<br />
It's recommended to run the latest Xen 4.0.x version, at least Xen 4.0.1.<br />
<br />
=== Which kernel image to boot as dom0 kernel from your custom built kernel source tree? ===<br />
<br />
If you have Xen hypervisor with bzImage dom0 kernel support, ie. xen 3.4 or later version, use "linux-2.6-xen/arch/x86/boot/bzImage" as your dom0 kernel (exactly the same kernel image you use for baremetal Linux).<br />
<br />
If you have Xen hypervisor without bzImage dom0 kernel support, ie. any official Xen release up to at least Xen 3.3.1, or most of the Xen versions shipped with Linux distributions (before 2009-03), use "linux-2.6-xen/vmlinux" as your dom0 kernel. (Note that "vmlinux" is huge, so you can also gzip it, if you want to make it a bit smaller).<br />
<br />
Also read the previous paragraphs for other requirements.<br />
<br />
Get your sources from the repository, something like this can be used but the exact path will change:<br />
<br />
<br />
<pre><nowiki><br />
$ cd /usr/src<br />
$ hg clone http://xenbits.xensource.com/xen-unstable.hg <br />
$ cd xen-unstable.hg<br />
$ sudo make xen<br />
$ sudo make tools<br />
$ sudo make install-xen<br />
$ sudo make install-tools<br />
</nowiki></pre><br />
<br />
<br />
If you encounter any error NOT related to deps report them to xen-devel, if you need help compiling you will find help in xen-users. At the end in dist folder you will find xen.gz follow that symlink to your real image.<br />
<br />
=== Update services ===<br />
<span id="configure_services"></span><br />
<br />
The Ubuntu way to register a service is this:<br />
<br />
<br />
<pre><nowiki><br />
$ sudo update-rc.d xendomains defaults 21 20<br />
</nowiki></pre><br />
<br />
For Red Hat use chkconfig<br />
<br />
For RC16 use systemctl:<br />
<br />
<pre><nowiki><br />
$ sudo systemctl start xenstored.service<br />
</nowiki></pre><br />
<br />
=== Other System Updates ===<br />
<br />
The XENFS and XEN_COMPAT_XENFS config options are needed for /proc/xen support. If CONFIG_XEN_DEV_EVTCHN is compiled as a module, make sure to load the xen-evtchn.ko module or xend will not start.<br />
<br />
You might also need to add a line to /etc/fstab. Xen 3.4.2 and newer automatically mount /proc/xen when /etc/init.d/xend is started, so no need to add xenfs mount entry to /etc/fstab on those systems:<br />
<br />
<br />
<pre><nowiki><br />
none /proc/xen xenfs defaults 0 0<br />
</nowiki></pre><br />
<br />
<br />
=== GRUB1 and GRUB2 (Booting) ===<br />
<span id="configure_grub"></span><br />
<br />
Working grub.conf example with VGA text console:<br />
<br />
<br />
<pre><nowiki><br />
title Xen 4.0, dom0 Linux kernel 2.6.32.24<br />
root (hd0,0)<br />
kernel /boot/xen-4.0.gz dom0_mem=512M<br />
module /boot/vmlinuz-2.6.32.24 root=/dev/sda1 ro nomodeset<br />
module /boot/initrd.img-2.6.32.24<br />
</nowiki></pre><br />
<br />
<br />
NOTE! You need to give correct root= parameter, ie. replace /dev/sda1 with your actual root device. Check your earlier grub kernel entries for the correct option. Also you need to have the "nomodeset" option for the time being. Check your earlier grub kernel entries for the correct option. Its good to look at your initial kernel boot configuration and use it as closely as possible, then modify the 40_custom file to suite your xen needs. Keep in mind that your initial kernel might not use the /dev/sdX it can use the UUID notation, well use it also.<br />
<br />
Here is the content extracted from grub.cfg for a Ubuntu/Fedora Core kernel using grub2:<br />
<br />
<br />
<pre><nowiki><br />
menuentry 'GNU/Linux, with Linux 2.6.38-8-generic' --class gnu-linux --class gnu --class os {<br />
recordfail<br />
set gfxpayload=$linux_gfx_mode<br />
insmod part_msdos<br />
insmod ext2<br />
set root='(/dev/sda,msdos2)'<br />
search --no-floppy --fs-uuid --set=root 016e7c8a-4bdd-4873-92dd-d71171a49d6d<br />
linux /boot/vmlinuz-2.6.38-8-generic root=UUID=016e7c8a-4bdd-4873-92dd-d71171a49d6d ro quiet splash vt.handoff=7<br />
initrd /boot/initrd.img-2.6.38-8-generic<br />
}<br />
</nowiki></pre><br />
<br />
Compare them and you will see the similarties, on this particular system the boot device is located in /dev/sda2 yet if used in grub the system will not boot. Insted GRUB uses the UUID schema to detect the devices, that way the root argument can be passed to the linux kernel image.<br />
<br />
Here is the contents of 40_customCompare them and you will see the similarities, on this particular system the boot device is located in /dev/sda2 yet if used in grub the system will not boot instead GRUB searches for the correct UUID and its is used in the kernel image, this can be easily detected when looking at the original ubuntu boot entry..<br />
<br />
Here is the contents of 40_custom:<br />
<br />
<br />
<pre><nowiki><br />
#! /sbin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries. Simply type the<br />
# menu entries you want to add after this comment. Be careful not to change<br />
# the 'exec tail' line above.<br />
menuentry 'GNU/Linux, with Linux 2.6.32.40-pv' --class gnu-linux --class gnu --class os {<br />
recordfail<br />
insmod part_msdos<br />
insmod ext2<br />
search --no-floppy --fs-uuid --set=root 016e7c8a-4bdd-4873-92dd-d71171a49d6d<br />
set root='(/dev/sda,msdos2)'<br />
search --no-floppy --fs-uuid --set=root 016e7c8a-4bdd-4873-92dd-d71171a49d6d<br />
multiboot /boot/xen-4.2-unstable.gz<br />
module /boot/vmlinuz-2.6.32.40-pv placeholder root=UUID=016e7c8a-4bdd-4873-92dd-d71171a49d6d dom0_mem=1024 console=tty quiet splash vt.handoff=7<br />
module /boot/initrd.img-2.6.32.40-pv<br />
}<br />
</nowiki></pre><br />
<br />
Xen MUST be started using multiboot this will point to the image created when xen was compiles, the next module line is the linux kernel built from the kernel repository, this can be either jeremy or kernel.org, after the image you append placeholder or dummy=dummy because grub will strip the first argument from the module line. The last line is the ram drive created after the kernel.<br />
<br />
Here is another working example grub.conf with serial console output (good for debugging since you can easily log the full kernel boot messages even if it crashes):<br />
<br />
<br />
<pre><nowiki><br />
title pv_ops dom0 (2.6.32.24) with serial console<br />
root (hd0,0)<br />
kernel /xen-4.0.gz dom0_mem=1024M loglvl=all guest_loglvl=all sync_console console_to_ring com1=19200,8n1 console=com1<br />
module /vmlinuz-2.6.32.24 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset<br />
module /initrd-2.6.32.24.img</nowiki></pre><br />
<br />
For more information about using a serial console with Xen please check the [[XenSerialConsole]] wiki page.<br />
<br />
=== Booting DomU guests ===<br />
<br />
If you've built a modular kernel, then all the modules will be the same either way. Some aspects of the kernel configuration have changed:<br />
<br />
* The console is now /dev/hvc0, so put "console=hvc0" on the kernel command line<br />
* Disk devices are always /dev/xvdX. If you want to dual-boot a system on both Xen and native, then it's best that use use lvm, LABEL or UUID to refer to your filesystems in your /etc/fstab.<br />
<br />
=== Running ===<br />
<span id="running"></span><br />
<br />
=== Troubleshooting, what to do if the custom built pv_ops dom0 kernel doesn't work/boot? ===<br />
<br />
Make sure you read the [[##troubleshooting]] section. It has tons of good suggestions. Also<br />
consult the [[XenCommonProblems]] or [[:Category:FAQ]] pages. <br />
<br />
== Historical contents ==<br />
<br />
=== Timeline of pvops ===<br />
<br />
<span id="history_timeline"></span><br />
Xen pv_ops (domU) support has been in mainline Linux since 2.6.23 (though it is probably first usable in 2.6.24), and is the basis of all on-going Linux/Xen development (the old Xenlinux patches officially ended with 2.6.18.x-xen, though various distros have their own forward-ports of them). Latest Linux kernels (2.6.27 and newer) are good for domU use. Starting from Fedora 9 all the new Fedora distribution versions include pv_ops based Xen domU kernel. Ubuntu 10.04 ("Lucid Lynx") and Debian 6.0 ("Squeeze") also includes Xen PV domU kernel. Red Hat Enterprise Linux 6.0 also includes pvops based Xen domU kernel.<br />
<br />
=== Contributing ===<br />
['''This is obsolete, but it might be worth reading''']<br />
Lots of work has been done to close the feature gaps compared to 2.6.18-xen. Many of these have been done - but there are still some left.<br />
<br />
==== Devices ====<br />
['''Done''']<br />
The Xen device model is more or less unchanged in the pv-ops kernel. Converting a driver from the xen-unstable or 2.6.18-xen tree should mostly be a matter of getting it to compile. There have been changes in the Linux device model between 2.6.18 and 2.6.26, so converting a driver will mostly be a matter of forward-porting to the new kernel, rather than any Xen specific issues.<br />
<br />
==== CPU hotplug ====<br />
['''Done''']<br />
All the mechanism should already be in place to support CPU hotplug; it should just be a matter of making it work.<br />
[2011-07-30]: It works with 3.0.<br />
<br />
==== Device hotplug ====<br />
['''Done''']<br />
In principle this is already implemented and should work. I'm not sure, however, that it's all plumbed through properly, so that hot-adding a device generates the appropriate udev events to cause devices to appear.<br />
<br />
==== Device unplug/module unload ====<br />
['''Done''']<br />
The 2.6.18-xen patches don't really support device unplug (and driver module unload), mainly because of the difficulties in dealing with granted pages. This should be fixed in the pvops kernel. The main thing to implement is to make sure that on driver termination, rather than freeing granted pages back into the kernel heap, they should be added to a list; that list is polled by a kernel thread which periodically tries to ungrant the pages and return them to the kernel heap if successful.<br />
<br />
=== Development of PVOOPS in Ingo's tree ===<br />
['''This is obsolete, but it might be worth reading''']<br />
<br />
All x86 Xen/pv-ops changes queued for upstream Linus are in Ingo Molnar's [http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=summary tip.git] tree. You can get general information about fetching and using this tree in his [http://people.redhat.com/mingo/tip.git/README README]. The [http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=shortlog;h=x86/xen x86/xen] topic branch contains most of the Xen-specific work, though changes in other branches may be necessary too. Using the [http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=shortlog;h=auto-latest auto-latest] branch is the merged product of all the other topic branches.<br />
<br />
=== Testing ===<br />
['''This is obsolete, but it might be worth reading''']<br />
<br />
Xen/paravirt_ops has not had wide use or testing, so any testing you do is extremely valuable. If you have an existing Xen configuration, then updating the kernel to a current pv-ops and trying to use it as you usually would, then any feedback on how well that works (success or failure) would be very interesting. In particular, information about:<br />
<br />
* performance: better/worse/same?<br />
* bugs: outright crash, or something just not right?<br />
* missing features: what can't you live without?<br />
<br />
=== Linux distribution support for pv_ops dom0 kernels ===<br />
['''This is obsolete, but it might be worth reading''']<br />
<br />
Fedora: Fedora 14 includes Xen 4.0.1 hypervisor and is able to run pvops dom0 kernel out-of-the-box. Fedora 14 does not ship with a dom0 capable kernel in the default distribution, but xendom0 kernel rpms are available from developer repositories. Fedora 13 and earlier versions ship with Xen 3.4.x and are not recommended for pvops dom0 usage, unless you update the Xen hypervisor to 4.0.x version. See this tutorial for more help: [[Fedora13Xen4Tutorial]] , and also check the Fedora dom0 wiki page: http://fedoraproject.org/wiki/Features/XenPvopsDom0 .<br />
<br />
Debian: Debian 6.0 ("Squeeze") includes Xen 4.0.x hypervisor, and also dom0 capable kernel based on the pvops tree.<br />
<br />
Other distributions: When using pvops dom0 kernel 2.6.32 or newer you need to have Xen hypervisor 4.0.1 or newer version.<br />
<br />
=== 2.6.32 and earlier kernels ===<br />
['''This is obsolete, but it might be worth reading''']<br />
The kernel build process will build two kernel images: arch/x86/boot/bzImage and vmlinux. They are two forms of the same kernel, and are functionally identical. However, older versions of the Xen tools stack lack support loading bzImage files (pre-Xen 3.2), so you must use the vmlinux form of the kernel (gzipped, if you prefer). <br />
=== Config files for 2.6.32 ===<br />
<br />
Example .config files:<br />
<br />
64bit x86_64 (branch: xen/stable-2.6.32.x):<br />
<br />
* 2.6.32.10: http://pasik.reaktio.net/xen/kernel-config/config-2.6.32.10-pvops-dom0-xen-stable-x86_64<br />
* 2.6.32.15: http://pasik.reaktio.net/xen/kernel-config/config-2.6.32.15-pvops-dom0-xen-stable-x86_64<br />
* 2.6.32.19: http://pasik.reaktio.net/xen/kernel-config/config-2.6.32.19-pvops-dom0-xen-stable-x86_64<br />
* 2.6.32.21: http://pasik.reaktio.net/xen/kernel-config/config-2.6.32.21-pvops-dom0-xen-stable-x86_64<br />
* 2.6.32.24: http://pasik.reaktio.net/xen/kernel-config/config-2.6.32.24-pvops-dom0-xen-stable-x86_64<br />
* 2.6.32.25: http://pasik.reaktio.net/xen/kernel-config/config-2.6.32.25-pvops-dom0-xen-stable-x86_64<br />
* 2.6.32.27: http://pasik.reaktio.net/xen/kernel-config/config-2.6.32.27-pvops-dom0-xen-stable-x86_64<br />
* 2.6.32.43: http://pasik.reaktio.net/xen/kernel-config/config-2.6.32.43-pvops-dom0-xen-stable-x86_64<br />
<br />
32bit PAE:<br />
<br />
* xen/stable-2.6.31.x (2.6.31.6): http://pasik.reaktio.net/xen/kernel-config/config-2.6.31.6-pvops-dom0-xen-master-x86_32<br />
* xen/stable-2.6.32.x (2.6.32.10): http://pasik.reaktio.net/xen/kernel-config/config-2.6.32.10-pvops-dom0-xen-stable-x86_32<br />
* xen/stable-2.6.32.x (2.6.32.27): http://pasik.reaktio.net/xen/kernel-config/config-2.6.32.27-pvops-dom0-xen-stable-x86_32<br />
<br />
Those kernel configs are based on Fedora 11/12 kernel configuration, with some modifications. They've been tested to work on multiple systems. '''Note that these .config files have various debugging options enabled which will decrease performance so don't use these .config files for performance testing!'''<br />
<br />
[[Category:PVOPS]]<br />
[[Category:Users]]<br />
[[Category:Developers]]<br />
[[Category:Project]]<br />
[[Category:Overview]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_FAQ_Installation&diff=5084Xen FAQ Installation2012-09-24T12:14:34Z<p>OliverChick: /* Is there a way to have a shared root file system amongst a set of Xen servers? */</p>
<hr />
<div>= File Systems =<br />
<br />
== Is there a way to have a shared root file system amongst a set of Xen servers? ==<br />
<br />
Yes, the best way to achieve this is to install your guest with an LVM-backed block device. You can then create a snapshot of this filesystem, with the command:<br />
lvcreate -L<size of snapshot> -s -n <snapshot name> <backend disk name><br />
<br />
You should create one snapshot per guest, and then put the snapshot into the guest's .cfg file.<br />
<br />
Using snapshots allows you to avoid having to make a read-only root filesystem. However, should you wish to use a read only root fs, you can install the OS in an LVM partition and use it shared across all the xen domUs when you use the parition as 'r' instead of 'w' when defining the disk.<br />
<br />
== Will I get good I/O performance if I use a file-backed (.img) block device? ==<br />
No. Using lvm to create a volume, and using the <br />
<br />
disk=['phy:/...']<br />
<br />
method in your .cfg file will yield better performance. This is particularly important for I/O intensive VMs, such as databases.<br />
<br />
== How can I make disk r4esizing work? ==<br />
I tried to resize a disk of my data guest from 100 to 400 GB. I did an lvresize<br />
/dev/xendata/data-disk -L 400G an it works. I started the Guest and did an df -h to check the size but there are still 100 G<br />
<br />
The container is bigger but the filesystem isn't. Resizing an LV doesn't make the FS any bigger.<br />
<br />
Log into the DomU and do a resize2fs <device>. You can do this while it's mounted as long as the filesystem is getting bigger.<br />
<br />
Oh, and if you've partitioned the LV inside the guest, you'll also need to resize the partition (BEFORE you do a resize2fs, etc.). There are two ways to do this - the safest is to use parted, which works if you're using ext2/ext3 (and a couple other of the most popular filesystems - reiser, I think). The other method is to delete the partition and recreate it with the extended end points. This isn't quite as safe and requires that 1) your start point for the partition is exactly the same as it was before, and 2) the partition is the last (or only) one on the LV.<br />
<br />
== How do I overcommit storage? ==<br />
This is a matter of what storage backend you use. If you use one of the following, you will be able to overcommit storage:<br />
*sparse raw file (with file: or tap:aio:)<br />
*qcow<br />
*vmdk/vdisk (I think full support is only in newer Xen or Opensolaris)<br />
*zvol (on Opensolaris)<br />
<br />
If you use disk/partition/LVM for domU storage, you won't be able to.<br />
<br />
= 32bit vs 64 bit =<br />
<br />
== Is there any way to install 64Bit Linux DomU on 32Bit Linux Dom0? ==<br />
<br />
Types of domU that can be run depends mostly on the hypervisor, and not dom0. So if you have a<br />
64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit.<br />
<br />
If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not<br />
64bit PV domU.<br />
<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_FAQ_Installation&diff=5083Xen FAQ Installation2012-09-24T12:12:38Z<p>OliverChick: /* Is it possible to start a VM that contains just gpxe? */ Deleted - link in answer is broken</p>
<hr />
<div>= File Systems =<br />
<br />
== Is there a way to have a shared root file system amongst a set of Xen servers? ==<br />
<br />
Yes, the best way to achieve this is to install your guest with an LVM-backed block device. You can then create a snapshot of this filesystem, with the command:<br />
lvcreate -L<size of snapshot> -s -n <snapshot name> <backend disk name><br />
<br />
You should create one snapshot per guest, and then put the snapshot into the guest's .cfg file.<br />
<br />
Using snapshots allows you to avoid having to make a read-only root filesystem. However, should you wish to use a read only root fs, you can install the OS in an LVM partition and use it shared across all the xen domUs when you use the parition as 'r' instead of 'w' when defining the disk.<br />
<br />
Like 1. mount ramfs in /tmp and in /var ... http://en.opensuse.org/How-To_Make_the_root_filesystem_read-only<br />
I use 2 disks in Xen with one as read-only mounted as / and the other is the data partition. I have a need to have scratch partition with pre-populated data and for this I create a LV and put data into it (eg:- software etc.,) and then create a snapshot of this volume and send it as rw to the xen machine. This way my original software partitions are intact and also the changes (may be damaging) done in the xen volumes are lost once the snapshot grows to 100%.<br />
<br />
== Will I get good I/O performance if I use a file-backed (.img) block device? ==<br />
No. Using lvm to create a volume, and using the <br />
<br />
disk=['phy:/...']<br />
<br />
method in your .cfg file will yield better performance. This is particularly important for I/O intensive VMs, such as databases.<br />
<br />
== How can I make disk r4esizing work? ==<br />
I tried to resize a disk of my data guest from 100 to 400 GB. I did an lvresize<br />
/dev/xendata/data-disk -L 400G an it works. I started the Guest and did an df -h to check the size but there are still 100 G<br />
<br />
The container is bigger but the filesystem isn't. Resizing an LV doesn't make the FS any bigger.<br />
<br />
Log into the DomU and do a resize2fs <device>. You can do this while it's mounted as long as the filesystem is getting bigger.<br />
<br />
Oh, and if you've partitioned the LV inside the guest, you'll also need to resize the partition (BEFORE you do a resize2fs, etc.). There are two ways to do this - the safest is to use parted, which works if you're using ext2/ext3 (and a couple other of the most popular filesystems - reiser, I think). The other method is to delete the partition and recreate it with the extended end points. This isn't quite as safe and requires that 1) your start point for the partition is exactly the same as it was before, and 2) the partition is the last (or only) one on the LV.<br />
<br />
== How do I overcommit storage? ==<br />
This is a matter of what storage backend you use. If you use one of the following, you will be able to overcommit storage:<br />
*sparse raw file (with file: or tap:aio:)<br />
*qcow<br />
*vmdk/vdisk (I think full support is only in newer Xen or Opensolaris)<br />
*zvol (on Opensolaris)<br />
<br />
If you use disk/partition/LVM for domU storage, you won't be able to.<br />
<br />
= 32bit vs 64 bit =<br />
<br />
== Is there any way to install 64Bit Linux DomU on 32Bit Linux Dom0? ==<br />
<br />
Types of domU that can be run depends mostly on the hypervisor, and not dom0. So if you have a<br />
64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit.<br />
<br />
If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not<br />
64bit PV domU.<br />
<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_FAQ_Installation&diff=5082Xen FAQ Installation2012-09-24T12:12:02Z<p>OliverChick: /* How do I use Xen with Dynamic Slices? */ Turn into a proper Q & A</p>
<hr />
<div>= File Systems =<br />
<br />
== Is there a way to have a shared root file system amongst a set of Xen servers? ==<br />
<br />
Yes, the best way to achieve this is to install your guest with an LVM-backed block device. You can then create a snapshot of this filesystem, with the command:<br />
lvcreate -L<size of snapshot> -s -n <snapshot name> <backend disk name><br />
<br />
You should create one snapshot per guest, and then put the snapshot into the guest's .cfg file.<br />
<br />
Using snapshots allows you to avoid having to make a read-only root filesystem. However, should you wish to use a read only root fs, you can install the OS in an LVM partition and use it shared across all the xen domUs when you use the parition as 'r' instead of 'w' when defining the disk.<br />
<br />
Like 1. mount ramfs in /tmp and in /var ... http://en.opensuse.org/How-To_Make_the_root_filesystem_read-only<br />
I use 2 disks in Xen with one as read-only mounted as / and the other is the data partition. I have a need to have scratch partition with pre-populated data and for this I create a LV and put data into it (eg:- software etc.,) and then create a snapshot of this volume and send it as rw to the xen machine. This way my original software partitions are intact and also the changes (may be damaging) done in the xen volumes are lost once the snapshot grows to 100%.<br />
<br />
== Will I get good I/O performance if I use a file-backed (.img) block device? ==<br />
No. Using lvm to create a volume, and using the <br />
<br />
disk=['phy:/...']<br />
<br />
method in your .cfg file will yield better performance. This is particularly important for I/O intensive VMs, such as databases.<br />
<br />
== Is it possible to start a VM that contains just gpxe? ==<br />
(which when started, will get an image from a provisioning server and will load that image)<br />
<br />
In this article, we'll show you the prcesses to setup PXE boot environment for Xen host (hypervisor + dom0) and Xen guest, both PV (Para-Virtualized) guest and HVM (Hardware-assisted Virtual Machine). Details at http://os-drive.com/files/docbook/xen-pxeboot.html.<br />
<br />
== How can I make disk r4esizing work? ==<br />
I tried to resize a disk of my data guest from 100 to 400 GB. I did an lvresize<br />
/dev/xendata/data-disk -L 400G an it works. I started the Guest and did an df -h to check the size but there are still 100 G<br />
<br />
The container is bigger but the filesystem isn't. Resizing an LV doesn't make the FS any bigger.<br />
<br />
Log into the DomU and do a resize2fs <device>. You can do this while it's mounted as long as the filesystem is getting bigger.<br />
<br />
Oh, and if you've partitioned the LV inside the guest, you'll also need to resize the partition (BEFORE you do a resize2fs, etc.). There are two ways to do this - the safest is to use parted, which works if you're using ext2/ext3 (and a couple other of the most popular filesystems - reiser, I think). The other method is to delete the partition and recreate it with the extended end points. This isn't quite as safe and requires that 1) your start point for the partition is exactly the same as it was before, and 2) the partition is the last (or only) one on the LV.<br />
<br />
== How do I overcommit storage? ==<br />
This is a matter of what storage backend you use. If you use one of the following, you will be able to overcommit storage:<br />
*sparse raw file (with file: or tap:aio:)<br />
*qcow<br />
*vmdk/vdisk (I think full support is only in newer Xen or Opensolaris)<br />
*zvol (on Opensolaris)<br />
<br />
If you use disk/partition/LVM for domU storage, you won't be able to.<br />
<br />
= 32bit vs 64 bit =<br />
<br />
== Is there any way to install 64Bit Linux DomU on 32Bit Linux Dom0? ==<br />
<br />
Types of domU that can be run depends mostly on the hypervisor, and not dom0. So if you have a<br />
64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit.<br />
<br />
If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not<br />
64bit PV domU.<br />
<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_FAQ_Installation&diff=5081Xen FAQ Installation2012-09-24T12:09:56Z<p>OliverChick: /* Why is PV performance on my installation poor? */</p>
<hr />
<div>= File Systems =<br />
<br />
== Is there a way to have a shared root file system amongst a set of Xen servers? ==<br />
<br />
Yes, the best way to achieve this is to install your guest with an LVM-backed block device. You can then create a snapshot of this filesystem, with the command:<br />
lvcreate -L<size of snapshot> -s -n <snapshot name> <backend disk name><br />
<br />
You should create one snapshot per guest, and then put the snapshot into the guest's .cfg file.<br />
<br />
Using snapshots allows you to avoid having to make a read-only root filesystem. However, should you wish to use a read only root fs, you can install the OS in an LVM partition and use it shared across all the xen domUs when you use the parition as 'r' instead of 'w' when defining the disk.<br />
<br />
Like 1. mount ramfs in /tmp and in /var ... http://en.opensuse.org/How-To_Make_the_root_filesystem_read-only<br />
I use 2 disks in Xen with one as read-only mounted as / and the other is the data partition. I have a need to have scratch partition with pre-populated data and for this I create a LV and put data into it (eg:- software etc.,) and then create a snapshot of this volume and send it as rw to the xen machine. This way my original software partitions are intact and also the changes (may be damaging) done in the xen volumes are lost once the snapshot grows to 100%.<br />
<br />
== Will I get good I/O performance if I use a file-backed (.img) block device? ==<br />
No. Using lvm to create a volume, and using the <br />
<br />
disk=['phy:/...']<br />
<br />
method in your .cfg file will yield better performance. This is particularly important for I/O intensive VMs, such as databases.<br />
<br />
== Is it possible to start a VM that contains just gpxe? ==<br />
(which when started, will get an image from a provisioning server and will load that image)<br />
<br />
In this article, we'll show you the prcesses to setup PXE boot environment for Xen host (hypervisor + dom0) and Xen guest, both PV (Para-Virtualized) guest and HVM (Hardware-assisted Virtual Machine). Details at http://os-drive.com/files/docbook/xen-pxeboot.html.<br />
<br />
== How can I make disk r4esizing work? ==<br />
I tried to resize a disk of my data guest from 100 to 400 GB. I did an lvresize<br />
/dev/xendata/data-disk -L 400G an it works. I started the Guest and did an df -h to check the size but there are still 100 G<br />
<br />
The container is bigger but the filesystem isn't. Resizing an LV doesn't make the FS any bigger.<br />
<br />
Log into the DomU and do a resize2fs <device>. You can do this while it's mounted as long as the filesystem is getting bigger.<br />
<br />
Oh, and if you've partitioned the LV inside the guest, you'll also need to resize the partition (BEFORE you do a resize2fs, etc.). There are two ways to do this - the safest is to use parted, which works if you're using ext2/ext3 (and a couple other of the most popular filesystems - reiser, I think). The other method is to delete the partition and recreate it with the extended end points. This isn't quite as safe and requires that 1) your start point for the partition is exactly the same as it was before, and 2) the partition is the last (or only) one on the LV.<br />
<br />
== How do I use Xen with Dynamic Slices? ==<br />
I want use xen with dynamic slices. For example, I have 20 domU based on FreeBSD, xen hypervisor 3.3.1, Debian Lenny dom0 system. All domUs have 80Gb LVM partitions, but realy they use 20 of this 80Gb and I want to create more domU's. How can I do it? I know that some virtualisation have possibility to do dynamic slices(4 example Virtul box)<br />
<br />
Do you mean storage overcommit? That is, assign more storage to domU than what you actually have?<br />
<br />
If yes, it's not a matter of Xen vs [[VirtualBox]]. It's a matter of what storage backend you use. If you use one of these: - sparse raw file (with file: or tap:aio:) - qcow - vmdk/vdisk (I think full support is only in newer Xen or Opensolaris) - zvol (on Opensolaris) then you can overcommit storage. But if you use disk/partition/LVM for domU storage, you won't be able to.<br />
<br />
= 32bit vs 64 bit =<br />
<br />
== Is there any way to install 64Bit Linux DomU on 32Bit Linux Dom0? ==<br />
<br />
Types of domU that can be run depends mostly on the hypervisor, and not dom0. So if you have a<br />
64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit.<br />
<br />
If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not<br />
64bit PV domU.<br />
<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_FAQ_Installation&diff=5080Xen FAQ Installation2012-09-24T12:06:02Z<p>OliverChick: /* Is there a way to have a shared root file system amongst a set of Xen servers? */ Suggest using lvm snapshots</p>
<hr />
<div>= File Systems =<br />
<br />
== Is there a way to have a shared root file system amongst a set of Xen servers? ==<br />
<br />
Yes, the best way to achieve this is to install your guest with an LVM-backed block device. You can then create a snapshot of this filesystem, with the command:<br />
lvcreate -L<size of snapshot> -s -n <snapshot name> <backend disk name><br />
<br />
You should create one snapshot per guest, and then put the snapshot into the guest's .cfg file.<br />
<br />
Using snapshots allows you to avoid having to make a read-only root filesystem. However, should you wish to use a read only root fs, you can install the OS in an LVM partition and use it shared across all the xen domUs when you use the parition as 'r' instead of 'w' when defining the disk.<br />
<br />
Like 1. mount ramfs in /tmp and in /var ... http://en.opensuse.org/How-To_Make_the_root_filesystem_read-only<br />
I use 2 disks in Xen with one as read-only mounted as / and the other is the data partition. I have a need to have scratch partition with pre-populated data and for this I create a LV and put data into it (eg:- software etc.,) and then create a snapshot of this volume and send it as rw to the xen machine. This way my original software partitions are intact and also the changes (may be damaging) done in the xen volumes are lost once the snapshot grows to 100%.<br />
<br />
== Why is PV performance on my installation poor? ==<br />
I installed two Debian web server which run a phpbb3 forum. One stays on a Xen paravirtualized domU (512 MB of ram, 1 vcpu, disc on a raw file file:/home/vale/debian.img,hda,w) on [[OpenSuse]] 11.0 and one run on a hyper-v virtual machine (512 MB 1 cpu) build on Windows Server<br />
2008 R2. The performances on PV are very poor than hyper-v. ab -n 3000 -k -c50 http://site.lan/phpBB3/ returns 13,22 req/sec on PV domU and 38,37 req/sec on hyper-v. Why? <br />
<br />
I installed O.S. guest as a HVM domain, then I installed linux-xen-image files and I use them for vmlinuz and initrd. I also installed libc6-xen.<br />
<br />
Xen PV config file:<br />
<br />
<pre><nowiki><br />
name='pv'<br />
ramdisk='/home/vale/initrd.img-2.6.18-6-xen-686' kernel='/home/vale/vmlinuz-2.6.18-6-xen-686' bootloader=''<br />
vif=['mac=00:16:3e:33:37:4f, bridge=xenbr0']<br />
vcpus=1 memory=512 disk=['file:/home/vale/pv.img,hda,w'] on_reboot='restart'<br />
on_crash='restart' extra='' root='/dev/hda1' platform='xen'<br />
</nowiki></pre><br />
<br />
I'm assuming that phpBB3 is relatively I/O intensive (since it uses db, which I assume you also installed on the same host). In that case, your bad numbers are probably because of this<br />
<br />
<pre><nowiki><br />
disk=['file:/home/vale/pv.img,hda,w']<br />
</nowiki></pre><br />
<br />
<br />
On Xen, file:/ is not recommended, and you should use tap:aio:/ instead for file-backed storage. Then again, another user reported that even tap:aio isn't good enough<br />
<br />
http://lists.xensource.com/archives/html/xen-users/2009-01/msg00820.html<br />
<br />
So in short, if you use Xen PV, you might want to consider using LVM/partition-backed storage.<br />
<br />
== Is it possible to start a VM that contains just gpxe? ==<br />
(which when started, will get an image from a provisioning server and will load that image)<br />
<br />
In this article, we'll show you the prcesses to setup PXE boot environment for Xen host (hypervisor + dom0) and Xen guest, both PV (Para-Virtualized) guest and HVM (Hardware-assisted Virtual Machine). Details at http://os-drive.com/files/docbook/xen-pxeboot.html.<br />
<br />
== How can I make disk r4esizing work? ==<br />
I tried to resize a disk of my data guest from 100 to 400 GB. I did an lvresize<br />
/dev/xendata/data-disk -L 400G an it works. I started the Guest and did an df -h to check the size but there are still 100 G<br />
<br />
The container is bigger but the filesystem isn't. Resizing an LV doesn't make the FS any bigger.<br />
<br />
Log into the DomU and do a resize2fs <device>. You can do this while it's mounted as long as the filesystem is getting bigger.<br />
<br />
Oh, and if you've partitioned the LV inside the guest, you'll also need to resize the partition (BEFORE you do a resize2fs, etc.). There are two ways to do this - the safest is to use parted, which works if you're using ext2/ext3 (and a couple other of the most popular filesystems - reiser, I think). The other method is to delete the partition and recreate it with the extended end points. This isn't quite as safe and requires that 1) your start point for the partition is exactly the same as it was before, and 2) the partition is the last (or only) one on the LV.<br />
<br />
== How do I use Xen with Dynamic Slices? ==<br />
I want use xen with dynamic slices. For example, I have 20 domU based on FreeBSD, xen hypervisor 3.3.1, Debian Lenny dom0 system. All domUs have 80Gb LVM partitions, but realy they use 20 of this 80Gb and I want to create more domU's. How can I do it? I know that some virtualisation have possibility to do dynamic slices(4 example Virtul box)<br />
<br />
Do you mean storage overcommit? That is, assign more storage to domU than what you actually have?<br />
<br />
If yes, it's not a matter of Xen vs [[VirtualBox]]. It's a matter of what storage backend you use. If you use one of these: - sparse raw file (with file: or tap:aio:) - qcow - vmdk/vdisk (I think full support is only in newer Xen or Opensolaris) - zvol (on Opensolaris) then you can overcommit storage. But if you use disk/partition/LVM for domU storage, you won't be able to.<br />
<br />
= 32bit vs 64 bit =<br />
<br />
== Is there any way to install 64Bit Linux DomU on 32Bit Linux Dom0? ==<br />
<br />
Types of domU that can be run depends mostly on the hypervisor, and not dom0. So if you have a<br />
64bit hypervisor, you should be able to run 32 and 64bit PV and HVM domUs, regardless whether dom0 is 32 or 64bit.<br />
<br />
If you have 32bit dom0 and 32bit hypervisor, you should be able to run 64bit HVM domU, but not<br />
64bit PV domU.<br />
<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_Common_Problems&diff=5076Xen Common Problems2012-09-24T11:43:33Z<p>OliverChick: Deleted a lot of old Q&As. Updated references from xm to xl.</p>
<hr />
<div><!-- MoinMoin name: XenCommonProblems --><br />
<!-- Comment: Copied "Xend does not start when using pv_ops dom0 kernel?" from the Paravirt page in this. --><br />
<!-- WikiMedia name: XenCommonProblems --><br />
<!-- Page revision: 00000167 --><br />
<!-- Original date: Wed Oct 26 18:28:24 2011 (1319653704000000) --><br />
<br />
{{Needs_Refactor|This page is a left over from the old Xen wiki and contained many recent FAQs. The key question is what to do with these. We have created [[:Category:FAQ]] which has articles that list FAQs by topic. We could break this article up and move the content to pages listed in [[:Category:FAQ]]. Please provide a view by making a comment in [[Talk:Xen Common Problems]]. Also note that some of the questions are a little out-of-date.}}<br />
<br />
'''Answers to some common problems and questions about Xen''' <br />
<!-- ! TOC here --><br />
<br />
== I'd like to contribute to the Xen wiki pages, I have something to add/edit/fix, how can I do it? ==<br />
Contributions are very welcome! You should create yourself a wiki account. No edit permissions are needed. More info on getting started at<br />
* [[Special:UserLogin|Create an account or log in]]<br />
* [[Sandbox|Play with the Sandbox]]<br />
* [http://upload.wikimedia.org/wikipedia/commons/8/89/Cheatsheet-mediawiki.pdf MediaWiki Cheat Sheet]<br />
* [http://www.mediawiki.org/wiki/Help:Contents MediaWiki Help Contents]<br />
* [http://www.mediawiki.org/wiki/Help:Formatting MediaWiki Formatting]<br />
* [http://www.mediawiki.org/wiki/Books_about_MediaWiki Books about MediaWiki]<br />
* [[Wiki_Community|Wiki Community Portal]]<br />
* [[:Category:Wiki Management|Wiki Management Tools]]<br />
* [[Xen:Multi-language Conventions|Multi-language Conventions]]<br />
<br />
== I'd like to read some kind of overview about Xen ==<br />
See the [[XenOverview]] wiki page and [[:Category:Overview]]. Also check the following PDF documents (which are somewhat out-of-date):<br />
<br />
* http://www.xen.org/files/Marketing/WhatisXen.pdf<br />
* http://www.xen.org/files/Marketing/WhyXen.pdf<br />
* http://www.xen.org/files/Marketing/NewtoXenGuide.pdf<br />
* http://www.xen.org/files/Marketing/HowDoesXenWork.pdf<br />
<br />
== Where can I read about the history of Xen? ==<br />
Please see: http://www.xen.org/community/xenhistory.html<br />
<br />
== I'm interesting in being a Xen developer! Are there projects to work on? ==<br />
Yes! Please check the [[XenDevelopmentProjects]] wiki page for more information!<br />
<br />
== How does Xen compare to KVM? Which one is better? ==<br />
Please see this blog post for more information: http://blog.xen.org/index.php/2010/05/07/xen-%E2%80%93-kvm-linux-%E2%80%93-and-the-community/<br />
<br />
Also check these documents:<br />
<br />
* http://www.slideshare.net/xen_com_mgr/why-xen-slides<br />
* http://blog.xen.org/index.php/2010/07/30/why-xen-paper-published/<br />
<br />
== Is there a "Best Practices" document available? ==<br />
See the [[XenBestPractices]] wiki page.<br />
<br />
== Where can I find a list of available Xen dom0 kernels? ==<br />
See the [[XenDom0Kernels]] wiki page.<br />
<br />
== Where can I find a list of available features in different Xen kernels? ==<br />
See the [[XenKernelFeatures]] wiki page.<br />
<br />
== I have problems getting Xen or dom0 kernel to boot, how can I set up a serial console to log and troubleshoot the boot process? ==<br />
See the [[XenSerialConsole]] wiki page.<br />
<br />
== Where can I find a list of all the available domU configuration options in /etc/xen/<guest> cfgfile? ==<br />
See the [[XenConfigurationFileOptions]] wiki page.<br />
<br />
== Is there a list of all available Xen hypervisor (xen.gz) commandline boot options for grub.conf? ==<br />
Yes, please see the [[XenHypervisorBootOptions]] wiki page.<br />
<br />
== Can I passthrough an USB device connected to dom0 to a Xen guest? ==<br />
Yes, please see the [[XenUSBPassthrough]] wiki page.<br />
<br />
== Can I passthrough a PCI device to Xen guest? ==<br />
Yes, please see the [[XenPCIpassthrough]] wiki page.<br />
<br />
== Can I passthru a VGA graphics adapter to Xen guest? ==<br />
Yes, please see the [[XenVGAPassthrough]] wiki page.<br />
<br />
== I have problems using my graphics card in Xen dom0, with the pvops dom0 kernel.. any tips? ==<br />
Yes, please see the [[XenPVOPSDRM]] wiki page.<br />
<br />
== Is there more information about Xen PVSCSI passthrough functionality? ==<br />
Yes, please see the [[XenPVSCSI]] wiki page.<br />
<br />
== Is there more information about Xen "blktap" disk backend? ==<br />
Yes, Xen actually has two blktap backends:<br />
<br />
* blktap1: please see the [[blktap]] wiki page for more information.<br />
* blktap2: please see the [[blktap2]] wiki page for more information.<br />
blktap2 supports VHD images, and is considered much more robust than the old blktap1 qemu/qcow image file support. Xen 4.0 includes blktap2 support. Note that also the dom0 kernel needs to have the blktap2 driver.<br />
<br />
== Is there a list of various 3rd party management tools and (web) interfaces for Xen or XCP? ==<br />
Yes, please see the [[XenManagementTools]] wiki page.<br />
<br />
== Is there more information about Xen Fault Tolerance, aka Remus Transparent High Availability (HA) for VMs? ==<br />
Yes, please see the [[Remus]] wiki page for more information.<br />
<br />
== Where can I find optimized Xen PV-on-HVM drivers for Linux HVM (fully virtualized) guests? ==<br />
Please see the [[XenLinuxPVonHVMdrivers]] wiki page.<br />
<br />
== Do you have a list of Xen related research papers? ==<br />
Yes, please see http://www.xen.org/community/xenpapers.html<br />
<br />
== Where can I find information about Xen on RISC CPUs? ==<br />
* Please see [[XenARM]] wiki page for Xen on ARM CPUs. Xen ARM project is actively developed.<br />
* Please see [[Xen_ARMv7_with_Virtualization_Extensions]] wiki page for Xen on ARMv7 CPUs with Virtualization Extensions. This project is actively developed.<br />
* Xen has also been ported to MIPS64 platform. See the Netlogic Microsystems press release for more information: http://vmblog.com/archive/2012/01/30/netlogic-microsystems-announces-the-industry-s-first-open-source-xen-hypervisor-for-multi-core-mips64-processors.aspx or the xen-devel mailinglist post: http://lists.xen.org/archives/html/xen-devel/2012-01/msg00301.html .<br />
* Please see [[XenPPC]] wiki page for Xen on PowerPC CPUs. XenPPC project is not active anymore.<br />
== What's the difference between Xen hypervisor (from xen.org) and Citrix [[XenServer]] or XCP? ==<br />
Xen hypervisor from xen.org is the core hypervisor used in many different products. It includes basic command line management tools. It is distributed as a tarball and from mercurial source code repositories. You need to compile and install Xen hypervisor from sources, and combine it with a kernel of your choice. It can be thought as the "core engine" you can use to build your own virtualization platform.<br />
<br />
Many Linux distributions package Xen and distribute it as prebuilt binaries, combined with Xen capable kernels of their choice. There are many additional thirdparty management tools available to manage the Xen hypervisor.<br />
<br />
There are multiple companies shipping products based on the Xen hypervisor, including Citrix, Oracle, Novell, Redhat, and others.<br />
<br />
Citrix [[XenServer]] is a commercial product that includes the core Xen hypervisor from xen.org, combined with CentOS-based dom0 distro, management toolstack, and everything else required to build a ready made virtualization platform. Citrix [[XenServer]] is a dedicated virtualization platform (not a general purpose Linux distro), and it is shipped as a ready to install ISO-image that contains everything you need out-of-the-box. Citrix [[XenServer]] includes the XAPI management toolstack (which not included in the core Xen hypervisor from xen.org), allowing you to pool multiple Xen hosts together and manage them centrally using either the graphical Citrix [[XenCenter]] management tool, the 'xe' commandline tool or using the XenAPI directly from your scripts. Citrix [[XenCenter]] graphical management tool is only available for Windows.<br />
<br />
Xen Cloud Platform (XCP) was announced in 2009, and it is the opensourced version of Citrix [[XenServer]], including the XAPI management toolstack. XCP and XAPI are now developed on xen.org repositories. XCP is shipped as ready to install ISO-images, just like Citrix [[XenServer]]. Citrix is basing their new Citrix [[XenServer]] releases on XCP. XCP includes the XenAPI provided by the XAPI toolstack and the 'xe' commandline tool. XCP does not include Citrix [[XenCenter]] and Citrix [[XenCenter]] cannot be used to manage XCP. XCP users can use the opensource [[OpenXenManager]] instead, which runs on Linux. See http://www.xen.org/products/cloudxen.html for more information about XCP.<br />
<br />
== How can I check the version of Xen hypervisor? ==<br />
Run "xl info" in dom0. You can find the hypervisor version in "xen_major", "xen_minor" and "xen_extra" fields. The version is major.minor.extra.<br />
<br />
Determining the version from within a domU is dependent on the guest operating system. For Linux guests:<br />
<br />
<br />
<pre><br />
$ dmesg | grep Xen\ version<br />
Xen version: 4.2.0 (preserve-AD)<br />
</pre><br />
<br />
== What are the names of different hardware features related to virtualization and Xen? ==<br />
<br />
* Xen supports running PV (paravirtualized) VMs on any PAE-capable x86 or x86_64 CPU (both Intel and AMD CPUs). CPU Virtualization extensions are NOT required or used to run Xen PV domUs.<br />
* Xen requires CPU Virtualization Extensions to run Xen HVM (Fully Virtualized) VMs. Also the system BIOS needs to support and enable the CPU Virtualization extensions.<br />
* CPU Virtualization extensions are called Intel VT-x or AMD-V and they are required for running Xen HVM guests.<br />
* HAP (Hardware Assisted Paging) can be optionally used to boost the performance of Xen memory management for HVM VMs. HAP is an additional feature of the CPU, and it's not present on older CPUs. Intel HAP is called Intel EPT (Extended Page Tables) and AMD HAP is called AMD NPT (Nested Page Tables). AMD NPT is sometimes also referred as AMD RVI (Rapid Virtualization Indexing).<br />
* IOMMU (IO Memory Management Unit) support from CPU/BIOS/chipset is needed for Xen IO Virtualization. IOMMU makes it possible to dedicate PCI device securely to a Xen VM by using Xen PCI passthru. Intel IOMMU is called Intel VT-d, and AMD IOMMU is called just AMD IOMMU. <br />
* SR-IOV (Single Root IO Virtualization) can be used together with IOMMU PCI passthru and PCI Express SR-IOV capable devices. SR-IOV needs to be supported and enabled by the system chipset, BIOS and the PCI-e device itself. For example Intel 82599 10 Gigabit Ethernet NIC supports 64 Virtual Functions (VFs), which means the NIC can be configured to show up as 64 different PCI devices (PCI IDs), so you can use Xen PCI passthru to passthrough each VF to some Xen VM and give the VM direct access to the PCI-e device. SR-IOV provides excellent IO performance and very low overhead.<br />
<br />
== How can I check if I'm able to run Xen HVM (fully virtualized) guests? ==<br />
Xen requires CPU virtualization support/extensions (Intel VT, AMD-V) for running HVM guests (=Windows). Virtualization support needs to be enabled in the system BIOS. Intel calls this feature also as "VT-x". Also note that Intel "VT-x" is different from "VT-d", which is a totally different feature (see the next section below).<br />
<br />
NOTE that Linux dom0 kernel doesn't see 'vmx' or 'svm' CPU flags in "/proc/cpuinfo" because Xen *hypervisor* (xen.gz) is using the hardware virtualization features and hiding the flags from dom0! Xen dom0 is actually a virtual machine, so it doesn't see all the cpu flags as Xen hypervisor is hiding some flags from dom0.<br />
<br />
You can run "xl info" in dom0 and check from the 'xen_caps' line if Xen is able to run hvm guests. Also Xen hypervisor boot messages in "xm dmesg" show if hardware virtualization (HVM) is enabled or disabled.<br />
<br />
Example "xl dmesg | grep -i hvm" output for an Intel system where HVM is supported by the CPU:<br />
<br />
<br />
<pre><br />
(XEN) HVM: VMX enabled<br />
</pre><br />
<br />
Example "xl dmesg" output for an Intel system where HVM is supported by the CPU but it's disabled in the system BIOS:<br />
<br />
<br />
<pre><br />
(XEN) VMX disabled by Feature Control MSR.<br />
</pre><br />
<br />
Example "xl dmesg | grep -i hvm" output for an AMD system where HVM is supported:<br />
<br />
<br />
<pre><br />
(XEN) HVM: SVM enabled<br />
</pre><br />
<br />
You can also see the HVM support status from the "xen_caps" line on Xen hypervisor "xl info | grep xen_caps" output:<br />
<br />
<br />
<pre><br />
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64<br />
</pre><br />
<br />
== How can I check if my CPU supports HAP (Hardware Assisted Paging) ? ==<br />
<br />
You can check Xen dmesg by running "xl dmesg" to verify if HAP is supported on your CPU:<br />
<br />
<pre><br />
(XEN) HVM: Hardware Assisted Paging detected and enabled.<br />
</pre><br />
<br />
Newer Xen versions (4.1.3+, 4.2.x+) will have info like this:<br />
<pre><br />
(XEN) HVM: Hardware Assisted Paging (HAP) detected<br />
(XEN) HVM: HAP page sizes: 4kB, 2MB<br />
</pre><br />
<br />
HAP support is provided by the following features on CPUs:<br />
* Intel EPT (Extended Page Tables).<br />
* AMD NPT (Nested Page Tables, sometimes also called as AMD RVI - Rapid Virtualization Indexing).<br />
<br />
== How can I check if my hardware has an IOMMU (VT-d) and it's enabled and supported? ==<br />
Hardware IOMMU (Intel VT-d) is required for hardware assisted PCI passthru (I/O virtualization) to Xen HVM (fully virtualized) guest VMs. You can check for IOMMU status from "xl dmesg" output.<br />
<br />
Example "xl dmesg" output for a system where IOMMU is supported:<br />
<br />
<br />
<pre><br />
(XEN) I/O virtualisation enabled<br />
</pre><br />
<br />
Example "xl dmesg" output for a system where IOMMU is not supported:<br />
<br />
<br />
<pre><br />
(XEN) I/O virtualisation disabled<br />
</pre><br />
<br />
You might also see additional output like:<br />
<br />
<br />
<pre><br />
(XEN) Intel VT-d Snoop Control supported.<br />
(XEN) Intel VT-d DMA Passthrough not supported.<br />
(XEN) Intel VT-d Queued Invalidation supported.<br />
(XEN) Intel VT-d Interrupt Remapping not supported.<br />
</pre><br />
<br />
And if hardware IOMMU is used for PV guest PCI passthru or not:<br />
<br />
<br />
<pre><br />
(XEN) I/O virtualisation for PV guests enabled<br />
</pre><br />
<br />
Xen doesn't require hardware IOMMU for PCI passthru to PV guests, but having an IOMMU makes it more secure. PCI passthru to Xen HVM guests requires hardware IOMMU.<br />
<br />
Remember there's usually a separate configuration option for IOMMU IO Virtualization (VT-d) in the BIOS, so you need to enable IOMMU from the system BIOS before booting to Xen.<br />
<br />
For more information about using an IOMMU with Xen see [[Xen_PCI_Passthrough]] and [[VTd_HowTo]] wiki pages.<br />
<br />
== Xen complains about "hotplug scripts not working" ==<br />
<br />
This problem is often related to udev. Do you have udev installed? Is your udev the correct/supported version? This error usually has more information in the end revealing the real reason.. for example:<br />
<br />
<br />
<pre><br />
Error: Device 0 (vif) could not be connected. Could not find bridge device br0.<br />
</pre><br />
<br />
<br />
Which means exactly what it says.. the guest is configured to to use a bridge called "br0", but there's no such bridge in dom0. Run "brctl show" to verify what bridges you have. Create the missing bridge, or edit the VM cfgfile and make it use another (correct) bridge. <br />
<br />
<br />
<pre><br />
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.<br />
</pre><br />
<br />
<br />
This problem is often caused by not having "xen-netback" driver loaded in dom0 kernel.<br />
<br />
The hotplug scripts are located in /etc/xen/scripts by default, and are labeled with the prefix vif-*. Those scripts log to /var/log/xen/xen-hotplug.log, and more detailed information can be found there.<br />
<br />
<br />
<pre><br />
Error: Device 5632 (vbd) could not be connected. Path closed or removed during hotplug add: backend/vbd/2/5632 state: 1"<br />
</pre><br />
<br />
<br />
This problem can be caused by not having "xen-blkback" driver loaded in dom0 kernel.<br />
<br />
So when dealing with these problems always check you have all the required xen backend driver modules loaded in dom0 kernel! netbk or xen-netback for networking, and blkbk or xen-blkback for block devices (virtual disks). <br />
<br />
Also read /var/log/xen/xl*.log, it most probably includes additional information about the problem and the error messages.<br />
<br />
== I upgraded PV domU from old Xenlinux kernel to new pvops kernel, and now the domU doesn't work anymore! ==<br />
Many people seem to upgrade their Xen guest PV kernels at the same time they upgrade to a newer Xen version. This is actually not a required step! You can still use your old domU kernels with the new Xen version, and with a new dom0 kernel version. Xen hypervisor is the compatibility layer, so dom0 and domUs can have totally different kernels.<br />
<br />
Old Xenlinux PV kernels (linux-2.6.18-xen, ubuntu 2.6.24, debian 2.6.26, sles11 2.6.27, sles11 sp1 2.6.32, opensuse 2.6.31 etc) have different device names for virtual disks and virtual console than the new pvops (upstream kernel.org) Linux kernels. The old device names in Xenlinux kernels usually are:<br />
<br />
* /dev/sdX for virtual disks, for example /dev/sda<br />
* /dev/xvc0 for the virtual console<br />
The new device names in pvops kernels are:<br />
<br />
* /dev/xvdX for virtual disks, for example /dev/xvda. XVD = Xen Virtual Disk.<br />
* /dev/hvc0 for the virtual console<br />
So you need to do changes in the guest for it to boot up and work properly with the new kernel:<br />
<br />
* Fix "/etc/xen/<guest>" configuration file and change the virtual disks from /dev/sdX to /dev/xvdX<br />
* Fix domU kernel root filesystem parameter, ie. change root=/dev/sda1 to root=/dev/xvda1<br />
* Fix domU kernel console parameter, ie. have "earlyprintk=xen console=hvc0" in the extra="" section.<br />
* If you use pygrub to load the kernel/initrd from the guest filesystem then you need to make the changes above in the domU /boot/grub/grub.conf (or menu.lst).<br />
* Make sure the domU kernel has xen-blkfront driver built-in, or if it's built as a module (most common option), then you need to have a proper initrd (ramdisk) image for the domU kernel that actually loads the xen-blkfront driver so that the guest kernel can access the root filesystem! Failing to do this will cause the domU kernel to crash on boot because it can't find the root filesystem!<br />
* Note that you usually can't use the dom0 initrd image for a domU! dom0 initrd is generated for *dom0*, so it tries to load all the drivers for the *physical* hardware, while you have only virtual hardware in the domU! initrd ramdisk images are system specific, where dom0 and domU are different systems. Usually it's easiest to build an initrd/initramfs image for the domU in the *domU*. So boot the domU up with the old kernel, and generate an initrd image for the new pvops kernel. Make sure the new generated initrd-image loads xen-blkfront driver!<br />
* You need set up (or modify) a getty for the new console device in the domU init/inittab settings, so you can get a login prompt on the "xl console" session.<br />
* You need to add the console device name to "/etc/securetty" in the domU so root is allowed to login from the console.<br />
* If you're having networking problems with the new pvops domU kernels make sure you have "xen-netfront" driver loaded in the new kernel. It's usually built as a module in the recent pvops/upstream/distro kernels.<br />
Also see [[Migrate_from_Linux_2.6.18_to_2.6.31_and_higher]] wiki page for more information.<br />
<br />
== I can't connect to the console of my guest using "xl console <guest>" ==<br />
Do you have "xenconsoled" process running in dom0? If you do, did you try killing it and restarting it? Also, only one console session per domU can exist at a time. Currently, attempting to use more than one console session per domU will not raise an error, but will result in strange behavior.<br />
<br />
== Console of my PV guest shows kernel boot messages and then it stops and doesn't work anymore ==<br />
Do you have a getty configured for the console device in the guest? You usually need to add an entry to /etc/inittab in the guest to make the guest present login prompt on the "xl console" session. Is the getty configured for a correct console device? See the chapter below for correct guest console devices.<br />
<br />
Example "/etc/inittab" entry for Debian Lenny (linux-image-2.6.26-2-xen) guest, write this on a new (last) line:<br />
<br />
<br />
<pre><br />
vc:2345:respawn:/sbin/getty 38400 hvc0<br />
</pre><br />
<br />
Example "/etc/inittab" entry for CentOS 5 (kernel-xen-2.6.18) guest:<br />
<br />
<br />
<pre><br />
co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav<br />
</pre><br />
<br />
After modifying /etc/inittab in the guest, run "kill -1 1" to make init (process id 1) reload the configuration file on-the-fly, or reboot the guest. This should make the console work and login prompt appear on the "xm console" session.<br />
<br />
'''NOTE!''' Some distros (like newer Ubuntu) don't use "/etc/inittab" anymore, but instead you have to configure the gettys in other places! Ubuntu 9.10 and newer use "/etc/init/*.conf".<br />
<br />
<pre><br />
# hvc0 - getty<br />
#<br />
# This service maintains a getty on hvc0 from the point the system is<br />
# started until it is shut down again.<br />
start on stopped rc RUNLEVEL=[2345]<br />
stop on runlevel [!2345]<br />
respawn exec /sbin/getty -L hvc0 9600 linux<br />
</pre><br />
<br />
== Console of my PV guest is totally empty, it doesn't show anything, not even kernel boot messages! ==<br />
This usually means your PV (paravirtual) guest is using a newer pv_ops (upstream Linux kernel.org) kernel that has different console device name. You need to add "console=hvc0" to the guest kernel command line options.<br />
<br />
If you're using Xen pygrub or pv-grub to load the kernel from guests filesystem, then you need to configure the guest kernel settings in the guest /boot/grub/grub.conf (or menu.lst), not in dom0! So edit the guest /boot/grub/grub.conf (or menu.lst) and add the "console=hvc0" option there for the default kernel.<br />
<br />
If you're not using pygrub or pv-grub, aka you're configuring everything in /etc/xen/<guest> configuration file in dom0, and you have the kernel/initrd in dom0 filesystem, then you can specify the additional "console=hvc0" parameter in the /etc/xen/<guest> configuration file in dom0, on the extra="" line.<br />
<br />
== What's the correct console device name for my Xen PV guest ==<br />
* Most kernels use "hvc0" as the console device<br />
<br />
== How do I exit domU "xl console" session ==<br />
Press ctrl+] or if you're using Putty press ctrl+5.<br />
<br />
== Everything seems OK but I still can't access the domU "xl console"! ==<br />
A couple of things to check:<br />
<br />
* Do you have some old already running "xl console" session running on the host? possibly stuck in some dead ssh connection?<br />
* Do you have virt-manager running on the host 'reserving' the guest console?<br />
* Did it work earlier?<br />
* Do you have problems with only one guest, or with all guests?<br />
* Does shutting down and then re-starting the guest help?<br />
* Are you really sure you are running a getty in the guest for the correct console device? :)<br />
* Is the guest really up and running? Can you access it over the network with ssh? Can you ping it?<br />
<br />
== How can I limit the number of vcpus my dom0 has? ==<br />
The recommended way is to use "dom0_max_vcpus=X" boot time option for Xen hypervisor (xen.gz) in grub.conf. You need to reboot after modifying grub.conf. Using this method makes sure you allocate resources only for the actual number of vcpus you need in dom0.<br />
<br />
== Can I dedicate a cpu core (or cores) only for dom0? ==<br />
Yes, you can. It might a good idea especially for systems running IO intensive guests. Dedicating a CPU core only for dom0 makes sure dom0 always has free CPU time to process the IO requests for the domUs. Also when dom0 has a dedicated core there are less CPU context switches to do, giving better performance.<br />
<br />
Specify "dom0_max_vcpus=X dom0_vcpus_pin" options for Xen hypervisor (xen.gz) in grub.conf and reboot.<br />
<br />
After rebooting you can verify with "xl vcpu-list" that dom0 vcpus are pinned to only use the matching physical cpus.<br />
<br />
The next step is to configure all the guests (domUs) to NOT use those same physical cpus. This can be done by specifying for example cpus="2-7" to all /etc/xen/<guest> cfgfiles. This example would leave physical cpus/cores 0 and 1 only for dom0, and make the guests use cpus/cores 2 to 7.<br />
<br />
== In dom0 how can I access and mount partitions inside a Xen disk image? ==<br />
The easiest way is to use "kpartx" in dom0. It allows you to easily access all the partitions inside an image file or inside LVM volume.<br />
<br />
You can use "kpartx -l /path/guestdisk" to list the partitions the image has, and "kpartx -a /path/guestdisk" to add the partition mappings. After the device mapper (dm) mappings have been added, you can access the partitions using "/dev/mapper/guestdiskpX" block devices. There's a separate block device for each partition. You can mount, copy, format, or whatever you need to do and it works just like for "real" partitions.<br />
<br />
When you're done using the partitions in dom0, and you have unmounted them, you have to remove the kpartx mappings by running "kpartx -d /path/guestdisk". It's important to do this before using the image again for other purposes or starting the guest again! If you forget to remove the mappings the image might get corrupted when you access the image with other tools or start the guest.<br />
<br />
Another neat way which works for me, is to simply attach the block device to dom0 as you would to a domU. e.g.:<br />
<br />
<br />
<pre><br />
xl block-attach Domain-0 file:/disk/image/for/domU xvda w<br />
</pre><br />
<br />
I have found this to work for OSs which use slices (such as Solaris and *BSD), and are not picked up using kpartx. You should check dmesg and see which device nodes were created for you. Once you are done working with the disk image you can:<br />
<br />
<br />
<pre><br />
xl block-detach Domain-0 xvda<br />
</pre><br />
<br />
If your domU is LVM-based, see [[Access_Disk_from_DomUs_when_Xen_was_installed_with_LVM]]<br />
<br />
== Xen dom0 complains about not enough free loop devices when trying to start a new domU or when trying to "mount -o loop" from the cmdline ==<br />
Linux "loop" module has max 8 loop devices (/dev/loop*) as a default. Every Xen "file:" backed domU disk uses one loop device in dom0, and if you do "mount -o loop disk.img /mnt" in dom0 that uses a loop device aswell.<br />
<br />
You can check all the loop devices in use by running "losetup -a". You can detach a loop device (free it) by running "losetup -d /dev/loopX" when it's not mounted or otherwise in use.<br />
<br />
You can increase the amount of available loop devices by loading the linux "loop" module with an option "max_loop=X", for example "modprobe loop max_loop=128". You can add "max_loop=X" option to /etc/modprobe.conf, /etc/modules (or whatever cfgfile your dom0 distribution uses for module options) to make it boot time default.<br />
<br />
You can also use Xen "phy:" backed LVM volumes instead of disk images. "phy:" doesn't require loop devices.<br />
<br />
Such an error message may also be indicative of other issues (such as the guest crashing and restarting so quickly that xend does not have time to free the older loopback device).<br />
<br />
== My Xen PV guest kernel crashes, how can I debug it and get a stack/call trace? ==<br />
Edit "/etc/xen/<guest>" cfgfile, and set:<br />
<br />
<br />
<pre><br />
on_crash="preserve"<br />
</pre><br />
<br />
Then when your domU guest crashes, run this in dom0:<br />
<br />
<br />
<pre><br />
/usr/lib/xen/bin/xenctx -s System.map-domUkernelversion <domUid> <vcpu-number><br />
</pre><br />
<br />
If you're running 64bit dom0, then xenctx might be under "/usr/lib64/". This command will give you a stack trace of the crashed domU kernel on the specified vcpu, allowing you to see where it crashes. You should get the stack trace for every vcpu your guest has! Vcpu numbers start from 0.<br />
<br />
Note that you need to use the "System.map" file from the exact kernel version the domU is running, otherwise the stack trace results are not correct!<br />
<br />
== Can I run graphical X applications in Xen dom0 without installing X server and display drivers? ==<br />
Yes, you can. Many people prefer to not install any graphical drivers or X on dom0 for maximum stability. You can still run graphical applications using ssh X11 forwarding. You can run for example "virt-manager" in dom0 and display the GUI on your desktop/laptop over ssh.<br />
<br />
1) Install "xorg-x11-xauth" package in dom0 (centos/rhel/fedora, "xauth" in debian/ubuntu, other distros might have different name for it).<br />
<br />
2) Log in to dom0 from your Linux workstation like this: ssh -X root@dom0.<br />
<br />
3) After the password is accepted you should notice ssh setting up the ssh X11 forwarding like this:<br />
<br />
<br />
<pre><br />
/usr/bin/xauth: creating new authority file /root/.Xauthority<br />
</pre><br />
<br />
4) You can now run graphical X applications, for example vnc viewer, virt-viewer etc, and the GUI will be tunneled securely over ssh to your local X desktop.<br />
<br />
If you're using Windows you can install "xming" and "putty". Start Xming, and after that enable X11 forwarding in putty settings (Connection -> ssh -> X11 -> Enable X11 forwarding) and then connect to your dom0.<br />
<br />
== What emulated NIC types/models are available in Xen HVM fully virtualized guests? ==<br />
The following emulated network interface cards are available for Xen HVM guests in Xen 3.4:<br />
<br />
* e100<br />
* e1000<br />
* rtl8139<br />
* ne2k_pci<br />
* pcnet<br />
Emulation is done by Qemu-dm running for each Xen HVM guest. Intel e1000 is known to be the best performing emulated NIC. Even faster is to use PV-on-HVM drivers, which totally bypasses emulation.<br />
<br />
Older Xen versions might not have all the above NIC options available.<br />
<br />
== Can I set up Xen HVM Linux guest to display the kernel boot messages on "xl console" ? ==<br />
Yes, you can. You need to add this line to the "/etc/xen/<hvmguest>" configuration file in dom0:<br />
<br />
<br />
<pre><br />
serial='pty'<br />
</pre><br />
<br />
<br />
And then in the HVM guest grub.conf (inside the HVM VM) configure kernel logging to the (virtual) serial port like this:<br />
<br />
<br />
<pre><br />
#============================================================<br />
# display the grub kernel selector menu on the serial console<br />
serial --unit=0 --speed=9600<br />
terminal --timeout=5 serial console<br />
# kernel entries title openSUSE 11.1 - 2.6.27.29-0.1<br />
root (hd0,1)<br />
kernel /boot/vmlinuz-2.6.27.29-0.1-default root=LABEL=ROOT resume=LABEL=SWAP splash=silent showopts console=tty1 console=ttyS0<br />
initrd /boot/initrd-2.6.27.29-0.1-default<br />
#================================================<br />
</pre><br />
<br />
<br />
So basicly you need to add "console=ttyS0" to the kernel line, and also configure grub to display the kernel selector on the (virtual) serial console using "serial" and "terminal" settings.<br />
<br />
After these settings "xl console <hvmguest>" works just like it does for PV (paravirtual) guests and allows you to see grub and the Linux kernel boot messages of the HVM guest. You can also use other tools (minicom, screen, etc) in dom0 to access the VM console pty device directly.<br />
<br />
Also remember to set up a getty in the guest for the serial console device, ttyS0, so that you can also login from the serial console! See above for tips about that.<br />
<br />
== How can I boot Xen HVM guest from a virtual emulated floppy, using an image file as the floppy? ==<br />
This is the required configuration in "/etc/xen/<hvmguest>" cfgfile:<br />
<br />
<br />
<pre><br />
fda = '/path/to/floppy.img' boot=a<br />
</pre><br />
<br />
You can also use this cmdline method while creating the guest:<br />
<br />
<br />
<pre><br />
xm create /etc/xen/hvmguest.cfg fda=/path/to/floppy.img boot=a<br />
</pre><br />
<br />
Important note: Make sure SElinux access restrictions are not blocking access to /path/to/floppy.img!<br />
<br />
== How do I change virtual/emulated CD .iso image for a Xen HVM guest? ==<br />
First check "/etc/xen/<guest>" cfgfile and check what is your cdrom device in the guest. It's usually "/dev/hdc".<br />
<br />
An example to swap the emulated CD using an iso image:<br />
<br />
<br />
<pre><br />
xl block-configure <guest> file:/path/to/new/cd.iso hdc:cdrom r<br />
</pre><br />
<br />
== Are there FreeBSD Xen PV kernels/images available? ==<br />
Please check the following link: http://wiki.freebsd.org/FreeBSD/Xen .<br />
<br />
== Where can I find information about NetBSD Xen support? ==<br />
NetBSD supports both Xen dom0 and PV domUs. For more information see: http://www.netbsd.org/ports/xen/<br />
<br />
== What's Xen pygrub? ==<br />
Pygrub allows you to simply specify in Xen PV guest "/etc/xen/<guest>" cfgfile:<br />
<br />
<br />
<pre><br />
bootloader = "/usr/bin/pygrub"<br />
</pre><br />
<br />
Which replaces all these options:<br />
<br />
<br />
<pre><br />
kernel = "vmlinuz-2.6.32.12"<br />
ramdisk = "initrd-2.6.32.12.img"<br />
root = "/dev/xvda1"<br />
extra = "earlyprintk=xen console=hvc0"<br />
</pre><br />
<br />
When you start a Xen PV guest pygrub will be executed in dom0 and it'll access the guest disk configured in the "/etc/xen/<guest>" cfgfile, find "/boot/grub/grub.conf" (or menu.lst) from the guest filesystem, parse it, fetch the kernel, initrd image and kernel parameters configured in the guest to dom0, and then boot up the guest using those kernel + initrd + parameters. All the domU specific settings are configured inside the domU, in grub.conf.<br />
<br />
Requirements for using pygrub for Xen PV domUs:<br />
<br />
* Pygrub binary available in dom0, installed together with Xen.<br />
* Pygrub configured for the guest in "/etc/xen/<guest>" cfgfile<br />
* Guest has /boot/grub/grub.conf (or menu.lst) with proper entries in it. There's actually no need to install the real grub to the MBR of the guest disk, it's enough to just have the grub.conf/menu.lst in the guest.<br />
<br />
Pygrub makes it much easier to:<br />
<br />
* Manage the guest kernels inside every guest, keeping the guest distribution package managers (dpkg,rpm) and package dependencies happy.<br />
* Upgrade guest kernels without touching dom0 or guest configuration files in "/etc/xen/" in dom0.<br />
* Each guest distribution can easily use the default kernel provided by the distribution.<br />
* Pygrub allows you to select which kernel to boot, in the "xl console <guest>" session. It's easiest to start the guest with "xl create -c /etc/xen/guest" to attach to the console immediate for selecting the kernel from pygrub menu. If nothing is chosen then the default entry will be booted automatically.<br />
Management tools like "virt-install" and "virt-manager" will use Xen pygrub as a default when you install new guests using them.<br />
<br />
== What's Xen pvgrub? ==<br />
Xen pvgrub is like pygrub but more secure.<br />
<br />
Pygrub is executed in dom0, so it could have security concerns/issues, if bugs were found from it. Pvgrub is executed in the Xen PV guest, so there are no such security issues with it.<br />
<br />
Pvgrub is a separate build and separate tool, so usually it's easier to begin with pygrub, and then later switch to pvgrub.<br />
<br />
See [[PvGrub]] wiki page for more information and usage of pvgrub.<br />
<br />
== Does Xen pygrub support booting PV guests using GRUB2 config files? ==<br />
Yes, pygrub supports guests using GRUB2 config files.<br />
<br />
== Can I browse the Xen source trees online? ==<br />
Yes, you can browse the source tree and see the changelogs/summaries and track changes online from the [[XenRepositories]] wiki page.<br />
<br />
== Can I browse the Xen Qemu-dm (HVM guest ioemu) source repositories online? ==<br />
Yes, you can see the changelogs/summaries and track changes online from the [[XenRepositories]] wiki page.<br />
<br />
<br />
== Arp change notification problems after live migration when using pvops 2.6.32.x dom0 kernel ==<br />
You need to have new enough version of pvops dom0 kernel (xen/stable-2.6.32.x branch, Aug 2010 or newer) and then you can enable "net.ipv4.conf.<dev>.arp_notify" sysctl setting for the devices where you want to send the arp notifications (gratuitous ARP). See this email for more information: http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01595.html .<br />
<br />
== Starting xend fails? ==<br />
Xend has been deprecated as of Xen 4.2.0. You should therefore not use the command '''xm''' any more. Instead, you should use the new '''xl''' command, which should be binary compatible.<br />
<br />
== How to specify custom (non-default) vif-script for some domU network interface? ==<br />
Here's an example how to have 2 nics (vifs) for the domU, each using different vif-script:<br />
<br />
<br />
<pre><br />
vif = [ 'mac=00:16:5e:72:04:01,bridge=xenbr0,script=your_custom_script1', 'mac=00:16:5e:72:04:02,bridge=xenbr1,script=your_custom_script2' ]<br />
</pre><br />
<br />
== Problems with Xen on Redhat Enterprise Linux 5 (RHEL5) or CentOS5 ==<br />
<br />
Try these links:<br />
* http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/Virtualization/index.html<br />
* http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/Virtualization/index.html#part-Virtualization-Troubleshooting<br />
<br />
== I'd like to run Xen hypervisor/dom0 on Redhat Enterprise Linux 6 (RHEL6) ==<br />
<br />
See this wiki page for a Xen 4.0 with RHEL6 tutorial and more info: [[RHEL6Xen4Tutorial]] .<br />
<br />
== How do I change the resolution of Xen PV domU vfb graphical VNC console? ==<br />
<br />
You can specify the pvfb (paravirtual framebuffer) resolution and bpp (amount of colors) for the VM while loading the xen-fbfront driver in the domU kernel.<br />
<br />
If xen-fbfront is built as a module, use the following options:<br />
<br />
<pre><br />
modprobe xen-fbfront video="32,1024,768"<br />
</pre><br />
<br />
Or add the options to "/etc/modprobe.conf", or whatever file your domU distro uses for driver module options. Note that you might need to regenerate the initrd/initramfs image for the domU kernel if the xen-fbfront driver is auto-loaded at boot time.<br />
<br />
Or if xen-fbfront driver is built-in to the domU kernel, use the following cmdline options for the domU kernel:<br />
<br />
<pre><br />
xen-fbfront.video=32,1024,768<br />
</pre><br />
<br />
If you're using Xen pygrub you can place that option to grub configfile inside the domU "/boot/grub/" directory, or if you're using kernel/ramdisk from dom0, then add those options to "extra" line on /etc/xen/<domU> on dom0.<br />
<br />
== How can I get resolutions larger than 800x600 for Xen HVM guest graphical VNC console? ==<br />
<br />
Edit "/etc/xen/<hvmvm>" cfgfile and add the following options:<br />
<br />
<pre><br />
stdvga=1<br />
videoram=16<br />
</pre><br />
<br />
This will increase the amount of virtual video memory in the HVM VM, allowing it to use bigger resolutions, up to 2048x1536 @ 32bpp. If you don't specify "stdvga=1", ie. you keep using the Cirrus emulated graphics adapter, resolutions up to 1280x1024 are possible with "videoram=16".<br />
<br />
After increasing the size of vram configure the resolution from inside the HVM guest in the usual way, just like you'd do on baremetal/native, using the resolution selector or configfile provided by the operating system in the VM.<br />
<br />
== I'm trying to create a new Xen VM but I get error there's not enough free memory ==<br />
<br />
Tools like "free" or "top" in Xen dom0 show that you have a lot of free memory, but Xen still complains that there's not enough free memory to create/start a new VM, giving errors such as "Out of memory". This usually happens because dom0 is using all the memory, so there's no free memory in the Xen hypervisor (xen.gz) for other VMs. Note that dom0 is actually a Xen virtual machine! <br />
<br />
Xen hypervisor dedicates physical memory for each VM, so you need to have actual free unallocated memory in the hypervisor to start a VM. You can check the Xen hypervisor memory usage with the following commands:<br />
<br />
Check the amount of total, used and free memory in Xen hypervisor:<br />
<br />
<pre><br />
xl info<br />
</pre><br />
<br />
<br />
and check how much memory each VM is using:<br />
<br />
<br />
<pre><br />
xl list<br />
</pre><br />
<br />
<br />
It's possible that dom0 is using most of your memory and Xen hypervisor doesn't have any free memory left. You should use "dom0_mem=" setting for Xen in grub to configure dom0 a fixed/dedicated amount of memory, so the rest of the memory is free for other VMs to use. See [[XenBestPractices:]] wiki page for more info about configuring "dom0_mem=" option for Xen.<br />
<br />
== Error: (4, 'Out of memory', 'panic: xc_dom_core.c:442: xc_dom_alloc_segment: segment ramdisk too large (0xee93 > 0x8000 - 0x1755 pages)') ==<br />
<br />
Getting this error when trying to start a new VM (running "xl create") means you're trying to use too big ramdisk image (initrd/initramfs file) for the domU. The ramdisk image configured is bigger than the amount of available memory for the VM. Remember the ramdisk images are compressed, and they need to fit as uncompressed to the domU memory. By modifying /etc/initramfs-tools/initramfs.conf, to set MODULES=dep, you can decrease the size of the generated initramfs.<br />
<br />
== What's the difference between vifX.Y and tapX.Y network interfaces in dom0? ==<br />
<br />
vifX.Y network interfaces are used with domUs (VMs) using paravirtualized network drivers, which means for pure PV domUs or for Xen HVM guests with paravirtualized PVHVM drivers in use. tapX.Y interfaces are used for HVM guests which are using emulated virtual NICs (Intel E1000, Realtek RTL8139, NE2k).<br />
<br />
vifX.Y interfaces are created by the xen-netback backend driver in dom0 kernel. The frontend driver xen-netfront runs in the kernel of each VM.<br />
<br />
There's exactly one vif/tap interface per virtual NIC in the VM. "X" means the domain ID, and "Y" is the number of the virtual NIC. So if you have a domU with ID 5 with 3 virtual NICs (eth0, eth1, eth2), the corresponding VIF interfaces in dom0 would be vif5.0, vif5.1, vif5.2. <br />
<br />
== How can I use Xen PVHVM optimized paravirtualized drivers with Ubuntu 11.10 or Fedora 16 HVM guests? ==<br />
<br />
Please see the [[Xen_Linux_PV_on_HVM_drivers]] wiki page for more information about Xen PVHVM drivers.<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_Common_Problems&diff=5070Xen Common Problems2012-09-24T11:01:46Z<p>OliverChick: /* How can I check the version of Xen hypervisor? */ xm -> xl</p>
<hr />
<div><!-- MoinMoin name: XenCommonProblems --><br />
<!-- Comment: Copied "Xend does not start when using pv_ops dom0 kernel?" from the Paravirt page in this. --><br />
<!-- WikiMedia name: XenCommonProblems --><br />
<!-- Page revision: 00000167 --><br />
<!-- Original date: Wed Oct 26 18:28:24 2011 (1319653704000000) --><br />
<br />
{{Needs_Refactor|This page is a left over from the old Xen wiki and contained many recent FAQs. The key question is what to do with these. We have created [[:Category:FAQ]] which has articles that list FAQs by topic. We could break this article up and move the content to pages listed in [[:Category:FAQ]]. Please provide a view by making a comment in [[Talk:Xen Common Problems]]. Also note that some of the questions are a little out-of-date.}}<br />
<br />
'''Answers to some common problems and questions about Xen''' <br />
<!-- ! TOC here --><br />
<br />
== I'd like to contribute to the Xen wiki pages, I have something to add/edit/fix, how can I do it? ==<br />
Contributions are very welcome! You should create yourself a wiki account. No edit permissions are needed. More info on getting started at<br />
* [[Special:UserLogin|Create an account or log in]]<br />
* [[Sandbox|Play with the Sandbox]]<br />
* [http://upload.wikimedia.org/wikipedia/commons/8/89/Cheatsheet-mediawiki.pdf MediaWiki Cheat Sheet]<br />
* [http://www.mediawiki.org/wiki/Help:Contents MediaWiki Help Contents]<br />
* [http://www.mediawiki.org/wiki/Help:Formatting MediaWiki Formatting]<br />
* [http://www.mediawiki.org/wiki/Books_about_MediaWiki Books about MediaWiki]<br />
* [[Wiki_Community|Wiki Community Portal]]<br />
* [[:Category:Wiki Management|Wiki Management Tools]]<br />
* [[Xen:Multi-language Conventions|Multi-language Conventions]]<br />
<br />
== I'd like to read some kind of overview about Xen ==<br />
See the [[XenOverview]] wiki page and [[:Category:Overview]]. Also check the following PDF documents (which are somewhat out-of-date):<br />
<br />
* http://www.xen.org/files/Marketing/WhatisXen.pdf<br />
* http://www.xen.org/files/Marketing/WhyXen.pdf<br />
* http://www.xen.org/files/Marketing/NewtoXenGuide.pdf<br />
* http://www.xen.org/files/Marketing/HowDoesXenWork.pdf<br />
<br />
== Where can I read about the history of Xen? ==<br />
Please see: http://www.xen.org/community/xenhistory.html<br />
<br />
== I'm interesting in being a Xen developer! Are there projects to work on? ==<br />
Yes! Please check the [[XenDevelopmentProjects]] wiki page for more information!<br />
<br />
== How does Xen compare to KVM? Which one is better? ==<br />
Please see this blog post for more information: http://blog.xen.org/index.php/2010/05/07/xen-%E2%80%93-kvm-linux-%E2%80%93-and-the-community/<br />
<br />
Also check these documents:<br />
<br />
* http://www.slideshare.net/xen_com_mgr/why-xen-slides<br />
* http://blog.xen.org/index.php/2010/07/30/why-xen-paper-published/<br />
<br />
== Is there a "Best Practices" document available? ==<br />
See the [[XenBestPractices]] wiki page.<br />
<br />
== Where can I find a list of available Xen dom0 kernels? ==<br />
See the [[XenDom0Kernels]] wiki page.<br />
<br />
== Where can I find a list of available features in different Xen kernels? ==<br />
See the [[XenKernelFeatures]] wiki page.<br />
<br />
== I have problems getting Xen or dom0 kernel to boot, how can I set up a serial console to log and troubleshoot the boot process? ==<br />
See the [[XenSerialConsole]] wiki page.<br />
<br />
== Where can I find a list of all the available domU configuration options in /etc/xen/<guest> cfgfile? ==<br />
See the [[XenConfigurationFileOptions]] wiki page.<br />
<br />
== Is there a list of all available Xen hypervisor (xen.gz) commandline boot options for grub.conf? ==<br />
Yes, please see the [[XenHypervisorBootOptions]] wiki page.<br />
<br />
== Can I passthrough an USB device connected to dom0 to a Xen guest? ==<br />
Yes, please see the [[XenUSBPassthrough]] wiki page.<br />
<br />
== Can I passthrough a PCI device to Xen guest? ==<br />
Yes, please see the [[XenPCIpassthrough]] wiki page.<br />
<br />
== Can I passthru a VGA graphics adapter to Xen guest? ==<br />
Yes, please see the [[XenVGAPassthrough]] wiki page.<br />
<br />
== I have problems using my graphics card in Xen dom0, with the pvops dom0 kernel.. any tips? ==<br />
Yes, please see the [[XenPVOPSDRM]] wiki page.<br />
<br />
== Is there more information about Xen PVSCSI passthrough functionality? ==<br />
Yes, please see the [[XenPVSCSI]] wiki page.<br />
<br />
== Is there more information about Xen "blktap" disk backend? ==<br />
Yes, Xen actually has two blktap backends:<br />
<br />
* blktap1: please see the [[blktap]] wiki page for more information.<br />
* blktap2: please see the [[blktap2]] wiki page for more information.<br />
blktap2 supports VHD images, and is considered much more robust than the old blktap1 qemu/qcow image file support. Xen 4.0 includes blktap2 support. Note that also the dom0 kernel needs to have the blktap2 driver.<br />
<br />
== Is there a list of various 3rd party management tools and (web) interfaces for Xen or XCP? ==<br />
Yes, please see the [[XenManagementTools]] wiki page.<br />
<br />
== Is there more information about Xen Fault Tolerance, aka Remus Transparent High Availability (HA) for VMs? ==<br />
Yes, please see the [[Remus]] wiki page for more information.<br />
<br />
== Where can I find optimized Xen PV-on-HVM drivers for Linux HVM (fully virtualized) guests? ==<br />
Please see the [[XenLinuxPVonHVMdrivers]] wiki page.<br />
<br />
== Do you have a list of Xen related research papers? ==<br />
Yes, please see http://www.xen.org/community/xenpapers.html<br />
<br />
== Where can I find information about Xen on RISC CPUs? ==<br />
* Please see [[XenARM]] wiki page for Xen on ARM CPUs. Xen ARM project is actively developed.<br />
* Please see [[Xen_ARMv7_with_Virtualization_Extensions]] wiki page for Xen on ARMv7 CPUs with Virtualization Extensions. This project is actively developed.<br />
* Xen has also been ported to MIPS64 platform. See the Netlogic Microsystems press release for more information: http://vmblog.com/archive/2012/01/30/netlogic-microsystems-announces-the-industry-s-first-open-source-xen-hypervisor-for-multi-core-mips64-processors.aspx or the xen-devel mailinglist post: http://lists.xen.org/archives/html/xen-devel/2012-01/msg00301.html .<br />
* Please see [[XenPPC]] wiki page for Xen on PowerPC CPUs. XenPPC project is not active anymore.<br />
== What's the difference between Xen hypervisor (from xen.org) and Citrix [[XenServer]] or XCP? ==<br />
Xen hypervisor from xen.org is the core hypervisor used in many different products. It includes basic command line management tools. It is distributed as a tarball and from mercurial source code repositories. You need to compile and install Xen hypervisor from sources, and combine it with a kernel of your choice. It can be thought as the "core engine" you can use to build your own virtualization platform.<br />
<br />
Many Linux distributions package Xen and distribute it as prebuilt binaries, combined with Xen capable kernels of their choice. There are many additional thirdparty management tools available to manage the Xen hypervisor.<br />
<br />
There are multiple companies shipping products based on the Xen hypervisor, including Citrix, Oracle, Novell, Redhat, and others.<br />
<br />
Citrix [[XenServer]] is a commercial product that includes the core Xen hypervisor from xen.org, combined with CentOS-based dom0 distro, management toolstack, and everything else required to build a ready made virtualization platform. Citrix [[XenServer]] is a dedicated virtualization platform (not a general purpose Linux distro), and it is shipped as a ready to install ISO-image that contains everything you need out-of-the-box. Citrix [[XenServer]] includes the XAPI management toolstack (which not included in the core Xen hypervisor from xen.org), allowing you to pool multiple Xen hosts together and manage them centrally using either the graphical Citrix [[XenCenter]] management tool, the 'xe' commandline tool or using the XenAPI directly from your scripts. Citrix [[XenCenter]] graphical management tool is only available for Windows.<br />
<br />
Xen Cloud Platform (XCP) was announced in 2009, and it is the opensourced version of Citrix [[XenServer]], including the XAPI management toolstack. XCP and XAPI are now developed on xen.org repositories. XCP is shipped as ready to install ISO-images, just like Citrix [[XenServer]]. Citrix is basing their new Citrix [[XenServer]] releases on XCP. XCP includes the XenAPI provided by the XAPI toolstack and the 'xe' commandline tool. XCP does not include Citrix [[XenCenter]] and Citrix [[XenCenter]] cannot be used to manage XCP. XCP users can use the opensource [[OpenXenManager]] instead, which runs on Linux. See http://www.xen.org/products/cloudxen.html for more information about XCP.<br />
<br />
== How can I check the version of Xen hypervisor? ==<br />
Run "xl info" in dom0. You can find the hypervisor version in "xen_major", "xen_minor" and "xen_extra" fields. The version is major.minor.extra.<br />
<br />
Determining the version from within a domU is dependent on the guest operating system. For Linux guests:<br />
<br />
<br />
<pre><br />
$ dmesg | grep Xen\ version<br />
Xen version: 3.4.2 (preserve-AD)<br />
</pre><br />
<br />
== What are the names of different hardware features related to virtualization and Xen? ==<br />
<br />
* Xen supports running PV (paravirtualized) VMs on any PAE-capable x86 or x86_64 CPU (both Intel and AMD CPUs). CPU Virtualization extensions are NOT required or used to run Xen PV domUs.<br />
* Xen requires CPU Virtualization Extensions to run Xen HVM (Fully Virtualized) VMs. Also the system BIOS needs to support and enable the CPU Virtualization extensions.<br />
* CPU Virtualization extensions are called Intel VT-x or AMD-V and they are required for running Xen HVM guests.<br />
* HAP (Hardware Assisted Paging) can be optionally used to boost the performance of Xen memory management for HVM VMs. HAP is an additional feature of the CPU, and it's not present on older CPUs. Intel HAP is called Intel EPT (Extended Page Tables) and AMD HAP is called AMD NPT (Nested Page Tables). AMD NPT is sometimes also referred as AMD RVI (Rapid Virtualization Indexing).<br />
* IOMMU (IO Memory Management Unit) support from CPU/BIOS/chipset is needed for Xen IO Virtualization. IOMMU makes it possible to dedicate PCI device securely to a Xen VM by using Xen PCI passthru. Intel IOMMU is called Intel VT-d, and AMD IOMMU is called just AMD IOMMU. <br />
* SR-IOV (Single Root IO Virtualization) can be used together with IOMMU PCI passthru and PCI Express SR-IOV capable devices. SR-IOV needs to be supported and enabled by the system chipset, BIOS and the PCI-e device itself. For example Intel 82599 10 Gigabit Ethernet NIC supports 64 Virtual Functions (VFs), which means the NIC can be configured to show up as 64 different PCI devices (PCI IDs), so you can use Xen PCI passthru to passthrough each VF to some Xen VM and give the VM direct access to the PCI-e device. SR-IOV provides excellent IO performance and very low overhead.<br />
<br />
== How can I check if I'm able to run Xen HVM (fully virtualized) guests? ==<br />
Xen requires CPU virtualization support/extensions (Intel VT, AMD-V) for running HVM guests (=Windows). Virtualization support needs to be enabled in the system BIOS. Intel calls this feature also as "VT-x". Also note that Intel "VT-x" is different from "VT-d", which is a totally different feature (see the next section below).<br />
<br />
NOTE that Linux dom0 kernel doesn't see 'vmx' or 'svm' CPU flags in "/proc/cpuinfo" because Xen *hypervisor* (xen.gz) is using the hardware virtualization features and hiding the flags from dom0! Xen dom0 is actually a virtual machine, so it doesn't see all the cpu flags as Xen hypervisor is hiding some flags from dom0.<br />
<br />
You can run "xm info" in dom0 and check from the 'xen_caps' line if Xen is able to run hvm guests. Also Xen hypervisor boot messages in "xm dmesg" show if hardware virtualization (HVM) is enabled or disabled.<br />
<br />
Example "xm dmesg | grep -i hvm" output for an Intel system where HVM is supported by the CPU:<br />
<br />
<br />
<pre><br />
(XEN) HVM: VMX enabled<br />
</pre><br />
<br />
Example "xm dmesg" output for an Intel system where HVM is supported by the CPU but it's disabled in the system BIOS:<br />
<br />
<br />
<pre><br />
(XEN) VMX disabled by Feature Control MSR.<br />
</pre><br />
<br />
Example "xm dmesg | grep -i hvm" output for an AMD system where HVM is supported:<br />
<br />
<br />
<pre><br />
(XEN) HVM: SVM enabled<br />
</pre><br />
<br />
You can also see the HVM support status from the "xen_caps" line on Xen hypervisor "xm info | grep xen_caps" output:<br />
<br />
<br />
<pre><br />
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64<br />
</pre><br />
<br />
== How can I check if my CPU supports HAP (Hardware Assisted Paging) ? ==<br />
<br />
You can check Xen dmesg by running "xm dmesg" to verify if HAP is supported on your CPU:<br />
<br />
<pre><br />
(XEN) HVM: Hardware Assisted Paging detected and enabled.<br />
</pre><br />
<br />
Newer Xen versions (4.1.3+, 4.2.x+) will have info like this:<br />
<pre><br />
(XEN) HVM: Hardware Assisted Paging (HAP) detected<br />
(XEN) HVM: HAP page sizes: 4kB, 2MB<br />
</pre><br />
<br />
HAP support is provided by the following features on CPUs:<br />
* Intel EPT (Extended Page Tables).<br />
* AMD NPT (Nested Page Tables, sometimes also called as AMD RVI - Rapid Virtualization Indexing).<br />
<br />
== How can I check if my hardware has an IOMMU (VT-d) and it's enabled and supported? ==<br />
Hardware IOMMU (Intel VT-d) is required for hardware assisted PCI passthru (I/O virtualization) to Xen HVM (fully virtualized) guest VMs. You can check for IOMMU status from "xm dmesg" output.<br />
<br />
Example "xm dmesg" output for a system where IOMMU is supported:<br />
<br />
<br />
<pre><br />
(XEN) I/O virtualisation enabled<br />
</pre><br />
<br />
Example "xm dmesg" output for a system where IOMMU is not supported:<br />
<br />
<br />
<pre><br />
(XEN) I/O virtualisation disabled<br />
</pre><br />
<br />
You might also see additional output like:<br />
<br />
<br />
<pre><br />
(XEN) Intel VT-d Snoop Control supported.<br />
(XEN) Intel VT-d DMA Passthrough not supported.<br />
(XEN) Intel VT-d Queued Invalidation supported.<br />
(XEN) Intel VT-d Interrupt Remapping not supported.<br />
</pre><br />
<br />
And if hardware IOMMU is used for PV guest PCI passthru or not:<br />
<br />
<br />
<pre><br />
(XEN) I/O virtualisation for PV guests enabled<br />
</pre><br />
<br />
Xen doesn't require hardware IOMMU for PCI passthru to PV guests, but having an IOMMU makes it more secure. PCI passthru to Xen HVM guests requires hardware IOMMU.<br />
<br />
Remember there's usually a separate configuration option for IOMMU IO Virtualization (VT-d) in the BIOS, so you need to enable IOMMU from the system BIOS before booting to Xen.<br />
<br />
For more information about using an IOMMU with Xen see [[Xen_PCI_Passthrough]] and [[VTd_HowTo]] wiki pages.<br />
<br />
== Xen complains about "hotplug scripts not working" ==<br />
<br />
This problem is often related to udev. Do you have udev installed? Is your udev the correct/supported version? This error usually has more information in the end revealing the real reason.. for example:<br />
<br />
<br />
<pre><br />
Error: Device 0 (vif) could not be connected. Could not find bridge device br0.<br />
</pre><br />
<br />
<br />
Which means exactly what it says.. the guest is configured to to use a bridge called "br0", but there's no such bridge in dom0. Run "brctl show" to verify what bridges you have. Create the missing bridge, or edit the VM cfgfile and make it use another (correct) bridge. <br />
<br />
<br />
<pre><br />
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.<br />
</pre><br />
<br />
<br />
This problem is often caused by not having "xen-netback" driver loaded in dom0 kernel.<br />
<br />
The hotplug scripts are located in /etc/xen/scripts by default, and are labeled with the prefix vif-*. Those scripts log to /var/log/xen/xen-hotplug.log, and more detailed information can be found there.<br />
<br />
<br />
<pre><br />
Error: Device 5632 (vbd) could not be connected. Path closed or removed during hotplug add: backend/vbd/2/5632 state: 1"<br />
</pre><br />
<br />
<br />
This problem can be caused by not having "xen-blkback" driver loaded in dom0 kernel.<br />
<br />
So when dealing with these problems always check you have all the required xen backend driver modules loaded in dom0 kernel! netbk or xen-netback for networking, and blkbk or xen-blkback for block devices (virtual disks). <br />
<br />
Also read the full "xm log", it most probably includes additional information about the problem and the error messages.<br />
<br />
== I upgraded PV domU from old Xenlinux kernel to new pvops kernel, and now the domU doesn't work anymore! ==<br />
Many people seem to upgrade their Xen guest PV kernels at the same time they upgrade from older Xen version to Xen 3.4.x or Xen 4.0.x. This is actually not a required step! You can still use your old domU kernels with the new Xen version, and with a new dom0 kernel version. Xen hypervisor is the compatibility layer, so dom0 and domUs can have totally different kernels.<br />
<br />
Old Xenlinux PV kernels (linux-2.6.18-xen, ubuntu 2.6.24, debian 2.6.26, sles11 2.6.27, sles11 sp1 2.6.32, opensuse 2.6.31 etc) have different device names for virtual disks and virtual console than the new pvops (upstream kernel.org) Linux kernels. The old device names in Xenlinux kernels usually are:<br />
<br />
* /dev/sdX for virtual disks, for example /dev/sda<br />
* /dev/xvc0 for the virtual console<br />
The new device names in pvops kernels are:<br />
<br />
* /dev/xvdX for virtual disks, for example /dev/xvda. XVD = Xen Virtual Disk.<br />
* /dev/hvc0 for the virtual console<br />
So you need to do changes in the guest for it to boot up and work properly with the new kernel:<br />
<br />
* Fix "/etc/xen/<guest>" configuration file and change the virtual disks from /dev/sdX to /dev/xvdX<br />
* Fix domU kernel root filesystem parameter, ie. change root=/dev/sda1 to root=/dev/xvda1<br />
* Fix domU kernel console parameter, ie. have "earlyprintk=xen console=hvc0" in the extra="" section.<br />
* If you use pygrub to load the kernel/initrd from the guest filesystem then you need to make the changes above in the domU /boot/grub/grub.conf (or menu.lst).<br />
* Make sure the domU kernel has xen-blkfront driver built-in, or if it's built as a module (most common option), then you need to have a proper initrd (ramdisk) image for the domU kernel that actually loads the xen-blkfront driver so that the guest kernel can access the root filesystem! Failing to do this will cause the domU kernel to crash on boot because it can't find the root filesystem!<br />
* Note that you usually can't use the dom0 initrd image for a domU! dom0 initrd is generated for *dom0*, so it tries to load all the drivers for the *physical* hardware, while you have only virtual hardware in the domU! initrd ramdisk images are system specific, where dom0 and domU are different systems. Usually it's easiest to build an initrd/initramfs image for the domU in the *domU*. So boot the domU up with the old kernel, and generate an initrd image for the new pvops kernel. Make sure the new generated initrd-image loads xen-blkfront driver!<br />
* You need set up (or modify) a getty for the new console device in the domU init/inittab settings, so you can get a login prompt on the "xm console" session.<br />
* You need to add the console device name to "/etc/securetty" in the domU so root is allowed to login from the console.<br />
* If you're having networking problems with the new pvops domU kernels make sure you have "xen-netfront" driver loaded in the new kernel. It's usually built as a module in the recent pvops/upstream/distro kernels.<br />
Also see [[Migrate_from_Linux_2.6.18_to_2.6.31_and_higher]] wiki page for more information.<br />
<br />
== I can't connect to the console of my guest using "xm console <guest>" ==<br />
Do you have "xenconsoled" process running in dom0? If you do, did you try killing it and restarting it? Also, only one console session per domU can exist at a time. Currently, attempting to use more than one console session per domU will not raise an error, but will result in strange behavior.<br />
<br />
== Console of my PV guest shows kernel boot messages and then it stops and doesn't work anymore ==<br />
Do you have a getty configured for the console device in the guest? You usually need to add an entry to /etc/inittab in the guest to make the guest present login prompt on the "xm console" session. Is the getty configured for a correct console device? See the chapter below for correct guest console devices.<br />
<br />
Example "/etc/inittab" entry for Debian Lenny (linux-image-2.6.26-2-xen) guest, write this on a new (last) line:<br />
<br />
<br />
<pre><br />
vc:2345:respawn:/sbin/getty 38400 hvc0<br />
</pre><br />
<br />
Example "/etc/inittab" entry for CentOS 5 (kernel-xen-2.6.18) guest:<br />
<br />
<br />
<pre><br />
co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav<br />
</pre><br />
<br />
After modifying /etc/inittab in the guest, run "kill -1 1" to make init (process id 1) reload the configuration file on-the-fly, or reboot the guest. This should make the console work and login prompt appear on the "xm console" session.<br />
<br />
'''NOTE!''' Some distros (like newer Ubuntu) don't use "/etc/inittab" anymore, but instead you have to configure the gettys in other places!<br />
<br />
Ubuntu 6.06 LTS is the last ubuntu version to use "/etc/inittab" configuration file. Ubuntu 6.10 to 9.04 use "/etc/event.d/*" configuration files to configure init. Ubuntu 9.10 and newer use "/etc/init/*.conf".<br />
<br />
Example "/etc/init/hvc0.conf" entry for Ubuntu 10.04 Xen PV (linux-image-2.6.32) guest:<br />
<br />
<br />
<pre><br />
# hvc0 - getty<br />
#<br />
# This service maintains a getty on hvc0 from the point the system is<br />
# started until it is shut down again.<br />
start on stopped rc RUNLEVEL=[2345]<br />
stop on runlevel [!2345]<br />
respawn exec /sbin/getty -L hvc0 9600 linux<br />
</pre><br />
<br />
== Console of my PV guest is totally empty, it doesn't show anything, not even kernel boot messages! ==<br />
This usually means your PV (paravirtual) guest is using a newer pv_ops (upstream Linux kernel.org) kernel that has different console device name. You need to add "console=hvc0" to the guest kernel command line options.<br />
<br />
If you're using Xen pygrub or pv-grub to load the kernel from guests filesystem, then you need to configure the guest kernel settings in the guest /boot/grub/grub.conf (or menu.lst), not in dom0! So edit the guest /boot/grub/grub.conf (or menu.lst) and add the "console=hvc0" option there for the default kernel.<br />
<br />
If you're not using pygrub or pv-grub, aka you're configuring everything in /etc/xen/<guest> configuration file in dom0, and you have the kernel/initrd in dom0 filesystem, then you can specify the additional "console=hvc0" parameter in the /etc/xen/<guest> configuration file in dom0, on the extra="" line.<br />
<br />
== What's the correct console device name for my Xen PV guest ==<br />
* Xenlinux ("xenified") kernels use "xvc0" as the console device.<br />
* Upstream kernel.org pv_ops kernels use "hvc0" as the console device<br />
Examples of Xenlinux kernels using "xvc0" console:<br />
<br />
* xen.org linux-2.6.18-xen<br />
* RHEL5 / CentOS5 kernel-xen 2.6.18<br />
* Debian Etch 2.6.18-6-xen<br />
* Debian Lenny 2.6.26-2-xen<br />
* Ubuntu 8.04 LTS "hardy heron" 2.6.24 xen kernel<br />
* Gentoo Xenlinux kernels<br />
* Novell SLES 10 and SLES 11 xen kernels<br />
* OpenSUSE xen kernels<br />
* Various "xenified" forward-ports of the Novell SLES/OpenSUSE Xenlinux patches (2.6.27, 2.6.29, 2.6.30, 2.6.31, 2.6.32, 2.6.33, 2.6.34)<br />
Examples of pv_ops domU kernels using "hvc0" console:<br />
<br />
* All upstream/mainline kernel.org Linux kernels since 2.6.26.<br />
* Fedora 10, Fedora 11, Fedora 12, Fedora 13 kernels<br />
* Ubuntu 8.10 2.6.27 server-kernel<br />
* Ubuntu 9.04 2.6.28 linux-image-server<br />
* Ubuntu 9.10 2.6.31 ec2-kernel<br />
* Ubuntu 10.04 ("Lucid Lynx") 2.6.32 kernel<br />
* Debian 6.0 ("Squeeze") 2.6.32 kernels<br />
== How do I exit domU "xm console" session ==<br />
Press ctrl+] or if you're using Putty press ctrl+5.<br />
<br />
== Everything seems OK but I still can't access the domU "xm console"! ==<br />
A couple of things to check:<br />
<br />
* Do you have some old already running "xm console" session running on the host? possibly stuck in some dead ssh connection?<br />
* Do you have virt-manager running on the host 'reserving' the guest console?<br />
* Did it work earlier?<br />
* Do you have problems with only one guest, or with all guests?<br />
* Does shutting down and then re-starting the guest help?<br />
* Are you really sure you are running a getty in the guest for the correct console device? :)<br />
* Is the guest really up and running? Can you access it over the network with ssh? Can you ping it?<br />
== Xen network-bridge script not working in Debian Lenny, errors about eth0 ==<br />
You edited "/etc/xen/xend-config.sxp" in your Debian Lenny dom0/host, and changed the default "network-dummy" to "network-bridge". When you reboot dom0, and xend is started, it gives error like this:<br />
<br />
ifdown: interface eth0 not configured<br />
<br />
RTNETLINK answers: Device or resource busy<br />
<br />
This error can be caused by non-common settings for eth0 in "/etc/network/interfaces" configuration file. Try cleaning up the configuration, and having only a very basic ipv4-only configuration with a static IP, to begin with. Remove IPV6 configuration. Remove all the IP aliases. Reboot and try again. First get it working, then possibly later modify the configuration to be more advanced.<br />
<br />
== Xend does not start when using pv_ops dom0 kernel? ==<br />
<br />
You need to have Xen event channel (evtchn) driver included in your dom0 kernel for xend to be able to start. If Xen event channel support is compiled as a module, use "lsmod" to check that you have xen-evtchn (or xen_evtchn) driver module loaded. It not, use "modprobe" to load it. If Xen event channel support is statically built-in to the dom0 kernel then you don't need to load any modules.<br />
<br />
You also need xen-gntdev driver loaded.<br />
<br />
In December 2009 pv_ops dom0 kernel modules were renamed to have a "xen-" prefix in them, ie. "evtchn.ko" became "xen-evtchn.ko", and "gntdev.ko" became "xen-gntdev.ko".<br />
<br />
This makes Xen 3.4.x xend fail to start, because it tried to load "evtchn.ko", but that doesn't exist. You need to load "xen-evtchn.ko" and then start xend. Fedora 12 xen-3.4.2-2 rpms have this problem fixed. If your xend does not automatically load evtchn or xen-evtchn driver module, please load it manually with modprobe.<br />
<br />
Also make sure you have xenfs mounted to "/proc/xen", that's needed aswell. Do you have files under "/proc/xen/" directory? You should have for example:<br />
<br />
<br />
<pre><br />
# ls /proc/xen/<br />
capabilities privcmd xenbus xsd_kva xsd_port<br />
# cat /proc/xen/capabilities<br />
control_d<br />
</pre><br />
<br />
"control_d" value in "/proc/xen/capabilities" means you're in Xen dom0 ("control domain").<br />
<br />
Do you have files under "/dev/xen/" ? You should have there at least the following device nodes:<br />
<br />
<br />
<pre><br />
# ls -la /dev/xen<br />
total 0<br />
drwxr-xr-x 2 root root 80 Jun 19 19:17 .<br />
drwxr-xr-x 20 root root 4580 Jun 19 19:33 ..<br />
crw-rw---- 1 root root 10, 58 Jun 19 19:17 evtchn<br />
crw-rw---- 1 root root 10, 57 Jun 19 19:17 gntdev<br />
</pre><br />
<br />
If you're missing those device nodes you can use "mknod" to create them manually. Creating those device nodes should happen automatically by udev when you have xen-evtchn and xen-gntdev driver modules loaded.<br />
<br />
You can see the correct major/minor for the device nodes from "/proc/misc":<br />
<br />
<br />
<pre><br />
# cat /proc/misc<br />
57 xen/gntdev<br />
58 xen/evtchn<br />
</pre><br />
<br />
Note how they match the values from the previous "ls -la /dev/xen". If the major/minor numbers don't match then xenstored and xend won't be able to start/function. Note the major/minor numbers for device nodes are dynamic nowadays, so you need to verify they're properly set up for your system.<br />
<br />
== How can I limit the number of vcpus my dom0 has? ==<br />
The recommended way is to use "dom0_max_vcpus=X" boot time option for Xen hypervisor (xen.gz) in grub.conf. You need to reboot after modifying grub.conf. Using this method makes sure you allocate resources only for the actual number of vcpus you need in dom0.<br />
<br />
Another option is to configure "(dom0-cpus X)" option in /etc/xen/xend-config.sxp, but it works in a different way: dom0 boots up with all the cpus visible to it, and when xend starts, it'll hot-remove the extra vcpus from dom0, and only leaves the number of vcpus specified in (dom0-cpus) to dom0. This option has the benefit that vcpus can be later added to dom0, if needed.<br />
<br />
== Can I dedicate a cpu core (or cores) only for dom0? ==<br />
Yes, you can. It might a good idea especially for systems running IO intensive guests. Dedicating a CPU core only for dom0 makes sure dom0 always has free CPU time to process the IO requests for the domUs. Also when dom0 has a dedicated core there are less CPU context switches to do, giving better performance.<br />
<br />
Specify "dom0_max_vcpus=X dom0_vcpus_pin" options for Xen hypervisor (xen.gz) in grub.conf and reboot.<br />
<br />
After rebooting you can verify with "xm vcpu-list" that dom0 vcpus are pinned to only use the matching physical cpus.<br />
<br />
The next step is to configure all the guests (domUs) to NOT use those same physical cpus. This can be done by specifying for example cpus="2-7" to all /etc/xen/<guest> cfgfiles. This example would leave physical cpus/cores 0 and 1 only for dom0, and make the guests use cpus/cores 2 to 7.<br />
<br />
== Booting Xen with GRUB2 fails? ==<br />
It seems GRUB2 destroys the first parameter from Xen hypervisor "multiboot" and dom0 kernel "module" lines. For dom0 kernel this usually means root= parameter gets lost and thus dom0 kernel fails to set up the root filesystem and the boot fails. For xen.gz this usually means parameters like "dom0_mem=" or "dom0_vcpus" will get lost, whatever is the first parameter.<br />
<br />
You can work around this problem by specifying "dummy=dummy" as the first parameter in grub2 config file for "multiboot" and "module" lines. This will fix the problem with Xen 4.0.0 and older hypervisor versions.<br />
<br />
See this link for a working GRUB2 + Xen example:http://old.nabble.com/Strange-interaction-from-grub2-and-XEN-td26464067.html<br />
<br />
The dummy workaround is not required anymore with Xen 4.0.1 and newer versions. See this patch for the Xen GRUB2 fix: http://xenbits.xen.org/xen-unstable.hg?rev/4207549948a4 and http://xenbits.xen.org/xen-4.0-testing.hg?rev/1da5224a2875 .<br />
<br />
Other things that could go wrong.<br />
Did you modify the config file manually? If yes, you might need to add<br />
"insmod multiboot" (or "insmod multiboot2")<br />
<br />
== 32bit Xen hypervisor crashes when using GRUB2 ==<br />
You get the following messages on the (serial) console when GRUB2 boots 32bit PAE Xen hypervisor:<br />
<br />
<br />
<pre><br />
(XEN) ****************************************<br />
(XEN) Panic on CPU 0:<br />
(XEN) Cannot access memory beyond end of bootstrap direct-map area<br />
(XEN) ****************************************<br />
(XEN)<br />
(XEN) Reboot in five seconds...<br />
(XEN) Unknown interrupt (cr2=00000000)<br />
</pre><br />
<br />
This is because your version of GRUB2 dumps the dom0 kernel and initrd image to a memory region that Xen cannot access. Changing to different GRUB2 version fixes the problem. Another option is to switch to 64 bit Xen hypervisor. Note that you can still run 32bit dom0 on 64bit Xen hypervisor.<br />
<br />
This problem has been fixed in Xen 4.0.0-rc8 and newer versions. You can use new enough 32bit PAE Xen hypervisor with GRUB2. See these changesets for patches: http://xenbits.xen.org/xen-unstable.hg?rev/bcc09eb7379f and http://xenbits.xen.org/xen-unstable.hg?rev/377433a77d70<br />
<br />
== In dom0 how can I access and mount partitions inside a Xen disk image? ==<br />
The easiest way is to use "kpartx" in dom0. It allows you to easily access all the partitions inside an image file or inside LVM volume.<br />
<br />
You can use "kpartx -l /path/guestdisk" to list the partitions the image has, and "kpartx -a /path/guestdisk" to add the partition mappings. After the device mapper (dm) mappings have been added, you can access the partitions using "/dev/mapper/guestdiskpX" block devices. There's a separate block device for each partition. You can mount, copy, format, or whatever you need to do and it works just like for "real" partitions.<br />
<br />
When you're done using the partitions in dom0, and you have unmounted them, you have to remove the kpartx mappings by running "kpartx -d /path/guestdisk". It's important to do this before using the image again for other purposes or starting the guest again! If you forget to remove the mappings the image might get corrupted when you access the image with other tools or start the guest.<br />
<br />
Another neat way which works for me, is to simply attach the block device to dom0 as you would to a domU. e.g.:<br />
<br />
<br />
<pre><br />
xm block-attach Domain-0 file:/disk/image/for/domU xvda w<br />
</pre><br />
<br />
I have found this to work for OSs which use slices (such as Solaris and *BSD), and are not picked up using kpartx. You should check dmesg and see which device nodes were created for you. Once you are done working with the disk image you can:<br />
<br />
<br />
<pre><br />
xm block-detach Domain-0 xvda<br />
</pre><br />
<br />
If your domU is LVM-based, see [[Access_Disk_from_DomUs_when_Xen_was_installed_with_LVM]]<br />
<br />
== Xen dom0 complains about not enough free loop devices when trying to start a new domU or when trying to "mount -o loop" from the cmdline ==<br />
Linux "loop" module has max 8 loop devices (/dev/loop*) as a default. Every Xen "file:" backed domU disk uses one loop device in dom0, and if you do "mount -o loop disk.img /mnt" in dom0 that uses a loop device aswell.<br />
<br />
You can check all the loop devices in use by running "losetup -a". You can detach a loop device (free it) by running "losetup -d /dev/loopX" when it's not mounted or otherwise in use.<br />
<br />
You can increase the amount of available loop devices by loading the linux "loop" module with an option "max_loop=X", for example "modprobe loop max_loop=128". You can add "max_loop=X" option to /etc/modprobe.conf, /etc/modules (or whatever cfgfile your dom0 distribution uses for module options) to make it boot time default.<br />
<br />
You can also use Xen "phy:" backed LVM volumes instead of disk images. "phy:" doesn't require loop devices.<br />
<br />
As an example for Debian Lenny check this: http://www.howtoforge.com/virtualization-with-xen-on-debian-lenny-amd64<br />
<br />
Such an error message may also be indicative of other issues (such as the guest crashing and restarting so quickly that xend does not have time to free the older loopback device).<br />
<br />
== Debian Lenny Xen PV domU doesn't start, in the console it says "Waiting for root file system" and then drops to a busybox shell ==<br />
Is your root device set correctly for the guest (domU) kernel? Most probably you're using a wrong root= parameter, and thus the system cannot mount the root device and start. Check the early boot messages from the kernel, there should be a line starting with "Command line:". There you can see the parameters passed to the domU kernel. Do you see the correct root device there?<br />
<br />
Remember the root= passed to a PV domU must be a path ''accessible from within the guest''<br />
<br />
You can set and edit the root device in dom0 from /etc/xen/<guest> configuration file. root device is specified either in "root=" line, or on "extra=" line. The configured root device should match the disk configuration for the guest.<br />
<br />
Another problem can be that you're using wrong initrd image for the domU kernel. You should use an initrd generated for the guest, not the same initrd as you use to boot the dom0.<br />
<br />
== My Xen PV guest kernel crashes, how can I debug it and get a stack/call trace? ==<br />
Edit "/etc/xen/<guest>" cfgfile, and set:<br />
<br />
<br />
<pre><br />
on_crash="preserve"<br />
</pre><br />
<br />
Then when your domU guest crashes, run this in dom0:<br />
<br />
<br />
<pre><br />
/usr/lib/xen/bin/xenctx -s System.map-domUkernelversion <domUid> <vcpu-number><br />
</pre><br />
<br />
If you're running 64bit dom0, then xenctx might be under "/usr/lib64/". This command will give you a stack trace of the crashed domU kernel on the specified vcpu, allowing you to see where it crashes. You should get the stack trace for every vcpu your guest has! Vcpu numbers start from 0.<br />
<br />
Note that you need to use the "System.map" file from the exact kernel version the domU is running, otherwise the stack trace results are not correct!<br />
<br />
== Can I run graphical X applications in Xen dom0 without installing X server and display drivers? ==<br />
Yes, you can. Many people prefer to not install any graphical drivers or X on dom0 for maximum stability. You can still run graphical applications using ssh X11 forwarding. You can run for example "virt-manager" in dom0 and display the GUI on your desktop/laptop over ssh.<br />
<br />
1) Install "xorg-x11-xauth" package in dom0 (centos/rhel/fedora, "xauth" in debian/ubuntu, other distros might have different name for it).<br />
<br />
2) Log in to dom0 from your Linux workstation like this: ssh -X root@dom0.<br />
<br />
3) After the password is accepted you should notice ssh setting up the ssh X11 forwarding like this:<br />
<br />
<br />
<pre><br />
/usr/bin/xauth: creating new authority file /root/.Xauthority<br />
</pre><br />
<br />
4) You can now run graphical X applications, for example vnc viewer, virt-viewer etc, and the GUI will be tunneled securely over ssh to your local X desktop.<br />
<br />
If you're using Windows you can install "xming" and "putty". Start Xming, and after that enable X11 forwarding in putty settings (Connection -> ssh -> X11 -> Enable X11 forwarding) and then connect to your dom0.<br />
<br />
== What emulated NIC types/models are available in Xen HVM fully virtualized guests? ==<br />
The following emulated network interface cards are available for Xen HVM guests in Xen 3.4:<br />
<br />
* e100<br />
* e1000<br />
* rtl8139<br />
* ne2k_pci<br />
* pcnet<br />
Emulation is done by Qemu-dm running for each Xen HVM guest. Intel e1000 is known to be the best performing emulated NIC. Even faster is to use PV-on-HVM drivers, which totally bypasses emulation.<br />
<br />
Older Xen versions might not have all the above NIC options available.<br />
<br />
== Can I set up Xen HVM Linux guest to display the kernel boot messages on "xm console" ? ==<br />
Yes, you can. You need to add this line to the "/etc/xen/<hvmguest>" configuration file in dom0:<br />
<br />
<br />
<pre><br />
serial='pty'<br />
</pre><br />
<br />
<br />
And then in the HVM guest grub.conf (inside the HVM VM) configure kernel logging to the (virtual) serial port like this:<br />
<br />
<br />
<pre><br />
#============================================================<br />
# display the grub kernel selector menu on the serial console<br />
serial --unit=0 --speed=9600<br />
terminal --timeout=5 serial console<br />
# kernel entries title openSUSE 11.1 - 2.6.27.29-0.1<br />
root (hd0,1)<br />
kernel /boot/vmlinuz-2.6.27.29-0.1-default root=LABEL=ROOT resume=LABEL=SWAP splash=silent showopts console=tty1 console=ttyS0<br />
initrd /boot/initrd-2.6.27.29-0.1-default<br />
#================================================<br />
</pre><br />
<br />
<br />
So basicly you need to add "console=ttyS0" to the kernel line, and also configure grub to display the kernel selector on the (virtual) serial console using "serial" and "terminal" settings.<br />
<br />
After these settings "xm console <hvmguest>" works just like it does for PV (paravirtual) guests and allows you to see grub and the Linux kernel boot messages of the HVM guest. You can also use other tools (minicom, screen, etc) in dom0 to access the VM console pty device directly.<br />
<br />
Also remember to set up a getty in the guest for the serial console device, ttyS0, so that you can also login from the serial console! See above for tips about that.<br />
<br />
== How can I boot Xen HVM guest from a virtual emulated floppy, using an image file as the floppy? ==<br />
This is the required configuration in "/etc/xen/<hvmguest>" cfgfile:<br />
<br />
<br />
<pre><br />
fda = '/path/to/floppy.img' boot=a<br />
</pre><br />
<br />
You can also use this cmdline method while creating the guest:<br />
<br />
<br />
<pre><br />
xm create /etc/xen/hvmguest.cfg fda=/path/to/floppy.img boot=a<br />
</pre><br />
<br />
Important note: Make sure SElinux access restrictions are not blocking access to /path/to/floppy.img!<br />
<br />
== How do I change virtual/emulated CD .iso image for a Xen HVM guest? ==<br />
First check "/etc/xen/<guest>" cfgfile and check what is your cdrom device in the guest. It's usually "/dev/hdc".<br />
<br />
An example to swap the emulated CD using an iso image:<br />
<br />
<br />
<pre><br />
xm block-configure <guest> file:/path/to/new/cd.iso hdc:cdrom r<br />
</pre><br />
<br />
== Are there FreeBSD Xen PV kernels/images available? ==<br />
Please check the following links: http://wiki.freebsd.org/AdrianChadd/XenImages and http://wiki.freebsd.org/AdrianChadd/XenHackery .<br />
<br />
FreeBSD Xen wiki: http://wiki.freebsd.org/FreeBSD/Xen .<br />
<br />
Tutorial how to install 32bit Xen PV FreeBSD domU on a Debian Lenny Xen dom0, using LVM volumes: http://silverwraith.com/blog/?p=83 .<br />
Another Freebsd Xen PV domU tutorial: http://forums.freebsd.org/showthread.php?t=10268 .<br />
<br />
== Where can I find information about NetBSD Xen support? ==<br />
NetBSD supports both Xen dom0 and PV domUs. For more information see: http://www.netbsd.org/ports/xen/<br />
<br />
== What's Xen pygrub? ==<br />
Pygrub allows you to simply specify in Xen PV guest "/etc/xen/<guest>" cfgfile:<br />
<br />
<br />
<pre><br />
bootloader = "/usr/bin/pygrub"<br />
</pre><br />
<br />
Which replaces all these options:<br />
<br />
<br />
<pre><br />
kernel = "vmlinuz-2.6.32.12"<br />
ramdisk = "initrd-2.6.32.12.img"<br />
root = "/dev/xvda1"<br />
extra = "earlyprintk=xen console=hvc0"<br />
</pre><br />
<br />
When you start a Xen PV guest pygrub will be executed in dom0 and it'll access the guest disk configured in the "/etc/xen/<guest>" cfgfile, find "/boot/grub/grub.conf" (or menu.lst) from the guest filesystem, parse it, fetch the kernel, initrd image and kernel parameters configured in the guest to dom0, and then boot up the guest using those kernel + initrd + parameters. All the domU specific settings are configured inside the domU, in grub.conf.<br />
<br />
Requirements for using pygrub for Xen PV domUs:<br />
<br />
* Pygrub binary available in dom0, installed together with Xen.<br />
* Pygrub configured for the guest in "/etc/xen/<guest>" cfgfile<br />
* Guest has /boot/grub/grub.conf (or menu.lst) with proper entries in it. There's actually no need to install the real grub to the MBR of the guest disk, it's enough to just have the grub.conf/menu.lst in the guest.<br />
* If the guest has GRUB2 configuration file (for example Ubuntu 10.04 or Debian Squeeze 6.0) then you need to have new enough Xen pygrub in dom0. Pygrub versions included in Xen 4.0.2 and 4.1.1 and newer properly support parsing GRUB2 guest config files.<br />
So pygrub makes it much easier to:<br />
<br />
* Manage the guest kernels inside every guest, keeping the guest distribution package managers (dpkg,rpm) and package dependencies happy.<br />
* Upgrade guest kernels without touching dom0 or guest configuration files in "/etc/xen/" in dom0.<br />
* Each guest distribution can easily use the default kernel provided by the distribution.<br />
* Pygrub allows you to select which kernel to boot, in the "xm console <guest>" session. It's easiest to start the guest with "xm create -f /etc/xen/guest -c" to attach to the console immediate for selecting the kernel from pygrub menu. If nothing is chosen then the default entry will be booted automatically.<br />
Management tools like "virt-install" and "virt-manager" will use Xen pygrub as a default when you install new guests using them.<br />
<br />
== What's Xen pvgrub? ==<br />
Xen pvgrub is like pygrub but more secure.<br />
<br />
Pygrub is executed in dom0, so it could have security concerns/issues, if bugs were found from it. Pvgrub is executed in the Xen PV guest, so there are no such security issues with it.<br />
<br />
Pvgrub is included in Xen 3.3 and newer versions. Pvgrub is a separate build and separate tool, so usually it's easier to begin with pygrub, and then later switch to pvgrub.<br />
<br />
See [[PvGrub]] wiki page for more information and usage of pvgrub.<br />
<br />
== Does Xen pygrub support booting PV guests using GRUB2 config files? ==<br />
Yes, pygrub in Xen 4.0.1 supports guests using GRUB2 config files (Ubuntu 10.04 LTS "Lucid Lynx"). Later the format of GRUB2 config files was changed, and Xen 4.0.2 and 4.1.1 (or newer versions) properly support this newest version of GRUB2 config files (Debian 6.0 "Squeeze"). GRUB2 syntax used by Fedora 16 is supported in pygrub in Xen 4.1.3 and Xen 4.2.0 (and later Xen versions). <br />
<br />
Also there's a patch for RHEL/CentOS 5.5 version of pygrub to support GRUB2 (Ubuntu 10.04) guests: https://bugzilla.redhat.com/show_bug.cgi?id=577511 and latest version of GRUB2 config files (Debian 6.0 "Squeeze"): https://bugzilla.redhat.com/show_bug.cgi?id=675733 . These RHEL5 Xen pygrub patches are included in RHEL5.6 (first patch, Ubuntu 10.04) and RHEL5.7 (second patch, Debian 6.0). RHEL5 Xen pygrub support for F16 GRUB2 syntax is added with these patches in RHEL 5.8: https://bugzilla.redhat.com/show_bug.cgi?id=746602 .<br />
<br />
== Can I browse the Xen source trees online? ==<br />
Yes, you can browse the source tree and see the changelogs/summaries and track changes online from the [[XenRepositories]] wiki page.<br />
<br />
== Can I browse the Xen Qemu-dm (HVM guest ioemu) source repositories online? ==<br />
Yes, you can see the changelogs/summaries and track changes online from the [[XenRepositories]] wiki page.<br />
<br />
== I'm using Xen 4.0.0 with the latest pvops 2.6.32.x dom0 kernel (2.6.32.15+) and xend/xenstored doesn't start anymore? ==<br />
Yes, this is a known issue. pvops dom0 kernel in xen/stable-2.6.32.x branch changed to using proper evtchn and gntdev device node names ("/proc/xen/*") in June 2010, which triggers a bug in libxc in Xen 4.0.0. This bug has been fixed in Xen 4.0.1-rc2 and newer versions. So please upgrade your Xen to 4.0.1-rc2 or newer version.<br />
<br />
Alternatively you can apply this patch if you want to keep using Xen 4.0.0: http://xenbits.xen.org/xen-4.0-testing.hg?rev/0e1521f654f2 .<br />
<br />
Another option is to manually fix the device node major/minor numbers by re-creating the device nodes manually and then re-starting xenstored and xend. You can see the proper major/minor for "/dev/xen/evtchn" and "/dev/xen/gntdev" from "/proc/misc":<br />
<br />
<br />
<pre><br />
# cat /proc/misc | grep xen<br />
57 xen/gntdev<br />
58 xen/evtchn<br />
<br />
# ls -la /dev/xen<br />
total 0<br />
drwxr-xr-x 2 root root 80 Jun 19 19:17 .<br />
drwxr-xr-x 20 root root 4580 Jun 19 19:33 ..<br />
crw-rw---- 1 root root 10, 58 Jun 19 19:17 evtchn<br />
crw-rw---- 1 root root 10, 57 Jun 19 19:17 gntdev<br />
</pre><br />
<br />
Check the proper major/minor values from "/proc/misc" and then use mknod to create the device nodes manually using the proper values. After that xenstored and xend should start normally. For more information see this email: http://lists.xensource.com/archives/html/xen-devel/2010-06/msg01129.html and [[XenParavirtOps]] wiki page.<br />
<br />
== Arp change notification problems after live migration when using pvops 2.6.32.x dom0 kernel ==<br />
You need to have new enough version of pvops dom0 kernel (xen/stable-2.6.32.x branch, Aug 2010 or newer) and then you can enable "net.ipv4.conf.<dev>.arp_notify" sysctl setting for the devices where you want to send the arp notifications (gratuitous ARP). See this email for more information: http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01595.html .<br />
<br />
== Starting xend fails? ==<br />
"ERROR Internal error: Could not obtain handle on privileged command interface (2 = No such file or directory)".<br />
<br />
or "xm" commands give the following error message:<br />
"Error: Unable to connect to xend: No such file or directory. Is xend running?".<br />
<br />
Please check these things:<br />
<br />
* First of all - are you actually running Xen? Did you modify grub.conf to boot Xen hypervisor (xen.gz)? You can verify with "dmesg | grep -i xen" or "grep -i xen /var/log/dmesg" - you should see at least a line like "Booting paravirtualized kernel on Xen" when you've actually booted into Xen dom0.<br />
* Do you have xenfs mounted? Check "/proc/xen" directory, you absolutely NEED to have files there. <br />
Value of "control_d" in file "/proc/xen/capabilities" means you're in Xen dom0:<br />
<br />
<pre><br />
# ls /proc/xen/<br />
capabilities privcmd xenbus xsd_kva xsd_port<br />
<br />
# cat /proc/xen/capabilities<br />
control_d<br />
</pre><br />
<br />
Maybe you need a line like this in "/etc/fstab":<br />
<br />
<pre><br />
none /proc/xen xenfs defaults 0 0<br />
</pre><br />
<br />
After adding that line to "/etc/fstab" reboot or run "mount /proc/xen".<br />
* Do you have "xen-evtchn" driver loaded? Check with "lsmod | grep -i xen" and load with "modprobe xen-evtchn".<br />
* Do you have "xen-gntdev" driver loaded? Check with "lsmod | grep -i xen" and load with "modprobe xen-gntdev"<br />
* Do you have the required device nodes under "/dev/xen/" directory? An example:<br />
<br />
<pre><br />
# ls -la /dev/xen<br />
total 0<br />
drwxr-xr-x 2 root root 80 Jun 19 19:17 .<br />
drwxr-xr-x 20 root root 4580 Jun 19 19:33 ..<br />
crw-rw---- 1 root root 10, 58 Jun 19 19:17 evtchn<br />
crw-rw---- 1 root root 10, 57 Jun 19 19:17 gntdev<br />
</pre><br />
<br />
* Correct major/minor numbers for those device nodes can be checked from file "/proc/misc", the values are dynamic and might change from system to system:<br />
<br />
<pre><br />
# cat /proc/misc | grep xen<br />
57 xen/gntdev<br />
58 xen/evtchn<br />
</pre><br />
<br />
* Do you have SElinux running? Did you try turning it off? Run "setenforce 0" or disable it in "/etc/selinux/config" and reboot dom0.<br />
* Do you have xenstored or oxenstored running? xend required xen store daemon to be running before starting xend.<br />
* If you're using certain Debian or Ubuntu (10.04+) versions, and you're compiling Xen from source (.tar.gz), you might need to run "make install-tools PYTHON_PREFIX_ARG=" to install Xen.. notice the empty argument to PYTHON_PREFIX_ARG to get the Xen python modules installed to correct directory location.<br />
* If you upgraded from older Xen version, did you first make sure all the files from earlier Xen versions were completely removed before installing the new version? Xend might fail to start when there's a bad installation mixing files from multiple Xen versions.<br />
<br />
For other troubleshooting tips related to pvops dom0 kernels try reading [[XenParavirtOps]] wiki page.<br />
<br />
== How to specify custom (non-default) vif-script for some domU network interface? ==<br />
Here's an example how to have 2 nics (vifs) for the domU, each using different vif-script:<br />
<br />
<br />
<pre><br />
vif = [ 'mac=00:16:5e:72:04:01,bridge=xenbr0,script=your_custom_script1', 'mac=00:16:5e:72:04:02,bridge=xenbr1,script=your_custom_script2' ]<br />
</pre><br />
<br />
<br />
== Problems with Xen on Redhat Enterprise Linux 5 (RHEL5) or CentOS5 ==<br />
<br />
Try these links:<br />
* http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/Virtualization/index.html<br />
* http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/Virtualization/index.html#part-Virtualization-Troubleshooting<br />
<br />
== I'd like to run Xen hypervisor/dom0 on Redhat Enterprise Linux 6 (RHEL6) ==<br />
<br />
See this wiki page for a Xen 4.0 with RHEL6 tutorial and more info: [[RHEL6Xen4Tutorial]] .<br />
<br />
== Starting Xen HVM guests fails when using Xen 4.x and gcc 4.6 ==<br />
<br />
When Xen 4.x is compiled with gcc 4.6 compiler it seems Xen hvmloader binary gets miscompiled and makes it impossible to run HVM VMs. This issue does not happen when using gcc 4.5 or older gcc versions. The error message might be something like this:<br />
<br />
<br />
<pre><br />
(XEN) io.c:194:d18358 MMIO emulation failed @ 0018:9ffff: 00 e0 de be 00 83<br />
(XEN) hvm.c:1099:d18358 Triple fault on VCPU0 - invoking HVM system reset.<br />
</pre><br />
<br />
<br />
or then just a line with words "HVM Loader" and nothing more, followed by a VM crash a couple of seconds after it started.<br />
This bug is fixed in xen.org repositories, but the fix is not yet in Xen 4.0.2 or 4.1.1, because the bug was found and fixed after the release of Xen 4.0.2 and Xen 4.1.1. See this email for info about the bugfix changesets: http://lists.xensource.com/archives/html/xen-devel/2011-07/msg00922.html . Especially users of Debian Wheezy, Ubuntu 11.10+ and Fedora 15/16 have seen this issue.<br />
<br />
== xm: [[ImportError]]: No module named xen.xm ==<br />
<br />
After installing Xen from source (either mercurial/hg repository or from .tar.gz) you get an error when trying to start xend or run "xm" commands.<br />
The error looks like:<br />
<br />
<pre><br />
ImportError: No module named xen.xm<br />
</pre><br />
<br />
<br />
This means Xen python modules are not installed to correct directory. Debian/Ubuntu changed the location of python modules include directory, so you need to use the following when installing Xen:<br />
<br />
<br />
<pre><br />
make install-tools PYTHON_PREFIX_ARG=<br />
</pre><br />
<br />
<br />
Notice the empty parameter to PYTHON_PREFIX_ARG. Re-install the modules/tools and the problem should get fixed.<br />
<br />
== With Linux 3.0 as a dom0 kernel using dom0_mem=<xyz> option for Xen in grub.conf doesn't work ==<br />
<br />
This is a known bug in Linux 3.0 kernel. It is fixed in Linux 3.1 and Linux 3.0.5 stable update. If using 3.0 older than 3.0.5 the workaround is to use, in addition to "dom0_mem=2048M" for Xen hypervisor (xen.gz), also "mem=2048M" option for dom0 Linux kernel (vmlinuz) in grub.conf.<br />
<br />
Also see [[Linux_30_bugs:]] wiki page for other known issues in upstream Linux 3.0 kernel.<br />
<br />
== How do I change the resolution of Xen PV domU vfb graphical VNC console? ==<br />
<br />
You can specify the pvfb (paravirtual framebuffer) resolution and bpp (amount of colors) for the VM while loading the xen-fbfront driver in the domU kernel.<br />
<br />
If xen-fbfront is built as a module, use the following options:<br />
<br />
<pre><br />
modprobe xen-fbfront video="32,1024,768"<br />
</pre><br />
<br />
Or add the options to "/etc/modprobe.conf", or whatever file your domU distro uses for driver module options. Note that you might need to regenerate the initrd/initramfs image for the domU kernel if the xen-fbfront driver is auto-loaded at boot time.<br />
<br />
Or if xen-fbfront driver is built-in to the domU kernel, use the following cmdline options for the domU kernel:<br />
<br />
<pre><br />
xen-fbfront.video=32,1024,768<br />
</pre><br />
<br />
If you're using Xen pygrub you can place that option to grub configfile inside the domU "/boot/grub/" directory, or if you're using kernel/ramdisk from dom0, then add those options to "extra" line on /etc/xen/<domU> on dom0.<br />
<br />
== How can I get resolutions larger than 800x600 for Xen HVM guest graphical VNC console? ==<br />
<br />
Edit "/etc/xen/<hvmvm>" cfgfile and add the following options:<br />
<br />
<pre><br />
stdvga=1<br />
videoram=16<br />
</pre><br />
<br />
This will increase the amount of virtual video memory in the HVM VM, allowing it to use bigger resolutions, up to 2048x1536 @ 32bpp. If you don't specify "stdvga=1", ie. you keep using the Cirrus emulated graphics adapter, resolutions up to 1280x1024 are possible with "videoram=16".<br />
<br />
After increasing the size of vram configure the resolution from inside the HVM guest in the usual way, just like you'd do on baremetal/native, using the resolution selector or configfile provided by the operating system in the VM.<br />
<br />
== I'm trying to create a new Xen VM but I get error there's not enough free memory ==<br />
<br />
Tools like "free" or "top" in Xen dom0 show that you have a lot of free memory, but Xen still complains that there's not enough free memory to create/start a new VM, giving errors such as "Out of memory". This usually happens because dom0 is using all the memory, so there's no free memory in the Xen hypervisor (xen.gz) for other VMs. Note that dom0 is actually a Xen virtual machine! <br />
<br />
Xen hypervisor dedicates physical memory for each VM, so you need to have actual free unallocated memory in the hypervisor to start a VM. You can check the Xen hypervisor memory usage with the following commands:<br />
<br />
Check the amount of total, used and free memory in Xen hypervisor:<br />
<br />
<pre><br />
xm info<br />
</pre><br />
<br />
<br />
and check how much memory each VM is using:<br />
<br />
<br />
<pre><br />
xm list<br />
</pre><br />
<br />
<br />
It's possible that dom0 is using most of your memory and Xen hypervisor doesn't have any free memory left. You should use "dom0_mem=" setting for Xen in grub to configure dom0 a fixed/dedicated amount of memory, so the rest of the memory is free for other VMs to use. See [[XenBestPractices:]] wiki page for more info about configuring "dom0_mem=" option for Xen.<br />
<br />
== Error: (4, 'Out of memory', 'panic: xc_dom_core.c:442: xc_dom_alloc_segment: segment ramdisk too large (0xee93 > 0x8000 - 0x1755 pages)') ==<br />
<br />
Getting this error when trying to start a new VM (running "xm create") means you're trying to use too big ramdisk image (initrd/initramfs file) for the domU. The ramdisk image configured is bigger than the amount of available memory for the VM. Remember the ramdisk images are compressed, and they need to fit as uncompressed to the domU memory. The solution is to edit "/etc/xen/<domU>" configuration file and increase the amount of memory for the VM, or switch to using a smaller ramdisk image for the domU kernel.<br />
<br />
== What's the difference between vifX.Y and tapX.Y network interfaces in dom0? ==<br />
<br />
vifX.Y network interfaces are used with domUs (VMs) using paravirtualized network drivers, which means for pure PV domUs or for Xen HVM guests with paravirtualized PVHVM drivers in use. tapX.Y interfaces are used for HVM guests which are using emulated virtual NICs (Intel E1000, Realtek RTL8139, NE2k).<br />
<br />
vifX.Y interfaces are created by the xen-netback backend driver in dom0 kernel. The frontend driver xen-netfront runs in the kernel of each VM.<br />
<br />
There's exactly one vif/tap interface per virtual NIC in the VM. "X" means the domain ID, and "Y" is the number of the virtual NIC. So if you have a domU with ID 5 with 3 virtual NICs (eth0, eth1, eth2), the corresponding VIF interfaces in dom0 would be vif5.0, vif5.1, vif5.2. <br />
<br />
== How can I use Xen PVHVM optimized paravirtualized drivers with Ubuntu 11.10 or Fedora 16 HVM guests? ==<br />
<br />
Please see the [[Xen_Linux_PV_on_HVM_drivers]] wiki page for more information about Xen PVHVM drivers.<br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Submitting_Xen_Project_Patches&diff=5068Submitting Xen Project Patches2012-09-24T10:50:27Z<p>OliverChick: Added a small amount of info on submitting Xen Linux patches</p>
<hr />
<div>== How To Generate and Submit a Patch to Xen ==<br />
<br />
Xen uses [http://www.selenic.com/mercurial/wiki/index.cgi Mercurial] for its source code management. The current Xen development tree is at http://xenbits.xensource.com/xen-unstable.hg. An excellent [http://www.selenic.com/mercurial/wiki/index.cgi/Tutorial tutorial] is here. Download and install mercurial to your system.<br />
<br />
=== Generating a patch ===<br />
----<br />
Here's a recommendation on how to send patches, as suggested by the Xen maintainers.<br />
<br />
To begin, configure Mercurial by making the following additions to your <code>~/.hgrc</code>:<br />
<br />
* Enable the [http://mercurial.selenic.com/wiki/MqExtension Patchqueue extension]<br />
<br />
<pre><br />
[extensions]<br />
mq=<br />
</pre><br />
<br />
<br />
* Show function names in patch hunk headers (which makes patches easier to review).<br />
<br />
<pre><br />
[diff]<br />
showfunc=True<br />
</pre><br />
<br />
<br />
When you want to make a patch, create a patch on the patch queue:<br />
<br />
<pre><br />
hg qnew patch01.diff<br />
</pre><br />
<br />
<br />
Then edit the source files you want to change. You can see which files have changed by using <code>hg status</code>.<br />
<br />
When you're done editing, save your changes into the patch, and add a description. The easiest way to add a description is to use the <code>-e</code> option to <code>hg qrefresh</code>:<br />
<br />
<pre><br />
hg qrefresh -e<br />
</pre><br />
<br />
<br />
<pre><br />
foobar: Add a new trondle calls<br />
<br />
Add a some new trondle calls to the foobar interface to support<br />
the new zot feature.<br />
<br />
Signed-off-by: Joe Smith <joe.smith@citrix.com><br />
</pre><br />
<br />
Alternately, after refreshing the patch with <code>hg qrefresh</code>, you can edit the files directly in <code>.hg/patches/</code>. Everything above the line starting with <code>diff</code> will be ignored:<br />
<br />
<pre><br />
foobar: Add a new trondle calls<br />
<br />
Add a some new trondle calls to the foobar interface to support<br />
the new zot feature.<br />
<br />
Signed-off-by: Joe Smith <joe.smith@citrix.com><br />
<br />
diff -r 63531e640828 tools/libxc/Makefile<br />
--- a/tools/libxc/Makefile Mon Dec 07 17:01:11 2009 +0000<br />
+++ b/tools/libxc/Makefile Mon Dec 21 11:45:00 2009 +0000<br />
...<br />
</pre><br />
<br />
Repeat as necessary for all of your changes<br />
<br />
<pre><br />
hg qnew patch02.diff<br />
</pre><br />
<br />
...<br />
=== Signing off a patch ===<br />
----<br />
All patches to the Xen code base must include the the line "Signed-off-by: your_name <your_email>" at the end of the change description. This is required and indicates that you certify the patch under the "Developer's Certificate of Origin" which states:<br />
<br />
<br />
<pre><br />
Developer's Certificate of Origin 1.1<br />
<br />
By making a contribution to this project, I certify that:<br />
<br />
(a) The contribution was created in whole or in part by me and I<br />
have the right to submit it under the open source license<br />
indicated in the file; or<br />
<br />
(b) The contribution is based upon previous work that, to the best<br />
of my knowledge, is covered under an appropriate open source<br />
license and I have the right under that license to submit that<br />
work with modifications, whether created in whole or in part<br />
by me, under the same open source license (unless I am<br />
permitted to submit under a different license), as indicated<br />
in the file; or<br />
<br />
(c) The contribution was provided directly to me by some other<br />
person who certified (a), (b) or (c) and I have not modified<br />
it.<br />
<br />
(d) I understand and agree that this project and the contribution<br />
are public and that a record of the contribution (including all<br />
personal information I submit with it, including my sign-off) is<br />
maintained indefinitely and may be redistributed consistent with<br />
this project or the open source license(s) involved.<br />
</pre><br />
<br />
=== Making good patches ===<br />
----<br />
Patches, if accepted, will turn into commits in the mercurial source tree. There are three people to think about when writing the patch and the comment:<br />
* Reviewers on the mailing list, who are trying to understand what your patch does, if it's correct, and what side effects it will have.<br />
* People skimming through changesets deciding if a patch is important for them to look at for backporting, review, implications on out-of-tree patches, &c.<br />
* Someone in the perhaps distant future, who is trying to understand why the code is the way it is.<br />
Try to make your patches with all of these people in mind. To do this:<br />
==== Break down your patches ====<br />
* Each patch should preferably do one logical thing (or one related set of things). The goal is for reviewers to understand the change that each patch is making with a minimum of effort.<br />
* No patch should ever break existing functionality.<br />
* Never fix bugs in one of your patches by changing it in a later patch; go back and change the patch with the bug in it.<br />
* Don't mix clean-up patches (which make things look prettier or move things round but don't change functionality) with code-change patches. Clean-up patches should be clearly marked as having no functional changes.<br />
==== Write a good description for each patch ====<br />
* If you're using mercurial queues, as described above, use <code>hg qrefresh -e</code> to edit the description, or edit the patch files directly in <code>.hg/patches/</code>. NB that if you edit the files directly, you'll have to <code>hg qpop -a ; hg qpush -a</code> to get the description into mercurial.<br />
* The first line the top of the patch should contain a short description of what the patch does, and hints as to what code it touches<br />
* The description should be useful for both the reviewers and people in the future trying to understand what the patch does. It can be as short as <code>Code cleanup -- no functional changes</code>, or as long as it takes to accurately describe the bug you are trying to solve or the new functionality you are introducing.<br />
* The description should be wrapped to a maximum of 80 columns.<br />
<br />
=== Sending the patches to the list ===<br />
----<br />
<br />
The xen-devel mailing list is moderated for non-subscribers. It is not mandatory to subscribe but it can help avoid this delay. It is possible to subscribe and then disable delivery in the mailman options so as to avoid moderation but not receive list traffic if that is what you would prefer.<br />
<br />
==== Mercurial Patchbomb Extension ====<br />
The most robust way to send files is by using the [http://mercurial.selenic.com/wiki/PatchbombExtension Mercurial Patchbomb extension]. <br />
<br />
To do this, first set up the Patchbomb extension in your <code>.hgrc</code> file:<br />
<br />
<pre><br />
[extensions]<br />
hgext.patchbomb =<br />
<br />
[email]<br />
method = smtp<br />
from = Your Name <your.email@your-domain.com><br />
cc = your.email@your-domain.com<br />
<br />
[smtp]<br />
host = mail.yourdomain.com<br />
port = 25<br />
</pre><br />
<br />
Then check to make sure you have the right patches to be submitted by using <code>hg out</code>:<br />
<br />
<pre><br />
$ hg out<br />
comparing with http://hg/xen-unstable.hg<br />
searching for changes<br />
changeset: 21165:2631707c54b3<br />
tag: qbase<br />
tag: add-trondle-call.diff<br />
user: Joe Smith <joe.smith@citrix.com><br />
date: Wed Apr 14 11:16:58 2010 +0100<br />
summary: foobar: Add new trondle calls<br />
<br />
...<br />
</pre><br />
<br />
Next you need to figure out who (if anyone) you should copy the patches to. To do this you should consult the <code>MAINTAINERS</code> file at the top of the Xen source tree. If there is a specific maintainer listed for the area of the code you are modifying then it is best to copy the patches to them. You should always send patches to the xen-devel@lists.xensource.com mailing list as well.<br />
<br />
Once you're sure you have the proper series of patches and know who you are sending it to then you're ready to use the patchbomb tool:<br />
<br />
<pre><br />
$ hg email -o --plain --to xen-devel@lists.xensource.com --cc the.maintainer@example.com<br />
</pre><br />
<br />
(The <code>-o</code> option tells patchbomb to submit all outgoing patches; <code>--plain</code> removes the extraneous HG header information from the patches in the e-mails; <code>--to</code> and <code>--cc</code> say who to send the mail to.) It will ask you some questions, like this:<br />
<br />
<pre><br />
comparing with http://hg/xen-unstable.hg<br />
searching for changes<br />
This patch series consists of 5 patches.<br />
<br />
Subject: [PATCH 0 of 5]<br />
</pre><br />
<br />
Enter in a summary for the entire patch series here, and press enter. You will then be dropped into an editor, to write the text for the patch series intro e-mail. <br />
<br />
NB, emacs users: if you're running this from an emacs shell, this can get tricky, since all of the editors it wants to offer you require a terminal. Best to run it in a normal terminal window somewhere.<br />
<br />
Tada! You should shortly see your patch series appear in your inbox, and on the xen-devel mailing list (depending on how you've configured it.)<br />
<br />
Other useful options include:<br />
* <code>-n</code> will go through all the motions of preparing the patchbomb, but instead of sending a mail, will just output the mails it would have sent. Useful for testing.<br />
* <code>-d</code> produces a "diffstat", showing lines added and removed for each file. It asks a lot more questions, though.<br />
* <code>-s</code> & <code>--desc</code> allow you to specify a subject line and body respectively for the summary email.<br />
* <code>firstpatch:lastpatch</code> allows you to name a specific range of patches to send and can be used instead of the <code>-o</code> option.<br />
<br />
==== Sending Patches Manually ====<br />
<br />
It is strongly recommended to use the Mercurial patchbomb extension discussed above. However it is possible to send a patch manually using your regular mail client. <br />
<br />
You should be aware that many mail clients have a tendency to mangle the whitespace of a patch making it impossible to apply. It is highly recommended to read Linux's [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt;hb=HEAD email-clients.txt] for advice on how to avoid this in popular mail clients.<br />
<br />
=== Review, Rinse & Repeat ===<br />
----<br />
<br />
After posting your patches you will hopefully see some response in the form of comments, patch review and eventually commit.<br />
<br />
The form of the review may often be quite direct and to the point which may be daunting for some people. However bear in mind that detailed criticism of a patch usually means that the reviewer is interested in your patch and wants to see it go in!<br />
<br />
Once you have addressed any review you should normally resend the patch. It is normally expected that you address all review before reposting. This often means code changes in your patch but could also mean simply responding to the review comments explaining you reasoning or giving reasons why something should be the way it is.<br />
<br />
When resending a patch you should normally include a note of what has changed since last time in the message. Common practice is to include these notes after your Signed-off-by separated by a triple-dash ("---"). This indicates patch commentary specific to the posting which need not be included in the final changelog (although you should also remember to update the changelog if necessary). You should also including a "V2" (V3, V4 etc) tag in the subject line (if you are using the Mercurial patchbomb extension then the <code>--flag</code> option is helpful here).<br />
<br />
If someone replies to your patch with a tag of the form "Acked-by: <Developer>", "Reviewed-by:", "Tested-by:" etc then, assuming you have not completely reworked the patch, you should include these tags in any reposting after your own Signed-off-by line. This lets people know that the patch has been seen and that someone approves of it and also serves to prevent reviewers wasting time re-reviewing a patch which is not significantly different to last time. The developers with commit access also like to see postings with such tags since it means they are likely to be much easier to deal with and commit.<br />
<br />
An example of a resend of the example patch from above might be:<br />
<pre><br />
Subject: [PATCH v2] foobar: Add a new trondle calls<br />
<br />
Add a some new trondle calls to the foobar interface to support<br />
the new zot feature.<br />
<br />
Signed-off-by: Joe Smith <joe.smith@citrix.com><br />
Acked-by: Jane Doe <jane.doe@example.com><br />
<br />
---<br />
Changed since v1:<br />
* fix coding style<br />
* be sure to treadle the trondle in the error case.<br />
<br />
diff -r 63531e640828 tools/libxc/Makefile<br />
--- a/tools/libxc/Makefile Mon Dec 07 17:01:11 2009 +0000<br />
+++ b/tools/libxc/Makefile Mon Dec 21 11:45:00 2009 +0000<br />
...<br />
</pre><br />
<br />
If you do not get any response to your patch or you got lots of Acked-by's but the patch has not been committed (remember that reviewers and maintainers are busy people too and sometimes things may fall through the cracks) then after some time, perhaps 2-4 weeks ([http://blog.xen.org/index.php/2009/09/16/submitting-patches-to-xen-org-community/ guidelines]), you should resend the patch, perhaps including [RESEND] in the subject line to alert people that the last mail was dropped. Before resending it may be worth considering if there is anything you can do to improve the commit message or subject line of your patch to better attract the attention of the relevant people. Remember to include any Acked-by/Reviewed-by which you received in response to the previous post.<br />
<br />
=== What If ===<br />
----<br />
* Your patch is really big?<br />
** Break it up into smaller logically distinct patches<br />
** Example - http://markmail.org/thread/e36vcwk3347de27n<br />
* You have lots and lots of patches? If you are going to generate > 20 patches a week:<br />
** You might want to host a repository tree that the maintainers can pull from, talk to the maintainers<br />
<br />
=== After your patch is committed ===<br />
<br />
Changes committed to Xen by the committers are immediately available in the "staging" repositories, for example http://xenbits.xen.org/staging/xen-unstable.hg. They are then automatically tested, and if the tests pass the changes are propagated to the main tree http://xenbits.xen.org/xen-unstable.hg.<br />
<br />
If your patch turns out to break something you will be expected to respond promptly to help diagnose and fix the problem. If it can't be fixed quickly, your change may be reverted.<br />
<br />
[[Category:Developers]]<br />
[[Category:Development Process]]<br />
[[Category:Xen]]<br />
<br />
== How To Generate and Submit a Patch to Qemu-Xen ==<br />
<br />
Xen uses QEMU as device model, that is the software component that takes care of emulating devices (like the network card) for HVM guests.<br />
Two QEMU trees, both using [http://git-scm.com/ git] for revision control, are currently in use by xen-unstable.hg:<br />
<br />
- [http://xenbits.xen.org/gitweb/?p=qemu-xen-unstable.git;a=summary qemu-xen-traditional]: old and stable tree, only bug fixes are accepted in this tree at the moment;<br />
<br />
- [http://xenbits.xen.org/gitweb/?p=staging/qemu-upstream-unstable.git;a=summary qemu-xen]: new tree used for development, based on the latest stable branch of Upstream QEMU, that currently is available at [http://git.qemu.org/ qemu git repo]. See [[QEMU Upstream]] on how to manually build it and use it to run VMs.<br />
<br />
<br />
New features should be developed again the latest upstream QEMU first, see http://wiki.qemu.org/Contribute/SubmitAPatch, then upon request they can be backported to qemu-xen.<br />
Only patches that have been acked and committed to [http://git.qemu.org/qemu.git qemu.git] are eligible to be backported to qemu-xen.<br />
In order to request a backport, send an email to xen-devel@lists.xen.org, specifying the original commit id in qemu.git and the reason why the patch should be backported to qemu-xen.<br />
<br />
== How to Generate, and Submit a Xen Patch to the Linux Tree ==<br />
<br />
Linux uses the git SCM, unlike Xen, which currently uses Mercurial. The Linux tree contains documentation on submitting patches, in Documentation/SubmittingPatches, as well as a script (scripts/checkpatch.pl) that ensures your patch is in Linux house style. Running git apply --check on your patch can reveal merge errors.<br />
<br />
Patches should be emailed to xen-devel@lists.xen.org, linux-kernel@vger.kernel.org, and any relevant maintainers (which can be found by running scripts/get_maintainer.pl on your patch).</div>OliverChickhttps://wiki.xenproject.org/index.php?title=XEND&diff=5063XEND2012-09-24T10:32:57Z<p>OliverChick: XEND now deprecated - added banner and update `to be deprecated' claims</p>
<hr />
<div>{{Info|This section contains link to Xen manual pages that are generated from the Xen codebase. They reflect the state of '''xen-unstable.hg'''. We do not yet have versions for specific Xen releases, but will have them in future}}<br />
<br />
{{Warning|Note that '''XEND''' has been deprecated! See [[MigrationGuideToXen4.1%2B#Toolstack_upgrade_notes|Xen 4.1 Upgrade Notes]] for more details.}}<br />
<br />
== Man Pages ==<br />
<br />
== Xen Man Pages ==<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Man page<br />
! Description<br />
|-<br />
| [http://xenbits.xen.org/docs/unstable/man/xm.1.html xm(1)]<br />
| Xen management user interface (deprecated, also see [[MigrationGuideToXen4.1%2B#Toolstack_upgrade_notes|Xen 4.1 Upgrade Notes]])<br />
|-<br />
| [http://xenbits.xen.org/docs/unstable/man/xend-config.sxp.5.html xend-config.sxp(5)]<br />
| Xen daemon configuration file (deprecated, also see [[MigrationGuideToXen4.1%2B#Toolstack_upgrade_notes|Xen 4.1 Upgrade Notes]])<br />
|-<br />
| [http://xenbits.xen.org/docs/unstable/man/xmdomain.cfg.5.html xmdomain.cfg(5)]<br />
| XM domain config file format (deprecated, also see [[MigrationGuideToXen4.1%2B#Toolstack_upgrade_notes|Xen 4.1 Upgrade Notes]])<br />
|-<br />
| [http://xenbits.xen.org/docs/unstable/misc/sedf_scheduler_mini-HOWTO.txt xm.cfg(5), '''sEDF scheduler''']<br />
| The sEDF scheduler provides weighted CPU sharing in an intuitive way and uses realtime-algorithms to ensure time guarantees.<br />
|}<br />
<br />
== Also See ==<br />
* [[XL vs Xend Feature Comparison]]<br />
[[Category:Beginners]]<br />
[[Category:Users]]<br />
[[Category:Developers]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=XM&diff=5061XM2012-09-24T10:30:46Z<p>OliverChick: XM has now been deprecated.</p>
<hr />
<div>{{Info|This section contains link to Xen manual pages that are generated from the Xen codebase. They reflect the state of '''xen-unstable.hg'''. We do not yet have versions for specific Xen releases, but will have them in future}}<br />
{{Warning|Note that '''xm''' has been deprecated! See [[MigrationGuideToXen4.1%2B#Toolstack_upgrade_notes|Xen 4.1 Upgrade Notes]] for more details.}}<br />
<br />
{| class="wikitable"<br />
|-<br />
! Document related to xm and xmdomain.cfg<br />
! Description<br />
|-<br />
| [http://xenbits.xen.org/docs/unstable/man/xm.1.html xm(1)]<br />
| Xen management user interface <br />
|-<br />
| [http://xenbits.xen.org/docs/unstable/man/xmdomain.cfg.5.html xmdomain.cfg(5)]<br />
| XM domain config file format<br />
|-<br />
| [http://xenbits.xen.org/docs/unstable/misc/sedf_scheduler_mini-HOWTO.txt xm.cfg(5), '''sEDF scheduler''']<br />
| The sEDF scheduler provides weighted CPU sharing in an intuitive way and uses realtime-algorithms to ensure time guarantees.<br />
|}<br />
<br />
[[Category:Beginners]]<br />
[[Category:Users]]<br />
[[Category:Developers]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_Document_Days/TODO&diff=5059Xen Document Days/TODO2012-09-24T10:28:21Z<p>OliverChick: /* Easy/beginners: Getting started with Xen using xen-tools (copy and paste from blog to wiki) */ Removed as I have done the import of IanJ's blog post.</p>
<hr />
<div>Go back to [[Xen Document Days]]<br />
<br />
== Requested Documentation ==<br />
<br />
{{Info|Feel free to comment on items using the following convention:<br />
<pre>* ~~~~: your comment</pre><br />
Feel free to add new workitems using the following convention:<br />
<pre>==== Workitem ===<br />
~~~~: work-item description<br />
</pre>}}<br />
<br />
=== In progress (just need to double check whether finished) ===<br />
<br />
==== Improve networking documentation ====<br />
Expand [[Host Configuration/Networking]] docs to cover non-bridge network configurations supported by xend (e.g. routed, nat'd). Possibly split into a page per config.<br />
* [[User:Lars.kurth|Lars.kurth]] 19:50, 25 June 2012 (UTC) : Significant work has been done to [[Xen Networking]]. Not sure whether the review tag from [[Xen_Networking]] can be removed <br />
* [[User:Ijc|Ijc]] 08:31, 28 June 2012 (UTC): IMHO not yet. I'll continue to work on the remainder of the doc and then remove the tag.<br />
* [[User:Lars.kurth|Lars.kurth]] 15:53, 19 September 2012 (UTC): Checked with ijc, needs a little more work<br />
<br />
==== A Xen Performance Tuning Guide ====<br />
* Which workloads work for which virt mode. Network considerations. NUMA. VCPU Pinning. Etc.<br />
* Examples from the KVM world: [http://sheepdog.taobao.org/people/zituan/kvm_tuning.html Guest perf tuning], [http://www.linux-kvm.org/page/Tuning_KVM KVM options affecting performance], [http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=%2Fliaat%2Fliaattunkickoff.htm Comprehensive guide covering pinning, caching, memory, huge pages, etc.] <br />
* [[User:Lars.kurth|Lars.kurth]] 19:50, 25 June 2012 (UTC) : Work has been done on [[Tuning]]. Not sure whether more needs to be done.<br />
* [[User:StefanoStabellini|Stefano]] 30 June 2012: The guide is in a decent state but I will keep improving it during the next doc days.<br />
* [[User:Lars.kurth|Lars.kurth]] 15:54, 19 September 2012 (UTC): Needs a quick sanity check for Xen 4.2<br />
<br />
=== Open work items ===<br />
<br />
==== cpupools intro / howto ====<br />
* [[user:Dunlapg|George Dunlap]] I plan on doing this for September's doc day.<br />
<br />
==== XCP Overview ====<br />
Similar to [[Xen Overview]]<br />
<br />
==== A Xen Security Guide ====<br />
The different options in Xen for Security, trade-offs, how to set them up, how to test Xen for security and how to optimize for different scenarios<br />
* [[User:Lars.kurth|Lars.kurth]] 09:48, 27 March 2012 (UTC): [[:Category:Security]] contains some security related docs<br />
* [[User:Lars.kurth|Lars.kurth]] 11:01, 4 April 2012 (UTC): It would be good if we could document a) XSM, b) Introspection API, c) Xen and SELinux in Dom0, d) Memory Access API (introduced in 4.1)<br />
* User Docs that where migrating content would make sense and update such as (we can attach PDF's to the wiki now for starters, or we can use a [http://www.appropedia.org/Appropedia:Porting_PDF_files_to_MediaWiki conversion tool]<br />
** http://bits.xensource.com/Xen/docs/user.pdf<br />
* [[User:Lars.kurth|Lars.kurth]] 15:59, 19 September 2012 (UTC): Some good articles came out of XenSummit NA (these can be built upon). Got funding to document XSM.<br />
<br />
==== Review and Update: xenpm usage recommendations ====<br />
There is [[Xen power management]] and [[Xenpm command]] which may all be outdated. These should probably be reviewed and updated.<br />
<br />
==== HOWTO : using xm trigger to poweroff or firing off NMIs ====<br />
Howto on using xm trigger to poweroff or firing off NMIs.<br />
<br />
==== HOWTO: Setting boot order for domUs (PV and HVM) ==== <br />
Howto set up boot order for domUs (all virt modes)<br />
<br />
==== HOWTO: Chain pypxeboot and pygrub====<br />
How to chain [http://sourceforge.net/projects/pypxeboot/ pypxeboot] and pygrub <br />
* [[User:Lars.kurth|Lars.kurth]] 10:35, 27 March 2012 (UTC): Is pypxeboot popular at all?<br />
* [[User:Fheigl|Fheigl]] I added that. It is somewhat common, OVM 2 and OVM 3 rely on it for PXE installs. I'm not sure if xenpvnetboot is the same, or works. The use case is "you want to use the same installation server for Xen VMs and phys. servers. You want to be able to reinstall them based on PXE reply.<br />
* [[User:Fheigl|Fheigl]] There is documentation for pypxeboot, but there is no (afaik) documentation for how pygrub is used as a fallback loader. We wasted many days just to get some hack that can't even load a newer kernel. Which sucks, in the end you spend more time/money making PV PXE boot work than you save by using virtualized servers.<br />
* [[User:Fheigl|Fheigl]] Q3: How could it be popular given the state of documentation. <= Key issue to the left of this sentence.<br />
* [[User:Lars.kurth|Lars.kurth]] 16:03, 19 September 2012 (UTC) : wondering whether [https://vimeo.com/46125332 this video] contains what is needed<br />
<br />
== Done Recently ==<br />
==== Clear up Xen TODO List ====<br />
* [[XenDevelopmentProjects]] - although this will need maintaining<br />
* Revamp http://wiki.xen.org/wiki/Xen_PCI_Passthrough. Should be more organized, easier to follow, less verbose, more thorough, and more up-to-date.<br />
* Review and update http://en.wikipedia.org/wiki/Xen - in particular the "Host: Unix-like systems" is out-of-date. The Guest section is too.<br />
* Make [[:Category:Host_Install|Host Install]] and [[:Category:Guest_Install|Guest Install]] more useful <br />
** [[User:Lars.kurth|Lars.kurth]] Note: both pages share [[Template:Distro_Resources]]<br />
** Docs for many distros are missing: identify what docs are missing or out of date and put them on the todo list<br />
* Feature Status Doc : [[Xen_Release_Features]]<br />
* [[Xen Overview]] which explains the top level architectural features and options, trade-offs and links to examples tutorials that show how you set these up<br />
* List i.e. stuff what to test after packaging. This would avoid the current state of affairs where most distros are infact broken w/re to Xen. See [[Distros]]<br />
* Installation Guides: How to install on various distros. Tag with [[:Category:Host Install]] and [[:Category:Guest_Install]].<br />
*[[Tuning]]<br />
* vcpu pinning (part of [[Tuning]])<br />
<br />
== Developer Docs ==<br />
<br />
=== Docs that need attention or are missing ===<br />
* Make XAPI docs (built from source) available on xen.org<br />
* PVOPS portal on xen.org - Konrad volunteered<br />
* some more xenstore docs (i.e. recent python bindings that were sent to the -users list<br />
* Using libxenstat python bindings (imo they're broken)<br />
* More PV protocol docs (see recent patches to blkif.h for example)<br />
* Document xenstore paths used by guests and toolstack etc<br />
<br />
== Wiki Maintenance ==<br />
=== Fix articles that need attention ===<br />
* [[:Category:Contains_Needs_Action]] - Pages that need fixing<br />
* [[:Category:Contains_Needs_Formatting]] - Pages that need formatting<br />
* [[Special:WantedPages]] - Missing pages (many may just need to be migrated), some may be obsolete<br />
<br />
=== Review Categorization ===<br />
We need to go through some of the categies on the http://wiki.xen.org/wiki/Main_Page and decise whether there are documents in each category that need to be highlighted in a trail, etc.<br />
<br />
=== Loose ends on migration ===<br />
* Migrate remaining wiki pages (see [[Wiki_Community/Migration_Instructions_from_Old_to_New_Xen_Wiki]])<br />
<br />
<br />
[[Category:Community]]<br />
[[Category:Events]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_tools&diff=5058Xen tools2012-09-24T10:26:35Z<p>OliverChick: Import of IanJ's xen-tools blog post. A few minor modifications were made, to make it read as a Wiki page, rather than a blog post</p>
<hr />
<div>==xen-tools—a straightforward VM provisioning/installation tool==<br />
<br />
Xen-tools is a straightforward Xen VM provisioning tool with an unusual but attractive approach. It is used in the Xen.org automated testing system, for installing Debian-derived test VMs, but can also be run from the command line.<br />
<br />
==What makes xen-tools special?==<br />
<br />
Most VM provisioning tools arrange to run the guest’s copy of its own installer, in a fresh VM with a blank disk. They provide preseeding information with the answers to the questions that the installer asks. Another common approach is to have a blessed disk image, and make a guest by making a copy (perhaps a copy-on-write clone) of the master.<br />
<br />
xen-tools doesn’t work like that. Instead, it relies on the existing Debian tools for installing chroots. chroots are a kind of lightweight near-virtualisation and are very heavily used by Debian’s developers to allow them to develop packages for different versions of the OS from the one they have installed (including perhaps different derivatives—so for example allowing packages for Ubuntu to be developed on a Debian machine or vice versa). Sometimes users find it chroots useful to gain access to different versions of software packages too.<br />
<br />
xen-tools uses the chroot installation tool debootstrap: it sets up the disk area or LVM for the new VM, and then installs the new guest by running debootstrap in the management domain. The resulting approach is very simple compared to a VM-based run of the entire installer. There is no need to manage the booting of the installer, provide it with preseed information to configure it properly, and so forth. Logging and error handling are much improved. And you get pretty good control over the exact contents of the guest.<br />
<br />
==When should you choose xen-tools?==<br />
<br />
Xen-tools is aimed at systems administered from the command-line using xl/xm (perhaps with some management layer on top of that). xen-tools will write a domain configuration file suitable for use with xl or xm.<br />
<br />
The biggest limitation is that it can only install a limited set of guests. The version of xen-tools in Debian testing can install most versions of Debian or Ubuntu, and also has support for CentOS 5 and 6. (The CentOS support is done using rinse rather than debootstrap.)<br />
<br />
You should not install an operating system with xen-tools if you mistrust, from a security point of view, the source of the binary packages for that OS. This is because xen-tools’s installation approach doesn’t do the actual installation in a VM and in principle it would be possible for a rogue package to “escape” from the installation process and contaminate your host. This isn’t relevant, of course, if your host is Debian and you are intending to install a Debian guest. And the attack would have to come in the form of maliciously bad packages from the Debian, Ubuntu or CentOS mirrors, which is pretty unlikely.<br />
<br />
But if you can use xen-tools I think you’ll find it simple and convenient to use—and fast, especially if you have a local mirror.<br />
<br />
==How to use xen-tools==<br />
<br />
The primary entrypoint is the program xen-create-image. It has a comprehensive manual page.<br />
<br />
xen-create-image knows how to create LVs for the disk and swap. Here’s an example invocation from the Xen.org automated testing system:<br />
<br />
xen-create-image \<br />
--dhcp --mac 5a:36:0e:48:00:0e \<br />
--memory 512M --swap 1000M \<br />
--dist squeeze \<br />
--mirror http://10.80.16.196/debian \<br />
--hostname debian.guest.osstest \<br />
--lvm field-cricket --force \<br />
--kernel /boot/vmlinuz-2.6.32.57 \<br />
--initrd /boot/initrd.img-2.6.32.57 \<br />
--arch i386 <br />
<br />
After having done that there are some wrinkles that my automatic test system fixes up: it overwrite the ssh keys and authorization setup so that all test VMs all have the same keys. The inittab is modified to spawn a console on the guest’s Xen PV console hvc0:<br />
<br />
xc:2345:respawn:/sbin/getty 38400 hvc0 <br />
<br />
==Summary==<br />
<br />
So all in all I think xen-tools is a straightforward and convenient tool for doing a particular job well. Thanks to Axel Beckert, Dmitry Nedospasov, Stéphane Jourdois, Steve Kemp and the other contributors to xen-tools!</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_Document_Days/TODO&diff=5053Xen Document Days/TODO2012-09-24T10:04:10Z<p>OliverChick: /* Easy/beginners: Clean up Xen_4.2_Man_Pages */ Removed as I have done the cleanup</p>
<hr />
<div>Go back to [[Xen Document Days]]<br />
<br />
== Requested Documentation ==<br />
<br />
{{Info|Feel free to comment on items using the following convention:<br />
<pre>* ~~~~: your comment</pre><br />
Feel free to add new workitems using the following convention:<br />
<pre>==== Workitem ===<br />
~~~~: work-item description<br />
</pre>}}<br />
<br />
=== In progress (just need to double check whether finished) ===<br />
<br />
==== Improve networking documentation ====<br />
Expand [[Host Configuration/Networking]] docs to cover non-bridge network configurations supported by xend (e.g. routed, nat'd). Possibly split into a page per config.<br />
* [[User:Lars.kurth|Lars.kurth]] 19:50, 25 June 2012 (UTC) : Significant work has been done to [[Xen Networking]]. Not sure whether the review tag from [[Xen_Networking]] can be removed <br />
* [[User:Ijc|Ijc]] 08:31, 28 June 2012 (UTC): IMHO not yet. I'll continue to work on the remainder of the doc and then remove the tag.<br />
* [[User:Lars.kurth|Lars.kurth]] 15:53, 19 September 2012 (UTC): Checked with ijc, needs a little more work<br />
<br />
==== A Xen Performance Tuning Guide ====<br />
* Which workloads work for which virt mode. Network considerations. NUMA. VCPU Pinning. Etc.<br />
* Examples from the KVM world: [http://sheepdog.taobao.org/people/zituan/kvm_tuning.html Guest perf tuning], [http://www.linux-kvm.org/page/Tuning_KVM KVM options affecting performance], [http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=%2Fliaat%2Fliaattunkickoff.htm Comprehensive guide covering pinning, caching, memory, huge pages, etc.] <br />
* [[User:Lars.kurth|Lars.kurth]] 19:50, 25 June 2012 (UTC) : Work has been done on [[Tuning]]. Not sure whether more needs to be done.<br />
* [[User:StefanoStabellini|Stefano]] 30 June 2012: The guide is in a decent state but I will keep improving it during the next doc days.<br />
* [[User:Lars.kurth|Lars.kurth]] 15:54, 19 September 2012 (UTC): Needs a quick sanity check for Xen 4.2<br />
<br />
=== Open work items ===<br />
<br />
==== Easy/beginners: Getting started with Xen using xen-tools (copy and paste from blog to wiki) ====<br />
Have a [http://blog.xen.org/index.php/2012/08/31/xen-tools-a-straightforward-vm-provisioninginstallation-tool/ blog post]. Copy and paste to wiki.<br />
<br />
==== cpupools intro / howto ====<br />
* [[user:Dunlapg|George Dunlap]] I plan on doing this for September's doc day.<br />
<br />
==== XCP Overview ====<br />
Similar to [[Xen Overview]]<br />
<br />
==== A Xen Security Guide ====<br />
The different options in Xen for Security, trade-offs, how to set them up, how to test Xen for security and how to optimize for different scenarios<br />
* [[User:Lars.kurth|Lars.kurth]] 09:48, 27 March 2012 (UTC): [[:Category:Security]] contains some security related docs<br />
* [[User:Lars.kurth|Lars.kurth]] 11:01, 4 April 2012 (UTC): It would be good if we could document a) XSM, b) Introspection API, c) Xen and SELinux in Dom0, d) Memory Access API (introduced in 4.1)<br />
* User Docs that where migrating content would make sense and update such as (we can attach PDF's to the wiki now for starters, or we can use a [http://www.appropedia.org/Appropedia:Porting_PDF_files_to_MediaWiki conversion tool]<br />
** http://bits.xensource.com/Xen/docs/user.pdf<br />
* [[User:Lars.kurth|Lars.kurth]] 15:59, 19 September 2012 (UTC): Some good articles came out of XenSummit NA (these can be built upon). Got funding to document XSM.<br />
<br />
==== Review and Update: xenpm usage recommendations ====<br />
There is [[Xen power management]] and [[Xenpm command]] which may all be outdated. These should probably be reviewed and updated.<br />
<br />
==== HOWTO : using xm trigger to poweroff or firing off NMIs ====<br />
Howto on using xm trigger to poweroff or firing off NMIs.<br />
<br />
==== HOWTO: Setting boot order for domUs (PV and HVM) ==== <br />
Howto set up boot order for domUs (all virt modes)<br />
<br />
==== HOWTO: Chain pypxeboot and pygrub====<br />
How to chain [http://sourceforge.net/projects/pypxeboot/ pypxeboot] and pygrub <br />
* [[User:Lars.kurth|Lars.kurth]] 10:35, 27 March 2012 (UTC): Is pypxeboot popular at all?<br />
* [[User:Fheigl|Fheigl]] I added that. It is somewhat common, OVM 2 and OVM 3 rely on it for PXE installs. I'm not sure if xenpvnetboot is the same, or works. The use case is "you want to use the same installation server for Xen VMs and phys. servers. You want to be able to reinstall them based on PXE reply.<br />
* [[User:Fheigl|Fheigl]] There is documentation for pypxeboot, but there is no (afaik) documentation for how pygrub is used as a fallback loader. We wasted many days just to get some hack that can't even load a newer kernel. Which sucks, in the end you spend more time/money making PV PXE boot work than you save by using virtualized servers.<br />
* [[User:Fheigl|Fheigl]] Q3: How could it be popular given the state of documentation. <= Key issue to the left of this sentence.<br />
* [[User:Lars.kurth|Lars.kurth]] 16:03, 19 September 2012 (UTC) : wondering whether [https://vimeo.com/46125332 this video] contains what is needed<br />
<br />
== Done Recently ==<br />
==== Clear up Xen TODO List ====<br />
* [[XenDevelopmentProjects]] - although this will need maintaining<br />
* Revamp http://wiki.xen.org/wiki/Xen_PCI_Passthrough. Should be more organized, easier to follow, less verbose, more thorough, and more up-to-date.<br />
* Review and update http://en.wikipedia.org/wiki/Xen - in particular the "Host: Unix-like systems" is out-of-date. The Guest section is too.<br />
* Make [[:Category:Host_Install|Host Install]] and [[:Category:Guest_Install|Guest Install]] more useful <br />
** [[User:Lars.kurth|Lars.kurth]] Note: both pages share [[Template:Distro_Resources]]<br />
** Docs for many distros are missing: identify what docs are missing or out of date and put them on the todo list<br />
* Feature Status Doc : [[Xen_Release_Features]]<br />
* [[Xen Overview]] which explains the top level architectural features and options, trade-offs and links to examples tutorials that show how you set these up<br />
* List i.e. stuff what to test after packaging. This would avoid the current state of affairs where most distros are infact broken w/re to Xen. See [[Distros]]<br />
* Installation Guides: How to install on various distros. Tag with [[:Category:Host Install]] and [[:Category:Guest_Install]].<br />
*[[Tuning]]<br />
* vcpu pinning (part of [[Tuning]])<br />
<br />
== Developer Docs ==<br />
<br />
=== Docs that need attention or are missing ===<br />
* Make XAPI docs (built from source) available on xen.org<br />
* PVOPS portal on xen.org - Konrad volunteered<br />
* some more xenstore docs (i.e. recent python bindings that were sent to the -users list<br />
* Using libxenstat python bindings (imo they're broken)<br />
* More PV protocol docs (see recent patches to blkif.h for example)<br />
* Document xenstore paths used by guests and toolstack etc<br />
<br />
== Wiki Maintenance ==<br />
=== Fix articles that need attention ===<br />
* [[:Category:Contains_Needs_Action]] - Pages that need fixing<br />
* [[:Category:Contains_Needs_Formatting]] - Pages that need formatting<br />
* [[Special:WantedPages]] - Missing pages (many may just need to be migrated), some may be obsolete<br />
<br />
=== Review Categorization ===<br />
We need to go through some of the categies on the http://wiki.xen.org/wiki/Main_Page and decise whether there are documents in each category that need to be highlighted in a trail, etc.<br />
<br />
=== Loose ends on migration ===<br />
* Migrate remaining wiki pages (see [[Wiki_Community/Migration_Instructions_from_Old_to_New_Xen_Wiki]])<br />
<br />
<br />
[[Category:Community]]<br />
[[Category:Events]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_4.2_Man_Pages&diff=5052Xen 4.2 Man Pages2012-09-24T10:01:53Z<p>OliverChick: Imported missing pages from http://xenbits.xen.org/docs/4.2-testing/</p>
<hr />
<div>{{Info|This section contains link to Xen manual pages that are generated from the Xen codebase. They reflect the state of '''4.2-testing'''. We do not yet have versions for specific Xen releases, but will have them in future}}<br />
<br />
== Wiki Man Pages ==<br />
See [[:Category:ManPage]]<br />
<br />
== All Generated Man Pages ==<br />
See [http://xenbits.xen.org/docs/4.2-testing/ xenbits.xen.org/docs/4.2-testing] <br />
<br />
<b>Note that the pages below may miss some new documents. If you do not find what you are looking for: please check the link above!</b><br />
<br />
== Xen Man Pages ==<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Man page<br />
! Description<br />
! Console<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/man/xl.1.html xl(1)]<br />
| Xen management tool, based on LibXenlight<br />
| XL<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/man/xm.1.html xm(1)]<br />
| Xen management user interface (deprecated, also see [[MigrationGuideToXen4.1%2B#Toolstack_upgrade_notes|Xen 4.1 Upgrade Notes]])<br />
| XM<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/man/xend-config.sxp.5.html xend-config.sxp(5)]<br />
| Xen daemon configuration file (deprecated, also see [[MigrationGuideToXen4.1%2B#Toolstack_upgrade_notes|Xen 4.1 Upgrade Notes]])<br />
| XM<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/man/xl.cfg.5.html xl.cfg(5)]<br />
| XL Domain Configuration File Syntax: to create a VM (a domain in Xen terminology, sometimes called a guest) with xl requires the provision of a domain config file. <br />
| XL<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/man/xl.conf.5.html xl.conf(5)]<br />
| XL Global/Host Configuration: allows configuration of hostwide xl toolstack options<br />
| XL<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/man/xlcpupool.cfg.5.html xlcpupool.cfg(5)]<br />
| XL Cpupool Configuration File Syntax: to create a Cpupool with xl requires the provision of a cpupool config file. <br />
| XL<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/man/xmdomain.cfg.5.html xmdomain.cfg(5)]<br />
| XM domain config file format (deprecated, also see [[MigrationGuideToXen4.1%2B#Toolstack_upgrade_notes|Xen 4.1 Upgrade Notes]])<br />
| XM<br />
|-<br />
| [[xentop(1)]]<br />
| xentop displays information about the Xen system and domains, in a continually-updating manner.<br />
| XENTOP<br />
|-<br />
| [[Xenpm_command|xenpm(1)]]<br />
| Xenpm is a userspace tool that can list the power information of available processors and control the power policy according to users' preference. <br />
| XENPM<br />
|}<br />
<br />
== Supporting Documents for XL & XM ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! Document<br />
! Description<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/xl-disk-configuration.txt xl.cfg(5), '''disk''' configuration]<br />
| This document specifies the xl config file format disk configuration option. <br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/xl-network-configuration.html xl.cfg(5), '''network''' configuration]<br />
| This document specifies the xl config file format vif configuration option. <br />
|- <br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/tscmode.txt xl.cfg(5), '''tsc_mode''' configuration]<br />
| In Xen 4 a new config option called tsc_mode may be specified for each domain. This document is targeted for Xen users and administrators that may need to select a non-default tsc_mode.<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/sedf_scheduler_mini-HOWTO.txt xm.cfg(5), '''sEDF scheduler''']<br />
| The sEDF scheduler provides weighted CPU sharing in an intuitive way and uses realtime-algorithms to ensure time guarantees.<br />
|}<br />
<br />
== Other documents ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! Document<br />
! Description<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/distro_mapping.txt Environment Variables for different Linux distros]<br />
| With directory layout differences between Red Hat, Debian, Suse and other distros one needs to set the variables for CONFIG_LEAF_DIR, SUBSYS_DIR and INITD_DIR.<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/distro_mapping.txt Distro directory layouts]<br />
| Overview of the differences in directory layout between RHEL, Debian and Suse.<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/kexec_and_kdump.txt Kexec, and kdump for Xen]<br />
| Guide to using kexec to switch to a new kernel; and kdump for catching a dump image, with Xen.<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/vtd.txt VT-d HOWTO]<br />
| How to use Intel's VT-d extensions.<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/xsm-flask.txt XSM/FLASK Configuration]<br />
| Configuring Xen to use the XSM/FLASK mandatory access control framework<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/dump-core-format.txt Xen Core Dump Format]<br />
| Format of the output of the x{m,l} core-dump command<br />
|-<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/xen-command-line.html Xeb Hypervisor Command Line Options]<br />
| List of hypervisor command line options<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/vbd-interface.txt Xen Guest Disk (VBD) interface]<br />
| The interface exposed to DomUs for communicating with block devices.<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/xenstore.txt Xenstore Protocol Definition]<br />
| Definition of standard behaviour, when using Xenstore.<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/efi.html EFI]<br />
| Configuring Xen to work with EFI.<br />
|}<br />
<br />
== Advanced topics ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! Document(s)<br />
! Description<br />
! Also See<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/vtd.txt How to do PCI Passthrough with VT-d]<br />
| <br />
| [[Xen_PCI_Passthrough|Xen PCI Passthrough Overview]], [[VTdHowTo|VT-d HowTo]]<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/vtpm.txt Virtual TPM support]<br />
| This document gives a short introduction to the virtual TPM support in XEN and goes as far as connecting a user domain to a virtual TPM instance and doing a short test to verify success. It is assumed that the user is fairly familiar with compiling and installing XEN and Linux on a machine.<br />
| [http://domino.research.ibm.com/comm/research_projects.nsf/pages/ssd_vtpm.index.html Virtual Trusted Platform Module (research note)]<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/grant-tables.txt A rough introduction to using grant tables]<br />
| Explanation of the data structures, and hypercalls required to share memory between domains.<br />
|<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/xen-error-handling.txt Xen Error Handling]<br />
| Explanation of the various types of error (BUG, ASSERT etc) that the hypervisor, and guest can call.<br />
|<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/hvm-emulated-unplug.html Xen HVM emulated device unplug protocol]<br />
| Definition of the protocol used to disconnect emulated deivces, get log messages from drivers, and prevent Dom0 from loading specific drivers. <br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/xenpaging.txt Xen paging]<br />
| Allow the sum of memory allocated to guests > physical memory available, by paging out.<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/crashdb.txt Xen Crash Debugger]<br />
| Using gdb to analyse why Xen has crashed.<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/qemu-upstream_howto_use_it.html Qemu Upstream: How to use it]<br />
| Pointer to a wiki page documenting how to build XXen with the QEMU unstable tree.<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/sedf_scheduler_mini-HOWTO.txt sEDF scheduler how to]<br />
| Using the SsEDF scheduler for weighted CPU sharing.<br />
|-<br />
| [http://xenbits.xen.org/docs/4.2-testing/misc/xl-numa-placement.html XL placement]<br />
| NUMA Node placement.<br />
|-<br />
| '''More documentation''':<br />
| See [http://xenbits.xen.org/docs/4.2-testing/ Generated documents]<br />
|}<br />
<br />
[[Category:Xen]]<br />
[[Category:Xen 4.2]]<br />
[[Category:ManPage]]<br />
[[Category:Manual]]<br />
[[Category:Beginners]]<br />
[[Category:Users]]<br />
[[Category:Developers]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Submitting_Xen_Project_Patches&diff=4989Submitting Xen Project Patches2012-09-14T16:11:03Z<p>OliverChick: /* After your patch is committed */ Corrected URL of the main tree.</p>
<hr />
<div>== How To Generate and Submit a Patch to Xen ==<br />
<br />
Xen uses [http://www.selenic.com/mercurial/wiki/index.cgi Mercurial] for its source code management. The current Xen development tree is at http://xenbits.xensource.com/xen-unstable.hg. An excellent [http://www.selenic.com/mercurial/wiki/index.cgi/Tutorial tutorial] is here. Download and install mercurial to your system.<br />
<br />
=== Generating a patch ===<br />
----<br />
Here's a recommendation on how to send patches, as suggested by the Xen maintainers.<br />
<br />
To begin, configure Mercurial by making the following additions to your <code>~/.hgrc</code>:<br />
<br />
* Enable the [http://mercurial.selenic.com/wiki/MqExtension Patchqueue extension]<br />
<br />
<pre><br />
[extensions]<br />
mq=<br />
</pre><br />
<br />
<br />
* Show function names in patch hunk headers (which makes patches easier to review).<br />
<br />
<pre><br />
[diff]<br />
showfunc=True<br />
</pre><br />
<br />
<br />
When you want to make a patch, create a patch on the patch queue:<br />
<br />
<pre><br />
hg qnew patch01.diff<br />
</pre><br />
<br />
<br />
Then edit the source files you want to change. You can see which files have changed by using <code>hg status</code>.<br />
<br />
When you're done editing, save your changes into the patch, and add a description. The easiest way to add a description is to use the <code>-e</code> option to <code>hg qrefresh</code>:<br />
<br />
<pre><br />
hg qrefresh -e<br />
</pre><br />
<br />
<br />
<pre><br />
foobar: Add a new trondle calls<br />
<br />
Add a some new trondle calls to the foobar interface to support<br />
the new zot feature.<br />
<br />
Signed-off-by: Joe Smith <joe.smith@citrix.com><br />
</pre><br />
<br />
Alternately, after refreshing the patch with <code>hg qrefresh</code>, you can edit the files directly in <code>.hg/patches/</code>. Everything above the line starting with <code>diff</code> will be ignored:<br />
<br />
<pre><br />
foobar: Add a new trondle calls<br />
<br />
Add a some new trondle calls to the foobar interface to support<br />
the new zot feature.<br />
<br />
Signed-off-by: Joe Smith <joe.smith@citrix.com><br />
<br />
diff -r 63531e640828 tools/libxc/Makefile<br />
--- a/tools/libxc/Makefile Mon Dec 07 17:01:11 2009 +0000<br />
+++ b/tools/libxc/Makefile Mon Dec 21 11:45:00 2009 +0000<br />
...<br />
</pre><br />
<br />
Repeat as necessary for all of your changes<br />
<br />
<pre><br />
hg qnew patch02.diff<br />
</pre><br />
<br />
...<br />
=== Signing off a patch ===<br />
----<br />
All patches to the Xen code base must include the the line "Signed-off-by: your_name <your_email>" at the end of the change description. This is required and indicates that you certify the patch under the "Developer's Certificate of Origin" which states:<br />
<br />
<br />
<pre><br />
Developer's Certificate of Origin 1.1<br />
<br />
By making a contribution to this project, I certify that:<br />
<br />
(a) The contribution was created in whole or in part by me and I<br />
have the right to submit it under the open source license<br />
indicated in the file; or<br />
<br />
(b) The contribution is based upon previous work that, to the best<br />
of my knowledge, is covered under an appropriate open source<br />
license and I have the right under that license to submit that<br />
work with modifications, whether created in whole or in part<br />
by me, under the same open source license (unless I am<br />
permitted to submit under a different license), as indicated<br />
in the file; or<br />
<br />
(c) The contribution was provided directly to me by some other<br />
person who certified (a), (b) or (c) and I have not modified<br />
it.<br />
<br />
(d) I understand and agree that this project and the contribution<br />
are public and that a record of the contribution (including all<br />
personal information I submit with it, including my sign-off) is<br />
maintained indefinitely and may be redistributed consistent with<br />
this project or the open source license(s) involved.<br />
</pre><br />
<br />
=== Making good patches ===<br />
----<br />
Patches, if accepted, will turn into commits in the mercurial source tree. There are three people to think about when writing the patch and the comment:<br />
* Reviewers on the mailing list, who are trying to understand what your patch does, if it's correct, and what side effects it will have.<br />
* People skimming through changesets deciding if a patch is important for them to look at for backporting, review, implications on out-of-tree patches, &c.<br />
* Someone in the perhaps distant future, who is trying to understand why the code is the way it is.<br />
Try to make your patches with all of these people in mind. To do this:<br />
==== Break down your patches ====<br />
* Each patch should preferably do one logical thing (or one related set of things). The goal is for reviewers to understand the change that each patch is making with a minimum of effort.<br />
* No patch should ever break existing functionality.<br />
* Never fix bugs in one of your patches by changing it in a later patch; go back and change the patch with the bug in it.<br />
* Don't mix clean-up patches (which make things look prettier or move things round but don't change functionality) with code-change patches. Clean-up patches should be clearly marked as having no functional changes.<br />
==== Write a good description for each patch ====<br />
* If you're using mercurial queues, as described above, use <code>hg qrefresh -e</code> to edit the description, or edit the patch files directly in <code>.hg/patches/</code>. NB that if you edit the files directly, you'll have to <code>hg qpop -a ; hg qpush -a</code> to get the description into mercurial.<br />
* The first line the top of the patch should contain a short description of what the patch does, and hints as to what code it touches<br />
* The description should be useful for both the reviewers and people in the future trying to understand what the patch does. It can be as short as <code>Code cleanup -- no functional changes</code>, or as long as it takes to accurately describe the bug you are trying to solve or the new functionality you are introducing.<br />
* The description should be wrapped to a maximum of 80 columns.<br />
<br />
=== Sending the patches to the list ===<br />
----<br />
<br />
The xen-devel mailing list is moderated for non-subscribers. It is not mandatory to subscribe but it can help avoid this delay. It is possible to subscribe and then disable delivery in the mailman options so as to avoid moderation but not receive list traffic if that is what you would prefer.<br />
<br />
==== Mercurial Patchbomb Extension ====<br />
The most robust way to send files is by using the [http://mercurial.selenic.com/wiki/PatchbombExtension Mercurial Patchbomb extension]. <br />
<br />
To do this, first set up the Patchbomb extension in your <code>.hgrc</code> file:<br />
<br />
<pre><br />
[extensions]<br />
hgext.patchbomb =<br />
<br />
[email]<br />
method = smtp<br />
from = Your Name <your.email@your-domain.com><br />
cc = your.email@your-domain.com<br />
<br />
[smtp]<br />
host = mail.yourdomain.com<br />
port = 25<br />
</pre><br />
<br />
Then check to make sure you have the right patches to be submitted by using <code>hg out</code>:<br />
<br />
<pre><br />
$ hg out<br />
comparing with http://hg/xen-unstable.hg<br />
searching for changes<br />
changeset: 21165:2631707c54b3<br />
tag: qbase<br />
tag: add-trondle-call.diff<br />
user: Joe Smith <joe.smith@citrix.com><br />
date: Wed Apr 14 11:16:58 2010 +0100<br />
summary: foobar: Add new trondle calls<br />
<br />
...<br />
</pre><br />
<br />
Next you need to figure out who (if anyone) you should copy the patches to. To do this you should consult the <code>MAINTAINERS</code> file at the top of the Xen source tree. If there is a specific maintainer listed for the area of the code you are modifying then it is best to copy the patches to them. You should always send patches to the xen-devel@lists.xensource.com mailing list as well.<br />
<br />
Once you're sure you have the proper series of patches and know who you are sending it to then you're ready to use the patchbomb tool:<br />
<br />
<pre><br />
$ hg email -o --plain --to xen-devel@lists.xensource.com --cc the.maintainer@example.com<br />
</pre><br />
<br />
(The <code>-o</code> option tells patchbomb to submit all outgoing patches; <code>--plain</code> removes the extraneous HG header information from the patches in the e-mails; <code>--to</code> and <code>--cc</code> say who to send the mail to.) It will ask you some questions, like this:<br />
<br />
<pre><br />
comparing with http://hg/xen-unstable.hg<br />
searching for changes<br />
This patch series consists of 5 patches.<br />
<br />
Subject: [PATCH 0 of 5]<br />
</pre><br />
<br />
Enter in a summary for the entire patch series here, and press enter. You will then be dropped into an editor, to write the text for the patch series intro e-mail. <br />
<br />
NB, emacs users: if you're running this from an emacs shell, this can get tricky, since all of the editors it wants to offer you require a terminal. Best to run it in a normal terminal window somewhere.<br />
<br />
Tada! You should shortly see your patch series appear in your inbox, and on the xen-devel mailing list (depending on how you've configured it.)<br />
<br />
Other useful options include:<br />
* <code>-n</code> will go through all the motions of preparing the patchbomb, but instead of sending a mail, will just output the mails it would have sent. Useful for testing.<br />
* <code>-d</code> produces a "diffstat", showing lines added and removed for each file. It asks a lot more questions, though.<br />
* <code>-s</code> & <code>--desc</code> allow you to specify a subject line and body respectively for the summary email.<br />
* <code>firstpatch:lastpatch</code> allows you to name a specific range of patches to send and can be used instead of the <code>-o</code> option.<br />
<br />
==== Sending Patches Manually ====<br />
<br />
It is strongly recommended to use the Mercurial patchbomb extension discussed above. However it is possible to send a patch manually using your regular mail client. <br />
<br />
You should be aware that many mail clients have a tendency to mangle the whitespace of a patch making it impossible to apply. It is highly recommended to read Linux's [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/email-clients.txt;hb=HEAD email-clients.txt] for advice on how to avoid this in popular mail clients.<br />
<br />
=== Review, Rinse & Repeat ===<br />
----<br />
<br />
After posting your patches you will hopefully see some response in the form of comments, patch review and eventually commit.<br />
<br />
The form of the review may often be quite direct and to the point which may be daunting for some people. However bear in mind that detailed criticism of a patch usually means that the reviewer is interested in your patch and wants to see it go in!<br />
<br />
Once you have addressed any review you should normally resend the patch. It is normally expected that you address all review before reposting. This often means code changes in your patch but could also mean simply responding to the review comments explaining you reasoning or giving reasons why something should be the way it is.<br />
<br />
When resending a patch you should normally include a note of what has changed since last time in the message. Common practice is to include these notes after your Signed-off-by separated by a triple-dash ("---"). This indicates patch commentary specific to the posting which need not be included in the final changelog (although you should also remember to update the changelog if necessary). You should also including a "V2" (V3, V4 etc) tag in the subject line (if you are using the Mercurial patchbomb extension then the <code>--flag</code> option is helpful here).<br />
<br />
If someone replies to your patch with a tag of the form "Acked-by: <Developer>", "Reviewed-by:", "Tested-by:" etc then, assuming you have not completely reworked the patch, you should include these tags in any reposting after your own Signed-off-by line. This lets people know that the patch has been seen and that someone approves of it and also serves to prevent reviewers wasting time re-reviewing a patch which is not significantly different to last time. The developers with commit access also like to see postings with such tags since it means they are likely to be much easier to deal with and commit.<br />
<br />
An example of a resend of the example patch from above might be:<br />
<pre><br />
Subject: [PATCH v2] foobar: Add a new trondle calls<br />
<br />
Add a some new trondle calls to the foobar interface to support<br />
the new zot feature.<br />
<br />
Signed-off-by: Joe Smith <joe.smith@citrix.com><br />
Acked-by: Jane Doe <jane.doe@example.com><br />
<br />
---<br />
Changed since v1:<br />
* fix coding style<br />
* be sure to treadle the trondle in the error case.<br />
<br />
diff -r 63531e640828 tools/libxc/Makefile<br />
--- a/tools/libxc/Makefile Mon Dec 07 17:01:11 2009 +0000<br />
+++ b/tools/libxc/Makefile Mon Dec 21 11:45:00 2009 +0000<br />
...<br />
</pre><br />
<br />
If you do not get any response to your patch or you got lots of Acked-by's but the patch has not been committed (remember that reviewers and maintainers are busy people too and sometimes things may fall through the cracks) then after some time, perhaps 2-4 weeks ([http://blog.xen.org/index.php/2009/09/16/submitting-patches-to-xen-org-community/ guidelines]), you should resend the patch, perhaps including [RESEND] in the subject line to alert people that the last mail was dropped. Before resending it may be worth considering if there is anything you can do to improve the commit message or subject line of your patch to better attract the attention of the relevant people. Remember to include any Acked-by/Reviewed-by which you received in response to the previous post.<br />
<br />
=== What If ===<br />
----<br />
* Your patch is really big?<br />
** Break it up into smaller logically distinct patches<br />
** Example - http://markmail.org/thread/e36vcwk3347de27n<br />
* You have lots and lots of patches? If you are going to generate > 20 patches a week:<br />
** You might want to host a repository tree that the maintainers can pull from, talk to the maintainers<br />
<br />
=== After your patch is committed ===<br />
<br />
Changes committed to Xen by the committers are immediately available in the "staging" repositories, for example http://xenbits.xen.org/staging/xen-unstable.hg. They are then automatically tested, and if the tests pass the changes are propagated to the main tree http://xenbits.xen.org/xen-unstable.hg.<br />
<br />
If your patch turns out to break something you will be expected to respond promptly to help diagnose and fix the problem. If it can't be fixed quickly, your change may be reverted.<br />
<br />
[[Category:Developers]]<br />
[[Category:Development Process]]<br />
[[Category:Xen]]<br />
<br />
== How To Generate and Submit a Patch to Qemu-Xen ==<br />
<br />
Xen uses QEMU as device model, that is the software component that takes care of emulating devices (like the network card) for HVM guests.<br />
Two QEMU trees, both using [http://git-scm.com/ git] for revision control, are currently in use by xen-unstable.hg:<br />
<br />
- [http://xenbits.xensource.com/git-http/qemu-xen-unstable.git qemu-xen-traditional]: old and stable tree, only bug fixes are accepted in this tree at the moment;<br />
<br />
- [http://xenbits.xen.org/git-http/qemu-upstream-unstable.git qemu-xen]: new tree used for development, based on the latest stable branch of Upstream QEMU, that currently is [http://git.qemu.org/pub/git/qemu-stable-1.0 qemu-stable-1.0]. See [[QEMU Upstream]] on how to manually build it and use it to run VMs.<br />
<br />
<br />
New features should be developed again the latest upstream QEMU first, see http://wiki.qemu.org/Contribute/SubmitAPatch, then upon request they can be backported to qemu-xen.<br />
Only patches that have been acked and committed to [http://git.qemu.org/qemu.git qemu.git] are eligible to be backported to qemu-xen.<br />
In order to request a backport, send an email to xen-devel@lists.xen.org, specifying the original commit id in qemu.git and the reason why the patch should be backported to qemu-xen.</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_Project_Schedulers&diff=4888Xen Project Schedulers2012-08-20T09:45:23Z<p>OliverChick: /* Xen Scheduling */ Fixed odd formatting around hyperlink to blog</p>
<hr />
<div><!-- MoinMoin name: Scheduling --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: Scheduling --><br />
<!-- Page revision: 00000017 --><br />
<!-- Original date: Sat Jun 9 18:29:49 2007 (1181413789000000) --><br />
<br />
{{TODO|This document gives an overview of Xen scheduling, but is likely out-of-date}}<br />
<br />
__NOTOC__<br />
= Xen Scheduling =<br />
This scheduling wiki page was originally compiled by [http://jacobmathai.blogspot.com Jacob Mathai].<br />
<br />
Xen includes kernel boot time options for scheduling. Similiar to traditional Linux schedulers that divide CPU time for userland processes, Below you will find some Xen & DomU options for the schedulers.<br />
<br />
== 1. Borrowed Virtual Time (Xen 2.0/3.0) ==<br />
<br />
<pre><nowiki><br />
sched=bvt<br />
Global Parameters<br />
ctx_allow - The context switch allowance is similar to the ''quantum'' in traditional schedulers. <br />
It is the minimum time that a scheduled domain will be allowed to run before being preempted.<br />
<br />
Per-domain parameters<br />
mcuadv - the MCU (Minimum Charging Unit) advance determines the proportional share of the CPU<br />
that a domain receives. It is set inversely proportionally to a domain's sharing weight.<br />
warp - the amount of `virtual time' the domain is allowed to warp backwards<br />
warpl - the warp limit is the maximum time a domain can run warped for<br />
warpu - the unwarp requirement is the minimum time a domain must run unwarped for before it can warp again<br />
</nowiki></pre><br />
<br />
== 2. Atropos (Xen 2.0) ==<br />
<br />
<pre><nowiki><br />
sched=atropos<br />
Atropos is a soft real time scheduler. It provides guarantees about absolute shares of the CPU, <br />
with a facility for sharing slack CPU time on a best-effort basis. It can provide timeliness <br />
guarantees for latency-sensitive domains.<br />
<br />
Every domain has an associated period and slice. The domain should receive `slice' nanoseconds <br />
every `period' nanoseconds. This allows the administrator to configure both the absolute share <br />
of the CPU a domain receives and the frequency with which it is scheduled.<br />
<br />
Note: don't over-commit the CPU when using Atropos (i.e. don't reserve more CPU than is <br />
available -- the utilization should be kept to slightly less than 100% in order to ensure predictable <br />
behavior).<br />
<br />
Per-domain parameters :<br />
period - The regular time interval during which a domain is guaranteed to receive its allocation of CPU time.<br />
slice - The length of time per period that a domain is guaranteed to run for (in the absence of voluntary yielding of the CPU).<br />
latency - The latency hint is used to control how soon after waking up a domain it should be scheduled.<br />
xtratime - This is a boolean flag that specifies whether a domain should be allowed a share of the system slack time.<br />
</nowiki></pre><br />
<br />
== 3. Round Robin (Xen 2.0) ==<br />
<br />
<pre><nowiki><br />
sched=rrobin<br />
The round robin scheduler is included as a simple demonstration of Xen's internal scheduler <br />
API. It is not intended for production use.<br />
<br />
Global Parameters<br />
rr_slice - The maximum time each domain runs before the next scheduling decision is made.<br />
</nowiki></pre><br />
<br />
== 4. sEDF scheduler (Xen 3.0) ==<br />
<br />
<pre><nowiki><br />
sched=sedf<br />
(from docs/misc/sedf_scheduler_mini-HOWTO.txt)<br />
This scheduler provides weighted CPU sharing in an intuitive way and uses realtime-algorithms <br />
to ensure time guarantees.<br />
<br />
Per-domain parameters<br />
use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"<br />
-period/slice are the normal EDF scheduling parameters in nanosecs<br />
-latency-hint is the scaled period in case the domain is doing heavy I/O<br />
(unused by the currently compiled version)<br />
-extra is a flag (0/1), which controls whether the domain can run in extra-time<br />
-weight is mutually exclusive with period/slice and specifies another way of setting a domains cpu slice<br />
See wikipedia for a short intro to EDF:<br />
http://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling<br />
</nowiki></pre><br />
<br />
== 5. ARINC 653 (Xen 4.0) ==<br />
<br />
<pre><nowiki><br />
sched=arinc653<br />
The arinc653 scheduler follows the ARINC 653 specification for scheduling, giving each partition (domain) a<br />
fixed, dedicated time slot for execution.<br />
<br />
Note: Current implementation does not support multicore, so 'maxcpus=1' must be set at boot.<br />
</nowiki></pre><br />
<br />
= System Calls and Scheduling =<br />
<br />
<pre><nowiki><br />
Some Scheduling System Calls<br />
/schedule.c<br />
SCHEDOP_yield<br />
SCHEDOP_block<br />
SCHEDOP_shutdown<br />
*nice( )<br />
getpriority( )<br />
setpriority( )<br />
sched_getscheduler( )<br />
sched_setscheduler( )<br />
sched_getparam( )<br />
sched_setparam( )<br />
sched_yield( )<br />
sched_get_ priority_min( )<br />
sched_get_ priority_max( )<br />
sched_rr_get_interval( )<br />
</nowiki></pre><br />
<br />
A related wiki topic on Real Time Applications & [[Preemption]] .<br />
<br />
== Also See ==<br />
* [[Credit Scheduler]]<br />
<br />
[[Category:Xen]]<br />
[[Category:Overview]]<br />
[[Category:Developers]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_Project_Schedulers&diff=4887Xen Project Schedulers2012-08-20T09:44:39Z<p>OliverChick: /* Xen Scheduling */ Removed information that is not relevant to scheduling.</p>
<hr />
<div><!-- MoinMoin name: Scheduling --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: Scheduling --><br />
<!-- Page revision: 00000017 --><br />
<!-- Original date: Sat Jun 9 18:29:49 2007 (1181413789000000) --><br />
<br />
{{TODO|This document gives an overview of Xen scheduling, but is likely out-of-date}}<br />
<br />
__NOTOC__<br />
= Xen Scheduling =<br />
This scheduling wiki page was originally compiled by [http://jacobmathai.blogspot.com Jacob Mathai]([http://www.dsm.fordham.edu/~mathai/ Jacob Mathai (Profile)]).<br />
<br />
Xen includes kernel boot time options for scheduling. Similiar to traditional Linux schedulers that divide CPU time for userland processes, Below you will find some Xen & DomU options for the schedulers.<br />
<br />
== 1. Borrowed Virtual Time (Xen 2.0/3.0) ==<br />
<br />
<pre><nowiki><br />
sched=bvt<br />
Global Parameters<br />
ctx_allow - The context switch allowance is similar to the ''quantum'' in traditional schedulers. <br />
It is the minimum time that a scheduled domain will be allowed to run before being preempted.<br />
<br />
Per-domain parameters<br />
mcuadv - the MCU (Minimum Charging Unit) advance determines the proportional share of the CPU<br />
that a domain receives. It is set inversely proportionally to a domain's sharing weight.<br />
warp - the amount of `virtual time' the domain is allowed to warp backwards<br />
warpl - the warp limit is the maximum time a domain can run warped for<br />
warpu - the unwarp requirement is the minimum time a domain must run unwarped for before it can warp again<br />
</nowiki></pre><br />
<br />
== 2. Atropos (Xen 2.0) ==<br />
<br />
<pre><nowiki><br />
sched=atropos<br />
Atropos is a soft real time scheduler. It provides guarantees about absolute shares of the CPU, <br />
with a facility for sharing slack CPU time on a best-effort basis. It can provide timeliness <br />
guarantees for latency-sensitive domains.<br />
<br />
Every domain has an associated period and slice. The domain should receive `slice' nanoseconds <br />
every `period' nanoseconds. This allows the administrator to configure both the absolute share <br />
of the CPU a domain receives and the frequency with which it is scheduled.<br />
<br />
Note: don't over-commit the CPU when using Atropos (i.e. don't reserve more CPU than is <br />
available -- the utilization should be kept to slightly less than 100% in order to ensure predictable <br />
behavior).<br />
<br />
Per-domain parameters :<br />
period - The regular time interval during which a domain is guaranteed to receive its allocation of CPU time.<br />
slice - The length of time per period that a domain is guaranteed to run for (in the absence of voluntary yielding of the CPU).<br />
latency - The latency hint is used to control how soon after waking up a domain it should be scheduled.<br />
xtratime - This is a boolean flag that specifies whether a domain should be allowed a share of the system slack time.<br />
</nowiki></pre><br />
<br />
== 3. Round Robin (Xen 2.0) ==<br />
<br />
<pre><nowiki><br />
sched=rrobin<br />
The round robin scheduler is included as a simple demonstration of Xen's internal scheduler <br />
API. It is not intended for production use.<br />
<br />
Global Parameters<br />
rr_slice - The maximum time each domain runs before the next scheduling decision is made.<br />
</nowiki></pre><br />
<br />
== 4. sEDF scheduler (Xen 3.0) ==<br />
<br />
<pre><nowiki><br />
sched=sedf<br />
(from docs/misc/sedf_scheduler_mini-HOWTO.txt)<br />
This scheduler provides weighted CPU sharing in an intuitive way and uses realtime-algorithms <br />
to ensure time guarantees.<br />
<br />
Per-domain parameters<br />
use "xm sched-sedf <dom-id> <period> <slice> <latency-hint> <extra> <weight>"<br />
-period/slice are the normal EDF scheduling parameters in nanosecs<br />
-latency-hint is the scaled period in case the domain is doing heavy I/O<br />
(unused by the currently compiled version)<br />
-extra is a flag (0/1), which controls whether the domain can run in extra-time<br />
-weight is mutually exclusive with period/slice and specifies another way of setting a domains cpu slice<br />
See wikipedia for a short intro to EDF:<br />
http://en.wikipedia.org/wiki/Earliest_deadline_first_scheduling<br />
</nowiki></pre><br />
<br />
== 5. ARINC 653 (Xen 4.0) ==<br />
<br />
<pre><nowiki><br />
sched=arinc653<br />
The arinc653 scheduler follows the ARINC 653 specification for scheduling, giving each partition (domain) a<br />
fixed, dedicated time slot for execution.<br />
<br />
Note: Current implementation does not support multicore, so 'maxcpus=1' must be set at boot.<br />
</nowiki></pre><br />
<br />
= System Calls and Scheduling =<br />
<br />
<pre><nowiki><br />
Some Scheduling System Calls<br />
/schedule.c<br />
SCHEDOP_yield<br />
SCHEDOP_block<br />
SCHEDOP_shutdown<br />
*nice( )<br />
getpriority( )<br />
setpriority( )<br />
sched_getscheduler( )<br />
sched_setscheduler( )<br />
sched_getparam( )<br />
sched_setparam( )<br />
sched_yield( )<br />
sched_get_ priority_min( )<br />
sched_get_ priority_max( )<br />
sched_rr_get_interval( )<br />
</nowiki></pre><br />
<br />
A related wiki topic on Real Time Applications & [[Preemption]] .<br />
<br />
== Also See ==<br />
* [[Credit Scheduler]]<br />
<br />
[[Category:Xen]]<br />
[[Category:Overview]]<br />
[[Category:Developers]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Category:Manual&diff=4886Category:Manual2012-08-20T09:35:13Z<p>OliverChick: /* Xen Books */ Removed broken links</p>
<hr />
<div>{{ManualNoCategory|Manuals and Documentation|<br />
This page lists books and manuals about Xen and derived projects.<br />
__TOC__}}<br />
<br />
== Xen ==<br />
This table lists the official Xen manuals. Most documentation for later versions is available in other formats.<br />
{| border="1" cellpadding="5" cellspacing="0" class="wikitable sortable"<br />
|-<br />
! scope="col" | Xen version<br />
! scope="col" class="unsortable" | PDF User manual<br />
! scope="col" class="unsortable" | PDF Developer manual<br />
! scope="col" class="unsortable" | Other<br />
|- valign="top"<br />
| 4.x<br />
| -<br />
| -<br />
| <br />
* [[Xen_4.x_Manuals|Man Pages, Release Notes, etc.]]<br />
* [[Xen_Networking|Xen Networking Overview]]<br />
* [[Host Configuration/Networking|Xen Networking Examples]]<br />
* [[Tuning|Tuning your Xen installation: recommended settings]]<br />
|-<br />
| 3.x<br />
| [[Media:Xen_3_user_manual.pdf|pdf]]<br />
| -<br />
|<br />
* [[Xen_3.x_Manuals|Man Pages, etc.]]<br />
|-<br />
| 2.x<br />
| [[Media:Xen_2_user_manual.pdf|pdf]]<br />
| [[Media:Xen_2_interface.pdf|pdf]]<br />
| -<br />
|}<br />
<br />
{{Anchor|XCP}}<br />
== XenServer / XCP ==<br />
This table lists Citrix XenServer manuals that also apply to XCP. There are some differences between XCP and XenServer, these are discussed on the errata pages.<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" class="wikitable sortable"<br />
|-<br />
! scope="col" | XCP version<br />
! scope="col" | XenServer version<br />
! scope="col" class="unsortable" | Errata<br />
|-<br />
| 1.5<br />
| [http://docs.vmd.citrix.com/XenServer/6.0.0/1.0/en_gb/ 6.0]<br />
| [[XCP_1.5_Manuals | yes]]<br />
|-<br />
| 1.1<br />
| [http://docs.vmd.citrix.com/XenServer/5.6.0sp2/1.0/en_gb/ 5.6 SP2]<br />
| [[XCP_1.1_Manuals | yes]]<br />
|-<br />
| 1.0<br />
| [http://docs.vmd.citrix.com/XenServer/5.6.0fp1/1.0/en_gb 5.6 FP1]<br />
| [[XCP_1.0_Manuals | yes]]<br />
|-<br />
| 0.5<br />
| [http://docs.vmd.citrix.com/XenServer/5.6.0/1.0/en_gb/ 5.6]<br />
| <br />
|}<br />
<br />
==Xen Books==<br />
This table lists available books.<br />
{| border="1" cellpadding="5" cellspacing="0" class="wikitable sortable"<br />
|-<br />
! scope="col" | Name<br />
! scope="col" | Author<br />
! scope="col" | Date<br />
! scope="col" | Format<br />
! scope="col" | Language<br />
|-<br />
| [http://www.virtuatopia.com/index.php/Xen_Virtualization_Essentials Xen Virtualization Essentials]<br />
| Neil Smyth <br />
| 2009-6-04<br />
| online<br />
| English<br />
|-<br />
| [http://safari.oreilly.com/9780132349710 The Definitive Guide to the Xen Hypervisor][http://www.informit.com/content/images/9780132349710/samplechapter/013234971X_06.pdf Chapter 6 Sample Text: Understanding Device Drivers]<br />
| David Chisnall<br />
| 2007-11-9<br />
| hardcover<br />
| English<br />
|-<br />
| [http://runningxen.com Running Xen: A Hands-on Guide to the Art of Virtualization][http://www.informit.com/articles/article.aspx?p=1187966 Chapter 3 Sample Text: The Xen Hypervisor] <br />
| Jeanna Neefe Matthews, Eli M. Dow, Todd Deshane, Wenjin Hu, Jeremy Bongio, Patrick F. Wilbur, and Brendan Johnson<br />
| 2008-5-5<br />
| paperback<br />
| English<br />
|-<br />
| [http://www.wrox.com/WileyCDA/WroxTitle/productCd-0470138114.html Professional XEN Virtualization]<br />
| William von Hagen<br />
| 2007-8-27<br />
| paperback<br />
| English<br />
|-<br />
| [http://buch.eisxen.org Xen 3]<br />
| Andrej Radonic and Frank Meyer<br />
| 2006-8<br />
| book<br />
| German<br />
|-<br />
| [http://www.xen-info.de/ Xen - Virtualisierung unter Linux (german)]<br />
| Timo Benk, Heninng Sprang, Jaroslaw Zdrzalek and Ralph Dehner<br />
| 2007-4<br />
| hardcover<br />
| German<br />
|-<br />
| [http://nostarch.com/xen.htm The Book of Xen][http://book.xen.prgmr.com/mediawiki/index.php/Chapter_1:_Xen:_A_High-Level_Overview Book of Xen Wiki Edition][http://www.nostarch.com/download/xen_ch7.pdf Chapter 7 Sample Text]<br />
| Chris Takemura and Luke S. Crawford<br />
| 2009-8<br />
| book<br />
| English<br />
|-<br />
| [http://www.amazon.cn/mn/detailApp?qid=1238548707&ref=SR&sr=13-21&uid=168-9160515-3593824&prodid=bkbk939920 System Virtualization: Theory & Implementation]<br />
| Intel R&D Team <br />
| ?<br />
| book<br />
| [[File:cn.png]] Chinese<br />
|-<br />
| [http://www.risec.aist.go.jp/project/knoppix/index-en.html Xenoppix] -- Knoppix customized with Xen<br />
| ?<br />
| ?<br />
| book<br />
| [[File:jp.png]] Japanese<br />
|-<br />
| [http://www.kohgakusha.co.jp/books/detail/4-7775-0073-X Chou Kanntan Xenoppix]<br />
| ?<br />
| ?<br />
| book<br />
| [[File:jp.png]] Japanese<br />
|}<br />
<br />
= Documents placed in this Category =</div>OliverChickhttps://wiki.xenproject.org/index.php?title=XCP_Introduction&diff=4885XCP Introduction2012-08-20T09:25:46Z<p>OliverChick: /* System components */ New info on v1.5</p>
<hr />
<div><!-- MoinMoin name: XCP_Introduction --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: XCP Introduction --><br />
<!-- Page revision: 00000006 --><br />
<!-- Original date: Sun Oct 16 14:30:31 2011 (1318775431000000) --><br />
__NOTOC__<br />
=Introduction=<br />
This introduction is a simple explanation for those unfamiliar with Xen, [[XenServer]], and Xen Cloud Platform (XCP).<br />
<br />
Xen itself is the underlying virtualization software. It's the hypervisor component that actually runs the virtual guest machines. It has been used by many projects and packaged in many ways. It can be installed and run on many *nix operating systems, for example as a Linux package installed with apt on Ubuntu. There's a very nice explanation with further details on the [http://en.wikipedia.org/wiki/Xen Xen Wikipedia page]. XCP is derived from the commercial Citrix [[XenServer]], which itself also includes Xen, but XCP is completely free and open source. XCP can be thought of as the open source release of XenServer.<br />
<br />
= System components =<br />
<br />
The current XCP v1.1 release was derived from [[XenServer]] 5.6 FP1. There is also a XCP v1.5 that is currently in beta testing, based on [[XenServer]] 6.0. It is hoped that XCP v1.6 will ship in September, or October 2012.<br />
<br />
XCP v1.1 is a packaged up version of Linux CentOS 5 (Linux kernel v2.6.32), combined together with Xen v3.4.2, and a web service API called XenAPI that provides a management API for the Xen components intended to be used by various [[XCP_Management_Tools|Management Tools]]. <br />
<br />
XCP v1.5 uses Xen v4.1.2, and CentOS v5.7 (Linux kernel v2.6.32). New features include GPU passthrough, for graphic-intesive VMs; improved performance; an Open vSwitch backend; and additional guest templates.<br />
<br />
XCP can be installed in two ways:<br />
* A bootable ISO allows you to quickly get a bare-metal machine running as a virtualization server (this is comparable to VMware ESXi).<br />
* The Debian and Ubuntu repos have XCP packages, allowing XCP setups that don't run on CentOS.<br />
<br />
= Installation =<br />
== Installable ISO ==<br />
# Download the ISO<br />
# Boot/install it on a fresh machine (likely using the whole available hard drive)<br />
# Configure the network from the very brief administrative interface that stays on the screen after installation<br />
# Manage the server over the network using [[Command Line Interface|CLI tools]], or a [[XenManagementTools|GUI management tool]]. <br />
# Now you can start installing and running [http://xen.org/download/xcp/index.html supported guest VMS] using [http://en.wikipedia.org/wiki/Xen#Types_of_virtualization paravirtualization or hardware virtualization]. <br />
## You can run hardware virtualization (HVM) guests only if your machine has the necessary hardware to support it. <br />
## Otherwise any CPU can run paravirtualization (PV) guests, it just means you're limited to the guest OSes and kernel versions that specifically support PV (e.g. Ubuntu 10.04 for example supports PV).<br />
<br />
There's a great article here that shows screen-shots all the way through the installation process: [http://www.dedoimedo.com/computers/xen-cloud.html http://www.dedoimedo.com/computers/xen-cloud.html]<br />
<br />
== From the Debian/Ubuntu Repos ==<br />
You can install xapi, the XenAPI management server, on a Debian or Ubuntu system.<br />
<br />
# Install Debian, or Ubuntu, using your preferred method<br />
# <pre>apt-get install xcp-xapi</pre><br />
<br />
See [[XAPI_on_Ubuntu|Installing Xapi on a Debian-based system]] for more information.<br />
<br />
= Management =<br />
After installation, many users choose to use [http://community.citrix.com/display/xs/XenCenter Citrix XenCenter] for management as it is a stable and mature tool. If you're not interested in a GUI, you can SSH to the XCP server itself, and run the built-in command line tools (xe and xl) as described on the [[XenManagementTools|Management Tools]] and [[Command Line Interface]] pages. You can also [[XCP_Install_CLI|install the management CLI on a separate Linux box]].<br />
<br />
If you have existing physical machines or VMs from other hypervisors, you can [[XCP Import Existing VM|import them into XCP]].<br />
<br />
= Documentation =<br />
<br />
Per the explanation on http://xen.org/products/xcp/community_and_support.html, the best documentation for XCP is the official Citrix [[XenServer]] docs for 5.6 FP1, available here: http://docs.vmd.citrix.com/XenServer/5.6.0fp1/1.0/en_gb/<br />
<br />
This is one reason documentation for "XCP" itself is hard to find; the team has not yet written official separate XCP docs as the [[XenServer]] docs are applicable to XCP. You can also find links to XCP documentation for a specific release in [[:Category:Manual]].<br />
<br />
This documentation is best combined with knowledge of the feature differences between XCP and [[XenServer]], as explained on the [[XCP/XenServer_Feature_Matrix|XCP/XenServer Feature Matrix comparison]] page.<br />
<br />
[[Category:XCP]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
[[Category:Overview]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_Serial_Console&diff=4541Xen Serial Console2012-07-30T16:08:43Z<p>OliverChick: /* I'm using IPMI SOL serial console (on a Blade), and pv_ops dom0 kernel seems to hang? */ Removed as patch has been upstream for over 2 years</p>
<hr />
<div><!-- MoinMoin name: XenSerialConsole --><br />
<!-- Comment: Added the details about Xen 4.2 being able to auto detect IO-ports of PCI/AMT cards --><br />
<!-- WikiMedia name: XenSerialConsole --><br />
<!-- Page revision: 00000043 --><br />
<!-- Original date: Wed Oct 26 18:45:25 2011 (1319654725000000) --><br />
<br />
__NOTOC__<br />
= Configuring Xen to use and log to a serial console =<br />
Serial console is a very good and important tool for debugging Xen and also Linux kernel problems. If your system doesn't start up, the display goes blank, the whole computer crashes during startup or during normal operation, serial console allows you to see and log everything that's happening to a text file and allows you to troubleshoot the issue much more easily. You can also paste the logged messages (as text) for online troubleshooting with other people.<br />
<br />
What actually is a serial console? Basicly you configure Xen and/or Linux kernel to write the boot and console messages to a serial port as text. Then you setup a cable (or nowadays IP connection) between the Xen server and for example a laptop. Then you configure the laptop to listen on the serial port, and log all the Xen and Linux dom0 console boot messages to a file giving you a full log of the boot process and system operation.<br />
<br />
You can also leave the serial console up and running allowing you to log any errors that might show up later.<br />
<br />
If your server is having problems and it crashes, you usually just see an empty VGA console when you go look at it. That doesn't help you at all troubleshooting the actual problem. Serial console to the rescue! Using a serial console you can log the full error and crash messages, and if you set up serial console logging to a file, you'll be able to easily check the logs later when you need them. Messages won't disappear from the serial console logs when the server powers off or reboots.<br />
<br />
== Components required for the serial console ==<br />
First of all you need two computers:<br />
<br />
1) The actual computer running Xen to debug/troubleshoot. It needs to have a serial port for the serial console. See below for types of supported serial ports. Remember USB-serial dongles are NOT usable for serial console on the computer running Xen.<br />
<br />
2) Another computer that views and logs the messages from the computer running Xen. This can be another server, a desktop machine, or a laptop. On this another computer you can use USB-serial adapters.<br />
<br />
== Types of serial ports on the computer running Xen ==<br />
There are four common types of serial ports for setting up a serial console for the computer running Xen:<br />
<br />
1) The computer running Xen has a built-in rs232 serial port (COM1) on the motherboard, with a DB9 serial cable connector. Most servers have real serial ports on the motherboard, and also older desktop computers and laptops have it. Most current (as of 2010) deskop and laptops don't include a serial port anymore.<br />
<br />
2) If your computer running Xen doesn't have a real physical serial port you can add a PCI add-on serial card with a DB9 serial connector. This is a good option for many computers.<br />
<br />
3) If you are using a laptop that doesn't have a physical serial port, you can get a [[ExpressCard]] serial card, for example "SYBA SD-EXP15005" (http://www.newegg.com/Product/Product.aspx?Item=[[N82E16839328018]]&Tpk=SDEXP15005), which works in the same way as PCI serial cards for desktop computers. Also some laptops offer a SOL (Serial Over LAN), usually when the laptop has Intel vPro (AMT) remote management feature built in.<br />
<br />
4) Virtual serial port, usually called SOL (Serial Over LAN). Many servers have a SOL serial port on the management processor, or on IPMI card. Basicly SOL looks like a real serial port to the operating system (Xen/Linux), but actually it can be accessed and used over the network using an IP connection, instead of the 'oldskool' method of using a serial cable between the computers. Some new desktop and laptop computers also have a SOL provided by the Intel vPro or AMT (Active Management Technology) management features.<br />
<br />
Note that for serial console you CAN'T use USB-serial dongles on the computer running Xen! (usb-serial dongles are not seen as real serial ports by the hardware or Xen, so usb-serial ports are NOT available in the beginning of boot process).<br />
<br />
== Connection between the computers ==<br />
You also need a connection between the computers:<br />
<br />
1) If you're using a physical serial port on the computer running Xen then you need to have a DB9-DB9 serial cable ("null-modem cable") between the two computers. For example serial cables that HP ships with their Procurve Ethernet Switches can be usually used between the computers for the serial console. The other computer needs to have a physical serial port aswell. If the other computer used for logging the serial console lacks a built-in serial port, you can get a PCI serial card for it, or you can get an USB serial adapter for it. USB serial adapter doesn't work for the computer running Xen (*), but it works for the other computer that is only used to view and log the serial console.<br />
<br />
(* unfortunately USB serial adapter is not a "real" serial port, it's not available at boot time so you cannot write boot-time messages to an USB serial adapter).<br />
<br />
2) If you're going to use a SOL virtual serial port then the other computer doesn't need a physical serial port, and there's no need for a serial cable between the two computers. Viewing and logging a SOL serial console only requires a network (IP) connection to the management processor of the server running Xen, and possibly a SOL viewer or terminal application on the other computer.<br />
<br />
== Getting required information to set up the serial console on the computer running Xen ==<br />
You need to know the following things to get the serial console set up in the computer running Xen:<br />
<br />
* IO port of the serial port<br />
* IRQ (interrupt request) of the serial port<br />
* Name of the serial device in Linux (ttyS*)<br />
You can get this information from the operating system. On Linux (dom0, if already running Xen) run "dmesg | grep ttyS". The output should be something like:<br />
<br />
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A<br />
<br />
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A<br />
<br />
The example output above shows the computer has two serial ports (COM1 and COM2), called ttyS0 and ttyS1 in Linux. IOport for the first serial port is 0x3f8 and the IRQ is 4, and IOport for the second serial port is 0x2f8 and the IRQ is 3. These are the default (legacy) IOports and IRQs reserved for serial ports on the motherboard.<br />
<br />
If you have a PCI serial card, or a SOL device, or an Intel AMT card, you might need to run "lspci -vvv" and find the serial port information from there.<br />
<br />
'''NOTE''': With Xen 4.2, you do _not_ have to find the serial information and Xen can find it automatically. You pass the extra argument ''pci'' in the ''com1'' line, as so: ''com1=38400,8n1,pci''. If you have an Intel AMT, then the extra argument is ''amt''.<br />
<br />
== Setting up the serial console in grub.conf ==<br />
=== Using Grub legacy: ===<br />
Here's an example grub1 grub.conf for configuring the serial console with Xen and pv_ops dom0 kernel (for example Debian 6.0 Squeeze uses pvops dom0 kernel):<br />
<br />
<pre><nowiki><br />
title Xen 4.0 / dom0 Linux 2.6.32.26 pvops with a serial console<br />
root (hd0,0)<br />
kernel /xen-4.0.gz dom0_mem=512M loglvl=all guest_loglvl=all com1=38400,8n1 console=com1<br />
module /vmlinuz-2.6.32.26 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset<br />
module /initrd-2.6.32.26.img</nowiki></pre><br />
<br />
In this example we're configuring Xen to use the serial console on onboard legacy serial port COM1, we set the serial console speed to 38400 bits per second, and settings to 8 databits, no parity and 1 stopbit. If you use the standard serial ports (COM1, COM2) you don't usually need to specify the IOport or the IRQ.<br />
<br />
Pv_ops dom0 Linux kernel is configured to use the Xen (hvc0) console. Dom0 Linux kernel console output will go to the serial console through Xen, so both Xen hypervisor and dom0 linux kernel output will go to the same serial console.<br />
<br />
Different dom0 Linux kernel versions might require a bit different settings.<br />
<br />
grub1 grub.conf example for RHEL5/CentOS5 Xen with Dell DRAC SOL (this example also displays GRUB on the serial console):<br />
<br />
<pre><nowiki><br />
serial --unit=0 --speed=57600<br />
terminal --timeout=10 console serial<br />
default=0<br />
timeout=5<br />
title Red Hat Enterprise Linux Server (2.6.18-92.el5xen)<br />
root (hd0,0)<br />
kernel /xen.gz-2.6.18-92.el5 console=tty0 console=com2 com2=57600,8n1<br />
module /vmlinuz-2.6.18-92.el5xen ro root=LABEL=/1 xencons=ttyS1 console=ttyS1<br />
module /initrd-2.6.18-92.el5xen.img</nowiki></pre><br />
<br />
On this system the Dell DRAC SOL serial port is seen as "COM2". It's a standard legacy serial port, so no IOport or IRQ configuration is necessary in grub.conf.<br />
<br />
=== Using Grub 2: ===<br />
If you run with Debian and Grub 2 (which should be the case if you are running Squeeze), then you should edit /etc/default/grub as below:<br />
<br />
<pre><nowiki>GRUB_CMDLINE_XEN="loglvl=all guest_loglvl=all com1=115200,8n1,0x3e8,5 console=com1,vga"<br />
GRUB_CMDLINE_LINUX="console=hvc0 earlyprintk=xen"</nowiki></pre><br />
<br />
The above setup of the serial device parameters are for a Supermicro X8STi-F motherboard, where IPMI SOL is configured for COM3 from the BIOS. Note that you need to use "com1=" option for Xen, even when the SOL is actually COM3. If you specify "com3=" for Xen the serial console won't work for some reason. When you are done with your grub config file, do:<br />
<br />
<pre><nowiki>update-grub2</nowiki></pre><br />
<br />
to generate the /boot/grub/grub.cfg<br />
<br />
== Viewing and logging the serial console on another computer using a serial cable ==<br />
Connect the serial cable between the computers, prepare the computer running Xen based on the grub.conf examples above, and then configure the other computer.The other computer needs to have the exact same serial port speed, databits, stopbit, parity and flow control settings than the computer running Xen!<br />
<br />
=== If you're using Windows on the other computer to view and log the serial console: ===<br />
First you need to know which COM port you've connected the serial cable to. Onboard serial ports are usually either COM1 or COM2. USB serial adapters might be what ever COM port, and often you're able to change the assigned USB serial adapter COM port from Windows Device Manager. So first use Windows Device Manager to figure out what serial ports you have and what you're using.<br />
<br />
Then you need a terminal emulator program to access the serial port. Windows includes Hyperterminal, but that's not a very good program. You can also use Putty, or Teraterm. There are many other programs for accessing serial ports. Usually any program that can be used for calling with a modem, or to configure an ethernet switch also works for accessing a serial console. Start the terminal emulator program, and configure the correct serial (COM) port, correct speed, correct settings (8n1), and flow control.<br />
<br />
=== If you're using Linux on the other computer to view and log the serial console: ===<br />
In linux you can get a list of the serial ports by running "dmesg | grep ttyS". USB serial adapters are usually named "ttyUSB*", so you can check for them with "dmesg | grep ttyUSB".<br />
<br />
You can use for example "minicom", "kermit" or many other tools to view the serial console. You can start minicom with "minicom -s" to enter the setup mode to configure the serial settings. Another option is to press "Ctrl-A p" when minicom is running to enter the settings dialog. After configuring the settings remember to save them, and then restart minicom. "Ctrl-A x" can be used to quit minicom. Read the minicom man-page for more information about the usage.<br />
<br />
You can also use simple "screen" command to view the serial console: "screen /dev/ttyUSB0 115200".<br />
<br />
=== If you're using SOL and ipmitool: ===<br />
<br />
Before connecting, make sure nobody else is using the serial console (only one person at a time can connect). You can disconnect a currently connected session using:<br />
<br />
<pre><nowiki>ipmitool -I lanplus -H server-ip-address -U ADMIN sol deactivate</nowiki></pre><br />
<br />
Then connect using:<br />
<br />
<pre><nowiki>ipmitool -I lanplus -H server-ip-address -U ADMIN sol activate</nowiki></pre><br />
<br />
If you want to log the output, simply using the "tee" utility is fine:<br />
<br />
<pre><nowiki>ipmitool -I lanplus -H server-ip-address -U ADMIN sol activate | tee my-log-file.txt</nowiki></pre><br />
<br />
== Starting up the computer running Xen and viewing the serial console ==<br />
When you have connected the computers with a serial cable, you have prepared grub.conf on the computer running Xen, and configured the terminal emulator on the another computer making sure you have matching speed and settings on both computers, feel free to power on the computer running Xen and select the Xen with a serial console boot entry from grub. Now you should first see Xen boot messages on the serial console followed by dom0 Linux kernel boot messages.<br />
<br />
== How does the serial console log look like? ==<br />
Take a look at this example: http://pasik.reaktio.net/xenserialconsolelog.txt<br />
<br />
== Connecting to SOL virtual serial port over the network ==<br />
Some servers allow you to telnet or ssh into the management processor (HP iLO, DELL DRAC), and view the SOL serial console from there.<br />
<br />
Some Intel vPro or AMT SOL implementations require you to use a special 'SOL remote console utility' to view the serial console. There's for example "amtterm" for Linux. Check the documentation of your server/computer for more information.<br />
<br />
== Configuring serial console for non-standard PCI serial ports (for example Intel AMT) ==<br />
If your serial port is on a non-standard IOport, for example 0xe000, you can use a grub1 grub.conf configuration like this:<br />
<br />
<br />
<pre><nowiki><br />
title Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console<br />
root (hd0,0)<br />
kernel /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0xe000,0 console=com1<br />
module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset<br />
module /initrd-2.6.31.6.img</nowiki></pre><br />
<br />
Important part being this:<br />
<br />
<br />
<pre><nowiki><br />
com1=115200,8n1,0xe000,0</nowiki></pre><br />
<br />
"0xe000" is the IOport of the serial port. Last ",0" means what IRQ to use.. some setups requires 0 there instead of the real IRQ. If you have problems, try using either the real IRQ, or then just 0.<br />
<br />
'''NOTE''': With Xen 4.2, you do _not_ have to find the serial information and Xen can find it automatically. You pass the extra argument ''pci'' in the ''com1'' line, as so: ''com1=115200,8n1,pci''. If you have an Intel AMT, then the extra argument is ''amt''.<br />
<br />
== No getty (login prompt) on the serial console so I can't login? ==<br />
You need to configure a getty in /etc/inittab to listen on the console device, or on the serial port. This will enable you to login to Xen dom0 from the serial console.<br />
<br />
Example /etc/inittab line to run getty on RHEL5/CentOS5 for COM2 (ttyS1) at speed 57600 bits per second:<br />
<br />
<br />
<pre><nowiki><br />
s1:2345:respawn:/sbin/agetty ttyS1 57600<br />
</nowiki></pre><br />
<br />
<br />
Example /etc/inittab line to run agetty on Debian 6.0 using Xen 4.1.1 for hvc0 at speed 38400 bits per second:<br />
<br />
<br />
<pre><nowiki><br />
s1:2345:respawn:/sbin/agetty 38400 hvc0<br />
</nowiki></pre><br />
<br />
== Can I get GRUB to show up on the serial console? ==<br />
Yes, that's possible. Some servers allows you to configure "BIOS redirection", which makes the full boot process starting from BIOS messages to show up on a serial console, including GRUB. If your BIOS doesn't support this, there's also another option. Example grub1 grub.conf:<br />
<br />
<br />
<pre><nowiki><br />
# Show grub on the Intel AMT serial-over-lan console<br />
serial --port=0x3440 --speed=115200<br />
terminal --timeout=10 console serial<br />
default=0<br />
timeout=10<br />
title Xen 3.4.2 / pv_ops Linux dom0 2.6.31.6 with a serial console<br />
root (hd0,0)<br />
kernel /xen-3.4.gz dom0_mem=512M loglvl=all guest_loglvl=all sync_console console_to_ring com1=115200,8n1,0x3440,0 console=com1<br />
module /vmlinuz-2.6.31.6 ro root=/dev/vg00/lv01 console=hvc0 earlyprintk=xen nomodeset<br />
module /initrd-2.6.31.6.img</nowiki></pre><br />
<br />
== Xen com1= option for non-standard serial ports (IPMI SOL, Intel AMT, PCI serial) == <br />
<br />
Note that even if your SOL device is, for example, COM3, you still need to specify "com1=<foo> console=com1" options for Xen. If you specify "com3=" the serial console won't work! Remember to list the correct (actual) serial port IOport and IRQ in the Xen "com1=" parameters! <br />
<br />
<br />
== It doesn't work, how to troubleshoot? ==<br />
* Are you using correct type of serial cable between the computers? You need a "null-modem" serial cable. For example serial cables shipped with HP Ethernet Switches usually work for serial consoles.<br />
* Do you have matching serial speed/parity/databit/stopbit settings on both computers? You need to make sure the settings match.<br />
* Try using different flow control settings.<br />
* If possible, you can run for example "minicom" or "putty" on both computers, and test the serial cable and connection first like that. You should be able to chat over the serial connection, see the text you write on the other computer.<br />
* Did you specify the optional IRQ on the Xen comX= line? Try specifying the correct IRQ. If that doesn't work, then try specifying 0 as the IRQ. Some setups require 0 as IRQ to make it work. Some setups don't require any IOport or IRQ settings on the comX= line.<br />
== I can't use a serial console, are there other methods to capture the boot time messages? ==<br />
Well.. you could always record a video of the boot process from the console display, using a phone or a real video camera.<br />
<br />
== Links for more information ==<br />
AMT-HOWTO: http://manpages.ubuntu.com/manpages/jaunty/man7/amt-howto.7.html<br />
<br />
DELL DRAC SOL configuration with RHEL5+Xen: http://blog.coolzero.info/blogs/index.php/2008/06/04/drac-5-rhel-5-2-centos-xen-based-and-ser?blog=5<br />
<br />
Using Intel AMT Serial-Over-LAN: http://software.intel.com/en-us/articles/using-intel-amt-serial-over-lan-to-the-fullest/<br />
<br />
HP iLO Integrated Lights-Out Virtual Serial Port configuration and operation HOWTO, 4th edition: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00263709/c00263709.pdf<br />
<br />
Linux serial console HOWTO: http://www.vanemery.com/Linux/Serial/serial-console.html<br />
<br />
Enabling serial console in [[OpenSolaris]] with Xen: http://hub.opensolaris.org/bin/view/Community+Group+xen/serial-console<br />
<br />
OpenSUSE How to Capture Xen Hypervisor and Kernel Messages using a Serial Cable:<br />
<br />
* http://en.opensuse.org/How_to_Capture_Xen_Hypervisor_and_Kernel_Messages_using_a_Serial_Cable<br />
Novell Configuring a Remote Serial Console for SLES: http://www.novell.com/support/viewContent.do?externalId=3456486&sliceId=1<br />
<br />
Ubuntu Serial Console howto: https://help.ubuntu.com/community/SerialConsoleHowto<br />
<br />
Ubuntu IPMI SOL usage: https://help.ubuntu.com/community/IPMI<br />
<br />
[[Category:Xen]]<br />
[[Category:HowTo]]<br />
[[Category:Users]]<br />
[[Category:Developers]]<br />
[[Category:Beginners]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Mainline_Linux_Kernel_Configs&diff=4538Mainline Linux Kernel Configs2012-07-30T15:41:01Z<p>OliverChick: /* Getting the current stable version */ Removed old link</p>
<hr />
<div>== Getting the current stable version ==<br />
<span id="stable_version"></span><br />
With [http://blog.xen.org/index.php/2011/06/14/linux-3-0-how-did-we-get-initial-domain-dom0-support-there/ v3.0 - how did dom0 support get there] has technical details, but the summary is that the 3.0 is "With Linux 3.0 we now have the major components to be classified as a working initial domain aka dom0.". There are bugs, which are documented in [http://wiki.xensource.com/xenwiki/Linux_30_bugs Linux 3.0 and further bugs]<br />
<br />
Download it: [ftp://ftp.kernel.org/pub/linux/kernel/v3.0/linux-3.0.8.tar.bz2] from [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary Linus Torvalds tree]: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git<br />
<br />
== Getting the current development version ==<br />
<span id="dev_version"></span><br />
<br />
The current day-to-day development is happening in a [http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=summary Konrad's git tree]<br />
<br />
The repository has numerous topic branches to track individual lines of development, and a couple of roll-up branches which contain everything merged together for easy compilation and running.<br />
<br />
'''NOTE! All active git branches require at least Xen 4.0.1, using older version (4.0.0 or older) will cause problems, xend not starting, etc.'''<br />
<br />
Current active branches are:<br />
<br />
* linux-next - patches that are queued up<br />
to go to Linus Torvalad's tree. This includes bug-fixes, new features, etc.<br />
* testing (in Konrad's repository) is off patches being run/developed and obviously going through testing - which means they might not compile or work properly.<br />
<br />
== Downloading the git tree ==<br />
<br />
<pre><nowiki><br />
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git linux<br />
$ cd linux<br />
</nowiki></pre><br />
<br />
<br />
that will automatically check out the 'origin/master' default branch. Note that you need at least 256 MB of free memory, otherwise the "git clone" will fail.<br />
<br />
Changing the branch: You most probably want to use the "linux-next" (or "upstream/xen") branch, so do this:<br />
<br />
<br />
<pre><nowiki><br />
$ cd /usr/src<br />
$ cd linux<br />
$ git reset --hard<br />
$ git checkout -b upstream/xen origin/upstream/xen<br />
Branch upstream/xen set up to track remote branch refs/remotes/origin/upstream/xen<br />
Switched to a new branch "upstream/xen"<br />
$ git pull<br />
$ git log | less<br />
</nowiki></pre><br />
<br />
<br />
(or replace "origin/upstream/xen" with "testing" for example)<br />
<br />
Later when you want to update the tree use:<br />
<br />
<br />
<pre><nowiki><br />
$ cd linux<br />
$ make clean<br />
$ git pull<br />
</nowiki></pre><br />
<br />
<br />
== Configuring the kernel ==<br />
<span id="configure_xen"></span><br />
<br />
Configure as normal; you can start with your current .config file or use '''make defconfig'''<br />
and then depending on what you want your kernel to do (it can do both):<br />
<br />
<br />
<pre><nowiki><br />
make menuconfig<br />
</nowiki></pre><br />
<br />
NOTE0: Make sure you have correct CPU type (Processor Family) set in the kernel configuration, Xen Dom0 options won't show up at all if you have too old CPU selected (too old means a CPU that doesn't support PAE; Pentium Pro was the first CPU to have PAE).<br />
<br />
NOTE1: If you're building 32 bit version of the kernel, you first need to enable PAE support, since Xen only supports 32 bit PAE kernels nowadays. Xen kernel build options won't show up at all before you've enabled PAE for 32 bit builds (Processor type and features -> High Memory Support (64GB) -> PAE (Physical Address Extension) Support). PAE is not needed for 64 bit kernels.<br />
<br />
=== Configure kernel for domU support ===<br />
<br />
# If building 32 bit kernel make sure you have CONFIG_X86_PAE enabled (which is set by selecting CONFIG_HIGHMEM64G)<br />
#* non-PAE mode doesn't work in 2.6.25, and has been dropped altogether from 2.6.26 and newer kernel versions.<br />
# Enable these core options (Processor type and features| Paravirtualized guest support]<br />
#* CONFIG_PARAVIRT=y<br />
#* CONFIG_XEN=y<br />
#* CONFIG_PARAVIRT_GUEST=y <br />
#* CONFIG_PARAVIRT_SPINLOCKS=y<br />
# And Xen pv console device support (Device Drivers|Character devices<br />
#* CONFIG_HVC_DRIVER=y<br />
#* CONFIG_HVC_XEN=y<br />
# And Xen disk and network support (Device Drivers|Block devices and Device Drivers|Network device support)<br />
#* CONFIG_XEN_FBDEV_FRONTEND=y<br />
#* CONFIG_XEN_BLKDEV_FRONTEND=y<br />
#* CONFIG_XEN_NETDEV_FRONTEND=y<br />
# And the rest (Device Drivers|Xen driver support)<br />
#* CONFIG_XEN_PCIDEV_FRONTEND=y<br />
#* CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y<br />
#* CONFIG_XEN_FBDEV_FRONTEND=y<br />
#* CONFIG_XEN_XENBUS_FRONTEND=y<br />
#* CONFIG_XEN_SAVE_RESTORE=y<br />
#* CONFIG_XEN_GRANT_DEV_ALLOC=m<br />
# And for tmem support:<br />
#* CONFIG_XEN_TMEM=y<br />
#* CONFIG_CLEANCACHE=y<br />
#* CONFIG_FRONTSWAP=y<br />
#* CONFIG_XEN_SELFBALLOONING=y<br />
<br />
=== Configure kernel for dom0 support ===<br />
<br />
NOTE: Xen dom0 support depends on ACPI support. Make sure you enable ACPI support or you won't see Dom0 options at all.<br />
<br />
In addition to the config options above you also need to enable:<br />
<br />
* CONFIG_X86_IO_APIC=y<br />
* CONFIG_ACPI=y<br />
* CONFIG_ACPI_PROCFS=y (optional)<br />
* CONFIG_XEN_DOM0=y<br />
* CONFIG_PCI_XEN=y<br />
* CONFIG_XEN_DEV_EVTCHN=y<br />
* CONFIG_XENFS=y<br />
* CONFIG_XEN_COMPAT_XENFS=y<br />
* CONFIG_XEN_SYS_HYPERVISOR=y<br />
* CONFIG_XEN_GNTDEV=y<br />
* CONFIG_XEN_BACKEND=y<br />
* CONFIG_XEN_NETDEV_BACKEND=m<br />
* CONFIG_XEN_BLKDEV_BACKEND=m<br />
* CONFIG_XEN_PCIDEV_BACKEND=m<br />
* CONFIG_XEN_PRIVILEGED_GUEST=y<br />
* CONFIG_XEN_BALLOON=y<br />
* CONFIG_XEN_SCRUB_PAGES=y<br />
<br />
<br />
If you're using RHEL5 or CentOS5 as a dom0 (ie. you have old udev version), make sure you enable the following options as well:<br />
<br />
* CONFIG_SYSFS_DEPRECATED=y<br />
* CONFIG_SYSFS_DEPRECATED_V2=y<br />
<br />
For more current Xen related config options check the example .config files from the troubleshooting section, and check the [[2.6.18-to-2.6.31-and-higher]] wiki page.<br />
<br />
== Building the kernel ==<br />
<span id="build_kernel"></span><br />
<br />
There are two parts when building Xen: [[#build_xen|Xen]] and the Kernel. After Kernel configuration you have to do two things, build the kernel and build the ramdrive.<br />
<br />
This is the Ubuntu way:<br />
<br />
<pre><nowiki><br />
$ cd /usr/src/linux<br />
$ sudo make<br />
$ sudo apt-get install kernel-package fakeroot<br />
$ export CONCURRENCY_LEVEL=<number_of_cores +1><br />
$ sudo make-kpkg clean<br />
$ sudo fakeroot make-kpkg --initrd --append-to-version=-pv kernel-image kernel-headers<br />
$ sudo dpkg -i ../<linux-image-3.0.XXX.deb><br />
</nowiki></pre><br />
<br />
The first line will make the kernel with the hidden configuration file (your file hopefully). You might have to do this several times because you will encounter errors that will requiere turning modules off, and start compiling again. It is a good plactice to use make clean when you change many modules at a time. The next line is used for dpkg but is not really that important. the sudo fakeroot line will create your ramdrive needed to boot. This is the debian way of making the image usable this will event copy it to boot but will not update grub.<br />
<br />
The old-skool way:<br />
<br />
<pre><nowiki><br />
cd linux<br />
make clean<br />
cp -a .config .config-old<br />
make oldconfig<br />
make menuconfig (if you need to change something)<br />
make bzImage<br />
make modules<br />
make modules_install<br />
# in the following lines replace "version" with the actual kernel version you're compiling.<br />
make install<br />
# And then generate initrd/initramfs image for your dom0 kernel, example for Fedora/RHEL/CentOS:<br />
mkinitrd -f /boot/initrd-version.img version<br />
# For Fedora Core the 'make install' does it automatically<br />
</nowiki></pre><br />
<br />
<br />
=== Update modules ===<br />
<span id="configure_modules"></span><br />
<br />
You need to update some new modules that your newly created kernel requires with XEN.<br />
Please note that often a monholitic kernel is a wise choice as it doesn't necessarilly requires initrd.<br />
<br />
<br />
<pre><nowiki><br />
$ sudo vim /etc/modules<br />
# /etc/modules: kernel modules to load at boot time.<br />
#<br />
# This file contains the names of kernel modules that should be loaded<br />
# at boot time, one per line. Lines beginning with "#" are ignored.<br />
lp<br />
rtc<br />
# Added these lines<br />
xen-evtchn<br />
xen-gntdev<br />
xen-netback<br />
xen-blkback<br />
xenfs<br />
blktap<br />
</nowiki></pre><br />
<br />
Again this is the Ubuntu way, find a way for your particular distribution to do the same.<br />
<br />
[[Category:Developers]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_FAQ_Networking&diff=4531Xen FAQ Networking2012-07-30T15:04:53Z<p>OliverChick: /* When designing such setups, with bridge networking, I often find it easier to think of dom0 as a switch or router, and domU like any other physical server on your network. */</p>
<hr />
<div><!-- MoinMoin name: XenFaq --><br />
<!-- Comment: Added link to XenFAQ2 --><br />
<!-- WikiMedia name: XenFaq --><br />
<!-- Page revision: 00000096 --><br />
<!-- Original date: Wed Sep 14 11:36:18 2011 (1316000178000000) --><br />
<br />
<!-- #pragma section-numbers on --><br />
<!-- ! TOC here --><br />
<br />
{{Needs_Review|This page is very out-of-date. Many of the issues described on this page have been resolved.}}<br />
<br />
= Networking Issues =<br />
== What is vif or xenbr0? ==<br />
You should read [[XenNetworking]] http://wiki.xen.org/wiki/XenNetworking<br />
<br />
== Why can't I ssh into or ping a newly created domain? ==<br />
In the default configuration we rely on the Linux bridge-utils in domain 0 to set up virtual networking. After you've created a new domain (e.g., domain 1) you should be able to run <code><nowiki>ifconfig</nowiki></code> in domain 0 and see an interface with a name like vif1.0; you should also be able to check that bridging is working by typing <code><nowiki>brctl show xen-br0</nowiki></code>. Finally, you can check the IP confiuration in the new domain by logging into it via the console (<code><nowiki>xm console</nowiki></code>) and running standard tools such as <code><nowiki>ifconfig</nowiki></code> and <code><nowiki>route</nowiki></code>.<br />
<br />
== Xen and Shorewall ==<br />
There is a document about configuring Shorewall in Dom0 at http://www.shorewall.net/Xen.html<br />
<br />
http://www1.shorewall.net/XenMyWay.html can be useful also.<br />
<br />
= Bridging =<br />
<br />
== Which Mechanism is used by Xen bridging to handle packets coming from various VMs to forward them to their destination ==<br />
<br />
Nothing. Xen by itself does not handle bridge. dom0 OS does that. On Linux dom0 : http://www.linuxfoundation.org/en/Net:Bridge<br />
On opensolaris dom0: http://opensolaris.org/os/project/crossbow/<br />
<br />
= IP Determination =<br />
<br />
== I want to know the IP of a running VM in XEN. Is there any way to have this without login to that VM?==<br />
<br />
Yes. First, you need to find the MAC address of the domU. This can be done by running:<br />
<pre><br />
xl network-list <domU name><br />
</pre><br />
<br />
which should produce an output similar to:<br />
<br />
<pre><br />
Idx BE MAC Addr. handle state evt-ch tx-/rx-ring-ref BE-path 0 0 00:16:3E:F7:D6:E7 0 4<br />
6 16238/16237 /local/domain/0/backend/vif/163/0<br />
</pre><br />
<br />
The domU's MAC address is 00:16:3E:F7:D6:E7<br />
<br />
You now need to snoop the bridge for domU's MAC. For example:<br />
<br />
<pre><nowiki><br />
# tcpdump -n -i eth0 ether src 00:16:3e:f7:d6:e7 tcpdump: verbose output suppressed, use<br />
-v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes<br />
15:54:56.419482 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 1, length 64 15:54:57.422349<br />
IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 2, length 64<br />
</nowiki></pre><br />
<br />
<br />
Then you know that domU has IP address 10.0.0.10.<br />
<br />
= NAT =<br />
<br />
== I managed to configure NAT on dom0 but this does not work properly. Outgoing traffic from domU is seen with the original domU ip address instead of the dom0 ip address and the requests can't get back to the domU. ==<br />
<br />
I figured out MASQUERADING was not set.<br />
<br />
The following rule needs to be set:<br />
<br />
<br />
<pre><nowiki><br />
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE<br />
</nowiki></pre><br />
<br />
<br />
= SSL/VPN =<br />
<br />
== Why can't I use openvpn with a xen guest? I can't load the tun module ==<br />
<br />
From openvpn perspective, the requirements for openvpn on xen domU is the same as openvpn on native Linux. If you can't load the tun module, then you need to get a kernel that supports it.<br />
<br />
The easiest way is to use a distro that supports it. For example, I'm using RHEL/Centos 5.3 domU, loaded with pygrub, and they can run openvpn just fine.<br />
<br />
Another alternative is compile your own kernel with tun/tap support.<br />
<br />
== Can I share one storage mount between multiple guests? ==<br />
<br />
This is possible, however it can lead to corruption if the filesystem doesn't support a cluster file system. If you want to share it anyway, you can try changing the mode to "r" (for read only) or "w!" (to force read-write multiple mount). In your domU.cfg:<br />
<br />
<pre><nowiki> <br />
'phy:/dev/data/bla-disk,sda1,w' => 'phy:/dev/data/bla-disk,sda1,r'<br />
</nowiki></pre><br />
<br />
== I'm looking for a way to monitor network activities of processes in Guest OS. I want to get a list of Guest OS processes that open TCP connections to other machines (like "lsof" command).==<br />
<br />
If you're thinking about doing on from dom0, that's not possible. You need something that runs on domU for that, possibly by using snmpd and extending it to run "netstat -anp --tcp". Other host (including dom0) can then collect the information using snmp.<br />
<br />
Also, have a look at Versiera, it provides what you are looking for including, user IDs, inbound/outbound communications, IPv4, IPV6, etc. There are many more capabilities. Versiera is not open-source, but the Internet self-manage service<br />
is free.<br />
<br />
== How do I view the resources used by guest VMs? ==<br />
<br />
All of DomU's I/O passes through Dom0. Therefore, you can measure resources used by VMs here.<br />
<br />
* For disk I/O:<br />
** phy: devices, can be measured by running iostat to see the usage of each device.<br />
** File-based backends, are most-easily checked using the userspace daemons. Maybe iotop would help. In any case, if aggregate usage is all you need, just measure the disk usage seen at Dom0.<br />
* For network:<br />
** Aggregate usage of peth0 can be found by running `ifconfig' on dom0.<br />
** If you need stats for each DomU, check the respective tun devices by running `ifconfig' in dom0.<br />
<br />
==Which parts of my network infrastructure should I run in dom0, and which should I run in domU? ==<br />
<br />
Network infrastructure, such as DHCP, DNS and OpenVPN servers, should all run in domUs. Installing such services in dom0 is dangerous, as if the services are compromised, an attacker could access other running VMs.<br />
<br />
As a general rule, a domU should be used to perform a small, independent task. Therefore if the OS crashes, or is compromised, the effect is constrained to a small part of your setup. This makes it easier to find the problem, and then fix.<br />
<br />
== How do I configure Xen guests to work with my VLANs? ==<br />
<br />
Have a trunk port in your dom0 and create bridges for each VLAN for Xen. If you have the VLAN trunk set up, you can create bridges as follows. For this example, my trunk interface is on eth0 and the vlan I am adding is 2.<br />
<br />
<pre><nowiki><br />
# vconfig add eth0 2 # brctl addbr xenbr2 # brctl addif xenbr2 eth0.2 # ifconfig eth0.2 up # ifconfig xenbr2 up<br />
</nowiki></pre><br />
<br />
Now add the following to your domU configuration file:<br />
<br />
<pre><nowiki><br />
vif=['bridge=xenbr2']<br />
</nowiki></pre><br />
<br />
And the domU will be on VLAN 2. To access the trunk port directly inside the guest, pass through the network card to get VLAN access. You can also script this and give it a space separated list of VLANs and loop it through. <br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
[[Category:Networking]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=Xen_FAQ_Networking&diff=4530Xen FAQ Networking2012-07-30T15:04:11Z<p>OliverChick: /* I can't use more than 3 network interfaces in domU */ Removed. Limitation doesn't exist in 4.*</p>
<hr />
<div><!-- MoinMoin name: XenFaq --><br />
<!-- Comment: Added link to XenFAQ2 --><br />
<!-- WikiMedia name: XenFaq --><br />
<!-- Page revision: 00000096 --><br />
<!-- Original date: Wed Sep 14 11:36:18 2011 (1316000178000000) --><br />
<br />
<!-- #pragma section-numbers on --><br />
<!-- ! TOC here --><br />
<br />
{{Needs_Review|This page is very out-of-date. Many of the issues described on this page have been resolved.}}<br />
<br />
= Networking Issues =<br />
== What is vif or xenbr0? ==<br />
You should read [[XenNetworking]] http://wiki.xen.org/wiki/XenNetworking<br />
<br />
== Why can't I ssh into or ping a newly created domain? ==<br />
In the default configuration we rely on the Linux bridge-utils in domain 0 to set up virtual networking. After you've created a new domain (e.g., domain 1) you should be able to run <code><nowiki>ifconfig</nowiki></code> in domain 0 and see an interface with a name like vif1.0; you should also be able to check that bridging is working by typing <code><nowiki>brctl show xen-br0</nowiki></code>. Finally, you can check the IP confiuration in the new domain by logging into it via the console (<code><nowiki>xm console</nowiki></code>) and running standard tools such as <code><nowiki>ifconfig</nowiki></code> and <code><nowiki>route</nowiki></code>.<br />
<br />
== Xen and Shorewall ==<br />
There is a document about configuring Shorewall in Dom0 at http://www.shorewall.net/Xen.html<br />
<br />
http://www1.shorewall.net/XenMyWay.html can be useful also.<br />
<br />
= Bridging =<br />
<br />
== Which Mechanism is used by Xen bridging to handle packets coming from various VMs to forward them to their destination ==<br />
<br />
Nothing. Xen by itself does not handle bridge. dom0 OS does that. On Linux dom0 : http://www.linuxfoundation.org/en/Net:Bridge<br />
On opensolaris dom0: http://opensolaris.org/os/project/crossbow/<br />
<br />
= IP Determination =<br />
<br />
== I want to know the IP of a running VM in XEN. Is there any way to have this without login to that VM?==<br />
<br />
Yes. First, you need to find the MAC address of the domU. This can be done by running:<br />
<pre><br />
xl network-list <domU name><br />
</pre><br />
<br />
which should produce an output similar to:<br />
<br />
<pre><br />
Idx BE MAC Addr. handle state evt-ch tx-/rx-ring-ref BE-path 0 0 00:16:3E:F7:D6:E7 0 4<br />
6 16238/16237 /local/domain/0/backend/vif/163/0<br />
</pre><br />
<br />
The domU's MAC address is 00:16:3E:F7:D6:E7<br />
<br />
You now need to snoop the bridge for domU's MAC. For example:<br />
<br />
<pre><nowiki><br />
# tcpdump -n -i eth0 ether src 00:16:3e:f7:d6:e7 tcpdump: verbose output suppressed, use<br />
-v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes<br />
15:54:56.419482 IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 1, length 64 15:54:57.422349<br />
IP 10.0.0.10 > 10.0.0.1: ICMP echo reply, id 5443, seq 2, length 64<br />
</nowiki></pre><br />
<br />
<br />
Then you know that domU has IP address 10.0.0.10.<br />
<br />
= NAT =<br />
<br />
== I managed to configure NAT on dom0 but this does not work properly. Outgoing traffic from domU is seen with the original domU ip address instead of the dom0 ip address and the requests can't get back to the domU. ==<br />
<br />
I figured out MASQUERADING was not set.<br />
<br />
The following rule needs to be set:<br />
<br />
<br />
<pre><nowiki><br />
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE<br />
</nowiki></pre><br />
<br />
<br />
= SSL/VPN =<br />
<br />
== Why can't I use openvpn with a xen guest? I can't load the tun module ==<br />
<br />
From openvpn perspective, the requirements for openvpn on xen domU is the same as openvpn on native Linux. If you can't load the tun module, then you need to get a kernel that supports it.<br />
<br />
The easiest way is to use a distro that supports it. For example, I'm using RHEL/Centos 5.3 domU, loaded with pygrub, and they can run openvpn just fine.<br />
<br />
Another alternative is compile your own kernel with tun/tap support.<br />
<br />
== Can I share one storage mount between multiple guests? ==<br />
<br />
This is possible, however it can lead to corruption if the filesystem doesn't support a cluster file system. If you want to share it anyway, you can try changing the mode to "r" (for read only) or "w!" (to force read-write multiple mount). In your domU.cfg:<br />
<br />
<pre><nowiki> <br />
'phy:/dev/data/bla-disk,sda1,w' => 'phy:/dev/data/bla-disk,sda1,r'<br />
</nowiki></pre><br />
<br />
== I'm looking for a way to monitor network activities of processes in Guest OS. I want to get a list of Guest OS processes that open TCP connections to other machines (like "lsof" command).==<br />
<br />
If you're thinking about doing on from dom0, that's not possible. You need something that runs on domU for that, possibly by using snmpd and extending it to run "netstat -anp --tcp". Other host (including dom0) can then collect the information using snmp.<br />
<br />
Also, have a look at Versiera, it provides what you are looking for including, user IDs, inbound/outbound communications, IPv4, IPV6, etc. There are many more capabilities. Versiera is not open-source, but the Internet self-manage service<br />
is free.<br />
<br />
== How do I view the resources used by guest VMs? ==<br />
<br />
All of DomU's I/O passes through Dom0. Therefore, you can measure resources used by VMs here.<br />
<br />
* For disk I/O:<br />
** phy: devices, can be measured by running iostat to see the usage of each device.<br />
** File-based backends, are most-easily checked using the userspace daemons. Maybe iotop would help. In any case, if aggregate usage is all you need, just measure the disk usage seen at Dom0.<br />
* For network:<br />
** Aggregate usage of peth0 can be found by running `ifconfig' on dom0.<br />
** If you need stats for each DomU, check the respective tun devices by running `ifconfig' in dom0.<br />
<br />
==Which parts of my network infrastructure should I run in dom0, and which should I run in domU? ==<br />
<br />
Network infrastructure, such as DHCP, DNS and OpenVPN servers, should all run in domUs. Installing such services in dom0 is dangerous, as if the services are compromised, an attacker could access other running VMs.<br />
<br />
As a general rule, a domU should be used to perform a small, independent task. Therefore if the OS crashes, or is compromised, the effect is constrained to a small part of your setup. This makes it easier to find the problem, and then fix.<br />
<br />
== When designing such setups, with bridge networking, I often find it easier to think of dom0 as a switch or router, and domU like any other physical server on your network. ==<br />
<br />
In your setup you're making dom0 act as router/firewall. Your problem is that probably you haven't setup ip forwarding and NAT on dom0 to allow domU internet access.<br />
<br />
Note that (if you want) you could also have dom0 act like a switch. In that scenario you'd need another domU, with two network interfaces connected to both dom0's eth0 and eth1, acting as router/firewall.<br />
<br />
== How do I configure Xen guests to work with my VLANs? ==<br />
<br />
Have a trunk port in your dom0 and create bridges for each VLAN for Xen. If you have the VLAN trunk set up, you can create bridges as follows. For this example, my trunk interface is on eth0 and the vlan I am adding is 2.<br />
<br />
<pre><nowiki><br />
# vconfig add eth0 2 # brctl addbr xenbr2 # brctl addif xenbr2 eth0.2 # ifconfig eth0.2 up # ifconfig xenbr2 up<br />
</nowiki></pre><br />
<br />
Now add the following to your domU configuration file:<br />
<br />
<pre><nowiki><br />
vif=['bridge=xenbr2']<br />
</nowiki></pre><br />
<br />
And the domU will be on VLAN 2. To access the trunk port directly inside the guest, pass through the network card to get VLAN access. You can also script this and give it a space separated list of VLANs and loop it through. <br />
<br />
[[Category:Xen]]<br />
[[Category:FAQ]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
[[Category:Networking]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=XCP_Introduction&diff=4527XCP Introduction2012-07-30T14:57:22Z<p>OliverChick: /* Installation */ Added the apt-get method of installating XCP</p>
<hr />
<div><!-- MoinMoin name: XCP_Introduction --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: XCP Introduction --><br />
<!-- Page revision: 00000006 --><br />
<!-- Original date: Sun Oct 16 14:30:31 2011 (1318775431000000) --><br />
__NOTOC__<br />
=Introduction=<br />
This introduction is a simple explanation for those unfamiliar with Xen, [[XenServer]], and Xen Cloud Platform (XCP).<br />
<br />
Xen itself is the underlying virtualization software. It's the hypervisor component that actually runs the virtual guest machines. It has been used by many projects and packaged in many ways. It can be installed and run on many *nix operating systems, for example as a Linux package installed with apt on Ubuntu. There's a very nice explanation with further details on the [http://en.wikipedia.org/wiki/Xen Xen Wikipedia page]. XCP is derived from the commercial Citrix [[XenServer]], which itself also includes Xen, but XCP is completely free and open source. XCP can be thought of as the open source release of XenServer.<br />
<br />
= System components =<br />
<br />
The current XCP v1.1 release was derived from [[XenServer]] 5.6 FP1. <br />
<br />
XCP 1.1 is a packaged up version of Linux CentOS 5 (Linux kernel v2.6.32), combined together with Xen 3.4.2, and a web service API called XenAPI that provides a management API for the Xen components intended to be used by various [[XCP_Management_Tools|Management Tools]]. XCP can be installed in two ways:<br />
* A bootable ISO allows you to quickly get a bare-metal machine running as a virtualization server (this is comparable to VMware ESXi).<br />
* The Debian and Ubuntu repos have XCP packages, allowing XCP setups that don't run on CentOS.<br />
<br />
= Installation =<br />
== Installable ISO ==<br />
# Download the ISO<br />
# Boot/install it on a fresh machine (likely using the whole available hard drive)<br />
# Configure the network from the very brief administrative interface that stays on the screen after installation<br />
# Manage the server over the network using [[Command Line Interface|CLI tools]], or a [[XenManagementTools|GUI management tool]]. <br />
# Now you can start installing and running [http://xen.org/download/xcp/index.html supported guest VMS] using [http://en.wikipedia.org/wiki/Xen#Types_of_virtualization paravirtualization or hardware virtualization]. <br />
## You can run hardware virtualization (HVM) guests only if your machine has the necessary hardware to support it. <br />
## Otherwise any CPU can run paravirtualization (PV) guests, it just means you're limited to the guest OSes and kernel versions that specifically support PV (e.g. Ubuntu 10.04 for example supports PV).<br />
<br />
There's a great article here that shows screen-shots all the way through the installation process: [http://www.dedoimedo.com/computers/xen-cloud.html http://www.dedoimedo.com/computers/xen-cloud.html]<br />
<br />
== From the Debian/Ubuntu Repos ==<br />
# Install Debian, or Ubuntu, using your preferred method<br />
# <pre>apt-get install xcp-xapi</pre><br />
<br />
= Management =<br />
After installation, many users choose to use [http://community.citrix.com/display/xs/XenCenter Citrix XenCenter] for management as it is a stable and mature tool. If you're not interested in a GUI, you can SSH to the XCP server itself, and run the built-in command line tools (xe and xl) as described on the [[XenManagementTools|Management Tools]] and [[Command Line Interface]] pages. You can also [[XCP_Install_CLI|install the management CLI on a separate Linux box]].<br />
<br />
If you have existing physical machines or VMs from other hypervisors, you can [[XCP Import Existing VM|import them into XCP]].<br />
<br />
= Documentation =<br />
<br />
Per the explanation on http://xen.org/products/xcp/community_and_support.html, the best documentation for XCP is the official Citrix [[XenServer]] docs for 5.6 FP1, available here: http://docs.vmd.citrix.com/XenServer/5.6.0fp1/1.0/en_gb/<br />
<br />
This is one reason documentation for "XCP" itself is hard to find; the team has not yet written official separate XCP docs as the [[XenServer]] docs are applicable to XCP. You can also find links to XCP documentation for a specific release in [[:Category:Manual]].<br />
<br />
This documentation is best combined with knowledge of the feature differences between XCP and [[XenServer]], as explained on the [[XCP/XenServer_Feature_Matrix|XCP/XenServer Feature Matrix comparison]] page.<br />
<br />
[[Category:XCP]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
[[Category:Overview]]</div>OliverChickhttps://wiki.xenproject.org/index.php?title=XCP_Introduction&diff=4525XCP Introduction2012-07-30T14:55:36Z<p>OliverChick: /* System components */ Added info on Debian and Ubuntu XCP setup</p>
<hr />
<div><!-- MoinMoin name: XCP_Introduction --><br />
<!-- Comment: --><br />
<!-- WikiMedia name: XCP Introduction --><br />
<!-- Page revision: 00000006 --><br />
<!-- Original date: Sun Oct 16 14:30:31 2011 (1318775431000000) --><br />
__NOTOC__<br />
=Introduction=<br />
This introduction is a simple explanation for those unfamiliar with Xen, [[XenServer]], and Xen Cloud Platform (XCP).<br />
<br />
Xen itself is the underlying virtualization software. It's the hypervisor component that actually runs the virtual guest machines. It has been used by many projects and packaged in many ways. It can be installed and run on many *nix operating systems, for example as a Linux package installed with apt on Ubuntu. There's a very nice explanation with further details on the [http://en.wikipedia.org/wiki/Xen Xen Wikipedia page]. XCP is derived from the commercial Citrix [[XenServer]], which itself also includes Xen, but XCP is completely free and open source. XCP can be thought of as the open source release of XenServer.<br />
<br />
= System components =<br />
<br />
The current XCP v1.1 release was derived from [[XenServer]] 5.6 FP1. <br />
<br />
XCP 1.1 is a packaged up version of Linux CentOS 5 (Linux kernel v2.6.32), combined together with Xen 3.4.2, and a web service API called XenAPI that provides a management API for the Xen components intended to be used by various [[XCP_Management_Tools|Management Tools]]. XCP can be installed in two ways:<br />
* A bootable ISO allows you to quickly get a bare-metal machine running as a virtualization server (this is comparable to VMware ESXi).<br />
* The Debian and Ubuntu repos have XCP packages, allowing XCP setups that don't run on CentOS.<br />
<br />
= Installation =<br />
# Download the ISO<br />
# Boot/install it on a fresh machine (likely using the whole available hard drive)<br />
# Configure the network from the very brief administrative interface that stays on the screen after installation<br />
# Manage the server over the network using [[Command Line Interface|CLI tools]], or a [[XenManagementTools|GUI management tool]]. <br />
# Now you can start installing and running [http://xen.org/download/xcp/index.html supported guest VMS] using [http://en.wikipedia.org/wiki/Xen#Types_of_virtualization paravirtualization or hardware virtualization]. <br />
## You can run hardware virtualization (HVM) guests only if your machine has the necessary hardware to support it. <br />
## Otherwise any CPU can run paravirtualization (PV) guests, it just means you're limited to the guest OSes and kernel versions that specifically support PV (e.g. Ubuntu 10.04 for example supports PV).<br />
<br />
There's a great article here that shows screen-shots all the way through the installation process: [http://www.dedoimedo.com/computers/xen-cloud.html http://www.dedoimedo.com/computers/xen-cloud.html]<br />
<br />
= Management =<br />
After installation, many users choose to use [http://community.citrix.com/display/xs/XenCenter Citrix XenCenter] for management as it is a stable and mature tool. If you're not interested in a GUI, you can SSH to the XCP server itself, and run the built-in command line tools (xe and xl) as described on the [[XenManagementTools|Management Tools]] and [[Command Line Interface]] pages. You can also [[XCP_Install_CLI|install the management CLI on a separate Linux box]].<br />
<br />
If you have existing physical machines or VMs from other hypervisors, you can [[XCP Import Existing VM|import them into XCP]].<br />
<br />
= Documentation =<br />
<br />
Per the explanation on http://xen.org/products/xcp/community_and_support.html, the best documentation for XCP is the official Citrix [[XenServer]] docs for 5.6 FP1, available here: http://docs.vmd.citrix.com/XenServer/5.6.0fp1/1.0/en_gb/<br />
<br />
This is one reason documentation for "XCP" itself is hard to find; the team has not yet written official separate XCP docs as the [[XenServer]] docs are applicable to XCP. You can also find links to XCP documentation for a specific release in [[:Category:Manual]].<br />
<br />
This documentation is best combined with knowledge of the feature differences between XCP and [[XenServer]], as explained on the [[XCP/XenServer_Feature_Matrix|XCP/XenServer Feature Matrix comparison]] page.<br />
<br />
[[Category:XCP]]<br />
[[Category:Users]]<br />
[[Category:Beginners]]<br />
[[Category:Overview]]</div>OliverChick