- Devel - libvirt List Archives

[libvirt] libvirt.py
by Fred Leeflang 27 Sep '09

27 Sep '09

Hello, Just getting started on this and checked out the source from git. Ran autogen.sh, configure, make, make install and it doesn't seem to automatically install libvirt.py. The generated Makefile in python/ has these lines commented out: #GENERATED = libvirt-export.c \ # libvirt.c \ # libvirt.h \ # libvirt.py Am I perhaps missing some python_includes? From what I can tell, WITH_PYTHON_TRUE only gets set to # if some includes are not there. I'm trying to build this on Debian Lenny with Python 2.5.2

2 1

[libvirt] [PATCH] Remove hand-crafted UUID parsers
by Daniel P. Berrange 25 Sep '09

25 Sep '09

* src/libvirt.c: Remove hand-crafted UUID parsers in favour of calling virParseUUID --- src/libvirt.c | 56 +++++--------------------------------------------------- 1 files changed, 5 insertions(+), 51 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 9fb0617..74d62a4 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -1839,26 +1839,11 @@ virDomainLookupByUUIDString(virConnectPtr conn, const char *uuidstr) virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__); goto error; } - /* XXX: sexpr_uuid() also supports 'xxxx-xxxx-xxxx-xxxx' format. - * We needn't it here. Right? - */ - ret = sscanf(uuidstr, - "%02x%02x%02x%02x-" - "%02x%02x-" - "%02x%02x-" - "%02x%02x-" - "%02x%02x%02x%02x%02x%02x", - raw + 0, raw + 1, raw + 2, raw + 3, - raw + 4, raw + 5, raw + 6, raw + 7, - raw + 8, raw + 9, raw + 10, raw + 11, - raw + 12, raw + 13, raw + 14, raw + 15); - - if (ret!=VIR_UUID_BUFLEN) { + + if (virUUIDParse(uuidstr, uuid) < 0) { virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__); goto error; } - for (i = 0; i < VIR_UUID_BUFLEN; i++) - uuid[i] = raw[i] & 0xFF; return virDomainLookupByUUID(conn, &uuid[0]); @@ -5038,26 +5023,10 @@ virNetworkLookupByUUIDString(virConnectPtr conn, const char *uuidstr) goto error; } - /* XXX: sexpr_uuid() also supports 'xxxx-xxxx-xxxx-xxxx' format. - * We needn't it here. Right? - */ - ret = sscanf(uuidstr, - "%02x%02x%02x%02x-" - "%02x%02x-" - "%02x%02x-" - "%02x%02x-" - "%02x%02x%02x%02x%02x%02x", - raw + 0, raw + 1, raw + 2, raw + 3, - raw + 4, raw + 5, raw + 6, raw + 7, - raw + 8, raw + 9, raw + 10, raw + 11, - raw + 12, raw + 13, raw + 14, raw + 15); - - if (ret!=VIR_UUID_BUFLEN) { + if (virUUIDParse(uuidstr, uuid) < 0) { virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__); goto error; } - for (i = 0; i < VIR_UUID_BUFLEN; i++) - uuid[i] = raw[i] & 0xFF; return virNetworkLookupByUUID(conn, &uuid[0]); @@ -8887,26 +8856,11 @@ virSecretLookupByUUIDString(virConnectPtr conn, const char *uuidstr) virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__); goto error; } - /* XXX: sexpr_uuid() also supports 'xxxx-xxxx-xxxx-xxxx' format. - * We needn't it here. Right? - */ - ret = sscanf(uuidstr, - "%02x%02x%02x%02x-" - "%02x%02x-" - "%02x%02x-" - "%02x%02x-" - "%02x%02x%02x%02x%02x%02x", - raw + 0, raw + 1, raw + 2, raw + 3, - raw + 4, raw + 5, raw + 6, raw + 7, - raw + 8, raw + 9, raw + 10, raw + 11, - raw + 12, raw + 13, raw + 14, raw + 15); - - if (ret!=VIR_UUID_BUFLEN) { + + if (virUUIDParse(uuidstr, uuid) < 0) { virLibConnError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__); goto error; } - for (i = 0; i < VIR_UUID_BUFLEN; i++) - uuid[i] = raw[i] & 0xFF; return virSecretLookupByUUID(conn, &uuid[0]); -- 1.6.2.5

3 3

[libvirt] Virsh migrate --live fails
by Subba Rao, Sandeep M (STSD) 25 Sep '09

25 Sep '09

Hi, I'm trying to live move a domU using virsh migrate command: [root@RHEL53Xen1 ~]# xm list Name ID Mem(MiB) VCPUs State Time(s) Copy_RHELVM3 1 511 1 -b---- 898.3 Domain-0 0 1507 4 r----- 133702.5 [root@RHEL53Xen1 ~]# virsh migrate --live Copy_RHELVM3 xen+ssh://15.154.102.20 error: server closed connection [root@RHEL53Xen1 ~]# However the same works using xm migrate --live. The source and the destination are RHEL 5.3 Xen hosts. Libvirt: [root@RHEL53Xen1 ~]# rpm -qa | grep libvirt libvirt-0.3.3-14.el5 libvirt-devel-0.3.3-14.el5 libvirt-cim-0.5.1-4.el5 libvirt-python-0.3.3-14.el5 Xen: [root@RHEL53Xen1 ~]# rpm -qa | grep xen xen-3.0.3-80.el5 xen-libs-3.0.3-80.el5 xen-devel-3.0.3-80.el5 kernel-xen-2.6.18-128.el5 I was earlier getting the error - "can't connect: Name or service not known". So, installed libvirt-0.6.4 as mentioned in the following link: https://bugzilla.redhat.com/show_bug.cgi?id=348861 After installing libvirt-0.6.4, I'm getting "server closed connection" error. Any help is much appreciated. Thanks, Sandeep

2 2

[libvirt] node device devicekit backend
by Dave Allan 25 Sep '09

25 Sep '09

I've been looking at implementing a libudev backed node device, and I noticed that the devicekit node device backend doesn't build. Since I believe DeviceKit is deprecated for this sort of use, and AFAIK the DeviceKit support was never functionally equivalent to the HAL support, I'm wondering if we can just drop DeviceKit support. It also drags in glib, which is a separate problem. Opinions? Dave

2 1

[libvirt] Miscellaneous fixes to build with -Werror
by Charles Duffy 25 Sep '09

25 Sep '09

HACKING suggests compiling with --enable-compile-warnings=error before submitting any patches; however, current master fails for me on this account (CentOS 5.3; gcc 4.1.2). Please see attached. I suspect most of these should be uncontroversial -- but wonder if perhaps virStrcpy uses would be better converted to virStrcpyStatic rather than adding virStrcpy to the symbol list as done here, and am curious about whether the need for explicit initialization to silence a warning regarding qemudSetLogging's log_level indicates a bug in the macro later used to assign that value.

4 6

[libvirt] Some problem with the save function
by Daniel Berteaud 25 Sep '09

25 Sep '09

Hi everyone. This is my first post to this list, so excuse me if it's not the right place to poste info like this. I've found some problems in qemu_driver.c in the latest versions of libvirt: - the first problem was also present in 0.7.0. If we run qemu guests unprivileged, we cannot use the save function (virsh save guestname /path/to/file). The reason seems to be that libvirt first create the destination file to write the header and the XML definition. The file is owned by root with 600 permission. Then, we ask qemu to append the dump of the memory (via the migrate exec: call) to this file. This part doesn't work because the qemu user cannot write to this file. So we endup with a file which only contains the header and the XML, and the guest is stoped :/ - the second problem is present since libvirt 0.7.1. Now that the saved file can be compressed, it seems we cannot save in a raw format any more. This is due to this part in the code (qemu_driver.c): if (STREQ (prog, "raw")) prog = "cat"; internalret = virAsprintf(&command, "migrate \"exec:" "%s -c >> '%s' 2>/dev/null\"", prog, safe_path); which result in "migrate \"exec cat -c >> safe_path 2>/dev/null\"" But cat doesn't support the -c argument, so once again, the save fails, as we end up with a save file which only contains the header and the XML definition. Unfortunately, my C knowledge is near 0, so I cannot correct this myself. - the third problem, is that restore doesn't work any more. I haven't dig it yet, but when I try to restore a guest using a saved file (uncompressed produced under libvirt 0.7.0), I've this error: virsh restore /tmp/guest.state error: Failed to restore domain from /tmp/guest.state error: internal error unable to start guest: Nothing interesting in /var/log/libvirt/qemu/guest.log: LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root /usr/bin/qemu-kvm -S -M pc -m 2048 -smp 4 -name guest -uuid 37b5937b-eacf-fda6-f4d0-33537d61b414 -monitor unix:/var/lib/libvirt/qemu/guest.monitor,server,nowait -localtime -no-reboot -boot c -drive file=/dev/data/guest,if=ide,index=0,boot=on -drive file=/var/lib/libvirt/iso/boot.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=52:54:00:48:c4:ca,vlan=0,name=nic.0 -net tap,fd=25,vlan=0,name=tap.0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 -k fr -vga cirrus -incoming exec:cat The qemu process eats 100% of CPU during a few seconds, then stops (if I strace it during this time, I see a lot of error like bad file descriptor). Anyone have save/restore functions working with 0.7.1 ? Cheers, Daniel -- Daniel Berteaud FIREWALL-SERVICES SARL. Société de Services en Logiciels Libres Technopôle Montesquieu 33650 MARTILLAC Tel : 05 56 64 15 32 Fax : 05 56 64 15 32 Mail: daniel(a)firewall-services.com Web : http://www.firewall-services.com

