- Devel - libvirt List Archives

[Libvir] PATCH: Allow updating of timer & file handle event watches
by Daniel P. Berrange 19 Sep '07

19 Sep '07

The forthcoming patch to add Avahi support requires a couple of enhancements to our event loop to support integration with Avahi's event callback needs - Ability to update the event mask for a pre-existing file handle watch - Ability to change the frequency of a timer watch - Ability to have a timer which fires immediately - Ability to disable events on a timer watch The first point was trivial - just change the 'events' flag we have recorded in the virEventHandle struct. The second point was also trivial - just change the period of the timer as recorded in virEventTimer struct. The last two points were more tricky, but doable. To fire a timer immediately I tweaked the logic so that it allows a frequency of '0'. Obviously to avoid spinning 100%, the app should unregister the timer once it has fired the desired number of times (usually 1). To disable a timer temporarily I allow the use of '-1' in the frequency. THe code had a bad mix of terminology using a 'timer' and 'timeout' field in the virEventTimer struct which confused me no end. So I renamed the 'timeout' field to 'frequency' which reflects its actual purpose. Finally, when building with debugging, the event loop can generate alot of data, so I added a EVENT_DEBUG macro to the file which prefixes EVENT: on all debug output so allow easy filtering. 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 -=|

2 3

[Libvir] PATCH: Disable automake portability warnings
by Daniel P. Berrange 19 Sep '07

19 Sep '07

