[PATCH 0/5] qemu: Allow snapshots and blockcopy of read-only disks
by Peter Krempa
First one doesn't make much sense but oVirt used it before, so we should
allow it now as well. Block copy makes sense and thus should be fixed
either way.
Last patch is for actually validating that it works.
Peter Krempa (5):
storage_file: create: Create new images with write permission bit
qemuBlockStorageSourceCreateFormat: Force write access when formatting
images
qemu: snapshot: Allow snapshots of read-only disks when we can create
them
qemu: blockcopy: Allow copy of read-only disks with -blockdev
HACK: qemu: caps: enable blockdev reopen
src/qemu/qemu_block.c | 12 ++++++++++++
src/qemu/qemu_blockjob.c | 5 +++++
src/qemu/qemu_capabilities.c | 1 +
src/qemu/qemu_driver.c | 11 ++++++++++-
src/qemu/qemu_monitor_json.c | 2 +-
src/storage/storage_file_fs.c | 6 +-----
src/storage/storage_file_gluster.c | 6 +-----
tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml | 1 +
tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml | 1 +
tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 +
23 files changed, 47 insertions(+), 12 deletions(-)
--
2.26.2
4 years, 6 months
[libvirt-ci PATCH 00/12] Introduce a new global YAML config file for lcitool
by Erik Skultety
This series is trying to consolidate the number of config files we currently
recognize under ~/.config/lcitool to a single global YAML config file. Thanks
to this effort we can expose more seetings than we previously could which will
come handy in terms of generating cloudinit images for OpenStack.
Patches 1-4 patches are just a little extra - not heavily related to the series
Patches 1-3 (ACKed) only cosmetical changes (like moving requirements.txt)
Since RFC:
- replaced TOML with YAML which simplified some aspects of the code, thanks
Andrea
- instead of hardcoding the default values, the config within the repo is used
as a template and overriden with user-selected options
Erik Skultety (12):
requirements: Introduce a requirements.txt file
lcitool: Decrease the indent when creating a tempdir for initrd
injection
lcitool: Prefer tempfile's native wrappers over low level primitives
lcitool: Use a temporary JSON file to pass extra variables
config: Introduce a new global config.yaml configuration file
lcitool: Introduce methods to load and validate the YAML config
lcitool: Update the config values with internal playbook settings
lcitool: Drop the get_flavor() method
lcitool: Drop the get_root_password_file() method
lcitool: Drop the gitlab-related getter methods
config: Move the virt-install settings from install.yml to the config
guests: README: Document the existence and usage of config.toml
guests/README.markdown | 18 +-
guests/config.yaml | 40 +++++
guests/lcitool | 192 +++++++++-------------
guests/playbooks/build/main.yml | 2 +-
guests/playbooks/update/main.yml | 6 +-
guests/playbooks/update/tasks/gitlab.yml | 4 +-
guests/playbooks/update/tasks/kludges.yml | 2 +-
guests/playbooks/update/tasks/users.yml | 42 ++---
guests/requirements.txt | 2 +
9 files changed, 159 insertions(+), 149 deletions(-)
create mode 100644 guests/config.yaml
create mode 100644 guests/requirements.txt
--
2.25.3
4 years, 6 months
[libvirt-ci PATCH] lcitool: Catch exceptions earlier
by Andrea Bolognani
Right now we catch and report properly only those exceptions that
are raised by the Application.run() method: basically, we work
under the assumption that nothing before that point can possibly
fail.
That's of course unrealistic: even now, creating an Inventory or
Projects object can raise an exception, in which case we simply
display a stack trace instead of a reasonable error message.
This commit introduces a CommandLine class which takes over
command line handling from the Application class, and moves all
exception handling to the main() method so that, short of
something going horribly wrong while parsing the command line,
we will always manage to hide stack traces from the user.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
guests/lcitool | 56 ++++++++++++++++++++++++++++----------------------
1 file changed, 32 insertions(+), 24 deletions(-)
diff --git a/guests/lcitool b/guests/lcitool
index ab3b95f..ff58829 100755
--- a/guests/lcitool
+++ b/guests/lcitool
@@ -390,15 +390,9 @@ class Projects:
return self._packages[project]
-class Application:
+class CommandLine:
def __init__(self):
- self._config = Config()
- self._inventory = Inventory()
- self._projects = Projects()
-
- self._native_arch = Util.get_native_arch()
-
self._parser = argparse.ArgumentParser(
conflict_handler="resolve",
description="libvirt CI guest management tool",
@@ -444,14 +438,14 @@ class Application:
installparser = subparsers.add_parser(
"install", help="perform unattended host installation")
- installparser.set_defaults(func=self._action_install)
+ installparser.set_defaults(action="install")
add_hosts_arg(installparser)
add_wait_arg(installparser)
updateparser = subparsers.add_parser(
"update", help="prepare hosts and keep them updated")
- updateparser.set_defaults(func=self._action_update)
+ updateparser.set_defaults(action="update")
add_hosts_arg(updateparser)
add_projects_arg(updateparser)
@@ -459,7 +453,7 @@ class Application:
buildparser = subparsers.add_parser(
"build", help="build projects on hosts")
- buildparser.set_defaults(func=self._action_build)
+ buildparser.set_defaults(action="build")
add_hosts_arg(buildparser)
add_projects_arg(buildparser)
@@ -467,20 +461,33 @@ class Application:
hostsparser = subparsers.add_parser(
"hosts", help="list all known hosts")
- hostsparser.set_defaults(func=self._action_hosts)
+ hostsparser.set_defaults(action="hosts")
projectsparser = subparsers.add_parser(
"projects", help="list all known projects")
- projectsparser.set_defaults(func=self._action_projects)
+ projectsparser.set_defaults(action="projects")
dockerfileparser = subparsers.add_parser(
"dockerfile", help="generate Dockerfile (doesn't access the host)")
- dockerfileparser.set_defaults(func=self._action_dockerfile)
+ dockerfileparser.set_defaults(action="dockerfile")
add_hosts_arg(dockerfileparser)
add_projects_arg(dockerfileparser)
add_cross_arch_arg(dockerfileparser)
+ def parse(self):
+ return self._parser.parse_args()
+
+
+class Application:
+
+ def __init__(self):
+ self._config = Config()
+ self._inventory = Inventory()
+ self._projects = Projects()
+
+ self._native_arch = Util.get_native_arch()
+
def _execute_playbook(self, playbook, hosts, projects, git_revision):
base = Util.get_base()
@@ -1011,17 +1018,18 @@ class Application:
varmap = self._dockerfile_build_varmap(facts, mappings, pip_mappings, projects, cross_arch)
self._dockerfile_format(facts, cross_arch, varmap)
- def run(self):
- args = self._parser.parse_args()
- if args.debug:
- args.func(args)
- else:
- try:
- args.func(args)
- except Exception as err:
- sys.stderr.write("{}: {}\n".format(sys.argv[0], err))
- sys.exit(1)
+ def run(self, args):
+ getattr(self, "_action_" + args.action)(args)
if __name__ == "__main__":
- Application().run()
+ args = CommandLine().parse()
+
+ if args.debug:
+ Application().run(args)
+ else:
+ try:
+ Application().run(args)
+ except Exception as err:
+ sys.stderr.write("{}: {}\n".format(sys.argv[0], err))
+ sys.exit(1)
--
2.25.4
4 years, 6 months
[libvirt PATCH v2 0/3] docs: Some reStructuredText tweaks
by Andrea Bolognani
Changes from [v1]:
* convert simple tables to definition lists;
* drop glib-adoption.rst entirely instead of tweaking it.
[v1] https://www.redhat.com/archives/libvir-list/2020-May/msg00292.html
Andrea Bolognani (3):
docs: Drop glib-adoption.rst
docs: Use definition list instead of table in coding style
docs: Document list-tables as recommended
docs/coding-style.rst | 47 ++++++++++++---------
docs/glib-adoption.rst | 96 ------------------------------------------
docs/hacking.rst | 1 -
docs/styleguide.rst | 20 +++++++++
4 files changed, 46 insertions(+), 118 deletions(-)
delete mode 100644 docs/glib-adoption.rst
--
2.25.4
4 years, 6 months
[PATCH] virDevMapperGetTargetsImpl: quit early if device is not a devmapper target
by Michal Privoznik
As suggested in the linked bug, libvirt should firstly check
whether the major number of the device is device mapper major.
Because if it isn't subsequent DM_DEVICE_DEPS task may not only
fail, but also yield different results. In the bugzilla this is
demonstrated by creating a devmapper target named 'loop0' and
then creating loop target /dev/loop0. When the latter is then
passed to a domain, our virDevMapperGetTargetsImpl() function
blindly asks devmapper to provide target dependencies for
/dev/loop0 and because of the way devmapper APIs work, it will
'sanitize' the input by using the last component only which is
'loop0' and thus return different results than expected.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1823976
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/util/virdevmapper.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/src/util/virdevmapper.c b/src/util/virdevmapper.c
index feb5982315..ee026d502e 100644
--- a/src/util/virdevmapper.c
+++ b/src/util/virdevmapper.c
@@ -64,6 +64,7 @@ virDevMapperGetTargetsImpl(const char *path,
char ***devPaths_ret,
unsigned int ttl)
{
+ struct stat sb;
struct dm_task *dmt = NULL;
struct dm_deps *deps;
struct dm_info info;
@@ -82,6 +83,15 @@ virDevMapperGetTargetsImpl(const char *path,
return ret;
}
+ if (stat(path, &sb) < 0) {
+ if (errno == ENOENT)
+ ret = 0;
+ return ret;
+ }
+
+ if (!dm_is_dm_major(major(sb.st_dev)))
+ return 0;
+
if (!(dmt = dm_task_create(DM_DEVICE_DEPS))) {
if (errno == ENOENT || errno == ENODEV) {
/* It's okay. Kernel is probably built without
--
2.26.2
4 years, 6 months
[libvirt-ci PATCH] lcitool: Set make parallelism dynamically
by Andrea Bolognani
We're about to make some changes to lcitool that would make it
more annoying to get access to the number of install-time vCPUs
from 'lcitool update', so let's use getconf instead.
As a side effect, this also copes better with the situation where
the builder was installed with a certain number of vCPUs but the
amount has since been modified.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
guests/playbooks/update/templates/bashrc.j2 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/guests/playbooks/update/templates/bashrc.j2 b/guests/playbooks/update/templates/bashrc.j2
index 8775864..05a86a1 100644
--- a/guests/playbooks/update/templates/bashrc.j2
+++ b/guests/playbooks/update/templates/bashrc.j2
@@ -4,7 +4,7 @@ export MAKE="{{ paths.make }}"
export NINJA="{{ paths.ninja }}"
export PYTHON="{{ paths.python }}"
-export MAKEFLAGS="-j{{ install_vcpus|int + 1 }}"
+export MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)"
export CCACHE_MAXSIZE="2G"
export VIRT_PREFIX="$HOME/build/libvirt"
--
2.25.4
4 years, 6 months
[libvirt PATCH v2] docs: introduce a page showing a overall CI dashboard
by Daniel P. Berrangé
With the move to GitLab CI one of the things we miss from Jenkins is a
single page dashboard showing CI status across all projects. This is a
very simple replacement that uses badges for CI pipeline status.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
docs/ci.rst | 230 ++++++++++++++++++++++++++++++++++++++++++++++
docs/docs.html.in | 3 +
docs/libvirt.css | 5 +
3 files changed, 238 insertions(+)
create mode 100644 docs/ci.rst
diff --git a/docs/ci.rst b/docs/ci.rst
new file mode 100644
index 0000000000..fe59b98923
--- /dev/null
+++ b/docs/ci.rst
@@ -0,0 +1,230 @@
+==============================
+Libvirt Continuous Integration
+==============================
+
+.. contents::
+
+The libvirt project primarily uses GitLab CI for automated testing of Linux
+builds, and cross-compiled Windows builds. `Travis <https://travis-ci.org/libvirt/libvirt>`_
+is used for validating macOS builds, and `Jenkins <https://ci.centos.org/view/libvirt>`_
+is temporarily used for validating FreeBSD builds.
+
+GitLab CI Dashboard
+===================
+
+The dashboard below shows the current status of the GitLab CI jobs for each
+repository:
+
+Core project
+------------
+
+.. list-table::
+ :widths: 80 20
+ :header-rows: 1
+
+ * - Project
+ - Pipeline
+
+ * - libvirt
+ - .. image:: https://gitlab.com/libvirt/libvirt/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt/pipelines
+ :alt: libvirt pipeline status
+
+
+Language bindings
+-----------------
+
+.. list-table::
+ :widths: 80 20
+ :header-rows: 1
+
+ * - Project
+ - Pipeline
+
+ * - libvirt-csharp
+ - .. image:: https://gitlab.com/libvirt/libvirt-csharp/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-csharp/pipelines
+ :alt: libvirt-csharp pipeline status
+
+ * - libvirt-go
+ - .. image:: https://gitlab.com/libvirt/libvirt-go/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-go/pipelines
+ :alt: libvirt-go pipeline status
+
+ * - libvirt-java
+ - .. image:: https://gitlab.com/libvirt/libvirt-java/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-java/pipelines
+ :alt: libvirt-java pipeline status
+
+ * - libvirt-ocaml
+ - .. image:: https://gitlab.com/libvirt/libvirt-ocaml/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-ocaml/pipelines
+ :alt: libvirt-ocaml pipeline status
+
+ * - libvirt-perl
+ - .. image:: https://gitlab.com/libvirt/libvirt-perl/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-perl/pipelines
+ :alt: libvirt-perl pipeline status
+
+ * - libvirt-php
+ - .. image:: https://gitlab.com/libvirt/libvirt-php/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-php/pipelines
+ :alt: libvirt-php pipeline status
+
+ * - libvirt-python
+ - .. image:: https://gitlab.com/libvirt/libvirt-python/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-python/pipelines
+ :alt: libvirt-python pipeline status
+
+ * - libvirt-rust
+ - .. image:: https://gitlab.com/libvirt/libvirt-rust/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-rust/pipelines
+ :alt: libvirt-rust pipeline status
+
+ * - ruby-libvirt
+ - .. image:: https://gitlab.com/libvirt/ruby-libvirt/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/ruby-libvirt/pipelines
+ :alt: ruby-libvirt pipeline status
+
+
+Object mappings
+---------------
+
+.. list-table::
+ :widths: 80 20
+ :header-rows: 1
+
+ * - Project
+ - Pipeline
+
+ * - libvirt-cim
+ - .. image:: https://gitlab.com/libvirt/libvirt-cim/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-cim/pipelines
+ :alt: libvirt-cim pipeline status
+
+ * - libvirt-dbus
+ - .. image:: https://gitlab.com/libvirt/libvirt-dbus/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-dbus/pipelines
+ :alt: libvirt-dbus pipeline status
+
+ * - libvirt-glib
+ - .. image:: https://gitlab.com/libvirt/libvirt-glib/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-glib/pipelines
+ :alt: libvirt-glib pipeline status
+
+ * - libvirt-go-xml
+ - .. image:: https://gitlab.com/libvirt/libvirt-go-xml/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-go-xml/pipelines
+ :alt: libvirt-go-xml pipeline status
+
+ * - libvirt-snmp
+ - .. image:: https://gitlab.com/libvirt/libvirt-snmp/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-snmp/pipelines
+ :alt: libvirt-snmp pipeline status
+
+
+Testing
+-------
+
+.. list-table::
+ :widths: 80 20
+ :header-rows: 1
+
+ * - Project
+ - Pipeline
+
+ * - libvirt-ci
+ - .. image:: https://gitlab.com/libvirt/libvirt-ci/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-ci/pipelines
+ :alt: libvirt-ci pipeline status
+
+ * - libvirt-dockerfiles
+ - .. image:: https://gitlab.com/libvirt/libvirt-dockerfiles/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-dockerfiles/pipelines
+ :alt: libvirt-dockerfiles pipeline status
+
+ * - libvirt-test-API
+ - .. image:: https://gitlab.com/libvirt/libvirt-test-API/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-test-API/pipelines
+ :alt: libvirt-test-API pipeline status
+
+ * - libvirt-tck
+ - .. image:: https://gitlab.com/libvirt/libvirt-tck/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-tck/pipelines
+ :alt: libvirt-tck pipeline status
+
+
+Documentation / websites
+------------------------
+
+.. list-table::
+ :widths: 80 20
+ :header-rows: 1
+
+ * - Project
+ - Pipeline
+ * - libvirt-publican
+ - .. image:: https://gitlab.com/libvirt/libvirt-publican/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-publican/pipelines
+ :alt: libvirt-publican pipeline status
+
+ * - libvirt-appdev-guide-python
+ - .. image:: https://gitlab.com/libvirt/libvirt-appdev-guide-python/badges/master/pipe...
+ :target: https://gitlab.com/libvirt/libvirt-appdev-guide-python/pipelines
+ :alt: libvirt-appdev-guide-python pipeline status
+
+ * - libvirt-wiki
+ - .. image:: https://gitlab.com/libvirt/libvirt-wiki/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-wiki/pipelines
+ :alt: libvirt-wiki pipeline status
+
+ * - virttools-planet
+ - .. image:: https://gitlab.com/libvirt/virttools-planet/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/virttools-planet/pipelines
+ :alt: virttools-planet pipeline status
+
+ * - virttools-web
+ - .. image:: https://gitlab.com/libvirt/virttools-web/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/virttools-web/pipelines
+ :alt: virttools-web pipeline status
+
+
+Miscellaneous
+-------------
+
+.. list-table::
+ :widths: 80 20
+ :header-rows: 1
+
+ * - Project
+ - Pipeline
+
+ * - libvirt-console-proxy
+ - .. image:: https://gitlab.com/libvirt/libvirt-console-proxy/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-console-proxy/pipelines
+ :alt: libvirt-console-proxy pipeline status
+
+ * - libvirt-designer
+ - .. image:: https://gitlab.com/libvirt/libvirt-designer/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-designer/pipelines
+ :alt: libvirt-designer pipeline status
+
+ * - libvirt-devaddr
+ - .. image:: https://gitlab.com/libvirt/libvirt-devaddr/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-devaddr/pipelines
+ :alt: libvirt-devaddr pipeline status
+
+ * - libvirt-sandbox
+ - .. image:: https://gitlab.com/libvirt/libvirt-sandbox/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-sandbox/pipelines
+ :alt: libvirt-sandbox pipeline status
+
+ * - libvirt-sandbox-image
+ - .. image:: https://gitlab.com/libvirt/libvirt-sandbox-image/badges/master/pipeline.svg
+ :target: https://gitlab.com/libvirt/libvirt-sandbox-image/pipelines
+ :alt: libvirt-sandbox-image pipeline status
+
+ * - libvirt-security-notice
+ - .. image:: https://gitlab.com/libvirt/libvirt-security-notice/badges/master/pipeline...
+ :target: https://gitlab.com/libvirt/libvirt-security-notice/pipelines
+ :alt: libvirt-security-notice pipeline status
diff --git a/docs/docs.html.in b/docs/docs.html.in
index 6bdf0c32b8..f1d44fadc0 100644
--- a/docs/docs.html.in
+++ b/docs/docs.html.in
@@ -142,6 +142,9 @@
<dt><a href="strategy.html">Project strategy</a></dt>
<dd>Sets a vision for future direction & technical choices</dd>
+ <dt><a href="ci.html">CI Testing</a></dt>
+ <dd>Details of the Continuous Integration testing strategy</dd>
+
<dt><a href="bugs.html">Bug reports</a></dt>
<dd>How and where to report bugs and request features</dd>
diff --git a/docs/libvirt.css b/docs/libvirt.css
index 94d0b9058c..a2c9778e03 100644
--- a/docs/libvirt.css
+++ b/docs/libvirt.css
@@ -592,3 +592,8 @@ td.gitmirror {
td.gitmirror a {
color: inherit;
}
+
+th p, td p {
+ margin-top: 0px;
+ margin-bottom: 0px;
+}
--
2.26.2
4 years, 6 months
[PATCH] qemuDomainCleanupRun: Actually run cleanup callbacks in reverse order
by Michal Privoznik
We have a framework to register cleanup callbacks that are run
when a domain is shut down. The idea is to run callbacks in
reverse order than they were registered. However, looking at the
code this is not the case. Fortunately, this framework is used to
register a single callback and a single callback only -
qemuMigrationDstPrepareCleanup() - therefore there was no problem
just yet.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_domain.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 9c629c31a3..7c71b797bc 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -8032,18 +8032,14 @@ qemuDomainCleanupRun(virQEMUDriverPtr driver,
virDomainObjPtr vm)
{
qemuDomainObjPrivatePtr priv = vm->privateData;
- size_t i;
VIR_DEBUG("driver=%p, vm=%s", driver, vm->def->name);
/* run cleanup callbacks in reverse order */
- for (i = 0; i < priv->ncleanupCallbacks; i++) {
- if (priv->cleanupCallbacks[priv->ncleanupCallbacks - (i + 1)])
- priv->cleanupCallbacks[i](driver, vm);
- }
+ while (priv->ncleanupCallbacks)
+ priv->cleanupCallbacks[--priv->ncleanupCallbacks](driver, vm);
VIR_FREE(priv->cleanupCallbacks);
- priv->ncleanupCallbacks = 0;
priv->ncleanupCallbacks_max = 0;
}
--
2.26.2
4 years, 6 months
device hotplug & file handles
by Gerd Hoffmann
Hi,
For usb device pass-through (aka -device usb-host) it would be very
useful to pass file handles from libvirt to qemu. The workflow would
change from ...
(1) libvirt enables access to /dev/usb/$bus/$dev
(2) libvirt passes $bus + $dev (using hostbus + hostaddr properties)
to qemu.
(3) qemu opens /dev/usb/$bus/$dev
... to ...
(1) libvirt opens /dev/usb/$bus/$dev
(2) libvirt passes filehandle to qemu.
Question is how can we pass the file descriptor best? My idea would be
to simply add an fd property to usb-host:
* Coldplug would be "-device usb-host,fd=<nr>" (cmd line).
* Hotplug would be "device_add usb-host,fd=<getfd-name>" (monitor).
Will that work from libvirt point of view?
Or does anyone have an better idea?
thanks,
Gerd
PS: background: https://bugzilla.redhat.com/show_bug.cgi?id=1595525
4 years, 6 months
[libvirt PATCH 0/2] network: force re-creation of iptables private chains on firewalld restart
by Laine Stump
Details are in the commit log of patch 2. Essentially, we've been
careful to only create the iptables chains once per run, because it's
very expensive, but when firewalld is restarted, it removes our
chains, so we need to put them back.
I think this may have been a problem as far back as libvirt 5.1.0,
when we began putting our iptables rules into private chains.
Laine Stump (2):
network: make it safe to call networkSetupPrivateChains() multiple
times
network: force re-creation of iptables private chains on firewalld
restart
src/network/bridge_driver.c | 16 +++---
src/network/bridge_driver_linux.c | 77 ++++++++++++++++++----------
src/network/bridge_driver_nop.c | 3 +-
src/network/bridge_driver_platform.h | 2 +-
4 files changed, 62 insertions(+), 36 deletions(-)
--
2.25.4
4 years, 6 months
