December 2011 - Devel - libvirt List Archives

[libvirt] [PATCH 0/6] Allow minimal bandwidth guarantee
by Michal Privoznik 09 Dec '11

09 Dec '11

Since 0.9.4 release libvirt supports setting some QoS attributes on virtual bridges and/or virtual interfaces. Average and peak rate, namely. It lacks minimal guaranteed bandwidth aka 'floor' attribute, though. This patch set tries to fill that hole. However, there are some things you want to know before diving into individual patches: 1) Hierarchical shaping The whole magic hidden in here: Classes [1] can have multiple children and form a tree. A class can borrow unused bandwidth from other sibling classes up to its 'ceil'. This is done in kernel, though. Classes does not share any info among interfaces. Therefore we need to group traffic from domain interfaces so it goes over one point (a bridge). It is now obvious why this functionality is limited to VIR_DOMAIN_NET_TYPE_NETWORK only as the other bridged network type (VIR_DOMAIN_NET_TYPE_BRIDGE:) is meant to be not managed or touched by libvirt at all. This patches build that tree of classes. On network startup, a root class with one child class are created. This child is supposed to be catchment for all interfaces which will ever be plugged and don't have any 'floor'. Once we have network prepared, an interface may be plugged in. That means on a domain startup, as we create virtual devices for a domain and plug them into a bridge, we can create separate class for created interface (if it is needed = has 'floor' set). Class are distinguished by u_int16 identifier which: - needs to be unique among one bridge, obviously - we want to keep, and pass on interface unplugging 2) Network status file Because of the class ID I am mentioning above, I found myself in need of saving next free class ID among with network, so it survives daemon reboots. That's what 5th patch does actually. On interface plug event an unique class ID is taken and on successful QoS set it is stored into an interface. Having said that, domain status XML was extended to keep pair <interface alias; class id> 3) Tying interface traffic with class is done via filter [2]. Filters direct packets into a classes during which packet undergoes examination. Such filter is caller classifier. For example, filter classify packets based on their marks, src/dest ip address, port, etc. And here comes another magic trick. But not so nice as the first one. Libvirt does not know anything about guest (interface) ip address(es). The only thing that libvirt knows for sure is MAC address. But for some reason, filters refuse to use ebtables marks even if iptables marks works well. Filters, however does not support classifying by MAC address. Well, not directly. u32 filter can match any part of a packet at any offset. Offset 0 is start of IP header. And offsets can be negative :) 1: http://tldp.org/HOWTO/Traffic-Control-HOWTO/components.html#c-class 2: http://tldp.org/HOWTO/Traffic-Control-HOWTO/components.html#c-filter Michal Privoznik (6): bandwidth: add new 'floor' attribute bandwidth: Create hierarchical shaping classes bandwidth: Create (un)plug functions bandwidth: Create network (un)plug functions network: Create status files domain: Keep assigned class_id in domstatus XML daemon/libvirtd.c | 3 + docs/formatdomain.html.in | 21 +++- docs/schemas/networkcommon.rng | 5 + po/POTFILES.in | 1 + src/conf/domain_conf.c | 10 +- src/conf/domain_conf.h | 1 + src/conf/netdev_bandwidth_conf.c | 81 +++++++++++--- src/conf/netdev_bandwidth_conf.h | 3 +- src/conf/network_conf.c | 220 ++++++++++++++++++++++++++++++++------ src/conf/network_conf.h | 9 ++ src/libvirt_network.syms | 2 + src/libvirt_private.syms | 2 + src/lxc/lxc_driver.c | 3 +- src/network/bridge_driver.c | 109 +++++++++++++++++-- src/network/bridge_driver.h | 7 ++ src/qemu/qemu_command.c | 20 +++- src/qemu/qemu_domain.c | 66 +++++++++++- src/qemu/qemu_process.c | 12 ++ src/util/virnetdevbandwidth.c | 205 ++++++++++++++++++++++++++++++++++-- src/util/virnetdevbandwidth.h | 19 +++- src/util/virnetdevmacvlan.c | 2 +- 21 files changed, 710 insertions(+), 91 deletions(-) -- 1.7.3.4

