Use Cases
oVirt is aimed at two specific audiences. The first is the Open Source Developer, which is us and is likely you. The second is the medium to large enterprise IT system.
Contents |
Open Source Developer
All of us at Red Hat are open source developers and so we'd like ourselves and others to be able to use the oVirt system easily and effectively.
Simple Requirements
2 Machines — 1 Admin Node and 1 Managed Node — are optimal for testing and development on oVirt. It is however possible to develop with a single hardware-virtualization-enabled machine by running the managed nodes as VMs on the single machine. libvirt will automatically start VMs within these managed nodes as straight QEMU guests, meaning they will be very slow, but will still work.
1 Download of a Management Appliance we provide. This appliance has all the necessary server services configured to run in the same virtual instance. It's assumed that this will be run as a virtual machine on a machine using Xen or KVM. The Management Appliance should not require a large amount of resources.
Process
Following the install instructions a developer or tester should be able quickly download any necessary bits and follow the instructions for getting a development system up and running.
Once a system is up and running the developer should be able to use the oVirt management interface to create new Virtual Machines to run on the Managed Node.
Further Steps
Simplifying steps for getting the source code to hack on the oVirt management wui would help to ease developers into developing on their own.
We need simple downloading of full appliances from places like rhx and other sites that provide packaged virtual appliances.
Medium to Large Enterprise
Enterprises who need to easily manage large numbers of virtual machines and physical hosts do not have a system that scales to their usage. oVirt was designed from the ground up to scale beyond a small number of virtual machines and hosts to thousands of virtual machines and hosts.
oVirt users
We envision three different oVirt user classes at the enterprise level:
Hardware administrator
- Racks physical hosts and provisions them with the oVirt managed node image
- Connects network attached storage (iSCSI, NFS)
- Groups hosts and storage in physical networks
- Assigns hosts and storage to teams of users
- Manages top-level user group membership
- Prepares hosts for downtime by migrating VMs
Team administrator
- Manages user quotas, permissions, and subgroups for team hardware
- Monitors physical hosts for resource issues, bottlenecks
- Maintains available team VM install images/appliances
- Defines SLA for team hardware, in terms of: CPU availability; memory usage; network bandwidth
oVirt user
- Creates, destroys, pauses, resumes, saves, restores VMs on a team hardware collection
- Connects to VMs from the browser interface with a console plug-in
- Configures VMs as virtual clusters for HA
- Bonds available NICs for bandwidth aggregation
- Views current and historic performance information for VMs to determine SLA needs
Fundamentally, we imagine a hardware administrator dedicating machines and storage to discrete groups, which then treat those resources generically. In this paradigm concern over precisely which box a particular app is running on disappears, replaced by software-defined resource limits and SLA definitions dictated by a team administrator. Finally users are freed to manage their own VMs, within quota/SLA, entirely as they see fit without requiring any administrator attention.

