From a528e973832ac9452dd29b660f10e3f424f357db Mon Sep 17 00:00:00 2001
From: Daniel Veillard 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
diff --git a/docs/architecture.html b/docs/architecture.html
index eb587cc13b..612b2e03b8 100644
--- a/docs/architecture.html
+++ b/docs/architecture.html
@@ -14,7 +14,7 @@ supervise the control and execution of the sets of domains. The hypervisor,
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:make rpm
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.
The model for QEmu and KVM is completely similar, basically KVM is based @@ -36,14 +36,14 @@ QEmu or KVM process. That program called libvirt_qemud talks though a specific 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.
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:
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.
sudo
-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
. The
PolicyKit.conf(5)
manual page provides details on the syntax
available. The two libvirt daemon actions available are named org.libvirt.unix.monitor
@@ -111,7 +111,7 @@ Plugin "gssapiv2" [loaded], API version: 4
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 the kadmin.local
command on the Kerberos
diff --git a/docs/bugs.html b/docs/bugs.html
index 0b143273d7..d462f4396a 100644
--- a/docs/bugs.html
+++ b/docs/bugs.html
@@ -9,7 +9,7 @@ If possible generate the patches by using cvs diff -u in a CVS checkout.
W
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:
- server: irc.oftc.net
- port: 6667 (the usual IRC port)
- channel: #virt
diff --git a/docs/devhelp/libvirt-conf.html b/docs/devhelp/libvirt-conf.html
index 57fbaecc8e..e1f0c4ef29 100644
--- a/docs/devhelp/libvirt-conf.html
+++ b/docs/devhelp/libvirt-conf.html
@@ -104,7 +104,7 @@ The content of this structure is not made public by the API.
virConfReadMem ()
virConfPtr virConfReadMem (const char * memory,
int len)
Reads a configuration file loaded in memory. The string can be zero terminated in which case @len can be 0
-memory: pointer to the content of the configuration file len: lenght in byte Returns: an handle to lookup settings or NULL if it failed to parse the content, use virConfFree() to free the data.
+memory: pointer to the content of the configuration file len: length in byte Returns: an handle to lookup settings or NULL if it failed to parse the content, use virConfFree() to free the data.
int virConfWriteFile (const char * filename,
virConfPtr conf)
Writes a configuration file back to a file.
@@ -112,7 +112,7 @@ The content of this structure is not made public by the API.int virConfWriteMem (char * memory,
int * len,
virConfPtr conf)
Writes a configuration file back to a memory area. @len is an IN/OUT parameter, it indicates the size available in bytes, and on output the size required for the configuration file (even if the call fails due to insufficient space).
-memory: | pointer to the memory to store the config file |
len: | pointer to the lenght in byte of the store, on output the size |
conf: | the conf |
Returns: | the number of bytes written or -1 in case of error. |
memory: | pointer to the memory to store the config file |
len: | pointer to the length in byte of the store, on output the size |
conf: | the conf |
Returns: | the number of bytes written or -1 in case of error. |
name: | URI of the hypervisor |
auth: | Authenticate callback parameters |
flags: | Open flags |
Returns: | a pointer to the hypervisor connection or NULL in case of error URIs are documented at http://libvirt.org/uri.html |
virConnectPtr virConnectOpenReadOnly (const char * name)
-
This function should be called first to get a restricted connection to the libbrary functionalities. The set of APIs usable are then restricted on the available methods to control the domains.
+This function should be called first to get a restricted connection to the library functionalities. The set of APIs usable are then restricted on the available methods to control the domains.
name: | URI of the hypervisor |
Returns: | a pointer to the hypervisor connection or NULL in case of error URIs are documented at http://libvirt.org/uri.html |
int virDomainAttachDevice (virDomainPtr domain,
const char * xml)
@@ -745,7 +745,7 @@ The content of this structure is not made public by the API.
+virDomainGetVcpus ()
int virDomainGetVcpus (virDomainPtr domain,
virVcpuInfoPtr info,
int maxinfo,
unsigned char * cpumaps,
int maplen)
Extract information about virtual CPUs of domain, store it in info array and also in cpumaps if this pointer is'nt NULL.
-
domain: pointer to domain object, or NULL for Domain0 info: pointer to an array of virVcpuInfo structures (OUT) maxinfo: number of structures in info array cpumaps: pointer to an bit map of real CPUs for all vcpus of this domain (in 8-bit bytes) (OUT) If cpumaps is NULL, then no cupmap information is returned by the API. It's assumed there is <maxinfo> cpumap in cpumaps array. The memory allocated to cpumaps must be (maxinfo * maplen) bytes (ie: calloc(maxinfo, maplen)). One cpumap inside cpumaps has the format described in virDomainPinVcpu() API. maplen: number of bytes in one cpumap, from 1 up to size of CPU map in underlying virtualization system (Xen...). Returns: the number of info filled in case of success, -1 in case of failure.
domain: pointer to domain object, or NULL for Domain0 info: pointer to an array of virVcpuInfo structures (OUT) maxinfo: number of structures in info array cpumaps: pointer to an bit map of real CPUs for all vcpus of this domain (in 8-bit bytes) (OUT) If cpumaps is NULL, then no cpumap information is returned by the API. It's assumed there is <maxinfo> cpumap in cpumaps array. The memory allocated to cpumaps must be (maxinfo * maplen) bytes (ie: calloc(maxinfo, maplen)). One cpumap inside cpumaps has the format described in virDomainPinVcpu() API. maplen: number of bytes in one cpumap, from 1 up to size of CPU map in underlying virtualization system (Xen...). Returns: the number of info filled in case of success, -1 in case of failure.
char * virDomainGetXMLDesc (virDomainPtr domain,
int flags)
Provide an XML description of the domain. The description may be reused later to relaunch the domain with virDomainCreateLinux().
@@ -828,7 +828,7 @@ The content of this structure is not made public by the API.domain: | pointer to a defined domain |
Returns: | 0 in case of success, -1 in case of error |
int virGetVersion (unsigned long * libVer,
const char * type,
unsigned long * typeVer)
-
Provides two information back, @libVer is the version of the library while @typeVer will be the version of the hypervisor type @type against which the library was compiled. If @type is NULL, "Xen" is assumed, if @type is unknown or not availble, an error code will be returned and @typeVer will be 0.
+Provides two information back, @libVer is the version of the library while @typeVer will be the version of the hypervisor type @type against which the library was compiled. If @type is NULL, "Xen" is assumed, if @type is unknown or not available, an error code will be returned and @typeVer will be 0.
libVer: | return value for the library version (OUT) |
type: | the type of connection/driver looked at |
typeVer: | return value for the version of the hypervisor (OUT) |
Returns: | -1 in case of failure, 0 otherwise, and values for @libVer and @typeVer have the format major * 1,000,000 + minor * 1,000 + release. |
int virInitialize (void)
@@ -908,7 +908,7 @@ The content of this structure is not made public by the API.
conn: pointer to the hypervisor connection freeMems: pointer to the array of unsigned long long startCell: index of first cell to return freeMems info on. maxCells: Maximum number of cells for which freeMems information can be returned. Returns: the number of entries filled in freeMems, or -1 in case of error.
unsigned long long virNodeGetFreeMemory (virConnectPtr conn)
-
provides the free memory availble on the Node
+provides the free memory available on the Node
conn: | pointer to the hypervisor connection |
Returns: | the available free memory in kilobytes or 0 in case of error |
int virNodeGetInfo (virConnectPtr conn,
virNodeInfoPtr info)
@@ -924,11 +924,11 @@ The content of this structure is not made public by the API.
pool: pointer to storage pool flags: future flags, use 0 for now Returns: 0 on success, or -1 if it could not be started
virStoragePoolPtr virStoragePoolCreateXML (virConnectPtr conn,
const char * xmlDesc,
unsigned int flags)
-
Create a new storage based on its XML description. The pool is not persitent, so its definition will disappear when it is destroyed, or if the host is restarted
+Create a new storage based on its XML description. The pool is not persistent, so its definition will disappear when it is destroyed, or if the host is restarted
conn: | pointer to hypervisor connection |
xmlDesc: | XML description for new pool |
flags: | future flags, use 0 for now |
Returns: | a virStoragePoolPtr object, or NULL if creation failed |
virStoragePoolPtr virStoragePoolDefineXML (virConnectPtr conn,
const char * xml,
unsigned int flags)
-
Define a new inactive storage pool based on its XML description. The pool is persitent, until explicitly undefined.
+Define a new inactive storage pool based on its XML description. The pool is persistent, until explicitly undefined.
conn: | pointer to hypervisor connection |
xml: | XML description for new pool |
flags: | future flags, use 0 for now |
Returns: | a virStoragePoolPtr object, or NULL if creation failed |
int virStoragePoolDelete (virStoragePoolPtr pool,
unsigned int flags)
diff --git a/docs/errors.html b/docs/errors.html index 70c2490e81..a400589f98 100644 --- a/docs/errors.html +++ b/docs/errors.html @@ -8,7 +8,7 @@ asynchronous error reporting. When an error happens in the library code the error is logged, allowing to retrieve it later and if the user registered an error callback it will be called synchronously. Once the call to libvirt ends the error can be detected by the return value and the full information for -the last logged error can be retrieved.To avoid as much as prossible troubles with a global variable in a +the last logged error can be retrieved.
To avoid as much as possible troubles with a global variable in a multithreaded environment, libvirt will associate when possible the errors to the current connection they are related to, that way the error is stored in a dynamic structure which can be made thread specific. Error callback can be @@ -43,7 +43,7 @@ following fields:
and then extra raw information about the error which may be initialized to 0 or NULL if unused
So usually, setting up specific error handling with libvirt consist of registering an handler with with virSetErrorFunc or with virConnSetErrorFunc, -chech the value of the code value, take appropriate action, if needed let +check the value of the code value, take appropriate action, if needed let libvirt print the error on stderr by calling virDefaultErrorFunc. For asynchronous error handing, set such a function doing nothing to avoid the error being reported on stderr, and call virConnGetLastError or diff --git a/docs/format.html b/docs/format.html index af03d1c8da..3c0b04b062 100644 --- a/docs/format.html +++ b/docs/format.html @@ -45,7 +45,7 @@ significant:
<domain type='xen' id='3'> pointing to an additional program in charge of emulating the devices
hda
-hdd
, or a floppy device
fda
, fdb
. The <disk>
element
also supports a 'device' attribute to indicate what kinda of hardware to
@@ -247,7 +247,7 @@ support a variety of options:192.168.22.0/255.255.255.0
. Each guest will have an
associated tun device created with a name of vnetN, which can also be
- overriden with the <target> element. Example configs are:
+ overridden with the <target> element. Example configs are:
<interface type='network'> <source network='default'/> </interface> @@ -263,7 +263,7 @@ support a variety of options:
- Userspace SLIRP stack
Provides a bridge from the VM directly onto the LAN. This assumes there is a bridge device on the host which has one or more of the hosts physical NICs enslaved. The guest VM will have an associated tun device - created with a name of vnetN, which can also be overriden with the + created with a name of vnetN, which can also be overridden with the <target> element. The tun device will be enslaved to the bridge. The IP range / network configuration is whatever is used on the LAN. This provides the guest VM full incoming & outgoing net access just like a @@ -281,11 +281,11 @@ support a variety of options:
- Userspace SLIRP stack
- Generic connection to LAN
Provides a means for the administrator to execute an arbitrary script to connect the guest's network to the LAN. The guest will have a tun - device created with a name of vnetN, which can also be overriden with the + device created with a name of vnetN, which can also be overridden with the <target> element. After creating the tun device a shell script will be run which is expected to do whatever host network integration is required. By default this script is called /etc/qemu-ifup but can be - overriden.
+ overridden.<interface type='ethernet'/> <interface type='ethernet'> @@ -409,7 +409,7 @@ BIOS you will see<capabilities> </features> </guest> ... -</capabilities>The first block (in red) indicates the host hardware capbilities, currently +</capabilities>
The first block (in red) indicates the host hardware capabilities, currently it is limited to the CPU properties but other information may be available, it shows the CPU architecture, and the features of the chip (the feature block is similar to what you will find in a Xen fully virtualized domain diff --git a/docs/html/libvirt-conf.html b/docs/html/libvirt-conf.html index cb9d464a4c..bd3a1c8e5e 100644 --- a/docs/html/libvirt-conf.html +++ b/docs/html/libvirt-conf.html @@ -37,8 +37,8 @@ The content of this structure is not made public by the API.
Reads a configuration file.
filename: | the path to the configuration file. |
Returns: | an handle to lookup settings or NULL if it failed to read or parse the file, use virConfFree() to free the data. |
virConfPtr virConfReadMem (const char * memory,
int len)
Reads a configuration file loaded in memory. The string can be zero terminated in which case @len can be 0
-memory: | pointer to the content of the configuration file |
len: | lenght in byte |
Returns: | an handle to lookup settings or NULL if it failed to parse the content, use virConfFree() to free the data. |
int virConfWriteFile (const char * filename,
virConfPtr conf)
+
memory: pointer to the content of the configuration file len: length in byte Returns: an handle to lookup settings or NULL if it failed to parse the content, use virConfFree() to free the data. Function: virConfWriteFile
int virConfWriteFile (const char * filename,
virConfPtr conf)
Writes a configuration file back to a file.
filename: the path to the configuration file. conf: the conf Returns: the number of bytes written or -1 in case of error. Function: virConfWriteMem
int virConfWriteMem (char * memory,
int * len,
virConfPtr conf)
Writes a configuration file back to a memory area. @len is an IN/OUT parameter, it indicates the size available in bytes, and on output the size required for the configuration file (even if the call fails due to insufficient space).
-
memory: pointer to the memory to store the config file len: pointer to the lenght in byte of the store, on output the size conf: the conf Returns: the number of bytes written or -1 in case of error.
Graphics and design by Diana Fong
memory: | pointer to the memory to store the config file |
len: | pointer to the length in byte of the store, on output the size |
conf: | the conf |
Returns: | the number of bytes written or -1 in case of error. |
Graphics and design by Diana Fong