- Users - libvirt List Archives

usb-hdmi-cec-adapter usb pass-through experiences
by daggs 03 Sep '20

03 Sep '20

Greetings, I need to get a device like this: https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter I have usb pass-through experiences with some usb devices such as dtv, wireless network, thumbsticks and wireless keyboards. I know there isn't much to be done in usb pass-through but I did had issues with the former two, now I'm using a wireless network without and issues. I wanted to know if someone has tried using this device as pass-through into a vm and can share his thoughts. Thanks, Dagg.

2 2

libvirt 6.7 meson.build error
by Chen Wenwei 03 Sep '20

03 Sep '20

Found pkg-config: /usr/local/bin/pkg-config (0.29.2) Did not find CMake 'cmake' Found CMake: NO Run-time dependency libapparmor found: NO (tried pkgconfig and cmake) Library attr found: YES Library audit found: YES Run-time dependency bash-completion found: YES 2.1 Run-time dependency blkid found: NO (tried pkgconfig and cmake) Library cap-ng found: YES Run-time dependency libcurl found: NO (tried pkgconfig and cmake) Run-time dependency dbus-1 found: NO (tried pkgconfig and cmake) Run-time dependency devmapper found: NO (tried pkgconfig and cmake) Library devmapper found: YES meson.build:1048:19: ERROR: Unknown variable "tmp". A full log can be found at /home/libvirt-6.7.0/build/meson-logs/meson-log.txt [root@localhost libvirt-6.7.0]#

2 1

bridge + SR-IOV guests with KVM
by Philipp Rosenberger 02 Sep '20

02 Sep '20

Hi, I managed to get SR-IOV with an Intel I350 NIC to work.For this I followed the documentation on this page: https://wiki.libvirt.org/page/Networking#Assignment_from_a_pool_of_SRIOV_VF… But as I have more VMs then VF on the NIC I also have a bridge wich serves the other guests. As I run Debian Buster as host I followed the documentation here: https://wiki.libvirt.org/page/Networking#Debian.2FUbuntu_Bridging If I use only the SRIOV everything works as expected. All guests can be reached for the network and the guests and host can reach each other. The same goes for a sole bridged environment. As I dived into the issue I found an answer form the intel community: https://community.intel.com/t5/Ethernet-Products/82599-VF-to-Linux-host-bri… It says I need to add the "VF mac addresses and eth0 mac address to bridge forwarding database". I have done this with the following command: bridge fdb add 52:54:00:3c:1c:e6 dev eth_lan0 The mac address is from my VM which is on the bridge. And the eth_lan0 interface is the physical interface of my bridge and also the PF of my I350 NIC. This seems to work. But doing this manually is annoying and a bit of a hassle when creating new VMs on the bridge. I there a way to let libvirt do this work? Best regards Philipp PS: This presentation shows it pretty well on page 33: https://events.static.linuxfound.org/sites/events/files/slides/LinuxConJapa…

2 1

Meson build
by Toolybird 02 Sep '20

02 Sep '20

