- Devel - libvirt List Archives

[Libvir] [PATCH 0/2] virDomainMigrate (for discussion only!)
by Richard W.M. Jones 17 Jul '07

17 Jul '07

This is a patch which adds virDomainMigrate. It is incomplete (only supports Xen, no remote support, no qemu support), but I hope you'll look at the proposed interface and discuss the parameters. More in the following two emails. 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

6 40

[Libvir] Initial OpenVZ Support Patches
by Shuveb Hussain 17 Jul '07

17 Jul '07

Hi, Here are the OpenVZ support patches. The .c and .h files go into src/ This is being released in the spirit of releasing early. Only the basic stuff is done and development is continuing. What works: * Getting number of active/inactive domains * Listing active/inactive domains * Creating a domain that has been already defined (using OpenVZ tools) * Shutdown, start, reboot * configure.in has a new switch --with-openvz(on by default), use --without-openvz to switch it off. After I get feedback, I will work on it and add other features later on. There is no need for any OpenVZ tools code. Just the OpenVZ kernel and tools need to be installed. This code depends on the OpenVZ tool binaries. Differences from QEMU/Xen: * ID and name are same * Not possible to create temporary domains and do away with them. Creating a domain will involve untarring a template cache and bringing it up. * No readonly access. OpenVZ tools need root access. There are other design issues to be discussed. These issues spring from the fact that OpenVZ is very different from Xen/QEMU. I will discuss these issues in further mails. Here is a sample session transcript: shuveb@debian-openvz:~/libvirt$ sudo src/virsh -c openvz:///system Welcome to lt-virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # list Id Name State ---------------------------------- 101 101 running 102 102 running 103 103 running virsh # shutdown 101 Domain 101 is being shutdown virsh # list Id Name State ---------------------------------- 102 102 running 103 103 running virsh # list --all Id Name State ---------------------------------- 102 102 running 103 103 running - 101 shut off virsh # start 101 Domain 101 started virsh # list Id Name State ---------------------------------- 101 101 running 102 102 running 103 103 running virsh # Thanks and Regards, -- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com

3 5

[Libvir] PATCH: Specify BIOS clock offset for HVM
by Daniel P. Berrange 17 Jul '07

17 Jul '07

The attached patch introduces a new XML element for specifying information about the guest (BIOS) clock. For Xen HVM, and QEMU / KVM guests this is used to specifyc whether the guest clock should be in UTC, or localtime. The latter is useful for Windows which likes the BIOS to be localtime, while the former is useful for all other operating systems. The former is of course the default - so no change in existing semantics. The <clock> element currently takes a single attribute 'offset'. This is either 'utc' or 'localtime', but if we port to VMWare, it will also allow an arbitrary numeric offset as well as these special constants. <clock offset='utc'/> Or <clock offset='localtime'/> It may later also be desirable to add a 'sync=[yes|no]' attribute to specify whether the HV tries to keep the clock in sync with the HV while it is running. VMWare has this concept, and so does Xen paravirt - though Xen paravirt sets it via /proc/sys/xen/independant_wallclock inside the guest and AFAICT doesn't (yet) expose it to the guest config in Dom0. Anyway, my patch implements use of utc/localtime offsets for Xen, and QEMU drivers. I've tested to verify that -localtime gets passed to the QEMU process as appropriate. 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] Regarding Libvirt & VirtManager
by Paulev 16 Jul '07

16 Jul '07

Hi All, I'm curious to know if LibVirt & VirtManager is being developed only by RedHat employees only. If not, what is the process for developers who wish to contribute to these projects. Also, I'd like to know how and by whom decisions are made for new features to be included in these projects. Thanks, Evan

2 1

[Libvir] OCaml binding 0.3.0.0 released
by Richard W.M. Jones 13 Jul '07

13 Jul '07

http://et.redhat.com/~rjones/ocaml-libvirt/ Adds: * virConnectGetHostname (as Libvirt.Connect.get_hostname) * virConnectGetURI (as Libvirt.Connect.get_uri) and full support for virterror, including all the internal fields. See: http://et.redhat.com/~rjones/ocaml-libvirt/html/Libvirt.Virterror.html 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

1 1

[Libvir] [PATCH] Add the check of the format of MAC address on virsh attach-interface
by Masayuki Sunou 13 Jul '07

13 Jul '07

