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

[Daniel P. Berrange]

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|