Hi, Just a heads up on my experiences with the new build system. Arch Linux meson-0.55.1 Overall, it looks good, so well done! Just a couple of minor things I noted: 1. Arch uses a meson wrapper script (arch-meson) that sets: --buildtype plain This seems to trigger a bug in meson that results in copious bogus compiler warnings: cc1: warning: ‘-Wformat-y2k’ ignored without ‘-Wformat’ [-Wformat-y2k] cc1: warning: ‘-Wformat-extra-args’ ignored without ‘-Wformat’ [-Wformat-extra-args] cc1: warning: ‘-Wformat-zero-length’ ignored without ‘-Wformat’ [-Wformat-zero-length] cc1: warning: ‘-Wformat-contains-nul’ ignored without ‘-Wformat’ [-Wformat-contains-nul] cc1: warning: ‘-Wformat-security’ ignored without ‘-Wformat’ [-Wformat-security] which of course breaks -Werror builds. I can easily work around it by setting `-D git_werror=disabled' or even better still: CFLAGS+=" -Wall" arch-meson... Maybe this github issue is related?: https://github.com/mesonbuild/meson/issues/7399 2. Arch currently builds libvirt with support for ZFS. Seeing as ZFS is not in the distro proper, a simple Autoconf tweak is used: ZFS=/usr/bin/zfs ZPOOL=/usr/bin/zpool \ ./configure ... This is surprisingly hard to emulate with meson, in fact it appears impossible, unless I resort to dodgy hacks with sed etc. Cheers

6 10

I want to unsubscribe
by Bilal Arif 31 Aug '20

31 Aug '20

Block360 PVT Limited NSTP, Islamabad, Pakistan. Whatsapp/Mobile: +923457343638 Web: www.block360.io

2 1

Re: plug pre-created tap devices to libvirt guests
by Marcus 31 Aug '20

31 Aug '20

> On Tue, Jun 30, 2020 at 04:02:05PM +0100, Daniel P. Berrangé wrote: > > On Tue, Jun 30, 2020 at 12:59:03PM +0200, Miguel Duarte de Mora Barroso wrote: > > > On Mon, Apr 6, 2020 at 4:03 PM Laine Stump <lstump redhat com> wrote: > > > > > > > > On 4/6/20 9:54 AM, Daniel P. Berrangé wrote: > > > > > On Mon, Apr 06, 2020 at 03:47:01PM +0200, Miguel Duarte de Mora Barroso wrote: > > > > >> Hi all, > > > > >> > > > > >> I'm aware that it is possible to plug pre-created macvtap devices to > > > > >> libvirt guests - tracked in RFE [0]. > > > > >> > > > > >> My interpretation of the wording in [1] and [2] is that it is also > > > > >> possible to plug pre-created tap devices into libvirt guests - that > > > > >> would be a requirement to allow kubevirt to run with less capabilities > > > > >> in the pods that encapsulate the VMs. > > > > >> > > > > >> I took a look at the libvirt code ([3] & [4]), and, from my limited > > > > >> understanding, I got the impression that plugging existing interfaces > > > > >> via `managed='no' ` is only possible for macvtap interfaces. > > > > > > > > > > > > No, it works for standard tap devices as well. > > > > > > > > > > > > The reason the BZs and commit logs talk mostly about macvtap rather than > > > > tap is because 1) that's what kubevirt people had asked for and 2) it > > > > already *mostly* worked for tap devices, so most of the work was related > > > > to macvtap (my memory is already fuzzy, but I think there were a couple > > > > privileged operations we still tried to do for standard tap devices even > > > > if they were precreated (standard disclaimer: I often misremember, so > > > > this memory could be wrong! But definitely precreated tap devices do work). > > > > > > > > > > It's been a while since I've started this thread, but lately I've > > > understood better how tap devices work, and that new insight makes me > > > wonder about a couple of things. > > > > > > Our ultimate goal In kubevirt is to consume a pre-created tap device > > > by a kubernetes pod that doesn't have the NET_ADMIN capability. > > > > > > After looking at the current libvirt code, I don't think that is > > > currently supported, since we'll *always* enter the > > > `virNetDevTapCreate` function in [1] (I'm interested in the *tap* > > > scenario). > > > > > > The tap device is effectively created in that function - [2] - by > > > opening the clone device (/dev/net/tun), and calling `ioctl(fd, > > > TUNSETIFF,...)` in it. AFAIK, both of those operations *require* the > > > NET_ADMIN capability. If I'm correct, this means that the current > > > libvirt implementation makes our goals impossible to achieve. > > > > AFAIK, that is not correct - CAP_NET_ADMIN isn't required to open > > or create a tap device - only to add the tap device to a bridge. > > > > So if you create the tap device & attach it to a bridge ahead of > > time, libvirt should then be able to open it and give it to QEMU > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri… > > ((uid_valid(tun->owner) && !uid_eq(cred->euid, tun->owner)) || > (gid_valid(tun->group) && !in_egroup_p(tun->group))) && > !ns_capable(net->user_ns, CAP_NET_ADMIN); > > > This is called by the TUNSETIFF code. > > AFAICT, that means if you fchown(tapfd, uid, gid), to the uid+gid of > libvirtd, it should not require CAP_NET_ADMIN. > > Regards, > Daniel I have no idea if this message will get linked into the thread properly, but I came across this and wanted to comment on the mystery without having an actual email to reply to or headers. I recently ran into this issue as well, and found that even *with* NET_ADMIN at the container level, trying to launch Qemu directly results in: qemu-system-x86_64: -netdev tap,id=hostnet0,ifname=tap0: could not configure /dev/net/tun (tap0): Permission denied So as a note I'd say even Libvirt aside, Qemu is trying to do this as well: https://github.com/qemu/qemu/blob/0982a56a551556c704dc15752dabf57b4be1c640/… But it's unclear where the EPERM is coming from in the kernel at tun_set_iff(). Of note, if I give Qemu a non-existing tap name, it will create it, but if I give it an existing tap name, I get EPERM.

1 1

Distinguishing between host and guest initiated VM shutdown
by Milan Zamazal 27 Aug '20

27 Aug '20

Hi, we have a problem in oVirt that highly available VMs don't restart after host poweroff because Vdsm identifies the case as a user initiated shutdown (https://bugzilla.redhat.com/1800966) When poweroff is run on the host, libvirt-guests service takes an action. `virsh shutdown' is run on the VM, the guest OS is shut down cleanly and libvirt reports a shutdown event with VIR_DOMAIN_EVENT_SHUTDOWN_GUEST detail. Although it is a host initiated shutdown actually. Does libvirt provide any means to distinguish this case from a regular user shutdown? Thanks, Milan

