[PATCH v2 00/11] Enabling logging for ch guests
by Praveen K Paladugu
LogContext management is now moved from Qemu driver to hypervisor. After
migrating Qemu to use domain_logcontext, I extended ch driver to use also use
domain_logcontext to capture early boot failures within domain specific log
files.
Changes in V2:
* refactored the patches to ensure all of them build.
* ch driver will use virtlogd to consolidate logs from hypervisor and its
domains.
Praveen K Paladugu (11):
hypervisor: copy qemu log context mgmt to hypervisor
hypervisor: rename reference to qemu in domain_logcontext
hypervisor: drop qemu specific args in domainLogContextNew
hypervisor: Build domain_logcontext
libvirt_private: export symbols from domain_logcontext
qemu: Modify qemu driver to use domainLogContext
qemu: delete qemu_logcontext files
ch: Enable logging for ch domains
ch: move curl_data and curl_callback definitions
ch: Enable logging curl responses from ch
ch: configure ch driver to use virlogd
po/POTFILES | 2 +-
src/ch/ch_conf.c | 1 +
src/ch/ch_conf.h | 2 +
src/ch/ch_monitor.c | 84 ++++++++++++-------
src/ch/ch_monitor.h | 6 +-
src/ch/ch_process.c | 36 ++++++--
.../domain_logcontext.c} | 78 +++++++++--------
src/hypervisor/domain_logcontext.h | 45 ++++++++++
src/hypervisor/meson.build | 1 +
src/libvirt_private.syms | 6 ++
src/qemu/meson.build | 1 -
src/qemu/qemu_domain.c | 28 +++----
src/qemu/qemu_domain.h | 12 +--
src/qemu/qemu_logcontext.h | 41 ---------
src/qemu/qemu_nbdkit.c | 12 ++-
src/qemu/qemu_process.c | 45 +++++-----
16 files changed, 236 insertions(+), 164 deletions(-)
rename src/{qemu/qemu_logcontext.c => hypervisor/domain_logcontext.c} (79%)
create mode 100644 src/hypervisor/domain_logcontext.h
delete mode 100644 src/qemu/qemu_logcontext.h
--
2.47.0
2 hours, 46 minutes
[PATCH v2 0/4] bhyve: implement domain{Block,Interface,Memory}Stats
by Roman Bogorodskiy
Changes since v1:
- Added "bhyve: implement domainInterfaceStats" patch
PS It was temping to factor out obtaining struct kinfo_proc using
sysctlnametomib() + sysctl(), but I have to make it visible to use
outside of virprocess, e.g. in bhyve_driver.c, so it doesn't look like
it's worth the effort for now. Probably it'll make sense to implement a
FreeBSD version of virProcessGetStat() once there are more users of this
code.
Roman Bogorodskiy (4):
bhyve: implement domainInterfaceStats
virprocess: implement virProcessGetStatInfo() for FreeBSD
bhyve: implement domainMemoryStats
bhyve: implement domainBlockStats
src/bhyve/bhyve_driver.c | 140 +++++++++++++++++++++++++++++++++++++++
src/util/virprocess.c | 104 +++++++++++++++++++++--------
2 files changed, 218 insertions(+), 26 deletions(-)
--
2.49.0
5 hours, 18 minutes
[PATCH 0/5] qemu: Fixes to firmware selection
by Andrea Bolognani
See [1] for the discussion motivating these changes.
[1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/U3...
Andrea Bolognani (5):
tests: Tweak descriptor for combined firmware
tests: Add firmware-auto-efi-sev-snp
qemu: Fix matching for stateless/combined firmware
qemu: Fix matching for read/write firmware
news: Update for firmware selection fixes
NEWS.rst | 6 +++
src/qemu/qemu_firmware.c | 39 +++++++++++++------
.../usr/share/qemu/firmware/90-combined.json | 4 +-
tests/qemufirmwaretest.c | 2 +-
...ware-auto-efi-rw-pflash.x86_64-latest.args | 36 +++++++++++++++++
...mware-auto-efi-rw-pflash.x86_64-latest.err | 1 -
...mware-auto-efi-rw-pflash.x86_64-latest.xml | 6 ++-
.../firmware-auto-efi-rw.x86_64-latest.args | 36 +++++++++++++++++
.../firmware-auto-efi-rw.x86_64-latest.err | 1 -
.../firmware-auto-efi-rw.x86_64-latest.xml | 6 ++-
...auto-efi-sev-snp.x86_64-latest+amdsev.args | 37 ++++++++++++++++++
...auto-efi-sev-snp.x86_64-latest+amdsev.xml} | 9 ++++-
.../firmware-auto-efi-sev-snp.xml | 20 ++++++++++
tests/qemuxmlconftest.c | 8 +++-
14 files changed, 190 insertions(+), 21 deletions(-)
create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.args
delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw-pflash.x86_64-latest.err
create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.args
delete mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-rw.x86_64-latest.err
create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.x86_64-latest+amdsev.args
copy tests/qemuxmlconfdata/{firmware-auto-efi-rw-pflash.x86_64-latest.xml => firmware-auto-efi-sev-snp.x86_64-latest+amdsev.xml} (76%)
create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-sev-snp.xml
--
2.50.1
3 days, 21 hours
[PATCH v2 18/24] qapi/migration: Deprecate capabilities commands
by Fabiano Rosas
The concept of capabilities is being merged into the concept of
parameters. From now on, the commands that handle capabilities are
deprecated in favor of the commands that handle parameters.
Affected commands:
- migrate-set-capabilities
- query-migrate-capabilities
Signed-off-by: Fabiano Rosas <farosas(a)suse.de>
---
docs/about/deprecated.rst | 12 ++++++++++++
migration/migration-hmp-cmds.c | 6 ++++++
qapi/migration.json | 16 ++++++++++++++--
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 42037131de..15474833ea 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -605,3 +605,15 @@ command documentation for details on the ``fdset`` usage.
The ``zero-blocks`` capability was part of the block migration which
doesn't exist anymore since it was removed in QEMU v9.1.
+
+``migrate-set-capabilities`` command (since 10.1)
+'''''''''''''''''''''''''''''''''''''''''''''''''
+
+This command was deprecated. Use ``migrate-set-parameters`` instead
+which now supports setting capabilities.
+
+``query-migrate-capabilities`` command (since 10.1)
+'''''''''''''''''''''''''''''''''''''''''''''''''''
+
+This command was deprecated. Use ``query-migrate-parameters`` instead
+which now supports querying capabilities.
diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
index 8615340a6b..7f234d5aa8 100644
--- a/migration/migration-hmp-cmds.c
+++ b/migration/migration-hmp-cmds.c
@@ -229,6 +229,9 @@ void hmp_info_migrate_capabilities(Monitor *mon, const QDict *qdict)
{
MigrationCapabilityStatusList *caps, *cap;
+ warn_report("info migrate_capabilities is deprecated;"
+ " use info migrate_parameters instead");
+
caps = qmp_query_migrate_capabilities(NULL);
if (caps) {
@@ -616,6 +619,9 @@ void hmp_migrate_set_capability(Monitor *mon, const QDict *qdict)
MigrationCapabilityStatus *value;
int val;
+ warn_report("migrate_set_capability is deprecated;"
+ " use migrate_set_parameter instead");
+
val = qapi_enum_parse(&MigrationCapability_lookup, cap, -1, &err);
if (val < 0) {
goto end;
diff --git a/qapi/migration.json b/qapi/migration.json
index 3d3f5624c5..c5e6ea1a2d 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -521,6 +521,11 @@
#
# @capabilities: json array of capability modifications to make
#
+# Features:
+#
+# @deprecated: This command is deprecated in favor of
+# migrate-set-parameters.
+#
# Since: 1.2
#
# .. qmp-example::
@@ -530,7 +535,8 @@
# <- { "return": {} }
##
{ 'command': 'migrate-set-capabilities',
- 'data': { 'capabilities': ['MigrationCapabilityStatus'] } }
+ 'data': { 'capabilities': ['MigrationCapabilityStatus'] },
+ 'features': ['deprecated'] }
##
# @query-migrate-capabilities:
@@ -539,6 +545,11 @@
#
# Returns: @MigrationCapabilityStatus
#
+# Features:
+#
+# @deprecated: This command is deprecated in favor of
+# query-migrate-parameters.
+#
# Since: 1.2
#
# .. qmp-example::
@@ -554,7 +565,8 @@
# {"state": false, "capability": "x-colo"}
# ]}
##
-{ 'command': 'query-migrate-capabilities', 'returns': ['MigrationCapabilityStatus']}
+{ 'command': 'query-migrate-capabilities', 'returns': ['MigrationCapabilityStatus'],
+ 'features': ['deprecated'] }
##
# @MultiFDCompression:
--
2.35.3
4 days, 21 hours
[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
5 days, 11 hours
[PATCH] qemu: don't warn about missing SMM for CVM firmware
by Daniel P. Berrangé
From: Daniel P. Berrangé <berrange(a)redhat.com>
Neither Intel TDX / AMD SEV(SNP) allow use of SMM, but the EDK2
firmware none the less supports secureboot. Libvirt currently
issues bogus warnings about Fedora firmware
warning : qemuFirmwareSanityCheck:1575 : Firmware description
'/usr/share/qemu/firmware/60-edk2-ovmf-x64-inteltdx.json' has
invalid set of features: requires-smm = 0, secure-boot = 1,
enrolled-keys = 1
This removes the warning if the firmware descriptor indicates use
of any confidential VM technology.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/qemu/qemu_firmware.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c
index f10137144e..dbec068738 100644
--- a/src/qemu/qemu_firmware.c
+++ b/src/qemu/qemu_firmware.c
@@ -1540,6 +1540,7 @@ qemuFirmwareSanityCheck(const qemuFirmware *fw,
bool requiresSMM = false;
bool supportsSecureBoot = false;
bool hasEnrolledKeys = false;
+ bool cvm = false;
for (i = 0; i < fw->nfeatures; i++) {
switch (fw->features[i]) {
@@ -1552,13 +1553,15 @@ qemuFirmwareSanityCheck(const qemuFirmware *fw,
case QEMU_FIRMWARE_FEATURE_ENROLLED_KEYS:
hasEnrolledKeys = true;
break;
- case QEMU_FIRMWARE_FEATURE_NONE:
- case QEMU_FIRMWARE_FEATURE_ACPI_S3:
- case QEMU_FIRMWARE_FEATURE_ACPI_S4:
case QEMU_FIRMWARE_FEATURE_AMD_SEV:
case QEMU_FIRMWARE_FEATURE_AMD_SEV_ES:
case QEMU_FIRMWARE_FEATURE_AMD_SEV_SNP:
case QEMU_FIRMWARE_FEATURE_INTEL_TDX:
+ cvm = true;
+ break;
+ case QEMU_FIRMWARE_FEATURE_NONE:
+ case QEMU_FIRMWARE_FEATURE_ACPI_S3:
+ case QEMU_FIRMWARE_FEATURE_ACPI_S4:
case QEMU_FIRMWARE_FEATURE_VERBOSE_DYNAMIC:
case QEMU_FIRMWARE_FEATURE_VERBOSE_STATIC:
case QEMU_FIRMWARE_FEATURE_LAST:
@@ -1566,7 +1569,8 @@ qemuFirmwareSanityCheck(const qemuFirmware *fw,
}
}
- if ((supportsSecureBoot != requiresSMM) ||
+ if ((!cvm &&
+ (supportsSecureBoot != requiresSMM)) ||
(hasEnrolledKeys && !supportsSecureBoot)) {
VIR_WARN("Firmware description '%s' has invalid set of features: "
"%s = %d, %s = %d, %s = %d",
--
2.50.1
6 days, 10 hours
[PATCH] Storage: ZFS: implement `resizeVol` method to support native resize
by George Melikov
From: George Melikov <mail(a)gmelikov.ru>
ZFS doesn't have thick allocations, every allocation is
thin-provisioned, so resize operation is essentially
a zvol size limit change
(`zfs set volsize=X pool/zvol_name`).
Shrink is allowed too (which leads to data destruction),
but shrink restriction is already implemented in libvirt,
so this function doesn't need to check anything.
This patch is posted via PR too and has green test runs
https://gitlab.com/libvirt/libvirt/-/merge_requests/495
Signed-off-by: George Melikov <mail(a)gmelikov.ru>
---
src/storage/storage_backend_zfs.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/src/storage/storage_backend_zfs.c b/src/storage/storage_backend_zfs.c
index 178b505e92..33434d0cac 100644
--- a/src/storage/storage_backend_zfs.c
+++ b/src/storage/storage_backend_zfs.c
@@ -439,6 +439,25 @@ virStorageBackendZFSDeletePool(virStoragePoolObj *pool,
return virCommandRun(cmd, NULL);
}
+static int
+virStorageBackendZFSResizeVol(virStoragePoolObj *pool,
+ virStorageVolDef *vol,
+ unsigned long long capacity,
+ unsigned int flags)
+{
+ virStoragePoolDef *def = virStoragePoolObjGetDef(pool);
+ g_autoptr(virCommand) resize_cmd = NULL;
+
+ virCheckFlags(0, -1);
+
+ resize_cmd = virCommandNewArgList(ZFS, "set", NULL);
+ virCommandAddArgFormat(resize_cmd, "volsize=%llu", capacity);
+ virCommandAddArgFormat(resize_cmd, "%s/%s",
+ def->source.name, vol->name);
+
+ return virCommandRun(resize_cmd, NULL);
+}
+
virStorageBackend virStorageBackendZFS = {
.type = VIR_STORAGE_POOL_ZFS,
@@ -450,6 +469,7 @@ virStorageBackend virStorageBackendZFS = {
.deletePool = virStorageBackendZFSDeletePool,
.uploadVol = virStorageBackendVolUploadLocal,
.downloadVol = virStorageBackendVolDownloadLocal,
+ .resizeVol = virStorageBackendZFSResizeVol,
};
--
2.47.2
6 days, 10 hours
[PATCH 0/5] Cleanup of callers of virDomainDefGetVcpu
by Peter Krempa
Fix few issues with how virDomainDefGetVcpu is called and in related
code.
Peter Krempa (5):
Unexport virCHProcessSetupVcpu
virDomainVcpuDefPostParse: Remove impossible check
qemu: domain: Remove unused qemuDomainGetVcpuHalted
virCHDomainRefreshThreadInfo: Don't trust vcpu ID returned by
hypervisor
virCHDomainRefreshThreadInfo: Remove illusion that caller cares about
return value
src/ch/ch_domain.c | 17 ++++++++++-------
src/ch/ch_domain.h | 2 +-
src/ch/ch_process.c | 2 +-
src/ch/ch_process.h | 3 ---
src/conf/domain_postparse.c | 4 ----
src/qemu/qemu_domain.c | 15 ---------------
src/qemu/qemu_domain.h | 1 -
7 files changed, 12 insertions(+), 32 deletions(-)
--
2.50.1
6 days, 10 hours
[RFC] x86 Host CPU features detection by MSRs
by Hector Cao
Hello,
This mail is a Request for Comment.
On recent Intel CPUs, some of the CPU features (mostly vmx-* subfeatures)
are listed and controlled
via the MSRs (Model Specific Registers) instead of the traditional CPUID
instruction method.
Right now, libvirt reads the MSR's values via /dev/cpu/*/cpu populated by
the msr kernel module.
src/cpu/cpu_x86.c:
...
/* This is best effort since there might be no way to read the MSR
* when we are not running as root. */
for (i = 0; i < nmsrs; i++) {
if (virHostCPUGetMSR(msrs[i], &msr) == 0) {
virCPUx86DataItem item = {
.type = VIR_CPU_X86_DATA_MSR,
.data.msr = {
...
There are 2 potential issues:
1) As stated in the source code comment above, MSR values read might fail
when libvirt is not run as root.
2) MSR values read might fail if the MSR kernel module is not loaded, this
is still the case in some of the Linux distros.
The issue 2) has been brought up in Ubuntu/Debian :
https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/271
but the feedback was to try to fix the issue in the libvirt source code
itself. Indeed, libvirt already loads some kernel modules it depends on.
For example the NBD kernel module in src/util/virtfile.c
...
static bool
virFileNBDLoadDriver(void)
{
if (virKModIsProhibited(NBD_DRIVER)) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Failed to load nbd module: administratively
prohibited"));
return false;
} else {
g_autofree char *errbuf = NULL;
if ((errbuf = virKModLoad(NBD_DRIVER))) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Failed to load nbd module"));
...
Andrea Bolognani's proposal of an approach that could work:
1. try using the unprivileged KVM API is available (or maybe the
necessary information is exposed via QMP too?) like how QEMU does;
2. if that fails, try using the privileged /dev API;
3. if that fails too, load the msr module and try again;
I would like to have some feedback from the libvirt community about if that
is worth tackling these issues and the right way to do that.
If we can end up with an agreement in this mail thread, I can work on the
solution implementation and send it in a separate submission.
Best regards,
Hector
6 days, 10 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
6 days, 10 hours
