November 2019 - Users - libvirt List Archives

[libvirt-users] Getting "Unable to set XATTR" on libvirt 5.6.0 inside containers
by Roman Mohr 22 Nov '19

22 Nov '19

Hi, We are updating KubeVirt to libvirt 5.6.0. Before that we were running on 5.0.0. It seems like something regarding setting xattrs on files has changed, because with libvirt 5.6.0 we are getting the following error: ``` Unable to set XATTR trusted.libvirt.security.dac on /var/lib/libvirt/qemu/domain-410-default_vmi-fedora: Operation not permitted') ``` The main problem is for us is that container filesystems don't necessarily support setting xattrs. My questions would therfore be: * Does anyone know what has changed, and why? * Can it be disabled? Thanks a lot and Best Regards, Roman

2 2

[libvirt-users] virsh snapshot-create --print-xml seems to ignore most arguments
by Timo Schneider 21 Nov '19

21 Nov '19

Hi, I am wondering if the --print-xml option is working correctly. The output for two snapshot-create commands are the same, even though the first one includes additional options (no-metadata and atomic). I want to use the generated XML to create a snapshot via a perl script, and Sys::Virt only seems to support snapshots using a XML description of the arguments. timos@cerberus:~$ sudo virsh snapshot-create-as --domain web guest- state1 --diskspec hda,file=overlay1.qcow2 --disk-only --atomic --no- metadata --print-xml <domainsnapshot> <name>guest-state1</name> <disks> <disk name='hda'> <source file='overlay1.qcow2'/> </disk> </disks> </domainsnapshot> timos@cerberus:~$ sudo virsh snapshot-create-as --domain web guest- state1 --diskspec hda,file=overlay1.qcow2 --disk-only --print-xml <domainsnapshot> <name>guest-state1</name> <disks> <disk name='hda'> <source file='overlay1.qcow2'/> </disk> </disks> </domainsnapshot> My libvirt version is: Compiled against library: libvirt 5.6.0 Using library: libvirt 5.6.0 Using API: QEMU 5.6.0 Running hypervisor: QEMU 4.1.0 Regards, Timo

2 1

[libvirt-users] FYI mail problems for libvirt lists
by Daniel P. Berrangé 21 Nov '19

21 Nov '19

It has come to our attention that many, possibly even all, people with non-redhat.com email addresses are unable to send mail to most libvirt mailing lists, receiving bounce messages saying the address doesn't exist eg Final-Recipient: rfc822; libvirt-users(a)redhat.com Action: failed Status: 5.0.0 Remote-MTA: dns; us-smtp-inbound-1.mimecast.com Diagnostic-Code: smtp; 550 Invalid Recipient - https://community.mimecast.com/docs/DOC-1369#550 [boadZMN8PrGodBBK6pzKWg.us309] In my testing, libvir-list(a)redhat.com is the only list that is currently accepting incoming mail from non-redhat.com addresses. I see bounces from libvirt-users(a)redhat.com, libvirt-ci(a)redhat.com, libvirt-announce(a)redhat.com and libvirt-security(a)redhat.com, as well as from the undocumented alias libvirt-list(a)redhat.com We believe outgoing mail delivery is still working normally in all cases. The problems appear to be caused by some changes that Red Hat administrators made to the email infrastructure recently. We have a severity 1 ticket open for this issue and are taking all possible steps to escalate it & get it resolved at the soonest opportunity. In the mean time if any users need assistance with libvirt questions, please feel free to ignore our normal guidance and use the main development list libvir-list(a)redhat.com for questions, as this appears to still be working. Alternatively you can use IRC #virt on irc.oftc.net If you need to report any security issues with libvirt, please try the libvirt-security(a)redhat.com list first, but if you get a bounce then email myself directly. Please accept our apologies for the disruption this is causing to the libvirt mailing lists. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

1 1

[libvirt-users] Descriptions of mdev types?
by Milan Zamazal 20 Nov '19

20 Nov '19

Hi, when retrieving an mdev device info using `virsh nodedev-dumpxml' or the libvirt API, something like the following is returned: <capability type='mdev_types'> <type id='nvidia-210'> <name>GRID M60-2B4</name> <deviceAPI>vfio-pci</deviceAPI> <availableInstances>4</availableInstances> </type> ... </capability> Besides device_api, available_instances and (optional) `name', `description' of the given mdev type may be optionally provided in /sys/.../mdev_supported_types/... for each of the available mdev types. I can see in the sources that libvirt doesn't try to retrieve it -- is it intentionally or is it just an omission? If the latter, could it be added, please? It looks like a useful piece of information for the user to get an idea what the given mdev type means. Thanks, Milan

