Re: [libvirt] [PATCH] bhyve: fix build with gcc48
On 05/23/2015 02:45 PM, Martin Kletzander wrote:
On Sat, May 23, 2015 at 08:05:23PM +0300, Roman Bogorodskiy wrote:
Build with gcc 4.8 fails with:
Arguably a bug in gcc; but since we can work around it without too much
pain, we should.
bhyve/bhyve_monitor.c: In function 'bhyveMonitorIO':
bhyveMonitorIO(int watch, int kq, int events ATTRIBUTE_UNUSED, void
*opaque)
{
-const struct timespec zerowait = {};
+const struct timespec zerowait = { 0, 0 };
Would also be sufficient to do 'zerowait = { 0 };' - any C compiler that
warns about an initializer of { 0 } is broken, because that is THE
idiomatic way to zero-initialize anything (scalar or structure)
according to C99.
You need to set at least minimum one field, all others will be set
to 0. But this is of course very right thing to do.
ACK, structures shouldn't be initialized this way.
Go ahead and push as you have it, though, with two members, since we
know struct timespec has (at least) two members.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] zfs: fix storagepoolxml2xml test
On Sat, May 23, 2015 at 10:49:09PM +0300, Roman Bogorodskiy wrote: Commit c4d27bd dropped output of owner/group -1. Update zfs tests accordingly. --- tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml | 2 -- tests/storagepoolxml2xmlout/pool-zfs.xml | 2 -- 2 files changed, 4 deletions(-) ACK diff --git a/tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml b/tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml index bbd2e9f..89dcdbf 100644 --- a/tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml +++ b/tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml @@ -12,8 +12,6 @@ path/dev/zvol/testpool/path permissions mode0755/mode - owner-1/owner - group-1/group /permissions /target /pool diff --git a/tests/storagepoolxml2xmlout/pool-zfs.xml b/tests/storagepoolxml2xmlout/pool-zfs.xml index ff02329..c9e5df9 100644 --- a/tests/storagepoolxml2xmlout/pool-zfs.xml +++ b/tests/storagepoolxml2xmlout/pool-zfs.xml @@ -11,8 +11,6 @@ path/dev/zvol/testpool/path permissions mode0755/mode - owner-1/owner - group-1/group /permissions /target /pool -- 2.3.7 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] libxl: load on FreeBSD
On Sat, May 23, 2015 at 09:15:08PM +0300, Roman Bogorodskiy wrote:
The libxl tries to check if it's running in dom0 by parsing
/proc/xen/capabilities and if that fails it doesn't load.
There's no procfs interface in Xen on FreeBSD, so this check always
fails.
Instead of using procfs, check if /dev/xen/xenstored, that's enough to
check if we're running in dom0 in FreeBSD case.
--
The 'HYPERVISOR_CAPABILITIES' name could be misleading now, however, I'd
prefer to use a common variable to avoid duplicating of the file checking
code. Maybe it should be renamed to something like HYPERVISOR_CONTROL?
You can just add new one, XENSTORED for example, and check whether at
least one exists, reading the file afterwards if it is the old one.
It might not be FreeBSD-specific. What's your opinion?
---
src/libxl/libxl_driver.c | 41 +
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 12be816..c848210 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -73,7 +73,11 @@ VIR_LOG_INIT(libxl.libxl_driver);
#define LIBXL_CONFIG_FORMAT_XM xen-xm
#define LIBXL_CONFIG_FORMAT_SEXPR xen-sxpr
-#define HYPERVISOR_CAPABILITIES /proc/xen/capabilities
+#ifdef __FreeBSD__
+# define HYPERVISOR_CAPABILITIES /dev/xen/xenstored
+#else
+# define HYPERVISOR_CAPABILITIES /proc/xen/capabilities
+#endif
/* Number of Xen scheduler parameters */
#define XEN_SCHED_CREDIT_NPARAM 2
@@ -427,8 +431,6 @@ static bool
libxlDriverShouldLoad(bool privileged)
{
bool ret = false;
-int status;
-char *output = NULL;
/* Don't load if non-root */
if (!privileged) {
@@ -441,21 +443,28 @@ libxlDriverShouldLoad(bool privileged)
does not exist);
return ret;
}
-/*
- * Don't load if not running on a Xen control domain (dom0). It is not
- * sufficient to check for the file to exist as any guest can mount
- * xenfs to /proc/xen.
- */
-status = virFileReadAll(HYPERVISOR_CAPABILITIES, 10, output);
-if (status = 0)
-status = strncmp(output, control_d, 9);
-VIR_FREE(output);
-if (status) {
-VIR_INFO(No Xen capabilities detected, probably not running
- in a Xen Dom0. Disabling libxenlight driver);
+#if !defined(__FreeBSD__)
if you're using ifdef upwards, then ifndef would look better here.
But that's just the tiniest thing ever.
+{
+int status;
+char *output = NULL;
-return ret;
+/*
+ * Don't load if not running on a Xen control domain (dom0). It is not
+ * sufficient to check for the file to exist as any guest can mount
+ * xenfs to /proc/xen.
+ */
+status = virFileReadAll(HYPERVISOR_CAPABILITIES, 10, output);
+if (status = 0)
+status = strncmp(output, control_d, 9);
+VIR_FREE(output);
+if (status) {
+VIR_INFO(No Xen capabilities detected, probably not running
+ in a Xen Dom0. Disabling libxenlight driver);
+
+return ret;
+}
}
+#endif
/* Don't load if legacy xen toolstack (xend) is in use */
if (virFileExists(/usr/sbin/xend)) {
--
2.3.7
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] qemu: Force capabilities cache refresh if libvirtd date is different
On Sat, May 23, 2015 at 10:33:30AM -0400, John Ferlan wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1195882
Original commit id 'cbde3589' indicates that the cache file would be
discarded if either the QEMU binary or libvirtd 'ctime' changes; however,
the code only discarded if the QEMU binary time didn't match or if the
new libvirtd ctime was later than what created the cache file.
Since many factors come into play with 'ctime' adjustments (including
perhaps turning back the hands of time), change the logic to also force
a refresh if the ctime of libvirt is different than what's in the cache.
Signed-off-by: John Ferlan jfer...@redhat.com
---
src/qemu/qemu_capabilities.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
ACK
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 375df22..a6fae38 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2981,9 +2981,9 @@ virQEMUCapsInitCached(virQEMUCapsPtr qemuCaps, const char
*cacheDir)
goto cleanup;
}
-/* Discard if cache is older that QEMU binary */
+/* Discard cache if QEMU binary or libvirtd changed */
if (qemuctime != qemuCaps-ctime ||
-selfctime virGetSelfLastChanged()) {
+selfctime != virGetSelfLastChanged()) {
VIR_DEBUG(Outdated cached capabilities '%s' for '%s'
(%lld vs %lld, %lld vs %lld),
capsfile, qemuCaps-binary,
--
2.1.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2] netdev: fail when setting up an SRIOV VF if PF is offline
On Fri, May 15, 2015 at 03:04:14PM -0400, Laine Stump wrote:
If an SRIOV PF is offline, the kernel won't complain if you set the
mac address and vlan tag for a VF via this PF, and it will even let
you assign the VF to a guest using PCI device assignment or macvtap
passthrough. But in this case (the PF isn't online), the device won't
be usable in the guest.
Silently setting the PF online would solve the connectivity problem,
but as pointed out by Dan Berrange, when an interface is set online
with no associated config, the kernel will by default turn on IPv6
autoconf, which could create unexpected security problems for the
host. For this reason, this patch instead logs an error and fails the
operation.
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=893738
Originally filed against RHEL6, but present in every version of
libvirt until today.
---
src/util/virnetdev.c | 22 ++
1 file changed, 22 insertions(+)
ACK
diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c
index e14b401..d0580a0 100644
--- a/src/util/virnetdev.c
+++ b/src/util/virnetdev.c
@@ -2258,6 +2258,28 @@ virNetDevReplaceVfConfig(const char *pflinkdev, int vf,
char macstr[VIR_MAC_STRING_BUFLEN];
char *fileData = NULL;
int ifindex = -1;
+bool pfIsOnline;
+
+/* Assure that PF is online prior to twiddling with the VF. It
+ * *should* be, but if the PF isn't online the changes made to the
+ * VF via the PF won't take effect, yet there will be no error
+ * reported. In the case that it isn't online, fail and report the
+ * error, since setting an unconfigured interface online
+ * automatically turns on IPv6 autoconfig, which may not be what
+ * the admin expects, so we want them to explicitly enable the PF
+ * in the host system network config.
+ */
+if (virNetDevGetOnline(pflinkdev, pfIsOnline) 0)
+ goto cleanup;
+if (!pfIsOnline) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+ Unable to configure VF %d of PF '%s'
+ because the PF is not online. Please
+ change host network config to put the
+ PF online.,
+ vf, pflinkdev);
+goto cleanup;
+}
if (virNetDevGetVfConfig(pflinkdev, vf, oldmac, oldvlanid) 0)
goto cleanup;
--
2.1.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 07/13] Add libvirt-admin library
On Fri, May 22, 2015 at 12:59:44PM +0100, Daniel P. Berrange wrote: On Thu, May 21, 2015 at 10:22:26PM -0700, Martin Kletzander wrote: On Thu, May 21, 2015 at 05:46:59PM +0200, Michal Privoznik wrote: On 20.05.2015 07:19, Martin Kletzander wrote: Initial scratch of the admin library. It has its own virAdmConnectPtr that inherits from virAbstractConnectPtr and thus trivially supports error reporting. There's pkg-config file added and spec-file adjusted as well. Since the library should be minimalistic and not depend on any other library, the list of files is especially crafted for it. Most of them could've been put to it's own sub-libraries that would be LIBADD'd to libvirt_util, libvirt_net_rpc and libvirt_setuid_rpc_client to minimize the number of object files being built, but that's a refactoring that isn't the orginal aim of this commit. + datatypes.c \ + util/viralloc.c \ + util/viratomic.c\ + util/virauth.c \ + util/virauthconfig.c\ + util/virbitmap.c\ + util/virbuffer.c\ + util/vircommand.c \ + util/virerror.c \ + util/virevent.c \ + util/vireventpoll.c \ + util/virfile.c \ + util/virhash.c \ + util/virhashcode.c \ + util/virjson.c \ + util/virkeyfile.c \ + util/virlog.c \ + util/virobject.c\ + util/virpidfile.c \ + util/virprocess.c \ + util/virrandom.c\ + util/virseclabel.c \ + util/virsocketaddr.c\ + util/virstorageencryption.c \ + util/virstoragefile.c \ + util/virstring.c\ + util/virthread.c\ + util/virtime.c \ + util/virtypedparam.c\ + util/viruri.c \ + util/virutil.c \ + util/viruuid.c \ + util/virxml.c \ + remote/remote_protocol.c\ This drags in (de)serializers for all the public APIs we have. I guess you have it here just becase of serializers for some basic types (e.g. string). Well, if we introduce a separate libvirt_admin.x file, rpcgen will generate the serializers again, and just for the types we need. So I think it's safe to drop this line (and libvirt-admin.so will lose some weight). Yes, but I have to rename that to something else than remote_string because that would collide in the libvirt daemon. That would mean I have to add each of the new names to gendispatch.pl. And so on and so on, just to get rid of some (de)serializers in the client library. I'll do that for remote_string for now, but if there are more than that, we should probably put those into another file. Well, you'll see how much bigger the diff will be even now. Then, I wonder if we need to recompile nearly all utils/ again. Can't we just link libvirt_utils.so in? Well, I wanted to make it lightweight even when it increases compilation time as it looks like we are constantly OK with that (setuid_rpc_client, vbox libs, etc.), but as I said in the commit message, I'd like to see a commit that minimizes the files being compiled. I don't think you are actually making this lightweight as you intend. In reality anyone who is using libvirt-admin.so will likely already have libvirt.so in memory. So by recompiling the files you are causing two copies of the same code to be kept in RAM. So if libvirt-admin.so just linked to libvirt.so, then we would in fact be more lightweight than this, and avoid the recompilation. OK, I though that shouldn't be the case, so it is installable separably, but since we allow only local socket for now, you're right that there's libvirt.so already loaded. The recompilation for the setuid binary is a special case because we have security requirements that trump the extra overhead that the duplication implies both at compile time and runtime. So I don't think the recompilation is really justified in the case of libvirt-admin.so One day though, I do think we should perhaps turn things like libvirt_util.la, libvirt_rpc.la, etc into a formally installed .so's that we can dynamically link to from other libvirt parts. We'd /not/ include any header files, as these .so's would be solely for libvirt usage, not application usage. I think this would ultimately better achieve what you're trying todo here. Regards,
Re: [libvirt] Plans for next release
On Sat, May 23, 2015 at 09:22:00PM +0800, Daniel Veillard wrote: Hi everybody, if we want to get it by next month, we should probably freeze on Tuesday for an 1.2.16 on June 1st, we 'only' have 137 commits since 1.2.15 but sticking to the monthly release is important. I hope this works for everybody, Well, let's hope the release after that will be 1.3.0 because I won't be able to merge Admin API in this one. Otherwise works for me thanks, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] zfs: fix storagepoolxml2xml test
Commit c4d27bd dropped output of owner/group -1. Update zfs tests accordingly. --- tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml | 2 -- tests/storagepoolxml2xmlout/pool-zfs.xml | 2 -- 2 files changed, 4 deletions(-) diff --git a/tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml b/tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml index bbd2e9f..89dcdbf 100644 --- a/tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml +++ b/tests/storagepoolxml2xmlout/pool-zfs-sourcedev.xml @@ -12,8 +12,6 @@ path/dev/zvol/testpool/path permissions mode0755/mode - owner-1/owner - group-1/group /permissions /target /pool diff --git a/tests/storagepoolxml2xmlout/pool-zfs.xml b/tests/storagepoolxml2xmlout/pool-zfs.xml index ff02329..c9e5df9 100644 --- a/tests/storagepoolxml2xmlout/pool-zfs.xml +++ b/tests/storagepoolxml2xmlout/pool-zfs.xml @@ -11,8 +11,6 @@ path/dev/zvol/testpool/path permissions mode0755/mode - owner-1/owner - group-1/group /permissions /target /pool -- 2.3.7 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] bhyve: fix build with gcc48
On Sat, May 23, 2015 at 08:05:23PM +0300, Roman Bogorodskiy wrote:
Build with gcc 4.8 fails with:
bhyve/bhyve_monitor.c: In function 'bhyveMonitorIO':
bhyve/bhyve_monitor.c:51:18: error: missing initializer for field 'tv_sec' of
'const struct timespec' [-Werror=missing-field-initializers]
const struct timespec zerowait = {};
Explicitly initialize zerowait to fix the build.
---
src/bhyve/bhyve_monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/bhyve/bhyve_monitor.c b/src/bhyve/bhyve_monitor.c
index 7f19c6e..1316720 100644
--- a/src/bhyve/bhyve_monitor.c
+++ b/src/bhyve/bhyve_monitor.c
@@ -48,7 +48,7 @@ struct _bhyveMonitor {
static void
bhyveMonitorIO(int watch, int kq, int events ATTRIBUTE_UNUSED, void *opaque)
{
-const struct timespec zerowait = {};
+const struct timespec zerowait = { 0, 0 };
You need to set at least minimum one field, all others will be set
to 0. But this is of course very right thing to do.
ACK, structures shouldn't be initialized this way.
bhyveMonitorPtr mon = opaque;
struct kevent kev;
int rc, status;
--
2.3.7
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] qemu: Add libvirt version check to refresh capabilities algorithm
On Sat, May 23, 2015 at 10:33:31AM -0400, John Ferlan wrote:
Rather than an algorithm based solely on libvirtd ctime to refresh the
capabilities add the element of the libvirt build version into the equation.
Since that version wouldn't be there prior to this code being run - don't
fail on reading the capabilities if not found. In this case, the cache
will always be read when a new libvirt version is installed.
You meant 'rebuilt' not 'read', right? Anyway, this makes complete
sense, ACK.
Signed-off-by: John Ferlan jfer...@redhat.com
---
src/qemu/qemu_capabilities.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index a6fae38..960afa4 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2605,6 +2605,7 @@ int virQEMUCapsProbeQMP(virQEMUCapsPtr qemuCaps,
* qemuCaps
* qemuctime234235253/qemuctime
* selfctime234235253/selfctime
+ * selfvers1002016/selfvers
* usedQMP/
* flag name='foo'/
* flag name='bar'/
@@ -2617,7 +2618,8 @@ int virQEMUCapsProbeQMP(virQEMUCapsPtr qemuCaps,
*/
static int
virQEMUCapsLoadCache(virQEMUCapsPtr qemuCaps, const char *filename,
- time_t *qemuctime, time_t *selfctime)
+ time_t *qemuctime, time_t *selfctime,
+ unsigned long *selfvers)
{
xmlDocPtr doc = NULL;
int ret = -1;
@@ -2627,6 +2629,7 @@ virQEMUCapsLoadCache(virQEMUCapsPtr qemuCaps, const char
*filename,
xmlXPathContextPtr ctxt = NULL;
char *str = NULL;
long long int l;
+unsigned long lu;
if (!(doc = virXMLParseFile(filename)))
goto cleanup;
@@ -2660,6 +2663,10 @@ virQEMUCapsLoadCache(virQEMUCapsPtr qemuCaps, const char
*filename,
}
*selfctime = (time_t)l;
+*selfvers = 0;
+if (virXPathULong(string(./selfvers), ctxt, lu) == 0)
+*selfvers = lu;
+
qemuCaps-usedQMP = virXPathBoolean(count(./usedQMP) 0,
ctxt) 0;
@@ -2798,6 +2805,8 @@ virQEMUCapsSaveCache(virQEMUCapsPtr qemuCaps, const char
*filename)
(long long)qemuCaps-ctime);
virBufferAsprintf(buf, selfctime%llu/selfctime\n,
(long long)virGetSelfLastChanged());
+virBufferAsprintf(buf, selfvers%lu/selfvers\n,
+ (unsigned long)LIBVIR_VERSION_NUMBER);
if (qemuCaps-usedQMP)
virBufferAddLit(buf, usedQMP/\n);
@@ -2938,6 +2947,7 @@ virQEMUCapsInitCached(virQEMUCapsPtr qemuCaps, const char
*cacheDir)
struct stat sb;
time_t qemuctime;
time_t selfctime;
+unsigned long selfvers;
if (virAsprintf(capsdir, %s/capabilities, cacheDir) 0)
goto cleanup;
@@ -2970,7 +2980,8 @@ virQEMUCapsInitCached(virQEMUCapsPtr qemuCaps, const char
*cacheDir)
goto cleanup;
}
-if (virQEMUCapsLoadCache(qemuCaps, capsfile, qemuctime, selfctime) 0) {
+if (virQEMUCapsLoadCache(qemuCaps, capsfile, qemuctime, selfctime,
+ selfvers) 0) {
virErrorPtr err = virGetLastError();
VIR_WARN(Failed to load cached caps from '%s' for '%s': %s,
capsfile, qemuCaps-binary, err ? NULLSTR(err-message) :
@@ -2983,12 +2994,14 @@ virQEMUCapsInitCached(virQEMUCapsPtr qemuCaps, const
char *cacheDir)
/* Discard cache if QEMU binary or libvirtd changed */
if (qemuctime != qemuCaps-ctime ||
-selfctime != virGetSelfLastChanged()) {
+selfctime != virGetSelfLastChanged() ||
+selfvers != LIBVIR_VERSION_NUMBER) {
VIR_DEBUG(Outdated cached capabilities '%s' for '%s'
- (%lld vs %lld, %lld vs %lld),
+ (%lld vs %lld, %lld vs %lld, %lu vs %lu),
capsfile, qemuCaps-binary,
(long long)qemuctime, (long long)qemuCaps-ctime,
- (long long)selfctime, (long long)virGetSelfLastChanged());
+ (long long)selfctime, (long long)virGetSelfLastChanged(),
+ selfvers, (unsigned long)LIBVIR_VERSION_NUMBER);
ignore_value(unlink(capsfile));
virQEMUCapsReset(qemuCaps);
ret = 0;
--
2.1.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Add missing XDR_FLAGS
On Thu, May 21, 2015 at 07:02:22PM +0300, Pavel Fedin wrote: Fixes build problems on x86_64-cygwin host for aarch64 target: CC lxc/libvirt_driver_lxc_impl_la-lxc_monitor_protocol.lo In file included from lxc/lxc_monitor_protocol.c:7:0: lxc/lxc_monitor_protocol.h:9:21: fatal error: rpc/rpc.h: No such file or directory CC rpc/libvirt_setuid_rpc_client_la-virnetmessage.lo In file included from rpc/virnetmessage.h:24:0, from rpc/virnetmessage.c:26: rpc/virnetprotocol.h:9:21: fatal error: rpc/rpc.h: No such file or directory CC lxc/libvirt_lxc-lxc_monitor_protocol.o In file included from lxc/lxc_monitor_protocol.c:7:0: lxc/lxc_monitor_protocol.h:9:21: fatal error: rpc/rpc.h: No such file or directory Signed-off-by: Pavel Fedin p.fe...@samsung.com --- src/Makefile.am | 3 +++ 1 file changed, 3 insertions(+) ACK Pushed (it's build-breaker anyway). diff --git a/src/Makefile.am b/src/Makefile.am index 579421d..0d1f58b 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -1290,6 +1290,7 @@ endif ! WITH_DRIVER_MODULES libvirt_driver_lxc_impl_la_CFLAGS = \ $(LIBNL_CFLAGS) \ $(FUSE_CFLAGS) \ + $(XDR_CFLAGS) \ -I$(srcdir)/access \ -I$(srcdir)/conf \ $(AM_CFLAGS) @@ -2216,6 +2217,7 @@ libvirt_setuid_rpc_client_la_CFLAGS = \ -I$(srcdir)/rpc \ $(AM_CFLAGS)\ $(SECDRIVER_CFLAGS) \ + $(XDR_CFLAGS) \ $(NULL) endif WITH_LXC @@ -2665,6 +2667,7 @@ libvirt_lxc_CFLAGS = \ $(LIBNL_CFLAGS) \ $(FUSE_CFLAGS) \ $(DBUS_CFLAGS) \ + $(XDR_CFLAGS) \ $(NULL) if WITH_BLKID libvirt_lxc_CFLAGS += $(BLKID_CFLAGS) -- 1.9.5.msysgit.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Plans for next release
On Sat, May 23, 2015 at 03:42:47PM -0400, Martin Kletzander wrote: On Sat, May 23, 2015 at 09:22:00PM +0800, Daniel Veillard wrote: Hi everybody, if we want to get it by next month, we should probably freeze on Tuesday for an 1.2.16 on June 1st, we 'only' have 137 commits since 1.2.15 but sticking to the monthly release is important. I hope this works for everybody, Well, let's hope the release after that will be 1.3.0 because I won't be able to merge Admin API in this one. okay so 1.2.16 around June 1st and 1.3.0 around July 1st Otherwise works for me oki, Daniel thanks, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Plans for next release
Hi everybody, if we want to get it by next month, we should probably freeze on Tuesday for an 1.2.16 on June 1st, we 'only' have 137 commits since 1.2.15 but sticking to the monthly release is important. I hope this works for everybody, thanks, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Plans for next release
if we want to get it by next month, we should probably freeze on Tuesday for an 1.2.16 on June 1st, we 'only' have 137 commits since 1.2.15 but sticking to the monthly release is important. I hope this works for everybody, thanks, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] storage: Fix problem with disk backend pool allocation calculation
https://bugzilla.redhat.com/show_bug.cgi?id=1224018 The disk pool recalculates the pool allocation, capacity, and available values each time through processing a newly created disk partition. However, there were two issues with doing so. The process generally is to read the partition table via virStorageBackendDiskReadPartitions and process the volume. This is called during create and refresh backend API's with the only difference being create passes a specific volume to be processed while refresh processes all volumes (passing NULL for the volume value). The first issue via virStorageBackendDiskCreateVol was that the pool's available value was cleared, so when virStorageBackendDiskMakeVol processes the (new) volume it will ignore any other partitions on the disk, thus after returning the pool allocation would only include the newly added volume. The second is while processing a partition, the adjustment of the available value depends on the type of partition. For primary and logical partitions, the available value was adjusted. However, for extended partitions, the available value wasn't adjusted. Since the calling function(s) storageVolCreateXML[From] will only adjust the pool available value when they determine that the backend code didn't this resulted in the available value being incorrectly adjusted by that code. If a pool refresh was executed, the correct value showed up. To fix the first issue, only clear the available value when we're being processed from the refresh path (vol will be NULL). To fix the second issue, increment available by 1 so that the calling function won't adjust after we're done. That could leave the appearance of a single byte being used by a pool that only has an extended partition, but that's better than having it show up as the size of the partition until someone refreshes. The refresh path will also nick by the same value so it'll be consistent. Signed-off-by: John Ferlan jfer...@redhat.com --- src/storage/storage_backend_disk.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c index 6394dac..bc14aab 100644 --- a/src/storage/storage_backend_disk.c +++ b/src/storage/storage_backend_disk.c @@ -164,8 +164,18 @@ virStorageBackendDiskMakeDataVol(virStoragePoolObjPtr pool, return -1; } +/* For data, adjust the pool's allocation by the size of the volume + * For metadata (aka extended volume), we haven't yet used the space; + * however, the calling createVol path will adjust the pool allocation + * by the volume allocation if it determines a storage backend doesn't + * adjust the pool's allocation value. So bump the allocation to avoid + * having the calling code misrepresent the value. The refresh path + * would resolve/change the value. + */ if (STRNEQ(groups[2], metadata)) pool-def-allocation += vol-target.allocation; +else +pool-def-allocation++; if (vol-source.extents[0].end pool-def-capacity) pool-def-capacity = vol-source.extents[0].end; @@ -309,7 +319,13 @@ virStorageBackendDiskReadPartitions(virStoragePoolObjPtr pool, pool-def-source.devices[0].path, NULL); -pool-def-allocation = pool-def-capacity = pool-def-available = 0; +/* The reload/restart/refresh path will recalculate everything; + * otherwise, keep allocation as is as capacity and available + * will be adjusted + */ +if (!vol) +pool-def-allocation = 0; +pool-def-capacity = pool-def-available = 0; ret = virCommandRunNul(cmd, 6, -- 2.1.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] qemu: Add libvirt version check to refresh capabilities algorithm
Rather than an algorithm based solely on libvirtd ctime to refresh the
capabilities add the element of the libvirt build version into the equation.
Since that version wouldn't be there prior to this code being run - don't
fail on reading the capabilities if not found. In this case, the cache
will always be read when a new libvirt version is installed.
Signed-off-by: John Ferlan jfer...@redhat.com
---
src/qemu/qemu_capabilities.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index a6fae38..960afa4 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2605,6 +2605,7 @@ int virQEMUCapsProbeQMP(virQEMUCapsPtr qemuCaps,
* qemuCaps
* qemuctime234235253/qemuctime
* selfctime234235253/selfctime
+ * selfvers1002016/selfvers
* usedQMP/
* flag name='foo'/
* flag name='bar'/
@@ -2617,7 +2618,8 @@ int virQEMUCapsProbeQMP(virQEMUCapsPtr qemuCaps,
*/
static int
virQEMUCapsLoadCache(virQEMUCapsPtr qemuCaps, const char *filename,
- time_t *qemuctime, time_t *selfctime)
+ time_t *qemuctime, time_t *selfctime,
+ unsigned long *selfvers)
{
xmlDocPtr doc = NULL;
int ret = -1;
@@ -2627,6 +2629,7 @@ virQEMUCapsLoadCache(virQEMUCapsPtr qemuCaps, const char
*filename,
xmlXPathContextPtr ctxt = NULL;
char *str = NULL;
long long int l;
+unsigned long lu;
if (!(doc = virXMLParseFile(filename)))
goto cleanup;
@@ -2660,6 +2663,10 @@ virQEMUCapsLoadCache(virQEMUCapsPtr qemuCaps, const char
*filename,
}
*selfctime = (time_t)l;
+*selfvers = 0;
+if (virXPathULong(string(./selfvers), ctxt, lu) == 0)
+*selfvers = lu;
+
qemuCaps-usedQMP = virXPathBoolean(count(./usedQMP) 0,
ctxt) 0;
@@ -2798,6 +2805,8 @@ virQEMUCapsSaveCache(virQEMUCapsPtr qemuCaps, const char
*filename)
(long long)qemuCaps-ctime);
virBufferAsprintf(buf, selfctime%llu/selfctime\n,
(long long)virGetSelfLastChanged());
+virBufferAsprintf(buf, selfvers%lu/selfvers\n,
+ (unsigned long)LIBVIR_VERSION_NUMBER);
if (qemuCaps-usedQMP)
virBufferAddLit(buf, usedQMP/\n);
@@ -2938,6 +2947,7 @@ virQEMUCapsInitCached(virQEMUCapsPtr qemuCaps, const char
*cacheDir)
struct stat sb;
time_t qemuctime;
time_t selfctime;
+unsigned long selfvers;
if (virAsprintf(capsdir, %s/capabilities, cacheDir) 0)
goto cleanup;
@@ -2970,7 +2980,8 @@ virQEMUCapsInitCached(virQEMUCapsPtr qemuCaps, const char
*cacheDir)
goto cleanup;
}
-if (virQEMUCapsLoadCache(qemuCaps, capsfile, qemuctime, selfctime) 0) {
+if (virQEMUCapsLoadCache(qemuCaps, capsfile, qemuctime, selfctime,
+ selfvers) 0) {
virErrorPtr err = virGetLastError();
VIR_WARN(Failed to load cached caps from '%s' for '%s': %s,
capsfile, qemuCaps-binary, err ? NULLSTR(err-message) :
@@ -2983,12 +2994,14 @@ virQEMUCapsInitCached(virQEMUCapsPtr qemuCaps, const
char *cacheDir)
/* Discard cache if QEMU binary or libvirtd changed */
if (qemuctime != qemuCaps-ctime ||
-selfctime != virGetSelfLastChanged()) {
+selfctime != virGetSelfLastChanged() ||
+selfvers != LIBVIR_VERSION_NUMBER) {
VIR_DEBUG(Outdated cached capabilities '%s' for '%s'
- (%lld vs %lld, %lld vs %lld),
+ (%lld vs %lld, %lld vs %lld, %lu vs %lu),
capsfile, qemuCaps-binary,
(long long)qemuctime, (long long)qemuCaps-ctime,
- (long long)selfctime, (long long)virGetSelfLastChanged());
+ (long long)selfctime, (long long)virGetSelfLastChanged(),
+ selfvers, (unsigned long)LIBVIR_VERSION_NUMBER);
ignore_value(unlink(capsfile));
virQEMUCapsReset(qemuCaps);
ret = 0;
--
2.1.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/2] Adjust refresh capabilities cache algorithm
Based on RFC posted and discussion therein: http://www.redhat.com/archives/libvir-list/2015-May/msg00655.html Threw away 1/2 from the RFC, but kept 2/2 since that seemed to be generally acceptible - even if it's still not clear the exact steps taken in order to create the problem. So 2/2 becomes 1/2 here. Added in a new 2/2 which adds LIBVIR_VERSION_NUMBER as a variable in the decision process for whether to refresh the cache. The theory behind this is if there's any oddities with time algorithms and time changes perhaps affecting 'ctime' - at least if the version is different in the cache file than determined for the running libvirtd, then we'll refresh that cache file. John Ferlan (2): qemu: Force capabilities cache refresh if libvirtd date is different qemu: Add libvirt version check to refresh capabilities algorithm src/qemu/qemu_capabilities.c | 25 +++-- 1 file changed, 19 insertions(+), 6 deletions(-) -- 2.1.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] qemu: Force capabilities cache refresh if libvirtd date is different
https://bugzilla.redhat.com/show_bug.cgi?id=1195882
Original commit id 'cbde3589' indicates that the cache file would be
discarded if either the QEMU binary or libvirtd 'ctime' changes; however,
the code only discarded if the QEMU binary time didn't match or if the
new libvirtd ctime was later than what created the cache file.
Since many factors come into play with 'ctime' adjustments (including
perhaps turning back the hands of time), change the logic to also force
a refresh if the ctime of libvirt is different than what's in the cache.
Signed-off-by: John Ferlan jfer...@redhat.com
---
src/qemu/qemu_capabilities.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 375df22..a6fae38 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2981,9 +2981,9 @@ virQEMUCapsInitCached(virQEMUCapsPtr qemuCaps, const char
*cacheDir)
goto cleanup;
}
-/* Discard if cache is older that QEMU binary */
+/* Discard cache if QEMU binary or libvirtd changed */
if (qemuctime != qemuCaps-ctime ||
-selfctime virGetSelfLastChanged()) {
+selfctime != virGetSelfLastChanged()) {
VIR_DEBUG(Outdated cached capabilities '%s' for '%s'
(%lld vs %lld, %lld vs %lld),
capsfile, qemuCaps-binary,
--
2.1.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] bhyve: fix build with gcc48
Build with gcc 4.8 fails with:
bhyve/bhyve_monitor.c: In function 'bhyveMonitorIO':
bhyve/bhyve_monitor.c:51:18: error: missing initializer for field 'tv_sec' of
'const struct timespec' [-Werror=missing-field-initializers]
const struct timespec zerowait = {};
Explicitly initialize zerowait to fix the build.
---
src/bhyve/bhyve_monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/bhyve/bhyve_monitor.c b/src/bhyve/bhyve_monitor.c
index 7f19c6e..1316720 100644
--- a/src/bhyve/bhyve_monitor.c
+++ b/src/bhyve/bhyve_monitor.c
@@ -48,7 +48,7 @@ struct _bhyveMonitor {
static void
bhyveMonitorIO(int watch, int kq, int events ATTRIBUTE_UNUSED, void *opaque)
{
-const struct timespec zerowait = {};
+const struct timespec zerowait = { 0, 0 };
bhyveMonitorPtr mon = opaque;
struct kevent kev;
int rc, status;
--
2.3.7
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Strange test build failure
Daniel P. Berrange wrote: On Fri, May 22, 2015 at 05:59:49PM +0200, Michal Privoznik wrote: On 22.05.2015 16:39, Dimitri John Ledkov wrote: On 22 May 2015 at 13:53, Michal Privoznik mpriv...@redhat.com wrote: On 22.05.2015 14:18, Daniel P. Berrange wrote: On Fri, May 22, 2015 at 01:13:40PM +0100, Dimitri John Ledkov wrote: # VIR_TEST_VERBOSE=1 VIR_TEST_DEBUG=1 ./qemuxml2argvtest 21 | grep NUMA 61) QEMU XML-2-ARGV hugepages-pages ... libvirt: error : unsupported configuration: NUMA node 1 is unavailable 64) QEMU XML-2-ARGV hugepages-shared ... libvirt: error : unsupported configuration: NUMA node 1 is unavailable 331) QEMU XML-2-ARGV numatune-memnode ... libvirt: error : unsupported configuration: NUMA node 1 is unavailable 333) QEMU XML-2-ARGV numatune-memnode-no-memory ... libvirt: error : unsupported configuration: NUMA node 3 is unavailable 336) QEMU XML-2-ARGV numatune-auto-prefer ... libvirt: error : unsupported configuration: NUMA node 1 is unavailable 449) QEMU XML-2-ARGV memory-hotplug-dimm ... libvirt: error : unsupported configuration: NUMA node 1 is unavailable 450) QEMU XML-2-ARGV memory-hotplug-dimm-addr ... libvirt: error : unsupported configuration: NUMA node 1 is unavailable So the test fails, but I don't believe I'm compiling libvirt with numad support... So I don't understand what is being asserted here. Can you tell us more about what platform you are building on, and particularly what compiler linker you are using And what arguments do you pass to configure. snip So even though you are building with numactl, it seems to me like you don't have numa_bitmask_isbitset(). Can you check config.log to see if HAVE_NUMA_BITMASK_ISBITSET is defined to 1? If my guess is right, this causes us to not mock virNumaNodeIsAvailable() and therefore we run the original function which checks real host the build is ran on. Or is this not the same as the issue with inline that was seen with clang before ? Yeah, it looks quite similar to that one. By the way, clang doesn't do much inlining with -O0, I guess that could be similar in gcc, so it should be a quick check to see if that's a compiler problem. Roman Bogorodskiy pgpUasjwoS_Ku.pgp Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/3] network: Resolve Coverity FORWARD_NULL
On 05/13/2015 12:32 PM, John Ferlan wrote:
To silence Coverity just add a 'p ' in front of the check in
networkFindUnusedBridgeName after the strchr() call. Even though
we know it's not possible to have strchr return NULL since the only
way into the function is if there is a '%' in def-bridge or it's NULL.
Agreed (I hand traced all the possible combinations to be sure), and ACK.
Signed-off-by: John Ferlan jfer...@redhat.com
---
src/network/bridge_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index 4b53475..f438c0b 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -2780,7 +2780,7 @@ networkFindUnusedBridgeName(virNetworkObjListPtr nets,
if (def-bridge
(p = strchr(def-bridge, '%')) == strrchr(def-bridge, '%')
-p[1] == 'd')
+p p[1] == 'd')
templ = def-bridge;
do {
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/3] conf: Resolve Coverity FORWARD_NULL
On 05/13/2015 12:32 PM, John Ferlan wrote:
Even though it's been pointed out they are false positives:
http://www.redhat.com/archives/libvir-list/2015-May/msg00301.html
and
http://www.redhat.com/archives/libvir-list/2015-May/msg00302.html
these still show up as Coverity issues. In order to silence Coverity
add an 'sa_assert' prior to check failure.
Signed-off-by: John Ferlan jfer...@redhat.com
---
src/conf/domain_conf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index add857c..5b69b5a 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -23078,6 +23078,7 @@ virDomainObjListCollect(virDomainObjListPtr domlist,
{
struct virDomainListData data = { NULL, 0 };
+sa_assert(domlist-objs);
virObjectLock(domlist);
Theoretically domlist-objs could be set to NULL by some other thread
after the sa_asser and before the virObjectLock, but since these are
false positives, the purpose is to shut up coverity, not to actually
check for a non-NULL pointer.
So ACK.
if (VIR_ALLOC_N(data.vms, virHashSize(domlist-objs)) 0) {
virObjectUnlock(domlist);
@@ -23141,6 +23142,7 @@ virDomainObjListConvert(virDomainObjListPtr domlist,
}
virObjectUnlock(domlist);
+sa_assert(*vms);
virDomainObjListFilter(vms, nvms, conn, filter, flags);
return 0;
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] libxl: load on FreeBSD
The libxl tries to check if it's running in dom0 by parsing
/proc/xen/capabilities and if that fails it doesn't load.
There's no procfs interface in Xen on FreeBSD, so this check always
fails.
Instead of using procfs, check if /dev/xen/xenstored, that's enough to
check if we're running in dom0 in FreeBSD case.
--
The 'HYPERVISOR_CAPABILITIES' name could be misleading now, however, I'd
prefer to use a common variable to avoid duplicating of the file checking
code. Maybe it should be renamed to something like HYPERVISOR_CONTROL?
---
src/libxl/libxl_driver.c | 41 +
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 12be816..c848210 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -73,7 +73,11 @@ VIR_LOG_INIT(libxl.libxl_driver);
#define LIBXL_CONFIG_FORMAT_XM xen-xm
#define LIBXL_CONFIG_FORMAT_SEXPR xen-sxpr
-#define HYPERVISOR_CAPABILITIES /proc/xen/capabilities
+#ifdef __FreeBSD__
+# define HYPERVISOR_CAPABILITIES /dev/xen/xenstored
+#else
+# define HYPERVISOR_CAPABILITIES /proc/xen/capabilities
+#endif
/* Number of Xen scheduler parameters */
#define XEN_SCHED_CREDIT_NPARAM 2
@@ -427,8 +431,6 @@ static bool
libxlDriverShouldLoad(bool privileged)
{
bool ret = false;
-int status;
-char *output = NULL;
/* Don't load if non-root */
if (!privileged) {
@@ -441,21 +443,28 @@ libxlDriverShouldLoad(bool privileged)
does not exist);
return ret;
}
-/*
- * Don't load if not running on a Xen control domain (dom0). It is not
- * sufficient to check for the file to exist as any guest can mount
- * xenfs to /proc/xen.
- */
-status = virFileReadAll(HYPERVISOR_CAPABILITIES, 10, output);
-if (status = 0)
-status = strncmp(output, control_d, 9);
-VIR_FREE(output);
-if (status) {
-VIR_INFO(No Xen capabilities detected, probably not running
- in a Xen Dom0. Disabling libxenlight driver);
+#if !defined(__FreeBSD__)
+{
+int status;
+char *output = NULL;
-return ret;
+/*
+ * Don't load if not running on a Xen control domain (dom0). It is not
+ * sufficient to check for the file to exist as any guest can mount
+ * xenfs to /proc/xen.
+ */
+status = virFileReadAll(HYPERVISOR_CAPABILITIES, 10, output);
+if (status = 0)
+status = strncmp(output, control_d, 9);
+VIR_FREE(output);
+if (status) {
+VIR_INFO(No Xen capabilities detected, probably not running
+ in a Xen Dom0. Disabling libxenlight driver);
+
+return ret;
+}
}
+#endif
/* Don't load if legacy xen toolstack (xend) is in use */
if (virFileExists(/usr/sbin/xend)) {
--
2.3.7
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] storage: Resolve Coverity FORWARD_NULL
On 05/14/2015 08:35 AM, John Ferlan wrote:
On 05/13/2015 02:43 PM, Jiri Denemark wrote:
On Wed, May 13, 2015 at 12:32:20 -0400, John Ferlan wrote:
Coverity points out it's possible for one of the virCommand{Output|Error}*
API's to have not allocated 'output' and/or 'error' in which case the
strstr comparison will cause a NULL deref
Signed-off-by: John Ferlan jfer...@redhat.com
---
src/storage/storage_backend_disk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/storage/storage_backend_disk.c
b/src/storage/storage_backend_disk.c
index 6394dac..5c2c49a 100644
--- a/src/storage/storage_backend_disk.c
+++ b/src/storage/storage_backend_disk.c
@@ -412,7 +412,7 @@ virStorageBackendDiskFindLabel(const char* device)
/* if parted succeeds we have a valid partition table */
ret = virCommandRun(cmd, NULL);
-if (ret 0) {
+if (ret 0 output error) {
if (strstr(output, unrecognised disk label) ||
strstr(error, unrecognised disk label)) {
ret = 1;
This doesn't seem to be correct if either output or error is NULL and
the other one is non-NULL. I'm too lazy to check if it's possible or
not, but I think we should change this code in the following way and be
safe:
if (ret 0) {
if ((output strstr(output, unrecognised disk label)) ||
(error strstr(error, unrecognised disk label))) {
ret = 1;
Jirka
Sure - seems reasonable, although I suspect if allocation of memory for
the output buffer fails, then allocation of memory for the error buffer
will fail too, but just in case it succeeds...
In case there's any question - ACK to Jirka's version of the patch.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFC PATCH] threshold: new API virDomainBlockSetWriteThreshold
qemu 2.3 added a new QMP command block-set-write-threshold,
which allows callers to get an interrupt when a file hits a
write threshold, rather than the current approach of repeatedly
polling for file allocation. This patch prepares the API for
callers to register to receive the event, as well as a way
to query the threshold.
The event is one-shot in qemu - a guest must re-register a new
threshold after each time it triggers. However, the
virConnectDomainEventRegisterAny() call does not allow
parameterization, so callers must use a pair of APIs - one
to register the callback (one-time call), and another to
repeatedly set the desired threshold (repeated each time a
threshold changes).
Note that the threshold is registered as a double, but reported
as an unsigned long long. This is intentional, as it allows
the use of a flag for registering a threshold via a percentage,
but once registered, the threshold is normalized according to
the current size of the disk.
To make the patch series more digestible, this patch
intentionally omits remote support, by using a couple of
placeholders at a point where the compiler forces the addition
of a case within a switch statement.
Signed-off-by: Eric Blake ebl...@redhat.com
---
Posting now to get feedback on the proposed API, before the actual
implementation is complete.
daemon/remote.c | 2 +
include/libvirt/libvirt-domain.h | 48 +++
src/conf/domain_event.c | 4 +-
src/driver-hypervisor.h | 7 +++
src/libvirt-domain.c | 101 +++
src/libvirt_public.syms | 1 +
tools/virsh-domain.c | 23 +
tools/virsh.pod | 1 +
8 files changed, 186 insertions(+), 1 deletion(-)
diff --git a/daemon/remote.c b/daemon/remote.c
index e259a76..51d7de5 100644
--- a/daemon/remote.c
+++ b/daemon/remote.c
@@ -1102,6 +1102,8 @@ static virConnectDomainEventGenericCallback
domainEventCallbacks[] = {
VIR_DOMAIN_EVENT_CALLBACK(remoteRelayDomainEventTunable),
VIR_DOMAIN_EVENT_CALLBACK(remoteRelayDomainEventAgentLifecycle),
VIR_DOMAIN_EVENT_CALLBACK(remoteRelayDomainEventDeviceAdded),
+/* TODO: Implement RPC support for this */
+VIR_DOMAIN_EVENT_CALLBACK(NULL),
};
verify(ARRAY_CARDINALITY(domainEventCallbacks) == VIR_DOMAIN_EVENT_ID_LAST);
diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
index d851225..0c4fd62 100644
--- a/include/libvirt/libvirt-domain.h
+++ b/include/libvirt/libvirt-domain.h
@@ -515,6 +515,15 @@ typedef virDomainBlockStatsStruct *virDomainBlockStatsPtr;
# define VIR_DOMAIN_BLOCK_STATS_ERRS errs
/**
+ * VIR_DOMAIN_BLOCK_STATS_WRITE_THRESHOLD:
+ *
+ * Macro represents the typed parameter, as an llong, that reports
+ * the threshold in bytes at which the block device will trigger a
+ * VIR_DOMAIN_EVENT_ID_WRITE_THRESHOLD, or 0 if no threshold is registered.
+ */
+# define VIR_DOMAIN_BLOCK_STATS_WRITE_THRESHOLD write-threshold
+
+/**
* virDomainInterfaceStats:
*
* Network interface stats for virDomainInterfaceStats.
@@ -1297,6 +1306,16 @@ int virDomainBlockStatsFlags
(virDomainPtr dom,
virTypedParameterPtr params,
int *nparams,
unsigned int flags);
+
+typedef enum {
+/* threshold is a percentage rather than byte limit */
+VIR_DOMAIN_BLOCK_SET_WRITE_THRESHOLD_PERCENTAGE = (1 0),
+} virDomainBlockSetWriteThresholdFlags;
+int virDomainBlockSetWriteThreshold(virDomainPtr dom,
+const char *disk,
+double threshold,
+unsigned int flags);
+
int virDomainInterfaceStats (virDomainPtr dom,
const char *path,
virDomainInterfaceStatsPtr
stats,
@@ -3246,6 +3265,34 @@ typedef void
(*virConnectDomainEventDeviceAddedCallback)(virConnectPtr conn,
void *opaque);
/**
+ * virConnectDomainEventWriteThresholdCallback:
+ * @conn: connection object
+ * @dom: domain on which the event occurred
+ * @devAlias: device alias
+ * @threshold: threshold that was exceeded, in bytes
+ * @length: length beyond @threshold that was involved in the triggering write
+ * @opaque: application specified data
+ *
+ * The callback signature to use when registering for an event of type
+ * VIR_DOMAIN_EVENT_ID_WRITE_THRESHOLD with virConnectDomainEventRegisterAny()
+ *
+ * This callback occurs when a block device detects a write event that
+ * exceeds a non-zero threshold set by
+ * virDomainBlockSetWriteThreshold(). When this event occurs, the
+ * threshold is reset to 0, and a new limit must be installed to see
+ * the event again on the
