- Users - libvirt List Archives

Read-only iscsi disk? Or hot-plug?
by Paul van der Vlis 08 Sep '20

08 Sep '20

Hello, I have an iSCSI disk with a backup. I want to use that backup on another machine to test putting back data. What I use now is this: ---- <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='directsync' io='native'/> <source dev='/dev/disk/by-id/scsi-36e843b6afdddf65dc4e9d4dc2dab66de'/> <target dev='vdh' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/> </disk> ---- Is it possible to do this read-only? What I also could do is to hot-unplug the disk at the production machine, and then hot-plug it at the test-machine. But the machines are Windows, and I don't know Windows well. With regards, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/

2 2

debian 10, vm cant connect to the host bridge
by Schuldei, Andreas 07 Sep '20

07 Sep '20

This is my system info: Debian Release: 10.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.4.60-1-pve (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Libvirt version 5.0.0 qemu Version: 1:3.1+dfsg-8+deb10u7 I try to get the filtering bridge to work. This is the host, with the br0 that is connected to a trunked port ================================ 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 valid_lft forever preferred_lft forever 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 34:48:ed:f0:a9:e8 brd ff:ff:ff:ff:ff:ff inet 10.12.0.13/24 brd 10.12.0.255 scope global eno1 valid_lft forever preferred_lft forever inet6 fe80::3648:edff:fef0:a9e8/64 scope link valid_lft forever preferred_lft forever 3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000 link/ether 34:48:ed:f0:a9:e9 brd ff:ff:ff:ff:ff:ff inet6 fe80::3648:edff:fef0:a9e9/64 scope link valid_lft forever preferred_lft forever 4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether e6:67:7b:87:b5:ca brd ff:ff:ff:ff:ff:ff inet6 fe80::e467:7bff:fe87:b5ca/64 scope link valid_lft forever preferred_lft forever 5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:2b:e3:f7 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:2b:e3:f7 brd ff:ff:ff:ff:ff:ff 19: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000 link/ether fe:54:00:fc:ea:e6 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fefc:eae6/64 scope link valid_lft forever preferred_lft forever =================== bridge vlan show port vlan ids eno2 4 7 221 800 br0 None virbr0 1 PVID Egress Untagged virbr0-nic 1 PVID Egress Untagged vnet0 800 ================== however the mac does not show up when i do ================== brctl showmacs br0 ================== so vnet0 does not yet communicate with the bridge inside the vm: ============================= 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 valid_lft forever preferred_lft forever 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:fc:ea:e6 brd ff:ff:ff:ff:ff:ff inet 195.37.235.121/26 brd 195.37.235.127 scope global enp1s0 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fefc:eae6/64 scope link valid_lft forever preferred_lft forever =============================== and =========== ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. >From 195.37.235.121 icmp_seq=1 Destination Host Unreachable >From 195.37.235.121 icmp_seq=2 Destination Host Unreachable ============== The mac address of vnet0 and enp1s0 is the same. That means they are the same entity. yay! The XML describing the network part of the VM is here: ===================== <interface type='bridge'> <mac address='52:54:00:29:b6:e0'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> ======================= what could be the problem?

2 3

Error With Xeon 2678 in virt-manager
by John Bajer 06 Sep '20

06 Sep '20

Hello, I have to select Ivy Bridge since I have Xeon 2678 but I cannot find it on the drop-down menu in virt-manager. When I select copy host cpu configuration it changes it to EPYC as soon as I click the start button. I have Manjaro on my computer. How to solve this problem? Thanks! *John Washington Bajer* *El Ciclista de la Triste Figura*

1 0

printing the qemu final execution line from an xml
by daggs 04 Sep '20

04 Sep '20

Greetings, I have a qemu line which I want to convert ot libvirt xml but as domxml-from-native is deprecated, I want to try it the other way around. e.g. write an libvirt xml and dump the final qemu line without running it. is there a way to do so? Thanks, Dagg.

2 2

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