[libvirt] [PATCH 0/3] spec file improvements
by Eric Blake
Our spec file is non-deterministic if you have this in your ~/.rpmmacros:
%_without_udev 1
because it then depends on whether you have systemd-devel installed
rather than being explicitly stated in the spec file.
[At this point, I'm sending the series to get the review started on the
two trivial parts; I'm still working on patch 3, including coming up with
a formula for proving that the unpatched build was non-deterministic,
rather than just my claim above]
Eric Blake (2):
build: fix spelling of configure --with-systemd-daemon
spec: explicitly avoid bhyve on Linux
libvirt.spec.in | 2 ++
m4/virt-lib.m4 | 20 +++++++++++++-------
2 files changed, 15 insertions(+), 7 deletions(-)
--
1.8.5.3
10 years, 9 months
[libvirt] [PATCH] virsh: Honour -q in domblklist, vcpupin and emulatorpin
by Michal Privoznik
If user wants to grep some info from domain, e.g. disk paths:
# virsh -q domblklist win7 | awk '{print $2}'
Source
/var/lib/libvirt/images/windows.qcow2
/home/zippy/work/tmp/en_windows_7_professional_x64_dvd_X15-65805.iso
while with my change:
# virsh -q domblklist win7 | awk '{print $2}'
/var/lib/libvirt/images/windows.qcow2
/home/zippy/work/tmp/en_windows_7_professional_x64_dvd_X15-65805.iso
We don't print table header in other commands, like list.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
tools/virsh-domain-monitor.c | 14 +++++++-------
tools/virsh-domain.c | 10 +++++-----
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c
index 1192565..4905b7e 100644
--- a/tools/virsh-domain-monitor.c
+++ b/tools/virsh-domain-monitor.c
@@ -495,12 +495,12 @@ cmdDomblklist(vshControl *ctl, const vshCmd *cmd)
goto cleanup;
if (details)
- vshPrint(ctl, "%-10s %-10s %-10s %s\n", _("Type"),
- _("Device"), _("Target"), _("Source"));
+ vshPrintExtra(ctl, "%-10s %-10s %-10s %s\n", _("Type"),
+ _("Device"), _("Target"), _("Source"));
else
- vshPrint(ctl, "%-10s %s\n", _("Target"), _("Source"));
+ vshPrintExtra(ctl, "%-10s %s\n", _("Target"), _("Source"));
- vshPrint(ctl, "------------------------------------------------\n");
+ vshPrintExtra(ctl, "------------------------------------------------\n");
for (i = 0; i < ndisks; i++) {
char *type = NULL;
@@ -609,9 +609,9 @@ cmdDomiflist(vshControl *ctl, const vshCmd *cmd)
if (ninterfaces < 0)
goto cleanup;
- vshPrint(ctl, "%-10s %-10s %-10s %-11s %s\n", _("Interface"), _("Type"),
- _("Source"), _("Model"), _("MAC"));
- vshPrint(ctl, "-------------------------------------------------------\n");
+ vshPrintExtra(ctl, "%-10s %-10s %-10s %-11s %s\n", _("Interface"),
+ _("Type"), _("Source"), _("Model"), _("MAC"));
+ vshPrintExtra(ctl, "-------------------------------------------------------\n");
for (i = 0; i < ninterfaces; i++) {
char *type = NULL;
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 3e73340..2e3f0ed 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -5815,8 +5815,8 @@ cmdVcpuPin(vshControl *ctl, const vshCmd *cmd)
if ((ncpus = virDomainGetVcpuPinInfo(dom, info.nrVirtCpu,
cpumaps, cpumaplen, flags)) >= 0) {
- vshPrint(ctl, "%s %s\n", _("VCPU:"), _("CPU Affinity"));
- vshPrint(ctl, "----------------------------------\n");
+ vshPrintExtra(ctl, "%s %s\n", _("VCPU:"), _("CPU Affinity"));
+ vshPrintExtra(ctl, "----------------------------------\n");
for (i = 0; i < ncpus; i++) {
if (vcpu != -1 && i != vcpu)
continue;
@@ -5944,9 +5944,9 @@ cmdEmulatorPin(vshControl *ctl, const vshCmd *cmd)
cpumaps = vshMalloc(ctl, cpumaplen);
if (virDomainGetEmulatorPinInfo(dom, cpumaps,
cpumaplen, flags) >= 0) {
- vshPrint(ctl, "%s %s\n", _("emulator:"), _("CPU Affinity"));
- vshPrint(ctl, "----------------------------------\n");
- vshPrint(ctl, " *: ");
+ vshPrintExtra(ctl, "%s %s\n", _("emulator:"), _("CPU Affinity"));
+ vshPrintExtra(ctl, "----------------------------------\n");
+ vshPrintExtra(ctl, " *: ");
ret = vshPrintPinInfo(cpumaps, cpumaplen, maxcpu, 0);
vshPrint(ctl, "\n");
}
--
1.9.0
10 years, 9 months
[libvirt] [PATCH] network: don't even call networkRunHook if there is no network
by Laine Stump
networkAllocateActualDevice() is called for *all* interfaces, not just
those with type='network'. In that case, it will jump down to its
validate: label immediately, without allocating anything. After
validation is done, two counters are potentially updated (one for the
network, and one for any particular physical device that is chosen),
and then networkRunHook() is called.
This patch refactors that code a slight bit so that networkRunHook()
doesn't get called if netdef is NULL (i.e. type != network) and to
place the conditional increment of dev->connections inside the "if
(netdef)" as well - dev can never be non-null if netdef is null
(because "dev" is the pointer to a device in a network's pool of
devices), so this doesn't have any functional effect, it just makes
the code clearer.
---
src/network/bridge_driver.c | 47 ++++++++++++++++++++++-----------------------
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index 152bd06..3fb5ad3 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -3662,36 +3662,35 @@ validate:
}
}
- if (dev) {
- /* mark the allocation */
- dev->connections++;
- if (actualType != VIR_DOMAIN_NET_TYPE_HOSTDEV) {
- VIR_DEBUG("Using physical device %s, %d connections",
- dev->device.dev, dev->connections);
- } else {
- VIR_DEBUG("Using physical device %04x:%02x:%02x.%x, connections %d",
- dev->device.pci.domain, dev->device.pci.bus,
- dev->device.pci.slot, dev->device.pci.function,
- dev->connections);
- }
- }
-
if (netdef) {
netdef->connections++;
VIR_DEBUG("Using network %s, %d connections",
netdef->name, netdef->connections);
- }
- /* finally we can call the 'plugged' hook script if any */
- if (networkRunHook(network, dom, iface,
- VIR_HOOK_NETWORK_OP_IFACE_PLUGGED,
- VIR_HOOK_SUBOP_BEGIN) < 0) {
- /* adjust for failure */
- if (dev)
- dev->connections--;
- if (netdef)
+ if (dev) {
+ /* mark the allocation */
+ dev->connections++;
+ if (actualType != VIR_DOMAIN_NET_TYPE_HOSTDEV) {
+ VIR_DEBUG("Using physical device %s, %d connections",
+ dev->device.dev, dev->connections);
+ } else {
+ VIR_DEBUG("Using physical device %04x:%02x:%02x.%x, connections %d",
+ dev->device.pci.domain, dev->device.pci.bus,
+ dev->device.pci.slot, dev->device.pci.function,
+ dev->connections);
+ }
+ }
+
+ /* finally we can call the 'plugged' hook script if any */
+ if (networkRunHook(network, dom, iface,
+ VIR_HOOK_NETWORK_OP_IFACE_PLUGGED,
+ VIR_HOOK_SUBOP_BEGIN) < 0) {
+ /* adjust for failure */
netdef->connections--;
- goto error;
+ if (dev)
+ dev->connections--;
+ goto error;
+ }
}
ret = 0;
--
1.8.5.3
10 years, 9 months
[libvirt] [PATCH] network: unplug bandwidth and call networkRunHook only when appropriate
by Laine Stump
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
10 years, 9 months
[libvirt] [PATCH] Fix memory leak in virSCSIDeviceListDel()
by Nehal J Wani
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
10 years, 9 months
[libvirt] [question] doubt about cpu model 'qemu64'
by Wangyufei (James)
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
10 years, 9 months
[libvirt] Entering freeze for libvirt-1.2.2
by Daniel Veillard
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/
10 years, 9 months
[libvirt] [PATCH 0/2] fix mingw build
by Eric Blake
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
10 years, 9 months
[libvirt] [PATCH] virNetDevVethCreate: Serialize callers
by Michal Privoznik
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
10 years, 9 months
[libvirt] Question about building libvirt.so
by vikhyath reddy
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.
10 years, 9 months
