From Fedora Project Wiki

No edit summary
(16 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{header|docs}}
{{header|docs}}
{{Docs_beat_open}}
{{Docs_beat_closed}}
==Libvirt Client Access Control==


= Live Snapshotting of Virtual Machines =
The '''libvirt''' client allows for the setting of permission rules which can be applied to all managed objects and API operations, thus allowing for all client connections to be limited to a minimal set of rules and privileges.
There are three levels of access which can be assigned:


The virtualization stack in Fedora has provided the ability to take "snapshots" of a virtual machine for many releases. These functions have however always required that the virtual machine be paused or stopped while the storage snapshot was created. Recent updates included in Fedora 17 allow for '''qemu''' and '''libvirt''' to create snapshots of a virtual machine without requiring any downtime.
* Unauthenticated - used for all connections, this state allows all API operations that are required to complete authentication. Following a successful authentication, two more levels can be assigned:
** Unrestricted - full access to all API operations
** Restricted - read only access


Live snapshot creation now works even for virtual machines using disk images stored in RAW format. In these cases '''libvirt''' creates snapshots using external QCOW2 files - transparently switching the virtual machine to run on the new external image(s) once created.
System administrators can set permission rules for authenticated connections. Every API call in '''libvirt''' has a set of permissions that are validated against the object that is being used. For example, User A wants to change a parameter in the '''domain''' object. When the user tries to save the change, '''virDomainSetSchedulerParametersFlags''' method will check whether the client has write permissions on the '''domain''' object. Additional checks and permission settings can be processed as well. Filtering can also be done to see which clients have permissions on which objects to allow for smother administration of permissions.
The '''libvirtd.conf''' configuration file is responsible for setting the access permissions. It uses the ''access_drivers'' parameter to enable this operation. Note that if more than one access driver is requested, all must succeed in order for permission to be granted.
More information can be found here:


= Manage Virtualized Environments with oVirt 3.1 =
* https://fedoraproject.org/wiki/Changes/Virt_ACLs
* http://libvirt.org/acl.html


Fedora 17 included the packages required to support a minimal installation of the oVirt virtualization management platform. This initial offering has now been significantly expanded. oVirt has arrived! In addition to the existing functionality it is now possible to use a Fedora installation as a fully fledged oVirt "Engine" - providing a graphical management console for your virtualized environments.
==Virt-manager Snapshots==
Virtual Machine Manager ('''virt-manager''') allows for easy management and monitoring of KVM guest virtual machine snapshots. Note that '''virt-manager''' will pause the guest virtual machine for a few seconds while taking the snapshot.
More information is available here:
* https://fedoraproject.org/wiki/Changes/Virt_Manager_Snapshots
* http://fedoraproject.org/wiki/Features/Virt_Live_Snapshots
* http://libvirt.org/formatsnapshot.html
* Snapshot section here: http://linux.die.net/man/1/virsh
* https://fedoraproject.org/wiki/QA:Testcase_Virt_Snapshot_UI


Project homepage: http://ovirt.org.
==ARM emulation on x86 Host Physical Machines==
Changes have been made to have smoother emulation of ARM guest virtual machines running on x86 hosts using standard '''libvirt''' tools, including '''virsh''', '''virt-manager''' and '''virt-install'''.
'''qemu''' has an ARM emulator that works well and is actively used in the  Fedora ARM effort. However '''libvirt''' and '''virt-manager''' currently have  issues launching '''qemu-system-arm''' VMs, mostly by encoding x86 assumptions  in the generated command line that cause '''qemu-system-arm''' to fail to  start. Changes have been made to fix this issue.
More information can be found here: https://fedoraproject.org/wiki/Changes/Virt_ARM_on_x86


== oVirt Engine Installation ==
==Ryu Software Defined Networking==
Fedora 20 features Ryu, software that enables effective, software defined networking for OpenStack virtualization. As a building block of an OpenFlow controller, Ryu provides a Layer 2 isolated network for Openstack. For more information, read:


The oVirt Engine provides a browser accessible management console for creating, provisioning, and using virtual machines. It also provides facilities for managing the networking and storage needs of the virtualized environment. For users who want to experience the management console but do not have a spare machine to act as a virtualization host an 'all in one' plugin is provided. The 'all in one' plugin allows a system to act as both the oVirt Engine and as a virtualization host.
* http://osrg.github.com/ryu/
* https://github.com/osrg/ryu/wiki
* http://osrg.github.com/ryu/doc/index.html


