[libvirt-users] [virtual interface] detach interface during boot succeed with no changes
by Yalan Zhang
Hi guys,
when I detach an interface from vm during boot (vm boot not finished), it
always fail. I'm not sure if there is an existing bug. I have
confirmed with someone that for disk, there is similar behavior, if
this is also acceptable?
# virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 2; virsh
detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh
dumpxml rhel7.2 |grep /interface -B9
Domain rhel7.2 destroyed
Domain rhel7.2 started
Interface detached successfully
<address type='pci' domain='0x0000' bus='0x00' slot='0x06'
function='0x0'/>
</controller>
<interface type='network'>
<mac address='52:54:00:98:c4:a0'/>
<source network='default' bridge='virbr0'/>
<target dev='vnet0'/>
<model type='rtl8139'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03'
function='0x0'/>
</interface>
When I detach after the vm boot, expand the sleep time to 10, it will succeed.
# virsh destroy rhel7.2; virsh start rhel7.2 ;sleep 10; virsh
detach-interface rhel7.2 network 52:54:00:98:c4:a0; sleep 2; virsh
dumpxml rhel7.2 |grep /interface -B9
Domain rhel7.2 destroyed
Domain rhel7.2 started
Interface detached successfully
-------
Best Regards,
Yalan Zhang
IRC: yalzhang
Internal phone: 8389413
2 years, 3 months
[libvirt-users] Question about disabling UFO on guest
by Bao Nguyen
Hello everyone,
I would like to ask a question regarding to disable UFO of virtio vNIC in
my guest. I have read the document at https://libvirt.org/formatdomain.html
*host*
The csum, gso, tso4, tso6, ecn and ufo attributes with possible
values on and off can be used to turn off host offloading options. By
default, the supported offloads are enabled by QEMU. *Since 1.2.9 (QEMU
only)* The mrg_rxbuf attribute can be used to control mergeable rx buffers
on the host side. Possible values are on (default) and off. *Since 1.2.13
(QEMU only)*
*guest*
The csum, tso4, tso6, ecn and ufo attributes with possible
values on and off can be used to turn off guest offloading options. By
default, the supported offloads are enabl
ed by QEMU.
*Since 1.2.9 (QEMU only)*
Then I disabled UFO on my vNIC on guest as the following configuration
<devices>
<interface type='network'>
<source network='default'/>
<target dev='vnet1'/>
<model type='virtio'/>
<driver name='vhost' txmode='iothread' ioeventfd='on' event_idx='off'
queues='5' rx_queue_size='256' tx_queue_size='256'>
*<host gso='off' ufo='off' />*
*<guest ufo='off'/>*
</driver>
</interface>
</devices>
Then I reboot my node to get the change effect and it works. However, can I
disable the UFO without touching the host OS? or it always has to disable
on both host and guest like that?
Thanks,
Brs,
Natsu
4 years, 4 months
qemu hook: event for source host too
by Guy Godfroy
Hello, this is my first time posting on this mailing list.
I wanted to suggest a addition to the qemu hook. I will explain it
through my own use case.
I use a shared LVM storage as a volume pool between my nodes. I use
lvmlockd in sanlock mode to protect both LVM metadata corruption and
concurrent volume mounting.
When I run a VM on a node, I activate the desired LV with exclusive lock
(lvchange -aey). When I stop the VM, I deactivate the LV, effectively
releasing the exclusive lock (lvchange -an).
When I migrate a VM (both live and offline), the LV has to be activated
on both source and target nodes, so I have to use a shared lock
(lvchange -asy). That's why I need a hook event on the source host too
(as far as I know after my tests, the migration event is only triggered
on the target host).
Is such a feature a possibility?
Thanks for your attention.
Guy Godfroy
4 years, 6 months
Re: USB-hotplugging fails with "failed to load cgroup BPF prog: Operation not permitted" on cgroups v2
by Pavel Hrdina
On Mon, Jan 20, 2020 at 09:00:15PM +0100, Pol Van Aubel wrote:
> Hi,
>
> Quoting Pavel Hrdina (2020-01-20 14:29:36)
> > On Sat, Jan 18, 2020 at 11:17:11PM +0100, Pol Van Aubel wrote:
> > > Hi all,
> > >
> > > I've disabled cgroups v1 on my system with the kernel boot option
> > > "systemd.unified_cgroup_hierarchy=1". Since doing so, USB hotplugging
> > > fails to work, seemingly due to a permissions problem with BPF. Please
> > > note that the technique I'm going to describe worked just fine for
> > > hotplugging USB devices to running domains until this change.
> > > Attaching / detaching USB devices when the domain is down still works as
> > > expected.
> > >
> > > I get the same error when attaching a device in virt-manager, as I do
> > > when running the following command:
> > >
> > > sudo virsh attach-device wenger /dev/stdin --persistent <<END
> > > <hostdev mode='subsystem' type='usb' managed='yes'>
> > > <source startupPolicy='optional'>
> > > <vendor id='0x046d' />
> > > <product id='0xc215' />
> > > </source>
> > > </hostdev>
> > > END
> > >
> > > This returns
> > > error: Failed to attach device from /dev/stdin
> > > error: failed to load cgroup BPF prog: Operation not permitted
> > >
> > >
> > > virt-manager returns basically the same error, but for completeness'
> > > sake, here it is:
> > >
> > > failed to load cgroup BPF prog: Operation not permitted
> > >
> > > Traceback (most recent call last):
> > > File "/usr/share/virt-manager/virtManager/addhardware.py", line 1327, in _add_device
> > > self.vm.attach_device(dev)
> > > File "/usr/share/virt-manager/virtManager/object/domain.py", line 920, in attach_device
> > > self._backend.attachDevice(devxml)
> > > File "/usr/lib/python3.8/site-packages/libvirt.py", line 590, in attachDevice
> > > if ret == -1: raise libvirtError ('virDomainAttachDevice() failed', dom=self)
> > > libvirt.libvirtError: failed to load cgroup BPF prog: Operation not permitted
> > >
> > >
> > > Now, libvirtd is running as root, so I don't understand why any
> > > operation on BPF programs is not permitted. I've dug into libvirt's code
> > > a bit to see what is throwing this error and it boils down to
> > > <https://github.com/libvirt/libvirt/blob/7d608469621a3fda72dff2a89308e68cc...>
> > > and
> > > <https://github.com/libvirt/libvirt/blob/02bf7cc68bfc76242f02d23e73cad3661...>
> > > but I have no clue what that syscall is doing, so that's where my
> > > debugging capability basically ends.
> > >
> > > Maybe this is something as simple as setting the right ACL somewhere. I
> > > haven't touched /etc/libvirt/qemu.conf except for setting nvram. There
> > > *is* something about cgroup_device_acl there but afaict that's for
> > > cgroups v1, when there was still a device cgroup controller. Any help
> > > would be greatly appreciated.
> > >
> > >
> > > Domain log files:
> > > Upon execution of the above commands, nothing gets added to the domain
> > > log in /var/log/qemu/wenger.log, so I've decided they're likely
> > > irrelevant to the issue. Please ask for any additional info required.
> > >
> > >
> > > System information:
> > > Arch Linux, (normal) kernel 5.4.11
> > > libvirt 5.10.0
> > > qemu 4.2.0, using KVM.
> > > Host system is x86_64 on an intel 5820k.
> > > Guest system is probably irrelevant, but is Windows 10 on the same.
> > >
> > >
> > > Possibly relevant kernel build options:
> > > $ zgrep BPF /proc/config.gz
> > > [22:55:52]: zgrep BPF /proc/config.gz
> > >
> > > CONFIG_CGROUP_BPF=y
> > > CONFIG_BPF=y
> > > CONFIG_BPF_SYSCALL=y
> > > CONFIG_BPF_JIT_ALWAYS_ON=y
> > > CONFIG_IPV6_SEG6_BPF=y
> > > CONFIG_NETFILTER_XT_MATCH_BPF=m
> > > # CONFIG_BPFILTER is not set
> > > CONFIG_NET_CLS_BPF=m
> > > CONFIG_NET_ACT_BPF=m
> > > CONFIG_BPF_JIT=y
> > > CONFIG_BPF_STREAM_PARSER=y
> > > CONFIG_LWTUNNEL_BPF=y
> > > CONFIG_HAVE_EBPF_JIT=y
> > > CONFIG_BPF_EVENTS=y
> > > # CONFIG_BPF_KPROBE_OVERRIDE is not set
> > > # CONFIG_TEST_BPF is not set
> >
> > Hi
> >
> > I've installed clean archlinux to try this out and it works as expected,
> > I'm able to attach USB device into a VM.
> >
> > My system env is mostly the same as yours except for kernel version:
> >
> > kernel 5.4.13
> > libvirt 5.10.0
> > qemu 4.2.0, using KVM.
> >
> > Please enable libvirt debug logs [1] and share the output with us.
>
> I've updated to 5.4.13 and created a barebones VM without storage to
> reproduce the behaviour. libvirtd debug logs are attached. There appear
> to be two BPF failures of the same BPF program (?). The first is on line
> 23209, which appears to be part of machine startup, and which I don't
> actually notice. The second one is where I manually add the USB device,
> on line 30599.
>
> Thanks,
Thanks for the logs, but it did not help to figure out where the issue
is. I was hoping to see some error output from the syscall but the line
that should contain it is empty:
2020-01-20 19:47:15.589+0000: 8579: debug : virBPFLoadProg:78 :
Can you please check system logs and output of dmesg?
I've managed to run into this article [1] that explains that even if you
have all permissions and no SELinux you can still be blocked by
something called kernel_lockdown and it should appear in dmesg.
Pavel
[1] <https://gehrcke.de/2019/09/running-an-ebpf-program-may-require-lifting-th...>
4 years, 7 months
PCI/GPU Passthrough with xen
by Christoph
Hi All,
it is possible to use pci/gpu passthrough with xen and libvirt?
If yes, how is the syntax? Can I get an example?
--
------
Greetz
4 years, 10 months
Does Libvirt's json parser support single quoted string in qmp json string?
by Peter Luo
Hi All,
I’m using qmp command via “virsh qemu-monitor-command” to perform block related jobs.
And in my case, I execute block-commit to commit the changes in the top image to the base image which is encrypted.
So in the base parameter, I need a json string which is single quoted to support the encryption parameters.
However, the virsh is failed to parse the whole json qmp command.
Attempt 1: Single quote without backflash, failed
root@host:~# virsh qemu-monitor-command i-9wdfw2x8 "{\"execute\": \"block-commit\", \"arguments\": { \"device\": \"drive-virtio-disk2\", \"job-id\": \"job100\", \"base\":'json:{\"encrypt.key-secret\":\"vol-38973xjl.secret\",\"driver\":\"qcow2\",\"file\":{\"driver\":\"file\",\"filename\":\"/pitrix/data/container/vol-38973xjl.img\"}}', \"top\": \"/pitrix/data/container/vol-38973xjl_ss-2tw7v0mm.img\"}}"
error: internal error: cannot parse json {"execute": "block-commit", "arguments": { "device": "drive-virtio-disk2", "job-id": "job100", "base":'json:{"encrypt.key-secret":"vol-38973xjl.secret","driver":"qcow2","file":{"driver":"file","filename":"/pitrix/data/container/vol-38973xjl.img"}}', "top": "/pitrix/data/container/vol-38973xjl_ss-2tw7v0mm.img"}}: lexical error: invalid char in json text.
, "job-id": "job100", "base":'json:{"encrypt.key-secret":"vo
(right here) ------^
Attempt 2: Single quote with backflash, failed
root@host:~# virsh qemu-monitor-command i-9wdfw2x8 "{\"execute\": \"block-commit\", \"arguments\": { \"device\": \"drive-virtio-disk2\", \"job-id\": \"job100\", \"base\":\'json:{\"encrypt.key-secret\":\"vol-38973xjl.secret\",\"driver\":\"qcow2\",\"file\":{\"driver\":\"file\",\"filename\":\"/pitrix/data/container/vol-38973xjl.img\"}}\', \"top\": \"/pitrix/data/container/vol-38973xjl_ss-2tw7v0mm.img\"}}"
error: internal error: cannot parse json {"execute": "block-commit", "arguments": { "device": "drive-virtio-disk2", "job-id": "job100", "base":\'json:{"encrypt.key-secret":"vol-38973xjl.secret","driver":"qcow2","file":{"driver":"file","filename":"/pitrix/data/container/vol-38973xjl.img"}}\', "top": "/pitrix/data/container/vol-38973xjl_ss-2tw7v0mm.img"}}: lexical error: invalid char in json text.
, "job-id": "job100", "base":\'json:{"encrypt.key-secret":"v
(right here) ------^
My libvirt version is 5.7.0, libyajl is 2.1.0.
Thanks,
Peter Luo
4 years, 10 months
Re: Does Libvirt's json parser support single quoted string in qmp json string?
by Peter Luo
Hi Peter Krempa,
Thanks for your quick response, yes, I know since libvirt 5.8, the -blockdev is used for disk by default.
However we have to maintain the old releases for the production environment for a while, so I still need use the old way to create the disk.
>"base" argument must be a string. this means you need double quotes in
>JSON ("). You also must properly escape any further JSON. >
Do you mean the base argument need be formatted like below?
\"base\":\"json:{\"encrypt.key-secret\":\"vol-38973xjl.secret\",\"driver\":\"qcow2\",\"file\":{\"driver\":\"file\",\"filename\":\"/pitrix/data/container/vol-38973xjl.img\"}}\"
Please help me to point out where the examples are located? I did take a quick look at those test files, but no one seems to be matched with my case.
Thanks,
Peter Luo
On 31/1/20, 6:52 PM, "Peter Krempa" <pkrempa(a)redhat.com> wrote:
On Fri, Jan 31, 2020 at 18:38:33 +0800, Peter Luo wrote:
> Hi All,
>
>
>
> I’m using qmp command via “virsh qemu-monitor-command” to perform block related jobs.
>
> And in my case, I execute block-commit to commit the changes in the top image to the base image which is encrypted.
>
> So in the base parameter, I need a json string which is single quoted to support the encryption parameters.
>
> However, the virsh is failed to parse the whole json qmp command.
None of the above should be required with libvirt-5.10 and later when
using qemu-4.2. Those two versions start using blockdev way of
specifying images and encrypted images are supported.
Please consider using libvirt-6.0 though as there are few fixes for
blockdev.
>
>
>
> Attempt 1: Single quote without backflash, failed
>
> root@host:~# virsh qemu-monitor-command i-9wdfw2x8 "{\"execute\": \"block-commit\", \"arguments\": { \"device\": \"drive-virtio-disk2\", \"job-id\": \"job100\", \"base\":'json:{\"encrypt.key-secret\":\"vol-38973xjl.secret\",\"driver\":\"qcow2\",\"file\":{\"driver\":\"file\",\"filename\":\"/pitrix/data/container/vol-38973xjl.img\"}}', \"top\": \"/pitrix/data/container/vol-38973xjl_ss-2tw7v0mm.img\"}}"
>
> error: internal error: cannot parse json {"execute": "block-commit", "arguments": { "device": "drive-virtio-disk2", "job-id": "job100", "base":'json:{"encrypt.key-secret":"vol-38973xjl.secret","driver":"qcow2","file":{"driver":"file","filename":"/pitrix/data/container/vol-38973xjl.img"}}', "top": "/pitrix/data/container/vol-38973xjl_ss-2tw7v0mm.img"}}: lexical error: invalid char in json text.
>
> , "job-id": "job100", "base":'json:{"encrypt.key-secret":"vo
"base" argument must be a string. this means you need double quotes in
JSON ("). You also must properly escape any further JSON.
Given that libvirt now supports the operation natively I'll refrain from
elaborating on how to properly escape JSON to contain JSON strings, but
there are few examples in the test suite.
But please use the upstream supported way instead.
4 years, 10 months
Detecting of features of VMs
by Peter Krempa
Hi,
I was asked by Nir and Eyal of the oVirt project on how to detect
whether a certain feature is supported by libvirt. As I thought it might
be better to document this publically rather than being lost in a
private thread I'm posting this to libvirt-users. The specific question
will be answered below.
---
There are currently two interfaces which allow discovery of libvirts and
in turn qemu's capabilities. Both return an XML which describes various
aspects of the hosts or VMs capabilities.
virConnectGetCapabilities(conn)
https://libvirt.org/formatcaps.html
The XML returned by this API describes mostly the host itself, the CPU,
NUMA topology, security driver support, migration features but also
describes guests architectures supported by the guest.
In case of the qemu driver the guest section describes some of the
aspects and configurations supported by the default qemu binary, the
machine types and virtualization types it supports. Additionally the
<features> section describes support for some long-existing features
such as ACPI, APIC and disk snapshots. As these features are supported
for a long time, it can be assumed that they are present (at least in
case of the qemu driver) when the second API is present.
Now while the virConnectGetCapabilities API provides mostly useful
information about the host, the limitation of not being able to report
information about specific qemu binaries or machine types lead to
introduction.
virConnectGetDomainCapabilities(conn, emulator_binary_path, architecture,
machine_type, virt_type, flags)
https://libvirt.org/formatdomaincaps.html
The XML returned by this API describes the capabilities of an VM which
would be started using the parameters given to the API (note that if the
parameters are NULL a default is provided).
The <os> subelement describes supported OS loader types and firmware
binaries. <cpu> describes which CPU models are supported by the emulator
and also the CPU which would be used if 'host-model' is selected as the
CPU model.
The <devices> section describes models and some properties of devices
supported by the VM. The 'enum's reported in this XML map to supported
values of some of the fields we report the possible configurations for.
Note that these values are reported individually and all combinations
aren't necessarily supported.
The last section 'features' describes whether some high-level features
supported by such a VM. The features themselves are described in the
documentation above.
Note that the entries into 'features' are added arbitrarily depending on
whether a feature is deemed important enough to be exposed. So please
feel free to report if anything is missing or it would be helpful if we
reported any feature.
---
Now specifically to the question: I was asked on when it's safe to pass
VIR_DOMAIN_UNDEFINE_CHECKPOINTS_METADATA to virDomainUndefine.
In this case it's safe to pass it if <features> contains the <backup>
element regardless of the value of 'supported' attribute. I'll also
mention this in the documentation of the domain caps XML.
4 years, 10 months