5 14

[libvirt] qemu_driver migrateuri handling broken?
by Gregor Schaffrath 24 Sep '09

24 Sep '09

Hi all. Short summary on DV's request ;) I ran into a problem migrating kvm machines with libvirt-0.6.5: 1) At first, using the same syntax for the migrateuri as with xen (just the IP) did not work... looking into the source code (! ;) ), I found a different syntax for qemu. 2) using tcp://<ip>:<port> just produced an 'unknown failure' on the receiving side: root@loadgen137:~> virsh -c qemu:///system migrate --live kvm-testnode-vnode3 qemu+tcp://10.192.11.136/system?no_verify=1 tcp://10.192.11.136:12345 error: Unknown failure (Note: it was working like a charm when I eliminated the migrateuri altogether, but this was not an option in all my work environments, since one of them doesn't feature DNS, breaking migration on the hostname alone (and keeping /etc/hosts in sync on n machines is something I'd like to avoid, if possible ;) )) 3) removing the case distinction and the handling of the migrateuri in the qemudDomainMigratePrepare2 function in qemu_driver.c entirely (if-statement, and full else-part) solved both my issues. --- The issue seems to be current with 0.7.1 as well (at least I did receive the same error message - I did not investigate further) --- My 2ct: ;) I think that a wrapper like libvirt should consequently abstract lower level details (such as 'qemu', or 'xen') as much as possible (that's what libvirt is for, I guess :) ). Since the removal of the URI handling solves both the issue _and_ eliminates a case distinction between xen and qemu (painlessly, as far as I can see), I'd suggest perhaps considering the removal. :) As to the sending side specification of transfer ports: I think there should always be a possiblity to leave port selection up to libvirt, as the sending side does not necessarily an oversight over the free ports on the receiving side. (I feel that the reason for the different syntax including mandatory :port part was motivated by the wish to allow users to specify ports on the sending side) Cheers, Gregor Schaffrath.

3 5

[libvirt] [PATCH] Fix a typo in virDiskHasValidPciAddr()
by Jiri Denemark 24 Sep '09

24 Sep '09

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/conf/domain_conf.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 09368d9..d494e54 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -125,7 +125,7 @@ struct _virDomainDiskDef { static inline int virDiskHasValidPciAddr(virDomainDiskDefPtr def) { - return def->pci_addr.domain || def->pci_addr.domain || def->pci_addr.slot; + return def->pci_addr.domain || def->pci_addr.bus || def->pci_addr.slot; } -- 1.6.5.rc1

3 2

[libvirt] "Unable to read QEMU help output: Interrupted system call" doing virDomainRestore() on current master
by Charles Duffy 24 Sep '09

24 Sep '09

Howdy. I've had this issue since yesterday, but avoided reporting it until determining today that it occurs on an unmodified upstream tree as well as my own local branch: $ virsh restore ramsave error: Failed to restore domain from ramsave error: Unable to read QEMU help output: Interrupted system call This happens immediately (no delay) and only on restore; "virsh start" behaves as usual. When running libvirtd under gdb, the failure mode is different: $ virsh restore ramsave error: Failed to restore domain from ramsave error: internal error Timed out while reading monitor startup output When running libvirtd under strace, this shows the binary being run (["/usr/bin/qemu-kvm", "-help"]) failing with a SIGPIPE while attempting to write to stdout. strace also shows a SIGSEGV being delivered to a libvirtd thread (a few clone()s removed from the parent) after that thread attempts to close all its open file descriptors above 0-2, but without being able to run gdb I'm at a bit of a loss as to what that thread is doing. Any suggestions?

2 1

[libvirt] [PATCH 0/5] Python fixes
by Cole Robinson 23 Sep '09

23 Sep '09

The following series fixes some functional (and cosmetic) issues with the python bindings. Thanks, Cole Cole Robinson (5): python: Don't generate conflicting conn.createXML functions. python: Add a newline between virConnect and virNode for readability. python: Don't generate bindings for vir*Ref python: Use a pure python implementation of 'vir*GetConnect' python: Fix generated virInterface method names python/generator.py | 40 +++++++++++++++++++++++++++++++++++++--- python/virConnect.py | 1 + 2 files changed, 38 insertions(+), 3 deletions(-)

2 8