[PATCH] libxl: Turn on user aliases
by Michal Privoznik
When I implemented user aliases I've invented this
virDomainDefFeatures flag so that individual drivers can signal
support for user provided aliases. The reasoning was that a
device alias might be part of guest ABI, or used in a different
way then in QEMU. Well, neither applies to the libxl driver, so
it's safe to allow user aliases there.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/231
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/libxl/libxl_domain.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index c91e531a9a..0816c5baa4 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -452,7 +452,8 @@ virDomainDefParserConfig libxlDomainDefParserConfig = {
.domainPostParseCallback = libxlDomainDefPostParse,
.domainValidateCallback = libxlDomainDefValidate,
- .features = VIR_DOMAIN_DEF_FEATURE_FW_AUTOSELECT |
+ .features = VIR_DOMAIN_DEF_FEATURE_USER_ALIAS |
+ VIR_DOMAIN_DEF_FEATURE_FW_AUTOSELECT |
VIR_DOMAIN_DEF_FEATURE_NET_MODEL_STRING,
};
--
2.34.1
2 years, 9 months
[PATCH v5 0/8] Implement detach device related APIs for test driver
by Luke Yue
diff to v4:
- Rebase to current master
diff to v3:
- Add virDomainDeviceDefOperationsCallbacks to xmlopt for de-duplicating purpose
- Add virDomainDeviceTypeFlags for de-duplicating purpose
- Remove the memballoon helper function
- Squash test_driver commits
- Move test device xmls to generichotplugdata
- Reimplement tests with internal APIs
link to v4: https://listman.redhat.com/archives/libvir-list/2021-December/msg00108.html
link to v3: https://listman.redhat.com/archives/libvir-list/2021-November/msg00288.html
link to CI: https://gitlab.com/lukedyue/libvirt/-/pipelines/464756840
Luke Yue (8):
conf: Introduce virDomainInputDefRemove and fix memory leak
conf: Introduce virDomainDeviceDefOperationsCallbacks to xmlopt
conf: Add virDomainDeviceTypeFlags and use it in various drivers
conf: Add tpm helpers for future use
domain_driver: extract DetachXXXDeviceConfig related functions and use
them
test_driver: Implement virDomainDetachDeviceFlags
examples: xml: test: add xml for testing devices related APIs
tests: Add generichotplugtest
examples/xml/test/meson.build | 1 +
examples/xml/test/testdomfc5.xml | 54 ++
examples/xml/test/testnodeinline.xml | 54 ++
src/bhyve/bhyve_domain.c | 2 +-
src/ch/ch_conf.c | 2 +-
src/conf/domain_conf.c | 572 +++++++++++++++++-
src/conf/domain_conf.h | 135 ++++-
src/conf/virconftypes.h | 2 +
src/hyperv/hyperv_driver.c | 3 +-
src/libvirt_private.syms | 21 +
src/libxl/libxl_conf.c | 3 +-
src/libxl/libxl_domain.c | 8 +
src/libxl/libxl_domain.h | 1 +
src/libxl/libxl_driver.c | 73 +--
src/lxc/lxc_conf.c | 3 +-
src/lxc/lxc_domain.c | 7 +
src/lxc/lxc_domain.h | 1 +
src/lxc/lxc_driver.c | 62 +-
src/openvz/openvz_conf.c | 2 +-
src/qemu/qemu_conf.c | 3 +-
src/qemu/qemu_domain.c | 39 ++
src/qemu/qemu_domain.h | 6 +
src/qemu/qemu_driver.c | 206 +------
src/qemu/qemu_process.c | 2 +-
src/security/virt-aa-helper.c | 2 +-
src/test/test_driver.c | 197 +++++-
src/vbox/vbox_common.c | 2 +-
src/vmware/vmware_driver.c | 2 +-
src/vmx/vmx.c | 2 +-
src/vz/vz_driver.c | 2 +-
tests/bhyveargv2xmltest.c | 2 +-
.../generichotplug-controller.xml | 1 +
.../generichotplug-disk-cdrom.xml | 5 +
.../generichotplug-filesystem.xml | 6 +
.../generichotplug-hostdev.xml | 5 +
.../generichotplug-input.xml | 1 +
.../generichotplug-interface.xml | 6 +
.../generichotplug-lease.xml | 5 +
.../generichotplug-memballoon.xml | 3 +
.../generichotplug-memory.xml | 6 +
.../generichotplugdata/generichotplug-rng.xml | 4 +
.../generichotplug-shmem.xml | 4 +
.../generichotplug-sound.xml | 3 +
.../generichotplugdata/generichotplug-tpm.xml | 5 +
.../generichotplug-vsock.xml | 3 +
.../generichotplug-watchdog.xml | 1 +
tests/generichotplugtest.c | 178 ++++++
tests/meson.build | 1 +
tests/testutils.c | 2 +-
49 files changed, 1378 insertions(+), 332 deletions(-)
create mode 100644 tests/generichotplugdata/generichotplug-controller.xml
create mode 100644 tests/generichotplugdata/generichotplug-disk-cdrom.xml
create mode 100644 tests/generichotplugdata/generichotplug-filesystem.xml
create mode 100644 tests/generichotplugdata/generichotplug-hostdev.xml
create mode 100644 tests/generichotplugdata/generichotplug-input.xml
create mode 100644 tests/generichotplugdata/generichotplug-interface.xml
create mode 100644 tests/generichotplugdata/generichotplug-lease.xml
create mode 100644 tests/generichotplugdata/generichotplug-memballoon.xml
create mode 100644 tests/generichotplugdata/generichotplug-memory.xml
create mode 100644 tests/generichotplugdata/generichotplug-rng.xml
create mode 100644 tests/generichotplugdata/generichotplug-shmem.xml
create mode 100644 tests/generichotplugdata/generichotplug-sound.xml
create mode 100644 tests/generichotplugdata/generichotplug-tpm.xml
create mode 100644 tests/generichotplugdata/generichotplug-vsock.xml
create mode 100644 tests/generichotplugdata/generichotplug-watchdog.xml
create mode 100644 tests/generichotplugtest.c
--
2.35.1
2 years, 10 months
[PATCH] libxl: remove redundant variable from libxlDomainJobObj
by Kristina Hanicova
It makes no sense to have 'started' variable in the
libxlDomainJobObj as the same one is already in virDomainJobData,
but never used.
Signed-off-by: Kristina Hanicova <khanicov(a)redhat.com>
---
src/libxl/libxl_domain.c | 10 +++++-----
src/libxl/libxl_domain.h | 1 -
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index ee031267ca..205049f98a 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -118,7 +118,7 @@ libxlDomainObjBeginJob(libxlDriverPrivate *driver G_GNUC_UNUSED,
VIR_DEBUG("Starting job: %s", libxlDomainJobTypeToString(job));
priv->job.active = job;
priv->job.owner = virThreadSelfID();
- priv->job.started = now;
+ priv->job.current->started = now;
priv->job.current->jobType = VIR_DOMAIN_JOB_UNBOUNDED;
return 0;
@@ -171,18 +171,18 @@ libxlDomainJobUpdateTime(struct libxlDomainJobObj *job)
virDomainJobData *jobData = job->current;
unsigned long long now;
- if (!job->started)
+ if (!jobData->started)
return 0;
if (virTimeMillisNow(&now) < 0)
return -1;
- if (now < job->started) {
- job->started = 0;
+ if (now < jobData->started) {
+ jobData->started = 0;
return 0;
}
- jobData->timeElapsed = now - job->started;
+ jobData->timeElapsed = now - jobData->started;
return 0;
}
diff --git a/src/libxl/libxl_domain.h b/src/libxl/libxl_domain.h
index 475e4a6933..157f480b93 100644
--- a/src/libxl/libxl_domain.h
+++ b/src/libxl/libxl_domain.h
@@ -46,7 +46,6 @@ struct libxlDomainJobObj {
virCond cond; /* Use to coordinate jobs */
enum libxlDomainJob active; /* Currently running job */
int owner; /* Thread which set current job */
- unsigned long long started; /* When the job started */
virDomainJobData *current; /* Statistics for the current job */
};
--
2.35.1
2 years, 10 months
[libvirt PATCH 0/5] nwfilter: fix deadlock with binding create/delete
by Daniel P. Berrangé
Historically the nwfilter driver didn't keep track of any
instances of filters. When it needed to rebuild filters it
called back to the virt drivers to ask them to re-create
the filters for their VMs. This lead to some complex locking
requirements where the virt driver needed to acquire locks
on the nwfilter driver before creating/deleting filter
instances.
Somewhat recently we introduced the virNWFilterBinding
concept which allowed the nwfilter driver to keep track of
all filter instances aka bindings. Thus it could rebuild
them without talking to the virt drivers. We never updated
the locking model when doing this though, so we were still
reliant on the virt drivers acquiring locks before creating
or deleting virNWFilterBinding objects.
When we started using the modular daemons though, the locks
acquired by the virt drivers no longer protected the nwfilter
driver as they were separate processes. Thus the race condition
fixed back in
commit 6e5c79a1b5a8b3a23e7df7ffe58fb272aa17fbfb
Author: Daniel P. Berrangé <berrange(a)redhat.com>
Date: Wed Jan 22 17:28:29 2014 +0000
Push nwfilter update locking up to top level
has now re-appeared when running modular daemons. In fact
it is possible to trigger it even in libvirtd if you ignore
the virt drivers and directly call the virNWFilterBinding
APIs, though that won't hit users in practice.
The solution is surprisingly simple. Since the nwfilter
driver keeps track of virNWFilterBinding objects, we
can simply put locking calls around the Create/Delete
methods for those objects, and remove the locking from
the virt drivers.
The only slight difference is that previous the locking
serialized the entire VM startup/shutdown sequence, while
the new locking only serializes individual NICs. This
should not matter in practice, since there's no shared
state between filters for NICs on the same VM.
This is a minimal fix suitable for the freeze. There is
scope for some significant improvements in locking which
I'm still working on. In particular we currently have a
terrible writer starvation problem with the RWLock that
protects the filter create/delete/redefine operations
that has existed forever. Repeatedly creating/deleting
virNWFilterBinding objects can prevent a virNWFilterDefineXML
call from ever running.
Daniel P. Berrangé (5):
nwfilter: stop using recursive mutex for IP learning
nwfilter: hold filter update lock when creating/deleting bindings
qemu,lxc: remove use to nwfilter update lock
nwfilter: remove decl of virNWFilterCreateVarHashmap
nwfilter: make some gentech driver methods static
src/lxc/lxc_driver.c | 6 ------
src/nwfilter/nwfilter_driver.c | 5 +++++
src/nwfilter/nwfilter_gentech_driver.c | 4 ++--
src/nwfilter/nwfilter_gentech_driver.h | 8 --------
src/nwfilter/nwfilter_learnipaddr.c | 2 +-
src/qemu/qemu_driver.c | 18 ------------------
src/qemu/qemu_migration.c | 3 ---
src/qemu/qemu_process.c | 4 ----
8 files changed, 8 insertions(+), 42 deletions(-)
--
2.35.1
2 years, 10 months
Libvirt Rust bindings could use some work
by Wim de With
Hello,
I was reading the Rust bindings for libvirt and I noticed that they are
not very idiomatic. A couple of examples:
1. It is conventional to have a *-sys crate containing only the C
interface and the linking configuration. The virt crate would then
depend on this libvirt-sys crate to implement a safe and ergonomic
wrapper.
2. The API heavily uses integers to indicate flags. Sometimes those
integers are type aliased and sometimes they are not. In Rust, this can
be much nicer, using enums to represent only valid flags. The same
applies to some return values.
3. Since libvirt is thread-safe, the Rust types could be Send and Sync,
so that they can also be used in a multithreaded context. Special care
needs to be taken with translating virGetLastError to Rust Results, but
it shouldn't be a problem.
For a nice example of a Rust wrapper around a C library, see:
https://github.com/rust-lang/git2-rs
I am willing to send some patches to fix some of these problems, but
this will almost certainly lead to breaking API changes, and I am not
sure what your opinion is on that.
Finally, while I am not a legal expert, I believe that licensing a Rust
library as LGPL does not make much sense. Rust does not have a stable
ABI so everything is statically linked. This means that adding virt to a
Cargo.toml file of a non-GPL application is already in violation of the
license.
Thanks,
Wim
2 years, 10 months
[PATCH v3 00/11] blockdev-replace
by Vladimir Sementsov-Ogievskiy
Hi all!
Finally, that's a proposal for new interface for filter insertion, which
provides generic way for inserting between different block graph nodes,
like BDS nodes, block exports and block devices.
v3: - add transaction support
- add test, that shows transactional filter insertion in different
cases
- drop RFC mark. I think it's now close to be a good solution. And
anyway, no comments on "RFC v2" version :) Still, I want to keep
x- prefix for now, just because there were too many different
ideas on this topic.
Vladimir Sementsov-Ogievskiy (11):
block-backend: blk_root(): drop const specifier on return type
block/export: add blk_by_export_id()
block: make bdrv_find_child() function public
block: bdrv_replace_child_bs(): move to external transaction
qapi: add x-blockdev-replace command
qapi: add x-blockdev-replace transaction action
block: bdrv_get_xdbg_block_graph(): report export ids
iotests.py: qemu_img_create: use imgfmt by default
iotests.py: introduce VM.assert_edges_list() method
iotests.py: add VM.qmp_check() helper
iotests: add filter-insertion
qapi/block-core.json | 62 +++++
qapi/transaction.json | 14 +-
include/block/block.h | 2 +-
include/block/block_int.h | 1 +
include/block/export.h | 1 +
include/sysemu/block-backend.h | 3 +-
block.c | 59 ++--
block/block-backend.c | 10 +-
block/export/export.c | 31 +++
blockdev.c | 113 +++++++-
stubs/blk-by-qdev-id.c | 9 +
stubs/blk-exp-find-by-blk.c | 9 +
stubs/meson.build | 2 +
tests/qemu-iotests/iotests.py | 23 ++
tests/qemu-iotests/tests/filter-insertion | 253 ++++++++++++++++++
tests/qemu-iotests/tests/filter-insertion.out | 5 +
16 files changed, 563 insertions(+), 34 deletions(-)
create mode 100644 stubs/blk-by-qdev-id.c
create mode 100644 stubs/blk-exp-find-by-blk.c
create mode 100755 tests/qemu-iotests/tests/filter-insertion
create mode 100644 tests/qemu-iotests/tests/filter-insertion.out
--
2.31.1
2 years, 10 months
GSoC 2022 CI project idea proposal
by Erik Skultety
So, we're offloading as much CI configuration/workflow stuff to lcitool
as possible. We can generate config files, install/update machines
(local or remote), dump Dockerfiles...we can't build and run those containers
locally. Instead, we have a CI helper script in libvirt repo which essentially
just wraps a Makefile which pulls a gitlab container for you and:
- gives you shell, or
- runs the build and tests
I'm not sure how many people actually know we have that helper script let alone
use it. I've been playing with the idea that we could integrate what's done in
the Makefile to lcitool utilizing either the podman library [1] or the docker
library [2]. Apart from consolidating all CI services-related efforts to
lcitool the other benefit would be that we could gain the ability to run and
debug in a project-specific container also in other libvirt projects not just
main libvirt.
So, I though this could be a nice project for GSoC. Ideas?
Unless there are arguments against this idea then I'd eventually add the idea
to our gitlab GSoC issue tracker.
[1] https://github.com/containers/podman-py
[2] https://docker-py.readthedocs.io/en/stable/
Erik
2 years, 10 months
Re: REST service for libvirt to simplify SEV(ES) launch measurement
by Dewey, Larry
[AMD Official Use Only]
I definitely agree that adding functionality to simplify, and hopefully unify, the attestation workflow for confidential containers would be extremely helpful, and would be very interested in being an integral part of the process. I have my own opinions about using a REST service instead of others due to potential maintenance overhead and lack of contract rule enforcement, but there are definitely pros and cons to all of the current protocols. I am excited to see where this goes.
2 years, 10 months
Entering freeze for libvirt-8.1.0
by Jiri Denemark
I have just tagged v8.1.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make sure the issue is more visible.
If you have not done so yet, please update NEWS.rst to document any
significant change you made since the last release.
Thanks,
Jirka
2 years, 10 months
GSoC 2022 introduction
by Moteen Shah
Hello,
This is Moteen Shah,
I have completed the build of the project and also read the
contribution.html <https://libvirt.org/contribute.html>,
I am still trying to figure out the issues I can work on, it would be
really helpful if you can give some advice on good first issues to work
with.
Regards,
Moteen
2 years, 10 months
