Bug 669586 - No expected error prompt when compress guest core dump to invalid format
Summary: No expected error prompt when compress guest core dump to invalid format
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.1
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Osier Yang
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-14 03:38 UTC by zhanghaiyan
Modified: 2011-12-06 10:53 UTC (History)
8 users (show)

Fixed In Version: libvirt-0.9.4-rc2-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 10:53:40 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1513 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2011-12-06 01:23:30 UTC

Description zhanghaiyan 2011-01-14 03:38:11 UTC
Description of problem:
When compress guest core dump to invalid format, an error should prompt saying 'Invalid dump image format specified in configuration file', but in fact, no error pops up. 

Version-Release number of selected component (if applicable):
- libvirt-0.8.7-1.el6.x86_64
- kernel-2.6.32-94.el6.x86_64
- qemu-kvm-0.12.1.2-2.128.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Get a running guest named 'cdrom_test'
# virsh start cdrom_test
2. Add the following line in /etc/libvirt/qemu.conf
# dump_image_format = "raw"
 dump_image_format = "abc
3. # service libvirtd restart
4. # virsh dump cdrom_test cdrom_test.abc
  
Actual results:
step4, no error prompt and can dump successfully
# virsh dump cdrom_test cdrom_test.abc
Domain cdrom_test dumped to cdrom_test.abc
Check the file format
# file cdrom_test.abc 
cdrom_test.abc: QEMU's suspend to disk image

Expected results:
step 4, Should pops up an error as below
error: Failed to core dump domain cdrom_test to cdrom_test.abc
error: operation failed: Invalid dump image format specified in configuration file

Additional info:
This function works well when I built the latest source code on fedora some days before.

Comment 2 Osier Yang 2011-01-17 12:17:55 UTC
http://www.redhat.com/archives/libvir-list/2011-January/msg00715.html

patch acked by upstream.

Comment 3 Eric Blake 2011-01-17 16:00:15 UTC
Hmm.  Upstream commit 1b6f13bb7002d intentionally chose the behavior of falling back to raw if the compression type was invalid, because the thought was that in the event of a crash, it was more important to get a dump produced in some form than to fail because of a mis-configuration.  In other words, I can't help but wonder if this bug should be closed as WONTFIX, because the behavior is intentional.

commit 1b6f13bb7002da76db15242e1d996e8a6222a754
Author: Hu Tao <hutao.com>
Date:   Tue Nov 30 15:12:54 2010 +0800

    Fall back to QEMUD_SAVE_FORMAT_RAW if compression method fails.
    
    When dumping a domain, it's reasonable to save dump-file in raw format
    if dump format is misconfigured or the corresponding compress program
    is not available rather then fail dumping.

Comment 4 Osier Yang 2011-01-18 05:35:22 UTC
<snip>
because the thought was that
in the event of a crash, it was more important to get a dump produced in some
form than to fail because of a mis-configuration.
</snip>

Yeah, I didn't realize this, the patch made by Hu Tao is helpful, but anyway, the error report statements should be improved, even use "VIR_WARN" is better than using "qemuReportError", isn't it? otherwise user will never known what happened, If no problem, I'd like make a new patch.

Comment 5 Osier Yang 2011-01-25 08:43:54 UTC
v2 patch posted to upstream:
http://www.redhat.com/archives/libvir-list/2011-January/msg00990.html

Comment 6 RHEL Program Management 2011-04-04 01:44:03 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 7 Dave Allan 2011-06-08 18:17:27 UTC
Osier, what happened with that patch, did we ever decide what to do with it?

Comment 8 Osier Yang 2011-07-28 01:42:19 UTC
commit 01e1ea1219d50d188a526880b9d4dd9babc7bfa1
Author: Osier Yang <jyang>
Date:   Thu Jul 28 09:37:52 2011 +0800

    qemu: Improve docs for virsh dump format
    
    The error in getCompressionType will never be reported, change
    the errors codes into warning (VIR_WARN("%s", _(foo)); doesn't break
    syntax-check rule), and also improve the docs in qemu.conf to tell
    user the truth.

Patch commited to upstream.

Comment 10 yuping zhang 2011-08-02 08:46:03 UTC
Verified this with with 
kernel-2.6.32-172.el6.x86_64
qemu-kvm-0.12.1.2-2.172.el6.x86_64
libvirt-0.9.4-0rc2.el6.x86_64

Steps:
1.Add the following line in /etc/libvirt/qemu.conf
# dump_image_format = "raw"
 dump_image_format = "123"
2. # service libvirtd restart
3.# virsh dump test test.123
Domain test dumped to test.123
4.# qemu-img info test.123
image: test.123
file format: raw
virtual size: 282M (295681024 bytes)
disk size: 282M

In log file /var/log/libvirt/libvirtd.log,the warning message:
06:44:21.882: 8723: warning : getCompressionType:2737 : Invalid dump image format specified in configuration file, using raw

In /etc/libvirt/qemu.conf file:
# dump_image_format is used when you use 'virsh dump' at emergency
# crashdump, and if the specified dump_image_format is not valid, or
# the requested compression program can't be found, this falls
# back to "raw" compression.

So change the status to VERIFIED.

Comment 11 errata-xmlrpc 2011-12-06 10:53:40 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.

http://rhn.redhat.com/errata/RHBA-2011-1513.html


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