[PATCH 0/1] [RFC] Live migration support for ch driver
by Stefan Kober
This change serves as a proof of concept that adds live migration support to
the Cloud Hypervisor driver. It is meant to show feasibility and to receive
early feedback.
I tested the live migration by invoking:
virsh -c ch:///session migrate --domain vmName --desturi ch+ssh://dstHost/session --live
Opens:
* What is required for a minimal viable live migration to be merged?
* Job state tracking? (virDomainObjBeginJob, ...)
* What should 'virsh domjobinfo' show?
* Testing?
* Anything else?
Stefan Kober (1):
Initial CH migrate API
src/ch/ch_conf.h | 4 +
src/ch/ch_domain.h | 2 +
src/ch/ch_driver.c | 362 +++++++++++++++++++++++++++++-
src/ch/ch_monitor.c | 156 +++++++++++++
src/ch/ch_monitor.h | 8 +
src/ch/ch_process.c | 136 ++++++++++-
src/ch/ch_process.h | 6 +
src/hypervisor/domain_interface.c | 1 +
src/libvirt-domain.c | 15 +-
9 files changed, 680 insertions(+), 10 deletions(-)
--
2.49.0
15 hours, 28 minutes
[PATCH] docs: fix indent of hostdev examples
by Daniel P. Berrangé
From: Daniel P. Berrangé <berrange(a)redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
docs/formatdomain.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 8753ee9c23..ca4e84983f 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -4600,15 +4600,15 @@ or:
...
<devices>
<hostdev mode='subsystem' type='mdev' model='vfio-pci'>
- <source>
- <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'/>
- </source>
+ <source>
+ <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'/>
+ </source>
</hostdev>
<hostdev mode='subsystem' type='mdev' model='vfio-ccw'>
<source>
<address uuid='9063cba3-ecef-47b6-abcf-3fef4fdcad85'/>
</source>
- <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
+ <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
</hostdev>
</devices>
...
--
2.49.0
17 hours, 21 minutes
[PATCH 0/1] cpu_map: fix vmx-* features wrong bitmaps
by Hector Cao
Hello,
I'm unable to make virsh capabilities to detect the right CPU model
on an Intel Granite Rapids platform. I would expect the get the
CPU model defined in one of the src/cpu_map/x86_GraniteRapids*.xml
files.
The cause of the wrong detection is the fact that some vmx-* are
not correctly detected and considered missing on this platform.
When I take a look at the src/cpu_map/x86_features.xml file, I
think that some of the vmx-* are wrongly defined.
Taking as an example the vmx-apicv-xapic feature, it is defined as
the first bit in the EAX register when we read the MSR 0x0000048b .
But in Intel specification, this feature is represented as the first
bit in the EDX register (32 higher bits).
You can find in this submission the patch that fixes this issue,
and this for all the affected MSRs.
I tested this fix on my Granite Rapids platform and the CPU model
is now correctly detected.
Hector Cao (1):
cpu_map: fix vmx-* features wrong bitmaps
src/cpu_map/x86_features.xml | 136 +++++++++++++++++------------------
1 file changed, 68 insertions(+), 68 deletions(-)
--
2.45.2
1 day, 6 hours
[RFC PATCH 0/5] qemu: Implement support for iommufd and multiple vSMMUs
by Nathan Chen
Hi,
This is a follow up to the first RFC patchset [0] for supporting multiple
vSMMU instances in a qemu VM. This patchset also introduces support for
using iommufd to propagate DMA mappings to kernel for assigned devices.
This patchset implements support for specifying multiple <iommu> devices
within the VM definition when smmuv3Dev IOMMU model is specified, and is
tested with Shameer's latest qemu RFC for HW-accelerated vSMMU devices [1]
Moreover, it adds a new 'iommufd' member for virDomainIOMMUDef,
in order to represent the iommufd object in qemu command line. This
patchset also implements new 'iommufdId' and 'iommufdFd' attributes for
hostdev devices to be associated with the iommufd object.
For instance, specifying the iommufd object and associated hostdev in a
VM definition with multiple IOMMUs, configured to be routed to
pcie-expander-bus controllers in a way where VFIO device to SMMUv3
associations are matched with the host (pcie-expander-bus and
pcie-root-port controllers are no longer auto-added/auto-routed
like in the first revision of this RFC, as the PCIe topology will be
configured by management apps):
<devices>
...
<controller type='pci' index='1' model='pcie-expander-bus'>
<model name='pxb-pcie'/>
<target busNr='252'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
</controller>
<controller type='pci' index='2' model='pcie-expander-bus'>
<model name='pxb-pcie'/>
<target busNr='248'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</controller>
...
<controller type='pci' index='21' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='21' port='0x0'/>
<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
</controller>
<controller type='pci' index='22' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='22' port='0xa8'/>
<address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
</controller>
...
<hostdev mode='subsystem' type='pci' managed='no'>
<source>
<address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/>
</source>
<iommufdId>iommufd0</iommufdId>
<address type='pci' domain='0x0000' bus='0x15' slot='0x00' function='0x0'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='no'>
<source>
<address domain='0x0019' bus='0x01' slot='0x00' function='0x0'/>
</source>
<iommufdId>iommufd0</iommufdId>
<address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/>
</hostdev>
<iommu model='smmuv3Dev'>
<iommufd>
<id>iommufd0</id>
</iommufd>
<address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
</iommu>
<iommu model='smmuv3Dev'>
<iommufd>
<id>iommufd0</id>
</iommufd>
<address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/>
</iommu>
</devices>
This would get translated to a qemu command line with the arguments below:
-device '{"driver":"pxb-pcie","bus_nr":252,"id":"pci.1","bus":"pcie.0","addr":"0x1"}' \
-device '{"driver":"pxb-pcie","bus_nr":248,"id":"pci.2","bus":"pcie.0","addr":"0x2"}' \
-device '{"driver":"pcie-root-port","port":0,"chassis":21,"id":"pci.21","bus":"pci.1","addr":"0x0"}' \
-device '{"driver":"pcie-root-port","port":168,"chassis":22,"id":"pci.22","bus":"pci.2","addr":"0x0"}' \
-object '{"qom-type":"iommufd","id":"iommufd0"}' \
-device '{"driver":"arm-smmuv3-accel","bus":"pci.1"}' \
-device '{"driver":"arm-smmuv3-accel","bus":"pci.2"}' \
-device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","iommufd":"iommufd0","bus":"pci.21","addr":"0x0"}' \
-device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","iommufd":"iommufd0","bus":"pci.22","addr":"0x0"}' \
If users would like to leverage qemu's iommufd feature to open the VFIO
cdev and /dev/iommu via an external management layer, the fd can be
specified like so in the VM definition:
<devices>
<hostdev mode='subsystem' type='pci' managed='yes'>
<driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x06' slot='0x12' function='0x2'/>
</source>
<iommufdId>iommufd0</iommufdId>
<iommufdFd>23</iommufdFd>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</hostdev>
<iommu model='intel'>
<iommufd>
<id>iommufd0</id>
<fd>22</fd>
</iommufd>
</iommu>
</devices>
This would get translated to a qemu command line with the arguments below:
-object '{"qom-type":"iommufd","id":"iommufd0","fd":"22"}' \
-device '{"driver":"vfio-pci","host":"0000:06:12.2","id":"hostdev1","iommufd":"iommufd0","fd":"23","bus":"pci.0","addr":"0x3"}' \
Summary of changes:
- Introduced support for specifying multiple <iommu> stanzas in the VM
XML definition when using smmuv3Dev model.
- Automating PCIe topology to populate VM definition with multiple vSMMUs
routed to pcie-expander-bus controllers is excluded, in favor of
deferring creation of PXBs and routing of VFIO devices to management apps.
- Introduced iommufd support.
TODO:
- I updated the namespace and cgroup configuration to allow access to iommufd
paths at /dev/vfio/devices/vfio* and /dev/iommu. However, qemu needs to be
launched with user and group set to 'root' in order for these paths to be
accessible. A passthrough device represented by /dev/vfio/18 normally has
'root' user and group permissions, but in the mount namespace it's changed to
'libvirt-qemu' and 'kvm'. I wasn't able to discern where this is happening by
looking at src/qemu/qemu_namespace.c and src/qemu/qemu_cgroup.c. Would you have
any pointers on how to change the iommufd paths' user and group permissions in
the libvirt mount namespace?
This series is on Github:
https://github.com/NathanChenNVIDIA/libvirt/tree/smmuv3Dev-iommufd-04-15-25
Thanks,
Nathan
[0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/7G...
[1] https://lore.kernel.org/qemu-devel/20250311141045.66620-1-shameerali.kolo...
Signed-off-by: Nathan Chen <nathanc(a)nvidia.com>
Nathan Chen (5):
conf: Support multiple smmuv3Dev IOMMU devices
conf: Add an iommufd member struct to virDomainIOMMUDef
qemu: Implement support for associating iommufd to hostdev
qemu: Update Cgroup and namespace for qemu to access iommufd paths
qemu: Add test case for specifying iommufd
docs/formatdomain.rst | 5 +-
src/conf/domain_addr.c | 12 +-
src/conf/domain_addr.h | 4 +-
src/conf/domain_conf.c | 292 ++++++++++++++++--
src/conf/domain_conf.h | 21 +-
src/conf/domain_validate.c | 94 +++++-
src/conf/schemas/domaincommon.rng | 37 ++-
src/conf/virconftypes.h | 2 +
src/libvirt_private.syms | 2 +
src/qemu/qemu_alias.c | 15 +-
src/qemu/qemu_cgroup.c | 47 +++
src/qemu/qemu_cgroup.h | 1 +
src/qemu/qemu_command.c | 146 ++++++---
src/qemu/qemu_domain_address.c | 33 +-
src/qemu/qemu_driver.c | 8 +-
src/qemu/qemu_namespace.c | 36 +++
src/qemu/qemu_postparse.c | 11 +-
src/qemu/qemu_validate.c | 22 +-
...fio-iommufd-intel-iommu.x86_64-latest.args | 43 +++
...vfio-iommufd-intel-iommu.x86_64-latest.xml | 80 +++++
.../hostdev-vfio-iommufd-intel-iommu.xml | 80 +++++
tests/qemuxmlconftest.c | 1 +
22 files changed, 878 insertions(+), 114 deletions(-)
create mode 100644 tests/qemuxmlconfdata/hostdev-vfio-iommufd-intel-iommu.x86_64-latest.args
create mode 100644 tests/qemuxmlconfdata/hostdev-vfio-iommufd-intel-iommu.x86_64-latest.xml
create mode 100644 tests/qemuxmlconfdata/hostdev-vfio-iommufd-intel-iommu.xml
--
2.43.0
3 days, 3 hours
[RFC PATCH 0/2] Fix forward type=hostdev nets for apparmor
by Tim Small
I'm working on a fix for a bug whereby apparmor permissions aren't
granted to allow a PCI SR-IOV virtual function to be used in a kvm guest
when the VF is defined via a forward type='hostdev' network (as per the
'hostdev' option documented here:
https://libvirt.org/formatnetwork.html#connectivity ).
Downstream bug here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993856
I'm not sure if the attached patches are sufficient. When I compare the
apparmor permissions file for a guest with a VF shared via forward
type='hostdev' vs. the same guest with a VF shared via a PCI hostdev
device, the latter has extra apparmor permissions for files like:
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource3_wc" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource0_wc" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource3" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/vendor" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/reset" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/device" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource0" rw,
"/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/config" rw,
... however both guests appear to function in my test environment
(Debian 13, 6.12.22-amd64) - i.e. both with and without those entries.
So I don't know if those permissions are unneeded, or if they are
granted at runtime instead. If those permissions are needed, then I'd
appreciate any hints on how to modify virt-aa-helper to discover the PCI
address. I appreciate that might not actually be possible because that
is dynamically allocated, and so might race - so some other solution
might be required.
Many Thanks,
Tim.
Tim Small (2):
virt-aa-helper: refactor for readability
virt-aa-helper: Allow SR-IOV VF PCI for hostdev networks
.../apparmor/usr.lib.libvirt.virt-aa-helper.in | 3 +++
src/security/virt-aa-helper.c | 18 ++++++++++++++----
2 files changed, 17 insertions(+), 4 deletions(-)
--
2.47.2
3 days, 12 hours
[PATCH v2] NEWS: Mention removal of compile time helper program lookup, virito-net ABI check and FDC capabilities
by Peter Krempa
From: Peter Krempa <pkrempa(a)redhat.com>
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
v2:
- moved the entry about $PATH lookup under "packaging changes"
- added a note that it fixes libvirt on distros which merged /sbin to
/bin but only on new installs
NEWS.rst | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index fd577021b3..d1bb19c8db 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -21,6 +21,25 @@ v11.4.0 (unreleased)
Support for the recently released IBM POWER11 processor was added.
+* **Packaging changes**
+
+ * All helper programs are now detected from ``$PATH`` during runtime
+
+ All of the code was now converted to dynamically look up helper programs
+ in ``$PATH`` rather than doing the lookup at build time and then compiling
+ in the result.
+
+ Programs ``mount``, ``umount``, ``mkfs``, ``modprobe``, ``rmmod``,
+ ``numad``, ``dmidecode``, ``ip``, ``tc``, ``mdevctl``, ``mm-ctl``,
+ ``iscsiadm``, ``ovs-vsctl``, ``pkttyagent``, ``bhyveload``, ``bhyvectl``,
+ ``bhyve``, ``ifconfig``, ``vzlist``, ``vzctl``, ``vzmigrate``, and the
+ tools from the lvm suite (``vgchange``, ``lvcreate``, etc..) are now not
+ needed during build and will still work properly if placed in ``$PATH``.
+
+ This also ensures that libvirt works correctly on distros that are
+ transitioning ``/sbin`` into ``/bin`` and upgraded installations have
+ a different layout from fresh installations.
+
* **Improvements**
* virsh: Add option ``--no-pkttyagent``
@@ -35,6 +54,11 @@ v11.4.0 (unreleased)
<nvram/>
</os>
+ * qemu: Improve accuracy of FDC/floppy device support statement in capabilities XML
+
+ The data is now based on the presence of the controller in qemu rather than
+ just a denylist of machine types where floppies not work.
+
* **Bug fixes**
* qemu: Fix failure when reverting to internal snapshots
@@ -52,6 +76,13 @@ v11.4.0 (unreleased)
destination host to crash when trying to resume failed post-copy
migration.
+ * qemu: Treat the ``queues`` configuration of ``virtio-net`` as guest ABI
+
+ The queue count itself isn't a device frontend property but libvirt uses
+ it to calculate ``vectors`` option of the device which is a guest OS visible
+ property, thus ``queues`` must not change during migration. The ABI stability
+ check now handles this properly.
+
v11.3.0 (2025-05-02)
====================
--
2.49.0
3 days, 14 hours
Re: [PATCH v4 00/27] hw/i386/pc: Remove deprecated 2.6 and 2.7 PC
machines
by Igor Mammedov
On Thu, 8 May 2025 15:35:23 +0200
Philippe Mathieu-Daudé <philmd(a)linaro.org> wrote:
> Since v3:
> - Addressed Thomas and Zhao review comments
> - Rename fw_cfg_init_mem_[no]dma() helpers
> - Remove unused CPU properties
> - Remove {multi,linux}boot.bin
> - Added R-b tags
>
> Since v2:
> - Addressed Mark review comments and added his R-b tags
>
> The versioned 'pc' and 'q35' machines up to 2.12 been marked
> as deprecated two releases ago, and are older than 6 years,
> so according to our support policy we can remove them.
>
> This series only includes the 2.6 and 2.7 machines removal,
> as it is a big enough number of LoC removed. Rest will
> follow.
CCing libvirt folks
series removes some properties that has been used as compat
knobs with 2.6/2.7 machine types that are being removed.
However libvirt might still use them,
please check if being removed properties are safe to remove
as is | should be deprecated 1st | should be left alone
from an immediate user perspective.
>
> Based-on: <20250506143905.4961-1-philmd(a)linaro.org>
>
[...]
3 days, 14 hours
[PATCHv2] passt: Define backend hostname and fqdn
by Enrique Llorente
This commit introduces a feature enhancement for configuring hostnames in
virtual machines (VMs) using DHCP. It adds new options to the "passt" tool
to set the hostname and fully qualified domain name (FQDN) for VMs. These
map to DHCP option 12 for the hostname and options 81 (IPv4) and 39 (IPv6)
for the FQDN.
The update enables passt to dynamically assign hostnames to DHCP-aware
VMs. To achieve this, the commit adds two fields to the passt domain XML
backend. These fields allow passt to configure the hostname and FQDN for
the virtual machine, ensuring smooth integration with the DHCP protocol.
This improvement is particularly valuable in environments where VMs need
dynamic hostname configuration, enhancing flexibility and automation in
virtualized network setups.
libvirt: Integrate passt --hostname --fqdn options
Resolves: https://issues.redhat.com/browse/RHEL-79806
Signed-off-by: Enrique Llorente <ellorent(a)redhat.com>
---
Compared to v1 this fix the mapping between backend fqdn and hostname
docs/formatdomain.rst | 8 +++++---
src/conf/domain_conf.c | 10 +++++++++-
src/conf/domain_conf.h | 2 ++
src/conf/schemas/domaincommon.rng | 6 ++++++
src/qemu/qemu_passt.c | 6 ++++++
tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml | 2 +-
tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml | 2 +-
tests/qemuxmlconfdata/net-user-passt.xml | 2 +-
.../net-vhostuser-passt.x86_64-latest.xml | 2 +-
tests/qemuxmlconfdata/net-vhostuser-passt.xml | 2 +-
10 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 8753ee9c23..9c80aa9270 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -5372,10 +5372,12 @@ came from the host's IP.
There are a few other options that are configurable only for the passt
backend. For example, the ``<backend>`` attribute ``logFile`` can be
used to tell the passt process for this interface where to write its
-message log, and the ``<source>`` attribute ``dev`` can tell it a
+message log, the ``<source>`` attribute ``dev`` can tell it a
particular host interface to use when deriving the routes given to the
-guest for forwarding traffic upstream. Due to the design decisions of
-passt, when using SELinux on the host, it is recommended that the log
+guest for forwarding traffic upstream and the ``hostname`` and ``fqdn``
+will conigure the DHCP option 12 hostname and DHCP option 81 and DHCPv6
+option 39 fqdn attribute. Due to the design decisions of passt, when using
+SELinux on the host, it is recommended that the log
file reside in the runtime directory of the user under which the passt
process will run, most probably ``/run/user/$UID`` (where ``$UID`` is
the UID of that user), e.g. ``/run/user/1000``. Be aware that libvirt
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index b3b0bd7329..15143f8fa2 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -2909,6 +2909,8 @@ virDomainNetDefFree(virDomainNetDef *def)
g_free(def->backend.tap);
g_free(def->backend.vhost);
g_free(def->backend.logFile);
+ g_free(def->backend.hostname);
+ g_free(def->backend.fqdn);
virDomainNetTeamingInfoFree(def->teaming);
g_free(def->virtPortProfile);
g_free(def->script);
@@ -9757,6 +9759,8 @@ virDomainNetBackendParseXML(xmlNodePtr node,
}
def->backend.logFile = virXMLPropString(node, "logFile");
+ def->backend.hostname = virXMLPropString(node, "hostname");
+ def->backend.fqdn = virXMLPropString(node, "fqdn");
if (tap)
def->backend.tap = virFileSanitizePath(tap);
@@ -20757,7 +20761,9 @@ virDomainNetBackendIsEqual(virDomainNetBackend *src,
if (src->type != dst->type ||
STRNEQ_NULLABLE(src->tap, dst->tap) ||
STRNEQ_NULLABLE(src->vhost, dst->vhost) ||
- STRNEQ_NULLABLE(src->logFile, dst->logFile)) {
+ STRNEQ_NULLABLE(src->logFile, dst->logFile) ||
+ STRNEQ_NULLABLE(src->hostname, dst->hostname) ||
+ STRNEQ_NULLABLE(src->fqdn, dst->fqdn)) {
return false;
}
return true;
@@ -24838,6 +24844,8 @@ virDomainNetBackendFormat(virBuffer *buf,
virBufferEscapeString(&attrBuf, " tap='%s'", backend->tap);
virBufferEscapeString(&attrBuf, " vhost='%s'", backend->vhost);
virBufferEscapeString(&attrBuf, " logFile='%s'", backend->logFile);
+ virBufferEscapeString(&attrBuf, " hostname='%s'", backend->hostname);
+ virBufferEscapeString(&attrBuf, " fqdn='%s'", backend->fqdn);
virXMLFormatElement(buf, "backend", &attrBuf, NULL);
}
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 58b97a2b54..79fd2f1f63 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1067,6 +1067,8 @@ struct _virDomainNetBackend {
char *vhost;
/* The following are currently only valid/used when backend type='passt' */
char *logFile; /* path to logfile used by passt process */
+ char *hostname; /* hostname of the passt process */
+ char *fqdn; /* fully qualified domain name of the passt process */
};
struct _virDomainNetPortForwardRange {
diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincommon.rng
index 5597d5a66b..f64199ca18 100644
--- a/src/conf/schemas/domaincommon.rng
+++ b/src/conf/schemas/domaincommon.rng
@@ -3913,6 +3913,12 @@
<ref name="absFilePath"/>
</attribute>
</optional>
+ <optional>
+ <attribute name="hostname"/>
+ </optional>
+ <optional>
+ <attribute name="fqdn"/>
+ </optional>
</element>
</optional>
<optional>
diff --git a/src/qemu/qemu_passt.c b/src/qemu/qemu_passt.c
index fcc34de384..81e5c51f6c 100644
--- a/src/qemu/qemu_passt.c
+++ b/src/qemu/qemu_passt.c
@@ -229,6 +229,12 @@ qemuPasstStart(virDomainObj *vm,
if (net->backend.logFile)
virCommandAddArgList(cmd, "--log-file", net->backend.logFile, NULL);
+ if (net->backend.hostname)
+ virCommandAddArgList(cmd, "--hostname", net->backend.hostname, NULL);
+
+ if (net->backend.fqdn)
+ virCommandAddArgList(cmd, "--fqdn", net->backend.fqdn, NULL);
+
/* Add IP address info */
for (i = 0; i < net->guestIP.nips; i++) {
const virNetDevIPAddr *ip = net->guestIP.ips[i];
diff --git a/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml b/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml
index cfe07cc627..77da297936 100644
--- a/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml
+++ b/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml
@@ -50,7 +50,7 @@
<range start='443' to='344'/>
</portForward>
<model type='rtl8139'/>
- <backend type='passt' logFile='/var/log/loglaw.blog'/>
+ <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</interface>
<input type='mouse' bus='ps2'/>
diff --git a/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml b/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml
index d7e0ef5f90..917a9edaa0 100644
--- a/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml
+++ b/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml
@@ -50,7 +50,7 @@
<range start='443' to='344'/>
</portForward>
<model type='rtl8139'/>
- <backend type='passt' logFile='/var/log/loglaw.blog'/>
+ <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</interface>
<input type='mouse' bus='ps2'/>
diff --git a/tests/qemuxmlconfdata/net-user-passt.xml b/tests/qemuxmlconfdata/net-user-passt.xml
index 20c9f50542..80d15de2ed 100644
--- a/tests/qemuxmlconfdata/net-user-passt.xml
+++ b/tests/qemuxmlconfdata/net-user-passt.xml
@@ -47,7 +47,7 @@
<range start='443' to='344'/>
</portForward>
<model type='rtl8139'/>
- <backend type='passt' logFile='/var/log/loglaw.blog'/>
+ <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</interface>
<input type='mouse' bus='ps2'/>
diff --git a/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml b/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml
index 529aff11f8..5802754c4b 100644
--- a/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml
+++ b/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml
@@ -53,7 +53,7 @@
<range start='443' to='344'/>
</portForward>
<model type='virtio'/>
- <backend type='passt' logFile='/var/log/loglaw.blog'/>
+ <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</interface>
<interface type='vhostuser'>
diff --git a/tests/qemuxmlconfdata/net-vhostuser-passt.xml b/tests/qemuxmlconfdata/net-vhostuser-passt.xml
index 71b845329b..0a37511a0f 100644
--- a/tests/qemuxmlconfdata/net-vhostuser-passt.xml
+++ b/tests/qemuxmlconfdata/net-vhostuser-passt.xml
@@ -50,7 +50,7 @@
<range start='443' to='344'/>
</portForward>
<model type='virtio'/>
- <backend type='passt' logFile='/var/log/loglaw.blog'/>
+ <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</interface>
<interface type='vhostuser'>
--
2.49.0
3 days, 15 hours
Plans for 11.4.0 release (freeze on 2025-05-27)
by Jiri Denemark
We are getting close to 11.4.0 release of libvirt. To aim for the
release on Monday 02 Jun I suggest entering the freeze on Tuesday 27 May
and tagging RC2 on Friday 30 May.
I hope this works for everyone.
Jirka
3 days, 20 hours
[PATCH] virConnectAuthCallbackDefault: Return failure if 'virGetPassword' returns NULL
by Peter Krempa
From: Peter Krempa <pkrempa(a)redhat.com>
virGetPassword can return NULL on linux or BSD if it fails. The caller
in virConnectAuthCallbackDefault does dereference it unconditionally.
Return failure if virGetPassword returns NULL.
Fixes: db72866310d1e520efa8ed2d4589bdb5e76a1c95
Closes: https://gitlab.com/libvirt/libvirt/-/issues/777
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/libvirt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index 581fc6deea..375d3fa7ef 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -158,7 +158,9 @@ virConnectAuthCallbackDefault(virConnectCredentialPtr cred,
if (fflush(stdout) != 0)
return -1;
- bufptr = virGetPassword();
+ if (!(bufptr = virGetPassword()))
+ return -1;
+
if (STREQ(bufptr, ""))
VIR_FREE(bufptr);
break;
--
2.49.0
4 days, 6 hours
