Large parts of the API may only be accessible with root priviledges, +
Large parts of the API may only be accessible with root privileges, however the read only access to the xenstore data doesnot have to be forbidden to user, at least for monitoring purposes. If "virsh dominfo" fails to run as an user, change the mode of the xenstore read-only socket Index: docs/architecture.html =================================================================== RCS file: /data/cvs/libvirt/docs/architecture.html,v retrieving revision 1.43 diff -u -r1.43 architecture.html --- docs/architecture.html 17 Mar 2008 10:27:31 -0000 1.43 +++ docs/architecture.html 4 Apr 2008 06:29:35 -0000 @@ -14,7 +14,7 @@ drivers, kernels and daemons communicate though a shared system bus implemented in the hypervisor. The figure below tries to provide a view of this environment:
The library can be initialized in 2 ways depending on the level of -priviledge of the embedding program. If it runs with root access, +privilege of the embedding program. If it runs with root access, virConnectOpen() can be used, it will use three different ways to connect to the Xen infrastructure:
- a connection to the Xen Daemon though an HTTP RPC layer
- a read/write connection to the Xen Store @@ -25,7 +25,7 @@ changing the state of the system, but for performance and accuracy reasons may talk directly to the hypervisor when gathering state information at least when possible (i.e. when the running program using libvirt has root -priviledge access).
- xend_internal: implements the driver functions though the Xen
Index: docs/auth.html
===================================================================
RCS file: /data/cvs/libvirt/docs/auth.html,v
retrieving revision 1.3
diff -u -r1.3 auth.html
--- docs/auth.html 17 Mar 2008 10:27:31 -0000 1.3
+++ docs/auth.html 4 Apr 2008 06:29:36 -0000
@@ -3,7 +3,7 @@
Access control +available except committing to the base.Access control
When connecting to libvirt, some connections may require client authentication before allowing use of the APIs. The set of possible -authentication mechanisms is administrator controlled, independant +authentication mechanisms is administrator controlled, independent of applications using libvirt.
- Server configuration
- UNIX socket permissions/group @@ -44,7 +44,7 @@ auth, but does not require that the client application ultimately run as root. Default policy will still allow any application to connect to the RO socket.
- server: irc.oftc.net
- port: 6667 (the usual IRC port)
- channel: #virt Index: docs/downloads.html =================================================================== RCS file: /data/cvs/libvirt/docs/downloads.html,v retrieving revision 1.31 diff -u -r1.31 downloads.html --- docs/downloads.html 20 Feb 2008 15:58:06 -0000 1.31 +++ docs/downloads.html 4 Apr 2008 06:29:36 -0000 @@ -7,4 +7,4 @@ checkout the development tree with:
-The default policy can be overriden by the administrator using the PolicyKit +The default policy can be overridden by the administrator using the PolicyKit master configuration file in
/etc/PolicyKit/PolicyKit.conf. ThePolicyKit.conf(5)manual page provides details on the syntax available. The two libvirt daemon actions available are namedorg.libvirt.unix.monitor@@ -111,7 +111,7 @@ security flags: NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION|NEED_SERVER_FQDN-Next is is necessary for the adminsitrator of the Kerberos realm to issue a principle +Next is is necessary for the administrator of the Kerberos realm to issue a principle for the libvirt server. There needs to be one principle per host running the libvirt daemon. The principle should be named
libvirt/full.hostname@KERBEROS.REALM. This is typically done by running thekadmin.localcommand on the Kerberos Index: docs/bugs.html =================================================================== RCS file: /data/cvs/libvirt/docs/bugs.html,v retrieving revision 1.43 diff -u -r1.43 bugs.html --- docs/bugs.html 20 Feb 2008 15:58:06 -0000 1.43 +++ docs/bugs.html 4 Apr 2008 06:29:36 -0000 @@ -9,7 +9,7 @@ If you want to report a bug or ask for a feature, please check the existing open bugs, then if yours isn't a duplicate of an existing bug, log a new bug and attach any patch or extra data that you may have available. It is always a good idea to also to post to the mailing-list -too, so that everybody working on the project can see it, thanks !Some of the libvirt developpers may be found on IRC on the OFTC +too, so that everybody working on the project can see it, thanks !
Some of the libvirt developers may be found on IRC on the OFTC network. Use the settings:
cvs -d :pserver:anoncvs@libvirt.org:2401/data/cvs co libvirtUse ./autogen.sh to configure the local checkout, then
makeandmake install, as usual. All normal cvs commands are now -available except commiting to the base.main menu
related links
Graphics and design by Diana Fong
main menu
related links
Graphics and design by Diana Fong
If it runs without root access virConnectOpenReadOnly() should be used to +privilege access).
If it runs without root access virConnectOpenReadOnly() should be used to connect to initialize the library. It will then fork a libvirt_proxy program running as root and providing read_only access to the API, this is then only useful for reporting and monitoring.
Libvirt QEmu and KVM support
The model for QEmu and KVM is completely similar, basically KVM is based @@ -36,14 +36,14 @@ protocol to the library, and connects to the console of the QEmu process in order to control and report on its status. Libvirt tries to expose all the emulations models of QEmu, the selection is done when creating the new -domain, by specifying the architecture and machine type targetted.
The code controlling the QEmu process is available in the +domain, by specifying the architecture and machine type targeted.
The code controlling the QEmu process is available in the
qemud/ directory.
the driver based architecture
As the previous section explains, libvirt can communicate using different channels with the current hypervisor, and should also be able to use different kind of hypervisor. To simplify the internal design, code, ease maintenance and simplify the support of other virtualization engine the internals have been structured as one core component, the libvirt.c module acting as a front-end for the library API and a set of hypervisor drivers -defining a common set of routines. That way the Xen Daemon accces, the Xen +defining a common set of routines. That way the Xen Daemon access, the Xen Store one, the Hypervisor hypercall are all isolated in separate C modules implementing at least a subset of the common operations defined by the drivers present in driver.h:
