Fedora Host Installation
This page covers the steps to get a working Xen host system (a.k.a. dom0) running Fedora.
Fedora 16 is the first version of Fedora shipping a Linux kernel suitable for being used as Xen dom0 out of the box (the first since the time of Fedora 8). This comes directly from the fact dom0 support is now merged in mainline Linux. This page explains the steps needed to turn a plain Fedora installation into fully functional Xen host.
Some general information about virtualization and Fedora are available here.
Installing Fedora
Base System Installation
For the most part, you can follow the Installation steps outlined in the official Fedora installation guides (here they are for F16, F17 and F18).
For the lazies, here they are the installation quick start guides: F16, F17, F18 not available yet.
For obtaining install media images, look here or here.
The only portion one should watch out is the disk partitioning section. If wanting to to use file-backed domUs, nothing special even there. However, if LVM volumes (or other block devices, like hard drive partitions) is to be used, it is wise to partition the hard drive at least into a /boot physical partition, and one or two volume groups. Have a look here for more details about this.
Updating the System
You probably want to be sure the all the software is as up-to-date as possible. To do that, run
# yum update
(or use any graphical front-end, e.g., find and click on 'Software Update').
Using the virt-preview Repository
People who would like to test the very latest virtualization related packages (coming from Fedora rawhide) can enable the Virtualization Preview Repository (please, notice that Fedora discourages doing this in 'production' deployments).
In order to make it happen, just do as follows:
# cd /etc/yum.repos.d/ # wget http://fedorapeople.org/groups/virt/virt-preview/fedora-virt-preview.repo # yum update
Disabling SELinux
It is possible to keep SELinux enabled and get Xen to work. However, that will happen at the cost of various SELinux related errors, that needs to be fixed, for instance, by running the following commands:
# grep <vairous_stuff_here> /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
dozens of times! If that is fine, then fine. If not, it might be better to disable SELinux, by making sure /etc/sysconfig/selinux has a line looking like:
SELINUXTYPE=permissive
or:
SELINUXTYPE=disabled
instead of one looking like:
SELINUXTYPE=enabled
Installing and Running Xen
Installing the Packages
For installing Xen, just run:
# yum install xen
as root. yum will, as usual, take care of downloading and installing anything that is needed. As a part of that, it also create a new GRUB2 boot menu entry. Once the installation is complete, just reboot and select "Xen 4.x.x" from the GRUB2 menu.
If on Fedora 18, you will likely see something like "Xen 4.2.x". If on Fedora 16 or 17, it will have "Xen 4.1.x" in it. It is also possible that you only see something like "Fedora, with Xen hypervisor", and that is also ok.
Networking deserves some special attention. In fact, it is something that gave a lot of trouble in the past (Xen 3/4.0). That is why, from Xen 4.1 on, the default behavior is to let the dom0's network scripts (i.e., the ones that came with the distribution, not the ones that come with Xen) handle setting up a network bridge, and let the toolstack just attach the domU's network interface to the it. More on this matter down in the page.
Booting Xen by Default
Although a Xen GRUB2 menu entry will be automatically created, it will likely not be the default one. To make it so, ensure to you have a line like this in /etc/default/grub:
GRUB_DEFAULT="saved"
and then do:
# grub2-mkconfig -o /boot/grub2/grub.cfg # grep ^menuentry /boot/grub2/grub.cfg | cut -d "'" -f2 # grub2-set-default <menu entry title you want>
Disabling Network Manager
In case of any networking issues, or if you want to manually manage the network configuration, disabling NetworkManager is necessary (e.g., because NetworkManager does not support bridges), and that requires manually editing a couple of config files. This is particularly true if you do not plan to install and use the typical Fedora virtualization tools, like libvirt, etc. In fact, libvirt automatically creates a bridge and sets up the VMs created via its interface(s) to use it by default. On the other hand, if not using libvirt, the bridge has to be created by hand.
For Red Hat-based distros, the networking configuration is stored in /etc/sysconfig/network-scripts/. First of all, disable the NetworkManager service:
# systemctl disable NetworkManager.service || systemctl restart network.service
Also, make sure that the network service is kicked off automatically on subsequent restarts by running:
# chkconfig network on
Next, create the configuration file for the bridge. The most common bridge name is br0, so let's stick to that (although other Xen documentation suggests using xenbr0 to make it obvious that the bridge is for Xen):
# touch /etc/sysconfig/network-scripts/ifcfg-br0
open the file in a text editor and put the following lines in it:
DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes DELAY=0 NM_CONTROLLED=no
Next, you need to find the configuration file for your existing network adaptor. It's most likely named ifcfg-eth0 or ifcfg-em0 (the part after the dash can and does change depending on the actual hardware). Once you know what config file you're using, open it, find the line
NM_CONTROLLED=yes
and change it to
NM_CONTROLLED=no
. Also, do not forget to add the line
BRIDGE=br0
(or whatever you named your bridge) to that file.
Finally, run this:
# systemctl restart network.service
and the bridge should look like this:
# ifconfig br0
br0 Link encap:Ethernet HWaddr 00:07:E9:06:50:12
inet addr:192.168.1.122 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::207:e9ff:fe06:5012/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1858 errors:0 dropped:0 overruns:0 frame:0
TX packets:678 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:329223 (321.5 KiB) TX bytes:76663 (74.8 KiB)
Rebooting and "Running" Xen
Now that Xen is installed, (re)boot in the proper option, as explained above, and check it's working, e.g., by running xl info from the command line, which should then tell something like this:
# xl info host : localhost.localdomain release : 3.7.6-201.fc18.x86_64 version : #1 SMP Mon Feb 4 15:54:08 UTC 2013 machine : x86_64 nr_cpus : 16 max_cpu_id : 63 nr_nodes : 2 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 2394 hw_caps : bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000000:00000001:00000000 virt_caps : hvm hvm_directio total_memory : 12285 free_memory : 128 sharing_freed_memory : 0 sharing_used_memory : 0 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : .1 ...
If Xen's not working, you'll get something like:
libxl: error: libxl.c:56:libxl_ctx_init Is xenstore daemon running? failed to stat /var/run/xenstored.pid: No such file or directory cannot init xl context
Choosing a Toolstack
By this point, everything is set, and ready to start installing VMs (also called domUs).
This can be done in a variety of ways, e.g., by using xl. xl is the default toolstack since Xen 4.2 so, especially in F18, it is highly recommended to use it, especially as the old toolstack, xend will be discontinued starting from Xen 4.3 (for a comparison between the two, see here). The two toolstacks do not play well together, and xend needs not to be running if wanting to issue xl commands. To check for that, something like:
# ps aux | grep xend
should do. If xend turns out to be running, it might be because it is being started automatically, as a service, during system boot. Check for that by doing:
# systemctl is-enabled xend.service
(and quite obviously the answer should be disabled), and check whether it currently running as a service with:
# systemctl status xend.service
.
To stop and disable it, and be then able to use xl, do:
# systemctl stop xend.service # systemctl disable xend.service
Of course, if for any reason one wants to use xend, just do the opposite, i.e., enable and start it by:
# systemctl enable xend.service # systemctl start xend.service
Using libvirt and Typical Fedora Virt-Tools
Installing the Packages
If wanting to use libvirt and/or VirtManager, just do the following (tested on Fedora 18):
# yum install libvirt-daemon-xen python-virtinst libvirt-daemon-config-network libvirt-daemon-driver-network virt-manager virt-viewer
Most likely, everything will just work, and you are all set for starting creating VMs, e.g., with virt-install as described here or with VirtManager, as described here. That happens because libvirt automatically creates and configures bridging and everything that is needed.
libvirt and libxl
As already stated, starting from Xen 4.2, the default toolstack is libxl (i.e., the "library-counterpart" of xl). libvirt has a libxl driver, but libvirt packages for F18 does not ship the proper version of it. On the other hand, the xend based driver is known to work quite well, so it might be best (for now) to just use that. That happens by making sure that libvirt-daemon-driver-libxl is not installed (again, tested on Fedora 18).
There is an on-going effort to fill the gap and render the libvirt libxl driver feature complete and fully functional, although it is yet unclear when that will happen.
This page will be kept up-to-date with any progress being made with respect to this, so come back here periodically and check them out.}}
Installing DomUs
With libvirt, installing VMs (especially in case of RedHat based distros, like Fedora or CentOS), this extremely easy, and you can refer to:
- installing a domU with virt-install (console based) or,
- installing a domU with virt-manager (GUI based),
for more details.
Known Issues
GRUB2 Menu in Fedora 16
In Fedora 16 there is a known bug that results in GRUB2 generating a number of boot entries for each Xen file that it finds in /boot, even if they are just symlinks. This results in quite a bit of spurious entries. This is no longer the case starting from Fedora 17.
SELinux and LVM in Fedora 16 & 17
In Fedora 16 and 17, you may need to disable SELinux if you're managing LVM storage manually (unless you want to relabel the volumes). In fact, xl will otherwise complain that "the disk is not accessible".
This does not seem to be an issue in Fedora 18 (if it is for you, report it to fedora-virt and/or fedora-xen). Of course, SELinux may cause a number of other issues (for instance if using xend) even in F18, thus disabling it might well be the best option anyway.
Kernel Update in Fedora 16, 17 & 18
When a new kernel is installed, as a consequence of running:
# yum update
grubby is used to update the GRUB2 config file. As reported by this bug, grubby does not handle Xen menu entries very well, and thus it is possible for Xen to no longer be able to boot. We're looking into possible fixes. For now, the solution is to manually run, after each update that install a new kernel, the following command:
# grub2-mkconfig -o /boot/grub2/grub.cfg
That is why, when updating the xen-hypervisor package, it is grub2-mkconfig that is invoked, and hence the issue does not manifest itself in that case.
libvirt, xend and libxl in Fedora 16, 17 & 18
libxl is the default toolstack for Xen 4.2, while it is nothing more than a tech preview for previous releases of Xen. For that reason, the libvirt libxl driver is disabled in Fedora 16 and 17, and the only option to use virt-install and virt-manager there, is to run and use xend.
In Fedora 18, the driver is enabled, but seems to have some bugs. This page will be kept update with any information related to this issue but, in the meanwhile, it might be better to use xend anyway (again, by just starting the daemon as described above).
