- Devel - libvirt List Archives

[libvirt] [PATCH] virConnectListAllDomains
by Richard W.M. Jones 29 Aug '08

29 Aug '08

As observed in this thread: https://www.redhat.com/archives/libvir-list/2008-July/msg00215.html several tools need to grab the complete list of domains frequently (eg. virt-manager and virt-top) and the way they do it currently is very inefficient, both in terms of the number of round-trips in the remote case (4 + 2*N calls), and the fact that we could implement drivers better if we could get all domains in a single operation. Therefore this patch adds the virConnectListAllDomains call: int virConnectListAllDomains (virConnectPtr conn, virDomainPtr **domains, virDomainInfo **infos, int stateflags); This call gets domains and virDomainInfo structures. The reasons for getting the info structures as well are that we get them anyway as a side-effect of filtering on state, and virsh, virt-top and virt-manager all get the info structures at the same time as getting the domains. As in Dan's proposal above, you can filter on state, with three special values (VIR_DOMAIN_LIST_ACTIVE, VIR_DOMAIN_LIST_INACTIVE and VIR_DOMAIN_LIST_ALL) which do what you think. virConnectListAllDomains is always available. If the driver doesn't implement it directly, then we emulate it in src/libvirt.c. This ensures that virt-manager etc can start to use this call straightaway. There is no direct implementation for Xen or QEMU yet. (If the general patch is accepted, then I'll implement at least for QEMU). However there is already a benefit to applying this patch because it optimizes the remote case from 4 + 2*N calls down to 1. There is no Python binding yet. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

3 6

[libvirt] "Choose alarm timer" feature for kvm
by Tiziano Müller 29 Aug '08

29 Aug '08

Hi everyone In KVM it is possible to select the alarm timer being used (dynticks, hpet, rtc, unix). Is someone already working on the support of this for libvirt? If not I'll see that I can come up with patches for libvirt and virt-inst within the next month (if time permits). Cheers, Tiziano -- ------------------------------------------------------- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin E-Mail : dev-zero(a)gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30

3 3

[libvirt] [PATCH]: Allow libvirt to manage bridges "plugged into" physical devices
by Chris Lalancette 29 Aug '08

29 Aug '08

All, For ovirt, we need the ability to have a bridge configured that is "plugged in" to an external interface; that is, the physical interface is one of the interfaces on the bridge. This allows us to manage physical hardware outside this box, since the ovirt WUI appliance will be hooked to this same bridge and will send/receive traffic to these external machines. Currently we are doing this "by hand" with scripts, which is clearly sub-optimal. This relatively simple patch adds a new "forward" type called "bridge" (yes, it's a bad name; I'm open to suggestions). Basically, when you have a bridge with this forward type, we take the "dev" that is specified (say, eth1), plug it into the bridge, and add the appropriate iptables rule to bridge traffic. With this in place, we can get rid of our hacky scripts and let libvirt do the dirty work for us. I also imagine this could be useful to support "xen-style" bridges, without necessarily using the Xen networking scripts. Comments? Signed-off-by: Chris Lalancette <clalance(a)redhat.com>

2 1

[libvirt] Problems using libvirt (linking errors)
by Johannes Formann 29 Aug '08

29 Aug '08

Hello, I habe a problem using a recent libvirt-Version (0.4.4) (installed from backports.org) in my own programms. I had used an older Version a while ago, but I think something might have changed in the API(?), since the old code has the same problems now. I include the headers #include <libvirt/libvirt.h> #include <libvirt/virterror.h> but when linking, I'll get errors like XSSserver.o: In function `XSSserver::XSSserverinitializeService(void*)': /root/rsplib-2.5.0/rsplib/XSSserver.cc:68: undefined reference to `virInitialize' /root/rsplib-2.5.0/rsplib/XSSserver.cc:72: undefined reference to `virConnectOpen' here is the function: bool XSSserver::XSSserverinitializeService(void* userData) { if ( virInitialize() != 0) { puts("WARNING: vir Initializew failed\n") ; return false; } virCon=virConnectOpen(NULL); if (virCon != NULL ) { return true; } puts("WARNING: Initialisierung misslungen") ; return false; } Any hints what I've done wrong/how to debug that problem? regards Johannes

2 3

[libvirt] PATCH: 0/4: Make LXC controller a separate binary
by Daniel P. Berrange 29 Aug '08

29 Aug '08

