[Libvir] Request for minimum memory level of dom0 (xen)
by Jan Michael
Hi LibVirt-Mailreaders,
Is it possible to provide information about the minimum memory level of
domain 0 (xen)?
The value is located in the xen deamon config file as "dom0-min-mem".
I would like to calculate on the basis of this value if there is enough
memory left to create additional domains.
Thanks in advance,
Jan Michael
17 years
[Libvir] The fist problem to compile libvirt in a Debian etch.
by Marco Sinhoreli
Hello list,
I'm writing a how-to about libvirt compilation in Debian Etch. Well, I tried
to compile version 0.1.11 in a Debian etch completly newly built from
debootstrap. These are the steps that I took:
----- init commands
apt-get install make gcc
# cd /usr/src && wget
http://libvirt.org/sources/libvirt-cvs-snapshot.tar.gz&& tar -xzvf
libvirt-cvs-snapshot.tar.gz
# cd libvirt-0.1.11
# ./configure
checking build system type... i686-pc-linux-gnulibc1
checking host system type... i686-pc-linux-gnulibc1
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C
compiler cannot create executables
See `config.log' for more details.
# tail config.log
#define PACKAGE "libvirt"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME ""
#define PACKAGE_STRING ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define VERSION "0.1.11"
configure: exit 77
----- finish commands
I don't know what's the problem. Ideas please...
thanks
--
Marco Sinhoreli
17 years
Re: [Libvir] The fist problem to compile libvirt in a Debian etch.
by Marco Sinhoreli
Hello list,
I changed the libvirt version and now I'm a one step forward ;-)
So, I installed these debian packages and I runned the commands above:
------
# apt-get install gcc make g++ autogen gettext autoconf automake
libncurses5-dev libxml2 libxml2-dev libreadline5-dev
# cd /usr/src
# wget http://libvirt.org/sources/libvirt-0.2.2.tar.gz
# tar -xzvf libvirt-0.2.2.tar.gz && cd libvirt-0.2.2
# ./configure -with-libxml=/usr
# make
In this step the make command retur a error:
[...]
gcc -g -O2 -o .libs/virsh virsh-virsh.o virsh-console.o ./.libs/libvirt.so
-L/usr/lib /usr/lib/libxml2.so -lcurses -lreadline -Wl,--rpath
-Wl,/usr/local/lib
virsh-virsh.o: In function `cmdVcpuinfo':
/usr/src/libvirt-0.2.2/src/virsh.c:1230: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1294: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1294: undefined reference to
`__stack_chk_fail'
virsh-virsh.o: In function `cmdDominfo':
/usr/src/libvirt-0.2.2/src/virsh.c:1153: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1211: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1211: undefined reference to
`__stack_chk_fail'
virsh-virsh.o: In function `cmdNetworkUuid':
/usr/src/libvirt-0.2.2/src/virsh.c:2227: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:2244: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:2244: undefined reference to
`__stack_chk_fail'
virsh-virsh.o: In function `cmdNetworkDefine':
/usr/src/libvirt-0.2.2/src/virsh.c:1854: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1890: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1890: undefined reference to
`__stack_chk_fail'
virsh-virsh.o: In function `cmdNetworkCreate':
/usr/src/libvirt-0.2.2/src/virsh.c:1798: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1834: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1834: undefined reference to
`__stack_chk_fail'
virsh-virsh.o: In function `cmdDomuuid':
/usr/src/libvirt-0.2.2/src/virsh.c:1712: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1728: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1728: undefined reference to
`__stack_chk_fail'
virsh-virsh.o: In function `cmdNodeinfo':
/usr/src/libvirt-0.2.2/src/virsh.c:1542: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1562: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1562: undefined reference to
`__stack_chk_fail'
virsh-virsh.o: In function `cmdDefine':
/usr/src/libvirt-0.2.2/src/virsh.c:733: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:769: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:769: undefined reference to
`__stack_chk_fail'
virsh-virsh.o: In function `cmdCreate':
/usr/src/libvirt-0.2.2/src/virsh.c:678: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:714: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:714: undefined reference to
`__stack_chk_fail'
virsh-virsh.o: In function `vshCmddefHelp':
/usr/src/libvirt-0.2.2/src/virsh.c:2563: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:2609: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:2609: undefined reference to
`__stack_chk_fail'
virsh-virsh.o: In function `cmdVcpupin':
/usr/src/libvirt-0.2.2/src/virsh.c:1315: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1384: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/virsh.c:1384: undefined reference to
`__stack_chk_fail'
virsh-console.o: In function `vshRunConsole':
/usr/src/libvirt-0.2.2/src/console.c:45: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/console.c:179: undefined reference to
`__stack_chk_guard'
/usr/src/libvirt-0.2.2/src/console.c:179: undefined reference to
`__stack_chk_fail'
./.libs/libvirt.so: undefined reference to `__stack_chk_fail_local'
collect2: ld returned 1 exit status
make[2]: ** [virsh] Erro 1
make[2]: Saindo do diretório `/usr/src/libvirt-0.2.2/src'
make[1]: ** [all-recursive] Erro 1
make[1]: Saindo do diretório `/usr/src/libvirt-0.2.2'
make: ** [all] Erro 2
#
-------------------------
I don't know why this error. Ideas?
regards,
Marco Sinhoreli
17 years
[Libvir] build problems with latest cvs version
by Jan Michael
Hi libvirt-list,
I run into the same build problem with version libvirt version 0.2.1,
0.2.2 and the latest cvs-version.
In libvirt directory I did the following (for cvs version)
./autogen.sh --disable-shared --disable-QEMU
I'd like to disable shared libraries and QEMU support (I have only
installed xen 3.0.3 envrionment).
The make process breaks while building in [/opt/test/libvirt/qemud],
while doing the following:
<make output>
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/libxml2 -I../
include -I../include -I/usr/include/libxml2 -Wp,-D_FORTIFY_SOURCE=2 -
fexceptions -fasynchronous-unwind-tables -Wall -Wmissing-prototypes -
Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-
strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-
decls -Wno-sign-compare -DLOCAL_STATE_DIR="\"/usr/local/var\"" -
DSYSCONF_DIR="\"/usr/local/etc\"" -DQEMUD_PID_FILE="\"/usr/local/var/
run/libvirt_qemud.pid\"" -g -O2 -MT libvirt_qemud-bridge.o -MD -MP -
MF ".deps/libvirt_qemud-bridge.Tpo" -c -o libvirt_qemud-bridge.o
`test -f 'bridge.c' || echo './'`bridge.c; \
then mv -f ".deps/libvirt_qemud-bridge.Tpo" ".deps/libvirt_qemud-
bridge.Po"; else rm -f ".deps/libvirt_qemud-bridge.Tpo"; exit 1; fi
bridge.c: In function `brAddBridge':
bridge.c:130: error: `SIOCBRADDBR' undeclared (first use in this
function)
bridge.c:130: error: (Each undeclared identifier is reported only once
bridge.c:130: error: for each function it appears in.)
bridge.c: In function `brDeleteBridge':
bridge.c:148: error: `SIOCBRDELBR' undeclared (first use in this
function)
bridge.c: In function `brAddInterface':
bridge.c:182: error: `SIOCBRADDIF' undeclared (first use in this
function)
bridge.c: In function `brDeleteInterface':
bridge.c:190: error: `SIOCBRDELIF' undeclared (first use in this
function)
bridge.c: In function `brSetForwardDelay':
bridge.c:481: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in
this function)
bridge.c:481: error: syntax error before string constant
bridge.c:481: warning: empty body in an if-statement
bridge.c: In function `brGetForwardDelay':
bridge.c:503: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in
this function)
bridge.c:503: error: syntax error before string constant
bridge.c:503: warning: empty body in an if-statement
bridge.c: In function `brSetEnableSTP':
bridge.c:531: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in
this function)
bridge.c:531: error: syntax error before string constant
bridge.c:531: warning: empty body in an if-statement
bridge.c: In function `brGetEnableSTP':
bridge.c:553: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in
this function)
bridge.c:553: error: syntax error before string constant
bridge.c:553: warning: empty body in an if-statement
</make output>
I get the same even on the older versions 0.2.2 and 0.2.1. Can you
please help me to solve this compilation error?
Many thanks in advance,
Jan Michael
17 years
[Libvir] PATCH: Remove duplicate graphics for HVM on 3.0.5
by Daniel P. Berrange
In the Xen 3.0.5 series, the HVM graphics config was moved to use the same
syntax as Paravirt (ie the pvfb devices). I previously added support for
this, but didn't realize that the old syntax was kept as back-compat when
doing 'xm list --long' or equiv. So we're ending up with 2 <graphics>
elements with the same information. This patch makes us ignore the old
style config if running on new XenD.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
17 years
[Libvir] PATCH: Disable xm_internal.c on newer XenD
by Daniel P. Berrange
The xm_internal.c driver (that processes /etc/xen config files) is only ever
intended to be used on XenD <= 3.0.3 There are impls of all the methods in
xend_internal.c that take priority on newer XenD, since the xend driver is
before it in the stack. The only flaw is that upon failure of one of the
xend method libvirt will carry on & invoke the xm_internal driver method.
The attached patch addresses this by completely disabling the xm_internal
driver on XenD >= 3.0.4
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
17 years
[Libvir] PATCH: Use --strict-order with dnsmasq
by Daniel P. Berrange
A bug reported by David Lutterkort...
The 'man resolv.conf' docs for 'nameserver' say
[quote]
nameserver Name server IP address
Internet address (in dot notation) of a name server that the
resolver should query. Up to MAXNS (currently 3, see <resolv.h>)
name servers may be listed, one per keyword. If there are multi-
ple servers, the resolver library queries them in the order
listed. If no nameserver entries are present, the default is to
use the name server on the local machine. (The algorithm used is
to try a name server, and if the query times out, try the next,
until out of name servers, then repeat trying all the name
servers until a maximum number of retries are made.)
[/quote]
While 'man dnsmasq' docs for 'strict-order' say:
[quote]
-o, --strict-order
By default, dnsmasq will send queries to any of the upstream
servers it knows about and tries to favour servers to are known
to be up. Setting this flag forces dnsmasq to try each query with
each server strictly in the order they appear in /etc/resolv.conf
[/quote]
So by default, the algorithm dnsmasq uses for DNS lookups is
a) Different from that use by GLibC
b) Wrong
Thus I think we should always use --strict-order when running dnsmasq. The
attached patch adds this
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
17 years
[Libvir] [PATCH] Allow network drivers to decline to take a connection
by Richard W.M. Jones
A couple of problems fixed in the attached patch.
Firstly the path used to connect to the network driver in non-root mode
was wrong. This may have affected you if you tried to use the
test:///default driver as non-root. I haven't tested this fully, but in
any case the path is obviously wrong and needs to be fixed.
Secondly remote introduces its own network driver, and so we now need to
allow network drivers to decline to take a connection (currently they
either succeed or give an error - meaning in effect that there can only
be one network driver). The first part of the attached patch allows this.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
17 years
[Libvir] [PATCH] Synchronous daemon restart
by Mark McLoughlin
Hey,
See:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238492
Basically, doing a "service libvirtd restart", you see:
libvirt-qemud: Failed to autostart network 'default': cannot create bridge 'virbr0' : File exists
and the default network is broken.
The problem turns out to be that the initscript doesn't wait before the
old daemon has shut down before starting the new one.
The fix is simple - if you don't pass a kill level argument to
killproc(), then it will block for a few seconds until the daemon has
shutdown before killing it with a SIGKILL.
Cheers,
Mark.
Index: qemud/libvirtd.in
===================================================================
RCS file: /data/cvs/libvirt/qemud/libvirtd.in,v
retrieving revision 1.1
diff -u -p -r1.1 libvirtd.in
--- qemud/libvirtd.in 23 Feb 2007 12:50:58 -0000 1.1
+++ qemud/libvirtd.in 2 May 2007 16:47:18 -0000
@@ -34,7 +34,7 @@ start() {
stop() {
echo -n $"Stopping $SERVICE daemon: "
- killproc $PROCESS -TERM
+ killproc $PROCESS
RETVAL=$?
echo
if [ $RETVAL -eq 0 ]; then
17 years
[Libvir] [PATCH] Don't throw away errors in virConnectOpen (at least not so often)
by Richard W.M. Jones
Error messages, I like them. I don't like them to be thrown away.
A nice feature of virterror is that it'll throw away errors under the
following conditions:
(1) You are in virConnectOpen, and
(2) You pass a non-NULL virConnectPtr to __virRaiseError.
libvirt has a lot of errors which meet those conditions - the attached
patch fixes the ones I could find.
It also fixes qemuOpenConnection so that it doesn't try to open a Unix
socket with random stack data.
It also adds error messages in some useful places where previously there
was an error, but no message.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
17 years