[PATCH] qemu: migration: Don't use empty string for 'tls-hostname' NBD blockdev
by Peter Krempa
While QEMU accepts and interprets an empty string in the tls-hostname
field in migration parametes as if it's unset, the same does not apply
for the 'tls-hostname' field when 'blockdev-add'-ing a NBD backend for
non-shared storage migration.
When libvirt sets up migation with TLS in 'qemuMigrationParamsEnableTLS'
the QEMU_MIGRATION_PARAM_TLS_HOSTNAME migration parameter will be set to
empty string in case when the 'hostname' argument is passed as NULL.
Later on when setting up the NBD connections for non-shared storage
migration 'qemuMigrationParamsGetTLSHostname', which fetches the value
of the aforementioned TLS parameter.
This bug was mostly latent until recently as libvirt used
MIGRATION_DEST_CONNECT_HOST mode in most cases which required the
hostname to be passed, thus the parameter was set properly.
This changed with 8d693d79c40 for post-copy migration, where libvirt now
instructs qemu to connect and thus passes NULL hostname to
qemuMigrationParamsEnableTLS, which in turn causes libvirt to try to
add NBD connection with empty string as tls-hostname resulting in:
error: internal error: unable to execute QEMU command 'blockdev-add': Certificate does not match the hostname
To address this modify 'qemuMigrationParamsGetTLSHostname' to undo the
weird semantics the migration code uses to handle TLS hostname and make
it return NULL if the hostname is an empty string.
Fixes: e8fa09d66bc
Resolves: https://issues.redhat.com/browse/RHEL-32880
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/qemu/qemu_migration_params.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_migration_params.c b/src/qemu/qemu_migration_params.c
index e955822f68..48f8657f71 100644
--- a/src/qemu/qemu_migration_params.c
+++ b/src/qemu/qemu_migration_params.c
@@ -1158,6 +1158,7 @@ qemuMigrationParamsEnableTLS(virQEMUDriver *driver,
*tlsAlias) < 0)
return -1;
+ /* QEMU interprets an empty string for hostname as if it is not populated */
if (!migParams->params[QEMU_MIGRATION_PARAM_TLS_HOSTNAME].set &&
qemuMigrationParamsSetString(migParams,
QEMU_MIGRATION_PARAM_TLS_HOSTNAME,
@@ -1659,13 +1660,23 @@ qemuMigrationCapsGet(virDomainObj *vm,
* @migParams: Migration params object
*
* Fetches the value of the QEMU_MIGRATION_PARAM_TLS_HOSTNAME parameter which is
- * passed from the user as VIR_MIGRATE_PARAM_TLS_DESTINATION
+ * passed from the user as VIR_MIGRATE_PARAM_TLS_DESTINATION.
+ *
+ * In contrast with the migration parameter semantics, where an empty string
+ * is considered as if the hostname was not provided, this function will return
+ * NULL instead of an empty string as other parts of QEMU expect that the
+ * hostname is not provided at all.
*/
const char *
qemuMigrationParamsGetTLSHostname(qemuMigrationParams *migParams)
{
+ const char *hostname = migParams->params[QEMU_MIGRATION_PARAM_TLS_HOSTNAME].value.s;
+
if (!migParams->params[QEMU_MIGRATION_PARAM_TLS_HOSTNAME].set)
return NULL;
- return migParams->params[QEMU_MIGRATION_PARAM_TLS_HOSTNAME].value.s;
+ if (STREQ(hostname, ""))
+ return NULL;
+
+ return hostname;
}
--
2.44.0
3 weeks, 4 days
[PATCH v2 00/20] node_dev_udev: use workerpool and improve nodedev events
by Marc Hartmayer
When an udev event occurs for a mediated device (mdev) the mdev config data
requires an update via mdevctl as the udev event does not contain all config
data. This update needs to occur immediately and to be finished before the
libvirt nodedev event is issued to keep the API usage reliable.
Changelog:
v1->v2:
+ squashed old patches 3 and 17 (comments from Jonathon and Boris)
+ added r-b's from Jonathon and Boris
+ worked in comments from Jonathon to old patch 15
+ added comment why only one worker can currently be used
+ added patch `node_device_udev: remove incorrect G_GNUC_UNUSED`
RFCv1->v1:
+ removed some of my own s-o-b's that were accidentally inserted in the RFC
+ added r-b's from Boris and Jonathon
+ worked in comments from Boris and Jonathon, but I did not inline
"nodeDeviceDefResetMdevActiveConfig" as I'm not sure whether this improves
the readability
+ reworked patch "[RFC PATCH v1 11/15] node_device_udev: Use
`stateShutdownPrepare` and `stateShutdownWait`"
+ reworked patch "node_device_udev: Use a worker pool for processing events and
emitting nodedev event"
+ added patches:
- node_device_udev: Move responsibility to release `(init|udev)Thread` to `udevEventDataDispose`
- node_device_udev: Fix leak of mdevctlLock, udevThreadCond, and mdevCtlMonitor
- node_device_udev: nodeStateShutdownPrepare: Disconnect the signals explicitly
- node_device_udev: Pass the driver state as parameter in prepartion for the next commit
- node_device_udev: Add support for `g_autoptr` to `udevEventData
- node_device_udev: Pass the `udevEventData` via parameter and use refcounting
Boris Fiuczynski (3):
nodedev: fix mdev add udev event data handling
nodedev: immediate update of active config on udev events
nodedev: reset active config data on udev remove event
Marc Hartmayer (17):
node_device_udev: Set @def to NULL
node_device_udev: Remove the timeout if the data is disposed
node_device_udev: Test for mdevctlTimeout != -1
node_device_udev: Don't take `mdevctlLock` for `mdevctl list` and add
comments about locking
node_device_udev: Take lock if `driver->privateData` is modified
node_device_udev: Add prefix `udev` for udev related data
node_device_udev: Inline `udevRemoveOneDevice`
node_device_udev: Move responsibility to release `(init|udev)Thread`
to `udevEventDataDispose`
node_device_udev: Fix leak of mdevctlLock, udevThreadCond, and
mdevCtlMonitors
node_device_udev: Introduce and use `stateShutdownPrepare` and
`stateShutdownWait`
node_device_udev: nodeStateShutdownPrepare: Disconnect the signals
explicitly
node_device_udev: Pass the driver state as parameter in preparation
for the next commit
node_device_udev: Use a worker pool for processing events and emitting
nodedev event
node_device_udev: Make the code easier to read
node_device_udev: Add support for `g_autoptr` to `udevEventData`
node_device_udev: Pass the `udevEventData` via parameter and use
refcounting
node_device_udev: remove incorrect G_GNUC_UNUSED
src/node_device/node_device_driver.h | 5 +-
src/util/virmdev.h | 4 +
src/conf/node_device_conf.c | 10 +-
src/node_device/node_device_driver.c | 28 +-
src/node_device/node_device_udev.c | 516 ++++++++++++++++++---------
src/test/test_driver.c | 11 +-
src/util/virmdev.c | 20 ++
src/libvirt_private.syms | 2 +
8 files changed, 398 insertions(+), 198 deletions(-)
base-commit: c38720b337f74337ec94c0fe2e97a7c2c57188ae
--
2.34.1
3 weeks, 4 days
RFC: Drop micro part of our release versioning scheme
by Jiri Denemark
Hi,
Does anyone feel strongly against dropping the "micro" part from
libvirt(-python) versions? I think the original idea was to use this
number for maintenance releases in -maint branches, but we stopped doing
those a long time ago (v3.2.1 was the last and most likely even the only
release with micro > 0 since the change in numbering libvirt releases).
So the micro part looks quite useless, not to mention I am lazy to type
the .0 suffix all the time :-)
And if we decide to drop it, what would be the right time? This 10.3
release, the following 10.4 release or should we wait until 11.0?
Personally I'd do it just now, but someone might be relying on the
numbers and would prefer to know about such change in advance to prepare
for it. So perhaps 10.4 or the most conservative 11.0 would be better
options.
Jirka
3 weeks, 4 days
[PATCH v2 00/27] native support for nftables in virtual network driver
by Laine Stump
V1: https://listman.redhat.com/archives/libvir-list/2023-May/239720.html
Finally, a V2! :-/
This patch series enables libvirt to use nftables rules rather than
iptables *when setting up virtual networks* (it does *not* add
nftables support to the nwfilter driver).
This is accomplished by
1) moving all virtual network iptables-related code from both
util/viriptables.c and network/bridge_driver_linux.c into
util/network_iptables.c, leaving only 3 iptables-related functions
that are called from the bridge driver:
networkAddFirewallRules()
networkRemoveFirewallRules()
networkSetupPrivateChains()
2) creating a network/network_nftables.c that implements nftables
equivalents for 2 of those 3 functions
(networkRemoveFirewallRules() isn't needed for nftables because
other patches in this series update virFirewall to automatically
create the list of commands needed to remove all the rules added by
a particular virFirewall).
There's a bunch of other cleanup and reorganization going on that's
described in the individual patches.
Changes from V1:
* The biggest change is that in V1 I had made a virNetFilter API that
was at the same level as all the low level functions in
viriptable.c. But in the end I realized that, while this would
guarantee that the rules added by the nftables backend were as close
as possible to those created by the iptables backend, it also meant
that any modifications to improve the nftables rules would anyway
necessitate splitting off at a higher level (the 3 functions listed
above), while at the same time rendering the virNetfilter API
unnecessary. So instead I consolidated everything at/below the level
of the 3 above functions into a single file, with a very simple
interface, then duplicated that file and modified the duplicate to
produce nftables rules instead of iptables. The result is that I've
copied slightly more code, but any changes to nftables rules won't
have any effect on the iptables backend.
* util/viriptables.c was moved to network/network_iptables.c since it
is a specific enough API that it was only ever used by the network
driver.
* There is no more circular dependency between virfirewall,
virnetfilter, & virXXtables as pointed out by danpb in his review of
V1. virFirewall does still have the functionality of automatically
generating the necessary commands to remove a firewall (which was
the reason for the circle), but it is self-contained in a couple of
functions in virfirewall.c rather than calling out to virnetfilter.c
(which, btw, doesn't even exist in V2).
* Based on the exchange in the responses to V1, I went ahead and made
nftables the default backend when available (V1 left iptables as the
default). The only behavioral difference between iptables and
nftables is the lack of checksum fixup of bad DHCP packets which is
only an issue for very old guest OSes, and is easy to workaround
(see patches 24 & 26 for details)
The firewall unit tests have been parameterized so that all the tests
are run for both backends. This of course does nothing for all the
tests in libvirt-tck (and any other tests that validate via checking
the output of e.g. "iptables -S"). That is going to take some work,
somewhere, by somebody :-)
One thing I'm undecided about is the firewall object stored in the
networkobj (patches 19 & 20) - the way the code is currently written,
the xml element is called <firewall>, and it contains the virFirewall
object that will remove the network's firewall. I have pondered the
idea of saving the entire original virFirewall object (which includes
all the commands that were used to *create* the firewall, as well as
all the commands needed to remove it), since this might be useful in
debugging. It is quite a lot of data though, and not easily readable
by a human (there is a separate element for each option of each
commandline), so I haven't decided if it's worthwhile. (Alternately,
if I leave it as is, maybe I should change the element name to
<fwRemoval>? Does anyone have an opinion?)
Laine Stump (27):
util/network: move viriptables.[ch] from util to network directory
network: move all functions manipulating iptables rules into
network_iptables.c
network: make all iptables functions used only in network_iptables.c
static
util: #define the names used for private packet filter chains
util: change name of virFirewallRule to virFirewallCmd
util: rename virNetFilterAction to iptablesAction, and add
VIR_ENUM_DECL/IMPL
util: check for 0 args when applying iptables rule
util: add -w/--concurrent when applying a FirewallCmd rather than when
building it
util: determine ignoreErrors value when creating virFirewallCmd, not
when applying
util/network: new virFirewallBackend enum
network: add (empty) network.conf file to distribution files
network: support setting firewallBackend from network.conf
network: framework to call backend-specific function to init private
filter chains
util: new functions to support adding individual firewall rollback
commands
util: implement rollback rule autocreation for iptables commands
network: turn on auto-rollback for the rules added for virtual
networks
util: new function virFirewallNewFromRollback()
util: new functions virFirewallParseXML() and virFirewallFormat()
conf: add a virFirewall object to virNetworkObj
network: use previously saved list of firewall removal commands
network: save network status when firewall rules are reloaded
meson: stop looking for iptables/ip6tables/ebtables at build time
rpm: drop BuildRequires for iptables and ebtables
network: add an nftables backend for network driver's firewall
construction
tests: test cases for nftables backend
network: prefer the nftables backend over iptables
RFC: spec: change iptables/ebtables from Requires to Recommends, add
nftables
libvirt.spec.in | 12 +-
meson.build | 3 -
po/POTFILES | 3 +-
src/conf/virnetworkobj.c | 40 +
src/conf/virnetworkobj.h | 11 +
src/libvirt_private.syms | 57 +-
src/network/bridge_driver.c | 35 +-
src/network/bridge_driver_conf.c | 45 +
src/network/bridge_driver_conf.h | 3 +
src/network/bridge_driver_linux.c | 639 +------
src/network/bridge_driver_nop.c | 6 +-
src/network/bridge_driver_platform.h | 6 +-
src/network/libvirtd_network.aug | 39 +
src/network/meson.build | 13 +
src/network/network.conf | 27 +
src/network/network_iptables.c | 1677 +++++++++++++++++
src/network/network_iptables.h | 30 +
src/network/network_nftables.c | 940 +++++++++
src/network/network_nftables.h | 28 +
src/network/test_libvirtd_network.aug.in | 5 +
src/nwfilter/nwfilter_ebiptables_driver.c | 1004 +++++-----
src/util/meson.build | 1 -
src/util/virebtables.c | 36 +-
src/util/virfirewall.c | 801 ++++++--
src/util/virfirewall.h | 86 +-
src/util/viriptables.c | 1072 -----------
src/util/viriptables.h | 155 --
.../{base.args => base.iptables} | 0
tests/networkxml2firewalldata/base.nftables | 256 +++
...-linux.args => nat-default-linux.iptables} | 0
.../nat-default-linux.nftables | 248 +++
...pv6-linux.args => nat-ipv6-linux.iptables} | 0
.../nat-ipv6-linux.nftables | 384 ++++
...rgs => nat-ipv6-masquerade-linux.iptables} | 0
.../nat-ipv6-masquerade-linux.nftables | 456 +++++
...linux.args => nat-many-ips-linux.iptables} | 0
.../nat-many-ips-linux.nftables | 472 +++++
...-linux.args => nat-no-dhcp-linux.iptables} | 0
.../nat-no-dhcp-linux.nftables | 384 ++++
...ftp-linux.args => nat-tftp-linux.iptables} | 0
.../nat-tftp-linux.nftables | 274 +++
...inux.args => route-default-linux.iptables} | 0
.../route-default-linux.nftables | 162 ++
tests/networkxml2firewalltest.c | 56 +-
tests/virfirewalltest.c | 424 ++---
45 files changed, 7138 insertions(+), 2752 deletions(-)
create mode 100644 src/network/libvirtd_network.aug
create mode 100644 src/network/network.conf
create mode 100644 src/network/network_iptables.c
create mode 100644 src/network/network_iptables.h
create mode 100644 src/network/network_nftables.c
create mode 100644 src/network/network_nftables.h
create mode 100644 src/network/test_libvirtd_network.aug.in
delete mode 100644 src/util/viriptables.c
delete mode 100644 src/util/viriptables.h
rename tests/networkxml2firewalldata/{base.args => base.iptables} (100%)
create mode 100644 tests/networkxml2firewalldata/base.nftables
rename tests/networkxml2firewalldata/{nat-default-linux.args => nat-default-linux.iptables} (100%)
create mode 100644 tests/networkxml2firewalldata/nat-default-linux.nftables
rename tests/networkxml2firewalldata/{nat-ipv6-linux.args => nat-ipv6-linux.iptables} (100%)
create mode 100644 tests/networkxml2firewalldata/nat-ipv6-linux.nftables
rename tests/networkxml2firewalldata/{nat-ipv6-masquerade-linux.args => nat-ipv6-masquerade-linux.iptables} (100%)
create mode 100644 tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.nftables
rename tests/networkxml2firewalldata/{nat-many-ips-linux.args => nat-many-ips-linux.iptables} (100%)
create mode 100644 tests/networkxml2firewalldata/nat-many-ips-linux.nftables
rename tests/networkxml2firewalldata/{nat-no-dhcp-linux.args => nat-no-dhcp-linux.iptables} (100%)
create mode 100644 tests/networkxml2firewalldata/nat-no-dhcp-linux.nftables
rename tests/networkxml2firewalldata/{nat-tftp-linux.args => nat-tftp-linux.iptables} (100%)
create mode 100644 tests/networkxml2firewalldata/nat-tftp-linux.nftables
rename tests/networkxml2firewalldata/{route-default-linux.args => route-default-linux.iptables} (100%)
create mode 100644 tests/networkxml2firewalldata/route-default-linux.nftables
--
2.44.0
3 weeks, 4 days
[PATCH v4 0/3] test: fix nodedev mdev XML regression
by Cole Robinson
See last patch for explanation. First two patches are related
bugfixes/improvements
v4 changes:
- 3 patches pushed
- mark parsed devices as persistent too
- add GetXML fix patch
Cole Robinson (3):
test: make parsed nodedevs active and persistent
test: Sync GetXML INACTIVE behavior with live driver
conf: nodedev: Fill active_config at XML parse time
src/conf/node_device_conf.c | 5 ++++-
src/test/test_driver.c | 19 ++++++++++++++++++-
tests/nodedevxml2xmltest.c | 15 ---------------
3 files changed, 22 insertions(+), 17 deletions(-)
--
2.44.0
3 weeks, 5 days
[PATCH] virnetdevopenvswitch: Create OVS ports as transient
by Michal Privoznik
Since OVS keeps desired state in a DB, upon sudden crash of the
host we may leave a port behind. There's no problem on VM
shutdown or NIC hotunplug as we call corresponding del-port
function (virNetDevOpenvswitchRemovePort()). But if the host
suddenly crashes we won't ever do that. What happens next, is
when OVS starts it finds desired state in its DB and creates a
stale port.
OVS added support for transient ports in v2.5.0 (Feb 2016) and
since its v2.9.0 it even installs a systemd service
(ovs-delete-transient-ports) that automatically deletes transient
ports on system startup. If we mark a port as transient then OVS
won't restore its state on restart after crash.
This change may render "--may-exist" argument redundant, but I'm
not sure about all the implications if it was removed. Let's keep
it for now.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/615
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/util/virnetdevopenvswitch.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/util/virnetdevopenvswitch.c b/src/util/virnetdevopenvswitch.c
index f1765ae1c8..e23f4c83b6 100644
--- a/src/util/virnetdevopenvswitch.c
+++ b/src/util/virnetdevopenvswitch.c
@@ -164,7 +164,9 @@ int virNetDevOpenvswitchAddPort(const char *brname, const char *ifname,
cmd = virNetDevOpenvswitchCreateCmd(&errbuf);
virCommandAddArgList(cmd, "--", "--may-exist",
- "add-port", brname, ifname, NULL);
+ "add-port", brname, ifname,
+ "--", "set", "Port", ifname, "other_config:transient=true",
+ NULL);
virNetDevOpenvswitchConstructVlans(cmd, virtVlan);
--
2.43.2
3 weeks, 6 days
[PATCH 0/3] qemu_validate: Reject virtiofs with bootindex on s390 with ccw bus
by Peter Krempa
qemu doesn't support booting there and thus doesn't even expose
bootindex.
Peter Krempa (3):
qemuxmlconftest: Add test case for virtiofs on s390 using 'ccw'
addresses
qemuxmlconftest: Decouple input and output files of
'vhost-user-fs-hugepage' case
qemu_validate: Reject virtiofs with bootindex on s390x with CCW
src/qemu/qemu_validate.c | 19 ++--
...ost-user-fs-ccw-bootindex.s390x-latest.err | 1 +
.../vhost-user-fs-ccw-bootindex.xml | 38 ++++++++
.../vhost-user-fs-ccw.s390x-latest.args | 37 ++++++++
.../vhost-user-fs-ccw.s390x-latest.xml | 43 +++++++++
tests/qemuxmlconfdata/vhost-user-fs-ccw.xml | 40 +++++++++
...vhost-user-fs-hugepages.x86_64-latest.args | 2 +
.../vhost-user-fs-hugepages.x86_64-latest.xml | 87 ++++++++++++++++++-
.../vhost-user-fs-hugepages.xml | 8 ++
tests/qemuxmlconftest.c | 3 +
10 files changed, 272 insertions(+), 6 deletions(-)
create mode 100644 tests/qemuxmlconfdata/vhost-user-fs-ccw-bootindex.s390x-latest.err
create mode 100644 tests/qemuxmlconfdata/vhost-user-fs-ccw-bootindex.xml
create mode 100644 tests/qemuxmlconfdata/vhost-user-fs-ccw.s390x-latest.args
create mode 100644 tests/qemuxmlconfdata/vhost-user-fs-ccw.s390x-latest.xml
create mode 100644 tests/qemuxmlconfdata/vhost-user-fs-ccw.xml
mode change 120000 => 100644 tests/qemuxmlconfdata/vhost-user-fs-hugepages.x86_64-latest.xml
--
2.44.0
3 weeks, 6 days
[PATCH 0/2] qemu: Substract isolcpus from all online affinity
by Michal Privoznik
*** BLURB HERE ***
Michal Prívozník (2):
virhostcpu: Introduce virHostCPUGetIsolated()
qemu: Substract isolcpus from all online affinity
src/libvirt_private.syms | 1 +
src/qemu/qemu_process.c | 7 +++++++
src/util/virhostcpu.c | 21 +++++++++++++++++++++
src/util/virhostcpu.h | 1 +
4 files changed, 30 insertions(+)
--
2.43.2
3 weeks, 6 days
[PATCH 00/10] qemu: Introduce shared_filesystems configuration option
by Andrea Bolognani
An alternative take on [1] based on review feedback.
The need to have something like this in the first place is driven by
KubeVirt (see [2] and [3]). A draft version of this series has been
integrated into KubeVirt and it has been confirmed that it was
effective in removing the need to use LD_PRELOAD hacks in the storage
provider.
CC'ing Stefan so he can have a look at the TPM part and shout if I've
gotten anything wrong :)
[1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/MM...
[2] https://issues.redhat.com/browse/CNV-34322
[3] https://issues.redhat.com/browse/CNV-39370
Andrea Bolognani (10):
security: Fix alignment
security: Fix name for _virSecurityDACChardevCallbackData
security: Drop virSecurity(DAC|SELinux)RestoreImageLabelSingle()
security: Drop virSecurity(DAC|SELinux)SetImageLabelRelative()
qemu: Tweak augeas schema
qemu: Introduce shared_filesystems configuration option
qemu: Propagate shared_filesystems
utils: Use overrides in virFileIsSharedFS()
qemu: Always set labels for TPM state
NEWS: Document qemu shared_filesystems option
NEWS.rst | 7 +++
src/lxc/lxc_controller.c | 2 +-
src/lxc/lxc_driver.c | 2 +-
src/lxc/lxc_process.c | 4 +-
src/qemu/libvirtd_qemu.aug | 11 ++--
src/qemu/qemu.conf.in | 17 ++++++
src/qemu/qemu_conf.c | 17 ++++++
src/qemu/qemu_conf.h | 2 +
src/qemu/qemu_domain.c | 2 +-
src/qemu/qemu_extdevice.c | 2 +-
src/qemu/qemu_migration.c | 12 ++--
src/qemu/qemu_security.c | 14 ++++-
src/qemu/qemu_tpm.c | 36 ++++++------
src/qemu/qemu_tpm.h | 8 ++-
src/qemu/test_libvirtd_qemu.aug.in | 5 ++
src/security/security_apparmor.c | 2 +
src/security/security_dac.c | 67 +++++++++-------------
src/security/security_driver.h | 4 ++
src/security/security_manager.c | 34 +++++++-----
src/security/security_manager.h | 20 ++++---
src/security/security_nop.c | 4 ++
src/security/security_selinux.c | 58 ++++++++-----------
src/security/security_stack.c | 16 ++++--
src/util/virfile.c | 89 +++++++++++++++++++++++++-----
src/util/virfile.h | 3 +-
tests/securityselinuxlabeltest.c | 2 +-
tests/virfiletest.c | 2 +-
27 files changed, 289 insertions(+), 153 deletions(-)
--
2.44.0
1 month
Plans for 10.3.0 release (freeze on Friday 26 Apr)
by Jiri Denemark
We are getting close to 10.3.0 release of libvirt. To aim for the
release on Thursday 02 May I suggest entering the freeze on Friday
26 Apr and tagging RC2 on Tuesday 30 Apr.
I hope this works for everyone.
Jirka
1 month