1 6

[libvirt] [PATCH] virsh: plug memory leak on cmdDomblkstat
by ajia＠redhat.com 09 Dec '11

09 Dec '11

From: Alex Jia <ajia(a)redhat.com> Detected by valgrind. Leak introduced in commit 88a993b: * tools/virsh.c: fix memory leak on cmdDomblkstat. * how to reproduce? % valgrind -v --leak-check=full virsh cmdDomblkstat <domain name> * actual valgrind result: ==6573== 1,836 bytes in 1 blocks are definitely lost in loss record 110 of 124 ==6573== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==6573== by 0x330D71497D: xdr_string (in /lib64/libc-2.12.so) ==6573== by 0x4D26CED: xdr_remote_nonnull_string (remote_protocol.c:30) ==6573== by 0x4D28138: xdr_remote_domain_get_xml_desc_ret (remote_protocol.c:1418) ==6573== by 0x4D3C0C2: virNetMessageDecodePayload (virnetmessage.c:382) ==6573== by 0x4D3279F: virNetClientProgramCall (virnetclientprogram.c:382) ==6573== by 0x4D0D50B: callWithFD (remote_driver.c:4339) ==6573== by 0x4D0D5AB: call (remote_driver.c:4360) ==6573== by 0x4D16EAF: remoteDomainGetXMLDesc (remote_client_bodies.h:861) ==6573== by 0x4CF9F4F: virDomainGetXMLDesc (libvirt.c:4098) ==6573== by 0x4154D9: cmdDomblklist (virsh.c:1722) ==6573== by 0x4149E2: vshCommandRun (virsh.c:16365) ==6573== ==6573== 46,009 (352 direct, 45,657 indirect) bytes in 1 blocks are definitely lost in loss record 123 of 124 ==6573== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==6573== by 0x3318286DC6: xmlXPathNewContext (in /usr/lib64/libxml2.so.2.7.6) ==6573== by 0x4C79AE2: virXMLParseHelper (xml.c:779) ==6573== by 0x415512: cmdDomblklist (virsh.c:1726) ==6573== by 0x4149E2: vshCommandRun (virsh.c:16365) ==6573== by 0x427743: main (virsh.c:17867) ==6573== ==6573== LEAK SUMMARY: ==6573== definitely lost: 2,188 bytes in 2 blocks ==6573== indirectly lost: 45,657 bytes in 332 blocks ==6573== possibly lost: 0 bytes in 0 blocks ==6573== still reachable: 128,034 bytes in 1,364 blocks ==6573== suppressed: 0 bytes in 0 blocks Signed-off-by: Alex Jia <ajia(a)redhat.com> --- tools/virsh.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index a51478f..7c2f3fc 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -1757,6 +1757,9 @@ cmdDomblklist(vshControl *ctl, const vshCmd *cmd) cleanup: VIR_FREE(disks); virDomainFree(dom); + VIR_FREE(xml); + xmlFreeDoc(xmldoc); + xmlXPathFreeContext(ctxt); return ret; } -- 1.7.1

3 3

Re: [libvirt] how to use macvtap in kvm guest
by Amit Tewari 09 Dec '11

09 Dec '11

Hi, No guest can not get ip. When I do ifup eth0 it give error device not found. Hostos=rhel 6.x86_64 Guest os= rhel 6.x86_64 Libvirt =0.8.7 Macvtap driver is loaded. Qemu-kvm= 0.12.1.2 i think this error is creating problem macvtap0:no ipv6 routers present ________________________________ From: xhu [mailto:xhu@redhat.com] Sent: Friday, December 09, 2011 10:53 AM To: Amit Tewari Cc: libvir-list(a)redhat.com Subject: Re: [libvirt] how to use macvtap in kvm guest On 12/09/2011 12:28 PM, Amit Tewari wrote: Hi I am creating macvtap0 interface on my eth1 interface. ip link show macvtap0 133: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN qlen 500 link/ether 3e:63:18:f3:49:63 brd ff:ff:ff:ff:ff:ff guest interface file- <interface type='direct'> <mac address='3e:63:18:f3:49:63'/> <source dev='eth0' mode='bridge'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> Now when I do- Virsh define guest works fine But when I do virsh start guest can guest gain ip? Dmesg shows error macvtap0:no ipv6 routers present libvirtd[24907]: segfault at 0 ip 0000003e22280062 sp 00007fd3057f8cb8 error 4 in libc-2.12.so[3e22200000+187000] and even if guest starts its eth interface is not created could you provide your host os, guest os, libvirt, qemu-kvm version? it is fine as i tried, no segment fault message and the guest can get ip. DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . ------------------------------------------------------------------------ ----------------------------------------------- -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . -----------------------------------------------------------------------------------------------------------------------

