[libvirt] [PATCH 0/3] Three simple bugfixes
by Laine Stump
Patch 1 was posted several days ago, but may have gotten lost in the
stream, so I'm reposting it. (The patches are unrelated other than
that they are nominally related to networking, they were all in my
queue at the same time, and they're all three very short. I'm just
posting them together to make it easier to keep track of them.)
Laine Stump (3):
netdev: fail when setting up an SRIOV VF if PF is offline
interface: allow multiple IPv4 addresses + dhcp on a single interface
util: better error message after failure to initialize firewall
backend
docs/schemas/interface.rng | 28 ++++++++++------------
src/util/virfirewall.c | 10 +++++++-
src/util/virnetdev.c | 22 +++++++++++++++++
.../ethernet-dhcp-and-multi-static.xml | 9 +++++++
tests/interfacexml2xmltest.c | 1 +
5 files changed, 54 insertions(+), 16 deletions(-)
create mode 100644 tests/interfaceschemadata/ethernet-dhcp-and-multi-static.xml
--
2.1.0
9 years, 6 months
[libvirt] [PATCH] conf: fix issue on virCPUDefCopy
by Thibaut Collet
This patch is only for maintenance branches v1.2.9-maint, v1.2.10-maint,
v1.2.11-maint and v1.2.12-maint
Thibaut Collet (1):
conf: fix issue on virCPUDefCopy
src/conf/cpu_conf.c | 1 +
1 file changed, 1 insertion(+)
--
1.7.10.4
9 years, 6 months
[libvirt] [RFC PATCH 0/2] Clear capabilities cache options
by John Ferlan
Posting this as an RFC since I'm trying to get upstream feedback on whether
either approach is better or whether perhaps both approaches should be used.
The problem occurred primarily for downstream installations where it seems
the order of the build libvirtd caused issues regarding whether certain
capabilities bits were present. Although the history of the case doesn't
"prove" my theory exactly other issues around the same time that were part
of a private bz or email stream (I forget now) seem to indicate that the
order of libvirtd builds and installations would be very important as they
relate to when the cache is rebuilt.
In the instances seen there was lots of testing going on related to whether
patches were found in a 'maintenance release' and the 'mainline release'.
Since the process is build the mainline first and then backport the patch(es)
to the maintenance release, it's possible the date of the maintenance
libvirtd would be later than that of the mainline release. If testing
installs the maintenance release first and the cache gets updated based
on the 'ctime' of libvirtd being later than what was currently installed
and then the mainline release is installed with a libvirtd 'ctime' that
would possibly be prior to that of the maintentance release, then the
cache wouldn't be updated. The fix for testing has been just to delete
the cache.
In looking at the code and history, I see a couple possible solutions.
The first seems to be a "big hammer" - on every libvirtd installation we
delete the entire cache - this would force the reread. I believe I got
that right using %post of the install to clear out anything in the
capabilities directory (whether just created or already existing from some
prior installation). Another solution was to adjust the libvirtd 'ctime'
check to be if different than what is found in the cache. When looking at
the original commit, this seems to be what the intention was in the commit
message, but the actual code was slightly different. Upstream review
comments for changes didn't mention the difference either, see:
http://www.redhat.com/archives/libvir-list/2014-March/msg00629.html
and
https://www.redhat.com/archives/libvir-list/2014-March/msg00301.html
John Ferlan (2):
spec: Remove capabilities cache during %post install
qemu: Force capabilities cache read if libvirtd date is different
libvirt.spec.in | 11 +++++++++++
src/qemu/qemu_capabilities.c | 6 ++++--
2 files changed, 15 insertions(+), 2 deletions(-)
--
2.1.0
9 years, 6 months
[libvirt] RFC: exposing qemu's block-set-write-threshold
by Eric Blake
I'm trying to wire up libvirt to do event reporting based on qemu 2.3's
BLOCK_WRITE_THRESHOLD event. Doing this will allow management
applications to do event-based notification on when to enlarge LVM (or
other) storage underlying a qcow2 volume, rather than their current
requirement to frequently poll block statistics. But I'm stuck on the
best way to expose the new parameter:
One idea is to treat it as part of the domain XML, and have
virDomainSetBlockIoTune add one more typed parameter for a disk's
current write threshold. Doing this could allow setting a threshold
even for an offline domain (although the threshold is only meaningful
for a running domain), but might get weird because qemu's event is
one-shot (you have to re-arm a new threshold every time an existing
threshold fires - so every time it fires, the domain XML is rewritten,
even though it is not guest-visible ABI that was changing). At least
with this approach, it is also easy for a client to poll the current
setting of the threshold, via virDomainGetBlockIoTune. But the
threshold isn't quite a tuning parameter (it isn't throttling how fast
the guest can write to the block device, only how full the host side can
get in order to allow transparent resizing of the host storage prior to
running out of space).
Another idea is to add a completely new API, maybe named
virDomainBlockSetWriteThreshold(virDomainPtr dom, const char *disk, long
long int threshold, unsigned int flags) (with threshold in bytes).
Here, virDomainBlockStatsFlags() could be a way to query the current
threshold. And if desired, we could add a flag value to treat threshold
as a percentage instead of a byte value (but is 1% too large of
granularity, and how would you scale the percentage to anything finer
while still keeping the parameter as long long int rather than double?)
Of course, I'd want virConnectGetAllDomainStats() to list the current
threshold setting (0 if no threshold or if the event has already fired,
non-zero if the threshold is still set waiting to fire), so that clients
can query thresholds for multiple domains and multiple disks per domain
in one API call. But I don't know if we have any good way to set
multiple thresholds in one call (at least virDomainSetBlockIoTune must
be called once per disk; it might be possible for my proposed
virDomainBlockStatsFlags() to set a threshold for multiple disks if the
disk name is passed as NULL - but then we're back to the question of
what happens if the guest has multiple disks of different sizes; it's
better to set per-disk thresholds than to assume all disks must be at
the same byte or percentage threshold).
I'm also worried about what happens across libvirtd restarts - if the
qemu event fires while libvirtd is unconnected, should libvirt be
tracking that a threshold was registered in the XML, and upon
reconnection check if qemu still has the threshold? If qemu no longer
has a threshold, then libvirt can assume it missed the event, and
generate one as part of reconnecting to the domain.
Thoughts? If I don't hear anything, I'll base my first implementation
on adding a new API, rather than reusing virDomainSetBlockIoTune.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
9 years, 6 months
[libvirt] [PATCH] conf: fix forget restore ctxt->node when parse memory device success
by Luyao Huang
https://bugzilla.redhat.com/show_bug.cgi?id=1223631
When set a memory device in the xml, <sysinfo> in xml will be lost.
Because we forgot restore ctxt->node to the oldnode after parse memory
device, this will make the parse function after virDomainMemoryDefParseXML
cannot find a node they need when parse a full xml(virDomainDefParseXML).
Signed-off-by: Luyao Huang <lhuang(a)redhat.com>
---
src/conf/domain_conf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index bfdc94e..7ddc1ea 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -11828,6 +11828,7 @@ virDomainMemoryDefParseXML(xmlNodePtr memdevNode,
if (virDomainDeviceInfoParseXML(memdevNode, NULL, &def->info, flags) < 0)
goto error;
+ ctxt->node = save;
return def;
error:
--
1.8.3.1
9 years, 6 months
[libvirt] [PATCH] virsh: fix a typos issue cause error not right
by Luyao Huang
Signed-off-by: Luyao Huang <lhuang(a)redhat.com>
---
tools/virsh-host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/virsh-host.c b/tools/virsh-host.c
index a72fd05..e939dac 100644
--- a/tools/virsh-host.c
+++ b/tools/virsh-host.c
@@ -500,7 +500,7 @@ cmdAllocpages(vshControl *ctl, const vshCmd *cmd)
if (vshCommandOptScaledInt(cmd, "pagesize", &tmp, 1024, UINT_MAX) < 0) {
vshError(ctl,
_("Numeric value for <%s> option is malformed or out of range"),
- "cellno");
+ "pagesize");
return false;
}
pageSizes[0] = VIR_DIV_UP(tmp, 1024);
--
1.8.3.1
9 years, 6 months
[libvirt] [PATCH v2 0/5] storage: fs: tweak dir perms handling on build
by Cole Robinson
Consider the following issue
- Using virt-manager with qemu:///session
- User adds a storage pool pointing at /tmp. No explicit permissions are
requested in the XML
- virt-manager calls PoolDefine, then PoolBuild
- libvirt tries to unconditionally chmod 755 /tmp. This fails because my
user doesn't own root. Pool build fails, virt-manager reports failure
Yes there's a couple ways we could avoid this specific case in
virt-manager, but I think it makes more sense to have pool.build on
a directory be a no-op in this case. The following patches address this.
I already pushed some bits of v1 of the series. Now the patches are:
- Patch 1 (new) fixes a bug in the previous patches I pushed
- Patch 2 (new) changes storage XML to not output -1 for owner/group
- Patch 3 changes storage XML to not hardcode a <mode> value if the user
didn't specify one in.
- Patch 4 (new) drops a redundant flag to virDirCreate
- Patch 5 makes pool.build skip dir chmod unless the user explicitly
requested <mode> via the XML. However if a mode is required for mkdir,
continue to use the previous default.
v2:
Add patches 1, 3, 4, adjust other patches to match
Style fix in patch 5
Cole Robinson (5):
virfile: virDirCreate: Fix ALLOW_EXIST conditional
storage: conf: Don't output owner/group -1
storage: conf: Don't set any default <mode> in the XML
virfile: virDirCreate: Drop redundand FORCE_PERMS flag
storage: fs: Only force directory permissions if required
docs/schemas/storagecommon.rng | 36 ++++++++------
src/conf/storage_conf.c | 57 +++++++++++-----------
src/storage/storage_backend.c | 20 ++++++--
src/storage/storage_backend.h | 3 ++
src/storage/storage_backend_fs.c | 21 +++++---
src/storage/storage_backend_logical.c | 4 +-
src/util/virfile.c | 8 ++-
src/util/virfile.h | 3 +-
tests/storagepoolxml2xmlout/pool-dir-naming.xml | 2 -
tests/storagepoolxml2xmlout/pool-dir.xml | 2 -
tests/storagepoolxml2xmlout/pool-netfs-gluster.xml | 3 --
tests/storagevolxml2xmlin/vol-file.xml | 4 +-
.../vol-gluster-dir-neg-uid.xml | 2 -
tests/storagevolxml2xmlout/vol-gluster-dir.xml | 3 --
tests/storagevolxml2xmlout/vol-sheepdog.xml | 3 --
15 files changed, 91 insertions(+), 80 deletions(-)
--
2.4.0
9 years, 6 months
[libvirt] [PATCH] build fix: fix libvirt build if WITH_HAL is defined
by Maxim Nestratov
---
src/node_device/node_device_hal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/node_device/node_device_hal.c b/src/node_device/node_device_hal.c
index 2d3bc17..6d18a87 100644
--- a/src/node_device/node_device_hal.c
+++ b/src/node_device/node_device_hal.c
@@ -372,7 +372,7 @@ gather_capability(LibHalContext *ctx, const char *udi,
virNodeDevCapsDefPtr caps;
if (VIR_ALLOC(caps) < 0)
return ENOMEM;
- caps->type = entry->type;
+ caps->data.type = entry->type;
if (entry->gather_fn) {
int rv = (*entry->gather_fn)(ctx, udi, &caps->data);
if (rv != 0) {
--
2.1.0
9 years, 6 months
[libvirt] [PATCH v2] sysinfo: Fix reports on ARM
by Michal Privoznik
Due to a kernel commit (b4b8f770e), cpuinfo format has changed on
ARMs. Firstly, 'Processor: ...' may not be reported, it's
replaced by 'model name: ...'. Secondly, the "Processor" string
may occur in CPU name, e.g. 'ARMv7 Processor rev 5 (v7l)'.
Therefore, we must firstly look for 'model name' and then for
'Processor' if not found.
Moreover, lines in the cpuinfo file are shuffled, so we better
not manipulate the pointer to start of internal buffer as we may
lost some info.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
diff to v1:
- Jan's comments worked in
- added new test case (yes, there really is a space at EOL in cpuinfo on my ARM)
src/util/virsysinfo.c | 9 +++----
tests/sysinfodata/arm-rpi2cpuinfo.data | 43 ++++++++++++++++++++++++++++++++
tests/sysinfodata/arm-rpi2sysinfo.expect | 18 +++++++++++++
tests/sysinfotest.c | 22 ++++++++++++----
4 files changed, 82 insertions(+), 10 deletions(-)
create mode 100644 tests/sysinfodata/arm-rpi2cpuinfo.data
create mode 100644 tests/sysinfodata/arm-rpi2sysinfo.expect
diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c
index 8bb17f0..40390ab 100644
--- a/src/util/virsysinfo.c
+++ b/src/util/virsysinfo.c
@@ -289,16 +289,15 @@ virSysinfoParseProcessor(const char *base, virSysinfoDefPtr ret)
virSysinfoProcessorDefPtr processor;
char *processor_type = NULL;
- if (!(tmp_base = strstr(base, "Processor")))
+ if (!(tmp_base = strstr(base, "model name")) &&
+ !(tmp_base = strstr(base, "Processor")))
return 0;
- base = tmp_base;
- eol = strchr(base, '\n');
- cur = strchr(base, ':') + 1;
+ eol = strchr(tmp_base, '\n');
+ cur = strchr(tmp_base, ':') + 1;
virSkipSpaces(&cur);
if (eol && VIR_STRNDUP(processor_type, cur, eol - cur) < 0)
goto error;
- base = cur;
while ((tmp_base = strstr(base, "processor")) != NULL) {
base = tmp_base;
diff --git a/tests/sysinfodata/arm-rpi2cpuinfo.data b/tests/sysinfodata/arm-rpi2cpuinfo.data
new file mode 100644
index 0000000..41fde00
--- /dev/null
+++ b/tests/sysinfodata/arm-rpi2cpuinfo.data
@@ -0,0 +1,43 @@
+processor : 0
+model name : ARMv7 Processor rev 5 (v7l)
+BogoMIPS : 38.40
+Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+CPU implementer : 0x41
+CPU architecture: 7
+CPU variant : 0x0
+CPU part : 0xc07
+CPU revision : 5
+
+processor : 1
+model name : ARMv7 Processor rev 5 (v7l)
+BogoMIPS : 38.40
+Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+CPU implementer : 0x41
+CPU architecture: 7
+CPU variant : 0x0
+CPU part : 0xc07
+CPU revision : 5
+
+processor : 2
+model name : ARMv7 Processor rev 5 (v7l)
+BogoMIPS : 38.40
+Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+CPU implementer : 0x41
+CPU architecture: 7
+CPU variant : 0x0
+CPU part : 0xc07
+CPU revision : 5
+
+processor : 3
+model name : ARMv7 Processor rev 5 (v7l)
+BogoMIPS : 38.40
+Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
+CPU implementer : 0x41
+CPU architecture: 7
+CPU variant : 0x0
+CPU part : 0xc07
+CPU revision : 5
+
+Hardware : BCM2709
+Revision : a01041
+Serial : 00000000c9e9323d
diff --git a/tests/sysinfodata/arm-rpi2sysinfo.expect b/tests/sysinfodata/arm-rpi2sysinfo.expect
new file mode 100644
index 0000000..acb3ad9
--- /dev/null
+++ b/tests/sysinfodata/arm-rpi2sysinfo.expect
@@ -0,0 +1,18 @@
+<sysinfo type='smbios'>
+ <processor>
+ <entry name='socket_destination'>0</entry>
+ <entry name='type'>ARMv7 Processor rev 5 (v7l)</entry>
+ </processor>
+ <processor>
+ <entry name='socket_destination'>1</entry>
+ <entry name='type'>ARMv7 Processor rev 5 (v7l)</entry>
+ </processor>
+ <processor>
+ <entry name='socket_destination'>2</entry>
+ <entry name='type'>ARMv7 Processor rev 5 (v7l)</entry>
+ </processor>
+ <processor>
+ <entry name='socket_destination'>3</entry>
+ <entry name='type'>ARMv7 Processor rev 5 (v7l)</entry>
+ </processor>
+</sysinfo>
diff --git a/tests/sysinfotest.c b/tests/sysinfotest.c
index d8266a7..74e5f71 100644
--- a/tests/sysinfotest.c
+++ b/tests/sysinfotest.c
@@ -166,11 +166,23 @@ VIRT_TEST_MAIN(test_x86)
static int
test_arm(void)
{
- return sysinfotest_run("arm sysinfo",
- NULL,
- NULL,
- "/sysinfodata/armcpuinfo.data",
- "/sysinfodata/armsysinfo.expect");
+ int ret = EXIT_SUCCESS;
+
+ if (sysinfotest_run("arm sysinfo",
+ NULL,
+ NULL,
+ "/sysinfodata/armcpuinfo.data",
+ "/sysinfodata/armsysinfo.expect") != EXIT_SUCCESS)
+ ret = EXIT_FAILURE;
+
+ if (sysinfotest_run("Raspberry Pi 2 sysinfo",
+ NULL,
+ NULL,
+ "/sysinfodata/arm-rpi2cpuinfo.data",
+ "/sysinfodata/arm-rpi2sysinfo.expect") != EXIT_SUCCESS)
+ ret = EXIT_FAILURE;
+
+ return ret;
}
VIRT_TEST_MAIN(test_arm)
--
2.3.6
9 years, 6 months
[libvirt] [PATCH] util: Avoid shadow of 'ulong' in virMemoryMaxValue
by Peter Krempa
Old compilers whine:
src/util/virutil.c: In function 'virMemoryMaxValue':
src/util/virutil.c:2612: error: declaration of 'ulong' shadows a global declaration [-Wshadow]
/usr/include/sys/types.h:151: error: shadowed declaration is here [-Wshadow]
s/ulong/capped/ to work around the problem
---1
Pushed under the trivial && build-breaker rules.
src/util/virutil.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/util/virutil.c b/src/util/virutil.c
index 638d6e2..e479cce 100644
--- a/src/util/virutil.c
+++ b/src/util/virutil.c
@@ -2603,17 +2603,17 @@ virMemoryLimitIsSet(unsigned long long value)
/**
* virMemoryMaxValue
*
- * @ulong: whether the value must fit into unsigned long
+ * @capped: whether the value must fit into unsigned long
* (long long is assumed otherwise)
*
* Returns the maximum possible memory value in bytes.
*/
unsigned long long
-virMemoryMaxValue(bool ulong)
+virMemoryMaxValue(bool capped)
{
/* On 32-bit machines, our bound is 0xffffffff * KiB. On 64-bit
* machines, our bound is off_t (2^63). */
- if (ulong && sizeof(unsigned long) < sizeof(long long))
+ if (capped && sizeof(unsigned long) < sizeof(long long))
return 1024ull * ULONG_MAX;
else
return LLONG_MAX;
--
2.3.5
9 years, 6 months
