Build Instructions

This document is intended for developers who want to build the oVirt components from scratch. If you just want to see how it works, just follow the install instructions. The below steps assume a familiarity with Linux development tools.

This page is specific to the lastest release for oVirt and uses the 'master' branch of the git repositories. To work from the current development tree, use the 'next' branch of the oVirt git repositories and see the rawhide build instructions

Throughout this document, we give commands to type at a shell prompt. By convention, if a command is meant to be run by a non-privileged user, we will preface it with sudo.

Source Repositories

Source code is contained in the following source repositories:

  1. ovirt-server: RPMs that provide oVirt Server Suite functionality
  2. ovirt-node: RPMs that provide oVirt node functionality
  3. ovirt-node-image: RPMs that contain LiveCD ISO image and PXE images of the oVirt Node which uses the ovirt-node RPM
  4. ovirt-recipe: RPM that contains a recipe for creating the oVirt Appliance using the Thincrust tools.
  5. ovirt-appliance: RPM that contains a Fedora appliance OS based on the ovirt-recipe RPM
  6. ovirt-release: RPM that contains yum repo configuration file for ovirt.org repositories and developer convenience scripts
  7. ovirt-docs: RPMs that contain documentation for the oVirt project

All of these source repositories are available via git web interface. It is not necessary to manually clone each of these repositories. Please follow the instructions below for using the ovirt.mk Makefile provided in the ovirt-build RPM for retrieving the repositories.

Prerequisites

There are a few prerequisites to building the oVirt components:

  1. Fedora 10: installed with latest updates.
  2. Passwordless Sudo: The user running the build does not need to be root, however it does need to have passwordless sudo as root access. This is because the ovirt-appliance and ovirt-node-image repositories use livecd-creator which presently requires root.
  3. Hardware Virtualization Support: The oVirt Node and oVirt Appliance require hardware assisted virtualization. A processor with either Intel VT or AMD AMD-V is required to run oVirt. The build process does not require hardware virtualization.
  4. rpmmacros: The user must have valid ~/.rpmmacros set up. A minimal rpmmacro file should contain:
    %_topdir      %(echo $HOME)/rpmbuild
    This will put your rpmbuild directory in ~/rpmbuild. Adjust the destination to your liking.
  5. SELinuxThe Node is built with SELinux enabled by default. This requires build host to also have SELinux enabled in Permissive mode. If SELinux is not enabled, the build will fail. If it is enabled but in Enforcing mode the build will temporarily put the host into Permissive mode and then toggle back to Enforcing

    NOTE: The Node does not require SELinux to be enabled, though it is by default. This behavior can be toggled in the Node kickstart file in the ovirt-node-image repository.
  6. Additional Computers: These computers should be cabled to a private LAN that will be bridged to the oVirt Appliance. These computers will run the oVirt Node and will be managed by the oVirt Server.

Getting Started

In order to build oVirt you will need several RPMs from the ovirt.org repositories. To get these, install the ovirt-release RPM which provides a yum configuration file. Because this process updates libvirt and you'll need to restart libvirt at the end, shut down any existing virtual machines before proceeding.

  1. Install the ovirt-release RPM to get yum configured:
    sudo rpm -ivh http://ovirt.org/repos/ovirt/ovirt-release-LATEST.noarch.rpm
  2. Update any existing RPMs with newer RPMs available in the oVirt repository:
    sudo yum update --enablerepo=ovirt
  3. Install additional RPMs necessary for building the components.
  4. sudo yum install --enablerepo=ovirt ovirt-build
  5. Restart libvirtd to pick up the newer version:
    sudo service libvirtd restart

Using the oVirt Makefile

the ovirt-build RPM provides a Makefile to assist developers with building from source.

This makefile provides a convenient way for a developer to clone/update all of the git repositories and to do an end-to-end build. In addition, it can be used to just build specific components rather than the entire system.

The makefile also uses several environment variables to alter its behavior:

  1. OVIRT_BRANCH - This specifies which branch to use in git. Default is 'next', which is for the latest development code. Stable releases are in the 'master' branch.
  2. FEDORA_URL - This provides a local mirror to use for Fedora repositories. Default is to use the remote mirrorlist. An example FEDORA_URL would be:
    http://download.fedora.redhat.com/pub/fedora/linux
  3. OVIRT_CACHE_DIR - The build of ovirt-node-image and ovirt-appliance requires RPMs from Fedora repositories. This is the location of a cache directory for storing files used in those builds. Default is to use ~/ovirt-cache
  4. SUBDIRS - The list of repositories to build. This can be overridden if you only want to work with a subset of the repositories available. The default set is defined in the ovirt.mk file in the ovirt-release repository.

To build the entire system

  1. Set the OVIRT_BRANCH environment variable to work with the 'master' branch
    export OVIRT_BRANCH=master
  2. Prepare your development directory and check out the git repositories:
    mkdir $HOME/ovirt
    cd $HOME/ovirt
    make -f /usr/share/ovirt-build/ovirt.mk update
  3. Create a symlink to the release/ovirt.mk makefile to use in the top level build directory:
    ln -s release/ovirt.mk Makefile
  4. Run a build of all components:
    make build
    This step will take a quite a while to complete the first time you run it. Subsequent runs should take much less time, since the downloaded packages are stored in a cache directory.

The following are some of the top level make targets in ovirt.mk that are useful for developers:

  1. update - This target refreshes all of the repository checkouts with git pull and switches to the branch specified in OVIRT_BRANCH
  2. build - Does a build of all repositories
  3. update-host - Does yum localinstall of locally build RPMS for ovirt-appliance, ovirt-release and ovirt-build
  4. update-app - Does an update-host followed by commands to install/update the appliance on the local machine.
  5. status, diff, branch, show-branch - Runs the corresponding git command on each of the repository directories

Following a successful build the generated RPMs for each of the git repositories will be placed into $OVIRT_CACHE_DIR/ovirt. A symlink is created in the build directory (for example: ~/ovirt/rpms).

Installing the Appliance and oVirt RPMS

After the build has finished, update your host with the new appliance, release and build RPMs. This can be done with the following command:

make update-app

Then install the oVirt network for the appliance with:

sudo create-ovirt-network [-e ethX]

The [-e ethX] argument is optional. If you want to bridge your appliance to an outside network through an unused interface on the system, supply this argument. Otherwise you can use the appliance without a bridge and it can still manage virtual machines on the local physical host.

NOTE: Fedora 10 uses NetworkManager by default to configure network interfaces. We recommend disabling NetworkManager and using the standard network scripts and network service. However, if you want to try running with NetworkManager enabled you can override the check with the -f flag to the create-ovirt-network script. Instructions for disabling NetworkManager can be found here: Appliance_Installation

Starting the Appliance

The appliance can then be started with:

sudo virsh start ovirt-appliance

You can either use virt-viewer or virsh console to monitor the boot process

sudo virt-viewer ovirt-appliance
sudo virsh console ovirt-appliance

The first appliance boot after a fresh install/build will take 5-10 minutes (depending on the speed of your host).

Finally, you can bring up the main oVirt web user-interface by running firefox on the host machine.

Browse to http://192.168.50.2/ovirt

Default username/password is ovirtadmin/ovirt

The root password for the appliance is ovirt

Managing oVirt Nodes

If you have real physical hardware cabled up, you can boot up any physical hardware you have cabled to your private LAN. Make sure that your hardware is set to PXE boot first, otherwise it will boot to the normal operating system.

If you do not have real physical hardware to run Nodes on, you can manage guests running directly on the host that is running the Appliance. To enable management of guests directly on the appliance host make sure the appliance is not running and then do the following:

sudo ovirt-install-node stateful

Boot the appliance as described in the above section and bring up the oVirt web user interface in a Firefox. Navigate to the Hosts tab in the Default hardware pool and verify that a host is added with the hostname physical.priv.ovirt.org. It should be marked as unavailable. This is normal.

Shut down the appliance with:

sudo virsh shutdown ovirt-appliance

Restart the libvirt daemon:

sudo service libvirtd restart

Start the appliance as described in the above section. Again, navigate to the Hosts tab of the Default hardware pool. This time the physical.priv.ovirt.org host should show up as available. You can now use this host to create and manage virtual machines.

Starting Fake Nodes for Development Testing

Once the appliance is booted, you can start fake oVirt Nodes on the host machine:

sudo virsh start nodeX

There are 6 fake Nodes installed for development. node3-5 PXE boot from the appliance. node6-8 boot from the oVirt ISO installed on the host. Each PXE node has a different default boot behavior for use in testing the different modes for the Node:

The fake oVirt Nodes are intended for development and testing usage. They have very limited amounts of memory (512MB RAM each) and cannot utilize hardware accelerated virtualization. Provisioning a real operating system on these fake Nodes is not recommended. If you only have a single hardware virtualization capable machine, you can manage guests directly on that machine from the appliance.