[libvirt] [PATCH 0/4] Fix segfault while redefining snapshots and allow redefinition of external snapshots
by Peter Krempa
This series fixes two issues while redefining snapshots:
1) Segfault when disk alignment of the new snapshot failed (patch 3)
2) Failure to redefine external snapshots. A check was missing to align disks for external snapshots. (patch 4)
Peter Krempa (4):
snapshot: conf: Make virDomainSnapshotIsExternal more reusable
snapshot: qemu: Separate logic blocks with newlines
snapshot: qemu: Fix segfault and vanishing snapshots when redefining
snapshot: qemu: Allow redefinition of external snapshots
src/conf/snapshot_conf.c | 14 ++++++++----
src/conf/snapshot_conf.h | 1 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_driver.c | 57 +++++++++++++++++++++++++++++++++++-------------
4 files changed, 54 insertions(+), 19 deletions(-)
--
1.8.0.2
12 years, 3 months
[libvirt] [PATCH 0/4 v2] ivshmem support
by Osier Yang
v1 - v2:
* Change attribute "model" to be a sub-element instead.
NOTE:
Since the invshmem server socket path is not created by
QEMU, but by an external app called "ivshmem_server", It's
not good to construct the socket path in libvirt with a solid
rule, and force the user to figure out what the path is
libvirt uses first and use that for "ivshmem_server". Thus it's
the user's business to set the selinux context on the socket
path so that the qemu process could be started successfully
when selinux is enabled.
Shawn Furrow proposed a patch more than a month ago:
https://www.redhat.com/archives/libvir-list/2012-September/msg01612.html
But this is a complete different implementation. Considering
there could be other memory related devices in futuer, this
introduces a new device model, called "memory device", instead
of a specific device like "ivshmem", though only "ivshmem"
is supported currently. Please refer to PATCH 1/4 for more
details.
CC'ed to Cam and Shawn, to see if there is advise on the documents.
Osier Yang (4):
docs: Add documents for memory device
conf: Parse and format memory device XML
qemu: Add cap flag QEMU_CAPS_IVSHMEM
qemu: Build command line for ivshmem device
docs/formatdomain.html.in | 40 +++++
docs/schemas/domaincommon.rng | 40 +++++
src/conf/domain_conf.c | 195 +++++++++++++++++++++-
src/conf/domain_conf.h | 27 +++
src/libvirt_private.syms | 3 +
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 85 ++++++++++
src/util/util.c | 5 +
src/util/util.h | 2 +
tests/qemuhelptest.c | 12 +-
tests/qemuxml2argvdata/qemuxml2argv-ivshmem.args | 7 +
tests/qemuxml2argvdata/qemuxml2argv-ivshmem.xml | 34 ++++
tests/qemuxml2argvtest.c | 2 +
14 files changed, 450 insertions(+), 5 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ivshmem.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-ivshmem.xml
--
1.7.7.6
12 years, 3 months
[libvirt] [PATCH 0/5] Add API to tunnel channels
by John Eckersberg
This series enables the qemu driver to tunnel a virtio channel. This
is useful for a remote session to communicate with a guest channel via
the streaming API.
This was originally fleshed out a while back in this thread:
https://www.redhat.com/archives/libvir-list/2011-September/msg01049.html
This implements only item (3) in that list.
The new API is nearly identical to the existing virDomainOpenConsole
API, except it works on channels, and supports UNIX sockets in
addition to PTYs for channel source type.
This is my first libvirt patch, please be gentle :)
John Eckersberg (5):
api: Add API to tunnel a guest channel via stream
conf: Rename virconsole.* to virchrdev.*
conf: Rename console-specific identifiers to be more generic
conf: Add unix socket support to virChrdevOpen
qemu: Implement virDomainOpenChannel API
configure.ac | 48 ++---
include/libvirt/libvirt.h.in | 16 ++
po/POTFILES.in | 2 +-
src/Makefile.am | 8 +-
src/conf/virchrdev.c | 442 +++++++++++++++++++++++++++++++++++++++++++
src/conf/virchrdev.h | 37 ++++
src/conf/virconsole.c | 414 ----------------------------------------
src/conf/virconsole.h | 36 ----
src/driver.h | 7 +
src/libvirt.c | 61 ++++++
src/libvirt_private.syms | 8 +-
src/libvirt_public.syms | 5 +
src/qemu/qemu_domain.c | 4 +-
src/qemu/qemu_domain.h | 4 +-
src/qemu/qemu_driver.c | 81 +++++++-
src/remote/remote_driver.c | 1 +
src/remote/remote_protocol.x | 9 +-
src/remote_protocol-structs | 6 +
18 files changed, 697 insertions(+), 492 deletions(-)
create mode 100644 src/conf/virchrdev.c
create mode 100644 src/conf/virchrdev.h
delete mode 100644 src/conf/virconsole.c
delete mode 100644 src/conf/virconsole.h
--
1.7.11.7
12 years, 3 months
[libvirt] [PATCH] build: fix mingw rpm build
by Eric Blake
Commit d13155c changed which files get installed for the
libvirt-guests service, but did not touch up the mingw spec
file. As a result, rpmbuild complained:
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/i686-w64-mingw32/sys-root/mingw/libexec/libvirt-guests.sh
/usr/x86_64-w64-mingw32/sys-root/mingw/libexec/libvirt-guests.sh
which in turn breaks ./autobuild.sh when cross-compilers are present.
* mingw-libvirt.spec.in: Remove files not relevant to mingw.
---
Pushing under the build-breaker rule.
mingw-libvirt.spec.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in
index 4695895..f1540b3 100644
--- a/mingw-libvirt.spec.in
+++ b/mingw-libvirt.spec.in
@@ -177,6 +177,8 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_datadir}/gtk-doc/*
rm -rf $RPM_BUILD_ROOT%{mingw32_libexecdir}/libvirt_iohelper.exe
rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt_iohelper.exe
+rm -rf $RPM_BUILD_ROOT%{mingw32_libexecdir}/libvirt-guests.sh
+rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh
# Mingw32
--
1.8.0.2
12 years, 3 months
[libvirt] [PATCH] network: fix check for ambiguous lookup
by Eric Blake
gcc -O2 complained:
../../src/conf/network_conf.c: In function 'virNetworkDefUpdateDNSSrv':
../../src/conf/network_conf.c:3232: error: 'foundIdx' may be used uninitialized in this function [-Wuninitialized]
It turned out to be a spurious warning (we didn't use foundIdx
unless foundCt was non-zero). But in investigating that, I noticed
a worse problem: we were using 'if (foundCt > 1)', but since foundCt
was bool, it could never be > 1.
* src/conf/network_conf.c (virNetworkDefUpdateDNSHost): Use
correct type.
(virNetworkDefUpdateDNSSrv): Likewise, and silence compiler
warning.
---
Pushing under the build-breaker rule in order to shut up the gcc
warning, and under the trivial rule to fix the wrong type.
src/conf/network_conf.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index f949f79..d185b46 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -1,7 +1,7 @@
/*
* network_conf.c: network XML handling
*
- * Copyright (C) 2006-2012 Red Hat, Inc.
+ * Copyright (C) 2006-2013 Red Hat, Inc.
* Copyright (C) 2006-2008 Daniel P. Berrange
*
* This library is free software; you can redistribute it and/or
@@ -3138,7 +3138,7 @@ virNetworkDefUpdateDNSHost(virNetworkDefPtr def,
virNetworkDNSHostDef host;
bool isAdd = (command == VIR_NETWORK_UPDATE_COMMAND_ADD_FIRST ||
command == VIR_NETWORK_UPDATE_COMMAND_ADD_LAST);
- bool foundCt = 0;
+ int foundCt = 0;
memset(&host, 0, sizeof(host));
@@ -3229,12 +3229,12 @@ virNetworkDefUpdateDNSSrv(virNetworkDefPtr def,
/* virNetworkUpdateFlags */
unsigned int fflags ATTRIBUTE_UNUSED)
{
- int ii, foundIdx, ret = -1;
+ int ii, foundIdx = -1, ret = -1;
virNetworkDNSDefPtr dns = &def->dns;
virNetworkDNSSrvDef srv;
bool isAdd = (command == VIR_NETWORK_UPDATE_COMMAND_ADD_FIRST ||
command == VIR_NETWORK_UPDATE_COMMAND_ADD_LAST);
- bool foundCt = 0;
+ int foundCt = 0;
memset(&srv, 0, sizeof(srv));
--
1.7.1
12 years, 3 months
[libvirt] [PATCH 2/2] target-i386: Disable kvm_mmu_op by default on pc-1.4
by Eduardo Habkost
The kvm_mmu_op feature was removed from the kernel since v3.3 (released
in March 2012), it was marked for removal since January 2011 and it's
slower than shadow or hardware assisted paging (see kernel commit
fb92045843). It doesn't make sense to keep it enabled by default.
Also, keeping it enabled by default would cause unnecessary hassle when
libvirt start using the "enforce" option.
Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com>
---
Cc: kvm(a)vger.kernel.org
Cc: Michael S. Tsirkin <mst(a)redhat.com>
Cc: Gleb Natapov <gleb(a)redhat.com>
Cc: Marcelo Tosatti <mtosatti(a)redhat.com>
Cc: libvir-list(a)redhat.com
Cc: Jiri Denemark <jdenemar(a)redhat.com>
I was planning to reverse the logic of the compat init functions and make
pc_init_pci_1_3() enable kvm_mmu_op and then call pc_init_pci_1_4(). But that
would require changing pc_init_pci_no_kvmclock() and pc_init_isa() as well. So
to keep the changes simple, I am keeping the pattern used when pc_init_pci_1_3()
was introduced, making pc_init_pci_1_4() disable kvm_mmu_op and then call
pc_init_pci_1_3().
---
hw/pc_piix.c | 11 ++++++++++-
target-i386/cpu.c | 8 ++++++++
target-i386/cpu.h | 1 +
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 99747a7..a6bf645 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -217,6 +217,7 @@ static void pc_init1(MemoryRegion *system_memory,
}
}
+/* machine init function for pc-0.14 - pc-1.2 */
static void pc_init_pci(QEMUMachineInitArgs *args)
{
ram_addr_t ram_size = args->ram_size;
@@ -232,12 +233,20 @@ static void pc_init_pci(QEMUMachineInitArgs *args)
initrd_filename, cpu_model, 1, 1);
}
+/* machine init function for pc-1.3 */
static void pc_init_pci_1_3(QEMUMachineInitArgs *args)
{
enable_kvm_pv_eoi();
pc_init_pci(args);
}
+/* machine init function for pc-1.4 */
+static void pc_init_pci_1_4(QEMUMachineInitArgs *args)
+{
+ disable_kvm_mmu_op();
+ pc_init_pci_1_3(args);
+}
+
static void pc_init_pci_no_kvmclock(QEMUMachineInitArgs *args)
{
ram_addr_t ram_size = args->ram_size;
@@ -285,7 +294,7 @@ static QEMUMachine pc_machine_v1_4 = {
.name = "pc-1.4",
.alias = "pc",
.desc = "Standard PC",
- .init = pc_init_pci_1_3,
+ .init = pc_init_pci_1_4,
.max_cpus = 255,
.is_default = 1,
};
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 808001a..ec877c7 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -157,6 +157,14 @@ void enable_kvm_pv_eoi(void)
#endif
}
+void disable_kvm_mmu_op(void)
+{
+#ifdef CONFIG_KVM
+ if (kvm_enabled())
+ kvm_default_features &= ~(1UL << KVM_FEATURE_MMU_OP);
+#endif
+}
+
void host_cpuid(uint32_t function, uint32_t count,
uint32_t *eax, uint32_t *ebx, uint32_t *ecx, uint32_t *edx)
{
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 1283537..27c8d0c 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1219,5 +1219,6 @@ void do_smm_enter(CPUX86State *env1);
void cpu_report_tpr_access(CPUX86State *env, TPRAccess access);
void enable_kvm_pv_eoi(void);
+void disable_kvm_mmu_op(void);
#endif /* CPU_I386_H */
--
1.7.11.7
12 years, 3 months
[libvirt] [PATCH 0/9] target-i386: make "enforce" flag work as it should
by Eduardo Habkost
This changes the -cpu check/enforce code to work as it should: it will
check every single CPUID bit to make sure it is supported by the host.
The changes are a bit intrusive, but:
- The longer we take to make "enforce" strict as it should (and make libvirt
finally use it), more users will have VMs with migration-unsafe unpredictable
guest ABIs. For this reason, I would like to get this into QEMU 1.4.
- The changes in this series should affect only users that are already using
the "enforce" flag, and I believe whoever is using the "enforce" flag really
want the strict behavior introduced by this series.
This series is based on Andreas' qom-cpu branch, and depends on the series:
Subject: [PATCH 0/2] Disable kvm_mmu_op by default on pc-1.4
Message-Id: <1357311145-16410-1-git-send-email-ehabkost(a)redhat.com>
Git tree for reference:
git://github.com/ehabkost/qemu-hacks.git cpu-enforce-all.v1
https://github.com/ehabkost/qemu-hacks/tree/cpu-enforce-all.v1
Eduardo Habkost (9):
target-i386: kvm: -cpu host: Use GET_SUPPORTED_CPUID for SVM features
target-i386: kvm: Enable all supported KVM features for -cpu host
target-i386: check/enforce: Fix CPUID leaf numbers on error messages
target-i386: check/enforce: Do not ignore "hypervisor" flag
target-i386: check/enforce: Check all CPUID.80000001H.EDX bits
target-i386: check/enforce: Check SVM flag support as well
target-i386: check/enforce: Eliminate check_feat field
target-i386: Call kvm_check_features_against_host() only if
CONFIG_KVM is set
target-i386: check/enforce: Check all feature words
target-i386/cpu.c | 73 +++++++++++++++++++++++++++++++++++++++----------------
target-i386/cpu.h | 3 +++
2 files changed, 55 insertions(+), 21 deletions(-)
--
1.7.11.7
12 years, 3 months
[libvirt] [PATCH] Fix substitution of sbindir in virtlockd.service
by Jim Fehlig
The makefile rule substitutes variables delimited by '::', but the
virtlockd service files uses '@'. Change the service file to
match the makefile rule.
---
src/locking/virtlockd.service.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/locking/virtlockd.service.in b/src/locking/virtlockd.service.in
index a9f9f93..dad7c19 100644
--- a/src/locking/virtlockd.service.in
+++ b/src/locking/virtlockd.service.in
@@ -5,7 +5,7 @@ After=syslog.target
[Service]
EnvironmentFile=-/etc/sysconfig/virtlockd
-ExecStart=@sbindir@/virtlockd
+ExecStart=::sbindir::/virtlockd
ExecReload=/bin/kill -HUP $MAINPID
# Loosing the locks is a really bad thing that will
# cause the machine to be fenced (rebooted), so make
--
1.8.0.1
12 years, 3 months
[libvirt] [PATCH] qemu: Detect VGA_QXL capability correctly
by Michal Privoznik
Since 4c993d8a we failed to set this important capability, which
allows starting a domain with QXL video card. We set DEVICE_QXL
capability bit instead, which is not necessary wrong. Anyway, if
qemu supports the new '-device qxl' it supports older '-vga qxl'
as well. The latter is used for the primary (the first) qxl video
card, the former for other video cards.
---
Other approach is to set QEMU_CAPS_VGA_QXL unconditionally
as supported by all qemu-1.2+ in qemuCapsInitQMPBasic().
But I think this one is slightly nicer.
src/qemu/qemu_capabilities.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index f49a31c..e16bc70 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2018,6 +2018,9 @@ qemuCapsProbeQMPObjects(qemuCapsPtr caps,
/* Prefer -chardev spicevmc (detected earlier) over -device spicevmc */
if (qemuCapsGet(caps, QEMU_CAPS_CHARDEV_SPICEVMC))
qemuCapsClear(caps, QEMU_CAPS_DEVICE_SPICEVMC);
+ /* If qemu supports newer -device qxl it supports -vga qxl as well */
+ if (qemuCapsGet(caps, QEMU_CAPS_DEVICE_QXL))
+ qemuCapsSet(caps, QEMU_CAPS_VGA_QXL);
return 0;
}
--
1.8.0.2
12 years, 3 months
[libvirt] libvirt unable to start domains
by Zeeshan Ali (Khattak)
Hi,
I updated my libvirt git clone and install yesterday (after about a
month or so) and now I can't start domains:
$ virsh start fedora18
error: Failed to start domain fedora18
error: unsupported configuration: This QEMU does not support QXL
graphics adapters
While libvirt is self-built, I'm using qemu 1.2.2-1.fc18 from vanila
Fedora 18 repo. Just to be clear, qemu was not updated before the
problem appeared, only libvirt.
Here is the libvirtd log:
http://static.fi/~zeenix/tmp/libvirtd-session-zeenix.log (13 MB).
Also attaching the domain config.
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
12 years, 3 months