Hi Even if specified MAC address is invalid, network interface is attached to the guest. And attached network interface cannot communicate. This patch checks the format of MAC address, and virsh become error when it is invalid. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. -------------------------------------------------------------------------------- Index: include/libvirt/virterror.h =================================================================== RCS file: /data/cvs/libvirt/include/libvirt/virterror.h,v retrieving revision 1.26 diff -u -p -r1.26 virterror.h --- include/libvirt/virterror.h 6 Jul 2007 14:56:15 -0000 1.26 +++ include/libvirt/virterror.h 12 Jul 2007 02:00:54 -0000 @@ -127,6 +127,7 @@ typedef enum { VIR_WAR_NO_NETWORK, /* failed to start network */ VIR_ERR_NO_DOMAIN, /* domain not found or unexpectedly disappeared */ VIR_ERR_NO_NETWORK, /* network not found */ + VIR_ERR_INVALID_MAC, /* invalid MAC adress */ } virErrorNumber; /** Index: src/virterror.c =================================================================== RCS file: /data/cvs/libvirt/src/virterror.c,v retrieving revision 1.28 diff -u -p -r1.28 virterror.c --- src/virterror.c 6 Jul 2007 14:56:15 -0000 1.28 +++ src/virterror.c 12 Jul 2007 02:00:54 -0000 @@ -646,6 +646,12 @@ __virErrorMsg(virErrorNumber error, cons else errmsg = _("Network not found: %s"); break; + case VIR_ERR_INVALID_MAC: + if (info == NULL) + errmsg = _("invalid MAC adress"); + else + errmsg = _("invalid MAC adress: %s"); + break; } return (errmsg); } Index: src/xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.81 diff -u -p -r1.81 xml.c --- src/xml.c 11 Jul 2007 08:41:11 -0000 1.81 +++ src/xml.c 12 Jul 2007 02:00:55 -0000 @@ -934,8 +934,19 @@ virDomainParseXMLIfDesc(virConnectPtr co } virBufferAdd(buf, "(vif ", 5); - if (mac != NULL) + if (mac != NULL) { + unsigned int addr[12]; + int ret = sscanf((const char *)mac, "%01x%01x:%01x%01x:%01x%01x:%01x%01x:%01x%01x:%01x%01x", + (unsigned int*)&addr[0], (unsigned int*)&addr[1], (unsigned int*)&addr[2], + (unsigned int*)&addr[3], (unsigned int*)&addr[4], (unsigned int*)&addr[5], + (unsigned int*)&addr[6], (unsigned int*)&addr[7], (unsigned int*)&addr[8], + (unsigned int*)&addr[9], (unsigned int*)&addr[10], (unsigned int*)&addr[11]); + if (ret != 12 || strlen(mac) != 17) { + virXMLError(conn, VIR_ERR_INVALID_MAC, (const char *) mac, 0); + goto error; + } virBufferVSprintf(buf, "(mac '%s')", (const char *) mac); + } if (source != NULL) { if (typ == 0) virBufferVSprintf(buf, "(bridge '%s')", (const char *) source);

3 3

[Libvir] [PATCH] Fix strange message on virsh attach-device
by Masayuki Sunou 13 Jul '07

13 Jul '07

Hi Virsh attach-device outputs a strange message, when XML whose top element is not <device> or <interface>. ---------------------------------------------------------------------- libvir: Xen Daemon error : POST operation failed: (xend.err "object of type 'NoneType' has no len()") error: Failed to attach device from test.xml ---------------------------------------------------------------------- This patch fixes it by not calling Xen in this case. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. ---------------------------------------------------------------------- Index: libvirt/src/xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.81 diff -u -p -r1.81 xml.c --- libvirt/src/xml.c 11 Jul 2007 08:41:11 -0000 1.81 +++ libvirt/src/xml.c 13 Jul 2007 02:48:04 -0000 @@ -1337,6 +1337,8 @@ virParseXMLDevice(virConnectPtr conn, ch else if (xmlStrEqual(node->name, BAD_CAST "interface")) { if (virDomainParseXMLIfDesc(conn, node, &buf, hvm, xendConfigVersion) != 0) goto error; + } else { + goto error; } cleanup: if (xml != NULL)

3 2

[Libvir] Small remote doc update and little checking script
by Daniel Veillard 12 Jul '07

12 Jul '07

Hi, I updated slightly the remote page (mostly adding an index at the top and updating a couple of things which changed prior to 0.3.0 release) http://libvirt.org/remote.html and added a small script to check the client/server setup on a given host, trying to pinpoint the problems I faced myself when trying to set the TLS certificates. This may help others, checked in docs/pki_check.sh and hence available at http://libvirt.org/pki_check.sh There is certainly many more check which can be done (like expiration date checking, or making sure certs and keys are properly matched), but it's a first step, an maybe it can help others testing the remote support. Feedback and patches are as usual welcome :-) 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/

1 0

[Libvir] PATCH: Report errors against virConnectPtr object
by Daniel P. Berrange 12 Jul '07

12 Jul '07

The QEMU driver is not passing in a virConnectPtr object for many of the places it calls virRaiseError. This means the errors aren't getting fed back to the client correctly - particularly when starting a VM / network. This patch passes around a virConnectPtr object so errors get reported correctly Instead of: $ ~/usr/bin/virsh --connect qemu://celery.virt.boston.redhat.com/system start demo error: Failed to start domain demo It now gives $ ~/usr/bin/virsh --connect qemu://celery.virt.boston.redhat.com/system start demo libvir: QEMU error : QEMU quit during console startup qemu: could not open hard disk image '/root/demo.img' error: Failed to start domain demo 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 -=|

3 4

[Libvir] PATCH: Fix crash if client acl check fails
by Daniel P. Berrange 12 Jul '07

12 Jul '07

There was a couple of places where if the ACL check for an incoming client failed, it would go on and register the client's FD in the event loop anyway. The trouble is, after the ACL failed, the client had been forcably disconnected & the client struct free'd, so the daemon died in the event loop a short time later. This patch fixes it & makes a couple of other places more paranoid about checking too 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 -=|

3 3

[Libvir] PATCH: More useful error messages with missing certs
by Daniel P. Berrange 12 Jul '07

12 Jul '07

On the server end if you try to start the server with TLS enabled and you don't have the certs setup, you get a cryptic: gnutls_certificate_set_x509_trust_file: Error while reading file. Rather useless the gnutls error message not telling you what file was missing. Similarly with virsh: # ~/usr/bin/virsh --connect qemu://localhost/system list libvir: Remote error : Error while reading file. Since GNU TLS doesn't even tell you the actual problem - was it wrong permissions, or missing file altogether, I decided its better to do an explicit 'stat' check ahead of time. So now it gives: $ ~/usr/bin/virsh --connect qemu://celery.virt.boston.redhat.com/system start demo libvir: Remote error : Cannot access CA certificate '/home/berrange/usr/etc/pki/CA/cacert.pem': No such file or directory (2) Or $ ~/usr/bin/virsh --connect qemu://celery.virt.boston.redhat.com/system start demo libvir: Remote error : Cannot access CA certificate '/home/berrange/usr/etc/pki/CA/cacert.pem': Permission denied (13) Or in the daemon # /usr/sbin/libvirtd --listen Cannot access CA certificate '/home/berrange/usr/etc/pki/CA/cacert.pem': No such file or directory (2) 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 -=|

3 4

[Libvir] Next features and target for development
by Daniel Veillard 12 Jul '07

12 Jul '07

Hi all, now that 0.3.0 is out, it's probably time to build the next set of features we aims at developping in the next months, the list I have currently is short, but still significant: - migration API: now that we have remote support it should be possible to build an API for migration of domains between 2 connections. Could be as simple as int virDomainMigrate(virDomainPtr domain, virConnectPtr to, int flags); sounds like a fun and very useful part. - USB support: we discussed that already, but the initial patch did not match the XML format suggestions we should try to resurrect this http://libvirt.org/search.php?query=USB&scope=LISTS http://www.redhat.com/archives/libvir-list/2007-March/thread.html#00118 - Support for Xen-API new entry points at least for localhost access since we have remote support now - platform support: resolve the PPC64 issues - more engine support: OpenVZ is on the work, is there interest in lguest, UML or for example Solaris zones ? Now is a good time to suggest new potential directions, and I certainly forgot some obvious points, so what did I missed ? 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/

11 42

[Libvir] Starting a domain
by Shuveb Hussain 12 Jul '07

12 Jul '07

Hi, suspend() -> resume() save() -> restore() shutdown() -> ??? Which method should I map in the OpenVZ driver that starts a domain that has been shutdown. Does the 'reboot' method do the job here as well? Thanks & Regards, -- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com

2 1

[Libvir] big-endian support for libvirt - introduce GUEST_HANDLE infrastructure ?
by Christian Ehrhardt 12 Jul '07

12 Jul '07

Hello everyone, we currently try to use/port libvirt to run on xenppc. While doing that I found a endianess issue. First a simple example: Sample code: #include <stdio.h> union u { int i; long long l; }; int main(void) { union u u; u.l = 0; u.i = ~0; printf("%016llx\n", u.l); return 0; } Little-endian output: 00000000ffffffff Big-endian output: ffffffff00000000 Now look at the padding in e.g. xen_v2s3_getdomaininfolistop: it doesn't work on big-endian systems. This problem is why the GUEST_HANDLE infrastructure is present in Xen. To work on big-endian systems, libvirt will need this or a similar mechanism. --- Current Questions --- We could now add several ugly ifdefs to libvirt code to differentiate powerpc from the others and solve the issue described above, but I think thats not a good solution. The GUEST_HANDLE mechanism would provide an architecture abstraction and is already implemented/working in libxc. The question is, shouldn't libvirt actually use the GUEST_HANDLE mechanism like libxc does (at least for the _v2d5_ structures) or are there big arguments against it? I would create a patch to add the GUEST_HANDLE stuff in libvirt if there is nothing against it, but I will need some help to test it on x86/x86_64/ia64 since I have no such machines here. If there is a major reason against the GUEST_HANDLE code, are there other suggestions/preferences how to solve this? Below is the technical background in a more verbose way for anyone interested --- Code Affected --- More or less everything in libvirt that would use GUEST_HANDLE in libxc: I saw the effect on a bad pointer passed down by the structure I use for my example below, but in the end it may affect all the stuff that uses the *GUEST_HANDLE* stuff in libxc which are e.g. uchar,ulong,... here an example: libxc: uint64_aligned_t max_pages; // <- arch dependent mapping of uint64_aligned_t libvirt: #define ALIGN_64 __attribute__((aligned(8))) uint64_t max_pages ALIGN_64; // <- this align is fix on all architectures --- The Issue in libvirt in one example --- XEN_GUEST_HANDLE usage in libxc: - XEN_GUEST_HANDLE is defined arch specific giving the arch the posibility to pad/align as needed. See xen/tools/libxc/xen/arch-powerpc.h for example. - xen/tools use set_xen_guest_handle and get_xen_guest_handle to set/access these handles and let the arch the posibility to handle any specific needs. Example: struct xen_sysctl_getdomaininfolist { domid_t first_domain; uint32_t max_domains; XEN_GUEST_HANDLE_64(xen_domctl_getdomaininfo_t) buffer; uint32_t num_domains; }; The arch defined XEN_GUEST_HANDLE_64 leads to the following type for buffer on powerpc (see the initial padding): typedef struct { \ int __pad[(sizeof (long long) - sizeof (void *)) / sizeof (int)]; \ xen_domctl_getdomaininfo_t *p; } __attribute__((__aligned__(8))) __guest_handle_xen_domctl_getdomaininfo_t In this scenario a 32bit pointer for *p with 0xFFFFFFFF will be stored as 0xPADPADPAFFFFFFFF and read in a valid way by the 64bit host that receives this syscall. XEN_GUEST_HANDLE usage in libvirt: - In my example where XEN_GUEST_HANDLE is in libxc libvirt currently uses a union based structure like the following: struct xen_v2s3_getdomaininfolistop { domid_t first_domain; uint32_t max_domains; union { struct xen_v2d5_getdomaininfo *v; uint64_t pad ALIGN_64; } buffer; uint32_t num_domains; }; typedef struct xen_v2s3_getdomaininfolistop xen_v2s3_getdomaininfolistop; The union used here to add the 64 bit padding does not work on big endian powerpc because reading this two half words in 64bit receiver gives 0xFFFFFFFF00000000 (The two half words are stored in the wrong order) while on ia64 it is read as the the valid 0x00000000FFFFFFFF. P.S. Thanks Hollis for the simple example code -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization +49 7031/16-3385 Ehrhardt(a)linux.vnet.ibm.com Ehrhardt(a)de.ibm.com IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294

5 12

[Libvir] xen long-list s-expression
by Daniel Miles 12 Jul '07

12 Jul '07

Hello everone, does anybody know if libvirt has any way of getting the full s-expression that xm list --long <domID> produces? Or failing that, some way to get the location property under device(vfb(location <location string>)) ?

3 2

[Libvir] PATCH: Force close of virConnectPtr if client quits abnormally
by Daniel P. Berrange 12 Jul '07

12 Jul '07

If a remote client quits abnormally (or if the server forcably drops a client for misbehaviing), it is possible that the virConnectPtr object is not closed. This leads to a build up of active connections in the server. The attached patch simply calls virConnectClose when killing off a client connection if there is a non-NULL client->conn object. 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 -=|

3 2

[Libvir] [PATCH] Add the check of the device source
by Masayuki Sunou 12 Jul '07

12 Jul '07

Hi If specified device source does not exist, Not appropriate error is displayed. ---------------------------------------------------------------------- # virsh attach-disk PV_FC7_14 NOT_EXIST_PATH xvdd libvir: Xen Daemon error : POST operation failed: (xend.err 'Device 51760 (vbd) could not be connected. Hotplug scripts not working.') ---------------------------------------------------------------------- This patch checks the existence of the device source path, and correct message is displayed in case of error. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. -------------------------------------------------------------------------------- Index: include/libvirt/virterror.h =================================================================== RCS file: /data/cvs/libvirt/include/libvirt/virterror.h,v retrieving revision 1.26 diff -u -p -r1.26 virterror.h --- include/libvirt/virterror.h 6 Jul 2007 14:56:15 -0000 1.26 +++ include/libvirt/virterror.h 12 Jul 2007 00:07:27 -0000 @@ -127,6 +127,7 @@ typedef enum { VIR_WAR_NO_NETWORK, /* failed to start network */ VIR_ERR_NO_DOMAIN, /* domain not found or unexpectedly disappeared */ VIR_ERR_NO_NETWORK, /* network not found */ + VIR_ERR_NO_DEVICE_SOURCE, /* device source not found */ } virErrorNumber; /** Index: src/virterror.c =================================================================== RCS file: /data/cvs/libvirt/src/virterror.c,v retrieving revision 1.28 diff -u -p -r1.28 virterror.c --- src/virterror.c 6 Jul 2007 14:56:15 -0000 1.28 +++ src/virterror.c 12 Jul 2007 00:07:28 -0000 @@ -646,6 +646,12 @@ __virErrorMsg(virErrorNumber error, cons else errmsg = _("Network not found: %s"); break; + case VIR_ERR_NO_DEVICE_SOURCE: + if (info == NULL) + errmsg = _("Device source not found"); + else + errmsg = _("Device source not found: %s"); + break; } return (errmsg); } Index: src/xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.81 diff -u -p -r1.81 xml.c --- src/xml.c 11 Jul 2007 08:41:11 -0000 1.81 +++ src/xml.c 12 Jul 2007 00:07:28 -0000 @@ -18,6 +18,7 @@ #include <xs.h> #endif #include <math.h> /* for isnan() */ +#include <sys/stat.h> #include "internal.h" #include "hash.h" #include "sexpr.h" @@ -720,6 +721,7 @@ virDomainParseXMLDiskDesc(virConnectPtr int cdrom = 0; int isNoSrcCdrom = 0; int ret = 0; + struct stat st; type = xmlGetProp(node, BAD_CAST "type"); if (type != NULL) { @@ -772,6 +774,12 @@ virDomainParseXMLDiskDesc(virConnectPtr ret = -1; goto cleanup; } + } else { + if (stat(source, &st) == -1) { + virXMLError(conn, VIR_ERR_NO_DEVICE_SOURCE, (const char *) source, 0); + ret = -1; + goto cleanup; + } } if (target == NULL) { virXMLError(conn, VIR_ERR_NO_TARGET, (const char *) source, 0);

