[libvirt] bug in libvirt.c?
by Evgeniy Sokolov
for (i = 0; i < virNetworkDriverTabCount; i++) {
if ((virDriverTab[i]->probe != NULL) &&
((latest = virDriverTab[i]->probe()) != NULL)) {
probes++;
.....
}
}
We use array virDriverTab, but cicle is to virNetworkDriverTabCount
which count number of virNetworkDriverTab drivers.
I think virDriverTabCount should be used.
Index: libvirt.c
===================================================================
RCS file: /data/cvs/libvirt/src/libvirt.c,v
retrieving revision 1.147
diff -u -p -r1.147 libvirt.c
--- libvirt.c 26 Jun 2008 09:37:51 -0000 1.147
+++ libvirt.c 10 Jul 2008 14:48:44 -0000
@@ -699,7 +699,7 @@ do_open (const char *name,
const char *use = NULL;
const char *latest;
int probes = 0;
- for (i = 0; i < virNetworkDriverTabCount; i++) {
+ for (i = 0; i < virDriverTabCount; i++) {
if ((virDriverTab[i]->probe != NULL) &&
((latest = virDriverTab[i]->probe()) != NULL)) {
probes++;
17 years
[libvirt] [Patch] Libvirt & Autobuild
by Mohammed Morsi
Attached is a small fix to get libvirt working w/ autobuild. Autobuild
attempts to create and test the RPM, which lists the PolicyKit as one of
the files to be installed, and thus if it is not installed, autobuild
reports an error and fails. The was to get this file installed is to
specify --with-polkit to ./autogen which I added to the autobuild.sh
build script. (also the syntax check errors broke autobuild, but these
have been fixed according to the latest email on the list). Knock on
wood, after this libvirt should work w/ autobuild and will be built
nightly, and I can finish getting oVirt working with it.
-Mo
17 years
[libvirt] [PATCH] renaming error -> openvzError
by Evgeniy Sokolov
function error() was renamed to openvzError() to don't conflict with
other functions with the same name.
other
- openvzError() is added to msg_gen_function
- fixed to pass "make syntax-check"
Thanks to Jim Meyering for review.
17 years
[libvirt] [PATCH] fix up dom-name validation
by John Levon
libvirt schema: improve domain name regex
This regexp is based upon what xend actually allows, plus the existing
&, which I presume is there for a reason.
Signed-off-by: John Levon <john.levon>
Index: docs/libvirt.rng
===================================================================
RCS file: /data/cvs/libvirt/docs/libvirt.rng,v
retrieving revision 1.8
diff -u -r1.8 libvirt.rng
--- docs/libvirt.rng 8 Jul 2008 12:05:13 -0000 1.8
+++ docs/libvirt.rng 10 Jul 2008 04:04:58 -0000
@@ -840,7 +840,7 @@
</define>
<define name='domainName'>
<data type='string'>
- <param name="pattern">[a-zA-Z0-9_\+\-&]+</param>
+ <param name="pattern">[A-Za-z0-9_.:/\+\-&-]+</param>
</data>
</define>
<define name='genericName'>
17 years
[libvirt] virDomainMemoryPeek & maximum remote message buffer size
by Richard W.M. Jones
The kernel images that I want to snoop in virt-mem are around 16 MB in
size. In the qemu / KVM case, these images have to travel over the
remote connection. Because of limits on the maximum message size,
they have to travel currently in 64 KB chunks, and it turns out that
this is slow. Apparently the dominating factors are how long it takes
to issue the 'memsave' command in the qemu monitor (there is some big
constant overhead), and extra network round trips.
The current remote message size is intentionally limited to 256KB
(fully serialized, including all XDR headers and overhead), so the
most we could practically send in a single message at the moment is
128KB if we stick to powers of two, or ~255KB if we don't.
The reason we limit it is to avoid denial of service attacks, where a
rogue client or server sends excessively large messages and causes the
peer to allocate lots of memory [eg. if we didn't have any limit, then
you could send a message which was several GB in size and cause
problems at the other end, because the message is slurped in before it
is fully parsed].
There is a second problem with reading the kernel in small chunks,
namely that this allows the virtual machine to make a lot of progress,
so we don't get anything near an 'instantaneous' snapshot (getting the
kernel in a single chunk doesn't necessarily guarantee this either,
but it's better).
As an experiment, I tried increasing the maximum message to 32 MB, so
that I could send the whole kernel in one go.
Unfortunately just increasing the limit doesn't work for two reasons,
one prosaic and one very weird:
(1) The current code likes to keep message buffers on the stack, and
because Linux limits the stack to something artificially small, this
fails. Increasing the stack ulimit is a short-term fix for this,
while testing. In the long term we could rewrite any code which does
this to use heap buffers instead.
(2) There is some really odd problem with our use of recv(2) which
causes messages > 64 KB to fail. I have no idea what is really
happening, but the sequence of events seems to be this:
server client
write(sock,buf,len) = len-k
recv(sock,buf,len) = len-k
write(sock,buf+len-k,len-k) = k
recv(sock,buf,k) = 0 [NOT k]
At this point the client assumes that the server has unexpectedly
closed the connection and fails. I have stared at this for a while,
but I've got no idea at all what's going on.
A test program is attached. You'll need a 32 bit KVM guest.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
17 years
[libvirt] Web Interface -> LibVirt Communication?
by Henri Cook
Hi,
I want to write a web tool that lets me administer my cluster from one
location (including operations that things like virt-manager don't
provide) - what's the proper way of achieving this? Can i communicate
over TCP with libvirt on each server (is this documented?) or should I
be trying to get my web app to auth and run virsh commands over SSH?
Thanks.
Henri
17 years
Re: [libvirt] libvirt-java
by Daniel Veillard
On Mon, Jul 07, 2008 at 01:14:40PM +0200, Tóth István wrote:
> Daniel Veillard wrote:
> > Ah, okay.... Well my perspective is that libvirt-java should include
> > only parts which are directly releated to using libvirt on Java. I would
> > really not try to reinvent or push any XML related APIs there, at least
> > as part of libvirt bindings (I still have the scars from libxml2, believe
> > me you don't want to push new XML APIs to programmers even specialized ones).
> >
> My thoughts exactly.
Okay seems we agree on the fundamentals :-)
> > But things like the XSD descriptiond might be useful generally, and
> > IMHO are very tied to libvirt, so i think they are a good fit.
> >
> Absolutely. I've had major problems when I tried to use some Java XML
> mapping libraries, because they can only process xsd,
> and not the language you use. So having high-quality xsd definitions is
> high on my personal wish-list.
Okay
> > Also fitting into this model are build makefiles for other environment,
> > I understand that for most Java developpers, configure and make are really
> > foreign tools, so adding ant/Eclipse/... build recipes for the package also
> > makes a lot of sense.
> >
> Well, they certainly wouldn't hurt, but I don't see that as a priority.
> Java-only programmers (end users) won't touch the JNI core parts.
> They will just install the package, and get on with using it, by adding
> the jar
> to their devel enviroment, and perhaps the JNI lib file to the command line.
>
> These kind of users don't really care about the java-libvirt build
> environment.
okay, so just the Jar availability is sufficient for them, okidoc.
> If you want to do something more interesting than renaming the java
> classes and methods,
> the you have to hit the JNI bindings, and that code is so ugly, that
> no-one without some C experience will want to touch it.
>
> Having said that, I think that an ant build file would be the most
> useful, as it can be used directly in all major
> development enviroments. There is also this maven thing, that seems to
> be widely used, but I still haven't figured out
> exactly what that is :-)
me either, though there are examples in the Fedora-java packaging pages.
[...]
> My current plans for java-libvirt are:
>
> 1. Add the storage API: It's really mostly just copy-paste-search
> replace but it still takes some work
okay
> 2. There are some consistency problems with the naming of classes and
> methods. I'd like to revisit the java api, and make some changes in
> names, and maybe class structure
Hum, better done early than late. Basically i would prefer to avoid
pushing incompatible changes. what kind of inconsistencies problems ?
> 3. There are many places where the C part leaks memory, this should also
> be audited/ fixed.
Ah, okay I will have to reread the bindings code then. Not sure how
to track leaks, I doubt valgrind can work with java ...
> Number 2 is what worries me, I don't know if it's a good idea to push
> toFedora, when I know I want to make incompatible API changes soon.
yes, which is why I would like to know a bit better :-)
> (Or you can just say that you won't accept them, but I'm a big fan of
> clean and consistent APIs, and the current one can be improved)
> I believe that I will get around to doing 1. and 2. at least in late
> july/early august, It's about a three day job, I just don't have that
> three days right now :-(
Maybe if you can expose what you think is wrong i can try to clean things up.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
17 years
