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 1420205 - For console device, default value of append attribute is not consistent with the document
Summary: For console device, default value of append attribute is not consistent with ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Peter Krempa
QA Contact: Jingjing Shao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-08 06:57 UTC by yalzhang@redhat.com
Modified: 2017-08-02 00:01 UTC (History)
8 users (show)

Fixed In Version: libvirt-3.1.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 17:21:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1846 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2017-08-01 18:02:50 UTC

Description yalzhang@redhat.com 2017-02-08 06:57:19 UTC
Description of problem:
In the document, it is said that the default value for append is 'off', but if omit this attribute, we get the default performance is the same as append='on', which is not consistent with the document.

Version-Release number of selected component (if applicable):
libvirt-2.5.0-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. prepare a guest with console type='file', and omit the append attribute for the source element.
# virsh dumpxml rhel7.4 | grep /console -B7
    <serial type='file'>
      <source path='/var/log/libvirt/vm-serial.log'/>
      <target port='0'/>
    </serial>
    <console type='file'>
      <source path='/var/log/libvirt/vm-serial.log'/>
      <target type='serial' port='0'/>
    </console>
2.  
# ll /var/log/libvirt/vm-serial.log
ls: cannot access /var/log/libvirt/vm-serial.log: No such file or directory
3.  
# virsh start rhel7.4
Domain rhel7.4 started

4.  when start the guest, the fresh log file is created
# cat /var/log/libvirt/vm-serial.log 

5. after the guest boot completed, check the log file
# cat /var/log/libvirt/vm-serial.log  

Red Hat Enterprise Linux Server 7.3 (Maipo)
Kernel 3.10.0-514.el7.x86_64 on an x86_64

localhost login: [root@server7 ~]# 

6.  destroy and start the guest again
# virsh destroy rhel7.4
Domain rhel7.4 destroyed
# cat /var/log/libvirt/vm-serial.log

Red Hat Enterprise Linux Server 7.3 (Maipo)
Kernel 3.10.0-514.el7.x86_64 on an x86_64

localhost login: [root@server7 ~]# 

 # virsh start rhel7.4
Domain rhel7.4 started

7.  When restart the guest, the log is appended, the performance is the same as append='on'
# cat /var/log/libvirt/vm-serial.log

Red Hat Enterprise Linux Server 7.3 (Maipo)
Kernel 3.10.0-514.el7.x86_64 on an x86_64

localhost login: [root@server7 ~]# 


# cat /var/log/libvirt/vm-serial.log

Red Hat Enterprise Linux Server 7.3 (Maipo)
Kernel 3.10.0-514.el7.x86_64 on an x86_64

localhost login: 
Red Hat Enterprise Linux Server 7.3 (Maipo)
Kernel 3.10.0-514.el7.x86_64 on an x86_64

localhost login: [root@server7 ~]# 

8. 
 In the libvirt.org  http://libvirt.org/formatdomain.html#elementsConsole 
and file:///usr/share/doc/libvirt-docs-2.5.0/html/formatdomain.html#elementsConsole
It is said that the default value is 'off'.
" If the interface type presented to the host is "file", then the source element may contain an optional attribute append that specifies whether or not the information in the file should be preserved on domain restart. Allowed values are "on" and ** "off" (default)** . Since 1.3.1. "

Actual results:
The default performance (append='on') is not consistent with the document (default is 'off').

Expected results:
The default performance is not append the log info, or the 'default value is on' specified in the document.

Additional info:
N/A

Comment 2 Peter Krempa 2017-03-01 12:36:35 UTC
The default value is treated differently when we use virtlogd instead of the default backend where ommiting the argument would by default truncate the file.

Comment 3 Peter Krempa 2017-03-02 08:04:03 UTC
Fixed upstream:

commit 215a8a976466117104d216f1f336c2c3ad51d010
Author: Peter Krempa <pkrempa>
Date:   Wed Mar 1 18:15:05 2017 +0100

    qemu: command: Truncate the chardev logging file even if append is not present
    
    Our documentation states that the chardev logging file is truncated
    unless append='on' is specified. QEMU also behaves the same way and
    truncates the file unless we provide the argument. The new virlogd
    implementation did not honor if the argument was missing and continued
    to append to the file.
    
    Truncate the file even when the 'append' attribute is not present to
    behave the same with both implementations and adhere to the docs.

Comment 5 Jan Stancek 2017-03-30 12:54:20 UTC
I'm seeing 2 issues that might be consequence of this change, strangely enough only on powerpc:

1. Bug 1437501 - avc: denied { unlink } for pid=11477 comm="virtlogd" scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0

2. it breaks guest log monitor/uploader in Beaker core task /distribution/virt/install. Daemon which monitors guest console log is left with fd, that's no longer getting any updates.

Guests are installed via virt-install, which generates XML automatically.

Is there a way to restore back append behaviour that is backwards compatible up to RHEL5?

Comment 6 Jakub Raček 2017-04-12 15:44:50 UTC
Created a separate BZ for issue 2 mentioned in comment #5. https://bugzilla.redhat.com/show_bug.cgi?id=1441751

Comment 7 Jingjing Shao 2017-05-05 12:25:36 UTC
Verify this bug as below

# rpm -q libvirt
libvirt-3.2.0-3.el7.x86_64

# virsh dumpxml V | grep serial -A5
 <serial type='file'>
      <source path='/var/log/libvirt/vm-serial.log'/>
      <target port='0'/>
      <alias name='serial0'/>
    </serial>
    <console type='file'>
      <source path='/var/log/libvirt/vm-serial.log'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>

# ll /var/log/libvirt/vm-serial.log
ls: cannot access /var/log/libvirt/vm-serial.log: No such file or directory

# virsh start V
Domain V started

# cat  /var/log/libvirt/vm-serial.log
....
Red Hat Enterprise Linux Server 7.4 Beta (Maipo)
Kernel 3.10.0-611.el7.x86_64 on an x86_64


# virsh destroy V
Domain V destroyed

# virsh start V
Domain V started

# cat  /var/log/libvirt/vm-serial.log
.....
Red Hat Enterprise Linux Server 7.4 Beta (Maipo)
Kernel 3.10.0-611.el7.x86_64 on an x86_64


The result is as expected

Comment 8 errata-xmlrpc 2017-08-01 17:21:45 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, 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/RHEA-2017:1846

Comment 9 errata-xmlrpc 2017-08-02 00:01: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, 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/RHEA-2017:1846


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