2 2

[Libvir] [PATCH] If ./configure --enable-debug=yes, print libvirt calls
by Richard W.M. Jones 11 Jul '07

11 Jul '07

This can prove useful if we want to track down problems like the double-call of domainSuspend. Also attached below is the output of virt-manager when this tracing is enabled. Note that if --enable-debug is not set, then no extra code is added to libvirt. 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 libvirt: virInitialize () libvirt: virInitialize () libvirt: virInitialize () libvirt: virInitialize () libvirt: virInitialize () libvirt: virInitialize () libvirt: virInitialize () libvirt: virInitialize () libvirt: virConnectOpen (name=xen) libvirt: do_open: proceeding with name=xen:/// libvirt: do_open: trying driver 0 (Test) ... libvirt: do_open: driver 0 returned DECLINED libvirt: do_open: trying driver 1 (QEMU) ... libvirt: do_open: driver 1 returned DECLINED libvirt: do_open: trying driver 2 (Xen) ... libvirt: do_open: driver 2 returned SUCCESS libvir: Remote error : No such file or directory libvir: warning : Failed to find the network: Is the daemon running ? libvirt: virConnectNumOfNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvirt: virConnectNumOfDefinedNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks libvirt: virConnectListDomains (conn=0x1052760, ids=0x7fff3a55c510, maxids=500) libvirt: virConnectNumOfDefinedDomains (conn=0x1052760) libvirt: virDomainLookupByID (conn=0x1052760, id=0) libvirt: virDomainGetUUID (domain=0x104c660, uuid=0x7fff3a55ccd0) libvirt: virDomainLookupByID (conn=0x1052760, id=12) libvirt: virDomainGetUUID (domain=0x105a510, uuid=0x7fff3a55ccd0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55c400) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55c400) libvirt: virNodeGetInfo (conn=0x1052760, info=0x7fff3a55cca0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55cad0) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55cad0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetName (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetName (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectGetType (conn=0x1052760) libvirt: virConnectGetType (conn=0x1052760) libvirt: virConnectNumOfNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvirt: virConnectNumOfDefinedNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectListDomains (conn=0x1052760, ids=0x7fff3a55c010, maxids=500) libvirt: virConnectNumOfDefinedDomains (conn=0x1052760) libvirt: virNodeGetInfo (conn=0x1052760, info=0x7fff3a55c7a0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectNumOfNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvirt: virConnectNumOfDefinedNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectListDomains (conn=0x1052760, ids=0x7fff3a55c010, maxids=500) libvirt: virConnectNumOfDefinedDomains (conn=0x1052760) libvirt: virNodeGetInfo (conn=0x1052760, info=0x7fff3a55c7a0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectNumOfNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvirt: virConnectNumOfDefinedNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectListDomains (conn=0x1052760, ids=0x7fff3a55c010, maxids=500) libvirt: virConnectNumOfDefinedDomains (conn=0x1052760) libvirt: virNodeGetInfo (conn=0x1052760, info=0x7fff3a55c7a0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectNumOfNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvirt: virConnectNumOfDefinedNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectListDomains (conn=0x1052760, ids=0x7fff3a55c010, maxids=500) libvirt: virConnectNumOfDefinedDomains (conn=0x1052760) libvirt: virNodeGetInfo (conn=0x1052760, info=0x7fff3a55c7a0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectNumOfNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvirt: virConnectNumOfDefinedNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectListDomains (conn=0x1052760, ids=0x7fff3a55c010, maxids=500) libvirt: virConnectNumOfDefinedDomains (conn=0x1052760) libvirt: virNodeGetInfo (conn=0x1052760, info=0x7fff3a55c7a0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainSuspend (domain=0x105a510) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55bab0) libvirt: virConnectNumOfNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvirt: virConnectNumOfDefinedNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectListDomains (conn=0x1052760, ids=0x7fff3a55c010, maxids=500) libvirt: virConnectNumOfDefinedDomains (conn=0x1052760) libvirt: virNodeGetInfo (conn=0x1052760, info=0x7fff3a55c7a0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectNumOfNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvirt: virConnectNumOfDefinedNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectListDomains (conn=0x1052760, ids=0x7fff3a55c010, maxids=500) libvirt: virConnectNumOfDefinedDomains (conn=0x1052760) libvirt: virNodeGetInfo (conn=0x1052760, info=0x7fff3a55c7a0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectNumOfNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvirt: virConnectNumOfDefinedNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectListDomains (conn=0x1052760, ids=0x7fff3a55c010, maxids=500) libvirt: virConnectNumOfDefinedDomains (conn=0x1052760) libvirt: virNodeGetInfo (conn=0x1052760, info=0x7fff3a55c7a0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainResume (domain=0x105a510) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55bab0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectNumOfNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvirt: virConnectNumOfDefinedNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectListDomains (conn=0x1052760, ids=0x7fff3a55c010, maxids=500) libvirt: virConnectNumOfDefinedDomains (conn=0x1052760) libvirt: virNodeGetInfo (conn=0x1052760, info=0x7fff3a55c7a0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectNumOfNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvirt: virConnectNumOfDefinedNetworks (conn=0x1052760) libvir: error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virConnectListDomains (conn=0x1052760, ids=0x7fff3a55c010, maxids=500) libvirt: virConnectNumOfDefinedDomains (conn=0x1052760) libvirt: virNodeGetInfo (conn=0x1052760, info=0x7fff3a55c7a0) libvirt: virDomainGetInfo (domain=0x104c660, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetInfo (domain=0x105a510, info=0x7fff3a55c5d0) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x105a510) libvirt: virDomainGetID (domain=0x104c660) libvirt: virDomainGetID (domain=0x105a510)

