Bug 1754887 - Silent failure adding kvmclock timer on non-86_64
Summary: Silent failure adding kvmclock timer on non-86_64
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libvirt
Version: 8.2
Hardware: All
OS: Unspecified
low
low
Target Milestone: rc
: 8.3
Assignee: Michal Privoznik
QA Contact: smitterl
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-24 10:02 UTC by smitterl
Modified: 2020-11-17 17:45 UTC (History)
10 users (show)

Fixed In Version: libvirt-6.6.0-5.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-17 17:45:34 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description smitterl 2019-09-24 10:02:04 UTC
Description of problem:
Configuring kvmclock timer for s390x without @present starts the vm without problems although kvmclock is not supported on s390x.

Version-Release number of selected component (if applicable):
qemu-kvm-4.1.0-10.module+el8.1.0+4234+33aa4f57
libvirt-5.6.0-6.module+el8.1.0+4244+9aa4e6bb

How reproducible:
Always

Steps to Reproduce:
1. Add <timer name="kvmclock"/> to clock config
2. Start vm

Actual results:
VM is started. Timer settings seems to be ignored. No errors in logs.


Expected results:
1. VM is not started
2. error message indicates kvmclock not supported on s390x.

Additional information:
When setting timer@present="yes" or "no", starting the machine fails with a different error message:

error: unsupported configuration: CPU flags requested but can't determine default CPU for arch s390x

Comment 1 Thomas Huth 2020-07-22 11:22:37 UTC
Suggested patch upstream:
https://www.redhat.com/archives/libvir-list/2020-July/msg01547.html

Comment 2 Michal Privoznik 2020-09-02 16:55:02 UTC
Merged upstream as:

2f5d8ffebe qemu: Do not silently allow non-available timers on non-x86 systems

v6.7.0-32-g2f5d8ffebe

Comment 3 Thomas Huth 2020-09-02 17:08:52 UTC
A note for QE: <timer name="kvmclock"/> will continue to be silently ignored. If I understood that correctly, without the present="yes" that <timer> tag simply means: "Give me that timer if available, otherwise just ignore it". The difference with the upstream patch is now that you should get an immediate error message when you add a <timer name="kvmclock" present="yes"/> instead of only getting an error when you try to start the guest.

Comment 10 smitterl 2020-09-15 17:38:16 UTC
[root@kernelqe3 libvirt]# virsh start avocado-vt-vm1
error: Failed to start domain avocado-vt-vm1
error: unsupported configuration: Configuring the 'kvmclock' timer is not supported for virtType=kvm arch=s390x machine=s390-ccw-virtio-rhel8.2.0 guests

[root@kernelqe3 libvirt]# virsh dumpxml avocado-vt-vm1 > /root/avocado-vt-vm1 
[root@kernelqe3 libvirt]# virsh undefine avocado-vt-vm1
Domain avocado-vt-vm1 has been undefined

[root@kernelqe3 libvirt]# virsh define /root/avocado-vt-vm1
error: Failed to define domain from /root/avocado-vt-vm1
error: unsupported configuration: Configuring the 'kvmclock' timer is not supported for virtType=kvm arch=s390x machine=s390-ccw-virtio-rhel8.2.0 guests

[root@kernelqe3 libvirt]# vim /root/avocado-vt-vm1 
[root@kernelqe3 libvirt]# virsh define /root/avocado-vt-vm1 
Domain avocado-vt-vm1 defined from /root/avocado-vt-vm1

[root@kernelqe3 libvirt]# virsh edit avocado-vt-vm1
error: unsupported configuration: Configuring the 'kvmclock' timer is not supported for virtType=kvm arch=s390x machine=s390-ccw-virtio-rhel8.2.0 guests
Failed. Try again? [y,n,i,f,?]:

Comment 11 smitterl 2020-09-15 17:39:14 UTC
(In reply to smitterl from comment #10)
> [root@kernelqe3 libvirt]# virsh start avocado-vt-vm1
> error: Failed to start domain avocado-vt-vm1
> error: unsupported configuration: Configuring the 'kvmclock' timer is not
> supported for virtType=kvm arch=s390x machine=s390-ccw-virtio-rhel8.2.0
> guests
> 
> [root@kernelqe3 libvirt]# virsh dumpxml avocado-vt-vm1 >
> /root/avocado-vt-vm1 
> [root@kernelqe3 libvirt]# virsh undefine avocado-vt-vm1
> Domain avocado-vt-vm1 has been undefined
> 
> [root@kernelqe3 libvirt]# virsh define /root/avocado-vt-vm1
> error: Failed to define domain from /root/avocado-vt-vm1
> error: unsupported configuration: Configuring the 'kvmclock' timer is not
> supported for virtType=kvm arch=s390x machine=s390-ccw-virtio-rhel8.2.0
> guests
> 
> [root@kernelqe3 libvirt]# vim /root/avocado-vt-vm1 
> [root@kernelqe3 libvirt]# virsh define /root/avocado-vt-vm1 
> Domain avocado-vt-vm1 defined from /root/avocado-vt-vm1
> 
> [root@kernelqe3 libvirt]# virsh edit avocado-vt-vm1
> error: unsupported configuration: Configuring the 'kvmclock' timer is not
> supported for virtType=kvm arch=s390x machine=s390-ccw-virtio-rhel8.2.0
> guests
> Failed. Try again? [y,n,i,f,?]:

Tested upstream master@8c16f81eb97bbd576a009f64f13773200171704b

Comment 12 smitterl 2020-09-15 19:03:31 UTC
Upstream patch for regression test: https://www.redhat.com/archives/libvir-list/2020-September/msg00895.html

Comment 13 smitterl 2020-09-16 10:42:58 UTC
Verified with:
libvirt-daemon-6.6.0-5.module+el8.3.0+8092+f9e72d7e.s390x

Scenario: present = yes
-----------------------
# cat /root/domain.xml |grep timer
  <timer name="tsc" present="yes"/>
# virsh define /root/domain.xml 
error: Failed to define domain from /root/domain.xml
error: unsupported configuration: Configuring the 'tsc' timer is not supported for virtType=kvm arch=s390x machine=s390-ccw-virtio-rhel8.2.0 guests

Scenario: present n/a
---------------------
# cat /root/domain.xml |grep timer
	  <timer name="tsc"/>
# virsh define /root/domain.xml 
Domain vm2 defined from /root/domain.xml


Agreed with Thomas that this is a low priority item and having unit test shouldn't be blocking. Setting VERIFIED.

Comment 16 errata-xmlrpc 2020-11-17 17:45:34 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (virt:8.3 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:5137


Note You need to log in before you can comment on or make changes to this bug.