The latest automake has a nasty habit of complaining about use of GNU Make features such as wildcards. We use these extensively in the tests/ directory since there are so many test datafiles, listing them explicitly is a waste of time. The attached patch passes the -Wno-portability flag to automake to make it keep quiet. NB, to do this required a bit of a re-working of the automake/autoconf initialization stuff. Our current configure script uses AC_INIT and AM_INIT_AUTOMAKE in the so called 'legacy style'. To quote the automake manual [quote] If your `configure.ac' has: AC_INIT([src/foo.c]) AM_INIT_AUTOMAKE([mumble], [1.5]) you can modernize it as follows: AC_INIT([mumble], [1.5]) AC_CONFIG_SRCDIR([src/foo.c]) AM_INIT_AUTOMAKE [/quote] This re-arrangement is valid on any non-jurassic era automake & only impacts developers running autogen.sh - not end users running the configure script itself. The one complication is that the version given to AC_INIT must be a literal, but we currently used an environment variable. So m4 black-magic gets around this problem. I also killed LIBVIRT_VERSION_EXTRA since it is not referenced anywhere in the source tree. 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 -=|

2 2

[Libvir] Network blocking issue
by Shuveb Hussain 17 Sep '07

17 Sep '07

Hi, I observed this while using the python bindings and accessing a remote host with libvirt: >>> import libvirt >>> c = libvirt.open('xen://veetee/') >>> c.getInfo() ['i686', 2021, 2, 1864, 1, 1, 2, 1] >>> c.getInfo() ['i686', 2021, 2, 1864, 1, 1, 2, 1] # remove network cable from remote machine now >>> c.getInfo() # blocks forever.... What is the problem here and is there a solution to this? I am running FC7 and here is the version info from virsh: virsh # version Compiled against library: libvir 0.3.2 Using library: libvir 0.3.2 Using API: Xen 3.0.1 Running hypervisor: Xen 3.1.0 I observed this for more than 10 mins, it was still hung. Thanks in advance! -- Shuveb Hussain. Money has nothing to do with Happiness, But, Poverty has a lot to do with Sorrow. Company: www.binarykarma.com Blog: www.binarykarma.org

4 9

[Libvir] NUMA topology calls
by beth kon 17 Sep '07

17 Sep '07

Daniel, We agreed that xenHypervisorGetCapabilities will call a xend_internal.c function to get the topology through xend. Was your intent to extend xenDaemonNodeGetInfo or have a new function, such as xenDaemonNodeGetTopology? I assumed a new function would be cleaner, but you didn't include such a function in your patch so I'm not sure if you had some other idea. -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

2 1

[Libvir] PATCH: Prevent zombie ssh tunnels
by Daniel P. Berrange 17 Sep '07

17 Sep '07

I noticed that when using the SSH tunnel for the remote driver I ended up with alot of zombie SSH processes. We simply forgot to waitpid() on the child when a connection attempt failed, or when shutting down an open remote connection. Attached is a possible patch 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 -=|

4 10

[Libvir] RFC: Broadcast our presence with avahi
by Daniel P. Berrange 14 Sep '07

14 Sep '07

All the really trendy network services these days broadcast their presence on the LAN using mDNS. In Linux world this means becoming an Avahi client and registering our services. virt-manager is also able to become an Avahi client and browser for services. So you'll be able to let the user just pick a host straight off a list instead of typing in hostname. The attached patch does two things: - Extends our event loop implementation so it can modify the event mask associated with an FD, and the timeout associated with a timer. While you could simulate this with an add & remove, this has the possibility of failure (from malloc). Merely updating an existing event can be done without failure. Avahi needs this ability for its event loop integration - Added qemu/mdns.c file to actually provide the service information. This has two parts. The first section of code is taken straight from one of the Avahi example programs. The second section is a implementaiton of the Avahi event loop contract in terms of our event API - it works very nicely which says good things about design of our event loop Some things... - I arbitrarily picked a service type of '_libvirtd._tcp'. The docs on picking service types seem non-existant on Avahi website, but it seems to be common to use service name from /etc/services and protocol both prefixed with _. - I advertise two subtypes, of '_xen.libvirtd._tcp' and '_qemu.libvirtd._tcp' What I actually want todo is to be able to probe the libvirt local drivers to auto-discover what virtualization platforms are available. A sort of lightweight virConnectOpen which merely returns TRUE/FALSE and doesn't actually allocate a virConnectPtr object. Need to extend the internal driver API for this. - I want to advertise whether the server is configured with TLS certs or not, so remote clients can automatically choose to use SSH urls with the remote driver if neccessary. - Let the admin turn advertisement on/off in the config file because some people may not like it on their LAN. If you fancy trying it, avahi-browse --all from another host on the LAN should show the service being advertised. The advertisements do not cross LAN routers by default. 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 -=|

4 8

[Libvir] Segfault with invalid virConnectPtr
by Richard W.M. Jones 13 Sep '07

13 Sep '07

Program terminated with signal 11, Segmentation fault. #0 0x0000003d8b472a1b in free () from /lib64/libc.so.6 (gdb) bt #0 0x0000003d8b472a1b in free () from /lib64/libc.so.6 #1 0x00002aaaaaae8dd7 in virResetError (err=0x33535c8) at virterror.c:111 #2 0x00002aaaaaae8fce in __virRaiseError (conn=0x33535a0, dom=0x0, net=0x0, domain=0, code=6, level=VIR_ERR_ERROR, str1=0x2aaaaab0c678 "invalid connection pointer in %s", str2=0x2aaaaab08560 "virConnectNumOfDomains", str3=0x0, int1=0, int2=0, msg=0x2aaaaab0c678 "invalid connection pointer in %s") at virterror.c:358 #3 0x00002aaaaaacfa8e in virLibConnError (conn=0x33535a0, error=VIR_ERR_INVALID_CONN, info=0x2aaaaab08560 "virConnectNumOfDomains") at libvirt.c:127 #4 0x00002aaaaaad1052 in virConnectNumOfDomains (conn=0x736e6961) at libvirt.c:758 #5 0x000000000043fa4e in ?? () A preliminary look at the code seems to indicate a fault in this logic: int virConnectNumOfDomains(virConnectPtr conn) { DEBUG("conn=%p", conn); if (!VIR_IS_CONNECT(conn)) { virLibConnError(conn, VIR_ERR_INVALID_CONN, __FUNCTION__); The VIR_IS_CONNECT macro is defined as: #define VIR_CONNECT_MAGIC 0x4F23DEAD #define VIR_IS_CONNECT(obj) ((obj) && (obj)->magic==VIR_CONNECT_MAGIC) Obviously if VIR_IS_CONNECT fails then "conn" should not be used further, so calling virLibConnError (conn, ...) is wrong. Personally I think when we detect memory corruption in a C program we should just call abort(). I'll see if I can come up with a patch to fix this later ... at the moment I'm more interested in why my program is passing an invalid connection pointer in the first place :-( Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ 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. 03798903

2 4

[Libvir] [PATCH] properly check buffer size in virDomainXMLDevID
by Hugh Brock 12 Sep '07

12 Sep '07

As promised, a patch to protect the 80-character "device id" buffer from overflow by the unbounded "device=" XML attribute. Before, a large "device" attribute gave a stack overflow error; now it merely results in an obscure (but non-fatal) xend error like so: libvir: Xen Daemon error : POST operation failed: (xend.err "invalid literal for int() with base 10: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'") (the long string of "x"es was my way of overflowing the buffer). Please ACK... --Hugh -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock(a)redhat.com | virtualization library http://libvirt.org

2 3

[Libvir] unsigned long
by John Levon 12 Sep '07

12 Sep '07

I just saw an email about unsigned long and max memory fly by along with a comment like "32-bit will never have more than 'X' Gb" ... This raises an obvious question: is libvirt explictly not 32/64 clean? On Solaris we build everything 32-bit by default unless there is a reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit kernel, then we have a problem. IMO an API should *always* use explicitly-sized integers when they contain range or size values (or use size_t etc.). Not doing so is both dangerous and confusing... (Xen does indeed have this problem, so we run all their tools with native word size. Currently we always use a 32-bit libvirt for 'virt-install', and it does seem to work fine. It would be a pity for this to change). cheers john

3 6

[Libvir] [PATCH] Remove warning when dumping XML from an inactive domain with Xen < 3.1
by Richard W.M. Jones 12 Sep '07

12 Sep '07

# virsh dumpxml solaris32fv libvir: Xen Daemon error : failed Xen syscall xenDaemonDomainDumpXML domain ID < 0 and xendConfigVersion < 3 0 [ and dump proceeds as normal ] The patch just removes the false error message and makes a note that this still needs a real fix later. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ 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. 03798903

3 3