3 7

[Libvir] [PATCH] Get rid of QEMUD_PID_FILE
by Richard W.M. Jones 11 Jul '07

11 Jul '07

It is no longer used by the code. 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 1

[Libvir] Double call to domainSuspend callback
by Bruce.Evans＠Sun.COM 11 Jul '07

11 Jul '07

Hi, I have implemented the 'domainSuspend' callback in libvirt for my hypervisor (see test.c or qemu_internal.c for reference) When using the Red Hat Virtual Manager (after connecting to my hypervisor), clicking on a domain row, then clicking the 'open' button at the botton right of the window, I get a new window where I can click the 'Pause' button for instance. When I do this, the 'domainSuspend' callback is entered twice as shown in my debug code below. Why is this happening? Is it a bug? So somewhere in the RHVM python code, this call is getting activated twice. Thanks, -Bruce --> 1st time: DBG: ldomsDomainSuspend(ENTER) name=ldom1 **send_ldom_lifecycle_action..(ENTER) ldom_name=ldom1, action=2 ****create_xml_file_4_ldom_action(ENTER), ldom=ldom1, action=stop-domain **send_xml_file_to_ldm(ENTER).. **open_ldm_connection(ENTER) **open_ldm_connection..LDM_INIT_ACK from zeus, Minor sent=0, Minor rcvd=0 **create_pkt_buf(ENTER) **get_response(ENTER) **get_response..received 341 bytes for rsp body **handle_resp(ENTER) **close_ldm_connection..trying to close LDM socket=18 ****parse_xml_get_response_status(ENTER) ****parse_xml_get_response_status.. <response><status> is success DBG: ldomsDomainGetInfo(ENTER) dom=ldom1 DBG: getDomainIndex(ENTER) domID=1, ldom_cnt=4 DBG: getDomainIndex(EXIT) domidx=1 DBG: ldomsDomainGetInfo() domidx=1 DBG: ldomsDomainGetInfo() ldomName=ldom1 DBG: ldomsDomainGetInfo() ldomState=1 --> 2nd time: DBG: ldomsDomainSuspend(ENTER) name=ldom1 **send_ldom_lifecycle_action..(ENTER) ldom_name=ldom1, action=2 ****create_xml_file_4_ldom_action(ENTER), ldom=ldom1, action=stop-domain **send_xml_file_to_ldm(ENTER).. **open_ldm_connection(ENTER) **open_ldm_connection..LDM_INIT_ACK from zeus, Minor sent=0, Minor rcvd=0 **create_pkt_buf(ENTER) **get_response(ENTER) **get_response..received 391 bytes for rsp body **handle_resp(ENTER) **close_ldm_connection..trying to close LDM socket=18 ****parse_xml_get_response_status(ENTER) ****parse_xml_get_response_status.. <response><status>=failure ****parse_xml_get_response_status.. No <resp_msg> tag **send_ldom_active_mgmt.. failure response from received xml Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/console.py", line 390, in control_vm_pause self.vm.suspend() File "/usr/share/virt-manager/virtManager/domain.py", line 365, in suspend self.vm.suspend() File "/usr/lib/python2.4/vendor-packages/libvirt.py", line 350, in suspend if ret == -1: raise libvirtError ('virDomainSuspend() failed', dom=self) libvirt.libvirtError: virDomainSuspend() failed

3 2

[Libvir] Re: Virtualization things.
by Richard W.M. Jones 11 Jul '07

11 Jul '07

