Fedora Host Installation
This tutorial will cover the steps to get a working dom0 running on a Fedora system.
Fedora 16 is the first version of Fedora that comes with a kernel that supports a Xen dom0 out of the box since Fedora 8. This is a result of dom0 support being merged into the mainline kernel. As such, there are very few steps that have to be done to get a functional dom0. Some information about using a Fedora system as a virtualization host, coming directly from them, can be found 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). If you're lazy, you probably may just look at the installation quick start guides (F16, F17).
For obtaining install media images, look here.
The only portion you have to watch out is the disk partitioning section. If you're going to use file-backed domUs, you can safely ignore this step. However, if you're going to use LVM (or other block devices, like hard drive partitions)-backed domUs, you're probably going to partition your drive into /boot, and at least one or two volume groups, meaning that you'll be making a custom partitioning scheme. Have a look here for more details about this Host OS Install Considerations.
Some Post-Install Tasks
At this point, you should do whatever else you have to get the basic system up and running. Example tasks would be updating the system, and installing ntpd to automatically keep your dom0's time in sync. At a minimum, you should check that a network connection is available and functioning.
You probably also want to be sure the all the software is as up-to-date as possible. To do that, run
yum update
as root (or use any graphical front-end, e.g., find and click on 'Software Update').
Still related to software updates, you might be interested in activating the Virtualization Preview Repository. It is the place where the very latest virtualization related packages live. Enabling it will install the most recent virtualization related packages, which could be very good for personal use, testing and experimentation, as it most likely IS NOT for 'production' deployments.
In Fedora 16 and 17, you may also need to disable SELinux if you're managing LVM storage manually, unless you want to relabel the created LVs. xl will complain that "the disk is not accessible" if you fail to do this and you're using LVs for storage. This does not seem to be an issue in Fedora 18 (although it needs to be verified properly after GA).
Installing Xen
Getting the Xen hypervisor is a simple matter - just run
yum install xen
as root. Yum will take care of downloading the dependencies and installing them for you automatically.
As part of the download, Yum will create a new grub2 boot menu. As such, don't panic if Yum seems to freeze at "Installing xen-hypervisor" for a while.
Once the installation is complete, you should reboot, and select Xen 4.x.x from the GRUB menu.
Networking deserves some special attention. In fact, it is something that gave a lot of trouble in the past (Xen 3/4.0). However, starting from Xen 4.1, 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.
Booting Xen by Default
Although a Xen GRUB2 menu entry will be automatically created, it will likely not be the default boot option. If this is what you want, ensure to you have a line like this:
GRUB_DEFAULT=saved
in /etc/default/grub, 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>
Installing the Virt Tools
If wanting to use libvirt and/or VirtManager, just do the following (tested on Fedora 18):
# yum install libvirt-daemon-driver-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.
|
libvirt: libxl VS. xend
Starting from Xen 4.2, the default toolstack is libxl. 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. |
Using the virt-preview Repository
People who would like to test the very latest virtualization related Fedora 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 Network Manager
In case of any networking issues, or if you want to manually manage the network configuration, disabling NetworkManager is necessary (as NetworkManager does not support bridges), and that requires manually editing a couple of config files. For Red Hat-based distros, the networking configuration is stored in /etc/sysconfig/network-scripts/. By default, NetworkManager is included in the default Fedora install. To disable it, do the following (as root):
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 your network should be looking like below:
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)
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. Unfortunately, it doesn't check if the file in question is a linked file, and results in generating a host of spurious entries. This is no longer the case from Fedora 17.
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.
xend vs. libxl in Fedora 16, 17 & 18
Starting from Xen 4.2, the default toolstack is libxl. libvirt has a libxl driver, but libvirt packages does not ship the proper version of it. On the other hand, the xend based driver is known to work quite well, so it is best (for now) to just use it. That happens by making sure that libvirt-daemon-driver-libxl is not installed (tested recently 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.
Running Xen and Installing DomUs
Now that Xen is installed, boot it and check it's working, e.g., by doing by running xl info from the command line. Your screen should then look like the below:
# xl info host : caesium release : 3.1.1-2.fc16.i686.PAE version : #1 SMP Mon Nov 14 15:57:20 UTC 2011 machine : i686 nr_cpus : 4 nr_nodes : 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
By this point, your system should be set up to install domUs. You can install domUs with a variety of ways.
For beginners, Fedora has libvirt in its repositories, which makes installing VMs, especially Red Hat based distros (like Fedora/CentOS), extremely easy. You can refer to:
- installing a domU with virt-install (console based) or,
- installing a domU with virt-manager (GUI based).