3 3

[libvirt-users] libvirt_lxc memory limit, emulator process part of the cgroup?
by Maximilian Philipps 15 Nov '19

15 Nov '19

hi, I am currently investigating a bug with libvirt lxc. Whenever I do a systemctl daemon-reload on the host, my container loses his memory limit and then reports having access to 8 exabyte of memory. I have tracked the issue down to two parts: memory.limit_in_bytes jumps from the correct value to 9223372036854771712. libvirt lxc appears to set the memory limit in transient way without writing a config for systemd. I can't prevent memory.limit_in_bytes changing by setting the correct value through systemctl set-property --runtime <scope> MemoryLimit= tasks in the memory cgroup gets cleaned up. After starting the container the cgroup contains 3 pid. The pid of the libvirt_lxc process, the pid of the init process in the container and third unknown pid that doesn't exists in /proc/. After a demon-reload only the init process remains in the cgroup and unless I move the libvirt_lxc process into the cgroup the memory limit isn't enforced. I have also noticed that when starting libvirtd it complains about GetMachineByPID failing for the libvirt_lxc process. This leaves me with one big question, the the emulator process libvirt_lxc supposed to be part of the container's cgroup or not? The leader of the container is the init process in the container. I am unsure on how the additional emulator process is supposed to be registered. Using: Debian Stretch, libvirt 5.0.0-4, systemd 241-7~deb10u1 and hybrid cgroups. Regards, Maximilian Philipps

2 1

[libvirt-users] Understanding the use of virt-install from the CLI (Linux)
by jonetsu 08 Nov '19

08 Nov '19

Hello, I've created several VMs using virt-manager and am using them. This time around though, I'd like to use the CLI approach. The problem resides in defining a storage space. This is using virt-install 1.5.1 on Xubuntu 18.04. For the occasion I created a new directory to store images. So I specify this new directory: virt-install \ --name=arch01 \ --disk path=/Share2/KVMImages/arch01.qcow2 \ --disk size=10 \ [ ... ] The above will not work as it reports: 'must be a file or a device, not a directory' So I specify a file: [ ... ] --disk path=/Share2/KVMImages/arch01.qcow2 \ --disk size=10 \ [ ... ] And it reports: 'Size must be specified for non existent volume 'arch01.qcow2'' But the size is already specified as one of the options. This is where I'm puzzled about the process. What is going on ?

3 4

[libvirt-users] Where can I find the slirp-helper?
by Han Han 07 Nov '19

07 Nov '19

For the libvirt 5.8 release, I find that there is a new comment in qemu.conf: #slirp_helper = "/usr/bin/slirp-helper" It indicates that there is a slirp-helper to help setup slirp network. But I cannot find it even after I built the latest qemu(v4.1.0-1378-g98b2e3c9ab) and libvirt (v5.9.0-rc1-2-g73f91d659b). Could you please tell me where I can find that helper program? Thanks -- Best regards, ----------------------------------- Han Han Quality Engineer Redhat. Email: hhan(a)redhat.com Phone: +861065339333

2 2

[libvirt-users] 32 bit support
by Phill. Whiteside 05 Nov '19

05 Nov '19

