May 2025 - Devel - Libvirt List Archives

[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

4
16
0 / 0

[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

3
5
0 / 0

[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

6
10
0 / 0

Question about SEV* guests and automatic firmware selection

by Jim Fehlig

Hi All, While investigating an internal bug report, we noticed that a minimal firmware auto-selection configuration along with SEV* fails to find a match. E.g. the following config <domain type="kvm"> <os firmware="efi"> <type arch="x86_64" machine="q35">hvm</type> <boot dev="hd"/> </os> <launchSecurity type="sev"> <policy>0x07</policy> </launchSecurity> ... </domain> Fails with "Unable to find 'efi' firmware that is compatible with the current configuration". A firmware that should match has the following json description { "description": "UEFI firmware for x86_64, with AMD SEV", "interface-types": [ "uefi" ], "mapping": { "device": "flash", "mode": "stateless", "executable": { "filename": "/usr/share/qemu/ovmf-x86_64-sev.bin", "format": "raw" } }, "targets": [ { "architecture": "x86_64", "machines": [ "pc-q35-*" ] } ], "features": [ "acpi-s4", "amd-sev", "amd-sev-es", "amd-sev-snp", "verbose-dynamic" ], "tags": [ ] } Auto-selection works fine if I specify a 'stateless' firmware, e.g. amend the above config with <os firmware="efi"> <type arch="x86_64" machine="q35">hvm</type> <loader stateless="yes"/> <boot dev="hd"/> </os> Being unfamiliar with the firmware auto-selection code, I tried the below naive hack, which only led to test failures and the subsequent runtime error "unable to find any master var store for loader: /usr/share/qemu/ovmf-x86_64-sev.bin". Should auto-selection work with the minimal config, or is it expected that user also specify a stateless firmware? Regards, Jim diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c index 2d0ec0b4fa..660b74141a 100644 --- a/src/qemu/qemu_firmware.c +++ b/src/qemu/qemu_firmware.c @@ -1293,15 +1293,17 @@ qemuFirmwareMatchDomain(const virDomainDef *def, return false; } - if (loader && loader->stateless == VIR_TRISTATE_BOOL_YES) { - if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_STATELESS) { - VIR_DEBUG("Discarding loader without stateless flash"); - return false; - } - } else { - if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_SPLIT) { - VIR_DEBUG("Discarding loader without split flash"); - return false; + if (loader) { + if (loader->stateless == VIR_TRISTATE_BOOL_YES) { + if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_STATELESS) { + VIR_DEBUG("Discarding loader without stateless flash"); + return false; + } + } else if (loader->stateless == VIR_TRISTATE_BOOL_NO) { + if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_SPLIT) { + VIR_DEBUG("Discarding loader without split flash"); + return false; + } } }

2 weeks, 4 days

3
6
0 / 0

[PATCH 0/4] Allow xml-configured coredump format on VM crash

by Nikolai Barybin

When libvirt processes VM crash event it always dumps core in raw format. This series makes it possible to configure dump format via domain xml. This would be especcialy helpful for Windows guests, because it requires a lot effort to convert raw dump into wingdb. Nikolai Barybin (4): conf: schemas: add coredump_format element to events section src: conf: add parsing/formatting for 'coredump_format' value qemu: use configurable dump format in doCoreDumpToAutoDumpPath() docs: formatdomain: document 'coredump_format' element docs/formatdomain.rst | 9 +++++ src/conf/domain_conf.c | 64 +++++++++++++++++++++++++++++++ src/conf/domain_conf.h | 2 + src/conf/schemas/domaincommon.rng | 19 +++++++++ src/libvirt_private.syms | 2 + src/qemu/qemu_driver.c | 2 +- 6 files changed, 97 insertions(+), 1 deletion(-) -- 2.43.5

1 month, 1 week

3
8
0 / 0

[PATCH 0/2] network: support NAT networking for FreeBSD/pf

by Roman Bogorodskiy

This series implements NAT networks support for FreeBSD using the Packet Filter (pf) firewall. The commit messages provide high-level details and limitations of the current implementation, and I'll use this cover letter to provide some more technical details and describe testing I have performed for this change. Libvirt FreeBSD/pf NAT testing For two networks: virsh # net-dumpxml default <network> <name>default</name> <uuid>68cd5419-9fda-4cf0-9ac6-2eb9c1ba41ed</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:db:0e:e5'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254'/> </dhcp> </ip> </network> virsh # net-dumpxml natnet <network> <name>natnet</name> <uuid>d3c59659-3ceb-4482-a625-1f839a54429c</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr1' stp='on' delay='0'/> <mac address='52:54:00:0a:fc:1d'/> <ip address='10.0.100.1' netmask='255.255.255.0'> <dhcp> <range start='10.0.100.2' end='10.0.100.254'/> </dhcp> </ip> </network> virsh # The following rules are generated: $ sudo pfctl -a '*' -sn nat-anchor "libvirt/*" all { nat-anchor "default" all { nat pass on re0 inet from 192.168.122.0/24 to <natdst> -> (re0) port 1024:65535 round-robin } nat-anchor "natnet" all { nat pass on re0 inet from 10.0.100.0/24 to <natdst> -> (re0) port 1024:65535 round-robin } } $ $ sudo pfctl -a 'libvirt/default' -t natdst -T show 0.0.0.0/0 !192.168.122.0/24 !224.0.0.0/24 !255.255.255.255 $ sudo pfctl -a 'libvirt/natnet' -t natdst -T show 0.0.0.0/0 !10.0.100.0/24 !224.0.0.0/24 !255.255.255.255 $ $ sudo pfctl -a '*' -sr scrub all fragment reassemble anchor "libvirt/*" all { anchor "default" all { pass quick on virbr0 inet from 192.168.122.0/24 to 192.168.122.0/24 flags S/SA keep state pass quick on virbr0 inet from 192.168.122.0/24 to 224.0.0.0/24 flags S/SA keep state pass quick on virbr0 inet from 192.168.122.0/24 to 255.255.255.255 flags S/SA keep state block drop on virbr0 all } anchor "natnet" all { pass quick on virbr1 inet from 10.0.100.0/24 to 10.0.100.0/24 flags S/SA keep state pass quick on virbr1 inet from 10.0.100.0/24 to 224.0.0.0/24 flags S/SA keep state pass quick on virbr1 inet from 10.0.100.0/24 to 255.255.255.255 flags S/SA keep state block drop on virbr1 all } } pass all flags S/SA keep state $ Create two guests attached to the "default" network, vmA and vmB. vmA $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp0s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:67:eb:de brd ff:ff:ff:ff:ff:ff inet 192.168.122.92/24 brd 192.168.122.255 scope global dynamic noprefixroute enp0s4 valid_lft 1082sec preferred_lft 1082sec inet6 fe80::5054:ff:fe67:ebde/64 scope link noprefixroute valid_lft forever preferred_lft forever vmA $ vmB $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: enp0s4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:d2:8b:41 brd ff:ff:ff:ff:ff:ff inet 192.168.122.154/24 metric 100 brd 192.168.122.255 scope global dynamic enp0s4 valid_lft 1040sec preferred_lft 1040sec inet6 fe80::5054:ff:fed2:8b41/64 scope link valid_lft forever preferred_lft forever vmB $ Test NAT rules: vmA $ ping -c 3 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=14.7 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=10.7 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=10.1 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2006ms rtt min/avg/max/mdev = 10.099/11.835/14.710/2.047 ms vmA $ vmB $ ping -c 3 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=15.1 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=11.0 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=10.4 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2006ms rtt min/avg/max/mdev = 10.434/12.198/15.113/2.075 ms vmB $ vmA $ curl wttr.in/?0Q Fog _ - _ - _ - +4(1) °C _ - _ - _ ↙ 11 km/h _ - _ - _ - 0 km 0.0 mm vmA $ vmB $ curl wttr.in/?0Q Fog _ - _ - _ - +4(1) °C _ - _ - _ ↙ 11 km/h _ - _ - _ - 0 km 0.0 mm vmB $ Inter-VM connectivity: vmA $ ping -c 3 192.168.122.154 PING 192.168.122.154 (192.168.122.154) 56(84) bytes of data. 64 bytes from 192.168.122.154: icmp_seq=1 ttl=64 time=0.253 ms 64 bytes from 192.168.122.154: icmp_seq=2 ttl=64 time=0.226 ms 64 bytes from 192.168.122.154: icmp_seq=3 ttl=64 time=0.269 ms --- 192.168.122.154 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2042ms rtt min/avg/max/mdev = 0.226/0.249/0.269/0.017 ms vmA $ vmA $ ssh 192.168.122.154 uname novel(a)192.168.122.154's password: Linux vmA $ Multicast test: vmA $ iperf -s -u -B 224.0.0.1 -i 1 ------------------------------------------------------------ Server listening on UDP port 5001 Joining multicast group 224.0.0.1 Server set to single client traffic mode (per multicast receive) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 1] local 224.0.0.1 port 5001 connected with 192.168.122.154 port 36963 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 1] 0.00-1.00 sec 131 KBytes 1.07 Mbits/sec 0.030 ms 0/91 (0%) [ 1] 1.00-2.00 sec 128 KBytes 1.05 Mbits/sec 0.022 ms 0/89 (0%) [ 1] 2.00-3.00 sec 128 KBytes 1.05 Mbits/sec 0.021 ms 0/89 (0%) [ 1] 0.00-3.02 sec 389 KBytes 1.06 Mbits/sec 0.026 ms 0/271 (0%) vmB $ iperf -c 224.0.0.1 -u -T 32 -t 3 -i 1 ------------------------------------------------------------ Client connecting to 224.0.0.1, UDP port 5001 Sending 1470 byte datagrams, IPG target: 11215.21 us (kalman adjust) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.122.154 port 36963 connected with 224.0.0.1 port 5001 [ ID] Interval Transfer Bandwidth [ 1] 0.0000-1.0000 sec 131 KBytes 1.07 Mbits/sec [ 1] 1.0000-2.0000 sec 128 KBytes 1.05 Mbits/sec [ 1] 2.0000-3.0000 sec 128 KBytes 1.05 Mbits/sec [ 1] 0.0000-3.0173 sec 389 KBytes 1.06 Mbits/sec [ 1] Sent 272 datagrams vmB $ Broadcast test: vmA $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0 net.ipv4.icmp_echo_ignore_broadcasts = 0 vmA $ vmB $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0 net.ipv4.icmp_echo_ignore_broadcasts = 0 vmB $ host $ ping 192.168.122.255 PING 192.168.122.255 (192.168.122.255): 56 data bytes 64 bytes from 192.168.122.154: icmp_seq=0 ttl=64 time=0.199 ms 64 bytes from 192.168.122.92: icmp_seq=0 ttl=64 time=0.227 ms (DUP!) 64 bytes from 192.168.122.154: icmp_seq=1 ttl=64 time=0.209 ms 64 bytes from 192.168.122.92: icmp_seq=1 ttl=64 time=0.235 ms (DUP!) ^C --- 192.168.122.255 ping statistics --- 2 packets transmitted, 2 packets received, +2 duplicates, 0.0% packet loss round-trip min/avg/max/stddev = 0.199/0.218/0.235/0.014 ms This testing does not cover any negative scenarios which are probably not that important at this point. Roman Bogorodskiy (2): network: bridge_driver: add BSD implementation network: introduce Packet Filter firewall backend meson.build | 2 + po/POTFILES | 2 + src/network/bridge_driver_bsd.c | 107 +++++++++ src/network/bridge_driver_conf.c | 8 + src/network/bridge_driver_linux.c | 2 + src/network/bridge_driver_platform.c | 2 + src/network/meson.build | 1 + src/network/network_pf.c | 327 +++++++++++++++++++++++++++ src/network/network_pf.h | 26 +++ src/util/virfirewall.c | 4 +- src/util/virfirewall.h | 2 + 11 files changed, 482 insertions(+), 1 deletion(-) create mode 100644 src/network/bridge_driver_bsd.c create mode 100644 src/network/network_pf.c create mode 100644 src/network/network_pf.h -- 2.49.0

1 month, 2 weeks

2
7
0 / 0

[PATCH 0/4] USB hostdev: allow addressing by port

by Maximilian Martin

This resubmission splits up the previous patch into multiple patches and incorporates review comments from Michal Prívozník. Currently, only vendor/product and bus/device matching are supported for USB host devices. Neither of these provide a stable and persistent way of assigning a guest a specific host device. Vendor/product can be ambiguous. Device numbers change on every enumeration. This patch adds a bus/port matching, which allows a specific port on the host to be specified using the dotted notation found in Linux's "devpath" sysfs attribute. This patch is based on the previous work of Thomas Hebb: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/7... Resolves: https://gitlab.com/libvirt/libvirt/-/issues/513 Signed-off-by: Maximilian Martin <maximilian_martin(a)gmx.de> Maximilian Martin (4): virusb test data: add devpath files for port addressing domain_conf, virhostdev, virusb, virusb test: add bus/port matching schema: add USB port attribute docs: add description for USB port matching docs/formatdomain.rst | 29 ++-- src/conf/domain_conf.c | 69 +++++++- src/conf/domain_conf.h | 1 + src/conf/schemas/domaincommon.rng | 11 +- src/hypervisor/virhostdev.c | 131 +++++++++------ src/libvirt_private.syms | 2 - src/util/virusb.c | 156 ++++++------------ src/util/virusb.h | 32 ++-- tests/virusbtest.c | 149 ++++++++++++----- .../sys_bus_usb/devices/1-1.5.3.1/devpath | 1 + .../sys_bus_usb/devices/1-1.5.3.3/devpath | 1 + .../sys_bus_usb/devices/1-1.5.3/devpath | 1 + .../sys_bus_usb/devices/1-1.5.4/devpath | 1 + .../sys_bus_usb/devices/1-1.5.5/devpath | 1 + .../sys_bus_usb/devices/1-1.5.6/devpath | 1 + .../sys_bus_usb/devices/1-1.5/devpath | 1 + .../sys_bus_usb/devices/1-1.6/devpath | 1 + .../sys_bus_usb/devices/1-1/devpath | 1 + .../sys_bus_usb/devices/2-1.2/devpath | 1 + .../sys_bus_usb/devices/2-1/devpath | 1 + .../sys_bus_usb/devices/usb1/devpath | 1 + .../sys_bus_usb/devices/usb2/devpath | 1 + .../sys_bus_usb/devices/usb3/devpath | 1 + .../sys_bus_usb/devices/usb4/devpath | 1 + 24 files changed, 351 insertions(+), 244 deletions(-) create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.4/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.5/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.6/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.6/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1.2/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb2/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb4/devpath -- 2.39.5

1 month, 3 weeks

3
16
0 / 0

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> > [...]

2 months

5
4
0 / 0

[PATCH v3 0/3] CH: Add support for a configuration file and log level configuration

by Stefan Kober

Similar to the qemu.conf file that allows QEMU specific configurations we add the possibility to specify a ch.conf file for Cloud Hypervisor configuration. The initial single config option is the log level, which sets the verbosity of the Cloud Hypervisor process. This allows for simpler debugging when using Cloud Hypervisor via libvirt. Stefan Kober (3): ch: Add config file support ch: add log level configuration option NEWS: ch: announce log_level config option NEWS.rst | 5 +++++ src/ch/ch.conf | 11 ++++++++++ src/ch/ch_conf.c | 31 ++++++++++++++++++++++++++ src/ch/ch_conf.h | 18 +++++++++++++++ src/ch/ch_driver.c | 6 +++++ src/ch/ch_monitor.c | 6 +++++ src/ch/libvirtd_ch.aug | 40 ++++++++++++++++++++++++++++++++++ src/ch/meson.build | 12 ++++++++++ src/ch/test_libvirtd_ch.aug.in | 5 +++++ 9 files changed, 134 insertions(+) create mode 100644 src/ch/ch.conf create mode 100644 src/ch/libvirtd_ch.aug create mode 100644 src/ch/test_libvirtd_ch.aug.in -- 2.49.0

2 months

2
4
0 / 0

[PATCH 0/3] qemu: Replace usb-storage with usb-bot

by Akihiko Odaki

usb-storage is a compound device that automatically creates a USB mass storage device and a SCSI device as its backend. Unfortunately it lacks some configuration options that are usually present with a SCSI device, and cannot represent CD-ROM in particular. Replace usb-storage with usb-bot, which can be combined with a manually created SCSI device. libvirt will configure the SCSI device in a way identical with how QEMU does for usb-storage except that now it respects a configuration option to represent CD-ROM. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/368 Signed-off-by: Akihiko Odaki <akihiko.odaki(a)daynix.com> --- Akihiko Odaki (3): qemu_capabilities: Introduce QEMU_CAPS_DEVICE_USB_BOT qemu: Replace usb-storage with usb-bot qemu_capabilities: Retire QEMU_CAPS_DEVICE_USB_STORAGE src/qemu/qemu_alias.c | 3 +- src/qemu/qemu_capabilities.c | 19 +- src/qemu/qemu_capabilities.h | 3 +- src/qemu/qemu_command.c | 55 +++++- src/qemu/qemu_command.h | 5 + src/qemu/qemu_hotplug.c | 34 +++- src/qemu/qemu_validate.c | 4 +- .../qemucapabilitiesdata/caps_10.0.0_s390x.replies | 186 ++++--------------- tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml | 2 +- .../caps_10.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_10.0.0_x86_64.xml | 2 +- .../caps_5.2.0_aarch64.replies | 174 ++++------------- tests/qemucapabilitiesdata/caps_5.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_5.2.0_ppc64.replies | 178 +++++------------- tests/qemucapabilitiesdata/caps_5.2.0_ppc64.xml | 2 +- .../caps_5.2.0_riscv64.replies | 170 ++++------------- tests/qemucapabilitiesdata/caps_5.2.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_5.2.0_x86_64.replies | 190 +++++-------------- tests/qemucapabilitiesdata/caps_5.2.0_x86_64.xml | 2 +- .../caps_6.0.0_aarch64.replies | 172 ++++------------- tests/qemucapabilitiesdata/caps_6.0.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_6.0.0_x86_64.replies | 188 +++++-------------- tests/qemucapabilitiesdata/caps_6.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_6.1.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_6.1.0_x86_64.xml | 2 +- .../caps_6.2.0_aarch64.replies | 178 ++++-------------- tests/qemucapabilitiesdata/caps_6.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_6.2.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_6.2.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_6.2.0_x86_64.xml | 2 +- .../caps_7.0.0_aarch64+hvf.replies | 182 +++++------------- .../caps_7.0.0_aarch64+hvf.xml | 2 +- .../caps_7.0.0_aarch64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.0.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_7.0.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_7.0.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_7.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_7.1.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_7.1.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_7.1.0_x86_64.xml | 2 +- tests/qemucapabilitiesdata/caps_7.2.0_ppc.replies | 186 ++++--------------- tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 2 +- .../caps_7.2.0_x86_64+hvf.replies | 206 +++++---------------- .../qemucapabilitiesdata/caps_7.2.0_x86_64+hvf.xml | 2 +- .../qemucapabilitiesdata/caps_7.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_7.2.0_x86_64.xml | 2 +- .../caps_8.0.0_riscv64.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.0.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_8.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_8.1.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.1.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_8.1.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml | 2 +- .../caps_8.2.0_aarch64.replies | 190 ++++--------------- tests/qemucapabilitiesdata/caps_8.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_armv7l.replies | 190 ++++--------------- tests/qemucapabilitiesdata/caps_8.2.0_armv7l.xml | 2 +- .../caps_8.2.0_loongarch64.replies | 186 ++++--------------- .../caps_8.2.0_loongarch64.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.2.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_9.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.0.0_x86_64.xml | 2 +- .../caps_9.1.0_riscv64.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.1.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_9.1.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.1.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_9.1.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.1.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_9.2.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.2.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_9.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.2.0_x86_64.xml | 2 +- tests/qemuhotplugtest.c | 8 +- .../qemuxmlconfdata/disk-cache.x86_64-latest.args | 3 +- .../disk-cdrom-bus-other.x86_64-latest.args | 3 +- .../disk-device-removable.x86_64-latest.args | 3 +- .../disk-usb-device.x86_64-latest.args | 3 +- 84 files changed, 1689 insertions(+), 5346 deletions(-) --- base-commit: e5299ddf86121d3c792ca271ffcb54900eb19dc3 change-id: 20250304-bot-5d84aa3a5cfe Best regards, -- Akihiko Odaki <akihiko.odaki(a)daynix.com>

2 months, 1 week

4
11
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Devel May 2025