To install the oVirt Engine:


* Log in to the Fedora system on which you wish to host oVirt Engine as the '''root''' user.
* Install the ''ovirt-engine'' package, and all of the packages it depends on, using '''yum'''.
    # yum install ovirt-engine
* Run the '''engine-setup''' script and follow the prompts to complete installation of oVirt Engine.
    # engine-setup
* Once the Engine has been installed successfully the script will provide instructions for accessing the web Administration Portal.
To install the oVirt Engine (including the 'all in one' plugin):
* Log in to the Fedora system on which you wish to host oVirt Engine as the '''root''' user.
* Install the ''ovirt-engine'' package, and all of the packages it depends on, using '''yum'''.
    # yum ovirt-engine-setup-plugin-allinone
* Run the '''engine-setup''' script and follow the prompts to complete installation of oVirt Engine.
    # engine-setup
* Once the Engine has been installed successfully the script will provide instructions for accessing the web Administration Portal.
== Virtualization Host Installation ==
For each system you wish to use as a virtualization host:
* Install Fedora 18. A minimal installation is sufficient. Ensure that you set password for the '''root''' user and that SSH is enabled.
* Log in to your oVirt Engine installation using your web browser.
* Select "Add" from the '''Hosts''' tab.
* Enter a name for the Fedora host.
* Provide the hostname or IP address and root password for the Fedora host
* Click '''OK'''.
There will be a short delay as your host downloads and installs required packages. Your Fedora host will then be added to the environment. Once you have added your first virtualization host try:
* Adding Data and ISO storage domains.
* Uploading an ISO image for an operating system.
* Creating a virtual machine!
== Additional Information ==
A Quick Start Guide for oVirt 3.1 is available at http://wiki.ovirt.org/wiki/Quick_Start_Guide.


[[Category:Docs Project]]
[[Category:Docs Project]]
[[Category:Draft documentation]]
[[Category:Draft documentation]]
[[Category:Documentation beats]]
[[Category:Documentation beats]]

Revision as of 18:55, 20 October 2013

DocsProject Header docTeam1.png
Warning.png
Beat Closed on Wiki
Work on beats has now moved to git at https://pagure.io/fedora-docs/release-notes. If you have changes or additions, please contact the docs team via #fedora-docs, docs@lists.fedoraproject.org, or with the release-notes BZ component.

Libvirt Client Access Control

The libvirt client allows for the setting of permission rules which can be applied to all managed objects and API operations, thus allowing for all client connections to be limited to a minimal set of rules and privileges. There are three levels of access which can be assigned:

  • Unauthenticated - used for all connections, this state allows all API operations that are required to complete authentication. Following a successful authentication, two more levels can be assigned:
    • Unrestricted - full access to all API operations
    • Restricted - read only access

System administrators can set permission rules for authenticated connections. Every API call in libvirt has a set of permissions that are validated against the object that is being used. For example, User A wants to change a parameter in the domain object. When the user tries to save the change, virDomainSetSchedulerParametersFlags method will check whether the client has write permissions on the domain object. Additional checks and permission settings can be processed as well. Filtering can also be done to see which clients have permissions on which objects to allow for smother administration of permissions. The libvirtd.conf configuration file is responsible for setting the access permissions. It uses the access_drivers parameter to enable this operation. Note that if more than one access driver is requested, all must succeed in order for permission to be granted. More information can be found here:

Virt-manager Snapshots

Virtual Machine Manager (virt-manager) allows for easy management and monitoring of KVM guest virtual machine snapshots. Note that virt-manager will pause the guest virtual machine for a few seconds while taking the snapshot. More information is available here:

ARM emulation on x86 Host Physical Machines

Changes have been made to have smoother emulation of ARM guest virtual machines running on x86 hosts using standard libvirt tools, including virsh, virt-manager and virt-install. qemu has an ARM emulator that works well and is actively used in the Fedora ARM effort. However libvirt and virt-manager currently have issues launching qemu-system-arm VMs, mostly by encoding x86 assumptions in the generated command line that cause qemu-system-arm to fail to start. Changes have been made to fix this issue. More information can be found here: https://fedoraproject.org/wiki/Changes/Virt_ARM_on_x86

Ryu Software Defined Networking

Fedora 20 features Ryu, software that enables effective, software defined networking for OpenStack virtualization. As a building block of an OpenFlow controller, Ryu provides a Layer 2 isolated network for Openstack. For more information, read: