Entering freeze for libvirt-9.10.0
by Jiri Denemark
I have just tagged v9.10.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://download.libvirt.org/
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
1 year, 4 months
[PATCH 0/2] rpcgen: tests: Improve on funky platforms
by Michal Privoznik
At least the second patch should be merged before the release so that
Jirka can do the release cleanly.
Michal Prívozník (2):
rpcgen: tests: Allow running test_demo from anywhere
rpcgen: tests: Run cleanly on platforms where char is unsigned
scripts/rpcgen/tests/meson.build | 4 +++-
scripts/rpcgen/tests/test_demo.c | 4 ++--
.../tests/test_demo_struct_fixed_array.bin | Bin 136 -> 136 bytes
.../tests/test_demo_struct_pointer_set.bin | Bin 12 -> 12 bytes
.../rpcgen/tests/test_demo_struct_scalar.bin | Bin 8 -> 8 bytes
.../test_demo_struct_variable_array_set.bin | Bin 28 -> 28 bytes
.../tests/test_demo_test_struct_all_types.bin | Bin 1752 -> 1752 bytes
7 files changed, 5 insertions(+), 3 deletions(-)
--
2.41.0
1 year, 4 months
[PATCH V5] support for hotplug/hotunplug in test hypervisor
by Thanos Makatos
Signed-off-by: Thanos Makatos <thanos.makatos(a)nutanix.com>
---
Changed since v4:
* removed inadvertent calls to functions virNWFilterReadLockFilterUpdates/virNWFilterUnlockFilterUpdates
(original patch was based on v8.0.0)
---
src/test/test_driver.c | 382 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 380 insertions(+), 2 deletions(-)
diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index e87d7cfd44..effb7f9880 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -26,8 +26,6 @@
#include <unistd.h>
#include <sys/stat.h>
#include <libxml/xmlsave.h>
-
-
#include "virerror.h"
#include "datatypes.h"
#include "test_driver.h"
@@ -38,9 +36,12 @@
#include "virnetworkobj.h"
#include "interface_conf.h"
#include "checkpoint_conf.h"
+#include "domain_addr.h"
+#include "domain_audit.h"
#include "domain_conf.h"
#include "domain_driver.h"
#include "domain_event.h"
+#include "domain_validate.h"
#include "network_event.h"
#include "snapshot_conf.h"
#include "virfdstream.h"
@@ -50,6 +51,7 @@
#include "node_device_conf.h"
#include "virnodedeviceobj.h"
#include "node_device_event.h"
+#include "vircgroup.h"
#include "virxml.h"
#include "virthread.h"
#include "virlog.h"
@@ -10035,6 +10037,379 @@ testConnectGetDomainCapabilities(virConnectPtr conn G_GNUC_UNUSED,
return virDomainCapsFormat(domCaps);
}
+static int
+testDomainAttachHostPCIDevice(testDriver *driver G_GNUC_UNUSED,
+ virDomainObj *vm,
+ virDomainHostdevDef *hostdev)
+{
+ int backend = hostdev->source.subsys.u.pci.backend;
+
+ switch ((virDomainHostdevSubsysPCIBackendType)backend) {
+ case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO:
+ case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_DEFAULT:
+ case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_KVM:
+ break;
+
+ case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_XEN:
+ case VIR_DOMAIN_HOSTDEV_PCI_BACKEND_TYPE_LAST:
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("test hypervisor does not support device assignment mode '%s'"),
+ virDomainHostdevSubsysPCIBackendTypeToString(backend));
+ return -1;
+ }
+
+ if (!virDomainObjIsActive(vm)) {
+ virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
+ _("guest unexpectedly quit during hotplug"));
+ return -1;
+ }
+
+ VIR_REALLOC_N(vm->def->hostdevs, vm->def->nhostdevs + 1);
+
+ virDomainAuditHostdev(vm, hostdev, "attach", true);
+
+ vm->def->hostdevs[vm->def->nhostdevs++] = hostdev;
+
+ return 0;
+}
+
+static int
+testDomainAttachHostDevice(testDriver *driver,
+ virDomainObj *vm,
+ virDomainHostdevDef *hostdev)
+{
+ if (hostdev->mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("hotplug is not supported for hostdev mode '%s'"),
+ virDomainHostdevModeTypeToString(hostdev->mode));
+ return -1;
+ }
+
+ if (hostdev->source.subsys.type != VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("hotplug is not supported for hostdev subsys type '%s'"),
+ virDomainHostdevSubsysTypeToString(hostdev->source.subsys.type));
+ return -1;
+ }
+
+ return testDomainAttachHostPCIDevice(driver, vm, hostdev);
+}
+
+static int
+testDomainAttachDeviceLive(virDomainObj *vm,
+ virDomainDeviceDef *dev,
+ testDriver *driver)
+{
+ int ret = -1;
+ const char *alias = NULL;
+
+ if ((virDomainDeviceType)dev->type != VIR_DOMAIN_DEVICE_HOSTDEV) {
+ virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
+ _("live attach of device '%s' is not supported"),
+ virDomainDeviceTypeToString(dev->type));
+ return -1;
+ }
+
+ testDomainObjCheckHostdevTaint(vm, dev->data.hostdev);
+ if ((ret = testDomainAttachHostDevice(driver, vm, dev->data.hostdev)) != 0)
+ return ret;
+
+ alias = dev->data.hostdev->info->alias;
+ dev->data.hostdev = NULL;
+
+ if (alias) {
+ virObjectEvent *event;
+ event = virDomainEventDeviceAddedNewFromObj(vm, alias);
+ virObjectEventStateQueue(driver->eventState, event);
+ }
+
+ return 0;
+}
+
+static int
+testDomainAttachDeviceLiveAndConfig(virDomainObj *vm,
+ testDriver *driver,
+ const char *xml,
+ unsigned int flags)
+{
+ g_autoptr(virDomainDeviceDef) devConf = NULL;
+ g_autoptr(virDomainDeviceDef) devLive = NULL;
+ unsigned int parse_flags = VIR_DOMAIN_DEF_PARSE_INACTIVE |
+ VIR_DOMAIN_DEF_PARSE_ABI_UPDATE;
+
+ virCheckFlags(VIR_DOMAIN_AFFECT_LIVE, -1);
+
+ if (flags & VIR_DOMAIN_AFFECT_LIVE) {
+ if (!(devLive = virDomainDeviceDefParse(xml, vm->def,
+ driver->xmlopt, NULL,
+ parse_flags)))
+ return -1;
+
+ if (virDomainDeviceValidateAliasForHotplug(vm, devLive,
+ VIR_DOMAIN_AFFECT_LIVE) < 0)
+ return -1;
+
+ if (virDomainDefCompatibleDevice(vm->def, devLive, NULL,
+ VIR_DOMAIN_DEVICE_ACTION_ATTACH,
+ true) < 0)
+ return -1;
+
+ if (testDomainAttachDeviceLive(vm, devLive, driver) < 0)
+ return -1;
+ }
+
+ return 0;
+}
+
+static int
+testDomainAttachDeviceFlags(virDomainPtr domain,
+ const char *xml,
+ unsigned int flags) {
+
+ testDriver *driver = domain->conn->privateData;
+ virDomainObj *vm = NULL;
+ int ret = -1;
+
+ if (!(vm = testDomObjFromDomain(domain)))
+ return -1;
+
+ if (virDomainObjUpdateModificationImpact(vm, &flags) < 0)
+ goto cleanup;
+
+ if (testDomainAttachDeviceLiveAndConfig(vm, driver, xml, flags) < 0)
+ goto cleanup;
+
+ ret = 0;
+
+ cleanup:
+ virDomainObjEndAPI(&vm);
+ return ret;
+}
+
+static int
+testDomainAttachDevice(virDomainPtr domain, const char *xml)
+{
+ return testDomainAttachDeviceFlags(domain, xml, 0);
+}
+
+/* search for a hostdev matching dev and detach it */
+static int
+testDomainDetachPrepHostdev(virDomainObj *vm,
+ virDomainHostdevDef *match,
+ virDomainHostdevDef **detach)
+{
+ virDomainHostdevSubsys *subsys = &match->source.subsys;
+ virDomainHostdevSubsysPCI *pcisrc = &subsys->u.pci;
+ virDomainHostdevDef *hostdev = NULL;
+
+ if (match->mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("hot unplug is not supported for hostdev mode '%s'"),
+ virDomainHostdevModeTypeToString(match->mode));
+ return -1;
+ }
+
+ if (virDomainHostdevFind(vm->def, match, &hostdev) < 0) {
+ if (subsys->type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI) {
+ virReportError(VIR_ERR_DEVICE_MISSING,
+ _("host pci device " VIR_PCI_DEVICE_ADDRESS_FMT
+ " not found"),
+ pcisrc->addr.domain, pcisrc->addr.bus,
+ pcisrc->addr.slot, pcisrc->addr.function);
+ } else {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("unexpected hostdev type %d"), subsys->type);
+ }
+ return -1;
+ }
+
+ *detach = hostdev;
+
+ return 0;
+}
+
+static int
+testDomainRemoveHostDevice(testDriver *driver G_GNUC_UNUSED,
+ virDomainObj *vm,
+ virDomainHostdevDef *hostdev)
+{
+ virDomainNetDef *net = NULL;
+ size_t i;
+
+ VIR_DEBUG("Removing host device %s from domain %p %s",
+ hostdev->info->alias, vm, vm->def->name);
+
+ if (hostdev->parentnet) {
+ net = hostdev->parentnet;
+ for (i = 0; i < vm->def->nnets; i++) {
+ if (vm->def->nets[i] == hostdev->parentnet) {
+ virDomainNetRemove(vm->def, i);
+ break;
+ }
+ }
+ }
+
+ for (i = 0; i < vm->def->nhostdevs; i++) {
+ if (vm->def->hostdevs[i] == hostdev) {
+ virDomainHostdevRemove(vm->def, i);
+ break;
+ }
+ }
+
+ virDomainAuditHostdev(vm, hostdev, "detach", true);
+
+ virDomainHostdevDefFree(hostdev);
+
+ if (net) {
+ if (net->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
+ g_autoptr(virConnect) conn = virGetConnectNetwork();
+ if (conn)
+ virDomainNetReleaseActualDevice(conn, vm->def, net);
+ else
+ VIR_WARN("Unable to release network device '%s'", NULLSTR(net->ifname));
+ }
+ virDomainNetDefFree(net);
+ }
+
+ return 0;
+}
+
+static int
+testDomainRemoveDevice(testDriver *driver,
+ virDomainObj *vm,
+ virDomainDeviceDef *dev)
+{
+ virDomainDeviceInfo *info;
+ virObjectEvent *event;
+ g_autofree char *alias = NULL;
+
+ /*
+ * save the alias to use when sending a DEVICE_REMOVED event after
+ * all other teardown is complete
+ */
+ if ((info = virDomainDeviceGetInfo(dev)))
+ alias = g_strdup(info->alias);
+ info = NULL;
+
+ if ((virDomainDeviceType)dev->type != VIR_DOMAIN_DEVICE_HOSTDEV) {
+ virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
+ _("don't know how to remove a %s device"),
+ virDomainDeviceTypeToString(dev->type));
+ goto out;
+ }
+
+ if (testDomainRemoveHostDevice(driver, vm, dev->data.hostdev) < 0)
+ return -1;
+
+out:
+ event = virDomainEventDeviceRemovedNewFromObj(vm, alias);
+ virObjectEventStateQueue(driver->eventState, event);
+
+ return 0;
+}
+
+static int
+testDomainDetachDeviceLive(virDomainObj *vm,
+ virDomainDeviceDef *match,
+ testDriver *driver)
+{
+ virDomainDeviceDef detach = { .type = match->type };
+ virDomainDeviceInfo *info = NULL;
+
+ if ((virDomainDeviceType)match->type != VIR_DOMAIN_DEVICE_HOSTDEV) {
+ virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
+ _("live detach of device '%s' is not supported"),
+ virDomainDeviceTypeToString(match->type));
+ return -1;
+ }
+
+ if (testDomainDetachPrepHostdev(vm, match->data.hostdev,
+ &detach.data.hostdev) < 0)
+ return -1;
+
+ /* "detach" now points to the actual device we want to detach */
+
+ if (!(info = virDomainDeviceGetInfo(&detach))) {
+ /*
+ * This should never happen, since all of the device types in
+ * the switch cases that end with a "break" instead of a
+ * return have a virDeviceInfo in them.
+ */
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("device of type '%s' has no device info"),
+ virDomainDeviceTypeToString(detach.type));
+ return -1;
+ }
+
+ /* Make generic validation checks common to all device types */
+
+ if (!info->alias) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Cannot detach %s device with no alias"),
+ virDomainDeviceTypeToString(detach.type));
+ return -1;
+ }
+
+ return testDomainRemoveDevice(driver, vm, &detach);
+}
+
+static int
+testDomainDetachDeviceAliasLiveAndConfig(testDriver *driver,
+ virDomainObj *vm,
+ const char *alias,
+ unsigned int flags)
+{
+ virDomainDef *def = NULL;
+ g_autoptr(virDomainDef) vmdef = NULL;
+
+ virCheckFlags(VIR_DOMAIN_AFFECT_LIVE, -1);
+
+ if (virDomainObjGetDefs(vm, flags, &def, NULL) < 0)
+ return -1;
+
+ if (def) {
+ virDomainDeviceDef dev;
+
+ if (virDomainDefFindDevice(def, alias, &dev, true) < 0)
+ return -1;
+
+ if (testDomainDetachDeviceLive(vm, &dev, driver) < 0)
+ return -1;
+ }
+
+ if (vmdef) {
+ if (virDomainDefSave(vmdef, driver->xmlopt, NULL) < 0)
+ return -1;
+ virDomainObjAssignDef(vm, &vmdef, false, NULL);
+ }
+
+ return 0;
+}
+
+static int
+testDomainDetachDeviceAlias(virDomainPtr dom,
+ const char *alias,
+ unsigned int flags)
+{
+ testDriver *driver = dom->conn->privateData;
+ virDomainObj *vm = NULL;
+ int ret = -1;
+
+ if (!(vm = testDomObjFromDomain(dom)))
+ return -1;
+
+ if (virDomainObjUpdateModificationImpact(vm, &flags) < 0)
+ goto cleanup;
+
+ if (testDomainDetachDeviceAliasLiveAndConfig(driver, vm, alias, flags) < 0)
+ goto cleanup;
+
+ ret = 0;
+
+ cleanup:
+ virDomainObjEndAPI(&vm);
+ return ret;
+}
/*
* Test driver
@@ -10058,6 +10433,9 @@ static virHypervisorDriver testHypervisorDriver = {
.connectListDomains = testConnectListDomains, /* 0.1.1 */
.connectNumOfDomains = testConnectNumOfDomains, /* 0.1.1 */
.connectListAllDomains = testConnectListAllDomains, /* 0.9.13 */
+ .domainAttachDevice = testDomainAttachDevice, /* 9.10.0 */
+ .domainAttachDeviceFlags = testDomainAttachDeviceFlags, /* 9.10.0 */
+ .domainDetachDeviceAlias = testDomainDetachDeviceAlias, /* 9.10.0 */
.domainCreateXML = testDomainCreateXML, /* 0.1.4 */
.domainCreateXMLWithFiles = testDomainCreateXMLWithFiles, /* 5.7.0 */
.domainLookupByID = testDomainLookupByID, /* 0.1.1 */
--
2.27.0
1 year, 4 months
[PATCH] qemu_driver: Don't handle the EOF event if monitor changed
by Guoyi Tu
Currently, libvirt creates a thread pool with only on thread to handle all
qemu monitor events for virtual machines, In the cases that if the thread
gets stuck while handling a monitor EOF event, such as unable to kill the
virtual machine process or release resources, the events of other virtual
machine will be also blocked, which will lead to the abnormal behavior of
other virtual machines.
For instance, when another virtual machine completes a shutdown operation
and the monitor EOF event has been queued but remains unprocessed, we
immediately destroy and start the virtual machine again, at a later time
when EOF event get processed, the processMonitorEOFEvent() will kill the
virtual machine that just started.
To address this issue, in the processMonitorEOFEvent(), we check whether
the current virtual machine's monitor object matches the one at the time
the event was generated. If they do not match, we immediately return.
Signed-off-by: Guoyi Tu <tugy(a)chinatelecom.cn>
Signed-off-by: dengpengcheng <dengpc12(a)chinatelecom.cn>
---
src/qemu/qemu_domain.c | 2 +-
src/qemu/qemu_driver.c | 11 +++++++++--
src/qemu/qemu_process.c | 2 +-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index ae19ce884b..bc80afdfac 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -11500,7 +11500,6 @@ qemuProcessEventFree(struct qemuProcessEvent *event)
case QEMU_PROCESS_EVENT_NETDEV_STREAM_DISCONNECTED:
case QEMU_PROCESS_EVENT_NIC_RX_FILTER_CHANGED:
case QEMU_PROCESS_EVENT_SERIAL_CHANGED:
- case QEMU_PROCESS_EVENT_MONITOR_EOF:
case QEMU_PROCESS_EVENT_GUEST_CRASHLOADED:
g_free(event->data);
break;
@@ -11514,6 +11513,7 @@ qemuProcessEventFree(struct qemuProcessEvent *event)
case QEMU_PROCESS_EVENT_UNATTENDED_MIGRATION:
case QEMU_PROCESS_EVENT_RESET:
case QEMU_PROCESS_EVENT_NBDKIT_EXITED:
+ case QEMU_PROCESS_EVENT_MONITOR_EOF:
case QEMU_PROCESS_EVENT_LAST:
break;
}
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index d00d2a27c6..57acafb48b 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3854,7 +3854,8 @@ processJobStatusChangeEvent(virDomainObj *vm,
static void
processMonitorEOFEvent(virQEMUDriver *driver,
- virDomainObj *vm)
+ virDomainObj *vm,
+ qemuMonitor *mon)
{
qemuDomainObjPrivate *priv = vm->privateData;
int eventReason = VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN;
@@ -3863,6 +3864,12 @@ processMonitorEOFEvent(virQEMUDriver *driver,
unsigned int stopFlags = 0;
virObjectEvent *event = NULL;
+ if (priv->mon != mon) {
+ VIR_DEBUG("Domain %p '%s' has been shutdown, ignoring EOF",
+ vm, vm->def->name);
+ return;
+ }
+
if (qemuProcessBeginStopJob(vm, VIR_JOB_DESTROY, true) < 0)
return;
@@ -4082,7 +4089,7 @@ static void qemuProcessEventHandler(void *data,
void *opaque)
processJobStatusChangeEvent(vm, processEvent->data);
break;
case QEMU_PROCESS_EVENT_MONITOR_EOF:
- processMonitorEOFEvent(driver, vm);
+ processMonitorEOFEvent(driver, vm, processEvent->data);
break;
case QEMU_PROCESS_EVENT_PR_DISCONNECT:
processPRDisconnectEvent(vm);
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index b9267d8699..4de6e5c234 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -316,7 +316,7 @@ qemuProcessHandleMonitorEOF(qemuMonitor *mon,
}
qemuProcessEventSubmit(vm, QEMU_PROCESS_EVENT_MONITOR_EOF,
- 0, 0, NULL);
+ 0, 0, priv->mon);
/* We don't want this EOF handler to be called over and over while the
* thread is waiting for a job.
--
2.17.1
1 year, 4 months
[libvirt PATCH] rpm: Drop rpcgen Build-Requires once again
by Andrea Bolognani
We no longer use it, so commit a62486b95fee correctly dropped
the Build-Requires; shortly afterwards, however, I accidentally
re-introduced it by mistake.
Fixes: 3df8cc658ed0ac2f84089ad0db61ba20eb8b8aa7
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
libvirt.spec.in | 1 -
1 file changed, 1 deletion(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 361a34675b..f3fdedfde4 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -313,7 +313,6 @@ BuildRequires: libxml2
BuildRequires: libxslt
BuildRequires: gettext
BuildRequires: systemd-rpm-macros
-BuildRequires: rpcgen
# Fedora build root suckage
BuildRequires: gawk
%if %{with_native}
--
2.43.0
1 year, 4 months
[PATCH 0/4] A bunch of trivial fixes
by Michal Privoznik
*** BLURB HERE ***
Michal Prívozník (4):
virpci: Decrease scope of VIR_PF_PHYS_PORT_NAME_REGEX macro
qemu_command: Don't open code virPCIDeviceAddressAsString()
vircpi: Decrease scope of VIR_PCI_DEVICE_ADDRESS_FMT macro
ch: Don't leak ch_driver->chCaps
src/ch/ch_driver.c | 5 +++--
src/qemu/qemu_command.c | 6 +-----
src/util/virpci.c | 9 +++++++++
src/util/virpci.h | 7 -------
4 files changed, 13 insertions(+), 14 deletions(-)
--
2.41.0
1 year, 4 months
[Call for Presentations] FOSDEM 2024: Virt & IaaS Devroom
by Kashyap Chamarthy
[Cross-posted to KVM, Rust-VMM, QEMU, and libvirt lists)
Hi, the CFP for the "Virt & IaaS" DevRoom is out[+].
Something new this year is a new talk-submission system: so you need to
create a new account, even if you've had an account with the older
talk-submission system. Details in the "Submit Your Proposal" section
below.
========================================================================
We are excited to announce that the call for proposals is now open for
the Virtualization and Cloud infrastructure devroom at the upcoming
FOSDEM 2024, to be hosted on February 3rd 2024.
This devroom is a collaborative effort, and is organized by dedicated
folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM,
and Foreman. We would like to invite all those who are involved in these
fields to submit your proposals by December 8th, 2023.
Important Dates
---------------
Submission deadline: 8th December 2023
Acceptance notifications: 10th December 2023
Final schedule announcement: 15th December 2023
Devroom: 3rd February 2024
About the Devroom
-----------------
The Virtualization & IaaS devroom will feature session topics such as
open source hypervisors or virtual machine managers such as Xen Project,
KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service
projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and
OpenNebula.
This devroom will host presentations that focus on topics of shared
interest, such as KVM; libvirt; shared storage; virtualized networking;
cloud security; clustering and high availability; interfacing with
multiple hypervisors; hyperconverged deployments; and scaling across
hundreds or thousands of servers.
Presentations in this devroom will be aimed at developers working on
these platforms who are looking to collaborate and improve shared
infrastructure or solve common problems. We seek topics that encourage
dialog between projects and continued work post-FOSDEM.
Submit Your Proposal
--------------------
All submissions must be made via the Pretalx event planning site[1]. It
is a new submission system so you will need to create an account. If you
submitted proposals for FOSDEM in previous years, you won’t be able to
use your existing account.
During submission please make sure to select Virtualization and Cloud
infrastructure from the Track list. Please fill out all the required
fields, and provide a meaningful abstract and description of your
proposed session.
Submission Guidelines
---------------------
We expect more proposals than we can possibly accept, so it is vitally
important that you submit your proposal on or before the deadline. Late
submissions are unlikely to be considered.
All presentation slots are 30 minutes, with 20 minutes planned for
presentations, and 10 minutes for Q&A.
All presentations will be recorded and made available under Creative
Commons licenses. In the Submission notes field, please indicate that
you agree that your presentation will be licensed under the CC-By-SA-4.0
or CC-By-4.0 license and that you agree to have your presentation
recorded. For example:
"If my presentation is accepted for FOSDEM, I hereby agree to license
all recordings, slides, and other associated materials under the
Creative Commons Attribution Share-Alike 4.0 International License.
Sincerely,
<NAME>."
In the Submission notes field, please also confirm that if your talk is
accepted, you will be able to attend FOSDEM and deliver your
presentation. We will not consider proposals from prospective speakers
who are unsure whether they will be able to secure funds for travel and
lodging to attend FOSDEM. (Sadly, we are not able to offer travel
funding for prospective speakers.)
Code of Conduct
---------------
Following the release of the updated code of conduct for FOSDEM, we'd
like to remind all speakers and attendees that all of the presentations
and discussions in our devroom are held under the guidelines set in the
CoC and we expect attendees, speakers, and volunteers to follow the CoC
at all times.
If you submit a proposal and it is accepted, you will be required to
confirm that you accept the FOSDEM CoC. If you have any questions about
the CoC or wish to have one of the devroom organizers review your
presentation slides or any other content for CoC compliance, please
email us and we will do our best to assist you.
Questions?
----------
If you have any questions about this devroom, please send your questions
to our devroom mailing list[2]. You can also subscribe to the list to
receive updates about important dates, session announcements, and to
connect with other attendees.
See you all at FOSDEM!
[1] https://pretalx.fosdem.org/fosdem-2024/cfp
[2] virtualization-devroom-manager at fosdem.org
=======================================================================
[+] This email is a slightly formatted version of the official announce:
https://lists.fosdem.org/pipermail/fosdem/2023q4/003481.html
--
/kashyap
1 year, 4 months
Re: [libvirt RFCv11 00/33] multifd save restore prototype
by Claudio Fontana
On 11/27/23 11:18, Daniel P. Berrangé wrote:
> On Mon, Nov 27, 2023 at 10:43:58AM +0100, Claudio Fontana wrote:
>> Hi all,
>>
>> I understand there has been some movement in this topic as the fixed-offset ram and multifd code evolves.
>>
>> I think I understood that now the idea is to pass from libvirt to QEMU two file descriptors,
>> one for writing metadata,
>> and a separate one for the actual memory pages, which is the one that can potentially be O_DIRECT.
>
> We determined that O_DIRECT changes propagate across dup'd file
> descriptors, so we have only two choices
>
> * 1 FD, and QEMU has to take care to toggle O_DIRECT on/off
> repeatedly depending on what phase it is in
> * 2 FDs, one with and one without O_DIRECT
>
> Either is viable for libvirt. I have a mild preference for having
> 1 FD, but not enough to call it a design blocker. So at the
> discretion of whomever implements the QEMU part.
>
>> 1) I would assume that libvirt would then need to check if the user requested --parallel / --parallel-connections to enable QEMU multifd.
>
> Yes
>
>> 2) I would also assume that libvirt would check the presence of --bypass-cache as the condition to set O_DIRECT on the second (memory pages fd), and to enable QEMU "io-direct" feature.
>
> Yes
>
>> 3) I would tentatively suggest that when it comes to fixed-ram-offset, the condition to enable that one is a check like the one currently in libvirt:
>>
>> src/util/virfile.c::virFileDiskCopy()
>>
>> ie checking that we are writing to a seekable file that is not S_ISBLK .
>>
>> Does this match your understanding/reasoning?
>
> Both the io-direct and fixed-ram-offset features are dependent on
> new QEMU impls, so there is a mild backwards compatibility concern.
>
> ie, lets say if we are running QEMU 9.0.0, but with old machine
> type pc-i440fx-8.0.0, and we save the state, but want to then
> restore with QEMU 8.2.0.
>
> Essentially we must NOT use io-direct/fixed-ram-offset if we
> want the ability to migrate to older QEMU. At the same time I
> would like us to be able to take advantage of this new QEMU
> support to the greatest extent possible, even if not doing the
> --parallel stuff which was the original motivator.
>
> Thus, we need some way to decide whether to use the new or the
> old on disk format.
>
> I wonder if having a setting in '/etc/libvirt/qemu.conf' is
> sufficient, or whether we must expose a flag via the API.
>
> With regards,
> Daniel
Thanks Daniel,
that's an interesting point. The new fixed-ram-offset format is a QEMU format, and as such I presume that in theory there is a
qemu_saveimage.h:#define QEMU_SAVE_VERSION 2
that could be bumped to 3 if this new format is used?
But then again, libvirt would need to decide whether to save in "old QEMU compatibility mode" or in the new QEMU_SAVE_VERSION 3 mode that allows for fixed-ram-offset.
Maybe a new libvirt option for controlling which QEMU_SAVE_VERSION format to use for the save, with the default being v2 for backward compatibility reasons?
Thanks,
Claudio
1 year, 4 months
Re: [kubevirt-dev] ANNOUNCE: Virtualization linting library
by Michal Prívozník
[Following move of libvir-list to new location]
On 11/15/23 09:26, Dan Kenigsberg wrote:
> Thanks, Michal, for this overture. I think libvirt and its people have a
> lot of knowledge about working-yet-not-recommended configurations that
> can be beneficial to higher-level management systems such as KubeVirt.
Indeed. But writing checks for such configurations should be trivial
enough, now that they can be written in Lua. But individual checks are
technicality, those can and will be extended once we know current (API)
design works for KubeVirt.
>
> How do you envisage it to be used by KubeVirt?
>
> Do you think virt-launcher can call it before it is calling
> virCreateXML()? If so, would it make sense to bubble up its warnings as
> VM.status conditions?
Yes, that's my idea. Once KubeVirt constructed domain XML, it can feed
it to virt-lint tool. From that it'll receive bunch of warnings (or none
if domain XML is okay) which could be then forwarded to the UI for users
to resolve. Or ignore and continue starting up the guest (for instance,
one of currently implemented checks is for enough of free PCIe root
ports for future hotplug - it's up to user to tell if they will ever
want hotplug).
>
> BTW, I think it may be valuable to add a machine-accessible code for
> each warning, on top of the English language text.
Good point. That way we can save user's preference on ignoring some
warnings. Or have KubeVirt fix some of the warnings automagically.
Anyway, my knowledge of KubeVirt internals is not intimate enough to
even attempt to integrate this. If anybody from KubeVirt developers is
willing to offer a helping hand, I'd appreciate it.
Michal
1 year, 4 months
[PATCH v2 0/3] Introduce pipewire audio backend
by Michal Privoznik
v2 of:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/4M...
diff to v1:
- Introduced 'runtimeDir' attribute to <audio/> so that users do not
have use <qemu:env/> hack to set PIPEWIRE_RUNTIME_DIR.
- Worked in the rest of Peter's review suggestions.
Michal Prívozník (3):
conf: Introduce pipewire audio backend
qemu: Generate cmd line for pipewire audio backend
NEWS: Document pipewire audio backend
NEWS.rst | 5 ++
docs/formatdomain.rst | 46 +++++++++++-
src/conf/domain_conf.c | 73 +++++++++++++++++++
src/conf/domain_conf.h | 13 ++++
src/conf/schemas/domaincommon.rng | 42 +++++++++++
src/qemu/qemu_command.c | 71 ++++++++++++++++++
src/qemu/qemu_validate.c | 1 +
.../audio-many-backends.x86_64-latest.args | 2 +
.../qemuxml2argvdata/audio-many-backends.xml | 1 +
.../audio-pipewire-best.x86_64-latest.args | 36 +++++++++
.../qemuxml2argvdata/audio-pipewire-best.xml | 43 +++++++++++
.../audio-pipewire-full.x86_64-latest.args | 36 +++++++++
.../qemuxml2argvdata/audio-pipewire-full.xml | 43 +++++++++++
.../audio-pipewire-minimal.x86_64-latest.args | 36 +++++++++
.../audio-pipewire-minimal.xml | 36 +++++++++
tests/qemuxml2argvtest.c | 10 +++
.../audio-many-backends.x86_64-latest.xml | 1 +
.../audio-pipewire-best.x86_64-latest.xml | 46 ++++++++++++
.../audio-pipewire-full.x86_64-latest.xml | 46 ++++++++++++
.../audio-pipewire-minimal.x86_64-latest.xml | 39 ++++++++++
tests/qemuxml2xmltest.c | 3 +
21 files changed, 627 insertions(+), 2 deletions(-)
create mode 100644 tests/qemuxml2argvdata/audio-pipewire-best.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/audio-pipewire-best.xml
create mode 100644 tests/qemuxml2argvdata/audio-pipewire-full.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/audio-pipewire-full.xml
create mode 100644 tests/qemuxml2argvdata/audio-pipewire-minimal.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/audio-pipewire-minimal.xml
create mode 100644 tests/qemuxml2xmloutdata/audio-pipewire-best.x86_64-latest.xml
create mode 100644 tests/qemuxml2xmloutdata/audio-pipewire-full.x86_64-latest.xml
create mode 100644 tests/qemuxml2xmloutdata/audio-pipewire-minimal.x86_64-latest.xml
--
2.41.0
1 year, 4 months
