diff --git a/ChangeLog b/ChangeLog
index dc581bc278..b359a6bb9a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+Wed Aug 16 19:07:52 CEST 2006 Daniel Veillard Letter A:
+VIR_CPU_MAPLEN
VIR_CPU_USABLE
VIR_UNUSE_CPU
VIR_USE_CPU
@@ -15,7 +16,8 @@
virConnectOpenReadOnly
Letter B:
-Letter C:
+Letter C:
+VIR_UNUSE_CPU
VIR_USE_CPU
_virDomainInfo
_virNodeInfo
@@ -26,9 +28,11 @@
virDomainPinVcpu
virDomainSuspend
-
+
+VIR_NODEINFO_MAXCPUS
_virDomainInfo
_virNodeInfo
+cpu
cpumap
virDomainGetVcpus
virDomainPinVcpu
@@ -105,6 +109,7 @@
Letter T:
+VIR_CPU_MAPLEN
VIR_CPU_USABLE
VIR_GET_CPUMAP
VIR_NODEINFO_MAXCPUS
@@ -176,7 +181,8 @@
virDomainShutdown
-
+
+virDomainDestroy
virDomainGetVcpus
virDomainGetInfo
diff --git a/docs/APIchunk1.html b/docs/APIchunk1.html
index 6e1a83abc3..223c183ce1 100644
--- a/docs/APIchunk1.html
+++ b/docs/APIchunk1.html
@@ -18,6 +18,7 @@
virErrorFunc
virResetError
+
VIR_USE_CPU
cpumap
@@ -33,7 +34,8 @@
virDomainUndefine
virGetLastError
-
+
+cpumap
cpumaps
maplen
virDomainGetUUID
@@ -86,7 +88,9 @@
+
+VIR_CPU_MAPLEN
VIR_CPU_USABLE
VIR_GET_CPUMAP
VIR_UNUSE_CPU
diff --git a/docs/APIchunk2.html b/docs/APIchunk2.html
index 5a1e5f6e7f..2cd8b3c0d3 100644
--- a/docs/APIchunk2.html
+++ b/docs/APIchunk2.html
@@ -79,7 +79,8 @@
virDomainGetXMLDesc
-
+
+maplen
virCopyLastError
virDomainSuspend
@@ -111,6 +112,7 @@
virDomainLookupByUUIDString
Letter m:
+VIR_CPU_MAPLEN
VIR_CPU_USABLE
VIR_GET_CPUMAP
VIR_NODEINFO_MAXCPUS
@@ -119,7 +121,8 @@
virGetVersion
-
+
+cpumap
virDomainGetVcpus
virDomainPinVcpu
diff --git a/docs/APIchunk3.html b/docs/APIchunk3.html
index 5d9ea8f879..ac1dbbe934 100644
--- a/docs/APIchunk3.html
+++ b/docs/APIchunk3.html
@@ -66,7 +66,8 @@
virDomainSave
-
+
+cpu
virDomainGetMaxMemory
virDomainSetMaxMemory
virDomainSetMemory
@@ -119,6 +120,7 @@
virDomainShutdown
+
virDomainDestroy
virDomainPinVcpu
@@ -150,7 +152,8 @@
virDomainGetXMLDesc
virDomainPinVcpu
virGetVersion
-
+
+VIR_CPU_USABLE
VIR_GET_CPUMAP
virConnectGetVersion
@@ -188,6 +191,7 @@
+
virConnectListDefinedDomains
virConnectListDomains
@@ -213,7 +217,8 @@
virDomainShutdown
-
+
+virConnectListDefinedDomains
virConnectListDomains
virConnectOpen
virDomainGetVcpus
diff --git a/docs/APIfiles.html b/docs/APIfiles.html
index 57bad96397..5b6c892f72 100644
--- a/docs/APIfiles.html
+++ b/docs/APIfiles.html
@@ -112,6 +112,7 @@
VIR_ERR_NO_XEN
VIR_ERR_NO_XENSTORE
VIR_ERR_OK
+VIR_ERR_OPERATION_DENIED
VIR_ERR_OPERATION_FAILED
VIR_ERR_OS_TYPE
VIR_ERR_POST_FAILED
diff --git a/docs/APIsymbols.html b/docs/APIsymbols.html
index b8642546f5..5f32e8e512 100644
--- a/docs/APIsymbols.html
+++ b/docs/APIsymbols.html
@@ -44,6 +44,7 @@
VIR_ERR_NO_XEN
VIR_ERR_NO_XENSTORE
VIR_ERR_OK
+VIR_ERR_OPERATION_DENIED
VIR_ERR_OPERATION_FAILED
VIR_ERR_OS_TYPE
VIR_ERR_POST_FAILED
diff --git a/docs/devhelp/libvirt-libvirt.html b/docs/devhelp/libvirt-libvirt.html
index b17c5c7c1a..5396234f2c 100644
--- a/docs/devhelp/libvirt-libvirt.html
+++ b/docs/devhelp/libvirt-libvirt.html
@@ -41,7 +41,7 @@
#define VIR_NODEINFO_MAXCPUS(nodeinfo);
#define LIBVIR_VERSION_NUMBER;
#define VIR_USE_CPU(cpumap, cpu);
-#define VIR_CPU_MAPLEN;
+#define VIR_CPU_MAPLEN(cpu);
#define VIR_CPU_USABLE(cpumaps, maplen, vcpu, cpu);
#define VIR_COPY_CPUMAP(cpumaps, maplen, vcpu, cpumap);
#define VIR_GET_CPUMAP(cpumaps, maplen, vcpu);
@@ -119,8 +119,8 @@ const char * virDomainGetName (VIR_COPY_CPUMAP macro extract the cpumap of the specified vcpu from cpumaps array and copy it into cpumap to be used later by virDomainPinVcpu() API.
cpumaps: | pointer to an array of cpumap (in 8-bit bytes) (IN) |
maplen: | the length (in bytes) of one cpumap |
vcpu: | the virtual CPU number |
cpumap: | pointer to a cpumap (in 8-bit bytes) (OUT) This cpumap must be previously allocated by the caller (ie: malloc(maplen)) |
#define VIR_CPU_MAPLEN; -+
#define VIR_CPU_MAPLEN(cpu); +
This macro is to be used in conjonction with virDomainPinVcpu() API. It returns the length (in bytes) required to store the complete CPU map between a single virtual & all physical CPUs of a domain.
cpu: | number of physical CPUs |
#define VIR_CPU_USABLE(cpumaps, maplen, vcpu, cpu); diff --git a/docs/devhelp/libvirt-virterror.html b/docs/devhelp/libvirt-virterror.html index d775372311..08719e49bd 100644 --- a/docs/devhelp/libvirt-virterror.html +++ b/docs/devhelp/libvirt-virterror.html @@ -129,7 +129,8 @@ void virConnResetLastError (VIR_ERR_DRIVER_FULL = 25 /* too many drivers registered */ VIR_ERR_CALL_FAILED = 26 /* not supported by the drivers */ VIR_ERR_XML_ERROR = 27 /* an XML description is not well formed or broken */ - VIR_ERR_DOM_EXIST = 28 /* the domain already exist */ + VIR_ERR_DOM_EXIST = 28 /* the domain already exist */ + VIR_ERR_OPERATION_DENIED = 29 /* operation forbidden on read-only connections */ };
disk
, interface
- and console
descriptions in no special orderdisk
, interface
and
+ console
descriptions in no special orderThe format of the devices and their type may grow over time, but the -following should be sufficient for basic use:
A disk
device indicates a block device, it can have two values for the
-type attribute either 'file' or 'block' corresponding to the 2 options
-availble at the Xen layer. It has two mandatory children, and one optional
-one in no specific order:
A disk
device indicates a block device, it can have two
+values for the type attribute either 'file' or 'block' corresponding to the 2
+options availble at the Xen layer. It has two mandatory children, and one
+optional one in no specific order:
An interface
element describes a network device mapped on the guest, it
-also has a type whose value is currently 'bridge', it also have a number of
-children in no specific order:
An interface
element describes a network device mapped on the
+guest, it also has a type whose value is currently 'bridge', it also have a
+number of children in no specific order:
A console
element describes a serial console connection to the
-guest. It has no children, and a single attribute tty
which provides
-the path to the Pseudo TTY on which the guest console can be accessed
-
Life cycle actions for the domain can also be expressed in the XML format, +
A console
element describes a serial console connection to
+the guest. It has no children, and a single attribute tty
which
+provides the path to the Pseudo TTY on which the guest console can be
+accessed
Life cycle actions for the domain can also be expressed in the XML format, they drive what should be happening if the domain crashes, is rebooted or is poweroff. There is various actions possible when this happen:
<domain type='xen' id='3'>
</disk>
<graphics type='vnc' port='5904'/>
</devices>
-</domain>
There is a few things to notice specifically for HVM domains:
<features>
block is used to enable certain
- guest CPU / system features. For HVM guests the following features are defined:
+</domain>There is a few things to notice specifically for HVM domains:
<features>
block is used to enable
+ certain guest CPU / system features. For HVM guests the following
+ features are defined:
pae
- enable PAE memory addressingapic
- enable IO APICacpi
- enable ACPI biosapic
- enable IO APICacpi
- enable ACPI bios<os>
block description is very different, first it indicates
- that the type is 'hvm' for hardware virtualization, then instead of a
- kernel, boot and command line arguments, it points to an os boot loader
- which will extract the boot informations from the boot device specified
- in a separate boot element. The dev
attribute on the boot
- tag can be one of:
+ <os>
block description is very different, first
+ it indicates that the type is 'hvm' for hardware virtualization, then
+ instead of a kernel, boot and command line arguments, it points to an os
+ boot loader which will extract the boot informations from the boot device
+ specified in a separate boot element. The dev
attribute on
+ the boot
tag can be one of:
fd
- boot from first floppy devicehd
- boot from first harddisk devicecdrom
- boot from first cdrom devicehd
- boot from first harddisk devicecdrom
- boot from first cdrom device<devices>
section includes an emulator entry pointing to an
- additional program in charge of emulating the devices<devices>
section includes an emulator entry
+ pointing to an additional program in charge of emulating the deviceshda
-hdd
, or a floppy device fda
,
- fdb
. The <disk>
element also supports a 'device'
- attribute to indicate what kinda of hardware to emulate. The following values are
- supported:
+ supported is dependant on the Hypervisor, but for Xen it can be any IDE
+ device hda
-hdd
, or a floppy device
+ fda
, fdb
. The <disk>
element
+ also supports a 'device' attribute to indicate what kinda of hardware to
+ emulate. The following values are supported:
floppy
- a floppy disk controllerdisk
- a generic hard drive (the default it omitted)cdrom
- a CDROM devicedisk
- a generic hard drive (the default it
+ omitted)cdrom
- a CDROM devicehdc
channel, while for 3.0.3 and later, it can be emulated on
- any IDE channel.<devices>
section also include at least one entry for the
- graphic device used to render the os. Currently there is just 2 types
- possible 'vnc' or 'sdl'. If the type is 'vnc', then an additional port
- attribute will be present indicating the TCP port on which the VNC server is
- accepting client connections.hdc
channel, while for 3.0.3 and later, it can be emulated
+ on any IDE channel.<devices>
section also include at least one
+ entry for the graphic device used to render the os. Currently there is
+ just 2 types possible 'vnc' or 'sdl'. If the type is 'vnc', then an
+ additional port
attribute will be present indicating the TCP
+ port on which the VNC server is accepting client connections.It is likely that the HVM description gets additional optional elements and attributes as the support for fully virtualized domain expands, especially for the variety of devices emulated and the graphic support diff --git a/docs/html/libvirt-libvirt.html b/docs/html/libvirt-libvirt.html index b4a806c32a..84f84ca3e0 100644 --- a/docs/html/libvirt-libvirt.html +++ b/docs/html/libvirt-libvirt.html @@ -62,7 +62,7 @@ The content of this structure is not made public by the API.
#define LIBVIR_VERSION_NUMBER
Macro providing the version of the library as version * 1,000,000 + minor * 1000 + micro
#define VIR_COPY_CPUMAP
This macro is to be used in conjonction with virDomainGetVcpus() and virDomainPinVcpu() APIs. VIR_COPY_CPUMAP macro extract the cpumap of the specified vcpu from cpumaps array and copy it into cpumap to be used later by virDomainPinVcpu() API.
-#define VIR_CPU_MAPLEN+
#define VIR_CPU_MAPLEN
This macro is to be used in conjonction with virDomainPinVcpu() API. It returns the length (in bytes) required to store the complete CPU map between a single virtual & all physical CPUs of a domain.
#define VIR_CPU_USABLE
This macro is to be used in conjonction with virDomainGetVcpus() API. VIR_CPU_USABLE macro returns a non zero value (true) if the cpu is usable by the vcpu, and 0 otherwise.
#define VIR_GET_CPUMAP
This macro is to be used in conjonction with virDomainGetVcpus() and virDomainPinVcpu() APIs. VIR_GET_CPUMAP macro returns a pointer to the cpumap of the specified vcpu from cpumaps array.
#define VIR_NODEINFO_MAXCPUS
This macro is to calculate the total number of CPUs supported but not neccessarily active in the host.
diff --git a/docs/html/libvirt-virterror.html b/docs/html/libvirt-virterror.html index b5df81041d..8fe8908de8 100644 --- a/docs/html/libvirt-virterror.html +++ b/docs/html/libvirt-virterror.html @@ -77,6 +77,7 @@ void virErrorFunc (void * userData,int virConnCopyLastError (virConnectPtr conn,
virErrorPtr to)
Copy the content of the last error caught on that connection One will need to free the result with virResetError()
diff --git a/docs/libvir.html b/docs/libvir.html index d7bedafd2d..84a5d17bbd 100644 --- a/docs/libvir.html +++ b/docs/libvir.html @@ -33,12 +33,31 @@ development of libvirt, it is preferable when possible to just use the CVS version or snapshot, contact the mailing list and check the ChangeLog to gauge progresses. +disk
, interface
- and console
descriptions in no special orderdisk
, interface
and
+ console
descriptions in no special orderThe format of the devices and their type may grow over time, but the following should be sufficient for basic use:
-A disk
device indicates a block device, it can have two values for the
-type attribute either 'file' or 'block' corresponding to the 2 options
-availble at the Xen layer. It has two mandatory children, and one optional
-one in no specific order:
A disk
device indicates a block device, it can have two
+values for the type attribute either 'file' or 'block' corresponding to the 2
+options availble at the Xen layer. It has two mandatory children, and one
+optional one in no specific order:
An interface
element describes a network device mapped on the guest, it
-also has a type whose value is currently 'bridge', it also have a number of
-children in no specific order:
An interface
element describes a network device mapped on the
+guest, it also has a type whose value is currently 'bridge', it also have a
+number of children in no specific order:
A console
element describes a serial console connection to the
-guest. It has no children, and a single attribute tty
which provides
-the path to the Pseudo TTY on which the guest console can be accessed
-
A console
element describes a serial console connection to
+the guest. It has no children, and a single attribute tty
which
+provides the path to the Pseudo TTY on which the guest console can be
+accessed
Life cycle actions for the domain can also be expressed in the XML format, they drive what should be happening if the domain crashes, is rebooted or is @@ -461,48 +480,50 @@ systems:
There is a few things to notice specifically for HVM domains:
<features>
block is used to enable certain
- guest CPU / system features. For HVM guests the following features are defined:
+ <features>
block is used to enable
+ certain guest CPU / system features. For HVM guests the following
+ features are defined:
pae
- enable PAE memory addressingapic
- enable IO APICacpi
- enable ACPI biospae
- enable PAE memory addressingapic
- enable IO APICacpi
- enable ACPI bios<os>
block description is very different, first it indicates
- that the type is 'hvm' for hardware virtualization, then instead of a
- kernel, boot and command line arguments, it points to an os boot loader
- which will extract the boot informations from the boot device specified
- in a separate boot element. The dev
attribute on the boot
- tag can be one of:
+ <os>
block description is very different, first
+ it indicates that the type is 'hvm' for hardware virtualization, then
+ instead of a kernel, boot and command line arguments, it points to an os
+ boot loader which will extract the boot informations from the boot device
+ specified in a separate boot element. The dev
attribute on
+ the boot
tag can be one of:
fd
- boot from first floppy devicehd
- boot from first harddisk devicecdrom
- boot from first cdrom devicefd
- boot from first floppy devicehd
- boot from first harddisk devicecdrom
- boot from first cdrom device<devices>
section includes an emulator entry pointing to an
- additional program in charge of emulating the devices<devices>
section includes an emulator entry
+ pointing to an additional program in charge of emulating the deviceshda
-hdd
, or a floppy device fda
,
- fdb
. The <disk>
element also supports a 'device'
- attribute to indicate what kinda of hardware to emulate. The following values are
- supported:
+ supported is dependant on the Hypervisor, but for Xen it can be any IDE
+ device hda
-hdd
, or a floppy device
+ fda
, fdb
. The <disk>
element
+ also supports a 'device' attribute to indicate what kinda of hardware to
+ emulate. The following values are supported:
floppy
- a floppy disk controllerdisk
- a generic hard drive (the default it omitted)cdrom
- a CDROM devicefloppy
- a floppy disk controllerdisk
- a generic hard drive (the default it
+ omitted)cdrom
- a CDROM devicehdc
channel, while for 3.0.3 and later, it can be emulated on
- any IDE channel.<devices>
section also include at least one entry for the
- graphic device used to render the os. Currently there is just 2 types
- possible 'vnc' or 'sdl'. If the type is 'vnc', then an additional port
- attribute will be present indicating the TCP port on which the VNC server is
- accepting client connections.hdc
channel, while for 3.0.3 and later, it can be emulated
+ on any IDE channel.
+ <devices>
section also include at least one
+ entry for the graphic device used to render the os. Currently there is
+ just 2 types possible 'vnc' or 'sdl'. If the type is 'vnc', then an
+ additional port
attribute will be present indicating the TCP
+ port on which the VNC server is accepting client connections.It is likely that the HVM description gets additional optional elements
diff --git a/docs/libvirt-api.xml b/docs/libvirt-api.xml
index 5d43ea3827..4674ebb8cb 100644
--- a/docs/libvirt-api.xml
+++ b/docs/libvirt-api.xml
@@ -128,6 +128,7 @@
Here is the list of official releases, however since it is early on in the
development of libvirt, it is preferable when possible to just use the CVS version or snapshot, contact the mailing list
-and check the ChangeLog to gauge progresses.Releases
0.1.3: Jul 11 2006
0.1.4: Aug 16 2006
0.1.3: Jul 11 2006