Re: [libvirt] [PATCH 2/2] qemu: extend logging to record guest configuration events

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

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.

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.

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.