[Moved to libvir-list. The original thread was on fedora-devel-list, starting here: https://www.redhat.com/archives/fedora-devel-list/2007-July/thread.html#005…] Till Maas wrote: > On Di Juli 10 2007, Richard W.M. Jones wrote: >> Till Maas wrote: >>> The idea is imho great, but for me with qemu it does not work properly. >> I'd really like to help out here. Did you get any error messages? > > The first problem is, that it seems to be a tool to create persisten virtual > machines, e.g. virtual servers, but most of the time I only want to boot a > live cd, e.g. a Fedora one. But virt-manager seems to demand an virtual HD > drive. I only tested it twice or so, but it looked not promising. The next version of virt-install will support this explicitly. I am reliably assured that it should work in qemu & Xen. Support is not there yet in virt-manager. > What I did so far was creating a new machine with a Fedora Live CD Image and > booted it. When I hit the Pause button, it appeared to be pressed, but > nothing happened. The machine still responded and the following error > appeared on the commandline, where I started virt-manager: > > ------------- > libvir: QEMU error : operation failed: suspend operation failed > Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/console.py", line 389, in > control_vm_pause > self.vm.suspend() > File "/usr/share/virt-manager/virtManager/domain.py", line 365, in suspend > self.vm.suspend() > File "/usr/lib/python2.5/site-packages/libvirt.py", line 350, in suspend > if ret == -1: raise libvirtError ('virDomainSuspend() failed', dom=self) > libvirt.libvirtError: virDomainSuspend() failed operation failed: suspend > operation failed > -------------- This is a bug. Do you know what version of libvirt & virt-manager this happens with? Suspend _ought_ to work with QEMU with libvirt >= 0.2.0. > Then when I shut down the machine and clicked on "run", it did not boot the > ISO Image I selected while creating the machine, but only complained that it > could not boot from HD (which is true, because I did not install anything to > the HD) > > Then I wanted to delete the machine, but the "Delete" button was still greyed > out, even when I shut it down (Imho it should be available all the time and > provide a warning that the machine needs to be shut down before it can be > deleted). When I closed virt-manager and opened it again, then I was able to > delete the machine. > > But I cannot find a way to add an iso image to the machine or make it boot the > iso image I selected at creation time. I haven't played with live CDs & virt-manager at all, but I'll have a go. What live CD were you trying? > Also the network selection seems not to work, when I want to add a network > interface, I can choose between virtual and shared device, but both only have > an empty list, where I have to select something to be able to click > on "Forward". This is another bug. If you get me the version of virt-manager, I'll look into it. > I guess you cannot help here very much, because it seems to me that > virt-manager just needs a lot of coding, to become as userfriendly as > VirtualBox is. 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

4 7

[Libvir] [PATCH] Fix memory leak on virDomainParseXMLDiskDesc()
by Masayuki Sunou 11 Jul '07

11 Jul '07

Hi I found some memory leaks in xml.c --> Missing release of drvType and drvName in virDomainParseXMLDiskDesc(). This patch fixes it. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. -------------------------------------------------------------------------------- Index: src/xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.80 diff -u -p -r1.80 xml.c --- src/xml.c 4 Jul 2007 09:16:23 -0000 1.80 +++ src/xml.c 11 Jul 2007 07:51:17 -0000 @@ -719,6 +719,7 @@ virDomainParseXMLDiskDesc(virConnectPtr int typ = 0; int cdrom = 0; int isNoSrcCdrom = 0; + int ret = 0; type = xmlGetProp(node, BAD_CAST "type"); if (type != NULL) { @@ -768,21 +769,14 @@ virDomainParseXMLDiskDesc(virConnectPtr } if (!isNoSrcCdrom) { virXMLError(conn, VIR_ERR_NO_SOURCE, (const char *) target, 0); - - if (target != NULL) - xmlFree(target); - if (device != NULL) - xmlFree(device); - return (-1); + ret = -1; + goto cleanup; } } if (target == NULL) { virXMLError(conn, VIR_ERR_NO_TARGET, (const char *) source, 0); - if (source != NULL) - xmlFree(source); - if (device != NULL) - xmlFree(device); - return (-1); + ret = -1; + goto cleanup; } /* Xend (all versions) put the floppy device config @@ -861,12 +855,17 @@ virDomainParseXMLDiskDesc(virConnectPtr virBufferAdd(buf, ")", 1); cleanup: - xmlFree(drvType); - xmlFree(drvName); - xmlFree(device); - xmlFree(target); - xmlFree(source); - return (0); + if(drvType) + xmlFree(drvType); + if(drvName) + xmlFree(drvName); + if(device) + xmlFree(device); + if(target) + xmlFree(target); + if(source) + xmlFree(source); + return (ret); } /**

3 2

[Libvir] Howto: install libvirt on Debian Etch (the ugly way)
by Roman Ammann 10 Jul '07

10 Jul '07

Hello list I read on the list that other people tried to install libvirt on Debian Etch. I finally succeeded so I'll post a little Howto. Maybe someone with a better understanding of automake and C stuff knows a nicer way but the ugly folder with the links to the different header files. The start point is a Debian Etch with a running Xen (in my case it's the xen-hypervisor-3.0.3-1-i386-pae package). If you're not using the PAE version of the xen-hypervisor change the "apt-get source" line accordingly. First you will need to install a bunch of development packages apt-get install build-essential libxml2-dev libncurses5-dev apt-get isntall libreadline5-dev python-dev Go to your home directory and install the Xen hypervisor sources cd apt-get source xen-hypervisor-3.0.3-1-i386-pae Create a folder with a bunch of symbolic links. We will use this folder libvirt to find the header files. mkdir libvirt-include cd libvirt-include/ ln -s /root/xen-3.0-3.0.3-0/xen/include/public/xen.h ln -s /root/xen-3.0-3.0.3-0/tools/xenstore/xs.h ln -s /root/xen-3.0-3.0.3-0/tools/xenstore/xs_lib.h ln -s /root/xen-3.0-3.0.3-0/xen/include/public xen ln -s /root/xen-3.0-3.0.3-0/linux-2.6-xen-sparse/include/xen/public/ xen/linux Configure the dynamic linker that it will be able to find the libxenstore library echo '/usr/lib/xen-3.0.3-1/lib' > /etc/ld.so.conf.d/i486-linux-gnu.conf ldconfig Go to your home directory, download an extract the libvirt source package cd wget http://libvirt.org/sources/libvirt-0.2.3.tar.gz tar xvfz libvirt-0.2.3.tar.gz cd libvirt-0.2.3 Configure, build and install the libvirt CFLAGS="-fno-stack-protector -I/root/libvirt-include -L/usr/lib/xen-3.0.3-1/lib" ./configure --with-xen --without-qemu make make install Enable the Unix socket server for xend. Edit /etc/xen/xend-config.sxp and change the line #(xend-unix-server no) to (xend-unix-server yes) Restart your Xen-Daemon /etc/init.d/xend restart If everything work you should see your running virtual machines when you enter virsh list Regards Roman

4 3

[Libvir] Updating an existing libvirt installation
by Omer Khalid 10 Jul '07

10 Jul '07

Hi, I am wondering if its possible to upgrade an existing libvirt installation to a newer version. Actually one of my clients is still have libvirt-0.1.8while my software works ver 0.1.9 upwards. Many thanks for your help, Cheers Omer -- ---------------------------------------------------------- CERN – European Organization for Nuclear Research, IT Department, CH-1211 Geneva 23, Switzerland Phone: +41 (0) 22 767 2224 Fax: +41 (0) 22 766 8683 E-mail : Omer.Khalid(a)cern.ch Homepage: http://cern.ch/Omer.Khalid

4 4

[Libvir] Release of libvirt-0.3.0
by Daniel Veillard 09 Jul '07

09 Jul '07

Considering the amount of changes available in CVS, a release was in order plus increasing the minor release number was also making sense. The package is available at ftp://libvirt.org/libvirt/ The main change is the secure remote support at the API level thanks to Richard Jones, look at the specific page to get informations on what is available and how to set up the certificates needed for authentication: http://libvirt.org/remote.html it's worth also looking at the URI documentation to see how to build the connection URI strings http://libvirt.org/uri.html Last thing, the background daemon has been renamed between versions 0.2.3 and the current version from libvirt_qemud to libvirtd since it now also serve for the remote support, so when upgrading the package it's a good idea to stop first the libvirt service, do the upgrade and then restart the service otherwise you may end up with a old version of the daemon running. This release includes a lot of changes: + Secure Remote support (Richard Jones). See the remote page of the documentation + Documentation: - remote support (Richard Jones) - description of the URI connection strings (Richard Jones) - update of virsh man page - matrix of libvirt API/hypervisor support with version informations (Richard Jones) + Bug fixes: - examples Makefile.am generation (Richard Jones) - SetMem fix (Mark Johnson) - URI handling and ordering of drivers (Daniel Berrange) - fix virsh help without hypervisor (Richard Jones) - id marshalling fix (Daniel Berrange) - fix virConnectGetMaxVcpus on remote (Richard Jones) - avoid a realloc leak (Jim Meyering) - scheduler parameters handling for Xen (Richard Jones) - various early remote bug fixes (Richard Jones) - remove virsh leaks of domains references (Masayuki Sunou) - configCache refill bug (Richard Jones) - fix XML serialization bugs + Improvements: - QEmu switch to XDR-based protocol (Dan Berrange) - device attach/detach commands (Masayuki Sunou) - OCaml bindings (Richard Jones) - new entry points virDomainGetConnect and virNetworkGetConnect useful for bindings (Richard Jones) - reunitifaction of remote and qemu daemon under a single libvirtd with a config file (Daniel Berrange) + Cleanups: - parsing of connection URIs (Richard Jones) - messages from virsh (Saori Fukuta) - Coverage files (Daniel Berrange) - Solaris fixes (Mark Johnson) - avoid [r]index calls (Richard Jones) - release information in Xen backend - virsh cpupin command cleanups (Masayuki Sunou) - xen:/// suppport as standard Xen URI (Richard Jones and Daniel Berrange) - improve driver selection/decline mechanism (Richard Jones) - error reporting on XML dump (Richard Jones) - Remove unused virDomainKernel structure (Richard Jones) - daemon event loop event handling (Daniel Berrange) - various unifications cleanup in the daemon merging (Daniel Berrange) - internal file and timer monitoring API (Daniel Berrange) - remove libsysfs dependancy - call brctl program directly (Daniel Berrange) - virBuffer functions cleanups (Richard Jones) - make init script LSB compliant - error handling on lookup functions (Richard Jones) - remove internal virGetDomainByID (Richard Jones) - revamp of xen subdrivers interfaces (Richard Jones) + Localization updates Thanks to everybody who helped for this release, with code, bug reports or suggestions ! 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/

1 0

[Libvir] XML escaping patch
by Daniel Veillard 06 Jul '07

06 Jul '07

This is related to bug #206653 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=206653 basically we are very optimistic when generating the XML files, and sometimes this can break. The most common case is if some string inherited from the user input or some other config file embeds one of > < or & , another one would be if the strings are containing character outside of ACSII range and not encoded in UTF-8. We can at least cope with the easy case of escaping the 3 characters. This patch adds a simple buffer printing routing working with a simple string argument, and use it for the 2 cases where I think it's most likely to be needed i.e. cmdline and bootloader_args. There is a number of places where paths are used and the user might use weird character names, but since those cases can't be handled properly (you can't change that path or try to convert encoding on the fly since we can't guess reliably which one is used) I didn't tried to change those. This makes for a relatively simple patch which should IMHO cover most case where we may break while we really should not. 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/

3 7

[Libvir] Some doubts for OpenVZ
by Shuveb Hussain 06 Jul '07

06 Jul '07

Hi, I have some basic doubts. 1. The OpenVZ system has one config file per VM which contains all the VM's parameters. So, during libvirt start-up, these files can be read, or openvz utils can be popened() to get information regarding these VMs. Is there a necessity to have per-vm config files in libvirt for the OpenVZ VMs? I understand UUIDs are used to identify each of the running VMs. Where will these values persist? Can I do away with UUIDs for OpenVZ and avoid the libvirt specific config file? 2. In OpenVZ, there is just a VPS ID/Name. There is no temporary reference like 'id'. For example QEMU is using the process PID. There is no such notion for OpenVZ. In that case, can I make 'name' and 'id' same for OpenVZ? Thanks, -- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com

3 5

[Libvir] virsh vcpupin does not work with xend
by Saori Fukuta 06 Jul '07

06 Jul '07

Hi, The virsh vcpupin command does not work when it uses Xend(xend_internal.c). HV(xen_internal.c) works fine. I'm testing on Xen3.1.0(hypervisor_version=2, dom_interface_version=5, xendConfigVersion=4), and using current libvirt(ChangeLog revision 1.546). To solve this problem, I got the xend debug information and compared that. * in the case of executing "virsh vcpupin 63 7 1" * [2007-05-29 09:33:20 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'str'>) * in the case of executing "xm vcpu-pin 63 7 1" * [2007-05-29 09:33:32 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'list'>) There is one different thing. The type of cpumap is str when executing virsh command, but the type of cpumap is list when executing xm command. Do you have any idea ? Thanks, Saori Fukuta

2 4

[Libvir] LSBization of libvirt init script
by Daniel Veillard 06 Jul '07

06 Jul '07

Small patch applied to qemud/libvirtd.init.in: - adds an LSB compliant header - add a couple of LSB defined functions - fixes the name in the chkconfig comments Hopefully it's correct :-) 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/

2 2

[Libvir] [Q]Will virConnectNumOfNetworks and virConnectNumOfDefinedNetworks be supported by Xen ?
by S.Sakamoto 06 Jul '07

06 Jul '07

Hi, When I use virt-manager that is connected by xen, the following error is given at every monitoring. libvir: Error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvir: Error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks Therefore I have a question. Will virConnectNumOfNetworks and virConnectNumOfDefinedNetworks be supported by Xen ? When is it if supported ? Thanks, Shigeki Sakamoto.

4 8

Re: [Libvir] [RFC]OpenVZ XML def
by Richard W.M. Jones 05 Jul '07

05 Jul '07

Shuveb Hussain wrote: [...] OK, but still let us know if there are particular things which are a problem to parse. Also if you can just follow-up sometime with example output from OpenVZ commands. I'd like to see that, since I tried to get OpenVZ working on my machine, but it broke down (unrelated to OpenVZ :-) 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

1 0

Re: [Libvir] [RFC]OpenVZ XML def
by Richard W.M. Jones 05 Jul '07

05 Jul '07

Shuveb Hussain wrote: >> >> Daemon though? Can't the libvirt code just invoke the OpenVZ commands >> directly? > > Yeah, that is very much possible. But if it were a daemon, it could be > a Python daemon, since text processing is much simpler and I don't > have to use the str*( ) funcs in C. What is your comment? I'm a big advocate of using a sane language instead of C, but libvirt is written in C for better or worse. The problem with a separate daemon is management of that daemon. Something needs to start it and stop it, it needs to have sockets with the right permissions and so on. What happens if the process runs and can't find the daemon? What is the path to the socket? etc. etc. At the moment we have two daemons - the qemu daemon (which has two separate functions intertwined), and a remote daemon (necessary, because there's no other way to communicate to a remote machine). One idea would be to have the Python code fork off from the main program and communicate over a pipe. With this, there is no daemon management problem. +----------------+ | Program | | - - - - - - - -| | libvirt | +----------------+ | | fork(2) and pipe(2) | +-------------+ | Python code | +-------------+ But I'm not the person who ultimately decides what would be acceptable in libvirt. You'd need to get general agreement on the best way to do this. 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 7

[Libvir] [PATCH] virDomainLookup* functions raise VIR_ERR_NO_DOMAIN if the domain doesn't exist
by Richard W.M. Jones 04 Jul '07

04 Jul '07

The patches that I'm going to follow up with change virDomainLookup* functions so that they raise VIR_ERR_NO_DOMAIN where a domain doesn't exist (but there is no other error), else raise some other error where there's an actual error occuring. This will allow wrappers in other languages to distinguish the three cases found / not found / error. 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 20

[Libvir] [PATCH] Fix xm_internal configCache
by Richard W.M. Jones 04 Jul '07

04 Jul '07

This patch: (1) Fixes inactive domains over remote. The real cause of this error turned out to be that after configCache hash is created, the last refresh date wasn't reset, so a subsequent call to xenXMConfigCacheRefresh might not actually repopulate the cache. This only affects the remote case, because only in the remote case do we have a long running process (libvirtd) which closes and reopens xm_internal.c, so this code had never been exercised before. It also explains why the bug was annoyingly intermittent. If you wait >= 10 seconds during testing, then the cache does get refilled, so the bug is hidden. (2) Adds error messages to xenXMConfigCacheRefresh. (3) As Daniel Veillard suggested, change the obscure !nconnections-- condition to two explicit statements. (4) In xenXMOpen, change the condition from nconnections == 0 to configCache == NULL, to remove the implicit dependency between the two variables. 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 2

[Libvir] [PATCH] xend 404 errors return VIR_ERR_NO_DOMAIN
by Richard W.M. Jones 04 Jul '07

04 Jul '07

(1) Check for 404 errors from xend and turn them into VIR_ERR_NO_DOMAIN (currently they are VIR_ERR_POST_FAILED). You'll typically see this when you have a handle to a domain, but the underlying domain is shutdown, as in this example: $ python Python 2.4.3 (#1, Dec 11 2006, 11:39:03) [GCC 4.1.1 20061130 (Red Hat 4.1.1-43)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import libvirt >>> conn = libvirt.open ("xen+tls:///") >>> dom = conn.lookupByName ("fc6_6") >>> dom.suspend () 0 >>> dom.resume () 0 #### here, I shut down the domain using 'xm' >>> dom.suspend () libvir: Xen Daemon error : Domain not found: No such domain fc6_6 Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/rjones/local/lib/python2.4/site-packages/libvirt.py", line 359, in suspend if ret == -1: raise libvirtError ('virDomainSuspend() failed', dom=self) libvirt.libvirtError: virDomainSuspend() failed Domain not found: No such domain fc6_6 (2) There was a case where xend was returning an error, but we didn't translate that into an error return code (-1). I'm sure this is an oversight, and the patch fixes it. 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 1

[Libvir] [PATCH] Fix callers to virGetDomain and virGetNetwork
by Richard W.M. Jones 04 Jul '07

04 Jul '07

(1) Removes virGetDomainByID. This function was neither used nor exported. (2) virGetDomain sets a virterror connection error whenever anything bad happens (realistically malloc failure is the only thing that can go wrong). Therefore callers do not need to set virterror if the function returns NULL. The patch fixes these callers. (3) Same as (2), for virGetNetwork. 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 1

[Libvir] Proposal: Python bindings should turn NO_DOMAIN/NO_NETWORK errors in KeyError exceptions
by Richard W.M. Jones 04 Jul '07

04 Jul '07

I propose that we should change the Python bindings so that when the virterror errors VIR_ERR_NO_DOMAIN and VIR_ERR_NO_NETWORK occur in the lookup* functions only, should cause KeyError to be raised. According to: http://docs.python.org/lib/module-exceptions.html "[KeyError is] raised when a mapping (dictionary) key is not found in the set of existing keys." I've already changed the OCaml bindings so that these errors get converted into Not_found exception, which is the "natural" exception for when something is looked up and not found. 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 2

[Libvir] [PATCH] virNetworkLookup* functions should raise VIR_ERR_NO_NETWORK
by Richard W.M. Jones 04 Jul '07

04 Jul '07

This small patch changes the virNetworkLookup* functions so that they raise VIR_ERR_NO_NETWORK in the case where the network cannot be found (as opposed to some other error). It requires the VIR_ERR_NO_DOMAIN patches (see previous thread) to be applied first, or at least patch #1 from that series. 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 2

[Libvir] [PATCH] Readd buffer errors & some cleanups
by Richard W.M. Jones 04 Jul '07

04 Jul '07

This readds some error checking of the returns from virBuffer* functions, removes need for is_blank (a _GNU_SOURCE extension), and a couple of other very minor cleanups. 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 4

[Libvir] PATCH: Fix remote driver to handle network API for local non-QEMU
by Daniel P. Berrange 04 Jul '07

04 Jul '07

The remote_internal.c code is basically a no-op in its remoteNetworkOpen method. This means the remote driver will only handle the networking APIs, if it is also handling the main domain APIs. This works fine if connecting to a remote URI, or if using QEMU URIs, but it does not work if using the test or Xen drivers. To make this work the remoteNetworkOpen method needs to open a connection to the remote daemon IIF the remoteOpen method did not already open one. So the attached patch adds the neccessary logic in remoteNetworkOpen. It also adds code to remoteNetworkClose to make it shutdown& free the connection IIF it was opened by the remoteNetworkOpen method. This is what the extra 'networkOnly' field in the 'struct private_data' is used to check. Second, all of the implementations of virNetwork* APIs in the remote_internal.c driver must use the 'struct private_data *' from networkPrivateData field in virConnectPtr, not the 'privateData' field. This is because the 'privateData' field is probably storing data related to the Xen or Test drivers. Third, this also fixes the qemu_driver.c which incorrectly used the privateData field insteadof the networkPrivateData field for 2 of the networking APIs, and finally makes sure the qemu_driver.c also acccepts the use of qemu:///session APIs for root user. 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 -=|

3 5

[Libvir] Proposal: libvirt should remove or rename a save file after a successful restore
by Richard W.M. Jones 02 Jul '07

02 Jul '07

Chris Lalancette found this problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246105 <quote> Once an "xm restore" has successfully completed, the -save file that it came from should really be deleted. Restoring a domain a second time from the same save file will result in disk corruption; the kernel VM state (in the saved file) will be in an inconsistent state with respect to what is actually on disk (in the domain disk file). The only valid use I can see for the -save file after a restore is possibly for some crash analysis, but even that could be worked around by renaming the save file after a success. In particular, I just ran into this situation (and I'm worried customers might do the same): [and then he goes on to describe a scenario in which you can commonly hit this situation] </quote> So the obvious and simple solution, it seems to me, is just to change libvirt.c:virDomainRestore so that if the driver underneath it returns from the restore without error, then we either remove or rename the restore file. It's a trivial patch -- what do people think? My thoughts: * Removing the file might seem quite abrupt/unexpected, and there is the possibility of data loss. * You have to rename the file as a hidden file (dotfile) in order for xendomains to ignore it. However these files are big and having large, hidden files which build up in number over time sounds like it could be a bad thing. * This might be considered a significant behaviour change. * It's easier to handle this for the remote case if we make the change inside libvirt, rather than in virsh etc. 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 2

[Libvir] Cleanup patch
by Daniel Veillard 29 Jun '07

29 Jun '07

Enclosed is a cleanup patch I applied, it corrects the XML api generation, fixes warning in the XSLT stylesheet, add comments to a number of internal functions, makes most function of the QEmu back-end static, fixes a few bugs found in the way. 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/

2 2

[Libvir] re: hvsupport html page
by Philippe Berthault 29 Jun '07

29 Jun '07

A great work ! This new help page will be very useful for all developers :-) Thanks a lot. P.Berthault.

1 0

[Libvir] [PATCH] Do check the UUID in __virGetDomain()
by Masayuki Sunou 29 Jun '07

29 Jun '07

Hi This patch adds checking the UUID in __virGetDomain(). Now, the UUID of domain is wrong in the following operations. 1. Start virsh in interactive mode. 2. Execute domuuid to the domain 3. Execute undefine to the domain which executed domuuid in 2. 4. Create the domain whose name is same as the domain that executed undefine. 5. Execute domuuid for the new domain This patch can fix it. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. -------------------------------------------------------------------------------- Index: src/hash.c =================================================================== RCS file: /data/cvs/libvirt/src/hash.c,v retrieving revision 1.22 diff -u -p -r1.22 hash.c --- src/hash.c 8 May 2007 10:53:27 -0000 1.22 +++ src/hash.c 7 Jun 2007 02:08:41 -0000 @@ -758,8 +758,14 @@ __virGetDomain(virConnectPtr conn, const ret = (virDomainPtr) virHashLookup(conn->domains, name); if (ret != NULL) { - /* TODO check the UUID */ - goto done; + if (memcmp(ret->uuid, uuid, 16)) { + if (virFreeDomain(conn, ret, 0) < 0) { + xmlMutexUnlock(conn->hashes_mux); + return(NULL); + } + } else { + goto done; + } } /* @@ -813,7 +819,7 @@ error: * Returns the reference count or -1 in case of failure. */ int -virFreeDomain(virConnectPtr conn, virDomainPtr domain) { +virFreeDomain(virConnectPtr conn, virDomainPtr domain, int lock) { int ret = 0; if ((!VIR_IS_CONNECT(conn)) || (!VIR_IS_CONNECTED_DOMAIN(domain)) || @@ -821,7 +827,8 @@ virFreeDomain(virConnectPtr conn, virDom virHashError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__); return(-1); } - xmlMutexLock(conn->hashes_mux); + if (lock) + xmlMutexLock(conn->hashes_mux); /* * decrement the count for the domain @@ -853,13 +860,14 @@ virFreeDomain(virConnectPtr conn, virDom if (conn->domains != NULL) virHashFree(conn->domains, (virHashDeallocator) virDomainFreeName); - if (conn->hashes_mux != NULL) + if (conn->hashes_mux != NULL && lock) xmlFreeMutex(conn->hashes_mux); free(conn); return(0); done: - xmlMutexUnlock(conn->hashes_mux); + if (lock) + xmlMutexUnlock(conn->hashes_mux); return(ret); } Index: src/internal.h =================================================================== RCS file: /data/cvs/libvirt/src/internal.h,v retrieving revision 1.41 diff -u -p -r1.41 internal.h --- src/internal.h 8 May 2007 10:53:27 -0000 1.41 +++ src/internal.h 7 Jun 2007 02:08:41 -0000 @@ -202,7 +202,7 @@ virDomainPtr __virGetDomain (virConnectP const char *name, const unsigned char *uuid); int virFreeDomain (virConnectPtr conn, - virDomainPtr domain); + virDomainPtr domain, int lock); virDomainPtr virGetDomainByID(virConnectPtr conn, int id); virNetworkPtr __virGetNetwork (virConnectPtr conn, Index: src/libvirt.c =================================================================== RCS file: /data/cvs/libvirt/src/libvirt.c,v retrieving revision 1.73 diff -u -p -r1.73 libvirt.c --- src/libvirt.c 5 Jun 2007 12:06:08 -0000 1.73 +++ src/libvirt.c 7 Jun 2007 02:08:41 -0000 @@ -730,7 +730,7 @@ virDomainFree(virDomainPtr domain) virLibDomainError(domain, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); return (-1); } - if (virFreeDomain(domain->conn, domain) < 0) + if (virFreeDomain(domain->conn, domain, 1) < 0) return (-1); return(0); } Index: src/qemu_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_internal.c,v retrieving revision 1.25 diff -u -p -r1.25 qemu_internal.c --- src/qemu_internal.c 5 Jun 2007 12:06:08 -0000 1.25 +++ src/qemu_internal.c 7 Jun 2007 02:08:42 -0000 @@ -906,7 +906,7 @@ static int qemuUndefine(virDomainPtr dom } cleanup: - if (virFreeDomain(dom->conn, dom) < 0) + if (virFreeDomain(dom->conn, dom, 1) < 0) ret = -1; return ret; Index: src/xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.116 diff -u -p -r1.116 xend_internal.c --- src/xend_internal.c 5 Jun 2007 12:06:09 -0000 1.116 +++ src/xend_internal.c 7 Jun 2007 02:08:42 -0000 @@ -1900,7 +1900,7 @@ error: virXendError(conn, VIR_ERR_INTERNAL_ERROR, _("failed to parse Xend domain information")); if (ret != NULL) - virFreeDomain(conn, ret); + virFreeDomain(conn, ret, 1); return(NULL); } #endif /* !PROXY */ @@ -3055,7 +3055,7 @@ xenDaemonCreateLinux(virConnectPtr conn, /* Make sure we don't leave a still-born domain around */ if (dom != NULL) { xenDaemonDomainDestroy(dom); - virFreeDomain(dom->conn, dom); + virFreeDomain(dom->conn, dom, 1); } if (name != NULL) free(name);

4 8

[Libvir] request for libvirt documentation improvement
by Philippe Berthault 29 Jun '07

29 Jun '07

The documentation of libvirt doesn't indicate which functions are for Xen or QEMU or both. The only way to know that, is by searching in libvirt sources. It would be interesting for libvirt users to add in the documentation, for each function, a mention such as "QEMU only", "Xen(TM) only", "QEMU and Xen(TM)", etc.. Regards. Libvirt 0.2.3 functions dedicated to QEMU only: virConnectListDefinedNetworks virConnectListNetworks virConnectNumOfDefinedNetworks virConnectNumOfNetworks virDomainGetAutostart virDomainSetAutostart virNetworkCreate virNetworkCreateXML virNetworkDefineXML virNetworkDestroy virNetworkFree virNetworkGetAutostart virNetworkGetBridgeName virNetworkGetName virNetworkGetUUID virNetworkGetUUIDString virNetworkGetXMLDesc virNetworkLookupByName virNetworkLookupByUUID virNetworkLookupByUUIDString virNetworkSetAutostart virNetworkUndefine Libvirt 0.2.3 functions dedicated to Xen(TM) only: virConnectGetMaxVcpus virConnectGetType virDomainAttachDevice virDomainCoreDump virDomainDetachDevice virDomainGetMaxMemory virDomainGetSchedulerParameters virDomainGetSchedulerType virDomainPinVcpu virDomainReboot virDomainSetMaxMemory virDomainSetMemory virDomainSetSchedulerParameters virDomainSetVcpus

6 10

[Libvir] Proposal: New virDomainLookup function to indicate Not found vs Error
by Richard W.M. Jones 29 Jun '07

29 Jun '07

virt-install has some code which waits for a domain to appear just after it has been created. It looks like the loop attached to the end of this email, and is functional but has two problems. Problem (1) is that self.conn.lookupByName doesn't distinguish between a "Not found" domain and an actual error. For example there is no way to tell the difference between being unable to contact xend (an actual error), and being able to contact xend, but xend not being able to find the domain (not found). As shown here: >>> import libvirt >>> conn = libvirt.open ("xen+tls:///") >>> d = conn.lookupByName ("Domain-0") >>> d = conn.lookupByName ("doesnotexist") [...] libvirt.libvirtError: virDomainLookupByName() failed then I deliberately kill the remote daemon: >>> d = conn.lookupByName ("doesnotexist") libvir: Remote error : Error in the push function. [...] The first exception is a Not found condition (not an error) whereas the second is an error. Problem (2) is that virterror is over anxious to print error messages to stderr, even if the caller can handle them and even if (as in the Not found case) they don't indicate errors. In practical terms this means that the virt-install loop attached below may print out 1 or 2 error messages even when it is functioning normally. You'll see an error like this appearing [sic]: libvir: Xen Daemon error : GET operation failed: Since it's difficult to change the LookupBy* functions without changing the ABI, I suspect that the best thing to do is going to be to add a new call with better semantics. Therefore I suggest: virDomainPtr * virDomainLookup (virConnectPtr conn, int flags, int id, char *str, int *error); where flags is one of: VIR_LOOKUP_BY_ID, VIR_LOOKUP_BY_NAME, VIR_LOOKUP_BY_UUID or VIR_LOOKUP_BY_UUID_STRING The return values are: ret = domain, *error = 0 => found it ret = NULL, *error = 0 => not found ret = NULL, *error = 1 => error (check virterror) Addition 1: There would be a similar function virNetworkLookup, but without needing the 'id' parameter because networks don't have IDs. Addition 2: Change the driver internals so that they don't call virterror in the not found case. (This requires quite a bit of rejigging in xend_internal, but is not too hard). Addition 3: Language bindings could be modified to detect this function and if present change their existing LookupBy* functions to use the new interface. Thoughts? Rich. ---------------------------------------------------- This is the troublesome loop: logging.debug("Created guest, looking to see if it is running") # sleep in .25 second increments until either a) we find # our domain or b) it's been 5 seconds. this is so that # we can try to gracefully handle domain creation failures num = 0 d = None while num < (5 / .25): # 5 seconds, .25 second sleeps try: d = self.conn.lookupByName(self.name) break except libvirt.libvirtError, e: logging.debug("No guest running yet " + str(e)) pass num += 1 time.sleep(0.25) -- 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 2

[Libvir] PATCH 0/20: Re-factor libvirtd / QEMU driver
by Daniel P. Berrange 28 Jun '07

28 Jun '07

The work to refactor the QEMU driver to use the regular libvirt driver API is now complete. The next 20 (!) patches provide fairly fine-grained steps refactoring the code. Aside from that which adds an event loop, and the very last one, they should all be pretty much straightforward refactoring with no functional change. With this patch series fully applied there is now only a single daemon which can serve both remote & QEMU drivers in one go, with no deadlock issues. 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 -=|

3 54

[Libvir] libvirt 0.1.8 Help
by Omer Khalid 27 Jun '07

27 Jun '07

Hi, I have the following code working on libvirt 0.1.9: ######################################## conn = libvirt.openReadOnly(None) if conn == None: print 'Failed to open connection to the hypervisor' #sys.exit(1) try: domains = conn.listDomainsID() num = conn.numOfDomains() except: print 'Failed to find the list of domains' for i in range(num): try: dom0 = conn.lookupByID(domains[i]) domInfo = dom0.info() except: print "Unexpected error:", sys.exc_info() ############################################## For legacy reason, I have to get it working on libvirt 0.1.8 but I am constantly getting the following error: Unexpected error: (<class libvirt.libvirtError at 0xb7f49f2c>, < libvirt.libvirtError instance at 0xb7f4f2cc>, <traceback object at 0xb7f44c5c>) Any help would be much appreciated! Cheers Omer -- ---------------------------------------------------------- CERN – European Organization for Nuclear Research, IT Department, CH-1211 Geneva 23, Switzerland Phone: +41 (0) 22 767 2224 Fax: +41 (0) 22 766 8683 E-mail : Omer.Khalid(a)cern.ch Homepage: http://cern.ch/Omer.Khalid

3 4

[Libvir] [PATCH] Move common buffer code to lib/ directory
by Richard W.M. Jones 26 Jun '07

26 Jun '07

I haven't quite got to my goal of removing _GNU_SOURCE (yet), but this patch along the way creates a lib/ subdirectory and moves the common buffer code (from qemud/buf.[ch] and in src/xml.[ch]) there. There are many, many places which call the buffer functions without checking the return value. I have manually verified / fixed up the calls which do bother to check return values, but not added any more checks where they don't. 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 2

[Libvir] [PATCH] Add virConnectGetHostname and virConnectGetURI calls, virsh commands, and some related fixes
by Richard W.M. Jones 26 Jun '07

26 Jun '07

This patch adds two calls: /** + * virConnectGetHostname: + * @conn: pointer to a hypervisor connection + * + * This returns the system hostname on which the hypervisor is + * running (the result of the gethostname(2) system call). If + * we are connected to a remote system, then this returns the + * hostname of the remote system. + * + * Returns the hostname which must be freed by the caller, or + * NULL if there was an error. + */ +char * +virConnectGetHostname (virConnectPtr conn) and: +/** + * virConnectGetURI: + * @conn: pointer to a hypervisor connection + * + * This returns the URI (name) of the hypervisor connection. + * Normally this is the same as or similar to the string passed + * to the virConnectOpen/virConnectOpenReadOnly call, but + * the driver may make the URI canonical. If name == NULL + * was passed to virConnectOpen, then the driver will return + * a non-NULL URI which can be used to connect to the same + * hypervisor later. + * + * Returns the URI string which must be freed by the caller, or + * NULL if there was an error. + */ +char * +virConnectGetURI (virConnectPtr conn) It also fixes a kind of accidental memory leak which turns out not to be a memory leak. In the current version of libvirt CVS, when using remote connections, remote's private data is not freed by remote_internal.c. However it turns out that it _is_ freed by qemuNetworkClose. Obviously some confusion there, but this patch fixes that. (Fixing that is a dependency of this patch, which is why the two are done together in one patch). I've added "virsh hostname" and "virsh uri" commands: $ src/virsh -c test:///default uri test:///default $ src/virsh -c test:///default hostname localhost.localdomain (Yeah, I haven't set the hostname on this machine ...) I've updated the Xen, test and remote drivers to support the calls. However I didn't update qemu because of Dan's big changes to qemu. Once we have decided whether to put in Dan's changes, I'll go back and implement this for qemu. (I'm actually not sure I would need to implement them, if remote supports the calls already). I haven't updated the Python bindings, but will do so next. I decided not to implement the proposed virConnectGetTransport call because I think it needs more thought. It would obviously be useful to find out whether the current connection is local or remote, encrypted or unencrypted, authenticated or unauthenticated, because all of these things could be usefully communicated back to the user by icons in virt-manager. Simply returning the transport name doesn't really do this. The user might also want to find out _how_ the session is encrypted (what TLS parameters are in use), and again a simple string can't do that. Before applying this patch you will need to do: rm qemud/remote_dispatch_localvars.h \ qemud/remote_dispatch_proc_switch.h \ qemud/remote_dispatch_prototypes.h \ qemud/remote_protocol.c \ qemud/remote_protocol.h and after applying you will need to do: make -C qemud remote_protocol.c 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 5