[libvirt] [PATCH] qemu: driver: Fix format characters in error message
by Peter Krempa
Error message in qemuDomainSetVcpusFlags uses %d for the two arguments
but both are unsigned. The resulting error message may be weird when
attempting to set a very large vcpu count.
---
src/qemu/qemu_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 5a7733c..a0587e1 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -4826,7 +4826,7 @@ qemuDomainSetVcpusFlags(virDomainPtr dom, unsigned int nvcpus,
if (!(flags & VIR_DOMAIN_VCPU_MAXIMUM) && nvcpus > maxvcpus) {
virReportError(VIR_ERR_INVALID_ARG,
_("requested vcpus is greater than max allowable"
- " vcpus for the domain: %d > %d"),
+ " vcpus for the domain: %u > %u"),
nvcpus, maxvcpus);
goto endjob;
}
--
2.9.2
8 years, 4 months
[libvirt] [PATCH 0/2] USB address assignment fixes
by Ján Tomko
Ján Tomko (2):
conf: free the ports array of a USB hub
conf: report an error message for non-existing USB hubs
src/conf/domain_addr.c | 9 +++++++++
.../qemuxml2argv-usb-hub-nonexistent.xml | 19 +++++++++++++++++++
tests/qemuxml2argvtest.c | 3 +++
3 files changed, 31 insertions(+)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-hub-nonexistent.xml
--
2.7.3
8 years, 4 months
[libvirt] [PATCH] libxl_driver: Indent LIBXL_VBD_SECTOR_SIZE macro correctly
by Michal Privoznik
Because of change in caaa1bd357a99ad this macro is no under
#ifdef block. That means it needs to be re-intended correctly.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
Pushed under build-breaker rule.
src/libxl/libxl_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 1170062..a573c82 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -5307,7 +5307,7 @@ libxlDiskPathToID(const char *virtpath)
return id;
}
-#define LIBXL_VBD_SECTOR_SIZE 512
+# define LIBXL_VBD_SECTOR_SIZE 512
static int
libxlDiskSectorSize(int domid, int devno)
--
2.8.4
8 years, 4 months
[libvirt] [PATCH] tests: fix domaincapstest linking for libxl
by Roman Bogorodskiy
Commit 11567cf added some libxl tests into domaincapstest and
added libvirt_driver_libxl_impl.la to domaincapstest_LDADD.
This causes link fail on systems without GNU regex implementation:
gmake[2]: Entering directory '/usr/home/novel/code/libvirt/tests'
CCLD domaincapstest
../src/.libs/libvirt_driver_libxl_impl.a(libvirt_driver_libxl_impl_la-libxl_capabilities.o):
In function `libxlMakeCapabilities':
libxl/libxl_capabilities.c:(.text+0x6b2): undefined reference to
`rpl_regcomp'
libxl/libxl_capabilities.c:(.text+0x6d0): undefined reference to
`rpl_regerror'
libxl/libxl_capabilities.c:(.text+0x803): undefined reference to
`rpl_regexec'
libxl/libxl_capabilities.c:(.text+0xa58): undefined reference to
`rpl_regfree'
clang-3.8: error: linker command failed with exit code 1 (use -v to
see invocation)
This happens because on these system it tries to use gnulib's builtin
regex implementation, but doesn't link to gnulib.
Fix by adding $(GNULIB_LIBS) along with libvirt_driver_libxl_impl.la to
domaincapstest_LDADD.
---
tests/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 5714d11..0cd8391 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -953,7 +953,7 @@ endif WITH_QEMU
if WITH_LIBXL
domaincapstest_SOURCES += testutilsxen.c testutilsxen.h
-domaincapstest_LDADD += ../src/libvirt_driver_libxl_impl.la
+domaincapstest_LDADD += ../src/libvirt_driver_libxl_impl.la $(GNULIB_LIBS)
endif WITH_LIBXL
virnetmessagetest_SOURCES = \
--
2.7.4
8 years, 4 months
[libvirt] [PATCH] libxl: fix unused functions
by Roman Bogorodskiy
Commit eee7bd4e introduced two functions: libxlDiskPathToID and
libxlDiskSectorSize.
However, as they're used only by code under #ifdef __linux__,
on non-Linux platforms it results in errors similar to this:
CC libxl/libvirt_driver_libxl_impl_la-libxl_driver.lo
libxl/libxl_driver.c:5263:1: error: unused function 'libxlDiskPathToID' [-Werror,-Wunused-function]
libxlDiskPathToID(const char *virtpath)
^
libxl/libxl_driver.c:5312:1: error: unused function 'libxlDiskSectorSize' [-Werror,-Wunused-function]
libxlDiskSectorSize(int domid, int devno)
^
2 errors generated.
Fix that by moving these functions under the #ifdef __linux__ block.
---
src/libxl/libxl_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 4957072..1170062 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -5259,6 +5259,7 @@ libxlDomainGetJobStats(virDomainPtr dom,
return ret;
}
+#ifdef __linux__
static int
libxlDiskPathToID(const char *virtpath)
{
@@ -5348,7 +5349,6 @@ libxlDiskSectorSize(int domid, int devno)
return ret;
}
-#ifdef __linux__
static int
libxlDomainBlockStatsVBD(virDomainObjPtr vm,
const char *dev,
--
2.7.4
8 years, 4 months
[libvirt] [PATCH 0/3] Node device update lifecycle event as top level event
by Jovanka Gulicoska
Introduce node device update lifecycle as top level event.
Series include API implementation, udev driver implementation,
event-test implementation and virsh nodedev-event changes.
Jovanka Gulicoska (3):
Introduce node device update event as top level event
virsh: nodedev-event update callback support
event-test: add support node device update event API
daemon/remote.c | 29 +++++++++++++++++
examples/object-events/event-test.c | 12 +++++++
include/libvirt/libvirt-nodedev.h | 1 +
src/conf/node_device_event.c | 55 ++++++++++++++++++++++++++++++++
src/conf/node_device_event.h | 3 ++
src/libvirt_private.syms | 1 +
src/node_device/node_device_udev.c | 2 ++
src/remote/remote_driver.c | 30 ++++++++++++++++++
src/remote/remote_protocol.x | 13 +++++++-
src/remote_protocol-structs | 5 +++
tools/virsh-nodedev.c | 62 ++++++++++++++++++++++++++++++++-----
11 files changed, 204 insertions(+), 9 deletions(-)
--
2.7.4
8 years, 4 months
[libvirt] [PATCH] virsh: Fix core for cmdSecretGetValue
by John Ferlan
https://bugzilla.redhat.com/show_bug.cgi?id=1366611
When commit id 'cb2e3e50' reworked the cmdSecretGetValue call to use
VIR_DISPOSE_STRING for base64, it neglected to initialize the base64
value to NULL since the cleanup: label could be reached prior to the
base64 value being set or not. This resulted in a core dump, adding
the initialization will avoid the issue.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
tools/virsh-secret.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/virsh-secret.c b/tools/virsh-secret.c
index 8588f4c..537bdd7 100644
--- a/tools/virsh-secret.c
+++ b/tools/virsh-secret.c
@@ -253,7 +253,7 @@ static bool
cmdSecretGetValue(vshControl *ctl, const vshCmd *cmd)
{
virSecretPtr secret;
- char *base64;
+ char *base64 = NULL;
unsigned char *value;
size_t value_size;
bool ret = false;
--
2.7.4
8 years, 4 months
[libvirt] Drop support for old libvirt versions?
by Andrea Bolognani
A while ago, we agreed to drop support for QEMU versions older
than 0.12.0, with the rationale that we should focus on
operating systems that are still supported by the respective
vendors, eg. RHEL/CentOS 6, Ubuntu 12.04 and SLES 11.
Recently, when discussing how to ensure a certain change will
not break migration with libvirt <= 0.9.4, I started wondering
whether we should apply the same rationale to libvirt versions
as well.
Here's a quick run down of relevant libvirt versions:
SLES 11 → ???
RHEL 6.0 → 0.8.1
Ubuntu 12.04 → 0.9.2
RHEL 6.8 → 0.10.2
Ubuntu 12.04.5 → 0.9.8
SLES 11 SP4 → 1.2.5
One thing I'm not clear about is whether or not SUSE, Red
Hat and Canonical will support old minor releases or just
the latest one. If the latter, we could safely drop support
for anything older than 0.9.8, which incidentally would make
the discussion referenced above entirely moot ;)
In any case, having a well-defined cut-off point has been
very useful when dealing with QEMU, so I think having one
for libvirt itself would be beneficial too.
Looking forward to your thoughts on this :)
--
Andrea Bolognani / Red Hat / Virtualization
8 years, 4 months
[libvirt] [PATCH] qemu_command: don't modify heads for graphics device
by Pavel Hrdina
Setting heads to 0 in case that *max_outputs* is not supported while building
command line doesn't have any real effect. It only removes *heads* attribute
from live XML, but after restarting libvirt the default value is restored.
Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
---
src/qemu/qemu_command.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 55df23d..06f5091 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -4298,8 +4298,6 @@ qemuBuildDeviceVideoStr(const virDomainDef *def,
virQEMUCapsGet(qemuCaps, QEMU_CAPS_QXL_MAX_OUTPUTS))) {
if (video->heads)
virBufferAsprintf(&buf, ",max_outputs=%u", video->heads);
- } else {
- video->heads = 0;
}
} else if (video->vram &&
((video->type == VIR_DOMAIN_VIDEO_TYPE_VGA &&
--
2.9.2
8 years, 4 months
[libvirt] libvirtd crash with host cpu model qemu64
by Jim Fehlig
I have an L1 nested VM with the following cpu
# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 2
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 6
Model: 2
Model name: QEMU Virtual CPU version 0.14
Stepping: 3
CPU MHz: 3092.210
BogoMIPS: 6184.42
Virtualization: AMD-V
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 64K
L1i cache: 64K
L2 cache: 512K
NUMA node0 CPU(s): 0,1
Flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 syscall nx lm nopl pni cx16 popcnt
hypervisor lahf_lm svm abm sse4a 3dnowprefetch vmmcall
When starting an L2 VM with <cpu mode="host-model">, libvirtd in the L1 VM crashes
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff739bf33 in x86DataCpuid (cpuid=0x8, cpuid=0x8,
data=data@entry=0x7fffb800ee78) at cpu/cpu_x86.c:287
287 for (i = 0; i < data->len; i++) {
(gdb) bt
f0 0x00007ffff739bf33 in x86DataCpuid (cpuid=0x8, cpuid=0x8,
data=data@entry=0x7fffb800ee78) at cpu/cpu_x86.c:287
f1 virCPUx86DataAddCPUID (data=data@entry=0x7fffb800ee78, cpuid=0x8)
at cpu/cpu_x86.c:355
f2 0x00007ffff739ef47 in x86Compute (host=<optimized out>, cpu=0x7fffb8000cc0,
guest=0x7fffecca7348, message=<optimized out>) at cpu/cpu_x86.c:1580
f3 0x00007fffd2b38e53 in qemuBuildCpuModelArgStr (migrating=false,
hasHwVirt=<synthetic pointer>, qemuCaps=0x7fffb8001040, buf=0x7fffecca7360,
def=0x7fffc400ce20, driver=0x1c) at qemu/qemu_command.c:6283
f4 qemuBuildCpuCommandLine (cmd=cmd@entry=0x7fffb8002f60,
driver=driver@entry=0x7fffc80882c0, def=def@entry=0x7fffc400ce20,
qemuCaps=qemuCaps@entry=0x7fffb8001040, migrating=<optimized out>)
at qemu/qemu_command.c:6445
In frame 2, &host_model->vendor->cpuid is passed to virCPUx86DataAddCPUID(),
but
(gdb) p *host_model
$23 = {name = 0x7fffb800ec50 "qemu64", vendor = 0x0, signature = 0, data = {
len = 2, data = 0x7fffb800e720}}
With vendor = 0x0, &host_model->vendor->cpuid evaluates to 8, which is not a
nice value to pass to virCPUx86DataAddCPUID(). I've hacked around the problem by
checking for a non-null host->vendor before calling
virCPUx86DataAddCPUID, but I get the feeling it is just that - a hack.
Comments on the attached patch, or suggestions for an alternate fix, are kindly
welcomed :-).
Regards,
Jim
8 years, 4 months
