- Devel - libvirt List Archives

[libvirt] [PATCH] network: unplug bandwidth and call networkRunHook only when appropriate
by Laine Stump 26 Feb '14

26 Feb '14

According to commit b4e0299dm if networkAllocateActualDevice() was successful, it will *always* allocate an iface->data.network.actual, so we can use this during networkReleaseActualDevice() to know if there is really anything to undo. We were properly using this information to only decrement the network connections counter if it had previously been incremented, but we were unconditionally unplugging bandwidth and calling the "unplugged" network hook for *all* interfaces (during qemuProcessStop()) whether they had been previously plugged or not. This caused problems if a domain failed to start at some time prior to all interfaces being allocated. (I encountered this when an interface had a bandwidth floor set but no inbound QoS). This patch changes both the call to networkUnplugBandwidth() and the call to networkRunHook() to only be called if there was a previous call to "plug" for the same interface. --- src/network/bridge_driver.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 3fb5ad3..c797f8f 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -3936,7 +3936,8 @@ networkReleaseActualDevice(virDomainDefPtr dom, } netdef = network->def; - if ((netdef->forward.type == VIR_NETWORK_FORWARD_NONE || + if (iface->data.network.actual && + (netdef->forward.type == VIR_NETWORK_FORWARD_NONE || netdef->forward.type == VIR_NETWORK_FORWARD_NAT || netdef->forward.type == VIR_NETWORK_FORWARD_ROUTE) && networkUnplugBandwidth(network, iface) < 0) @@ -4029,15 +4030,15 @@ networkReleaseActualDevice(virDomainDefPtr dom, } success: - if (iface->data.network.actual) + if (iface->data.network.actual) { netdef->connections--; + VIR_DEBUG("Releasing network %s, %d connections", + netdef->name, netdef->connections); - /* finally we can call the 'unplugged' hook script if any */ - networkRunHook(network, dom, iface, VIR_HOOK_NETWORK_OP_IFACE_UNPLUGGED, - VIR_HOOK_SUBOP_BEGIN); - - VIR_DEBUG("Releasing network %s, %d connections", - netdef->name, netdef->connections); + /* finally we can call the 'unplugged' hook script if any */ + networkRunHook(network, dom, iface, VIR_HOOK_NETWORK_OP_IFACE_UNPLUGGED, + VIR_HOOK_SUBOP_BEGIN); + } ret = 0; cleanup: if (network) -- 1.8.5.3

3 2

[libvirt] [PATCH] Fix memory leak in virSCSIDeviceListDel()
by Nehal J Wani 26 Feb '14

26 Feb '14

While running virscsitest, it was found that valgrind pointed out the following memory leak: ==320== 5 bytes in 1 blocks are definitely lost in loss record 4 of 37 ==320== at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==320== by 0x3E6CE81171: strdup (strdup.c:43) ==320== by 0x4CB28DF: virStrdup (virstring.c:554) ==320== by 0x4CAC987: virSCSIDeviceSetUsedBy (virscsi.c:289) ==320== by 0x402321: test2 (virscsitest.c:100) ==320== by 0x403231: virtTestRun (testutils.c:199) ==320== by 0x402121: mymain (virscsitest.c:180) ==320== by 0x4039AD: virtTestMain (testutils.c:782) ==320== by 0x3E6CE1ED1C: (below main) (libc-start.c:226) ==320== --- src/util/virscsi.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/util/virscsi.c b/src/util/virscsi.c index acc3815..2f469f2 100644 --- a/src/util/virscsi.c +++ b/src/util/virscsi.c @@ -435,6 +435,7 @@ virSCSIDeviceListDel(virSCSIDeviceListPtr list, for (i = 0; i < dev->n_used_by; i++) { if (STREQ_NULLABLE(dev->used_by[i], name)) { if (dev->n_used_by > 1) { + VIR_FREE(dev->used_by[i]); VIR_DELETE_ELEMENT(dev->used_by, i, dev->n_used_by); } else { tmp = virSCSIDeviceListSteal(list, dev); -- 1.7.1

2 1

[libvirt] [question] doubt about cpu model 'qemu64'
by Wangyufei (James) 26 Feb '14

26 Feb '14

Hello, Recently I noticed that if I gave no model to qemu, then I would get 'qemu64' as default cpu model. Model 'qemu64' defined in qemu and defined in libvirt both support feature 'svm'. And if I start a VM with 'qemu64' as the qemu default model, I can get no 'svm' feature in the GuestOS: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht pni cx16 popcnt hypervisor syscall nx lm lahf_lm My host cpu is intel E5620, and it doesn't support 'svm' feature: 'fpu', 'vme', 'de', 'pse', 'tsc', 'msr', 'pae', 'mce', 'cx8', 'apic', 'sep', 'mtrr', 'pge', 'mca', 'cmov', 'pat', 'pse36', 'clflush', 'ds', 'acpi', 'mmx', 'fxsr', 'sse', 'sse2', 'ss', 'ht', 'tm', 'pbe', 'pni', 'pclmulqdq', 'dtes64', 'monitor', 'ds_cpl', 'vmx', 'smx', 'est', 'tm2', 'ssse3', 'cx16', 'xtpr', 'pdcm', 'pcid', 'dca', 'sse4.1', 'sse4.2', 'popcnt', 'aes', 'syscall', 'nx', 'pdpe1gb', 'rdtscp', 'lm', 'lahf_lm', 'dts', 'arat', 'constant_tsc' I can get the same result with libvirt API compareCPU on the host: model:qemu64; ret:0 model:Conroe; ret:2 model:Penryn; ret:2 model:Nehalem; ret:2 model:Westmere; ret:2 model:SandyBridge; ret:0 model:Haswell; ret:0 Isn't it strange that the host cpu doesn't support 'qemu64' model, but we can still start a VM with 'qemu64' as the default model on it? Best Regards, -WangYufei

1 0

[libvirt] Entering freeze for libvirt-1.2.2
by Daniel Veillard 26 Feb '14

26 Feb '14

As planned I tagged a release candidate 1 version in git and made tarballs and rpms available at the usual place: ftp://libvirt.org/libvirt/ it seems to work well in my limited testing, but let's spend some time this week making more tests and checking it compiles on other systems and architectures. if all goes well I will probably push the release next week-end, with an rc2 on Wednesday based on feedback, thanks ! Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

3 4

[libvirt] [PATCH 0/2] fix mingw build
by Eric Blake 26 Feb '14

26 Feb '14

I hit some issues while running ./autobuild.sh on a machine set up for a mingw cross build; pushing this series under the build-breaker rule. Eric Blake (2): build: fix cgroups on non-Linux build: avoid ld_preload tests on mingw src/util/vircgroup.c | 27 +++++++++++++++++++++++++- tests/Makefile.am | 7 ++++--- tests/virportallocatortest.c | 45 +++++++++++++++++++++++++++----------------- 3 files changed, 58 insertions(+), 21 deletions(-) -- 1.8.5.3

1 2

[libvirt] [PATCH] virNetDevVethCreate: Serialize callers
by Michal Privoznik 25 Feb '14

25 Feb '14

Consider dozen of LXC domains, each of them having this type of interface: <interface type='network'> <mac address='52:54:00:a7:05:4b'/> <source network='default'/> </interface> When starting these domain in parallel, all workers may meet in virNetDevVethCreate() where a race starts. Race over allocating veth pairs because allocation requires two steps: 1) find first nonexistent '/sys/class/net/vnet%d/' 2) run 'ip link add ...' command Now consider two threads. Both of them find N as the first unused veth index but only one of them succeeds allocating it. The other one fails. For such cases, we are running the allocation in a loop with 10 rounds. However this is very flaky synchronization. It should be rather used when libvirt is competing with other process than when libvirt threads fight each other. Therefore, internally we should use mutex to serialize callers, and do the allocation in loop (just in case we are competing with a different process). By the way we have something similar already since 1cf97c87. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/util/virnetdevveth.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/src/util/virnetdevveth.c b/src/util/virnetdevveth.c index 25eb282..e698ce2 100644 --- a/src/util/virnetdevveth.c +++ b/src/util/virnetdevveth.c @@ -39,6 +39,19 @@ /* Functions */ +virMutex virNetDevVethCreateMutex; + +static int virNetDevVethCreateMutexOnceInit(void) +{ + if (virMutexInit(&virNetDevVethCreateMutex) < 0) { + virReportSystemError(errno, "%s", _("unable to init mutex")); + return -1; + } + return 0; +} + +VIR_ONCE_GLOBAL_INIT(virNetDevVethCreateMutex); + static int virNetDevVethExists(int devNum) { int ret; @@ -117,6 +130,10 @@ int virNetDevVethCreate(char** veth1, char** veth2) * We might race with other containers, but this is reasonably * unlikely, so don't do too many retries for device creation */ + if (virNetDevVethCreateMutexInitialize() < 0) + return -1; + + virMutexLock(&virNetDevVethCreateMutex); #define MAX_VETH_RETRIES 10 for (i = 0; i < MAX_VETH_RETRIES; i++) { @@ -179,6 +196,7 @@ int virNetDevVethCreate(char** veth1, char** veth2) MAX_VETH_RETRIES); cleanup: + virMutexUnlock(&virNetDevVethCreateMutex); virCommandFree(cmd); VIR_FREE(veth1auto); VIR_FREE(veth2auto); -- 1.9.0

2 1

[libvirt] Question about building libvirt.so
by vikhyath reddy 25 Feb '14

25 Feb '14

Hi, Thanks for libvirt. It is a life saver. I am in the process of writing some custom wrappers for libvirt so that it can be easily accessed from nodejs using the nodejs-ffi interfacing (basically describes a way to convert nodejs to c calls). I did write the wrapper on the lines of the examples provided. But I am unable to see my new functions in the libvirt.so file (which nodejs interfacing needs). Which means that my wrappers under <libvirt>/wrappers/ are not getting into libvirt.so like the ones at <libvirt>/examples Can you please guide me as to where I am going wrong? I was able to do a successful configure + make and I thought this will regenerate the new libvirt.so (which it does, but I cant see my new wrapper methods in it). Much appreciated, Thanks, vik.

5 7

[libvirt] libvirt iSCSI target discovery
by Sijo Jose 25 Feb '14

25 Feb '14

Hi, Is it possible to discover iSCSI targets using libvirt API..? OR is it possible to get the similar results of below commands using libvirtAPI..? iscsiadm --mode discovery --type sendtargets --portal server1.example.com sudo iscsiadm -m discovery -t st -p 192.168.0.10 Regards Sijo

2 1

[libvirt] [PATCH V2] libxl: queue domain event earlier in shutdown handler
by Jim Fehlig 25 Feb '14

25 Feb '14

The shutdown handler may restart a domain when handling a reboot event or when <on_*> is set to 'restart'. Restarting consists of calling libxlVmCleanup followed by libxlVmStart. libxlVmStart will emit a VIR_DOMAIN_EVENT_STARTED event, but the SHUTDOWN event is not emitted until exiting the shutdown handler, after the STARTED event. This patch changes the logic a bit to queue the event at the start of the shutdown action, ensuring it is queued before any subsequent events that may be generated while executing the shutdown action. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- V2: Enqueue any pending events at the beginning of the shutdown action labels, as suggested by Michal Privoznik https://www.redhat.com/archives/libvir-list/2014-February/msg01446.html src/libxl/libxl_driver.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index f7379b5..a79efcb 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -473,6 +473,10 @@ libxlDomainShutdownThread(void *opaque) } destroy: + if (dom_event) { + libxlDomainEventQueue(driver, dom_event); + dom_event = NULL; + } libxl_domain_destroy(ctx, vm->def->id, NULL); if (libxlVmCleanupJob(driver, vm, reason)) { if (!vm->persistent) { @@ -483,6 +487,10 @@ destroy: goto cleanup; restart: + if (dom_event) { + libxlDomainEventQueue(driver, dom_event); + dom_event = NULL; + } libxl_domain_destroy(ctx, vm->def->id, NULL); libxlVmCleanupJob(driver, vm, VIR_DOMAIN_SHUTOFF_SHUTDOWN); libxlVmStart(driver, vm, 0, -1); -- 1.8.1.4

2 2

[libvirt] [PATCH libvirt-java] spec: Depend on java-headless for Fedora 21+
by Cole Robinson 25 Feb '14

25 Feb '14

Details: https://bugzilla.redhat.com/show_bug.cgi?id=1068369 --- libvirt-java.spec.in | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/libvirt-java.spec.in b/libvirt-java.spec.in index 137af83..d07b998 100644 --- a/libvirt-java.spec.in +++ b/libvirt-java.spec.in @@ -12,7 +12,11 @@ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root Requires: jna Requires: libvirt-client >= @libvirt.required@ +%if 0%{?fedora} >= 21 +Requires: java-headless >= @java.required@ +%else Requires: java >= @java.required@ +%endif Requires: jpackage-utils BuildRequires: ant BuildRequires: jna -- 1.8.5.3

2 2