3 4

support for live migration with PCI passthrough devices
by Henry lol 26 Aug '20

26 Aug '20

Hi guys, I'm wondering whether libvirt supports live migration for the VM with PCI passthrough devices. or it must be assumed before live migration that all passthrough devices be unplugged? If so, all unplugged devices should be manually hot-plugged to the VM after migration?? Thanks.

4 4

python-libvirt domain.destroy() doesn't appear to be working for me
by Jeremy Markle 25 Aug '20

25 Aug '20

I'm using the python-libvirt library and finding that I cannot get .destroy() or .shutdown() to work. https://github.com/simora/docker-libvirt-flask/blob/cba6041b47bdf4ccb3b9506… That is the line in my code. .create() works fine and using virsh in the docker container works fine to destroy the domain as well. This is based on ubuntu bionic in a docker container with the libvirt socket and such made available. .create() works, listing works and virsh works so permissions are not the issue. I'm confident I have failed to properly use the function or am missing the appropriate logging. Any assistance would be greatly appreciated.

3 5

couple of questions
by Vjaceslavs Klimovs 24 Aug '20

24 Aug '20

Hey folks, I've been experimenting with native NBD live migration w/ TLS and have a couple of questions. 1) It appears that in some cases modified default_tls_x509_cert_dir from qemu.conf is not respected, seems like virsh always expects a default location and does not check default_tls_x509_cert_dir: virsh # migrate vm1 qemu+tls://ratchet.lan/system --live --persistent --undefinesource --copy-storage-all --verbose --tls error: internal error: unable to execute QEMU command 'object-add': Unable to access credentials /etc/pki/qemu/ca-cert.pem: No such file or directory It's checking /etc/pki and not the location specified in default_tls_x509_cert_dir. Is this a bug or am I missing something? 2) QEMU has -object tls-cipher-suites, but there does not seem to be a way to specify TLS priority in libvirt's qemu conf. Solvable via compile time --tls-priority flag, but that's not very convenient. Is there a way to set TLS priority for QEMU TLS connections from libvirt configs? This would be equivalent to libvirtd.conf's tls_priority setting, but for QEMU, not for libvirt's own connections. 3) After setting up default_tls_x509_cert_dir and default_tls_x509_verify = 1 (and directories as required see 1), virsh initiated migrations with --tls flag succeed and captures show that it's using TLS. However, they equally succeed without the flag. Is there a way to ensure that only TLS communication is permitted between QEMUs? I tried nbd_tls, but that did not seem to have any effect. Thanks a lot for your help!

2 2