RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2128993 - data type of start time should be improved
Summary: data type of start time should be improved
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: libvirt
Version: 9.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Peter Krempa
QA Contact: Lili Zhu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-09-22 08:51 UTC by Lili Zhu
Modified: 2023-05-09 08:09 UTC (History)
6 users (show)

Fixed In Version: libvirt-8.10.0-1.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-05-09 07:27:15 UTC
Type: Bug
Target Upstream Version: 8.10.0
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-134663 0 None None None 2022-09-22 09:29:43 UTC
Red Hat Product Errata RHBA-2023:2171 0 None None None 2023-05-09 07:27:30 UTC

Description Lili Zhu 2022-09-22 08:51:30 UTC
Description of problem:
Error msg should be improved when the start time is out of range or malformed

Version-Release number of selected component (if applicable):
libvirt-8.5.0-6.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
Scenario 1:
1. Define a guest with following xml
 <clock offset='absolute' start='4294967296'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>

2. define the guest
# virsh define avocado-vt-vm1.xml 
Domain 'avocado-vt-vm1' defined from avocado-vt-vm1.xml

3. start the guest
# virsh start avocado-vt-vm1 
Domain 'avocado-vt-vm1' started

4. check qemu cmdline
...
-rtc base=2106-02-07T06:28:16,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet
...

5.Edit the guest xml, should make sure the start time is not 4294967296 before edit
# virsh edit avocado-vt-vm1
  <clock offset='absolute' start='4294967296'>    <== change the start to 4294967296
error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng
Expecting an element timer, got nothing
Extra element clock in interleave
Element domain failed to validate content

Failed. Try again? [y,n,i,f,?]: 

From the code,
        /* absolute clock start time for VIR_DOMAIN_CLOCK_OFFSET_ABSOLUTE */
        unsigned long long starttime;
The data type of starttime is unsigned long long

          <group>
            <attribute name="offset">
              <value>absolute</value>
            </attribute>
            <attribute name="start">
              <ref name="unsignedInt"/>
            </attribute>
          </group>

But data type in rng file is unsignedInt

Scenario2:
1. define a guest with start time large than 253402300799
  <clock offset='absolute' start='253402300800'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>

2. start the guest
virsh start avocado-vt-vm1
error: Failed to start domain 'avocado-vt-vm1'
error: internal error: process exited while connecting to monitor: 2022-09-22T08:47:48.299885Z qemu-kvm: invalid datetime format
valid formats: '2006-06-17T16:01:21' or '2006-06-17'

(qemu will report the error to show the start time is out of range, and the error msg is misleading here, since it is said in libvirt doc: start attribute takes an epoch timestamp)



Actual results:
The data type of start time is not self-consistent.

Expected results:


Additional info:

Comment 1 Peter Krempa 2022-11-04 09:04:30 UTC
Fixed upstream:

commit 9acd9fa7336fbc910b92254f40be7570a353e4c9
Author: Peter Krempa <pkrempa>
Date:   Thu Nov 3 16:04:17 2022 +0100

    qemu: validate: Validate maximum start time for <clock offset='absolute'>
    
    Glib can internally convert only unix timestamps up to
    9999-12-31T23:59:59 (253402300799). Validate that the user doesn't use
    more than that as otherwise we cause an assertion failure:
    
     (process:1183396): GLib-CRITICAL **: 14:25:00.906: g_date_time_format: assertion 'datetime != NULL' failed
    
    Additionally adjust the schema to allow bigger values as we use
    'unsigned long long' to parse the value.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2128993
    Signed-off-by: Peter Krempa <pkrempa>
    Reviewed-by: Ján Tomko <jtomko>

v8.9.0-103-g9acd9fa733

Comment 2 Lili Zhu 2022-12-06 12:34:04 UTC
Tested this bug with:
libvirt-8.10.0-1.el9.x86_64

Scenario 1:
1. Edit the guest xml, should make sure the start time is not 4294967296 before edit
# virsh edit avocado-vt-vm1
  <clock offset='absolute' start='4294967296'>

Domain 'avocado-vt-vm1' XML configuration edited.


Scenario2:
1. define a guest with start time large than 253402300799
  <clock offset='absolute' start='253402300800'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>

# virsh define avocado-vt-vm1.xml 
error: Failed to define domain from avocado-vt-vm1.xml
error: unsupported configuration: The maximum 'start' value for <clock offset='absolute'> is 253402300799

Comment 6 Lili Zhu 2022-12-21 02:38:14 UTC
Verify this with:
libvirt-8.10.0-2.el9.x86_64

The verification steps are the same with those in Comment #2.

As the testing result matches with the expected result, mark the bug as verified.

Comment 8 errata-xmlrpc 2023-05-09 07:27:15 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 (libvirt 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-2023:2171


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