[libvirt] [perl][PATCH] Add VIR_MIGRATE_PARAM_TLS_DESTINATION constant
by Michal Privoznik
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
Changes | 1 +
lib/Sys/Virt.xs | 1 +
lib/Sys/Virt/Domain.pm | 9 +++++++++
3 files changed, 11 insertions(+)
diff --git a/Changes b/Changes
index 37529ac..cf5d8cc 100644
--- a/Changes
+++ b/Changes
@@ -4,6 +4,7 @@ Revision history for perl module Sys::Virt
- Add VIR_DOMAIN_JOB_SUCCESS and VIR_DOMAIN_JOB_STATS_KEEP_COMPLETED
constants
+ - Add VIR_MIGRATE_PARAM_TLS_DESTINATION constant
5.10.0 2019-12-03
diff --git a/lib/Sys/Virt.xs b/lib/Sys/Virt.xs
index 98a12d7..a729a52 100644
--- a/lib/Sys/Virt.xs
+++ b/lib/Sys/Virt.xs
@@ -9246,6 +9246,7 @@ BOOT:
REGISTER_CONSTANT_STR(VIR_MIGRATE_PARAM_AUTO_CONVERGE_INCREMENT, MIGRATE_PARAM_AUTO_CONVERGE_INCREMENT);
REGISTER_CONSTANT_STR(VIR_MIGRATE_PARAM_BANDWIDTH_POSTCOPY, MIGRATE_PARAM_BANDWIDTH_POSTCOPY);
REGISTER_CONSTANT_STR(VIR_MIGRATE_PARAM_PARALLEL_CONNECTIONS, MIGRATE_PARAM_PARALLEL_CONNECTIONS);
+ REGISTER_CONSTANT_STR(VIR_MIGRATE_PARAM_TLS_DESTINATION, MIGRATE_PARAM_TLS_DESTINATION);
REGISTER_CONSTANT(VIR_DOMAIN_MIGRATE_MAX_SPEED_POSTCOPY, MIGRATE_MAX_SPEED_POSTCOPY);
diff --git a/lib/Sys/Virt/Domain.pm b/lib/Sys/Virt/Domain.pm
index 2caec51..ae909de 100644
--- a/lib/Sys/Virt/Domain.pm
+++ b/lib/Sys/Virt/Domain.pm
@@ -1141,6 +1141,15 @@ progress is not made
The number of connections used during parallel migration.
+=item C<Sys::Virt::Domain::MIGRATE_PARAM_TLS_DESTINATION>
+
+Override the destination host name used for TLS verification.
+Normally the TLS certificate from the destination host must match
+the host's name for TLS verification to succeed. When the
+certificate does not match the destination hostname and the
+expected cetificate's hostname is known, this parameter can be
+used to pass this expected hostname when starting the migration.
+
=back
=item $ddom = $dom->migrate(destcon, flags=0, dname=undef, uri=undef, bandwidth=0)
--
2.23.0
4 years, 11 months
Re: [libvirt] [PATCH 2/2] Add -mem-shared option
by Thomas Huth
On 02/12/2019 22.00, Eduardo Habkost wrote:
> On Mon, Dec 02, 2019 at 08:39:48AM +0100, Igor Mammedov wrote:
>> On Fri, 29 Nov 2019 18:46:12 +0100
>> Paolo Bonzini <pbonzini(a)redhat.com> wrote:
>>
>>> On 29/11/19 13:16, Igor Mammedov wrote:
>>>> As for "-m", I'd make it just an alias that translates
>>>> -m/mem-path/mem-prealloc
>>>
>>> I think we should just deprecate -mem-path/-mem-prealloc in 5.0. CCing
>>> Thomas as mister deprecation. :)
>>
>> I'll add that to my series
>
> Considering that the plan is to eventually reimplement those
> options as syntactic sugar for memory backend options (hopefully
> in less than 2 QEMU releases), what's the point of deprecating
> them?
Well, it depends on the "classification" [1] of the parameter...
Let's ask: What's the main purpose of the option?
Is it easier to use than the "full" option, and thus likely to be used
by a lot of people who run QEMU directly from the CLI? In that case it
should stay as "convenience option" and not be deprecated.
Or is the option merely there to give the upper layers like libvirt or
some few users and their scripts some more grace period to adapt their
code, but we all agree that the options are rather ugly and should
finally go away? Then it's rather a "legacy option" and the deprecation
process is the right way to go. Our QEMU interface is still way to
overcrowded, we should try to keep it as clean as possible.
Thomas
[1] Using the terms from:
https://www.youtube.com/watch?v=Oscjpkns7tM&t=8m
4 years, 11 months
[libvirt] [PATCH v2 00/14] drop usage of c-type gnulib module
by Pavel Hrdina
Changes in v2:
- fixed missing parentheses in patch 01
- added patch 02 to cover c_isascii
Pavel Hrdina (14):
util: define IS_BLANK instead of using c_isblank from gnulib
virkeyfile: define IS_ASCII instead c_isascii from gnulib
use g_ascii_isalnum instead of c_isalnum from gnulib
use g_ascii_isalpha instead of c_isalpha from gnulib
use g_ascii_iscntrl instead of c_iscntrl from gnulib
use g_ascii_isdigit instead of c_isdigit frum gnulib
use g_ascii_islower instead of c_islower from gnulib
use g_ascii_isprint instead of c_isprint from gnulib
use g_ascii_isspace instead of c_isspace from gnulib
use g_ascii_isxdigit instead of c_isxdigit from gnulib
use g_ascii_tolower instead of c_tolower from gnulib
use g_ascii_toupper instead of c_toupper from gnulib
syntax-check: update c-type checks to refer to Glib
bootstrap.conf: drop usage of c-type gnulib module
bootstrap.conf | 1 -
build-aux/syntax-check.mk | 11 ++---------
src/bhyve/bhyve_parse_command.c | 3 +--
src/conf/network_conf.c | 3 +--
src/conf/nwfilter_conf.c | 3 +--
src/interface/interface_backend_udev.c | 5 ++---
src/libxl/libxl_conf.c | 3 +--
src/node_device/node_device_udev.c | 3 +--
src/qemu/qemu_agent.c | 3 +--
src/qemu/qemu_domain.c | 3 +--
src/qemu/qemu_monitor.c | 3 +--
src/qemu/qemu_qapi.c | 4 +---
src/remote/remote_driver.c | 3 +--
src/rpc/virnetsocket.c | 3 +--
src/storage/parthelper.c | 5 ++---
src/util/virbitmap.c | 5 ++---
src/util/virconf.c | 18 +++++++++---------
src/util/virfile.c | 8 +++-----
src/util/virhostcpu.c | 7 +++----
src/util/virkeyfile.c | 13 +++++++------
src/util/virmacaddr.c | 11 +++++------
src/util/virnetdevvportprofile.c | 3 +--
src/util/virpidfile.c | 3 +--
src/util/virstoragefile.c | 3 +--
src/util/virstring.c | 13 ++++++-------
src/util/virutil.c | 11 +++++------
src/util/viruuid.c | 9 ++++-----
src/vmx/vmx.c | 8 +++-----
tools/virsh-console.c | 3 +--
tools/virsh-domain.c | 3 +--
tools/vsh-table.c | 5 ++---
tools/vsh.c | 5 ++---
32 files changed, 73 insertions(+), 111 deletions(-)
--
2.23.0
4 years, 11 months
[libvirt] libvirt-guests.sh without or with failing ACPI support
by Henning Schild
Hi all,
the systemd shutdown scripts work sequentially with a 300s timeout
(seen on Debian). If a VM does not have ACPI support, or the ACPI
support failed for some reason, you are looking at a 300s timeout per
instance for a host shutdown/reboot.
i.e. 10 instances without working ACPI = 3000s to shut down
I think the systemd scripting should be parallel instead of
sequentially. So if you have many VMs without working ACPI you just
have to wait 300s in total for the host to shut down.
Steps to reproduce:
- star a VM that does not support ACPI
- reboot the host and wait 300s for the VM to be shut down
- now start it multiple times
- wait multiples of 300s for the shutdown
Expected behaviour:
- no matter how many instances do not support ACPI, make it 300s max
because we shut them down in parallel
regards,
Henning
4 years, 11 months
[libvirt] [jenkins-ci PATCH 0/2] Build Go projects on CentOS 7 once again
by Andrea Bolognani
Andrea Bolognani (2):
guests: Enable Go projects on CentOS 7 once again
Build Go projects on CentOS 7 once again
guests/host_vars/libvirt-centos-7/main.yml | 2 ++
guests/playbooks/build/projects/libvirt-go-xml.yml | 13 +------------
guests/playbooks/build/projects/libvirt-go.yml | 13 +------------
jenkins/projects/libvirt-go-xml.yaml | 9 +--------
jenkins/projects/libvirt-go.yaml | 9 +--------
5 files changed, 6 insertions(+), 40 deletions(-)
--
2.23.0
4 years, 11 months
[libvirt] [PATCH 0/2] net: Drop legacy "name" from -net and remove NetLegacy
by Thomas Huth
It's time to remove the deprecated "name" parameter from -net.
Please have a closer look at the second patch ... I think it should be
fine, but I'm not 100% sure whether it's ok for all cases to drop NetLegacy,
so please double-check.
Thomas Huth (2):
net: Drop the legacy "name" parameter from the -net option
net: Drop the NetLegacy structure, always use Netdev instead
net/net.c | 84 +++++++-------------------------------------
qapi/net.json | 53 +---------------------------
qemu-deprecated.texi | 12 ++++---
3 files changed, 20 insertions(+), 129 deletions(-)
--
2.18.1
4 years, 11 months
[libvirt] [jenkins-ci PATCH] Sync comments
by Andrea Bolognani
Some comments were only present in the Ansible part and not in
the Jenkins part and vice versa.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
Pushed as trivial.
guests/playbooks/build/projects/libvirt-tck.yml | 2 ++
jenkins/projects/libosinfo.yaml | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/guests/playbooks/build/projects/libvirt-tck.yml b/guests/playbooks/build/projects/libvirt-tck.yml
index ef88cd3..b8d848c 100644
--- a/guests/playbooks/build/projects/libvirt-tck.yml
+++ b/guests/playbooks/build/projects/libvirt-tck.yml
@@ -1,5 +1,7 @@
---
- set_fact:
+ # CentOS 7 doesn't include perl-generators, which is necessary to
+ # build libvirt-tck
name: libvirt-tck
machines:
- libvirt-debian-9
diff --git a/jenkins/projects/libosinfo.yaml b/jenkins/projects/libosinfo.yaml
index cde10ec..819c5ac 100644
--- a/jenkins/projects/libosinfo.yaml
+++ b/jenkins/projects/libosinfo.yaml
@@ -1,8 +1,6 @@
---
- project:
name: libosinfo
- # libosinfo depends on meson 0.49.0, which is not available on
- # CentOS 7, Debian 9, Ubuntu 18;
machines: '{all_machines}'
title: libosinfo
archive_format: xz
--
2.23.0
4 years, 11 months
[libvirt] libvirt mdev migration, mdevctl integration
by Alex Williamson
Hey folks,
We had some discussions at KVM Forum around mdev live migration and
what that might mean for libvirt handling of mdev devices and
potential libvirt/mdevctl[1] flows. I believe the current situation is
that libvirt knows nothing about an mdev beyond the UUID in the XML.
It expects the mdev to exist on the system prior to starting the VM.
The intention is for mdevctl to step in here by providing persistence
for mdev devices such that these pre-defined mdevs are potentially not
just ephemeral, for example, we can tag specific mdevs for automatic
startup on each boot.
It seems the next step in this journey is to figure out if libvirt can
interact with mdevctl to "manage" a device. I believe we've avoided
defining managed='yes' behavior for mdev hostdevs up to this point
because creating an mdev device involves policy decisions. For
example, which parent device hosts the mdev, are there optimal NUMA
considerations, are there performance versus power considerations, what
is the nature of the mdev, etc. mdevctl doesn't necessarily want to
make placement decisions either, but it does understand how to create
and remove an mdev, what it's type is, associate it to a fixed
parent, apply attributes, etc. So would it be reasonable that for a
manage='yes' mdev hostdev device, libvirt might attempt to use mdevctl
to start an mdev by UUID and stop it when the VM is shutdown? This
assumes the mdev referenced by the UUID is already defined and known to
mdevct. I'd expect semantics much like managed='yes' around vfio-pci
binding, ex. start/stop if it doesn't exist, leave it alone if it
already exists.
If that much seems reasonable, and someone is willing to invest some
development time to support it, what are then the next steps to enable
migration?
AIUI, libvirt blindly assumes hostdev devices cannot be migrated. This
may already be getting some work due to Jens' network failover support
where the attached hostdev doesn't really migrate, but it allows the
migration to proceed in a partially detached state so that it can jump
back into action should the migration fail. Long term we expect that
not only some mdev hostdevs might be migratable, but possibly some
regular vfio-pci hostdevs as well. I think libvirt will need to remove
any assumptions around hostdev migration and rather rely on
introspection of the QEMU process to determine if any devices hold
migration blockers (or simply try the migration and let QEMU fail
quickly if there are blockers).
So assuming we now have a VM with a managed='yes' mdev hostdev device,
what do we need to do to reproduce that device at the migration target?
mdevctl can dump a device in a json format, where libvirt could use
this to define and start an equivalent device on the migration target
(potentially this json is extended by mdevctl to include the migration
compatibility vendor string). Part of our discussion at the Forum was
around the extent to which libvirt would want to consider this json
opaque. For instance, while libvirt doesn't currently support localhost
migration, libvirt might want to use an alternate UUID for the mdev
device on the migration target so as not to introduce additional
barriers to such migrations. Potentially mdevctl could accept the json
from the source system as a template and allow parameters such as UUID
to be overwritten by commandline options. This might allow libvirt to
consider the json as opaque.
An issue here though is that the json will also include the parent
device, which we obviously cannot assume is the same (particularly the
bus address) on the migration target. We can allow commandline
overrides for the parent just as we do above for the UUID when defining
the mdev device from json, but it's an open issue who is going to be
smart enough (perhaps dumb enough) to claim this responsibility. It
would be interesting to understand how libvirt handles other host
specific information during migration, for instance if node or processor
affinities are part of the VM XML, how is that translated to the
target? I could imagine that we could introduce a simple "first
available" placement in mdevctl, but maybe there should minimally be a
node allocation preference with optional enforcement (similar to
numactl), or maybe something above libvirt needs to take this
responsibility to prepare the target before we get ourselves into
trouble.
Anyway, I hope this captures some of what was discussed at KVM Forum
and that we can continue that discussion here to map out the design and
tasks to enable vfio/mdev hostdev migration in libvirt. Thanks,
Alex
[1] https://github.com/mdevctl/mdevctl
4 years, 11 months
Re: [libvirt] qemu: directly create virResctrlInfo ignoring capabilities
by Wang Huaqiang
This patch introduced a bug and broke the 'resctrl' feature.
It introduced a 'divide by zero' error if you defined any 'resctrl'
allocation group through <cputune/cachetune/cache>.
Reason is 'caps->resctrl' is fully initialized through two steps,
'virResctrlInfoNew'
invokes 'virResctrlGetInfo' completes the first step, later,
'virResctrlInfoGetCache'
accomplishes the filling of
'caps->resctrl->levels->types->control.granularity'.
The simplest way to fix the bug is drawback this patch, but still have
the undesirable
overhead.
Another way to fix but not that simple is moving the 'caps->host.cache'
object
into 'virresctrl'. If no one takes this task, I can do it and need some
days for it.
Br
Huaqiang
> [libvirt] [PATCH 29/30] qemu: directly create virResctrlInfo ignoring
> capabilities
> From: Daniel P. Berrangé <berrange redhat com>
> To: libvir-list redhat com
> Subject: [libvirt] [PATCH 29/30] qemu: directly create virResctrlInfo
> ignoring capabilities
> Date: Wed, 4 Dec 2019 14:21:12 +0000
> We always refresh the capabilities object when using virResctrlInfo
> during process startup. This is undesirable overhead, because we can
> just directly create a virResctrlInfo instead.
>
> Signed-off-by: Daniel P. Berrangé <berrange redhat com>
> ---
> src/qemu/qemu_process.c | 24 ++++++++----------------
> src/util/virresctrl.h | 2 ++
> 2 files changed, 10 insertions(+), 16 deletions(-)
>
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index 3a3860b1a3..2b35680abc 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -2724,29 +2724,24 @@ qemuProcessSetupEmulator(virDomainObjPtr vm)
>
>
> static int
> -qemuProcessResctrlCreate(virQEMUDriverPtr driver,
> - virDomainObjPtr vm)
> +qemuProcessResctrlCreate(virDomainObjPtr vm)
> {
> - int ret = -1;
> size_t i = 0;
> - virCapsPtr caps = NULL;
> qemuDomainObjPrivatePtr priv = vm->privateData;
> + g_autoptr(virResctrlInfo) resctrl = NULL;
>
> if (!vm->def->nresctrls)
> return 0;
>
> - /* Force capability refresh since resctrl info can change
> - * XXX: move cache info into virresctrl so caps are not needed */
> - caps = virQEMUDriverGetCapabilities(driver, true);
> - if (!caps)
> + if (!(resctrl = virResctrlInfoNew()))
> return -1;
>
> for (i = 0; i < vm->def->nresctrls; i++) {
> size_t j = 0;
> - if (virResctrlAllocCreate(caps->host.resctrl,
> + if (virResctrlAllocCreate(resctrl,
> vm->def->resctrls[i]->alloc,
> priv->machineName) < 0)
> - goto cleanup;
> + return -1;
>
> for (j = 0; j < vm->def->resctrls[i]->nmonitors; j++) {
> virDomainResctrlMonDefPtr mon = NULL;
> @@ -2754,14 +2749,11 @@ qemuProcessResctrlCreate(virQEMUDriverPtr driver,
> mon = vm->def->resctrls[i]->monitors[j];
> if (virResctrlMonitorCreate(mon->instance,
> priv->machineName) < 0)
> - goto cleanup;
> + return -1;
> }
> }
>
> - ret = 0;
> - cleanup:
> - virObjectUnref(caps);
> - return ret;
> + return 0;
> }
>
>
> @@ -6882,7 +6874,7 @@ qemuProcessLaunch(virConnectPtr conn,
> goto cleanup;
>
> VIR_DEBUG("Setting up resctrl");
> - if (qemuProcessResctrlCreate(driver, vm) < 0)
> + if (qemuProcessResctrlCreate(vm) < 0)
> goto cleanup;
>
> VIR_DEBUG("Setting up managed PR daemon");
> diff --git a/src/util/virresctrl.h b/src/util/virresctrl.h
> index 3dd7c96348..759320d0fd 100644
> --- a/src/util/virresctrl.h
> +++ b/src/util/virresctrl.h
> @@ -100,6 +100,8 @@ typedef virResctrlInfo *virResctrlInfoPtr;
> virResctrlInfoPtr
> virResctrlInfoNew(void);
>
> +G_DEFINE_AUTOPTR_CLEANUP_FUNC(virResctrlInfo, virObjectUnref);
> +
> int
> virResctrlInfoGetCache(virResctrlInfoPtr resctrl,
> unsigned int level,
4 years, 11 months
[libvirt] [PATCH] Fix src/ pkg-config API XML paths
by Cole Robinson
The .pc files in src/ are intended for use with the ./run script,
to ease building bindings against an uninstalled libvirt build.
The pointer to the API XML files is incorrect though, it needs to
point into the build tree.
This fixes use of the run script for building libvirt-python, ex:
/path/to/libvirt.git/run ./setup.py build
Signed-off-by: Cole Robinson <crobinso(a)redhat.com>
---
src/libvirt-lxc.pc.in | 2 +-
src/libvirt-qemu.pc.in | 2 +-
src/libvirt.pc.in | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/libvirt-lxc.pc.in b/src/libvirt-lxc.pc.in
index 27e3de4244..9243bcf903 100644
--- a/src/libvirt-lxc.pc.in
+++ b/src/libvirt-lxc.pc.in
@@ -9,7 +9,7 @@ includedir=@abs_top_builddir@/include
source_includedir=@abs_top_srcdir@/include
datarootdir=@abs_top_builddir@
-libvirt_lxc_api=@datadir(a)/docs/libvirt-lxc-api.xml
+libvirt_lxc_api=@abs_top_builddir(a)/docs/libvirt-lxc-api.xml
Name: libvirt
Version: @VERSION@
diff --git a/src/libvirt-qemu.pc.in b/src/libvirt-qemu.pc.in
index 3eb9ad4bc1..a4f9e65c03 100644
--- a/src/libvirt-qemu.pc.in
+++ b/src/libvirt-qemu.pc.in
@@ -9,7 +9,7 @@ includedir=@abs_top_builddir@/include
source_includedir=@abs_top_srcdir@/include
datarootdir=@abs_top_builddir@
-libvirt_qemu_api=@datadir(a)/docs/libvirt-qemu-api.xml
+libvirt_qemu_api=@abs_top_builddir(a)/docs/libvirt-qemu-api.xml
Name: libvirt
Version: @VERSION@
diff --git a/src/libvirt.pc.in b/src/libvirt.pc.in
index 6ff1ce6272..a16e455210 100644
--- a/src/libvirt.pc.in
+++ b/src/libvirt.pc.in
@@ -9,12 +9,12 @@ includedir=@abs_top_builddir@/include
source_includedir=@abs_top_srcdir@/include
datarootdir=@abs_top_builddir@
-libvirt_api=@datadir(a)/docs/libvirt-api.xml
+libvirt_api=@abs_top_builddir(a)/docs/libvirt-api.xml
# For compat with older versions - also present
# in libvirt-qemu.pc / libvirt-lxc.pc
-libvirt_qemu_api=@datadir(a)/docs/libvirt-qemu-api.xml
-libvirt_lxc_api=@datadir(a)/docs/libvirt-lxc-api.xml
+libvirt_qemu_api=@abs_top_builddir(a)/docs/libvirt-qemu-api.xml
+libvirt_lxc_api=@abs_top_builddir(a)/docs/libvirt-lxc-api.xml
Name: libvirt
Version: @VERSION@
--
2.23.0
4 years, 11 months
