August 2008 - Devel - libvirt List Archives

[libvirt] How to get the real error?
by Christoph Höger 30 Aug '08

30 Aug '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am trying to use libvirt to manage a virtualized HPC cluster software. That works well so far. But when I encounter an error and try to get it with virGetLastError() I often see an error message that makes no sense. E.g. I had virDomainCreateLinux(...) returning NULL and virGetLastError()->message stating "Failed to find the network: Is the daemon running ?" which is obviously wrong, because libvirtd is running and the network is using bridged mode (no 'source' element). This also happened when I had that particular domain name already in use and on other errors. I am using libvirt version 0.4.4. is that a known regression or am I just missing something? thanks christoph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIuU1FhMBO4cVSGS8RAiVRAJ0ad31+Bf5k7V7axKHDx4Yv5xc3VgCfcKsl GiHynl3ac0fdwrx+vTrvSxU= =ZqQs -----END PGP SIGNATURE-----

1 0

[libvirt] A laundry list of "TODO" items for libvirt
by Daniel P. Berrange 29 Aug '08

29 Aug '08

A bunch of us at Red Hat had a bit of a brainstorming session to make a list of things we'd like to see added to libvirt going forward, to better support our needs for virtualization in Fedora / oVirt. We've put details of everything up on the libvirt wiki: http://wiki.libvirt.org/page/Todo This list isn't a firm commitment to actually implement these features. We may later decide that some of them don't belong in libvirt (eg, the question of allowing multiu-thread access to virConnectPtr is open to debate). Nor have we got people actually working on these items - unless explicitly noted against a todo item. If anyone is looking to do work on libvirt and isn't sure of what to work on, this list may be of interest. Also, this is a wiki, so feel free to add more ideas - or add expanded details to existing ideas. Or reply to this mail, and one of us will add new ideas to the wiki for you The only request is that you don't actually start implementing things from the list without first discussing proposals on this list, because most of these ideas need more design / analysis before its reasonable to write code Regards, 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 :|

5 8

[libvirt] XML representation of security labels
by James Morris 29 Aug '08

29 Aug '08

As part of the sVirt effort, I'm investigating how and when to label the resources accessed by domains. There is already some support for querying security labels in libvirt, although it does not seem to be widely used as yet. For storage pool XML descriptors, there's a permissions element per http://libvirt.org/formatstorage.html : <permissions> <owner>0744</owner> <group>0744</group> <mode>0744</mode> <label>virt_image_t</label> </permissions> The label element in this is currently assumed by libvirt to be an SELinux security label obtainable via getfilecon(3). There are a couple of issues here: 1. We should probably not build security model specific code directly into the library. It's more flexible and also cleaner to abstract the security model out. So, I suggest making a plugin scheme similar to those already present in libvirt, where a security model can register a driver to handle abstracted operations like "getSecurityLabel". 2. The XML format for security labels needs to be extended to indicate which security model is in use, and potentially carry model-specific metadata. For SELinux, we may want to know what type of policy is active, and later, be able to interpret labels generated on other systems. In this case, I suggest we deprecate the existing label element and, if present, assume it's a plain SELinux context (or perhaps ignore it). I'd suggest we implement a new label element to avoid breaking compatibility and to avoid potential confusion with other types of device labels (e.g. as you might see via /dev/disk/by-label). So, how about the following: <seclabel> <model>  <selinux> <type>targeted</type> </selinux> </model> <value>system_u:object_r:virt_image_t:s0</value> </seclabel> The model and value elements would be mandatory, but possibly empty. The seclabel element would be a child of the permissions element: <permissions> <owner>0744</owner> <group>0744</group> <mode>0744</mode> <seclabel> <model> <selinux> <type>targeted</type> </selinux> </model> <value>system_u:object_r:virt_image_t:s0</value> </seclabel> </permissions> It would also likely be reused for labeling domains themselves, and other resources. Thoughts? - James -- James Morris <jmorris(a)namei.org>

6 9

[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 28 Aug '08

28 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