Currently libvirt is just forking off a child process to handle the LXC I/O controller. This works OK, but is kinda evil. This series of patches makes it into a fully-fledged exec()able binary. With a tiny bit more work, you could even use this to launch an LXC container standalone without needing libvirt - which could be useful for debugging during development at the very least. The other nice thing is that it makes a 'ps' listing more meaningful - you see a 'libvirt_lxc' process and the name of the container as a command line arg. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

3 16

[libvirt] PATCH: Fix fetch of NUMA info when building Xen capabilities
by Daniel P. Berrange 28 Aug '08

28 Aug '08

Currently if you use libvirt CVS HEAD on Xen >= 3.2 hypervisor it will fail to open a connection. This is because I mistakenly removed the passing of the virConnectPtr object when querying NUMA capabilities from XenD. This patch fixes that regression Daniel Index: src/xen_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xen_internal.c,v retrieving revision 1.124 diff -u -p -r1.124 xen_internal.c --- src/xen_internal.c 20 Aug 2008 20:48:36 -0000 1.124 +++ src/xen_internal.c 28 Aug 2008 15:38:05 -0000 @@ -2159,7 +2159,8 @@ struct guest_arch { static virCapsPtr -xenHypervisorBuildCapabilities(const char *hostmachine, +xenHypervisorBuildCapabilities(virConnectPtr conn, + const char *hostmachine, int host_pae, char *hvm_type, struct guest_arch *guest_archs, @@ -2185,7 +2186,7 @@ xenHypervisorBuildCapabilities(const cha if (sys_interface_version >= 4) { - if (xenDaemonNodeGetTopology(NULL, caps) != 0) { + if (xenDaemonNodeGetTopology(conn, caps) != 0) { virCapabilitiesFree(caps); return NULL; } @@ -2271,7 +2272,8 @@ xenHypervisorBuildCapabilities(const cha * Return the capabilities of this hypervisor. */ virCapsPtr -xenHypervisorMakeCapabilitiesInternal(const char *hostmachine, +xenHypervisorMakeCapabilitiesInternal(virConnectPtr conn, + const char *hostmachine, FILE *cpuinfo, FILE *capabilities) { char line[1024], *str, *token; @@ -2404,7 +2406,8 @@ xenHypervisorMakeCapabilitiesInternal(co } } - if ((caps = xenHypervisorBuildCapabilities(hostmachine, + if ((caps = xenHypervisorBuildCapabilities(conn, + hostmachine, host_pae, hvm_type, guest_archs, @@ -2425,7 +2428,7 @@ xenHypervisorMakeCapabilitiesInternal(co * Return the capabilities of this hypervisor. */ virCapsPtr -xenHypervisorMakeCapabilities(void) +xenHypervisorMakeCapabilities(virConnectPtr conn) { virCapsPtr caps; FILE *cpuinfo, *capabilities; @@ -2451,7 +2454,10 @@ xenHypervisorMakeCapabilities(void) } } - caps = xenHypervisorMakeCapabilitiesInternal(utsname.machine, cpuinfo, capabilities); + caps = xenHypervisorMakeCapabilitiesInternal(conn, + utsname.machine, + cpuinfo, + capabilities); if (cpuinfo) fclose(cpuinfo); Index: src/xen_internal.h =================================================================== RCS file: /data/cvs/libvirt/src/xen_internal.h,v retrieving revision 1.29 diff -u -p -r1.29 xen_internal.h --- src/xen_internal.h 20 Aug 2008 20:48:36 -0000 1.29 +++ src/xen_internal.h 28 Aug 2008 15:38:05 -0000 @@ -17,7 +17,7 @@ extern struct xenUnifiedDriver xenHypervisorDriver; int xenHypervisorInit (void); -virCapsPtr xenHypervisorMakeCapabilities (void); +virCapsPtr xenHypervisorMakeCapabilities (virConnectPtr conn); /* The following calls are made directly by the Xen proxy: */ @@ -38,7 +38,8 @@ int xenHypervisorClose (virConnectPtr c int xenHypervisorGetVersion (virConnectPtr conn, unsigned long *hvVer); virCapsPtr - xenHypervisorMakeCapabilitiesInternal(const char *hostmachine, + xenHypervisorMakeCapabilitiesInternal(virConnectPtr conn, + const char *hostmachine, FILE *cpuinfo, FILE *capabilities); char * Index: src/xen_unified.c =================================================================== RCS file: /data/cvs/libvirt/src/xen_unified.c,v retrieving revision 1.53 diff -u -p -r1.53 xen_unified.c --- src/xen_unified.c 20 Aug 2008 20:48:36 -0000 1.53 +++ src/xen_unified.c 28 Aug 2008 15:38:05 -0000 @@ -333,7 +333,7 @@ xenUnifiedOpen (virConnectPtr conn, xmlU } } - if (!(priv->caps = xenHypervisorMakeCapabilities())) { + if (!(priv->caps = xenHypervisorMakeCapabilities(conn))) { DEBUG0("Failed to make capabilities"); goto fail; } Index: tests/xencapstest.c =================================================================== RCS file: /data/cvs/libvirt/tests/xencapstest.c,v retrieving revision 1.14 diff -u -p -r1.14 xencapstest.c --- tests/xencapstest.c 25 Jul 2008 13:17:27 -0000 1.14 +++ tests/xencapstest.c 28 Aug 2008 15:38:05 -0000 @@ -49,7 +49,7 @@ static int testCompareFiles(const char * if (!(fp2 = fopen(capabilities, "r"))) goto fail; - if (!(caps = xenHypervisorMakeCapabilitiesInternal(hostmachine, fp1, fp2))) + if (!(caps = xenHypervisorMakeCapabilitiesInternal(NULL, hostmachine, fp1, fp2))) goto fail; if (!(actualxml = virCapabilitiesFormatXML(caps))) -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

2 1

[libvirt] Need Info on virNodeGetCellsFreeMemory
by ajishrao 28 Aug '08

28 Aug '08

Hi, how to find the memory utilization of the whole which is running with some guest? By libvirt I can only see virNodeGetCellsFreeMemory relevant API, But didn't understand how to use it. Thanks & Regards --Ajish

3 2

Re: [libvirt] Error compiling libvirt 0.4.4
by Richard W.M. Jones 28 Aug '08

28 Aug '08

On Thu, Aug 28, 2008 at 11:25:44AM -0300, Everton P. Alexandre wrote: > I managed to do the installation!!! But now, when I > try to use the virsh or to execute a program, the > following message appear: > > libvir: Remote error : No such file or directory > libvir: warning : Failed to find the network: Is the > daemon running? So as the message says, you need to run the daemon (libvirtd). Well, truthfully you don't _need_ to run it, unless you want certain features like remote access, managed networks or QEMU support. If you've got libvirtd running but you still get that message, then it'll probably be either a security or a paths problem. http://libvirt.org/remote.html Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

1 0

[libvirt] [PATCH] enable parallel builds
by James Morris 28 Aug '08

28 Aug '08

I'm not sure if this is the best way to do this, but it seems to work. ---- Enable parallel compilation of the repository when running the autobuild script and/or via rpmbuild. --- autobuild.sh | 15 ++++++++++++++- libvirt.spec.in | 2 +- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/autobuild.sh b/autobuild.sh index 7ae5d1e..1a5413b 100755 --- a/autobuild.sh +++ b/autobuild.sh @@ -21,7 +21,20 @@ rm -rf coverage --with-lxc \ --with-xen-proxy -make +# from the gdc spec file +# if RPM_BUILD_NCPUS unset, set it +if [ -z "$RPM_BUILD_NCPUS" ] ; then + if [ -x /usr/bin/getconf ] ; then + RPM_BUILD_NCPUS=$(/usr/bin/getconf _NPROCESSORS_ONLN) + if [ $RPM_BUILD_NCPUS -eq 0 ]; then + RPM_BUILD_NCPUS=1 + fi + else + RPM_BUILD_NCPUS=1 + fi +fi + +make -j$RPM_BUILD_NCPUS make install set -o pipefail diff --git a/libvirt.spec.in b/libvirt.spec.in index d37c0e0..cd8e937 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -169,7 +169,7 @@ of recent versions of Linux (and other OSes). --with-init-script=redhat \ --with-qemud-pid-file=%{_localstatedir}/run/libvirt_qemud.pid \ --with-remote-file=%{_localstatedir}/run/libvirtd.pid -make +make %{?_smp_mflags} %install rm -fr %{buildroot}

3 4

[libvirt] Exposing some unique features?
by Nguyen Anh Quynh 28 Aug '08

28 Aug '08

Hi, Though libvirt tries very hard to hide the difference between hypervisors behind an abstraction layer, there are still differences that we might want to expose to the users. For example, QEMU has the monitor interface, which provides some unique functions. Users might want to have access to the monitor interface and send command to it (like "gdbserver" command?). So how can we expose such information? We can have a new driver function, which return an opaque structure. The content of the structure is of course depends on the hypervisor type. One problem is that this might be dangerous if users relies on the QEMU monitor to execute some functions that should be done under control. Idea? Thanks, Quynh

3 5