2 1

[libvirt] [PATCH] fix memory leak in src/nodeinfo.c
by Stefan Berger 09 Dec '11

09 Dec '11

Fix memory leak: ==27534== 24 bytes in 1 blocks are definitely lost in loss record 207 of 530 ==27534== at 0x4A05E46: malloc (vg_replace_malloc.c:195) ==27534== by 0x38EC26EC37: vasprintf (in /lib64/libc-2.13.so) ==27534== by 0x4E998E6: virVasprintf (util.c:1677) ==27534== by 0x4E999F1: virAsprintf (util.c:1695) ==27534== by 0x4F1EAAC: nodeGetInfo (nodeinfo.c:593) ==27534== by 0x47948F: qemuCapsInitCPU (qemu_capabilities.c:855) ==27534== by 0x4796B1: qemuCapsInit (qemu_capabilities.c:915) ==27534== by 0x456550: qemuCreateCapabilities (qemu_driver.c:245) ==27534== by 0x4578C4: qemudStartup (qemu_driver.c:580) ==27534== by 0x4F20886: virStateInitialize (libvirt.c:852) ==27534== by 0x420E55: daemonRunStateInit (libvirtd.c:1156) ==27534== by 0x4E94C56: virThreadHelper (threads-pthread.c:157) Mark this leaked variable as const char * when it is passed into another function. --- src/nodeinfo.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) Index: libvirt-iterator/src/nodeinfo.c =================================================================== --- libvirt-iterator.orig/src/nodeinfo.c +++ libvirt-iterator/src/nodeinfo.c @@ -68,7 +68,7 @@ /* NB, this is not static as we need to call it from the testsuite */ int linuxNodeInfoCPUPopulate(FILE *cpuinfo, - char *sysfs_cpudir, + const char *sysfs_cpudir, virNodeInfoPtr nodeinfo); static int linuxNodeGetCPUStats(FILE *procstat, @@ -199,7 +199,7 @@ static int parse_core(unsigned int cpu) } int linuxNodeInfoCPUPopulate(FILE *cpuinfo, - char *sysfs_cpudir, + const char *sysfs_cpudir, virNodeInfoPtr nodeinfo) { char line[1024]; @@ -597,9 +597,12 @@ int nodeGetInfo(virConnectPtr conn ATTRI ret = linuxNodeInfoCPUPopulate(cpuinfo, sysfs_cpuinfo, nodeinfo); VIR_FORCE_FCLOSE(cpuinfo); - if (ret < 0) + if (ret < 0) { + VIR_FREE(sysfs_cpuinfo); return -1; + } + VIR_FREE(sysfs_cpuinfo); /* Convert to KB. */ nodeinfo->memory = physmem_total () / 1024;

2 2

[libvirt] [PATCH v2] fix error when parsing ppc64 models on x86 host
by Stefan Berger 09 Dec '11

09 Dec '11

When parsing ppc64 models on an x86 host an out-of-memory error message is displayed due to it checking for retcpus being NULL. Fix this by removing the check whether retcpus is NULL since we will realloc into this variable. Also in the X86 model parser display the OOM error at the location where it happens. --- v2: Fixing leak of 'cpus' --- src/qemu/qemu_capabilities.c | 37 ++++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 17 deletions(-) Index: libvirt-iterator/src/qemu/qemu_capabilities.c =================================================================== --- libvirt-iterator.orig/src/qemu/qemu_capabilities.c +++ libvirt-iterator/src/qemu/qemu_capabilities.c @@ -443,8 +443,10 @@ qemuCapsParseX86Models(const char *outpu if (retcpus) { unsigned int len; - if (VIR_REALLOC_N(cpus, count + 1) < 0) + if (VIR_REALLOC_N(cpus, count + 1) < 0) { + virReportOOMError(); goto error; + } if (next) len = next - p - 1; @@ -456,8 +458,10 @@ qemuCapsParseX86Models(const char *outpu len -= 2; } - if (!(cpus[count] = strndup(p, len))) + if (!(cpus[count] = strndup(p, len))) { + virReportOOMError(); goto error; + } } count++; } while ((p = next)); @@ -491,12 +495,7 @@ qemuCapsParsePPCModels(const char *outpu const char *next; unsigned int count = 0; const char **cpus = NULL; - int i; - - if (!retcpus) { - VIR_DEBUG("No retcpus specified"); - return -1; - } + int i, ret; do { const char *t; @@ -523,32 +522,38 @@ qemuCapsParsePPCModels(const char *outpu if (retcpus) { unsigned int len; - if (VIR_REALLOC_N(cpus, count + 1) < 0) + if (VIR_REALLOC_N(cpus, count + 1) < 0) { virReportOOMError(); + ret = -1; goto error; + } len = t - p - 1; - if (!(cpus[count] = strndup(p, len))) + if (!(cpus[count] = strndup(p, len))) { virReportOOMError(); + ret = -1; goto error; + } } count++; } while ((p = next)); if (retcount) *retcount = count; - if (retcpus) + if (retcpus) { *retcpus = cpus; - return 0; + cpus = NULL; + } + ret = 0; error: if (cpus) { for (i = 0; i < count; i++) VIR_FREE(cpus[i]); + VIR_FREE(cpus); } - VIR_FREE(cpus); - return -1; + return ret; } int @@ -587,10 +592,8 @@ qemuCapsProbeCPUModels(const char *qemu, if (virCommandRun(cmd, NULL) < 0) goto cleanup; - if (parse(output, count, cpus) < 0) { - virReportOOMError(); + if (parse(output, count, cpus) < 0) goto cleanup; - } ret = 0;

2 2

[libvirt] [PATCH] threadpool: Don't wait on condition if pool has no workers
by Michal Privoznik 09 Dec '11

09 Dec '11

Pool creates new workers dynamically. However, it is possible for a pool to have no workers. If we want to free that pool, we don't want to wait on quit condition as it will never be signaled. --- Pushing under trivial rule src/util/threadpool.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/util/threadpool.c b/src/util/threadpool.c index c16e2af..883d1e5 100644 --- a/src/util/threadpool.c +++ b/src/util/threadpool.c @@ -258,7 +258,8 @@ void virThreadPoolFree(virThreadPoolPtr pool) virCondBroadcast(&pool->prioCond); } - ignore_value(virCondWait(&pool->quit_cond, &pool->mutex)); + if (pool->nWorkers > 0 || pool->nPrioWorkers > 0) + ignore_value(virCondWait(&pool->quit_cond, &pool->mutex)); while ((job = pool->jobList.head)) { pool->jobList.head = pool->jobList.head->next; -- 1.7.3.4

2 5

[libvirt] [PATCH] fix error when parsing ppc64 models on x86 host
by Stefan Berger 09 Dec '11

09 Dec '11

When parsing ppc64 models on an x86 host an out-of-memory error message is displayed due to it checking for retcpus being NULL. Fix this by removing the check whether retcpus is NULL since we will realloc into this variable. Also in the X86 model parser display the OOM error at the location where it happens. --- src/qemu/qemu_capabilities.c | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) Index: libvirt-iterator/src/qemu/qemu_capabilities.c =================================================================== --- libvirt-iterator.orig/src/qemu/qemu_capabilities.c +++ libvirt-iterator/src/qemu/qemu_capabilities.c @@ -443,8 +443,10 @@ qemuCapsParseX86Models(const char *outpu if (retcpus) { unsigned int len; - if (VIR_REALLOC_N(cpus, count + 1) < 0) + if (VIR_REALLOC_N(cpus, count + 1) < 0) { + virReportOOMError(); goto error; + } if (next) len = next - p - 1; @@ -456,8 +458,10 @@ qemuCapsParseX86Models(const char *outpu len -= 2; } - if (!(cpus[count] = strndup(p, len))) + if (!(cpus[count] = strndup(p, len))) { + virReportOOMError(); goto error; + } } count++; } while ((p = next)); @@ -493,11 +497,6 @@ qemuCapsParsePPCModels(const char *outpu const char **cpus = NULL; int i; - if (!retcpus) { - VIR_DEBUG("No retcpus specified"); - return -1; - } - do { const char *t; @@ -587,10 +586,8 @@ qemuCapsProbeCPUModels(const char *qemu, if (virCommandRun(cmd, NULL) < 0) goto cleanup; - if (parse(output, count, cpus) < 0) { - virReportOOMError(); + if (parse(output, count, cpus) < 0) goto cleanup; - } ret = 0;

2 1

[libvirt] [PATCH] virsh: correct the cmdDomIfGetLink function return value error
by ajia＠redhat.com 09 Dec '11

09 Dec '11

From: Alex Jia <ajia(a)redhat.com> * tools/virsh.c: Although finding interface with matching mac addr, forgot to set 'ret' boolean value to 'true'. * how to reproduce? % virsh domif-getlink <guest name> <interface mac> % echo $? Signed-off-by: Alex Jia <ajia(a)redhat.com> --- tools/virsh.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index 276e1cc..91c3459 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -1538,6 +1538,7 @@ cmdDomIfGetLink (vshControl *ctl, const vshCmd *cmd) mac = virXMLPropString(cur, "address"); if (STRCASEEQ(mac, iface)){ + ret = true; goto hit; } } -- 1.7.1

3 4

[libvirt] FYI: SpecVirt results using libvirt + KVM
by Daniel P. Berrange 09 Dec '11

09 Dec '11

Some folks may be aware of the SpecVirt benchmark, where KVM is giving the competition something to worry about :-) http://www.spec.org/virt_sc2010/results/ >From the POV of libvirt uses though, there has been one annoyance with the previously submitted results though, in that they have been invoking the KVM command line directly. This has made it harder for people who are deploying KVM using libvirt to replicate the optimal configurations. I'm pleased to be able to point out that the latest result published for KVM by IBM has in fact been done using libvirt! You can clearly see how the guests are being configured with libvirt and the results demonstrate that using libvirt to manage KVM does not involve sacrificing any of the performance that KVM offers: http://www.spec.org/virt_sc2010/results/res2011q4/ This can only continue to get better as our communities work together to add more performance related features to both libvirt and KVM :-) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 0

[libvirt] [PATCH] bridge: Fix forward delay APIs
by Jiri Denemark 09 Dec '11

09 Dec '11

Due to copy&paste error in c1df2c14b590b3d68b707aa4f3a570f95a6bc548, virNetDevBridge[SG]etSTPDelay APIs were accessing wrong file. --- src/util/virnetdevbridge.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/virnetdevbridge.c b/src/util/virnetdevbridge.c index e246b2c..08c8f5c 100644 --- a/src/util/virnetdevbridge.c +++ b/src/util/virnetdevbridge.c @@ -395,7 +395,7 @@ int virNetDevBridgeSetSTPDelay(const char *brname, if ((fd = virNetDevSetupControl(brname, &ifr)) < 0) goto cleanup; - ret = virNetDevBridgeSet(brname, "stp_state", MS_TO_JIFFIES(delay), + ret = virNetDevBridgeSet(brname, "forward_delay", MS_TO_JIFFIES(delay), fd, &ifr); cleanup: @@ -426,7 +426,7 @@ int virNetDevBridgeGetSTPDelay(const char *brname, if ((fd = virNetDevSetupControl(brname, &ifr)) < 0) goto cleanup; - ret = virNetDevBridgeGet(brname, "stp_state", &i, + ret = virNetDevBridgeGet(brname, "forward_delay", &i, fd, &ifr); *delayms = JIFFIES_TO_MS(i); -- 1.7.8

2 1