Documentation Virtualization Beat

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Libvirt Client Access Control)
(Libvirt Client Access Control)
Line 6: Line 6:
 
There are three levels of access which can be assigned:
 
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:
+
* 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  
+
** Unrestricted - full access to all API operations  
** Restricted - read only access  
+
** 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 user has the write permission on the domain object instance passed in as a parameter. 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.  
 
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 user has the write permission on the domain object instance passed in as a parameter. 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.  
Line 14: Line 14:
 
More information can be found here:
 
More information can be found here:
  
* https://fedoraproject.org/wiki/Changes/Virt_ACLs
+
* https://fedoraproject.org/wiki/Changes/Virt_ACLs
* http://libvirt.org/acl.html
+
* http://libvirt.org/acl.html
  
 
==Virt-manager Snapshots==  
 
==Virt-manager Snapshots==  

Revision as of 14:09, 8 October 2013

DocsProject Header docTeam1.png


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 user has the write permission on the domain object instance passed in as a parameter. 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:

* 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

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