[libvirt] [PATCH] Define ISCSIADM unconditionally
by Ján Tomko
Commit 5e1d5dd moved the functions using isciadm to util/viriscsi.c,
but ISCSIADM was only defined when the iscsi backend was compiled in.
Define it unconditionally to fix the build (and allow testing
of viriscsi.c) even if iscsi backend is disabled.
---
Pushed as a build breaker fix.
configure.ac | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 62b74c5..85d0dbe 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1852,9 +1852,13 @@ if test "$with_storage_iscsi" = "yes" || test "$with_storage_iscsi" = "check"; t
if test "$with_storage_iscsi" = "yes" ; then
AC_DEFINE_UNQUOTED([WITH_STORAGE_ISCSI], 1, [whether iSCSI backend for storage driver is enabled])
- AC_DEFINE_UNQUOTED([ISCSIADM],["$ISCSIADM"],[Location of iscsiadm program])
fi
fi
+if test -z "$ISCIADM" ; then
+ AC_DEFINE_UNQUOTED([ISCSIADM],["iscsiadm"],[Name of iscsiadm program])
+else
+ AC_DEFINE_UNQUOTED([ISCSIADM],["$ISCSIADM"],[Location of iscsiadm program])
+fi
AM_CONDITIONAL([WITH_STORAGE_ISCSI], [test "$with_storage_iscsi" = "yes"])
if test "$with_storage_scsi" = "check"; then
--
1.8.3.2
10 years, 9 months
[libvirt] [PATCHv2 0/8] Test parsing of iscsiadm output
by Ján Tomko
v1: https://www.redhat.com/archives/libvir-list/2014-March/msg00720.html
v2:
* instead of using cat, switch RunProgRegex to use a synchronous command
and modify the output buffer via a virCommandDryRun callback
* move the functions dealing with iscsiadm out of the iscsi backend
to src/util (and move StorageBackendRunRegex as well)
Ján Tomko (8):
Sort includes in storage_backend_iscsi.c
Move virStorageBackendRun to vircommand
Switch virCommandRunRegex to use virStringSplit
Don't create iscsiadm command line in ISCSIPool{Start,Stop}
Remove storage pool from the arguments of a few functions
Move functions using iscsiadm to viriscsi.c
Add test for virISCSIGetSession
Add test for virISCSIScanTargets
po/POTFILES.in | 1 +
src/Makefile.am | 1 +
src/libvirt_private.syms | 11 +
src/storage/storage_backend.c | 249 -----------------
src/storage/storage_backend.h | 22 --
src/storage/storage_backend_disk.c | 43 +--
src/storage/storage_backend_fs.c | 9 +-
src/storage/storage_backend_iscsi.c | 482 ++------------------------------
src/storage/storage_backend_iscsi.h | 4 -
src/storage/storage_backend_logical.c | 63 +++--
src/util/vircommand.c | 242 +++++++++++++++++
src/util/vircommand.h | 20 ++
src/util/viriscsi.c | 498 ++++++++++++++++++++++++++++++++++
src/util/viriscsi.h | 52 ++++
tests/Makefile.am | 6 +
tests/viriscsitest.c | 219 +++++++++++++++
16 files changed, 1145 insertions(+), 777 deletions(-)
create mode 100644 src/util/viriscsi.c
create mode 100644 src/util/viriscsi.h
create mode 100644 tests/viriscsitest.c
--
1.8.3.2
10 years, 9 months
[libvirt] [PATCH 0/2] AppArmor updates
by Felix Geyer
I'm working on getting AppArmor support enabled in the Debian libvirt package.
As a result I've updated the profiles in example/ and added support for
filesystem mounts.
Felix Geyer (2):
apparmor: Allow access to filesystem mounts
apparmor: Improve profiles
examples/apparmor/libvirt-qemu | 21 +++++++++++++++----
examples/apparmor/usr.lib.libvirt.virt-aa-helper | 10 +++++++++
examples/apparmor/usr.sbin.libvirtd | 16 +++++++++++----
src/security/virt-aa-helper.c | 26 ++++++++++++++++++------
4 files changed, 59 insertions(+), 14 deletions(-)
--
1.8.5.3
10 years, 9 months
[libvirt] [PATCH v7 0/4] support dumping guest memory in compressed format
by qiaonuohan＠cn.fujitsu.com
dumping guest's memory is introduced without compression supported, but now
qemu can dump guest's memory in kdump-compressed format. This patchset is used
to add support in libvirt side to let qemu do the dump in compressed format and
please refer the following address to see implementation of the qemu side, the
lastest version of qemu side is v9.
http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg03016.html
ChangLog:
Changes from v6 to v7:
1. revert changing dumpformat of virDomainCoreDumpWithFormat back to an enum
Changes from v5 to v6:
1. add qemuMonitorGetDumpGuestMemoryCapability API to check the available dump
format
Changes from v4 to v5:
1. modify some restriction check
Changes from v3 to v4:
1. dropping patch "add dump_memory_format in qemu.conf"
2. fix to follow some conventions
Changes from v2 to v3:
1. address Jiri Denemark's comment about adding a new public API instead of
changing an old one.
Changes from v1 to v2:
1. address Daniel P. Berrange's comment about using a new parameter to replace
flags like VIR_DUMP_COMPRESS_ZLIB.
qiaonuohan (4):
add new virDomainCoreDumpWithFormat API
qemu: add qemuMonitorGetDumpGuestMemoryCapability
qemu: add support for virDomainCoreDumpWithFormat API
allow "virsh dump --memory-only" specify dump format
include/libvirt/libvirt.h.in | 31 ++++++++++++++
src/driver.h | 7 ++++
src/libvirt.c | 98 ++++++++++++++++++++++++++++++++++++++++++++
src/libvirt_public.syms | 5 +++
src/qemu/qemu_driver.c | 70 ++++++++++++++++++++++++++-----
src/qemu/qemu_monitor.c | 27 ++++++++++--
src/qemu/qemu_monitor.h | 6 ++-
src/qemu/qemu_monitor_json.c | 69 ++++++++++++++++++++++++++++++-
src/qemu/qemu_monitor_json.h | 6 ++-
src/remote/remote_driver.c | 1 +
src/remote/remote_protocol.x | 15 ++++++-
src/remote_protocol-structs | 7 ++++
src/test/test_driver.c | 22 ++++++++--
tests/qemumonitorjsontest.c | 2 +-
tools/virsh-domain.c | 45 ++++++++++++++++++--
tools/virsh.pod | 5 +++
16 files changed, 391 insertions(+), 25 deletions(-)
--
1.8.5.3
10 years, 9 months
[libvirt] [PATCH 0/3] Check boot order on device attach
by Jiri Denemark
https://bugzilla.redhat.com/show_bug.cgi?id=1007754
When attaching a new device, we need to check if its boot order
configuration is compatible with current domain definition.
Jiri Denemark (3):
Fix usage of virDomainDefCompatibleDevice
Pass action to virDomainDefCompatibleDevice
Check boot order on device attach
src/conf/domain_conf.c | 85 +++++++++++++++++++++++++++++++++++++++++++++++++-
src/conf/domain_conf.h | 10 +++++-
src/lxc/lxc_driver.c | 32 ++++++++++++-------
src/qemu/qemu_driver.c | 32 ++++++++++++-------
4 files changed, 133 insertions(+), 26 deletions(-)
--
1.9.1
10 years, 9 months
[libvirt] [PATCH] tests: Set abs_*dir in a consistent way
by Jiri Denemark
Use $(shell cd $(...) && pwd) to set abs_*dir variables similarly to
what src/Makefile.am does.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
tests/Makefile.am | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 90f70ff..20a98c7 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -16,6 +16,10 @@
## License along with this library. If not, see
## <http://www.gnu.org/licenses/>.
+# old automake does not provide abs_{src,build}dir variables
+abs_builddir = $(shell pwd)
+abs_srcdir = $(shell cd $(srcdir) && pwd)
+
SHELL = $(PREFERABLY_POSIX_SHELL)
INCLUDES = \
@@ -28,8 +32,8 @@ INCLUDES = \
$(GETTEXT_CPPFLAGS)
AM_CFLAGS = \
- -Dabs_builddir="\"`pwd`\"" \
- -Dabs_srcdir="\"`cd '$(srcdir)'; pwd`\"" \
+ -Dabs_builddir="\"$(abs_builddir)\"" \
+ -Dabs_srcdir="\"$(abs_srcdir)\"" \
$(LIBXML_CFLAGS) \
$(GNUTLS_CFLAGS) \
$(SASL_CFLAGS) \
@@ -373,7 +377,7 @@ TESTS = $(test_programs) \
# Also, BSD sh doesn't like 'a=b b=$$a', so we can't use an
# intermediate shell variable, but must do all the expansion in make
-lv_abs_top_builddir=`cd '$(top_builddir)'; pwd`
+lv_abs_top_builddir=$(shell cd '$(top_builddir)'; pwd)
path_add = $(subst :,$(PATH_SEPARATOR),\
$(subst !,$(lv_abs_top_builddir)/,!daemon:!tools:!tests))
@@ -381,9 +385,9 @@ VIR_TEST_EXPENSIVE ?= $(VIR_TEST_EXPENSIVE_DEFAULT)
TESTS_ENVIRONMENT = \
abs_top_builddir=$(lv_abs_top_builddir) \
abs_top_srcdir=`cd '$(top_srcdir)'; pwd` \
- abs_builddir=`pwd` \
- abs_srcdir=`cd '$(srcdir)'; pwd` \
- CONFIG_HEADER="`cd '$(top_builddir)'; pwd`/config.h" \
+ abs_builddir=$(abs_builddir) \
+ abs_srcdir=$(abs_srcdir) \
+ CONFIG_HEADER="$(lv_abs_top_builddir)/config.h" \
PATH="$(path_add)$(PATH_SEPARATOR)$$PATH" \
SHELL="$(SHELL)" \
LIBVIRT_DRIVER_DIR="$(lv_abs_top_builddir)/src/.libs" \
--
1.9.0
10 years, 9 months
[libvirt] [PATCH] qemu: Return meaningful error when qemu dies early
by Jiri Denemark
https://bugzilla.redhat.com/show_bug.cgi?id=844378
When qemu dies early after connecting to its monitor but before we
actually try to read something from the monitor, we would just fail
domain start with useless message:
"An error occurred, but the cause is unknown"
This is because the real error gets reported in a monitor EOF handler
executing within libvirt's event loop.
The fix is to take any error set in qemuMonitor structure and propagate
it into the thread-local error when qemuMonitorClose is called and no
thread-local error is set.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/qemu/qemu_monitor.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c
index b2af0ae..bca2612 100644
--- a/src/qemu/qemu_monitor.c
+++ b/src/qemu/qemu_monitor.c
@@ -924,6 +924,12 @@ void qemuMonitorClose(qemuMonitorPtr mon)
virCondSignal(&mon->notify);
}
+ /* Propagate existing monitor error in case the current thread has no
+ * error set.
+ */
+ if (mon->lastError.code != VIR_ERR_OK && !virGetLastError())
+ virSetError(&mon->lastError);
+
virObjectUnlock(mon);
virObjectUnref(mon);
}
--
1.9.0
10 years, 9 months
[libvirt] CPU Topology in Libvirt Java 0.51
by Vikas Kokare
We are trying to get the cpu topology data (cores, sockets, threads) using
the Java binding of the libvirt API, after connecting to a hypervisor. We
are expecting the domain (vm) XML payload to contain the <cpu> element with
the <topology> sub-element, but it is not present.
<cpu mode='custom' match='exact'>
<model fallback='allow'>Penryn</model>
<vendor>Intel</vendor>
<feature policy='require' name='tm2'/>
...
</cpu>
10 years, 9 months
Re: [libvirt] Adding support to limit client connections for vnc/spice display driver
by Patil, Tushar
On Wed, Mar 19, 2014 at 06:41:16PM +0000, Patil, Tushar wrote:
> >
>> We are using KVM hypervisor driver for running OpenStack IaaS. Couple
>> of months back we have reported one security issue [1] in OS. Basically
>> we want to limit on the number of vnc client connections that can be
>> opened by users for a given VM. I know that there is share policy where
>> you can specify "VNC_SHARE_MODE_EXCLUSIVE" share mode. But it only allows
>> one client connection to the vnc console, it will disconnect all previously
>> opened vnc client connections. Since vnc display driver already has the
>> data of client connections, it would be possible to add the logic to limit
>> on the number of client connections.
>>
>> What we want is the ability to specify threshold how many vnc client
>> connections should be allowed at any given point of time in the domain
>> xml for graphics device (especially for vnc/spice)?
>>
>> Example
> ><graphics type="vnc" autoport="yes" keymap="en-us" listen="127.0.0.1"/, share-policy="limit-connections", connections="5">
>>
>> Add support to accept new share policy "limit-connections'.
>> So in the above example, when user tries to open vnc display for the 6th
>>time, then the request should be rejected.
>>
>> I need your expert opinion in deciding whether it's a good idea to add
>> this support in the vnc/spice display driver or this kind of constraint
>> should be imposed outside libvirt?
> Libvirt isn't at all involved in vnc/spice connections. They happen
> directly between QEMU & the client app, optionally via Nova's proxy
> service. If QEMU had a setting for such a limit then libvirt could
> set it, but AFAIK none exists, so there's nothing libvirt can do
> about this currently. So options are either todo work in QEMU to
> add this config feature, then wire it into libvirt, or address it in
> the Nova proxy service.
Thanks for your advice. I will add a new feature request in qemu. After this feature is added to qemu, I will then add a request in libvirt to use the newly added parameters.
Thanks and Best Regards,
Tushar
______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding
10 years, 9 months
