A great work !
This new help page will be very useful for all developers :-)
Thanks a lot.
P.Berthault.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
The documentation of libvirt doesn't indicate which functions are for
Xen or QEMU or both. The only way to know that, is by searching in
libvirt sources.
It would be interesting for libvirt users to add in the documentation,
for each function, a mention such as "QEMU only", "Xen(TM) only", "QE
Richard W.M. Jones a écrit :
Is "long long" part of ANSI C? I thought it was a gcc extension. I
think you should use to give you integers of fixed sizes,
which seems to be what you want.
long long integer type is part of ISO C99 and gcc is conform to C99 norm.
Regards.
--
Libvir-list mail
Daniel Veillard a écrit :
I think Xen just returns -1 when the field is uninitialized, probably
meaning 'all physical memory'. Once you use "xm mem-max 0 ..." then it
consider the Dom0 domain constrained, but not before. And since there
are machine where it's possible to hot plug new memory thi
Daniel P. Berrange a écrit :
On Fri, Jan 12, 2007 at 11:47:16AM +0100, Philippe Berthault wrote:
The maxMem field of the virDomainInfo structure is given in bytes
instead of Kbytes when the domain is 0 (Domain-0). With others domains,
the value of maxMem is correct.
Exemple with virsh
The maxMem field of the virDomainInfo structure is given in bytes
instead of Kbytes when the domain is 0 (Domain-0). With others domains,
the value of maxMem is correct.
Exemple with virsh:
On a system with 4 GB memory, virsh reports:
# virsh dominfo 0
...
Max memory: 4294967292 kB
With th
Daniel Veillard a écrit :
On Thu, Jan 11, 2007 at 11:42:31AM +0100, Philippe Berthault wrote:
Daniel Veillard a écrit :
On Thu, Jan 11, 2007 at 11:27:52AM +0100, Philippe Berthault wrote:
Daniel Veillard a écrit :
it is 0.1.8 but with 12 patches which are
Daniel Veillard a écrit :
On Thu, Jan 11, 2007 at 11:27:52AM +0100, Philippe Berthault wrote:
Daniel Veillard a écrit :
it is 0.1.8 but with 12 patches which are backport of later bug fixes or
important features like localization, shareable disk support, core dump
support,
etc
Daniel Veillard a écrit :
On Thu, Jan 11, 2007 at 10:13:34AM +0100, Philippe Berthault wrote:
Hello,
Currently, the libvirt integrated into RHEL-5 beta release is the pretty
old 0.1.8 version.
Could you confirm that in the first release candidate RHEL-5 RC1
(planned february, 28), the
Hello,
Currently, the libvirt integrated into RHEL-5 beta release is the pretty
old 0.1.8 version.
Could you confirm that in the first release candidate RHEL-5 RC1
(planned february, 28), the libvirt will be the 0.1.8 version or another
one ?
Thanks.
--
Libvir-list mailing list
Libvir-list@r
Thanks a lot for your response about virtinst library. The information
we need (hvm or not) is in the /sys/hypervisor/properties/capabilites file.
As you say "If we start adding hardware info to libvirt, where do we
draw the line ?". We are agree with this question. It wasn't a good idea
to in
Hello,
To administrate virtual machines by using livbvirt, we need to known if
the underlying hardware platform supports hvm (Intel-VT or AMD-V) or
not. Currently, this information is returned by the "xm info" command of
Xen in the "xen_caps" line but there is no equivalent in libvirt. So we
There is a conflit between libvirt 0.1.8 and the latest release 3.0.3 of
Xen. With Xen 3.0.3 release, the virsh vcpuinfo command (or
virDomainGetVcpus API) always returns the 0 as physical CPU used by any
vCPU.
Example:
#: xm vcpu-list VM1
Name ID VCPUs CPU State Time(s) CPU Affinity
VM1
In the virNodeInfo structure, it's assumed that all nodes of
multiprocessor systems have the same number of sockets. But on NUMA
machines, it's not mandatory that all SMP nodes have the same number of
sockets.
So there is a potential problem when computing the number of processors
by using th
Thanks a lot, it's now OK on my IA64 system with your CVS code. :-)
Daniel Veillard a écrit :
On Thu, Oct 12, 2006 at 04:58:16PM +0200, Philippe Berthault wrote:
The maxMem and memory fields of the virDomainInfo structure are false on
IA64 systems.
The problem
ze as 16 KB on
IA64 ?
Philippe Berthault a écrit :
The maxMem and memory fields of the virDomainInfo structure are false
on IA64 systems.
The problem is in xen_internal.c at lines 1530,1531:
info->memory = XEN_GETDOMAININFO_TOT_PAGES(dominfo) * 4;
info->maxMem = XEN_GETDOMAININFO_MAX
The maxMem and memory fields of the virDomainInfo structure are false on
IA64 systems.
The problem is in xen_internal.c at lines 1530,1531:
info->memory = XEN_GETDOMAININFO_TOT_PAGES(dominfo) * 4;
info->maxMem = XEN_GETDOMAININFO_MAX_PAGES(dominfo) * 4;
It's assumed that page size is 4 KB
In the virXen_getvcpusinfo() function of xen_internal.c source file, the
vcpu number stored in the virVcpuInfo structure is the xen domain id
instead of the vcpu id.
Here the patch of the correction.
--- libvirt-0.1.7/src/xen_internal.c2006-09-29 10:18:17.0 +0200
+++ libvirt-0.1.8/
After closing libvirt with virConnectClose, it's possible to open
libvirt again in the same program with virConnectOpen but following
operations on domains systematically fail.
In example:
conn = virConnectOpen(NULL);
dom = virDomainLookupByID(conn, id);
virDomainFree(dom);
virConnectClose(con
I think that, instead of designate the backend domain by its id, it
would be better to designate it by its name.
This is because the id isn't fix, excepted for the domain-0.
Philippe Berthault.
[EMAIL PROTECTED] a écrit :
After the new VCPU functions, we also need Virtual Block D
Daniel P. Berrange a écrit :
TODO: These vcpus functions permits to dynamically change the vcpu/cpu
relation after the domain has been started but nothing has been done
regarding static cpus attribution in the XML configuration file of a domain.
Yes there is a
ree(): invalid next size (fast): 0x08051dd8 ***
Aborted
With the domain-0, the virsh vcpuinfo is OK. I haven't investigated
with the debugger but perhaps you have an idea of what is the problem ?
Thanks,
Philippe Berthault.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
#2 and pcpu #3.
The non existent processors have their related bits set to 0 in cpumap.
To indicate the 'any' affinity, all bits in cpumap must be set before
calling the virDomainPinVcpu API.
Regards,
Philippe Berthault.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
hing has been done
regarding static cpus attribution in the XML configuration file of a domain.
Philippe Berthault.
--- libvirt-0.1.3/include/libvirt/libvirt.h 2006-07-11 18:05:07.0
+0200
+++ libvirt-0.1.3.with_vcpus/include/libvirt/libvirt.h 2006-08-02
16:42:51.0 +0200
@
In the mail I've sent (in HTML format), there was no extra '*' around
identifiers.
It's seems that your mail server doesn't accept HTML and I suspect it
has replaced all HTML tags by these '*'.
Philippe Berthault.
--
Libvir-list mailing list
Libvir-lis
Here the new virtual cpu functions proposal.
What do you think about it ?
/**
* virVcpuInfo: structure for information about a virtual CPU
in a domain.
*/
typedef enum {
VIR_VCPU_OFFLINE = 0, /* the virtual
CPU is offline */
VIR_VCPU_RUNNING = 1, /* the virtual
CPU is r
Just a C implem nitpick, but that can lead to interesting debugging
sessions (I think I got beaten by that a couple of time).
Nowhere the compiler can guess that you're accessing a 2 dimentional array
with a row of length domInfo.nrVirtCpu, it's a one dimension array so I
think cpuMaps[vcpu][b
Daniel Veillard a écrit :
On Tue, Aug 01, 2006 at 05:06:59PM +0200, Philippe Berthault wrote:
I've tried to illustrate an exemple of virDomainGetVcpus API with a 2
dimensional cpumaps array.
Hum, right, the best is probably to go down to some examples at this
us virDomainGetVcpus
API is that the cpumap parameter hasn't the same meaning in these two
APIs. This point requires to duplicate macro for bit manipulations on
these maps.
Philippe Berthault
__
virConnectPtr pC
retrieve the CPU map of one
VCPU. Such API would be:
int virDomainGetCpus(virDomainPtr domain, unsigned int vcpu, unsigned
char *cpumap, int maplen);
The name is ...GetCpus (not 'Vcpus') because this API get the physical
CPU map, not the virtual CPU map.
Regards,
Philippe Bert
Hello,
Several major modifications will appear this year in future Xen releases
(3.0.3 and 3.0.4) that may have impacts on libvirt. These modifications
(see xen roadmap edited by Ian Pratt in july 2006) are :
- Introduction of XML-RPC,
- Xen configuration files in XML format,
- Suppression of
exist in future versions of
libvirt or not ?
Thanks,
Philippe Berthault.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
The 'virterror.h' file has an #include directive to "libvirt.h" which
isn't correct
because libvirt include files are installed on a sub-directory named
'libvirt'.
i.e. when libvirt is compiled with configure --script=/usr, then libvirt
files are
installed in /usr/include/libvirt/.*
To be stan
I've written a program based on libvirt (release 0.1.0) in which I uses the
virSetErrorFunc() function to avoid messages on the screen but one message
is always displayed (on stderr) and isn't trapped by the
virSetErrorFunc() function.
This message is "Unimplemented block at xs_internal.c:255"
is yes, is it possible to introduce a global lock in Xen
(or in libvirt ?) to avoid conflict between libvirt and xm command or
between several libvirt based commands.
Thanks,
Philippe Berthault.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir
The problem comes from the xend configuration.
The HTTP interface of xend must be enabled to use libvirt.
Please adds the following line in your /etc/xen/xend-config.sxp file:
(xend-http-server yes)
and libvirt will be ok after restarting xend daemon.
Philippe Berthault.
Michel Gauthier a
36 matches
Mail list logo
