[libvirt] [PATCH] libxl: fix dom0 autoballooning with Xen 4.8
by Jim Fehlig
xen.git commit 57f8b13c changed several of the libxl memory
get/set functions to take 64 bit parameters. The libvirt
libxl driver still uses uint32_t variables for these various
parameters, which is particularly problematic for the
libxl_set_memory_target() function.
When dom0 autoballooning is enabled, libvirt (like xl) determines
the memory needed to start a domain and the memory available. If
memory available is less than memory needed, dom0 is ballooned
down by passing a negative value to libxl_set_memory_target()
'target_memkb' parameter. Prior to xen.git commit 57f8b13c,
'target_memkb' was an int32_t. Subtracting a larger uint32 from
a smaller uint32 and assigning it to int32 resulted in a negative
number. After commit 57f8b13c, the same subtraction is widened
to a int64, resulting in a large positive number. The simple
fix taken by this patch is to assign the difference of the
uint32 values to a temporary int32 variable, which is then
passed to 'target_memkb' parameter of libxl_set_memory_target().
Note that it is undesirable to change libvirt to use 64 bit
variables since it requires setting LIBXL_API_VERSION to 0x040800.
Currently libvirt supports LIBXL_API_VERSION >= 0x040400,
essentially Xen >= 4.4.
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
src/libxl/libxl_domain.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index a5314b0..ed73cd2 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -909,6 +909,7 @@ libxlDomainFreeMem(libxl_ctx *ctx, libxl_domain_config *d_config)
{
uint32_t needed_mem;
uint32_t free_mem;
+ int32_t target_mem;
int tries = 3;
int wait_secs = 10;
@@ -922,7 +923,8 @@ libxlDomainFreeMem(libxl_ctx *ctx, libxl_domain_config *d_config)
if (free_mem >= needed_mem)
return 0;
- if (libxl_set_memory_target(ctx, 0, free_mem - needed_mem,
+ target_mem = free_mem - needed_mem;
+ if (libxl_set_memory_target(ctx, 0, target_mem,
/* relative */ 1, 0) < 0)
goto error;
--
2.9.2
7 years, 10 months
[libvirt] [RFC] Vhost-user backends cross-version migration support
by Maxime Coquelin
Hi,
Few months ago, Michael reported a problem about migrating VMs relying
on vhost-user between hosts supporting different backend versions:
- Message-Id: <20161011173526-mutt-send-email-mst(a)kernel.org>
- https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg03026.html
The goal of this thread is to draft a proposal based on the outcomes
of discussions with contributors of the different parties (DPDK/OVS
/libvirt/...).
Problem statement:
==================
When migrating a VM from one host to another, the interfaces exposed by
QEMU must stay unchanged in order to guarantee a successful migration.
In the case of vhost-user interface, parameters like supported Virtio
feature set, max number of queues, max vring sizes,... must remain
compatible. Indeed, the frontend not being re-initialized, no
renegotiation happens at migration time.
For example, we have a VM that runs on host A, which has its vhost-user
backend advertising VIRTIO_F_RING_INDIRECT_DESC feature. Since the Guest
also support this feature, it is successfully negotiated, and guest
transmit packets using indirect descriptor tables, that the backend
knows to handle.
At some point, the VM is being migrated to host B, which runs an older
version of the backend not supporting this VIRTIO_F_RING_INDIRECT_DESC
feature. The migration would break, because the Guest still have the
VIRTIO_F_RING_INDIRECT_DESC bit sets, and the virtqueue contains some
decriptors pointing to indirect tables, that backend B doesn't know to
handle.
This is just an example about Virtio features compatibility, but other
backend implementation details could cause other failures.
What we need is to be able to query the destination host's backend to
ensure migration is possible. Also, we would need to query this
statically, even before the VM is started, to be sure it could be
migrated elsewhere for any reason.
Solution 1: Libvirt queries DPDK vhost lib: *KO*
================================================
Initial idea was to have the management tool (libvirt) to query DPDK
vhost lib and get key/value pairs and check whether migration is
possible. This solution doesn't work for several reasons:
1. Vhost lib API provide a way for the application to disable features
at runtime (understand, not at build time). So coming back to previous
example, DPDK v16.11 supports indirect descriptor features, but it could
be disabled by OVS. We had a look at whether this API was mandatory, and
it turns out to be, as TSO feature is supported on DPDK but not in OVS.
So we cannot rely on DPDK only.
2. Some parameter may be not only DPDK specific, such as the maximum
number of queues for example.
Solution 2: Libvirt queries OVS for vhost backend key/value pairs: *KO*
=======================================================================
Second idea was for OVS to expose its vhost backend implementation
parameters as key/value pairs, for example in the DB or by a dedicated
tool. For example, you could have this kind of information:
- virtio-features: 0x12045694
- max-rx-queues: 1024
- max-rx-ring-size: 512
Doing this, Libvirt has the information to take decision whether
migration is possible or not.
The problem is that Libvirt doesn't know (and want) to interpret these
values (should it be equal/lower/greater/...?), and each time a new
key is introduced in OVS, Libvirt will have to be updated to handle it,
adding an unwanted synchronization constraint between the projects.
Solution 3: Libvirt queries OVS for vhost backend version string: *OK*
======================================================================
The idea is to have a table of supported versions, associated to
key/value pairs. Libvirt could query the list of supported versions
strings for each hosts, and select the first common one among all hosts.
Then, libvirt would ask OVS to probe the vhost-user interfaces in the
selected version (compatibility mode). For example host A runs OVS-2.7,
and host B OVS-2.6. Host A's OVS-2.7 has an OVS-2.6 compatibility mode
(e.g. with indirect descriptors disabled), which should be selected at
vhost-user interface probe time.
Advantage of doing so is that libvirt does not need any update if new
keys are introduced (i.e. it does not need to know how the new keys have
to be handled), all these checks remain in OVS's vhost-user implementation.
Ideally, we would support per vhost-user interface compatibility mode,
which may have an impact also on DPDK API, as the Virtio feature update
API is global, and not per port.
- Implementation:
-----------------
Goal here is just to illustrate this proposal, I'm sure you will have
good suggestion to improve it.
In OVS vhost-user library, we would introduce a new structure, for
example (neither compiled nor tested):
struct vhostuser_compat {
char *version;
uint64_t virtio_features;
uint32_t max_rx_queue_sz;
uint32_t max_nr_queues;
};
*version* field is the compatibility version string.
It could be something like: "upstream.ovs-dpdk.v2.6"
In case for example Fedora adds some more patches to its
package that would break migration to upstream version, it could have
a dedicated compatibility string: "fc26.ovs-dpdk.v2.6".
In case OVS-v2.7 does not break compatibility with previous OVS-v2.6
version, then no need to create a new compatibility entry, just keep
v2.6 one.
*virtio_features* field is the Virtio features set for a given
compatibility version. When an OVS tag is to be created, it would be
associated to a DPDK version. The Virtio features for these version
would be stored in this field. It would allow to upgrade the DPDK
package for example from v16.07 to v16.11 without breaking migration.
In case the distribution wants to benefit from latests Virtio
features, it would have to create a new entry to ensure migration
won't be broken.
*max_rx_queue_sz*
*max_nr_queues* fields are just here for example, don't think this is
needed today. I just want to illustrate that we have to anticipate
other parameters than the Virtio feature set, even if not necessary
at the moment.
We create a table with different compatibility versions in OVS
vhost-user lib:
static struct vhostuser_compat vu_compat[] = {
{
.version = "upstream.ovs-dpdk.v2.7",
.virtio_features = 0x12045694,
.max_rx_queue_sz = 512,
},
{
.version = "upstream.ovs-dpdk.v2.6",
.virtio_features = 0x10045694,
.max_rx_queue_sz = 1024,
},
}
At some time during installation, or system init, the table would be
parsed, and compatibility version strings would be stored into the OVS
database, or a new tool would be created to list these strings.
Before launching the VM, libvirt will query the version strings for
each hosts using for example the JSON RPC API of OVS (maybe not the best
solution, looking forward for your comments on this). Libvirt would then
select the first common supported version, and insert this string into
the vhost-user interfaces parameters in the OVS DBs of each host.
When the vhost-user connection is initiated, OVS would know in which
compatibility mode to init the interface, for example by restricting
the support Virtio features of the interface.
Do you think this is reasonable? Or maybe you have alternative ideas
that would be best fit to ensure successful migration?
Cheers,
Maxime
7 years, 10 months
[libvirt] [PATCH] HACKING: Update after recent change of the html file
by Peter Krempa
---
Pushed as trivial.
HACKING | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/HACKING b/HACKING
index ff545a8fa..fff003b9e 100644
--- a/HACKING
+++ b/HACKING
@@ -231,7 +231,8 @@ feature or changing the output of a program.
such as adding new XML elements or fixing all but the most obscure bugs, must
be (briefly) described in a release notes entry; changes that are only
relevant to other libvirt developers, such as code refactoring, don't belong
-in the release notes.
+in the release notes. Note that "docs/news.xml" should be updated in its own
+commit not to get in the way of backports.
There is more on this subject, including lots of links to background reading
on the subject, on Richard Jones' guide to working with open source projects
--
2.11.0
7 years, 10 months
[libvirt] [PATCH] virtlockd: fix systemd unit file dependancies
by Daniel P. Berrange
After deploying virtlogd by default we identified a number of
mistakes in the systemd unit file. virtlockd's relationship
to libvirtd is the same as virtlogd, so we must apply the
same unit file fixes to virtlockd
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
daemon/libvirtd.service.in | 1 +
src/locking/virtlockd.service.in | 1 +
src/locking/virtlockd.socket.in | 1 +
3 files changed, 3 insertions(+)
diff --git a/daemon/libvirtd.service.in b/daemon/libvirtd.service.in
index bbf27da..c72dde5 100644
--- a/daemon/libvirtd.service.in
+++ b/daemon/libvirtd.service.in
@@ -6,6 +6,7 @@
[Unit]
Description=Virtualization daemon
Requires=virtlogd.socket
+Requires=virtlockd.socket
Before=libvirt-guests.service
After=network.target
After=dbus.service
diff --git a/src/locking/virtlockd.service.in b/src/locking/virtlockd.service.in
index 57089b0..69b568f 100644
--- a/src/locking/virtlockd.service.in
+++ b/src/locking/virtlockd.service.in
@@ -1,6 +1,7 @@
[Unit]
Description=Virtual machine lock manager
Requires=virtlockd.socket
+Before=libvirtd.service
Documentation=man:virtlockd(8)
Documentation=http://libvirt.org
diff --git a/src/locking/virtlockd.socket.in b/src/locking/virtlockd.socket.in
index 9808bbb..45e0f20 100644
--- a/src/locking/virtlockd.socket.in
+++ b/src/locking/virtlockd.socket.in
@@ -1,5 +1,6 @@
[Unit]
Description=Virtual machine lock manager socket
+Before=libvirtd.service
[Socket]
ListenStream=@localstatedir@/run/libvirt/virtlockd-sock
--
2.9.3
7 years, 10 months
[libvirt] [PATCH] docs: Release notes should be updated in a separate commit
by Andrea Bolognani
Updating docs/news.xml in the same commit that performs the
documented change makes backports needlessly complicated,
both for mainteinance branches and downstream distributions,
because it introduces additional potential for merge
conflicts.
Document in the contributor guidelines that the release notes
should be updated in a separate commit instead, so that it's
easy to backport just the code change.
---
docs/hacking.html.in | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/docs/hacking.html.in b/docs/hacking.html.in
index c7bbcbd..b1bb149 100644
--- a/docs/hacking.html.in
+++ b/docs/hacking.html.in
@@ -302,7 +302,8 @@
or fixing all but the most obscure bugs, must be (briefly) described
in a release notes entry; changes that are only relevant to other
libvirt developers, such as code refactoring, don't belong in the
- release notes.</p>
+ release notes. Note that <code>docs/news.xml</code> should be updated
+ in its own commit not to get in the way of backports.</p>
</li>
</ol>
--
2.7.4
7 years, 10 months
[libvirt] [V2 0/5] Support cache tune in libvirt
by Eli Qiao
This series patches are for supportting CAT featues, which also
called cache tune in libvirt.
First to expose cache information which could be tuned in capabilites XML.
Then add new domain xml element support to add cacahe bank which will apply
on this libvirt domain.
This series patches add a util file `resctrl.c/h`, an interface to talk with
linux kernel's sys fs.
There are some TODO work such as logic of supportting l3code/l3data, expose
new public interface to get free cache information.
Some discussion about this feature support can be found from:
https://www.redhat.com/archives/libvir-list/2017-January/msg00644.html
Eli Qiao (5):
Resctrl: Add some utils functions
Resctrl: expose cache information to capabilities
Resctrl: Add new xml element to support cache tune
Resctrl: Add private interface to set cachebanks
Qemu: Set cache banks
docs/schemas/domaincommon.rng | 41 ++
include/libvirt/virterror.h | 1 +
src/Makefile.am | 1 +
src/conf/capabilities.c | 56 +++
src/conf/capabilities.h | 23 +
src/conf/domain_conf.c | 134 ++++++
src/conf/domain_conf.h | 18 +
src/libvirt_private.syms | 10 +
src/qemu/qemu_capabilities.c | 68 +++
src/qemu/qemu_driver.c | 4 +
src/qemu/qemu_process.c | 10 +
src/util/virerror.c | 1 +
src/util/virresctrl.c | 994 ++++++++++++++++++++++++++++++++++++++++++
src/util/virresctrl.h | 135 ++++++
14 files changed, 1496 insertions(+)
create mode 100644 src/util/virresctrl.c
create mode 100644 src/util/virresctrl.h
--
1.9.1
7 years, 10 months
[libvirt] [PATCH 0/2] Fix random crash in qemuhotplugtest
by Peter Krempa
First patch makes the bug 100%[1] reproducible.
*[1]: Race conditions may apply.
Peter Krempa (2):
DON'T APPLY: Reproducer to serialize threads "correctly"
tests: qemuhotplug: Don't free the monitor object as part of @vm
tests/qemuhotplugtest.c | 10 +++++++++-
tests/qemumonitortestutils.c | 2 ++
2 files changed, 11 insertions(+), 1 deletion(-)
--
2.11.0
7 years, 10 months
[libvirt] [PATCH] tests: qemuhotplug: Fix memory leaks after cpu hotplug testing patches
by Peter Krempa
testQemuHotplugCpuDataFree leaked @data always and
testQemuHotplugCpuPrepare leaked @prefix on success
---
Pushed as trivial.
tests/qemuhotplugtest.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/qemuhotplugtest.c b/tests/qemuhotplugtest.c
index 9a203bd44..8cceb883e 100644
--- a/tests/qemuhotplugtest.c
+++ b/tests/qemuhotplugtest.c
@@ -377,6 +377,7 @@ testQemuHotplugCpuDataFree(struct testQemuHotplugCpuData *data)
virObjectUnref(data->vm);
qemuMonitorTestFree(data->mon);
+ VIR_FREE(data);
}
@@ -434,6 +435,8 @@ testQemuHotplugCpuPrepare(const char *test,
if (qemuDomainRefreshVcpuInfo(&driver, data->vm, 0, false) < 0)
goto error;
+ VIR_FREE(prefix);
+
return data;
error:
--
2.11.0
7 years, 10 months
[libvirt] [PATCH] qemu: turn on virtlockd by default
by Daniel P. Berrange
The virtlockd daemon has existed for years now, but we have never
turned it on by default, requiring explicit user opt-in. This leaves
users unprotected against accidents out of the box.
By turning it on by default, users will at least be protected for
mistakes involving local files, and files on shared filesystems
that support fcntl() (eg NFS).
In turning it on the various services files are updated to have
the same dependancies for virtlockd as we have for virtlogd
now, since turning the latter on exposed some gaps.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
daemon/libvirtd.service.in | 1 +
src/locking/virtlockd.service.in | 1 +
src/locking/virtlockd.socket.in | 1 +
src/qemu/qemu.conf | 2 +-
src/qemu/qemu_conf.c | 3 +++
5 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/daemon/libvirtd.service.in b/daemon/libvirtd.service.in
index bbf27da..c72dde5 100644
--- a/daemon/libvirtd.service.in
+++ b/daemon/libvirtd.service.in
@@ -6,6 +6,7 @@
[Unit]
Description=Virtualization daemon
Requires=virtlogd.socket
+Requires=virtlockd.socket
Before=libvirt-guests.service
After=network.target
After=dbus.service
diff --git a/src/locking/virtlockd.service.in b/src/locking/virtlockd.service.in
index 57089b0..69b568f 100644
--- a/src/locking/virtlockd.service.in
+++ b/src/locking/virtlockd.service.in
@@ -1,6 +1,7 @@
[Unit]
Description=Virtual machine lock manager
Requires=virtlockd.socket
+Before=libvirtd.service
Documentation=man:virtlockd(8)
Documentation=http://libvirt.org
diff --git a/src/locking/virtlockd.socket.in b/src/locking/virtlockd.socket.in
index 9808bbb..45e0f20 100644
--- a/src/locking/virtlockd.socket.in
+++ b/src/locking/virtlockd.socket.in
@@ -1,5 +1,6 @@
[Unit]
Description=Virtual machine lock manager socket
+Before=libvirtd.service
[Socket]
ListenStream=@localstatedir@/run/libvirt/virtlockd-sock
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index a8cd369..3239f7b 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -535,7 +535,7 @@
# share one writable disk, libvirt offers two approaches for
# locking files. The first one is sanlock, the other one,
# virtlockd, is then our own implementation. Accepted values
-# are "sanlock" and "lockd".
+# are "sanlock", "lockd", "nop". The default is "lockd".
#
#lock_manager = "lockd"
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 6613d59..d4c6cdc 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -314,6 +314,9 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged)
cfg->glusterDebugLevel = 4;
cfg->stdioLogD = true;
+ if (VIR_STRDUP(cfg->lockManagerName, "lockd") < 0)
+ goto error;
+
if (!(cfg->namespaces = virBitmapNew(QEMU_DOMAIN_NS_LAST)))
goto error;
--
2.9.3
7 years, 10 months
[libvirt] [PATCH] qemu: enforce maximum ports value for nec-xhci
by Ján Tomko
This controller only allows up to 15 ports.
https://bugzilla.redhat.com/show_bug.cgi?id=1375417
---
src/qemu/qemu_domain.c | 8 ++++++++
.../qemuxml2argv-usb-controller-xhci-limit.xml | 16 ++++++++++++++++
tests/qemuxml2argvtest.c | 3 +++
3 files changed, 27 insertions(+)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-usb-controller-xhci-limit.xml
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index c6ce090..61489e0 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -3147,6 +3147,14 @@ qemuDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
if (dev->type == VIR_DOMAIN_DEVICE_CONTROLLER) {
virDomainControllerDefPtr cont = dev->data.controller;
+ if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&
+ cont->model == VIR_DOMAIN_CONTROLLER_MODEL_USB_NEC_XHCI &&
+ cont->opts.usbopts.ports > 15) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("nec-xhci controller only supports up to 15 ports"));
+ goto cleanup;
+ }
+
if (cont->type == VIR_DOMAIN_CONTROLLER_TYPE_PCI) {
if (cont->model == VIR_DOMAIN_CONTROLLER_MODEL_PCI_EXPANDER_BUS &&
!qemuDomainMachineIsI440FX(def)) {
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-usb-controller-xhci-limit.xml b/tests/qemuxml2argvdata/qemuxml2argv-usb-controller-xhci-limit.xml
new file mode 100644
index 0000000..5ff2de7
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-usb-controller-xhci-limit.xml
@@ -0,0 +1,16 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory unit='KiB'>219136</memory>
+ <currentMemory unit='KiB'>219136</currentMemory>
+ <vcpu placement='static'>1</vcpu>
+ <os>
+ <type arch='i686' machine='pc'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <devices>
+ <emulator>/usr/bin/qemu</emulator>
+ <controller type='usb' index='0' model='nec-xhci' ports='16'/>
+ <memballoon model='none'/>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 3532cb5..78cb609 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1415,6 +1415,9 @@ mymain(void)
QEMU_CAPS_CHARDEV, QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_PIIX3_USB_UHCI,
QEMU_CAPS_NEC_USB_XHCI, QEMU_CAPS_NEC_USB_XHCI_PORTS,
QEMU_CAPS_USB_HUB);
+ DO_TEST_PARSE_ERROR("usb-controller-xhci-limit",
+ QEMU_CAPS_CHARDEV, QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_PIIX3_USB_UHCI,
+ QEMU_CAPS_NEC_USB_XHCI, QEMU_CAPS_NEC_USB_XHCI_PORTS);
DO_TEST("smbios", QEMU_CAPS_SMBIOS_TYPE);
DO_TEST_PARSE_ERROR("smbios-date", QEMU_CAPS_SMBIOS_TYPE);
--
2.10.2
7 years, 10 months
