Hi, On Mon, Apr 04, 2011 at 03:55:26PM +0100, Daniel P. Berrange wrote:
On Mon, Mar 28, 2011 at 05:13:47PM +0900, Naoya Horiguchi wrote:
The following events can be logged onto /var/log/libvirt/qemu/<domain>.log:
starting/shutting down/suspending/resuming/migrating domains changing the amount of memory changing the number of VCPUs inserting/ejecting a media into/from CDROM/Floppy devices attaching/detaching PCI/SCSI/USB devices (including NICs and disks.)
This patch generalizes qemudLog*() introduced in commit 93bc093ac to handle the whole range of qemu driver's events.
This is useful for the same reason as explainged in the previous patch.
I think we need to think about the question of logging in a more thorough way.
- libvirt.c: Logs invocation of every API call - qemu/driver.c/qemu_audit.c: Logs major lifecycle changes & any config change that is related host resources - virterror.c: Logs any API call that results in an error - qemu_driver.c: Logs a set of lifecycle/config changes (your previous patch 1/2) at VIR_INFO - qemu_driver.c: Logs a different set of lifecycle/config changes in /var/log/libvirt/qemu/<domain>.loog
Thank you for detailed explanation.
I don't think the latter two are particularly great because they are only cover a fraction of the API calls in the QEMU driver. libvirt.c has full logging cover, but it only covers API calls, it doesn't indicate whether it was successful or failed.
I see.
For SystemTAP, we likely want to add probes to libvirt.c which will log initial parameters, and the return values. Our SystemTAP probe macros also generate log statements.
A further complication is that /var/log/libvirt/qemu/$NAME.log is intended for QEMU's stderr output. The only time that libvirtd currently writes to it, is before QEMU starts and after it has shutdown.
OK.
This new patch means that libvirtd writes to it while QEMU is running, which is not really safe because you can now end up with 2 proceses writing to the same file at once. The log messages may well get interleaved/corrupted by each other. I don't think that is good for something that wants to be used as a formal record of operations on a VM.
I think that in each driver we only really want to have to insert one set of formal "operation logging" calls. Since we already have the audit APIs present, I think we could try to make use of that to generate a record of operations against a VM in some way.
I didn't care about audit logging because it's not used in RHEL6.0. I tried this logging mechanism and made sure that this logging recorded enough information about operational events in /var/log/libvirt/libvirtd.log. This feature meets our demand, so I'll drop this patch. Thanks, Naoya