- Devel - libvirt List Archives

[libvirt] [PATCH] default URI in probe
by Evgeniy Sokolov 11 Jul '08

11 Jul '08

I specified default URI in probe(). To use libvirt with OpenVZ: # ./configure --with-openvz # make # ./src/virsh list Id Name State ---------------------------------- 33 33 running 105 105 running 108 108 running

2 1

[libvirt] [PATCH] using one function to locate OpenVZ config files
by Evgeniy Sokolov 11 Jul '08

11 Jul '08

There were 3 places with the same code. I moved it to separate function. other: use O_RDONLY to read config file

2 1

[libvirt] bug in libvirt.c?
by Evgeniy Sokolov 10 Jul '08

10 Jul '08

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++;

3 2

[libvirt] [Patch] Libvirt & Autobuild
by Mohammed Morsi 10 Jul '08

10 Jul '08

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

2 3

[libvirt] PV loader in capabilities?
by John Levon 10 Jul '08

10 Jul '08

Why is it NULL instead of the path to pygrub? On Solaris, the path is different. regards john

3 4

[libvirt] [PATCH] fix diagnostic when execute openvz commands
by Evgeniy Sokolov 10 Jul '08

10 Jul '08

-- Evgeniy Sokolov

4 7

[libvirt] [PATCH] renaming error -> openvzError
by Evgeniy Sokolov 10 Jul '08

10 Jul '08

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.

2 1

[libvirt] [PATCH] fix up dom-name validation
by John Levon 10 Jul '08

10 Jul '08

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'>

2 1

[libvirt] [PATCH] SetAutostart and GetAutostart in openvz driver
by Evgeniy Sokolov 10 Jul '08

10 Jul '08

Implemented functions domainSetAutostart and domainGetAutostart. other: fixed closing file descriptor during reading uuid from config.

3 3

[libvirt] virDomainMemoryPeek & maximum remote message buffer size
by Richard W.M. Jones 09 Jul '08

09 Jul '08

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/

3 2