trustGuestRxFilters broken after upgrade to Debian 12
by Paul B. Henson
We've been running Debian 11 for a while, using sr-iov:
<network>
<name>sr-iov-intel-10G-1</name>
<uuid>6bdaa4c8-e720-4ea0-9a50-91cb7f2c83b1</uuid>
<forward mode='hostdev' managed='yes'>
<pf dev='eth2'/>
</forward>
</network>
and allocating vf's from the pool:
<interface type='network' trustGuestRxFilters='yes'>
<mac address='52:54:00:08:da:5b'/>
<source network='sr-iov-intel-10G-1'/>
<vlan>
<tag id='50'/>
</vlan>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
After upgrading to Debian 12, when I try to start any vm which uses the
trustGuestRxFilters option, it fails to start with the message:
error: internal error: unable to execute QEMU command 'query-rx-filter':
invalid net client name: hostdev0
If I remove the option, it starts fine (but of course is broken
functionality wise as the option wasn't there just for fun :) ).
Any thoughts on what's going on here? The Debian 12 versions are:
libvirt-daemon/stable,now 9.0.0-4
qemu-system-x86/stable,now 1:7.2+dfsg-7+deb12u3
I see Debian 12 backports has version 8.1.2+ds-1~bpo12+1 of qemu, but no
newer versions of libvirt. I haven't tried the backports version to
see if that resolves the problem.
Thanks much...
3 weeks
Error Cannot acquire state change lock from
remoteDispatchDomainMigratePrepare3Params during live migration of domains
by Christian Rohmann
Hallo libvirt-users!
we observe lock-ups / timeouts with in prometheus-libvirt-exporter
(https://github.com/inovex/prometheus-libvirt-exporter) when
libvirt is live-migrating domains:
> Timed out during operation: cannot acquire state change lock (held by
> monitor=remoteDispatchDomainMigratePrepare3Params)
All of the source code can be found at:
https://github.com/inovex/prometheus-libvirt-exporter/blob/master/pkg/exp....
Basically the error happens when DomainMemoryStats or other operational
domain info is queried via the libvirt socket.
1) We are actually using the read-only socket at
'/var/run/libvirt/libvirt-sock-ro', so there should not be any locking
required.
Is there any way to not run into lock contention, like running a request
with some "nolock" indication?
2) This being reported as timeout waiting for the lock, what is the
timeout and would waiting a bit longer help?
Or is the lock active during the whole time a domain live migration is
running?
3) Is this in any way related to the type of migration? Tunneled vs.
native (https://libvirt.org/migration.html)?
4) Is there any indication that we could use to skip those domains (or
certain queries)?
The same issue was actually previously reported for another
implementation of a Prometheus exporter
(https://github.com/kumina/libvirt_exporter/issues/33).
Currently the exporter locks up or throws the mentioned timeout errors
during the the migration of 200 domains, 5 at a time.
It would be awesome to find a way to make this work as smooth as
possible, even during live migrations!
I am thankful for any insights into how the libvirt socket, the various
calls, the locking mechanisms or live migration modes work!
Regards
Christian
7 months
How to configure the default connection for virsh
by Nir Soffer
We are using minikube vms, which require adding the user to to libvirt
group[1].
We use `virsh -c qemu:///system` for debugging these vms or related libvirt
networks.
Using virsh without specifying the '-c' argument is a common mistake that
leads to
trouble, for example creating the libvirt default network incorrectly.
I wonder if it is possible to configure virsh so it uses -c qemu:///system
by default?
We know that this is not great, but we don't know a better way to use
minikube
with the kvm2 driver. The minikube vms are started for creating a
development
environment and during CI, and they cannot require a password or any
complicated
setup.
[1] https://github.com/kubernetes/minikube/issues/3467
Nir
7 months, 1 week
Linking virtual sound cards in two virtual machines?
by Lars Kellogg-Stedman
I would like to create a virtual audio cable between two libvirt
guests such that sound output from guest A goes to sound input on
guest B, and vice versa. I figure the solution to this is using
something like the pulseaudio's "virtual sink", but I'm not entirely
sure what the syntax would look like (fwiw, I'm on Fedora 39, which
means libvirt 9.7.0, which means this has to be through libvirt's
pulseaudio driver rather than the pipewire driver, since the latter
isn't available in 9.7.0).
I started by creating a virtual sink (and yes, I realize that's only
half the process):
pactl load-module module-null-sink sink_name=vaudio0
And adding the following snippet to the domain xml for guest "node1.virt":
<audio id='1' type='pulseaudio'>
<input name='vaudio0' streamName='node1-in' latency='100'/>
<output name='vaudio0' streamName='node1-out' latency='100'/>
</audio>
But trying to start this guest results in:
error: Failed to start domain 'node1.virt'
error: internal error: process exited while connecting to monitor:
audio: Could not init `pa' audio driver
There doesn't appear to be any additional information in
/var/log/libvirt/qemu/node1.virt.log. I'm wondering if someone has an
example of what this might look like?
Thanks,
--
Lars Kellogg-Stedman <lars(a)redhat.com>
7 months, 1 week
'nconnect' nfs mount option support
by Abhisar Sinha
Hi,
Is there a way to specify the 'nconnect' nfs mount opt value in the XML
file used by 'virsh create-pool' command? If not, how hard would it be to
implement this functionality? Please advise.
Thanks,
Abhisar
7 months, 1 week
TLS Configuration with libvirt and Perfect Forward Secrecy
by Tommy.J.Mairo
Dear libvirt Users,
I'm seeking guidance on configuring TLS with libvirt to achieve perfect forward secrecy (PFS). While I followed the tutorial on setting up TLS with libvirt from the project wiki [1], I encountered an error when bringing up the legacy monolithic libvirt daemon.
The error message, "Certificate /etc/pki/libvirt/servercert.pem usage does not permit key encipherment," appeared even though I declared the "encryption_key" field in the certtool template file when generating the server certificate. Moreover, when I inspected the generated certificate with certtool, I discovered that it only had a "Digital signature" entry under X509v3 key usage. The deficiency in "Key Encipherment" usage could result from the key type specifications when generating the private key with the command "certtool --generate-privkey --key-type=ed25519 --curve=Ed25519 --sec-param=ultra > /etc/pki/libvirt/private/serverkey.pem". I prefer using elliptic-curve cryptography, specifically curve25519, over RSA, which the tutorial employs.
Although a digital signature-only certificate can still perform Diffie–Hellman exchanges with ECDSA, it cannot encrypt client-generated pre-master secrets. Nonetheless, a TLS session can still be established without pre-master secrets, avoiding session key leakage even if the decryption key is compromised in the future. This fulfills the PFS requirement, and I believe that a certificate without "Key Encipherment" usage contributes to the system's overall security.
Based on my understanding, I am seeking any insights or suggestions on whether there is a way to suppress the "certificate usage does not permit key encipherment" error and allow the legacy monolithic libvirt daemon to proceed.
Thanks,
Tommy.J.Mairo
[1] https://wiki.libvirt.org/TLSSetup.html
7 months, 2 weeks