Hi good people, I've got a bit of a weird issue. I'm using QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.19) And after some considerable time of not using it for 32bit installations I now find that it can no longer install some older 32 bit installations (e.g. https://phillw.net/isos/lubuntu/natty/ ) The CPU goes to 100% and then after a while it just stops (I'm using virt-manager v1.5.1) I'm running lubuntu 18.04 (64 bit) on an i7 chipset that runs 64 bit debian / centos and MS server 2019 KVM instances via virt-manager without problems. Any pointers would be appreciated, Phill.

4 5

[libvirt-users] It takes long time to start kvm virtual machine with nwfilter in docker container.
by John Y. 04 Nov '19

04 Nov '19

1. It takes minutes to start the virtual machine when I add "filterref" to libvirt.xml and run command "virsh start vm1". It also takes minutes to destroy the virtual machine. <interface type="bridge"> <mac address="fa:16:3e:fa:f7:94"/> <target dev="tap69e948b0-bf"/> <source bridge="br02"/> <model type="virtio"/> <filterref filter="no-arp-spoofing"> <parameter name="IP" value="192.168.2.2"/> <parameter name="MAC" value="fa:16:3e:fa:f7:94"/> </filterref> </interface> 2. I found some logs in /var/log/libvirt/libvirtd.log 2019-11-04 03:46:18.495+0000: 15257: info : virFirewallApplyRule:815 : Applying rule '/usr/sbin/ebtables --concurrent -t nat -D PREROUTING -i tap69e948b0-bf -j libvirt-J-tap69e948b0-bf' 2019-11-04 03:46:18.495+0000: 15257: debug : virCommandRunAsync:2499 : About to run /usr/sbin/ebtables --concurrent -t nat -D PREROUTING -i tap69e948b0-bf -j libvirt-J-tap69e948b0-bf 2019-11-04 03:46:18.496+0000: 15257: debug : virFileClose:111 : Closed fd 24 2019-11-04 03:46:18.496+0000: 15257: debug : virFileClose:111 : Closed fd 26 2019-11-04 03:46:18.496+0000: 15257: debug : virFileClose:111 : Closed fd 29 2019-11-04 03:46:18.496+0000: 15257: debug : virCommandRunAsync:2502 : Command result 0, with PID 16291 2019-11-04 03:46:19.242+0000: 15257: debug : virCommandRun:2350 : Result invalid value 255, stdout: '' stderr: '2019-11-04 03:46:19.239+0000: 16291: debug : virFileClose:111 : Closed fd 26 2019-11-04 03:46:19.239+0000: 16291: debug : virFileClose:111 : Closed fd 29 2019-11-04 03:46:19.239+0000: 16291: debug : virFileClose:111 : Closed fd 24 Illegal target name 'libvirt-J-tap69e948b0-bf'. ' 2019-11-04 03:46:19.242+0000: 15257: debug : virFirewallApplyRuleDirect:704 : Ignoring error running command 2019-11-04 03:46:19.242+0000: 15257: debug : virFileClose:111 : Closed fd 25 2019-11-04 03:46:19.243+0000: 15257: debug : virFileClose:111 : Closed fd 28 2019-11-04 03:46:19.243+0000: 15257: info : virFirewallApplyRule:815 : Applying rule '/usr/sbin/ebtables --concurrent -t nat -D POSTROUTING -o tap69e948b0-bf -j libvirt-P-tap69e948b0-bf' 2019-11-04 03:46:19.243+0000: 15257: debug : virCommandRunAsync:2499 : About to run /usr/sbin/ebtables --concurrent -t nat -D POSTROUTING -o tap69e948b0-bf -j libvirt-P-tap69e948b0-bf 2019-11-04 03:46:19.243+0000: 15257: debug : virFileClose:111 : Closed fd 24 2019-11-04 03:46:19.243+0000: 15257: debug : virFileClose:111 : Closed fd 26 2019-11-04 03:46:19.244+0000: 15257: debug : virFileClose:111 : Closed fd 29 2019-11-04 03:46:19.244+0000: 15257: debug : virCommandRunAsync:2502 : Command result 0, with PID 16292 2019-11-04 03:46:19.990+0000: 15257: debug : virCommandRun:2350 : Result invalid value 255, stdout: '' stderr: '2019-11-04 03:46:19.986+0000: 16292: debug : virFileClose:111 : Closed fd 26 2019-11-04 03:46:19.986+0000: 16292: debug : virFileClose:111 : Closed fd 29 2019-11-04 03:46:19.986+0000: 16292: debug : virFileClose:111 : Closed fd 24 Illegal target name 'libvirt-P-tap69e948b0-bf'. ' 2019-11-04 03:46:19.990+0000: 15257: debug : virFirewallApplyRuleDirect:704 : Ignoring error running command 2019-11-04 03:46:19.990+0000: 15257: debug : virFileClose:111 : Closed fd 25 2019-11-04 03:46:19.990+0000: 15257: debug : virFileClose:111 : Closed fd 28 3. It works fine on hosts. 4. It works fine in other host's libvirt container. How can I solve this problem? Best regards, John

2 2