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 1008533 - Improve error message when requested dump directory does not exist
Summary: Improve error message when requested dump directory does not exist
Keywords:
Status: CLOSED DUPLICATE of bug 851411
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Eric Blake
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1004400
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-16 14:38 UTC by Doron Fediuck
Modified: 2014-04-02 07:03 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1004400
Environment:
Last Closed: 2014-04-02 07:03:12 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Doron Fediuck 2013-09-16 14:38:00 UTC 
Cloning in order to track in RHEL 6.5.

+++ This bug was initially created as a clone of Bug #1004400 +++

Description of problem:
The default value of auto_dump_path is /var/lib/libvirt/qemu/dump, this directory is not created at installation

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1. yum -y install libvirt
2. ls /var/lib/libvirt/qemu/dump

Actual results:
dump directory is missing

Expected results:
dump directory should exist

Additional info:

--- Additional comment from Eric Blake on 2013-09-04 17:37:23 IDT ---

Why do you think the directory should be created at installation?  What's wrong with the current behavior of auto-creating it at use time the first time something is actually dumped there?  I see little reason to create an empty directory, when it gets auto-created at the point where it is needed, so I'm inclined to close this as not a bug unless you can explain WHY you want it at installation time.

--- Additional comment from Laszlo Hornyak on 2013-09-04 17:46:21 IDT ---

I do not really care when is it created, but it was not created when crasing a VM with watchdog set to action=dump

--- Additional comment from Eric Blake on 2013-09-04 17:49:05 IDT ---

Ah, that makes more sense for why you are raising a bug report.  Can you show actual steps you used for triggering a watchdog crash, and the error message that results when the directory does not exist, in the hopes that it can help someone pinpoint the watchdog code that is not properly auto-creating the directory?

--- Additional comment from Daniel Berrange on 2013-09-04 17:55:44 IDT ---

NB, the other general reason for creating dirs at RPM install time, rather than 'mkdir' at runtime is to ensure correct SELinux labelling. Probably doesn't matter here since the label of the default dump dir will match the parent dir anyway, but it is good practice to pre-create the dirs anyway IMHO

--- Additional comment from Laszlo Hornyak on 2013-09-04 18:28:51 IDT ---

libvirt log

--- Additional comment from Laszlo Hornyak on 2013-09-04 18:29:41 IDT ---



--- Additional comment from Laszlo Hornyak on 2013-09-04 18:39:27 IDT ---


Steps to Reproduce:
1. create VM with watchdog action=dump
2. run the VM
3. crash the VM
4. wait till watchdog triggered

Actual results:
- Vm goes paused for a few seconds, then it turns back to running state
- no dump found on the local filesystem


Expected results:
- Dump should have been created
- VM should remain in paused mode (unless there is any reason to keep a VM running after it is crashed)
Comment 2 EricLee 2013-09-24 09:54:38 UTC 
Hi Doron,

How did you get the situation that dir missing? It will be created automatically after start libvirtd in my test.

A clean rhel6.4 os, install libvirt, and the start libvirtd:
# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.4 (Santiago)

# yum install -y libvirt

# ll /var/lib/libvirt/qemu/
total 0

# service libvirtd start
Starting libvirtd daemon:                                  [  OK  ]

# ll /var/lib/libvirt/qemu/
total 12
drwxr-xr-x. 2 root root 4096 Sep 24 05:52 dump
drwxr-xr-x. 2 qemu qemu 4096 Sep 24 05:52 save
drwxr-xr-x. 2 qemu qemu 4096 Sep 24 05:52 snapshot

I think you should start libvirtd service to do the action of crashing guest. But that dump path is created automatically.

Thanks,
EricLee
Comment 3 Eric Blake 2013-09-24 22:40:30 UTC 
I've confirmed that 'virsh dump' autocreates the directory for libvirt-1.1.2-2.fc19.x86_64; I still need to play with watchdog dumps (if that's a different directory that forgets to auto-create) as well as test older libvirt versions.
Comment 5 EricLee 2013-09-25 05:25:50 UTC 
(In reply to Eric Blake from comment #3)
> I've confirmed that 'virsh dump' autocreates the directory for
> libvirt-1.1.2-2.fc19.x86_64; I still need to play with watchdog dumps (if
> that's a different directory that forgets to auto-create) as well as test
> older libvirt versions.

Hi Eric,

I have tested that in RHEL6.5 libvirt-0.10.2-26.el6.x86_64, 'virsh dump' will not autocreate directory if not existing, and will throw error:

# virsh dump aa /dir/not/exist/aa.dump
error: Failed to core dump domain aa to /dir/not/exist/aa.dump
error: Failed to create file '/dir/not/exist/aa.dump': Operation not permitted

and I got the same error log in libvirtd.log when use watchdog to dump the guest to not existing dir.

Thanks,
EricLee
Comment 6 Eric Blake 2013-09-25 15:19:13 UTC 
(In reply to EricLee from comment #5)
> (In reply to Eric Blake from comment #3)
> > I've confirmed that 'virsh dump' autocreates the directory for
> > libvirt-1.1.2-2.fc19.x86_64; I still need to play with watchdog dumps (if
> > that's a different directory that forgets to auto-create) as well as test
> > older libvirt versions.
> 
> Hi Eric,
> 
> I have tested that in RHEL6.5 libvirt-0.10.2-26.el6.x86_64, 'virsh dump'
> will not autocreate directory if not existing, and will throw error:
> 
> # virsh dump aa /dir/not/exist/aa.dump
> error: Failed to core dump domain aa to /dir/not/exist/aa.dump
> error: Failed to create file '/dir/not/exist/aa.dump': Operation not
> permitted
> 
> and I got the same error log in libvirtd.log when use watchdog to dump the
> guest to not existing dir.
> 
> Thanks,
> EricLee

Explicitly requesting to dump to /dir/not/exist is not the same as automatic dumping to a default of /var/lib/libvirt/qemu/dump/.  Since no one is able to prove that the automatic directory creation on watchdog action is not working, I'm closing this as not a bug.  We can reopen it if someone provides evidence of an actual problem.

I did some git spelunking; we have been autocreating since at least commit e123e1ee (v0.9.4).  I will also point out that we do not install the /var/lib/libvirt/qemu/save/ directory in the spec file (used by managedsave) - if automatic creation isn't working, I would suspect that it would be a problem for more than just dump images.
Comment 7 hyao@redhat.com 2013-10-11 06:55:56 UTC 
Hi Eric,

I think the error message for not exist directory is not specific.Is it possible to change it to "cannot access /dir/not/exist/: No such file or directory"?
Comment 9 Eric Blake 2013-10-14 14:33:13 UTC 
(In reply to hyao from comment #7)
> Hi Eric,
> 
> I think the error message for not exist directory is not specific.Is it
> possible to change it to "cannot access /dir/not/exist/: No such file or
> directory"?

Yes, it's probably possible to enhance the error message quality, but it's lower priority than the original report.
Comment 11 Jiri Denemark 2014-04-02 07:03:12 UTC 
The bug in the error message is already tracked by bug 851411.

*** This bug has been marked as a duplicate of bug 851411 ***
Note You need to log in before you can comment on or make changes to this bug.