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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list